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.
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.

User Count Based or Flow Control Based RRC Rejections

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.