Doc.

Code (0003)

Apple VoLTE Certificate Assurance:

Analysis&Optimization for VoLTE
Call Drop
011 (Document version. The document version number consists of two digits. The
version number of the first release is 01. If the software version remains unchanged,
each time the document is updated, the last digit of the document version number is
increased by 1. When a newer version of the software is released, the first document
Issue corresponding to the new software version has the document version starting from 01.)

Date 2015-11-3

HUAWEI TECHNOLOGIES CO., LTD.

Issue 01 (2010-07-02) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd
Copyright © Huawei Technologies Co., Ltd. 2010. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be within
the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either expressed or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China

Web site: http://www.huawei.com

Email: support@huawei.com

Issue 01 (2010-07-02) Huawei Proprietary and Confidential ii

Copyright © Huawei Technologies Co., Ltd
Title: Apple VoLTE Certificate Assurance: Analysis&Optimization for VoLTE Call Drop

Author: t00252597/ Tie Yi

Product Family: LTE Product Version BTS3900 V100R010C10SPC120

Fault Type: VoLTE Call Drop

Keywords: Apple, iPhone, FDD, VoLTE, Call Drop, SRVCC, RRC Re-establishment Failure

Permission level: Huawei Engineers Permission

Issue 01 (2010-07-02) Huawei Proprietary and Confidential iii

Copyright © Huawei Technologies Co., Ltd
 1 Background

Saudi Operator Z need commercialize VoLTE service as first operator in Middle East Region, which will greatly
promote itself brand in market. As iPhone series smart phones are the most popular terminals in living network, if Z
need commercialize VoLTE service in iPhones, it must pass Apple VoLTE Certificate, then Apple will push IOS
upgrading software packet for all iPhone 6 and iPhone 6s subscribers under Z network.

2 Requirement for Apple Certificate

Apple VoLTE Certificate Regulation:

1. Apple uses engineering terminals and itself test software to test the VoLTE performance of network, Huawei is not
allowed to approach to Apple engineering terminals.
2. Apple will use 2 terminals as one set to dial VoLTE call automatically 100 times each other, each call will last
90seconds and then keep in idle mode for 30 seconds, there are 3 sets and call drop rate should be less than 4%.
3. Apple will choose the test route and scenario by itself.

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 2-1

Copyright © Huawei Technologies Co., Ltd
 3 Tasks to Satisfy the Requirement

1. Check the IMS, PS RNC and eNodeB software version if it support VoLTE commercialization.
Cooperate with all product lines, all software version support commercialization.
2. Arrange using iPhone 6 engineering terminal and Huawei Mate 7 which support VoLTE to do the drive test for
whole city to check the network radio quality, VoLTE performance and compatibility between terminals and
network.
Radio quality is not good, average SINR is around 6db, no compatibility issue was found.
3. Finish the troubleshooting and call drop root cause clarification.
Check Part 5 Analysis
4. According to the call drop root cause, discuss with customer and finalize the optimization strategy solution.
Check Part 6 solution

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 3-2

Copyright © Huawei Technologies Co., Ltd
 4 Simulation VoLTE Test

Figure 1 Drive test with Porbe and Mate 7

1. Huawei finished VoLTE short call drive test with Probe and Mate 7 in main roads, more than 40 times
call drops happened, SINR average value is around 6db, and SINR is almost below 0db in 25% of test
area as figure 1.
2. Customer finished VoLTE short call drive test with TEMS and iPhone6 in some main roads, also more
than 30 times call drop happened, and RRC connection dropped more than 30 times, check the detailed
information provided by TEMS, it is obvious that all RRC disconnected when SINR is not good as
figure 2.

Figure 2- RRC drop info provided by TEMS

From general analysis, it is suspended that VoLTE call drop caused by bad SINR.

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 4-3

Copyright © Huawei Technologies Co., Ltd
 5 Problem Analysis

IPHONE 6 and Mate7 drive testing at Riyadh city found call drop rate is high, aslo RRC Restablishment fialure
rate is high.

5.1 The call drop root cause classification

UE experience Conclusion
NO. TYPE ISSUES description
description Status

1 Non- eSRVCC VoLTE call drop happened at poor radio environment Call drop Close

3 eSRVCC SRVCC to 3G failure, call drop. Call drop close

5.2 Conclusion about VoLTE call drop

Conclusion about Non-SRVCC

5.2.1.1 Due to Radio environment, RRC disconnect, and call drop.

Case 1:
Probe time (20:43)
Because of radio environment, B1 Event is triggered and UE keep sending B1 MR, then call drop happened and
UE re-access in third-party cell.

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 5-4

Copyright © Huawei Technologies Co., Ltd
Checking from E2E trace, actually eNB already sent inter rat HO command to UE, but UE didn’t receive it due to
radio environment and call drop, then UE try to access in other cells and MME find one UE info on 2 eNB, then
MME normal release the bearer on original site.

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 5-5

Copyright © Huawei Technologies Co., Ltd
Case2:
Probe time(15:27)

Due to bad SINR(-17db), RRC.ReEst was triggered. From terminal log, we can find UE keep sending A3 report,
and the second A3 is intra-eNB（PCI=102）.

But from E2E trace, eNB already sent intra-eNB HO in the second MR, checking from terminal log, terminal did’t
receive this HO command, probably due to bad SINR( because we can see after eNB sending HO command, UE
was still sending MR , no response to eNB command), so eNB didn’t receive HO complete message from UE, and
eNB are still waiting UE response, 2 seconds later, eNB receive the normal release message from MME, so there
is no abnormal release counter in eNB.

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 5-6

Copyright © Huawei Technologies Co., Ltd
 Conclusion about SRVCC
5.2.2.1 SRVCC HO failure
There are 2 kind of situation for SRVCC failure.

TypeA: UE left LTE and already access in UMTS.

Case 1:

1. UE receive HO command from eNB, and eNB receive SRVCC HO successlul mesaage.It means UE
already finished accessing in 3G, but then call drop in 3G.

2. From eNB, eNB received HO success.

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 5-7

Copyright © Huawei Technologies Co., Ltd
 3. Analysis 3G R&D.

SRVCC procesure successed, but the 3G cell Ec/No is too much bad-20dB, which even smaller than minimon
access EcNo threshold, UE report to relocation to GSM.during all these UE activity, some message
(relocation complete message should be send from RNC to CN to ask MME to release UE-Context) missed
which caused SRVCC failure. Current LTE B1 event Utran measurement trigger quantity is setting as RSCP
or BOTH, the parameter ID is InterRatHoUtranB1MeasQuan, considering our testing area is in Riyadh
dense urban area, below snapshot site RIY0287 location for reference, if our measurement based on
RSCP even B1 even triggered by good RSCP target utran cell, but if the Ec/No is not good, SRVCC will be
easily failure due to target cell quality, 3G service relies on Ec/No more than RSCP especially in urban
area. As suggested by Huawei 3G R&D we should change the Utran measurement trigger quantity as
Ec/No to guarantee the SRVCC success rate. parameter description also mentioned below. But we
should pay attention that ehe value BOTH applies only to UEs complying with 3GPP Release 10.
For UEs complying with 3GPP Release 8 or 9, the value BOTH takes the same effect as the value
RSCP, the recommended value for Ec/No is -12(namely -24 in the system).

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 5-8

Copyright © Huawei Technologies Co., Ltd
 MO InterRatHoComm
ParameterID InterRatHoUtranB1MeasQuan

ParameterName Utran measurement trigger quantity

NE BTS3900, BTS3900 LTE

MOD INTERRATHOCOMM
MMLCommand LST INTERRATHOCOMM

GUIValueRange RSCP, ECN0, BOTH

EnumerationNumber/Bit RSCP~0, ECN0~1, BOTH~2

Unit None

ActualValueRange RSCP, ECN0, BOTH

DefaultValue ECN0

RecommendedValue ECN0

Indicates the quantity to be measured for handovers to UTRAN. For

details, see 3GPP TS 36.331. This parameter is dedicated to
UTRAN FDD. The RSCP values are relatively stable, while the
ECN0 values may vary with the network load. The value BOTH
applies only to UEs complying with 3GPP Release 10. For UEs
complying with 3GPP Release 8 or 9, the value BOTH takes the
same effect as the value RSCP. In QoE-based handovers, this
parameter does not apply to UEs complying with 3GPP Release 8
or 9 and the measurement quantity is fixed to ECN0 for such UEs.
Meaning
If this parameter is set to RSCP, the eNodeB delivers RSCP-based
UTRAN measurement configurations to UEs. If this parameter is set
to ECN0, the eNodeB delivers ECN0-based UTRAN measurement
configurations to UEs. If this parameter is set to BOTH, the eNodeB
delivers both RSCP- and ECN0-based UTRAN measurement
configurations to UEs complying with 3GPP Release 10.

TypeB: UE left LTE , but not finished access procedure in UMTS.

Case 1.

1. UE triggered SRVCC and UE received MobilityFromEutrancommand, then UE try to aceess in 3G but

failed to synchronization and access in 3G , then come back to LTE, because of re-access in other cell,
and RRCreestbalishmentrejection happen due to no UE context issue and then service request.

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 5-9

Copyright © Huawei Technologies Co., Ltd
 2. From eNB， eBN didn’t receive HO successful message drom MME, it means UE fail to access in 3G,
and then come back to LTE, this time UE info existed in 2 eNB and MME sent Normal release to original
cell.

3. Analysis from 3G R&D.

Standard signaling flow for CS&PS SRVCC mentioned as below,

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 5-10

Copyright © Huawei Technologies Co., Ltd
 In our case 3G RNC after sending Relocation-request-acknowledge information didn’t receive the
Handover to UTRAN Complete information which should be send by UE.

After 7-8 seconds no response from RNC, 3G CN required to release Iu resources, at almost the same
time for 4G MME initialed the UE-Context-Release-Command to E-NodeB,SRVCC failure.
Our most SRVCC failure belongs to this case, what’s the root reason, why? Both 3G&4G quality is
bad,3G RTWP-73dBm,4G measured RSRQ-17dB.

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 5-11

Copyright © Huawei Technologies Co., Ltd
5.3 Conclusion about RRC.ReEst.Succ Rate
How will RRC.ReEst Failure affect VoLTE call drop
For the most of cases we met, RRC disconnected due to bad SINR, then UE started RRC Reestablishenment in
other eNodeB, if RRC link recovers through Reestablishenment, UE can continue VoLTE call. If RRC
Reestablishenment failed, E-RAB bearer will be released and VoLTE call drop occurs.

The reason for RRC.ReEst Failure

RRC.ReEst is used to recover RRC link rapidly, but only when UE context exists on eNB, RRC.ReEst will be
successful. RRC.ReEst Request message contains CRNTI, MAC-I information, eNB will search UE context
according to CRNTI and MAC-I, if eNB can find it, RRC.ReEst will be successful, if not, it will fail.

Scenario A: UE attempt RRC Reestablishenment in Source eNB, if UE context still exists in eNB, RRC
Reestablishenment will succeed, or it will fail.

Scenario B: UE attempt RRC Reestablishenment in other eNB. firstly, UE camp on the eNB A, due to bad
SINR, UE RRC disconnected in eNB A, then UE attempt RRC Reestablishment in eNB B, if eNB B has UE
context, RRC Reestablishment will succeed. However, if UE never accesses in eNB B before, so there is no
UE context in eNB B, for this occasion, algorithm called RRC-Reestablishment without UE context will work.
eNB B will attempt to get UE context from eNB A through X2 interface. If UE context still existed in eNB A,
if UE context still exists in eNB, RRC Reestablishenment will succeed, or it will fail.

The Reason for No UE Context in eNB

Choose one Top sites eNodBID 217464 with low RRC Reestablishenment Success Rate issue to analyze in
further.
Accoding to analysis in further, the context does not get by target eNodeB if there is no X2 link or X2 link
abnormal, and there are two main reasons lead to reestablishment success rate low:

1. No X2 Link lead to Reestablishment Success Rate Low

2. Transmission Abnormal Lead to Reestablishment Success Rate Low

SR5256404 Root
Cause Analysis for Reestablishment Success Rate Low in Zain of Saudi Arabia.docx

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 5-12

Copyright © Huawei Technologies Co., Ltd
 6 Optimization Stategy

6.1 RF optimization
After proceeding with the below optimization strategy, dial 100 times VoLTE call, only 1-2 call drop occurred
in the VoLTE simulation drive test conducted by operator.

Call Drop on LTE

Some LTE call drop cases were found under heavy load and bad SINR during test, even sometime RSRP is good,
which will lead to UE can’t receive Handover command from UE or eNodeB can’t receive UE MR, and as we
know, average PRB utilization ratio for Riyadh network is more than 60%, RF optimization, Carrier Aggregation
and building more eNB is recommended to reduce load of network and increasing the SINR.
For SRVCC L2U call drop, we found sometimes RTWP is not good, sometimes ECNO is not good, even when
UE Handover to 3G, we find ECNO is not good and handover between UMTS and GSM is triggered soon. For
this kind of cases, we suggest to change B1 trigger from RSCP to ECNO to trigger SRVCC, so when Handover to
3G, UE can proceed service under a better radio environment.

Low RRC Reestablishment Success Rate

Checking from all eNBs in Riyadh, many X2 Interfaces Fault and SCTP Link Faults were found, so these
alarm influenced RRC Reestablishment Success rate greatly. We suggested customer to clear all the X2 and
SCTP alarm for all eNBs in Riyadh. After clearance, more than 2000 alrams were cleared.

Check the X2 Handover, S1 Handover and RRC.ReEst.Succ Rate for Riyadh eNodeB. Below it the statistic
analysis graph, it shows the amount of X2 Handover increases, the amount of S1 Handover decrease, at the
same time, RRC.ReEst.Succ Rate increase obviously since 10/31/2015(data of 11/04/2015 was extracted not
for the whole day ), RRC.ReEst.Succ is more than 90%. Then we arrange the VoLTE drive test and call drop
occurred no more than 10. So if the network SINR is very bad, the short-term and efficient way to solve
VoLTE call drop issues is to confirm there is no X2 and SCTP alarms, which will greatly promote solving
VoLTE call drop.

25000000 85.00%

20000000 79.64%80.00%
78.58%
15000000 75.71% 75.00%
72.56%
10000000 70.83% 70.00%
69.06% 68.33% 69.48%
5000000 65.00%

0 60.00%
10/28/2015 10/29/2015 10/30/2015 10/31/2015 11/01/2015 11/02/2015 11/03/2015 11/04/2015
00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00

S1 HO X2 HO HO total RRC.ReEstSR

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 6-13

Copyright © Huawei Technologies Co., Ltd
 Parameter Optimization
While we do the RF optimization, we can also adjust some performance parameter for VoLTE service to
enhance the performance of the network. Below is the suggestion from R&D, it is recommended to have a
trial before implement for all sites.

VoLTE
optimization parameter.xlsx

7 Other

7.1 Call Drop Counter Issue

Why Apple feedback there are 13 times VoLTE call drop, there is only once QCI.1 Abnormal Release was
captured by the eNB counter?
Due to PS signaling processing procedure, if cross procedure occurred during call drop, MME will send
ERAB normal release to eNB, and eNB will counter it as normal release, which actually is the VoLTE call
drop from UE perception. Already feedback to PS Product Design Dept., some cross signaling scenario which
leads to no call drop counters will be solved in PS software version 13.0, for complete solving counter issues,
it will be considered in more advanced PS software version.

7.2 Optimization case

Problem causes：Problem points are too bad for 4G and 3G signals，4G can't SRVCC to 3G ,resulting in dropped ;

Solution：Change Utran B1 threshold for original LTE cell to let UE SRVCC to 2G cell, because the 2G signal is
very good in the problem area;

Re test results：Problem area 4G cell SRVCC to 2G cell, then no call drop.

4G SINR：

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 7-14

Copyright © Huawei Technologies Co., Ltd
3G EcNo

2G RxQual:

Issue 01 (2010-07-02) Huawei Proprietary and Confidential 7-15

Copyright © Huawei Technologies Co., Ltd