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.

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.

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.

The second major KPI for LTE is the LTE ERAB Success Rate which is also part of the
accessibility. After the UE has completed the RRC Connection which has been
explained in my previous article, LTE KPI Optimization: RRC Success Rate , it needs to
get a Bearer assigned to it to initiate services. The bearer can be default (usually Data
QCI9) or dedicated (VoLTE QCI1). During initial access, the default bearer is added
and that constitutes the major portion of the total ERABs.

Firstly, lets understand the definition and points where the ERAB KPI is pegged. After
the UE sends the RRC Setup Complete message to the eNB, the eNB sends a S1 Initial
UE Message to the MME indicating the purpose of the UE (Attach, TAU, CSFB, Service
Request etc) and its credentials. Once the MME receives this message and it decides
that a bearer is required, it will send an Initial Context Setup Request to the eNB.
This message is considered as the ERAB Attempt as it contains the bearers to be
added along with their QCI values. The eNB receives this message and adds the DRB
(Data Radio Bearer) based on the bearer profile in Initial Context Setup Request. But
before the eNB can add bearers, it needs to activate the security for the connection.
This is done by the Security Mode Command which carries the ciphering and
 integrity protection algorithms. After this the eNB sends a RRC Connection
Reconfiguration message to the UE which adds a DRB and it includes the
configuration for the DRB like bearer identity, PDCP & RLC configuration (AM/UM
etc). SRB2 is also added at this point with this message. The UE receives these
messages and reconfigures the connection. Then the UE responds with Security
Mode complete and RRC Connection Reconfiguration Complete messages. As the
eNB receives these messages, it sends an Initial Context Setup Response to MME and
this message is considered as the ERAB Success.

Common Failures In ERAB Setup Phase

Now let’s understand the common failures that usually cause a ERAB setup failure.
Most of the times, the ERAB setup failures can be divided into two broad categories

Ø  Radio Induced ERAB Setup Failures

Ø  MME Induced ERAB Setup Failures

Let’s have an in-depth look at both of them and find ways to tackle them

Radio Induced ERAB Setup Failures

 Radio Link Failure

Consider a UE that receives Security Mode Command but fails to maintain radio
connection afterwards. This can happen in following two scenarios:
1. N310 consecutive out-of-sync events and T310 expiry

N310 indicates an interval of 200 consecutive PDCCH decoding failures. Simply put, if

the UE fails to decode PDCCH for 200ms, it will be considered one N310. However,
from here onwards, it is a sliding window with 10ms granularity. So, if the N310 value
is 2 then it means that if the UE fails to decode PDCCH for 210 ms, it will have
exceeded the configured N310 threshold. Once, N310 has been exceeded, the UE
starts timer T310 and if the UE is unable to retain the connection (still unable to
decode PDCCH) before T310 expires, the UE will initiate RRC ReEstablishment. Let’s
understand with an example. Consider N310 of 11 and T310 of 500ms, then the UE
will initiate RRC Connection ReEstablishment after 800 ms (N310 = (200 + (10*10)) =
300ms + T310 = 500ms).

2. Maximum RLC retransmission count exceeded

Consider that the UE receives both the Security Mode Command and the RRC
Connection Reconfiguration message. Now, it has to transmit the Security Mode
Complete and RRC Connection Reconfiguration Complete message in Uplink.
However, if the eNB fails to decode these responses, it will send a NACK to the UE or
the eNB may not send anything if it completely fails to even receive these messages.
The RLC layer in the UE is configured to resend the message if the message is not
acknowledged. So, the RLC layer will keep resending until a valid acknowledgement is
received. But the RLC cannot resend the same message indefinitely and it has a
upper limit of retransmissions. Once that limit is reached, the RLC will not retransmit
 again and the UE will consider that the radio link is compromised. This will trigger a
RRC ReEstablishment Request.

However, in both these cases, the RRC ReEstablishment Request will be rejected by
the eNB since processing this request requires to have a valid UE context at the eNB.
But since the UE did not respond to Security Mode Command, so the eNB does not
consider the context to be active yet and rejects the RRC ReEstablishment Request.
At the same instance, the eNB will send Initial Context Setup Fail to MME indicating
an ERAB Setup Failure.

 Optimization

Such issues can be reduced by increasing the N310 & T310 value. For instance, if the
value of N310 is increased from 2 to 6 and T310 is increased from 500ms to 1000ms,
then the UE will wait longer and there is more chance that N311 will be triggered.
N311 is the In-Sync value and so it is the opposite of N310. T310 stops if N311 is
triggered. If N311 is 1 then it means that UE needs 100ms of successful PDCCH
decoding to stop T310. So, there is a higher probability of triggering N311 if the value
of N310 and T310 is big.

Similarly, if the RLC retransmission count threshold is increased from 8 to 16, then
the RLC will retransmit 16 times instead of 8 times which will increase the probability
that the eNB might be able to decode the message and prevent RLF.

 No Response From UE

In this case, the UE receives the Security Mode Command and the RRC Connection
Reconfiguration messages in downlink but does not respond to these messages in
uplink. This can result in the Inactivity Timer expiry and the eNB will send a UE
Context Release Request to the MME during ERAB setup phase which will cause the
ERAB setup failure. Let’s see why this scenario happens in live networks. Once a UE
receives a downlink message which needs a response, it will need an uplink
allocation to send a response. In order to get an uplink allocation, the UE requests
the eNB by using a Scheduling Request Indicator or SRI. The UE sends a SRI based on
the SRI Configuration shared with it in the RRC Connection Setup Message. The SRI
Configuration tells the UE about the periodicity of the SRI and it determines the
subframe where the UE will send the SRI. So, the eNB will look for that UE’s SRI in
that subframe only and based on that, the eNB allocates an uplink resource to the
UE by instructing the UE on the PDCCH. Now, the vendors have moved to adaptive
SRI intervals which can result in a new SRI configuration in the RRC Connection
Reconfiguration message. There are UEs that do not support this change of SRI
configuration and they keep using the old SRI configuration. So, once they have
 received the Security Mode Command and the RRC Connection Reconfiguration
messages in downlink and they want to respond in uplink, they will have to send a
SRI first. The UE will be sending SRI according to the old SRI Configuration shared in
RRC Connection Setup message while the eNB will be looking for the UE’s SRI in the
subframe defined in SRI Configuration of RRC Connection Reconfiguration message.
This will result in a scenario where the eNB will consider that there is no response
from UE and once the inactivity timer is expired, the ERAB setup will fail.

This can also happen if the UE is in poor coverage or if the PUCCH has high
interference. The UE will keep sending SRIs in the correct location on PUCCH but the
eNB might not be able to read them resulting in a similar scenario as explained
above.

 Optimization

If such a scenario is observed consistently, it will be a good idea to shift from an

adaptive SRI period to a fixed SRI period. This will avoid reconfiguring the SRI
periodicity and will prevent this issue.

Also, using PUCCH enhancements like IRC on PUCCH can help reduce the probability
of such issues.

 RLC Mode Issue

This is rarely seen in networks when a UM mode (Unacknowledged Mode of RLC) QCI
is used for UEs which do not support UM mode. A common example is the QCI7
which is a Non-GBR QCI defined for live streaming or voice services and it usually
works in UM Mode. But there are many UEs which do not support UM mode and the
eNB simply fails to add a bearer with UM mode for them. This issue can be seen
from the counters as it will show that ERAB failures on Radio interface are happening
only on QCI7 or any other QCI which is set to UM Mode.

 Optimization

Simply changing the RLC mode for the QCI from UM to AM should solve this issue.

 Security Mode Failure

Another issue that is a bit rare is the Security Mode Failure issue. In this case, the UE
receives the Security Mode Command from the eNB but responds with a Security
Mode Failure message. Consequently, eNB sends Initial Context Setup Failure to the
MME resulting in ERAB setup failure. This happens if the security configuration on
the eNB is not supported by the UE or sometimes it can happen if the UE cannot
handle both the Security Mode Command and the RRC Connection Reconfiguration
together. In most of the cases, this turns out to be the terminal issue.

MME Induced ERAB Setup Failures

Let’s have a look at the MME induced ERAB failures. This may come as a surprise but
most of the MME induced ERAB setup failures in commercial networks are actually
caused by the radio interface and not the MME. I know it is hard to understand but
those of you who have delved themselves in RRC and S1 traces will understand it
more clearly once I explain this issue.

As explained in the section above, when the UE experiences a RLF after receiving the
Security Mode Command, it can try RRC ReEstablishment which actually tells the eNB
that there was a RLF on the UE’s side. Consider a UE experiencing a RLF before it
receives the Security Mode Command. The UE can only send a RRC ReEstablishment
after security is activated but if the UE experiences a RLF before the Security Mode
Command has been received, it cannot send a RRC ReEstablishment Request.

Now, consider that the UE experiences RLF after RRC Setup Complete message and
before Security Mode Command, this UE will go to idle and retry a new RRC
connection by sending another RRC Connection Request. Let’s say that the UE sends
a RRC Connection Request to another eNB (eNB2) and that eNB2 will start processing
it. The eNB2 does not know that the eNB1 already has a ERAB setup process going
on for this UE. The eNB2 will send a S1 Initial UE Message to MME for this UE and the
MME will see that it already has another ERAB setup process going on with eNB1. So,
for MME to initiate the new ERAB setup process by sending Initial Context Setup
Request to eNB2, it needs to first stop the process on eNB1, as it cannot have
separate context of same UE on two different eNBs. As a result, the MME will send a
UE Context Release Command to eNB1 asking to abort the ERAB setup process. The
eNB1 is trying to find the UE over the air interface and once it receives the Context
Release Command from MME, it will consider that the MME aborted the ERAB setup
and will peg it as a MME induced ERAB setup failure. eNB1 will send an Initial Context
Setup Failure to MME and the ERAB setup on eNB1 will be pegged under MME
induced failure. However, this issue was actually caused due to radio issue but the
eNB1 was not able to find that out.
 This issue can also happen if the UE sends the second RRC Connection Request to
the same eNB or even to the same cell. At RRC level, the eNB does not check TMSI
value and the UE is referenced by its CRNTI. So, if the same UE sends another RRC
Connection Request to the same eNB, it will allocate a new CRNTI and will consider it
a new connection. But when the eNB will send S1 Initial UE Message to MME, the
MME will check the TMSI and will send UE Context Release Command to the previous
session resulting in ERAB setup failure on the first process.

Another scenario that can cause a MME induced ERAB Setup failure is the Initial
Context Setup Timer on the MME. If that timer is set to small value and eNB is
waiting for the UE to respond to Security Mode Command, the MME will send UE
Context Release Command due to timeout. This will also result in a MME induced
ERAB Setup Failure.

 Optimization

There is no real optimization on the first scenario as it is purely a coverage issue and
coverage enhancement by physical or soft changes can be done to mitigate it. The
second scenario can be minimized by increasing the Initial Context Setup Timer on
the MME.