RF Optimization

LTE troubleshooting cases in

Huawei equipment
___

By Jose Heredia

https://joseh.me

INTRODUCTION
RAN troubleshooting for LTE sites is a continuous task that must be taken with high priority
since it can have a huge impact on users causing higher churn if it is not managed timely. As an
RF engineer, we need to monitor KPI daily along with customer complaints, this way we can
proactively optimize the network. As a general rule, we should monitor network level KPIs, but
also analyze Top N cells/sites, since the impact of these sites in the network performance may
be unnoticed, but locally users may be experiencing bad performance. Some of the most
 2

common KPI to monitor are: RRC accessibility, eRAB accessibility, service drop and DL
Throughput.

In the next pages we will be reviewing some typical RF troubleshooting cases that we can face
when optimizing LTE networks.

Case 1: Wrong TAC in external elements definition

In any mobile network, cells must have nearby cells defined as neighbors in order to allow
handovers (moving from one cell to another, without affecting the ongoing service: voice call,
video streaming, internet browsing etc.), if this is not correctly set up then handover failures
occur which can lead to service drops.

In Huawei equipment, it is possible to export the neighbor configuration of all sites and
compare the parameters with the real values configured in each site. For example, we can get
the current configuration of each cell for PCI, TAC, CellID, eNB ID etc. and then review how the
neighbors are defined to check whether those parameters are correctly configured. Also, drive
tests can be a useful way to find this kind of issues, if during the mobility tests there are many
service drops, it is very likely neighbor configuration is not correct.

Fig 1- LTE Retainability improvement

After the audit of neighbor configuration is performed and the differences are fixed in the
network, there is an obvious improvement in LTE retainability (Fig 1). Also, it can be noticed
that execution attempts and successes increase a lot after the change (Fig 2), this is as expected
since this kind of failures impacts the preparation phase (before execution) so it is normal that

Jose Manuel Heredia Suarez - https://joseh.me

 3

after the preparation failures are reduced, there will be a higher number of execution attempts
and success.

Fig 2 - HHO exec attempts and success

Case 2: 3G-4G reselection issue

For this case we have 2 troubleshooting problems handled differently but both having impact in
the reselection from 3G to 4G.

1. Missing LTE frequency definition in 3G network

During field tests, it was found that once the phone goes to 3G it is very difficult to
reselect to 4G. Since the tests involved CSFB, the mobile phone was always reaching 3G
to establish the voice call and after 5 seconds, finish the call and reselect to 4G. The
problem was mainly happening around 1 specific site, after the phone changed 3G
serving cell (from a different site) it immediately reselected to 4G. So based on these
findings, the troubleshooting case was focused on the problematic site.

When having 3G to 4G reselection issues, the first thing we check is whether there is LTE
coverage in the area, field tests force the phone to select 4G and they share good RF
levels for LTE (RSRP above -90 dBm, SINR above 7 dB).

After confirming that LTE is available in the problematic area, the next step is to check
whether the 3G serving cell has the correct configuration for 4G reselection. This is

Jose Manuel Heredia Suarez - https://joseh.me

 4

mainly done by reviewing the parameters configuration in the MO

UCELLNFREQPRIOINFO (For Huawei equipment, for other vendors there should also
be an MO with the same function but different name).

For this case, it was found that for the 3G serving cell, there was no object created in this
MO, which is the main reason why the 3G to 4G reselection was not happening, after
checking for the all site, it was found that there was no MO defined for any cell in the
site.

Fig 3 - ADD UCELLNFREQPRIOINFO

As can be seen in Fig 3, it is very important to define the LTE carriers available in the
area and set a priority which should be higher priority than the 3G carrier priority.
Another important parameter to configure correctly is the Measurement bandwidth which
should match the real bandwidth of the LTE carrier.

2. 3G to 2G service HO causing delay in 3G to 4G reselection

During SSV, the field test team found that after executing CSFB, the UE fallback to GSM
to continue with the call, after the call is finished, the UE reselection to 3G and then to
4G increased the delay to return to LTE network.

Jose Manuel Heredia Suarez - https://joseh.me

 5

Fig 4 - Signaling reselection issues

In the Fig 4, it is noticed how the UE moves from 4G to 3G and then to 2G during CSFB.
According to the current strategy set by the customer for its network, 3G to 2G handover
should not be enabled if the 3G coverage is continuous. 3G Drive tests in the area show
stable connection and good RSCP levels in the cluster, so this IRAT handover should be
disabled.

Fig 5 - IRAT HO Configuration

Jose Manuel Heredia Suarez - https://joseh.me

 6

In 3G Huawei equipment, it is possible to configure IRAT HO on cell level through the

MO UCELLHOCOMM. Configuration for the cells in the area shows CS IRAT HO is active
while PS IRAT HO is deactivated.

After deactivating the switch, the field test team checked that the UE remained in 3G
during the voice call and returned to LTE immediately after the call was finished.

Fig 6 - 3G to 4G Reselection after CSFB

Case 3: RRC Access degradation due to high random access preamble usage

By analyzing random access preamble usage of the network, it is noticed few cells reaching
100% at some hours.

Fig 7 - Top cells with high random access preamble usage

Jose Manuel Heredia Suarez - https://joseh.me

 7

Fig 8 - Chart top 2 cells for random access preamble usage

In the previous chart, it is noticeable that the random access preamble usage reaches maximum
values in some peak hours. Fig 9 shows the time advance of samples located within 1Km and
2Km for those 1 of the top cells, the number of samples increases during the same time the
random access preamble usage reaches its maximum.

Fig 9 - Time advanced chart

Based on these results, an increase of 2 degrees in electrical downtilt for this cell will help to
reduce the coverage and share the traffic increase in peak hours reducing the probability of
random access preamble usage congestion.

For the remaining top cell, the coverage is well contained so it is recommended to perform a
re-planning of random access resources.

Jose Manuel Heredia Suarez - https://joseh.me

 8

Case 4: Handover fail due to wrong external elements definition

Analyzing handover preparation success rate, it was found some top cells with KPI below 90%.
In fig 10 can be observed how the process to get a handover preparation failure happens.

Fig 10 - Handover preparation fail process

In this case the main counter impacted because of these failures is

L.HHO.IntraFreq.Prep.FailOut.PrepFailure, this counter increase when the HO preparation
failure occur during Intra Frequency HO preparation and it is highly related to mismatch
configuration between LTE external neighbors definition and the real value configured in the
neighbor cell.

In order to confirm the root cause, a trace was performed in the S1 interface of the impacted
cell. This trace shows several Handover requirements and failures.

Fig 11 - S1 Trace results

Jose Manuel Heredia Suarez - https://joseh.me

 9

By checking the signaling of the S1AP_Handover_Preparation_Fail message, it can be seen the

reason for failure.

Fig 12 - S1AP_Handover_Preparation_Fail

The reason for the failure is Unknown Target ID which means that the source cell has wrong
configuration for the target neighbor cell. We could directly check the configuration and
compare whether the real cell configuration is set in the neighbor definition, but for this case we
check the message S1AP_Handover_Require where the target cell parameters are sent.

Fig 13 - S1AP_Handover_Require

Jose Manuel Heredia Suarez - https://joseh.me

 10

The message shows that the source cells is trying to performed a Handover to a cell with
following parameters:

- eNB ID: 800452

- TAC: 13082

After checking the configuration of the target cell, it is found that for eNB ID 800452, the real
TAC is 13501. So we can conclude that the preparation failure occurs because the neighbor cell
definition in the source cell is wrong (TAC doesn't match).

Case 5: DL Throughput degradation due to wrong Tx configuration

Drive test for SSV shows Max DL throughput below 4Mbps where the target value should be 25
Mbps on average. It was confirmed with traffic KPI, that the cell was on low load at the time of
the test, so we discarded high load as a possible cause for the low throughput.

Fig 14 - DL Throughput test

In order to test only the RF environment, a packet injection test was configured in the eNB
pointing to the test UE. This packet injection basically orders the eNB to send a big number of
packets to a specific UE to test DL throughput in the RF environment without taking into
consideration Tx or Core network, which means the packets are generated in the eNB and sent
through the air interface to the UE.

The tests show that the Max DL Throughput reached 30Mbps confirming that there is no
limitation in the RF environment.

Jose Manuel Heredia Suarez - https://joseh.me

 11

Fig 15 - DL Throughput test packet injection

Based on these results, it was escalated to the Tx team who found that the problem was due to a
limitation on the DSCP in the Tx. Once the customer fixed the issue, it was noticed how the Tx
throughput increased.

Fig 16 - RxMaxSpeed at Tx

Jose Manuel Heredia Suarez - https://joseh.me

 12

Fig 17 - Cells DL Throughput

Case 6: MIMO performance degradation

Rank indicator 2 usage KPI went down to 0% after a specific date. In LTE networks, MIMO is a
feature that allows multiple transmission and reception at the same time for capable UEs.
Increasing the number of parallel streams increases average throughput. Rank indicator 2
means there are 2 unique streams between eNB and UE which theoretically can be considered as
twice throughput.

Fig 18 - Rank Indicator 2 Usage

Jose Manuel Heredia Suarez - https://joseh.me

 13

Based on these results an implementation team was sent to the site to review the ports
connection in the antenna and RRU. When using MIMO, there should be more than 1 Tx port
between antenna and RRU. For example for 2T2R, usually there are 2 ports (each port is a
Tx/Rx), if there is 2T4R then there should be 4 ports (2 Tx/Rx and 2 Rx).

For this case, the site was a 2T4R, so there were 4 ports connected to each antenna.

Fig 19 - Antenna connection ports

When physical problems are suspected, it is also important to review alarms on the site. For this
case one alarm is triggered:

Fig 20 - Site alarms

After reviewing with the integration team, it was found that the site was configured with CPRI
port bit rate of 1.25G. For the 2T4R scenario, this is a low capability CPRI configuration. The
installed optical transceiver is low capacity and cannot support 2.5G configuration, it is required
to change the transceiver for one capable of reaching 2.5G.

Fig 21 - CPRI port Config

Jose Manuel Heredia Suarez - https://joseh.me

 14

Case 7: Accessibility degradation after MME upgrade

After an MME upgrade, eRAB accessibility in the network reduced drastically.

Fig 22 - eRAB accessibility

The main reason for the degradation in eRAB accessibility is RNL (Radio network layer). In the
figure below, there are 2 specific dates where the failures increased obviously (March 16 and
March 28) . These 2 dates match with the dates where 2 MME were upgraded, so it is clear that
both operations impacted the accessibility in the same way.

Fig 23 - eRAB accessibility failures

Jose Manuel Heredia Suarez - https://joseh.me

 15

MME KPI shows that S1 mode failure times of UE-initiated service request (#10 implicit
detached) reduced considerably and S1 mode failure times of UE-initiated service request (#111
protocol error, unspecified) increased.

Fig 24 - S1 mode failure times of UE-initiated service request (#10 implicit detached)

Fig 25 - S1 mode failure times of UE-initiated service request (#111 protocol error, unspecified)

The analysis shows that after the upgrade the parameter BIT5 of BYTE_EX45 automatically
changes from 0 to 1. In the next figure can be noticed the effects that can happen if this switch
is modified.

Jose Manuel Heredia Suarez - https://joseh.me

 16

Fig 26 - BIT5 of BYTE_EX45

So, the solution for this issue was to change this parameter back to 0. Once the change was
applied, the performance recovered.

Fig 27 - eRAB Accessibility after optimization

Jose Manuel Heredia Suarez - https://joseh.me