VOLTE Call Drop Analysis And Investigation

11/05/2016

HUAWEI TECHNOLOGIES CO., LTD.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. HUAWEI Confidential Page 1
Conclusion
 Investigation Phase
First phase:
1:For live network the VOLTE call drop rate is higher than acceptance. We traced in top 6 sites on 22-Apr and found 13 VOLTE Call Drop and
all caused by the same scene: MME send QCI1 ERAB Release message to eNodeB 300ms later after eNodeB send
RRC_MOBIL_FROM_EUTRA_CMD to UE in the SRVCC procedure and didn’t send the S1AP_UE_CONTEXT_REL_CMD (successful-
handover). This caused eNodeB releasing the UE CONTEXT 20s later and record as it a VOLTE Call Drop.
Second phase:
1.On 29-Apr we reproduced the E-RAB drop issue plus with SRVCC failure in Operator V office. Test result showed all VOLTE MO to NON-
VOLTE terminal calls will fail as VOLTE MO trigger SRVCC in alerting stage. As VOLTE MO will active dedicated EPS bearer before 180
ringing, if SRVCC procedure begin immediately after EPS bearer, MME will send normal release to ENB and VOLTE call MO will drop.
2.VOLTE to VOLTE call and NON-VOLTE terminal to VOLTE MT calls are fine as EPS bearer will be actived after alerting.
Third phase:
1: On 3-May we retest the SRVCC for get the E2E trace of probe log, LTE eNB log, LTE MME, LTE IMS and 3G trace log files. After
combination analysis, the root cause of this issue is inferred to be SRVCC-IWF entity(3G CN equipment) not support SRVCC-alerting. As
SRVCC-IWF is not HUAWEI equipment, so suggest Operator V related team to check and feedback this.
2: On LTE eNB side, we have provided SRVCC parameter optimization suggestions to decrease the VOIP call drop rate. And it show good
result. whole network VOLTE call drop decrease from 0.9% to 0.3% already.

 Result Summary
1: after discussion, Operator V optimization team agreed and implemented the SRVCC parameter optimization suggestions for L2U A2 to
decrease the probability of SRVCC triggered in alerting phase. For live network, the average call drop rate have decreased obviously.
2: For SRVCC in alerting phase, need SRVCC-IWF(3G CN) to support, suggest to check its function of SRVCC alerting and improvement
network performance. Customer has feedback IWF didn't support SRVCC-Alerting indeed and plan to update it in Q3 of 2016.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 2
HUAWEI Confidential Page 2
 First phase: KPI Analysis---VOLTE User and Call Drop Rate

1. VOLTE users number raised gradually from 12-Apr, highly related to Samsung xx and xx Edge terminal VOLTE software update beginning on 12-Apr.
2. Call drop rate for VOLTE came to higher since 12-Apr, synchronized with the VOLTE users raise. And the drop times for VOLTE increase almost 1800
comparing 15-Apr to 12-Apr.(16-Apr to 18-Apr network issue, VOLTE for QCI1 has been suspended so KPI seems like strange for DRB.QCI1)

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 3
HUAWEI Confidential Page 3
 First phase: KPI Analysis---VOLTE Call Drop Reason

1. VOLTE call drop rate raised from 12-Apr, and normal PS call drop rate is stable and normal from 12-Apr to 15-Apr.
(MME has issue from16-Apr.)
2. VOLTE call drop mainly caused by handover failure, around 1600 times.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 4
HUAWEI Confidential Page 4
First phase: KPI Analysis---Handover Analysis

1. SRVCC failure times also increased around 1600

times comparing 12-Apr to 15-Apr, and the E2W
SRVCC success rate degraded from 12-Apr visibly.
2. LTE intra-frequency and inter-frequency handover
success rate has no degradation from 12-Apr to 15-
Apr (16-Apr changed as CN issue), so VOLTE call drop
most are caused by SRVCC E2W failure.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 5
HUAWEI Confidential Page 5
 First phase: KPI Analysis---Top Cell Analysis

We list the TOP high 50 cells of VOLTE call drop and found there is no TOP cell. The top1 cell only has 26 call drops in one week and the Call
drop times are still high after removing the TOP 50 cells.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 6
HUAWEI Confidential Page 6
 First phase: Trace Analysis---Abnormal Message from MME

Call Drop Procedure

Normal Procedure
In the Call drop procedure, eNodeB has send RRC_MOBIL_FROM_EUTRA_CMD to UE successfully, however MME inform eNodeB to release
QCI1 ERAB 300ms later and eNodeB treat it is not a normal procedure then send S1AP_ERAB_REL_RSP message to MME. The
S1AP_ERAB_REL_RSP message with the reason: S1-inter-system-handover-triggered shows that it is in the handover progress currently and
MME shouldn’t send the ERAB Release message. However, eNodeB didn’t receive the S1AP_UE_CONTEXT_REL_CMD (successful-handover)
from MME and released the UE CONTEXT 20s later and record as a VOLTE Call Drop.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 7
HUAWEI Confidential Page 7
Second phase: Alerting Analysis– VOLTE TO VOLTE
As most of the VOLTE increased drops are corresponding with L2U SRVCC failure times. So we test for 3 types of call scennario for VOLTE
call: VOLTE to VOLTE, VOLTE to NON- VOLTE terminal , and NON- VOLTE terminal to VOLTE.
For these 3 types, we tested with SRVCC triggered(change xx sites SRVCC threshold) and without SRVCC triggered. And found that:
In NON- VOLTE terminal to VOLTE with SRVCC triggered scenario, as the EPS deditcated bearer will be actived before 180 ringing, so VOLTE
call will fail. First we can check the VOLTE to VOLTE signaling, EPS bearer(Time:16:14:12.801) will be activated after 180
ringing(Time:16:14:05.190). VOLTE call is successful.

QCI1 dedicated bearer activated

Dedicated EPS Bearer Acitivated

SIP message 180 ringing

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 8
HUAWEI Confidential Page 8
 Second phase: Alerting Analysis– NON- VOLTE terminal TO VOLTE

VOLTE phone as the target terminal

Dedicated EPS Bearer Acitivated

SIP message 180 ringing

Second, we test the NON- VOLTE terminal to VOLTE scenario. As the signaling showed:
EPS dedicated bearer will be activated(time 16:16:32.802) after 180 ringing(time 16:16:20.700). And VOLTE MT call is successful.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 9
HUAWEI Confidential Page 9
Second phase: Alerting Analysis– VOLTE MO to NON- VOLTE terminal (1)

VOLTE MO identification

Dedicated EPS Bearer Acitivated

SIP message 180 ringing

And for the third part as above, this is a VOLTE to NON- VOLTE terminal call setup proecdure.
We can check from the L3 signaling and SIP message that: in this type of call scenario, dedicated EPS bearer will be activated(Time
16:15:31:802) before SIP message 180 ringing(Time 16:15:32:144). For no SRVCC condition, VOLTE call is ok.
For SRVCC triggered screnario, the VOLTE MO will fail as next page showed, which have tested and confirmed.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 10
HUAWEI Confidential Page 10
Second phase: Alerting Analysis– VOLTE MO to NON- VOLTE terminal (2)
Aftered changed the SRVCC threshold for L2U.
From the air interface trace, can check that it is the same failure behaviour as we got from the live network top cells: after eNB send the
SRVCC command to UE, immediately MME send normal release to ENB(around 300 ms). So the VOLTE call will fail.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 11
HUAWEI Confidential Page 11
Third phase: E2E Combination Analysis For SRVCC-Alerting(1)
For the E2E trace and log file analysis, first we test the cases as following. For VOLTE to VOLTE call and NON-VOLTE to VOLTE call, as the
EPS bearer will be activated after connected, so SRVCC will not be triggered in alerting phase, all success.
And for VOLTE to NON-VOLTE call, because EPS bearer will be activated before 180 ringing, so SRVCC can be triggered in alerting phase if
the LTE signal satisfied the A2 threshold.

SRVCC Not SRVCC- SRVCC after

TC# Test Case MOC MTC
Trigger alerting(L2U) connected(L2U)
TC1 VOLTE2VOLTE VOLTE VOLTE OK N.A. OK

TC2 VOLTE2CSFB VOLTE CSFB OK Fail OK

TC3 VOLTE2UMTS VOLTE UMTS OK Fail OK

TC4 CSFB2VOLTE CSFB VOLTE OK N.A. OK

TC5 UMTS2VOLTE UMTS VOLTE OK N.A. OK

When SRVCC triggered in alerting phase. This is actually for one function which is called as SRVCC-alerting for indicating support SRVCC
in alerting phase or not.
From the test case result, it is clearly that only the SRVCC-alerting will fail, if SRVCC happened after connected, then the VOLTE call will be
handover to 3G and continue the conversation successfully.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 12
HUAWEI Confidential Page 12
Third phase: E2E Combination Analysis For SRVCC-Alerting(2)
As below picture, this is a typical network structure of HUAWEI for SRVCC structure(Comments: for live network except SE2900(SBC/P-
CSCF/ATCF/ATGW) and S/I CSCF, the others equipment belong to other venders). SCC AS will make the judgement for IMS support
SRVCC-alerting or not in the call procedure. And the detailsis as following :

The SCC AS identifies a session to be handed over by the Dialog ID in the Target-Dialog header
field and performs the following operation: Determines whether alerting call handovers are
supported in the session.
Alerting call handovers are supported if the following conditions are met:

1: The initial INVITE message and the 183 message carry +g.3gpp.srvcc-alerting.

2:The Contact header field in the INVITE message sent by the SRVCC IWF carries +g.3gpp.srvcc-
alerting, and the Accept and Recv-Info header fields carry state-and-event-info.

If alerting call handovers are not supported, the SCC AS sends a 480 message to reject the
handover request.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 13
HUAWEI Confidential Page 13
Third phase: E2E Combination Analysis For SRVCC-Alerting(3)
For the live network of operator V, IMS main equipment architecture is as below: A-SBC and S/I CSCF belong to Huawei. And the rest are
from others vendors. Check the IMS SIP message trace log, we can find in the SRVCC IWF SRVCC request message, there is no
+g.3gpp.srvcc-alerting information. So that can be inferred as SRVCC-IWF not support SRVCC-alerting function( IWF and SCC AS not
belong to Huawei). And SCC AS sends 480 temporarily unavailable to reject this SRVCC request, and also sends 500 server internal error
to inform LTE EPC part.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 14
HUAWEI Confidential Page 14
Third phase: E2E Combination Analysis For SRVCC-Alerting(4)
LTE side probe and S1/UU trace analysis: for the VOLTE to NON-VOLTE call which triggered SRVCC-alerting, we can see as below that
after the SRVCC command message of A1AP_HANDOVER_CMD sent from MME to eNB, MME will send ERAB release message of
SIAP_ERAB_REL_CMD very soon(around 300ms) to eNB. This can be matched to the IMS part SIP message 500 server internal error
which send to MME.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 15
HUAWEI Confidential Page 15
Third phase: E2E Combination Analysis For SRVCC-Alerting(5)
3G side trace log analysis : And for 3G side, compared the probe log and trace. We can find when RNC send
RANAP_RELOCATION_COPLETE to 3G CN, CN will immediately send RANAP_IU_RELEASE_COMMND to reject the SRVCC-alerting
procedure. This is also matched to the IMS part 480 temporarily unavailable which send to 3G CN.

Summary: after check the E2E trace and log file, we can inform the SRVCC-alerting failure root cause is as SRVCC-IWF support issue. As it
is not Huawei’s equipment, so suggest operator V team help to check the related function configuration. Customer has feedback IWF
didn't support SRVCC-Alerting indeed and plan to update it in Q3 of 2016.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 16
HUAWEI Confidential Page 16
Work Ground And Suggestion
1: Work ground: operator V optimization team agreed and implemented the SRVCC parameter optimization suggestion for L2U A2 to
decrease the probability of SRVCC triggered in alerting phase as following. Check from the latest live network performance, the SRVCC
and VOLTE call drop KPI improve visible and ongoing monitoring, whole network VOLTE call drop decrease from 0.9% to 0.3% already.

MML Command Parameter ID Parameter Name Original Value Optimization Value

InterRatHoCommGroupId InterRAT handover common group ID 1 1

MOD INTERRATHOCOMMGROUP
-115 for L8/18/26 -118 for L8/18/26
InterRatHoA2ThdRsrp InterRAT A2 RSRP trigger threshold
-106 for L900, 5M -112 for L900, 5M

MOD CNOPERATORHOCFG UtranA2ThdRsrpOffset UTRAN A2 Threshold RSRP Offset 0 0

GeranA2ThdRsrpOffset GERAN A2 Threshold RSRP Offset -2 -2

2: As SRVCC-IWF not belongs to Huawei, and the SCC AS(make the judgment for SRVCC-alerting support or not ) is from other vendors
also; we suggest operator V customer to check the IWF entity function to confirm the root cause, after activated the SRVCC-alerting
function the LTE performance should be improved to better. Customer has feedback IWF didn't support SRVCC-Alerting indeed and plan
to update it in Q3 of 2016.

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. Page 17
HUAWEI Confidential Page 17
 Thank You
Thank You
www.huawei.com
www.huawei.com

HISILICONTECHNOLOGIES
HUAWEI SEMICONDUCTOR
CO., LTD. HUAWEI Confidential Page 18