13 LTE Call Drop Diagnosis

LTE Call Drop
Diagnosis
www.huawei.com
Copyright © 2013 Huawei Technologies Co., Ltd. All rights reserved.

Objective
 After completion of this class, you will be able to:
 Describe the definition of call drop
 Analyze the symptoms and causes of various types of call drop
 Describe the handling methods for various types of call drop
Copyright © 2013 Huawei Technologies Co., Ltd. All rights reserved. Page1
Contents
1. Definition and classification of call drop
2. Analysis of causes of call drop
3. Handling of call drop problems
Definition and Classification of Call Drop
 A call drop is an eRAB release due to abnormal cause(s)
after the eRAB between UE and eNB is successfully
established.
 In different scenarios call drops can be of different definition

and appearance. We herein focus on the UE side statistics
and the network side statistics.
 At UE side, call drops rely on DT tools’ statistics.
 At network side, call drops rely on performance KPI statistics.

Network side call
UE side call drops
drops
UE Side Call Drop Rate Formula
 Based on the DT test results, UE side call drop rate is
defined as:
 Call drop rate = eRAB AbnormRel / eRAB Setup Success
*100%
 eRAB AbnormRel： Number of abnormal releases of activated E-
RABs
 eRAB Setup Success： Number of successfully set up E-RABs
UE Side Call Drop Rate Formula (cont.)
 Huawei DT tools (Probe & Assistant) define eRAB
AbnormRel (eRAB abnormal release) as the following
scenarios:
 1. UE has not received NAS message “DEACTIVATE EPS
BEARER CONTEXT REQUEST” from MME, and UE has
neither initiated NAS message “DETACH REQUEST” to
network, but eNodeB has received the downwards delivered
“RRC Connection Reconfiguration” message. Thus number of
eRAB abnormal release is counted.
 2. UE has neither received NAS message “DEACTIVATE EPS
BEARER CONTEXT REQUEST”, nor has it initiated NAS
message “DETACH REQUEST” to network side, but it received
“RRC Connection Release” message delivered from eNodeB,
and meanwhile if in the preceding 4 seconds there were RLC
layer data transmitting (either uplink or downlink), eRAB
abnormal release is counted.
 3. UE has setup eRAB, and before receiving “RRC Connection

Release” message RRC becomes Idle state, thus eRAB
 4. UE has not received messages such as “RRC Connection
Reconfiguration”, “DEACTIVATE EPS BEARER CONTEXT
REQUEST”, “RRC Connection Release”, etc. and it has neither
sent “DETACH REQUEST”, and nor has the RRC state
transited, but UE initiates RRC request, in such case eRAB
 5. When RRC connection reestablishment fails eRAB abnormal

release is counted.
Call Drop Appearance in DT Test
 In DT test using PROBE and Huawei test UE (or other DT tool and
test UE) and throughput monitoring software, if call drop occurs
we may see the below information:
 In the monitoring window the throughput suddenly drops to 0.
DL throughput UL throughput
It implies a call drop that the throughput UL and DL suddenly drops to 0.
Call Drop Appearance in DT Test (cont.)
 It implies a call drop when UE is in a normal service process
and suddenly System Information is received.
 Usually UE reads System Information during detach, inactivity
timer release and reestablishment. If a normal service is going on
and does not involve these scenarios, a call drop may be
conclude.
Signaling Appearance of Call Drop on
Standard Interface
 Call drop usually indicates that eNodeB initiates release and
informs MME to release the context.
 In DT test if the cause value contained in message
S1AP_UE_CONTEXT_REL_REQ sent from eNodeB to
MME over S1 interface is not “User-inactivity”, call drop may
be concluded.
When eNodeB detects that there is no data interchange with UE

in a certain time, it will initiate release request to MME, and the
cause value is “user inactivity”. This case is not a call drop.
Network Side Call Drop Formula
 At the network side call drop index can be monitored
through KPI.
 Network side KPI call drop rate is defined as below:

 Call drop rate = L.E-RAB.AbnormRel / ( L.E-RAB.NormRel +
L.E-RAB.AbnormRel )*100%
 L.E-RAB.AbnormRel: Total number of abnormal releases of user’s
eRAB in the cell
 L.E-RAB.NormRel: Total number of releases of user’s eRAB in the

cell
Counter L.E-RAB.AbnormRel
Measurement
 Two scenarios of L.E-RAB.AbnormRel measurement
Scenario 1 Scenario 2
E-RAB RELEASE INDICATION UE CONTEXT RELEASE REQUEST

indicates a release of an E-RAB requests to release UE context
all E-RABs will be released
Other Related Indicator: Abnormal
Releases with Different QCIs
Except for the total E-RAB abnormal release counter and
normal release counter, there are also abnormal release
counters sorted by QCIs.
Counter Name Counter Description

L.E-RAB.AbnormRel.QCI.1 abnormal releases of E-RABs with QCI 1 in a cell
E-RAB abnormal release counters with different QCI
Other Related Indicator: Normal
Releases with Different QCIs
 E-RAB normal release counter measured according to QCIs
Counter Name Description

L.E-RAB.NormRel.QCI.1 normal releases of E-RABs with QCI 1 in a cell
Other Related Indicator: Abnormal E-
RAB Releases for Outgoing HOs
 Checking the counters for abnormal releases and normal
releases of outgoing handovers can help to find call drops
caused by handovers.
L.E-RAB.AbnormRel.HOOut.QCI.1 abnormal E-RAB releases for outgoing HOs with QCI 1 in a cell
L.E-RAB.AbnormRel.HOOut total abnormal E-RAB releases for outgoing HOs
Other Related Indicator: Normal E-
RAB Releases for Outgoing HOs
L.E-RAB.NormRel.HOOut.QCI.1 normal E-RAB releases for outgoing HOs with QCI 1 in a cell
L.E-RAB.NormRel.HOOut total normal E-RAB releases for outgoing HOs
Counters for Abnormal E-RAB
Releases for Different Causes
 Checking counters for abnormal E-RAB releases for
different causes can help to find the cause of call drops.
abnormal releases of E-RABs because of
L.E-RAB.AbnormRel.Radio
faults at the radio network layer
L.E-RAB.AbnormRel.TNL
faults at the transport layer
L.E-RAB.AbnormRel.Cong
network congestion
L.E-RAB.AbnormRel.HOFailure
handover failures
E-RAB RELEASE INDICATION
(UE CONTEXT RELEASE REQUEST)
eNodeB MME
Counters for various abnormal release causes count

according to the cause value of release in the message
Contents
Common Call Drop Causes
 Common causes of call drops:
Missing Weak
neighbor coverage
Signaling
Interference interchange
failure
Handover Other
problem causes
Missing Neighbor
 Usually at the initial optimization stage of network
construction the majority of call drops are caused by
missing neighbors.
 For intra-frequency neighbors in LTE network, the following
methods may be adopted to confirm whether it is due to
missing intra-frequency neighbor:
 Method 1: check the DT data, if the UE re-accesses
immediately after the drop, and the PCI of re-access is different
from that when the call dropped, missing neighbor or
misconfiguration of neighbor is suspicious. This can be further
confirmed by measurement control. (Check the messages
before the call drop and find the nearest intra-frequency
measurement control and check the neighbor list in it.)
This method is applicable when ANR is not enabled
Missing Neighbor (cont.)
 Method 2: watch the signaling at the network side. If the
eNodeB does not process after receiving the UE’s MR, and at
the same time there is no HANDOVER_REQUEST on X2
interface sending to the target cell (X2 link configured), or there
is no HANDOVER_REQUIRED on S1 interface sending to
MME (X2 not configured, S1 used), missing neighbor is
suspicious. (This method is only applicable to inter-eNodeB HO,
because there is no X2 interface with intra-eNodeB HO.)
 Method 3: Check the data configuration of the eNodeB,

comparing with the engineering parameters and see if missing
neighbor could be found.
Miss Neighbor: Missing inter-
frequency and inter-RAT Neighbor
 The method of confirming missing inter-frequency neighbor
is almost the same to that of intra-frequency. The difference
is that when call drop occurs the UE has not measured or
reported inter-frequency neighbor, and after the drop the UE
camps in the inter-frequency neighbor cell.
 Missing inter-RAT neighbor appears the way that the UE
dropped from LTE network and after the drop the UE
reselects and camps in an inter-RAT network, and the
signal quality of the inter-RAT network is good.
Another method to locate missing neighbor problem is to use the
UE’s scanner function and watch if there is a stronger cell which
is not in the neighbor list.
Poor Coverage
 Poor coverage appears as low RSRP. Scanner can be used
to detect the downlink RSRP. The typical RSRP is shown
below (only for reference):
 Good: RSRP >= -90dBm
 Normal: -110dBm <= RSRP <= -90dBm
 Bad: RSRP < -110dBm
Interference
 Interference usually appears with high signal strength and
low quality simultaneously.
 e.g. in the downlink, when RSRP of the serving cell is higher
than -90dBm and the SINR is lower than 6dB, basically the
conclusion can be that there is downlink interference.
 When the neighbor cell is missed, mis-configured or HO is not

triggered in time, it also may appear that the RSRP of the
serving cell is good but the SINR is poor.
Call Drop during HO
 Based on triggering time HO problem can be sorted in 3
types: Premature HO, Delayed HO and Ping-pong HO.
 Premature HO: due to the introduction of RRC reestablishment
usually when Premature HO occurs the UE may reestablish
with the source cell so that call drop will not occur.
 In Premature HO if it fails the UE may initiate RRC
reestablishment with the source cell. Because the source cell
remains the UE’s context the reestablishment may succeed and
the service can continue.
Call Drop during HO (cont.): Delayed
HO
 In terms of signal changing trend Delayed HO mainly
appears with the below phenomena:
 Corner effect: RSRP/SINR of the source cell decreases sharply
meanwhile that of the target cell increase sharply (a sudden
appearance in the neighbor list with very high level).
 Needle-tip effect: RSRP/SINR of the source cell decreases for
a while and then increases or that of the target cell sharply
increases for a short moment and then decreases sharply (i.e.
a signal groove appears in the serving cell or a spike appears
in the target cell).
 When delayed HO occurs, it can easily happen that the
target cell does not have the UE’s context, thus RRC
reestablishment will fail and this will lead to a call drop.
Call Drop during HO (cont.): Ping-
pong HO
 In terms of signal changing trend, Ping-pong HO has the
below characteristics :
 The serving cell is changed fast: one of 2 or more cells
becomes the serving cell alternately. The dominant serving
cell has good RSRP and SINR and each cell lasts a short time
as the dominant cell.
 There is no best cell: multiple cells with similar normal RSRP,

and every cell’s SINR is poor.
Conventional Methods to Resolve Call
Drops
 To resolve call drops due to delayed HO, usually the below
methods can be taken. The basic goal of them is to make
the HO occur earlier.
 Adjust the position of antenna(s)
 Modify HO parameter(s)
A3 event offset
 Configure the Cell Offset
A3 Trigger: Mn + Ofn + Ocn – Hys > Ms + Ofs + Ocs + Off
Offset of neighbor cell Offset of serving cell
Conventional Method to Resolve Call
Drops (cont.)
 For call drops due to ping-pong HO, the main method is to
adjust the position of antenna(s) so that in the area there
can be a stable best cell.
 For inter-frequency and inter-RAT HO, it needs to start GAP
to do the inter-frequency or inter-RAT measurement, so
parameter A2 should be properly configured to avoid
starting the GAP too late that may lead to a call drop
because of insufficient time for the UE to measure the
target. The target cell’s threshold should also be configured
properly.
A2 event trigger: Ms + Hys < Thresh
•A2 event is the trigger of inter-frequency and inter-RAT HO
measurement
Call Drops Due to Other Faults
 If there are hardware or transmission problems, call drops
may also occur.
 Transmission problem (S1/X2 reset, intermittent disconnection,
etc.)
 eNodeB fault (board reset, RF tunnel fault, etc.)
 UE fault (Model or software version)
 For hardware or transmission problems, we may do further

analysis via the log file or alarm information and so on.
Contents
Basic Procedure for Call Drop KPI
Analysis
 When the call drop KPI is poor, firstly the scope of the
problem should be comfirmed. We need to find if it is a call
drop KPI deterioration of the entire network or of some Top
cells
 When the scope of the problem is confirmed, we may find

the cause of the call drops
Confirm the Find the

scope of call cause of the
drop problem call drops
Analysis of the Entire Network
 Analyze the call drop KPI of a period of time (e.g. 1 – 2
weeks), if the KPI is high for the entire network, it may be
caused by the following factors:
 A significant adjustment was applied to the network, e.g. cut
over, swap, etc.
 Core network side version change or parameter modification.
 eRAN side parameter modification, e.g. some timer change or

algorithm switch adjustment.
 eNodeB software upgrade or patch
 A sudden increase of traffic leading to higher call drop rate.

Analysis of the Entire Network (cont.)
 If the aforementioned factors can be excluded, we need to
analyze the abnormal release counters to see the
distribution ratio of abnormal releases, and handle
according to the classified causes of call drop problems
If L.E-RAB.AbnormRel.TNL is the majority
• Check the S1/X2 interface transmission, resolve transmission

alarm, e.g. intermittent disconnection
If L.E-RAB.AbnormRel.Radio/L.E-RAB.AbnormRel.HOFailure is the
majority
• Check whether the network design is proper. e.g. PCI and Neighbor
cell planning.
Procedure for Call Drop Analysis of
Top Cells
 After confirming the top cells, process according to the below
procedure:
 Whether significant adjustment was applied to the top cells, e.g. cut
over, swap.
 Check if there is related alarm information at the eNodeB side, e.g.
RRU related alarm, transmission related alarm, BBU related alarm,
etc.
 Whether the core network that the top cells belong to modified any
parameter.
 Whether there is OM operation on the top cells, e.g. cell deactivation,
board reset, etc.
 Whether the traffic of the cell increased suddenly that led to worse call
drop rate.
 Whether cell parameter has been changed.
Procedure for Call Drop Analysis of
Top Cells (cont.)
 If the aforementioned factors are excluded and the call drop rate
remains high, we may analyze the abnormal release counters to
see the distribution ratio of abnormal release causes, and then
process according to the classified causes.
 If L.E-RAB.AbnormRel.TNL is the majority: Watch the S1/X2
transmission, check the transmission alarm, e.g. intermittent
disconnection.
 If L.E-RAB.AbnormRel.HOFailure is the majority: analyze the 2
specific cells’ counters between which call drop rate is high, sort out
the neighbor relation over which the failures occur the most, check
whether the neighbor cell is properly configured.
 If L.E-RAB.AbnormRel.Cong is the majority: load balancing or
capacity expansion is needed.
 If L.E-RAB.AbnormRel.Radio is the majority: check whether there are
top users, weak coverage, interference or abnormal UEs.
Classified Troubleshooting of Call
Drop: Radio Problem
 Fault symptom: at eNodeB side, if the abnormal release is
counted by counter L.E-RAB.AbnormRel.Radio, call drop
due to radio interface can be concluded, and it is call drop in
non-HO scenario.
 Possible cause: weak coverage, uplink interference,

abnormal UE and so on lead to maximum RLC repeat time,
out of synchronization or signaling interchange failure, etc.
Drop: Radio Problem (cont.)
 Weak coverage confirmation: obtain the number of reports of
wideband CQI, number of times each MCS is scheduled on
PDSCH, number of times each MCS is scheduled on PUSCH,
observe the distribution of CQI and MCS. If they are mainly
distributed on low levels, we may confirm it with DT test, and
adjust the coverage accordingly.
 Related index:
 L.ChMeas.CQI.DL.*: number of wideband CQI reports with the value
of * (* stands for the value of CQI)
 L.ChMeas.PDSCH.MCS.*: number of times MCS index * is scheduled
on PDSCH（* stands for the value of MCS）
 L.ChMeas.PUSCH.MCS.*: number of times MCS index * is scheduled
on PUSCH（* stands for the value of MCS）
Drop: Radio Problem (cont.)
 Uplink interference confirmation: if it
is not because of weak coverage,
uplink interference needs to be
detected.
 Interference detection is a way to

monitor the frequency or time
domain interference through the
analysis of the data of frequency
spectrum and power distribution
 eNodeB uplink interference

detection can be started through
Uplink interference detection
M2000 on M2000
Drop: Transmission Problem
counted by counter L.E-RAB.AbnormRel.TNL, call drop due
to radio interface can be concluded.
 Possible cause: transmission fault between the eNodeB and

the MME, e.g. intermittent disconnection on S1 interface.
 Handling: check the transmission alarm and resolve the

transmission fault, and then check if the call drop index
becomes normal.
Classified Troubleshooting of Call Drop:
a Case of Transmission Problem
 The below is the call drop cause statistics result of a certain
network in several days:
L.E-
L.E- L.E- L.E- L.E-
Call Drop RAB.Abnorm
Time RAB.Abnorma RAB.NormR RAB.Abnor RAB.Abnorm
Rate Rel.HOFail
lRel el mRel.TNL Rel.Cong
ure
2011.12.6 3572 607442 0.0058 38 0 262
2011.12.7 3897 658393 0.0059 198 0 321
2011.12.8 3842 705126 0.0054 53 0 405
2011.12.9 3814 664429 0.0057 48 0 397
2011.12.10 5011 645081 0.0077 343 0 485
2011.12.11 9219 596828 0.0152 1874 0 613
2011.12.11: A big part of call drops are due to transmission problem
Drop: a Case of Transmission
Problem (cont.)
 After checking the alarm, it was found that on 2011.12.11
there were S1 interface alarm and SCTP link alarm. The
faults were fixed the next day and the KPI became normal.
Alarm Name Occurrence Time Recovery/Change

Time
SCTP Link Fault Alarm 2011-12-11 23:20:03 2011-12-11 23:20:14
S1 Interface Fault Alarm 2011-12-11 23:10:56 /
S1 Interface Fault Alarm 2011-12-11 23:10:56 2011-12-11 23:15:15
2011.12.11, fault alarm on S1 interface

led to deteriorate call drop KPI
Drop: Congestion Problem
counted by counter L.E-RAB.AbnormRel.Cong, call drop
due to resource congestion can be concluded.
 Possible cause: at the eNodeB side the radio resources are
congested which lead to abnormal releases, e.g. the
maximum number of users is reached.
 Handling: if call drops due to congestion occur in the top
cells for a long time, for the short-term, load balancing and
interoperation can be considered, but for the long-term,
capacity expansion is needed, and after the congestion is
resolved, it is necessary to observe whether the call drop
KPI becomes normal.
Drop: HO Problem
counted by counter L.E-RAB.AbnormRel. HOFailure, call drop due
to outgoing handover failure can be concluded.
 Possible cause: it will lead to an abnormal release when the user
is moving and is handed over out and the handover fails.
 Handling: if a lot of call drops due to outgoing handover failure
appear in a top cell , outgoing handover counters that are
associated to two specific cells can be used to locate the
questionable neighbor cell.
 Via the outgoing handover counters between two specific cells, the
number of handover failures from the top cell to the specific target cell
can be obtained. We may perform neighbor relationship inspection
and handover parameter optimization to the target cells with high
failure numbers.
Summary
 When handling call drop problems, the first thing is to know
the scope of call drops and confirm whether it is a entire
network problem or a top cell problem.
 After the scope of call drop is confirmed, counters of call

drop causes and CHR can be used to help the analysis of
the cause of call drops.
Thank You
www.huawei.com

13 LTE Call Drop Diagnosis

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

13 LTE Call Drop Diagnosis

Hochgeladen von

Copyright:

Verfügbare Formate

LTE Call Drop

Copyright © 2013 Huawei Technologies Co., Ltd. All rights reserved.

 Describe the definition of call drop

 Analyze the symptoms and causes of various types of call drop

 Describe the handling methods for various types of call drop

2. Analysis of causes of call drop

3. Handling of call drop problems

 In different scenarios call drops can be of different definition

 At network side, call drops rely on performance KPI statistics.

 eRAB Setup Success： Number of successfully set up E-RABs

 3. UE has setup eRAB, and before receiving “RRC Connection

 5. When RRC connection reestablishment fails eRAB abnormal

When eNodeB detects that there is no data interchange with UE

 Network side KPI call drop rate is defined as below:

 L.E-RAB.NormRel: Total number of releases of user’s eRAB in the

E-RAB RELEASE INDICATION UE CONTEXT RELEASE REQUEST

Counter Name Counter Description

E-RAB abnormal release counters with different QCI

Counter Name Description

Counters for various abnormal release causes count

2. Analysis of causes of call drop

3. Handling of call drop problems

 Method 3: Check the data configuration of the eNodeB,

 Normal: -110dBm <= RSRP <= -90dBm

 Bad: RSRP < -110dBm

 When the neighbor cell is missed, mis-configured or HO is not

 There is no best cell: multiple cells with similar normal RSRP,

A3 Trigger: Mn + Ofn + Ocn – Hys > Ms + Ofs + Ocs + Off

Offset of neighbor cell Offset of serving cell

 eNodeB fault (board reset, RF tunnel fault, etc.)

 UE fault (Model or software version)

 For hardware or transmission problems, we may do further

2. Analysis of causes of call drop

3. Handling of call drop problems

 When the scope of the problem is confirmed, we may find

Confirm the Find the

 Core network side version change or parameter modification.

 eRAN side parameter modification, e.g. some timer change or

 eNodeB software upgrade or patch

 A sudden increase of traffic leading to higher call drop rate.

If L.E-RAB.AbnormRel.TNL is the majority

• Check the S1/X2 interface transmission, resolve transmission

 Possible cause: weak coverage, uplink interference,

 Interference detection is a way to

 eNodeB uplink interference

 Possible cause: transmission fault between the eNodeB and

 Handling: check the transmission alarm and resolve the

2011.12.11: A big part of call drops are due to transmission problem

Alarm Name Occurrence Time Recovery/Change

2011.12.11, fault alarm on S1 interface

 After the scope of call drop is confirmed, counters of call

Das könnte Ihnen auch gefallen