Analysis Report of RRC connection release afte

r successful re-establishment

HUAWEI TECHNOLOGIES CO., LTD.

Issue Description
Test Date ： Around 13:00 - 14:00 2018-04-22
Issue Description ： RRC connection was released after successful re-establishment during the drive test and eventually
resulting in a drop call
The DT tool shows below information:

HUAWEI TECHNOLOGIES
HISILICON CO., LTD.
SEMICONDUCTOR Page 2
Issue Description
From the UU trace:
1. UE reestablish to eNB ， and eNB receive RRC_CONNECTION_REESTABLISHMENT_COMPLETE
2. eNB send release command, the reason for the release is “Radio Resource not available”.

HUAWEI TECHNOLOGIES
HISILICON CO., LTD.
SEMICONDUCTOR Page 3
Analysis
 CHR analysis ：
1. From the the CHR log, timings for the current call drop, trace and problem scenes are consistent
2. The log shows the reason that PDCP was in the ready state when the reestablishment was completed
3. Problem happened because MAC L2 didn’t send the PDCP SN information to RRC L3 and consequently eNODE released the radio
connection
 CHR only records the scenario when the problem occurs, but there is no schedule information for the user when the problem
occurs （ User CELLDT trace)

HUAWEI TECHNOLOGIES
HISILICON CO., LTD.
SEMICONDUCTOR Page 4
Process Analysis
Process flow is as below:

 All RRC Re-establishment procedures will trigger the PDCP SN transfer process

 When re-establishment process is triggered, RRC L3 module sends the PDCP SN request to L2 and proceeds with the Re-
establishment request. After completing the Re-establishment process, L3 tries to fetch the SN number from L2 for the earlier made
request but if it finds that the SN number MSG is not received. Consequently eNODEB releases the radio connection for the UE

 CHR doesn’t record the MSG transfer process, And to analyze the MSG transfer, CELLDT Trace is required

 CELLDT trace was recorded for top sites for multiple days. Abnormal scenario happened with probability 0.0015%

 Analysis for abnormal scenario is shown in the coming slides

HUAWEI TECHNOLOGIES
HISILICON CO., LTD.
SEMICONDUCTOR Page 5
 Detailed Problem Analysis
 From CELLDT trace at the abnormal scenario time, it is identified
that L3 and L2 message transfer is successful but there is delay
in L3 receiving the response from L2
 In step 1, L3 module sends MSG to L2 module. Upon receiving
the MSG request, L2 responds immediately
 In step 2, L2 sends the MSG response to L3
 So, CELLDT shows that function of L2 module, L3 module and
message transfer module is normal but with some delay
 There is delay between baseband board and UMPT in the
message transfer process. Further investigation shows that the
high CPU load led to message transfer delay between L2 and L3
 Similar scenario is tested in HQ laboratory as well and the
scenario was captured few times in tedious testing. At the time of
scenario happening, CPU load was high
 However, even at high CPU load the probability of this scenario
happening is low

HUAWEI TECHNOLOGIES
HISILICON CO., LTD.
SEMICONDUCTOR Page 6
MSG transfer Analysis
From the BRD log, In transmission between UMPT and BBP, there is no message loss:
1. L2 MSG is in PDCP side, L3 MSG is in TRAN side
2. IPC and IWARE are transmission components
3. After tracing message transfer on each node, no message lost is found on any of the four nodes 1/2/3/4

HUAWEI TECHNOLOGIES
HISILICON CO., LTD.
SEMICONDUCTOR Page 7
Comparison with Normal Flow
 The signaling flow in normal reestablishment and abnormal reestablishment is same and is mentioned below:
1. Handover to CELL 2
2. reconfigure the CA SCELL
3. reestablish to CELL 4

 Its is confirmed from the UU trace that under the same flow, the UE reestablishes successfully in both abnormal and normal
scenarios . In the case of the same flow, eNB do the same processing function, so there is no abnormality on eNODEB side.
However in abnormal scene, the difference is high CPU load

Abnormal Scenario: Normal Scenario:

HUAWEI TECHNOLOGIES
HISILICON CO., LTD.
SEMICONDUCTOR Page 8
Conclusion and Way Forward
 When CPU load was high, few calls were abnormally released due to internal message transfer delay between L2 and L3

 The problem scenario is very rare to trigger (probability of 0.0015% on top site) and the probability of the scenario happening is low even in
high CPU load

 As the problem occurs during re-establishment attempt and high CPU load, it is suggested to maintain CPU load within limit and the
number of RRC re-establishment attempts should be optimized

 Below are few parameter suggestions to optimize RRC re-establishment attempts:

Parameter Value Recommend impact

DediDciPwrOffset When PaPcOff =0,
DediDciPwrOffset=-30;
When PaPcOff =1,
DediDciPwrOffset=-30
PdcchMaxCodeRate 90
TimingResOptSwitch OFF
RrcConnRelMaxRetxTh 10
d
SriPeriodAdaptive QCIADAPTIVE
If PaPcOff =0, leads to a larger coverage
DediDciPwrOffset=0; of the PDCCH UE specific
If PaPcOff =1, search space
DediDciPwrOffset=10;
75 PDCCH aggregation level
will be higher
ON Unnecessary TA Commands
to be delivered decreases
32 Better for reestablishment
NOQCIADAPTIVE Better for reestablishment
in call drop scenes

HUAWEI TECHNOLOGIES
HISILICON CO., LTD.
SEMICONDUCTOR Page 9
 Thank you
www.huawei.com

Copyright©2010 Huawei Technologies Co., Ltd. All Rights Reserved.