You are on page 1of 5

LTE Service Drop check and improvement

1.
Introduction

The service drop rate is an important key performance indicator (KPI) for radio networks. It indicates the ratio
of the number of dropped services to the total number of services. A high service drop rate cannot meet user
requirements.

A service drop is counted each time the eNodeB sends an E-RAB RELEASE INDICATION or UE CONTEXT RELEASE
COMMAND message to the MME with a release cause other than Normal Release, Detach, User Inactivity, cs
fallback triggered, and Inter-RAT redirection after an E-UTRAN radio access bearer (E-RAB) has been
successfully set up for a UE.

1.1 Background Information

This section provides background information for service drops. The background information includes the
formula used to calculate the service drop rate, counters and alarms related to service drops, and drive tests
and TopN cell analysis method for troubleshooting service drops.

An E-UTRAN radio access bearer (E-RAB) is a bearer on the access stratum (AS) for carrying service data of UEs.
An E-RAB release is a process of releasing the bearer resources for UEs, and it represents the capability of a cell
to release bearer resources for UEs. One E-RAB release is counted once.

1.2 Related Counters

E-RAB Release Measurement (Cell) (E-RAB.Rel.Cell)

Counters related to service drops are classified as follows:

 Release types
– Normal releases
– Abnormal releases
– Normal releases for outgoing handovers
– Abnormal releases for outgoing handovers
 QoS class identifier (QCI)
– QCIs of 1 to 9
 Abnormal release causes
– Radio faults (L.E-RAB.AbnormRel.Radio): If the percentage of abnormal E-RAB releases due to
radio faults to all abnormal ERAB releases is greater than 30%, you need to check whether the
network planning such as the physical cell identifier (PCI) and neighboring cell planning is
proper.
– Transmission faults (L.E-RAB.AbnormRel.TNL): If the percentage of abnormal E-RAB releases
due to transmission faults to all abnormal E-RAB releases is greater than 30%, you need to
check whether the transmission links over the S1/X2 interface experience exceptions such as
intermittent disconnections.
– Congestion (L.E-RAB.AbnormRel.Cong): If the percentage of abnormal E-RAB releases due to
congestion to all abnormal E-RAB releases is greater than 30%, you need to check whether
congestion occurs in the cell.
– Handover failures (L.E-RAB.AbnormRel.HOFailure): If the percentage of abnormal E-RAB
releases due to handover failures to all abnormal E-RAB releases is greater than 30%, you
need to check whether parameters are properly set for the neighboring cells.

Interne Groupe Sonatel


– MME faults (L.E-RAB.AbnormRel.MME): If the percentage of abnormal E-RAB releases due to
mobility management entity (MME) faults to all abnormal E-RAB releases is greater than 30%,
you need to check whether parameters are properly set for the evolved packet core (EPC).
1.3 Formula

The service drop rate is calculated based on services but not on UEs. For example, services are set up on
multiple data radio bearers (DRBs) for a UE. Then, if all these services experience drops, multiple service drops
are counted.

The formula for calculating the service drop rate is as follows:

Service drop rate = L.E-RAB.AbnormRel/(L.E-RAB.AbnormRel + L.E-RAB.NormRel)

Where,

 The L.E-RAB.AbnormRel counter measures the total number of abnormal E-RAB releases in a cell.
 The L.E-RAB.NormRel counter measures the total number of normal E-RAB releases in a cell.
1.4 TopN Cell Selection

TopN cells must be selected according to the following rules:

 The service drop rate of each of topN cells must be higher than the average service drop rate of the
whole network.
 Cells are sequenced in descending order based on the number of abnormal E-RAB releases.
2. Troubleshooting Method

This section describes how to identify and troubleshoot the possible cause.

2.1 Possible Causes

If the service drop rate increases or greatly fluctuates, you must first locate the faults and then handle the
faults accordingly.

2.2 Troubleshooting Procedure


2.2.1 Troubleshooting service drops of the whole network
1. Check whether the whole network has experienced operations such as cutover, replacement, upgrade,
or patch installation.
2. Check whether the eNodeB parameters, such as timers or algorithm switches, have been modified.
3. Check whether the traffic volume sharply increases: The traffic volume trend of the whole network can
be determined based on the number of E-RAB setup attempts and successful E-RAB setups. Check
whether there are activities such as number allocation or important holidays that may lead to a traffic
volume increase.
4. Check whether the versions or parameters of the EPC network elements (NEs) have been modified.
2.2.2 Troubleshooting service drops of the topN cells
1. Check whether the topN cells have experienced operations such as cutover or relocation.
2. Check whether the topN cells have experienced operation and maintenance (OM) operations such as
cell deactivation or board restart.
3. Check whether the traffic volume sharply increases: The traffic volume trend of a topN cell can be
determined based on the number of E-RAB setup attempts and successful E-RAB setups. Check
whether there are activities such as concerts or sports that may lead to a traffic volume increase.
4. Check whether the cell parameters have been modified, such as the maximum number of
acknowledged mode (AM) protocol data unit (PDU) retransmissions by the UE or eNodeB, or the UE
inactivity timer length.

Interne Groupe Sonatel


5. Check whether the versions or parameters of the EPC NEs corresponding to the topN cells have been
modified.
2.2.3 Troubleshooting Service Drops Due to Radio Faults

This section provides information required to troubleshoot service drops due to radio faults. The information
includes fault descriptions, background information, possible causes, fault handling method and procedure,
and typical cases.

2.2.3.1 Fault Description

According to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.Radio counter measures
the number of abnormal E-RAB releases due to radio interface faults in nonhandover scenarios.

2.2.3.2 Possible Causes

Abnormal E-RAB releases due to radio faults are caused by faults such as the number of Radio Link Control
(RLC) retransmissions reaching the maximum, UE uplink out-of-synchronization, or signaling procedure failures
that are resulted from weak coverage, uplink interference, or UE exceptions.

2.2.3.3 Fault Handling Procedure


1. Check whether UEs are mostly located in weak coverage areas: Check the values of the counters
related to different channel quality indicator (CQI) levels and modulation and coding scheme (MCS)
orders to determine whether low-level CQIs and low-order MCSs are mostly used.
a. Yes: Confirm the cell coverage by using drive tests, and then adjust the weak coverage
accordingly. Go to 2.
b. No: Go to 3.
2. Check whether the fault is rectified.
a. Yes: End.
b. No: Go to 3.
3. Check whether uplink interference exists.
a. Yes: Remove the interference source. Go to 4.
b. No: Go to 5.
4. Check whether the fault is rectified.
a. Yes: End.
b. No: Go to 5.
5. Contact provider technical support.
2.2.4 Troubleshooting Service Drops Due to Transmission
2.2.4.1 Faults

This section provides information required to troubleshoot service drops due to transmission faults. The
information includes fault descriptions, background information, possible causes, fault handling method and
procedure, and typical cases.

2.2.4.2 Fault Description

According to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.TNL counter measures
the number of abnormal E-RAB releases due to faults at the transport network layer.

2.2.4.3 Possible Causes

Abnormal E-RAB releases due to transmission faults are caused by transmission exceptions between the
eNodeB and the MME. For example, the transmission link over the S1 interference experiences intermittent
disconnections.

Interne Groupe Sonatel


2.2.4.4 Fault Handling Procedure

Check whether transmission-related alarms are reported. If any, clear the reported alarms. Then, check
whether the corresponding counter has a proper value.

1. Check whether transmission-related alarms are reported on the M2000 client.


a. Yes: Clear the alarms by referring to the instructions in the alarm reference. Go to 2.
b. No: Go to 3.
2. Check whether the fault is rectified.
a. Yes: End.
b. No: Go to 3.
3. Contact provider technical support.
2.2.5 Troubleshooting Service Drops Due to Congestion

This section provides information required to troubleshoot service drops due to congestion. The information
includes fault descriptions, background information, possible causes, fault handling method and procedure,
and typical cases.

2.2.5.1 Fault Description

According to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.Cong counter measures
the number of abnormal E-RAB releases due to resource congestion.

2.2.5.2 Possible Causes

Abnormal E-RAB releases due to congestion are caused by congestion of radio resources on the eNodeB side.
For example, the radio sources are insufficient if the number of UEs reaches the upper limit.

2.2.5.3 Fault Handling Procedure

If service drops due to congestion occurs in a topN cell for a long time, mobility load balancing (MLB) can be
enabled to temporarily reduce the cell load. In the long term, the cell requires capacity expansion. After
rectifying the congestion fault, check whether the corresponding counter has a proper value.

1. Turn on the switch for the MLB algorithm, and then check whether the congestion fault is rectified.
a. Yes: End.
b. No: Go to 2.
2. Contact provider technical support.
2.2.6 Troubleshooting Service Drops Due to Handover Failures

This section provides information required to troubleshoot service drops due to handover faults. The
information includes fault descriptions, background information, possible causes, fault handling method and
procedure, and typical cases.

2.2.6.1 Fault Description

According to the definitions of eNodeB performance counters, the L.ERAB. AbnormRel.HOFailure counter
measures the number of abnormal E-RAB releases due to outgoing handover failures.

2.2.6.2 Related Information


 Number of Inter-Specific Cell Outgoing Handover Attempts (L.HHO.NCell.PrepAttOut)
 Number of Performed Inter-Specific Cell Outgoing Handovers (L.HHO.NCell.ExecAttOut)
 Number of Successful Outgoing Handovers Between Two Specific Cells (L.HHO.NCell.ExecSuccOut)
 Number of Ping-Pong Handovers Between Two Specific Cells (L.HHO.Ncell.PingPongHo)

Interne Groupe Sonatel


2.2.6.3 Possible Causes

Abnormal E-RAB releases due to handover failures are caused by failures of handovers from the local cell to
another cell.

2.2.6.4 Fault Handling Procedure

If service drops due to outgoing handover failures increase in a topN cell, you can identify the causes based on
the counters related to outgoing handovers to specific cells.

1. Obtain the related counters: Calculate the number of handover failures from the topN cell to each
specific target cell and find out the target cell that has the highest number of handover failures. Then,
check the parameter settings related to the neighbor relationship with this target cell. If the parameter
settings are improper, optimize the parameter settings as required.
2. Check whether the fault is rectified.
a. Yes: End.
b. No: Go to 3.
3. Contact provider technical support.
2.2.7 Troubleshooting Service Drops Due to MME Faults

This section provides information required to troubleshoot service drops due to MME faults. The information
includes fault descriptions, background information, possible causes, fault handling method and procedure,
and typical cases.

2.2.7.1 Fault Description

According to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.MME counter measures
the number of abnormal E-RAB releases that are initiated by the evolved packet core (EPC). However, these
abnormal releases are not included in the value of the L.ERAB. AbnormRel counter.

2.2.7.2 Possible Causes

Abnormal E-RAB releases due to MME faults are initiated by the EPC when UEs are performing services.

2.2.7.3 Fault Handling Procedure

MME faults must be identified on the EPC side.

1. Obtain the S1 tracing messages related to the topN cell and analyze specific release causes.
2. Collect the analysis result and information about the signaling procedure and then contact EPC
engineers.
3. Check whether the fault is rectified.
a. Yes: End.
b. No: Go to 4.
4. Contact provider technical support.
3. Diagram

Start

Interne Groupe Sonatel

Serice drop False


high?

You might also like