LTE KPI Optimization Deep

Dive: RRC Success Rate

This is the first part in LTE KPI Optimization and more related articles will be published
soon. So, let us get started without wasting any further time.

When the UE wants to attach or connect to the network, it needs to setup a RRC
Connection as explained in my article LTE Network Entry Steps . But before that it needs
to get synchronized in uplink. This is done by sending a RACH preamble (Msg1) to the
eNB and eNB responds with a Random Access Response (RAR aka Msg2). This is
where the UE sends a Msg3 also known as the RRC Connection Request and this marks
the attempt for the RRC Success Rate KPI. This message contains the objective of the
connection and based on that it is subdivided into following major categories:

 Mo-data : Usually used for UE coming back from idle mode if it has data to send or
if it has to make a call
 Mo-signaling : Most commonly observed for TAUs and Attach messages
 Mt-access : Idle UE responds to a paging message
 Emergency
 High Priority Access

It also contains a UE identity which can be a TMSI value if the UE was already previously
attached to LTE and had a TMSI allocation or it can be a random value indicating that the
UE does not know about its TMSI or it might be coming from another RAT.

Based on this request, the eNB sends a RRC Connection Setup message which contains
the information of SRB and some basic radio parameters like power control, SRI & CQI
periodicity.

Once, the UE gets the RRC Connection Setup, it makes the changes based on the
instructions in the message and then responds with RRC Connection Setup Complete
message. This message also contains the NAS information if the UE intends to send it.
The eNB pegs RRC attempt counter when it receives the RRC Connection Request and
the process is deemed successful on the receipt of the RRC Connection Setup Complete
message.

Common Failures In RRC Setup Phase

In order to maintain and optimize the RRC KPI, one should know the major issues that
can cause a RRC setup failure.

RRC Setup Failure Due To No Response

This is the most common RRC failure which is present in every network. Most of the
failures in the RRC stage are due to no response from the UE. This means that the eNB
receives RRC Connection Request message from the UE and responds with a RRC
Connection Setup message but does not receive or is unable to decode the RRC
Connection Setup Complete message.
Now let’s understand why this happens. The RRC Connection message is usually around
7 bytes in length while the RRC Connection Setup Complete message may contain the
whole NAS information (like TAU or Attach Request) and its size can vary from as small
as 8 bytes to as big as over 100 bytes. Consider that a UE near cell edge with limited
power sends a RRC Connection Request. Since, it is only around 7 bytes, it will need a
small number of RBs so power per carrier will be high. But when it needs to send RRC
Connection Setup Complete which is around 100 bytes, it will need a bigger number of
resources even if the message is fragmented. So, the average power per carrier will be
reduced leading to a higher probability that the message may not be decoded at the eNB.

This can also happen if there is interference on the cell as it will make it further difficult
for the eNB to decode the message. It can also happen if the UE fails to decode RRC
Connection Setup message so it will never send the RRC Connection Setup Complete
message.

RRC Rejections

This is the second issue that can happen but it is usually much less observed in
commercial networks compared to the failures due to no response. In these cases, the
eNB rejects the incoming RRC Connection Request by sending a RRC Reject message.
This is mostly observed when eNB experiences congestion and there are not enough
resources left to assign to a new user requesting a RRC Connection.

If the PUCCH is congested, the RRC connection can be rejected. PUCCH carries HARQ
ACK/NACKs, CQI and SRIs. If the PUCCH resources are not available, users will not be
able to send CQIs and the eNB cannot schedule without CQI information. Usually
vendors implement PUCCH in a way that when PUCCH utilization is increased, the CQI
interval is increased. For example, users sending CQI with an interval of 10ms will be
shifted towards 40ms in order to increase the capacity of the PUCCH.
But when no further capacity is available, the eNB needs to put a limit on new incoming
connections resulting in RRC Rejections. Similarly, RRC Rejections can be seen if the
active UE count increases beyond the board limit or if the CAPS exceed the limit. The
details related to troubleshooting and optimizations for such issues is given below.

Optimization For RRC Success Rate KPI

The following procedures are usually used based on different scenarios

Conventional Method : Physical Optimization

The easiest and conventional method is the physical optimization. For instance, down-
tilting a cell will reduce the coverage and remove the far-away users. This will reduce the
probability of RRC failure due to no response. However, there will be issues that might
not be resolved by the conventional approach so I have listed down other methods that
might come in handy.

Relevant Timers

There are two relevant timers for RRC Success Rate KPI.

The first timer is maintained on the UE and it is the famous T300. UE starts it after
sending the RRC Connection Request and stops it at the receipt of RRC Connection
Setup or Reject message. If this timer is too small, the UE will stop waiting for the RRC
Connection Setup message and the RRC procedure will fail. So, increasing this timer can
help in this phase.

Secondly, eNB has an internal timer (different vendors have different names for it) which
the eNB starts after sending the RRC Connection Setup message. It stops this timer after
successfully receiving the RRC Connection Setup Complete message. So, if this timer is
small and the UE is trying to send the RRC Connection Setup Complete with
retransmissions, then the eNB will consider it a failure as soon as the timer expires. So,
increasing this timer might also help in certain scenarios.
Coverage Enhancement & Power Control

The RRC failures due to lack of response from UE can also be caused if the power
control on the PUSCH is not correct or if it is too conservative. For instance, the power
control on PUSCH depends on the P0 Nominal value as well as Alpha factor. Different
vendors use different settings here like using a low P0 Nominal value (for example -100
dBm) with a higher Alpha factor of around 0.9 or 1 or a using a high P0 Nominal value
(for example -70dBm) with a smaller Alpha factor of 0.7 or 0.8. But if both the P0 Nominal
and Alpha factor are low then the UE will use a smaller power value to send the RRC
Connection Setup Complete and therefore, the chances are that it will not be decoded
correctly.

In case there is interference on the cell, then features which mitigate interference should
be enabled. For instance, enabling Interference Rejection Combining can provide good
gains in such scenarios.

Mobile Originating Signalling RRC Success Rate

Usually Mo-Sig RRC Success Rate is lower than others. The reason is once again linked
to the size of the MSG-5 (RRC Connection Setup Complete). For a normal Mo-data or
Mt-access, the size of RRC Connection Setup Complete message is around 8 to 10
bytes but for Mo-signalling, it can vary and usually is above 50 bytes. This is because
Mo-signalling RRC Request is usually used for NAS signalling messages like Attach
Request or Tracking Area Update Requests. These messages are big in size and are
sent inside the RRC Connection Setup Complete message as NAS. So, this reduces the
RRC Success Rate of RRC Mo-Signalling compared to other RRC Request types.

This means that if the network has a higher ratio of RRC Mo-Signalling requests then it
will have a lower RRC Success Rate. Usually, Mo-Signalling is around 20 to 25% while
Mo-data has the highest percentage. Still it can vary from network to network based on
TAC planning and mobility strategy. However, if you have very high Mo-Signalling
percentage then the chances are that RRC Success Rate will be relatively lower
compared to another similar network with lower Mo-Signalling percentage.

Incompatible UEs

It has been seen that sometimes there are users that are not compatible with the
configuration of the network. So, once they receive the RRC Connection Setup message
and they find out that they are not compatible with the configuration provided, they do not
respond with a RRC Connection Setup Complete message resulting in a RRC failure on
the eNB. However, such users keep trying again and again impacting the KPI. This kind
of issue can be seen from the traces or CHRs that verifies that it is a single user. It might
be inferred from the RRC counters as well since the number of failures are relatively
same in consecutive intervals. However, such cases usually go unsolved as it is not a
network issue but an abnormal UE problem.

PUCCH Based RRC Rejections

RRC Rejections due to PUCCH congestion can be solved by simply increasing the
PUCCH Resource Blocks. Vendors have parameters for PUCCH allocations and
 minimum PUCCH Resource Block allocation is 4 per subframe. This is because each slot
has PUCCH RB allocation on both ends of the band so that means that each slot will
have atleast 2 Resource Blocks for PUCCH – one at the top of the frequency band and
the other at the bottom of the band. Since, each subframe has two slots so that means
that the subframe will have atleast 4 PUCCH Resource Blocks.

When 4 PUCCH RBs are not enough, they can be expanded to a higher value using
parameter or in some implementations, an adaptive approach can be maintained where
the eNB changes the PUCCH RB count dynamically based on the load requirement. This
approach solves the issue completely.

Different baseband boards and vendors have different limitations on active user count
and CAPS (Call Attempts Per Second). When such limitation is reached, incoming RRC
Connection Requests are rejected by the eNB based on flow control or resource issue. In
such cases, the following basic steps can be done

 Decrease the UE Inactivity Timer to a smaller value. This will initiate early release
for the users and load due to user count will be reduced. However, this can increase
the signalling load as idle users can try to come back to network more frequently which
can increase CPU usage of the eNB. So, only use this if the issue is related to user
limitation while CPU usage is fine.
 T302 should be increased to limit the RRC signalling load. When a UE gets a RRC
Reject from eNB, it has to wait for T302 seconds before sending another RRC
Connection Request. So, increasing T302 will increase the interval between such RRC
Connection Requests and therefore, reduce the signalling load on the eNB.
 Mobility Load Balancing is another feature that can help in such a scenario by
moving users away from the congested carrier to another less utilized carrier.

If you have any questions or feedback regarding this article, simply drop a comment
below. I will respond accordingly and also intend to write more about KPI Optimization
soon.

Accessing LTE KPIs

KPIs are the important performance parameters that are required to troubleshoot and
optimize the LTE network and check the performance of the most essential network
functions.

 Summary Report: Select the time range, venue and APs from the respective
drop-down and click Apply to view the following System KPI reports:
o RRC Connection Establishment Success Rate: The Radio Resource
Control (RRC) protocol connects UE/Clients (CBRS compliant LTE device
such as a dongle or a phone) with LTE AP. A RRC connection is successful
when an UE performs the call establishment procedure, and get resources
from the LTE AP. The connection success rate is displayed as a
percentage, computing the successful connections against total
connection attempts. An acceptable success rate percentage is displayed
in green color and a poor success rate is displayed in red.
o RRC Connection Reestablishment Success Rate: The re-
establishment procedure is required in order to re-establish the lost RRC
connection. This procedure is successful only when LTE AP has a valid UE
context. A re-establishment is initiated upon detecting radio link failure,
handover failure, mobility failure, integrity check failure and when there is
a RRC connection reconfiguration failure. The connection re-establishment
success rate is displayed as a percentage, computing the successful re-
connections against total re-connection attempts. An acceptable success
rate percentage is displayed in green color and a poor success rate is
displayed in red.

o Initial E-RAB Setup Success Rate: After the UE sends the RRC setup
complete message to the LTE AP, the LTE AP sends an initial UE message
to the MME indicating that the purpose of the UE and its credentials. When
the MME receives this message and it decides that a bearer is required, it
sends an initial Context setup request to the LTE AP. This message is
considered as the initial EPS Radio Access Bearer (E-RAB) attempt, as it
contains the bearers to be added.

The initial connection setup success rate is displayed as a percentage,

computing the successful connections against total connection attempts.
An acceptable success rate percentage is displayed in green color and a
poor success rate is displayed in red.

o Additional E-RAB Setup Success Rate : The additional E-RAB success

rate is displayed as a percentage, computing the successful additional
connections against total connections.
o Handover Success Rate: This KPI is used to measure the performance of
network when handling the movement of users and still retain the service
for the user. When the source LTE AP sends RRC connection
reconfiguration message to the UE, an inter LTE AP hand over is done. The
number of the attempted handover is calculated at the source cell. The
hand over success rate is displayed as a percentage, computing the
successful handover against total handover attempts. An acceptable
success rate percentage is displayed in green and a poor success rate is
displayed in red.

o Dropped Call Rate (DCR): DCR in LTE network is a scenario when a

user’s ongoing session is dropped, terminated abruptly, and
unintentionally, requiring the user to initiate a new connection to resume
services. At the LTE AP level, this is considered as an abnormal release
which can be verified from the error code inside the Context Release
message. The DCR is displayed as a percentage, computing the number of
dropped calls against total calls handled. An acceptable DCR percentage is
displayed in green color and a poor rate is displayed in red.

o SAS Availability: For LTE APs to remain in the transmitting state, a valid
grant from SAS is mandatory. Each AP is constantly communicating with
SAS via the heartbeat mechanism. Therefore, it is critical that the SAS
connection with LTE AP is always available. For any SAS outages, a
counter is maintained to record the percentage of time for which SAS is
available to track LTE AP service availability.
 o Cell Availability: Each LTE AP is referred to a Cell as per LTE protocol
terminology. Each Cell is considered as available when an LTE AP can
provide the E-RAB service in the cell. This KPI is calculated as the
percentage of time that the cell is considered available against the total
measurement time. A healthy percentage is displayed in green, and a
poor percentage is displayed in red.

 Throughput statistics: The following KPIs measures various data traffic

statistics in terms of throughput (Mbps) and volume (GBytes) for the Down Link
(DL) and the Up Link (UP) direction.
o Average DL throughput (Mbps):This KPI measures the average rate at
which data is transferred from the LTE AP to the UE, within a selected
reporting interval.

o Average UL throughput (Mbps): This KPI measures the average rate at

which data is transferred from the UE to LTE AP, within a selected
reporting interval.

o DL traffic volume (GBytes): This KPI measures the total amount of data
transferred from LTE AP to the UE

o UL traffic volume (GBytes): This PKI measures the total amount of data
transferred from the UE to LTE AP.

 GPS statistics:
o GPS Availability: This KPI measures the availability GPS measurements
only for LTE APs within a venue that are configured to sync up with GPS
satellites. The GPS availability is measured in percentage of time within
the selected reporting interval.

o Phase Locked: This KPI indicates the average percentage of time LTE APs
within a Venue remained in the phase-locked state with timing source.
This KPI is measured in percentage of time within the selected reporting
interval.

o Holdover: This KPI indicates the average percentage of time LTE APs
within a Venue were degraded to holdover phase because of unavailability
of a reliable timing information from their timing source. This KPI is
measured in percentage of time within the selected reporting interval.

o Frequency Phase Recovery:This KPI indicates the average percentage

of time all GPS capable LTE APs within a Venue were in frequency
recovery phase. This KPI is measured in percentage of time within the
selected reporting interval.

 Stats per LTE AP: Click the Stats per LTE AP to view the KPIs pertaining to
each configured LTE AP, in a tabular format. The data is presented per Access
Point.

All of the per Venue KPIs are also available for each LTE AP.