LTE KPIs

PRESENTATION

Contents
Introduction
1.
2.
3.
4.
5.
6.
7.
8.
9.

Scope of Presentation
Introduction of Ericsson KPIs
Accessibility
Retainability
Drop Sessions
Integrity
Downlink Throughput Troubleshooting
Mobility
Handover Optimization

Introduction
1 .Scope of Presentation.
This presentation describes the Key Performance Indicators (KPIs) for
the LTE Radio Access Network (RAN) used to measure the contribution
to subscriber perceived quality and system performance.
KPIs can be used for the following tasks:
Monitoring and optimizing the radio network performance to provide
better subscriber-perceived quality or better use of installed resources
Rapidly detecting unacceptable performance in the network, enabling
the operator to take immediate actions to preserve the quality of the
network
Providing radio network planners with the detailed information
required for dimensioning and configuring the network for optimal use

Accessibili
ty
There are a few E-UTRAN KPIs which will adversely affect end-user
experience if any of these KPIs under perform and it is critical to
monitor closely the performance of these main KPIs. This
troubleshooting guideline aims to present ideas to pinpoint
potential areas for trouble-shooting if any of these main E-UTRAN
KPIs under perform.
1.1 Accessibility
Accessibility measurements are based on drive tests or statistics. It
is a combined metric including RRC, S1 and E-RAB establishment
success rate. In the case of poor accessibility, each success rate
must be analyzed individually. Reasons for poor accessibility
include but are not limited to:
Poor coverage. In this case, qRxLevMin can be decreased.
UE camping in the wrong cell. In this case, parameters for cell
reselection can be tuned.
High UL interference
Admission reject, due to lack of licenses

Accessibili
ty

Accessibili
ty

EUTRAN Accessibility
KPIs

Accessibili
ty

1.2 Random Access

Accessibili
ty

In the LTE network, the UE uses the random access process to gain
access to cells for the following reasons:
Initial access to the network from the idle state
Regaining access to the network after a radio link failure
As part of the handover process to gain timing synchronization
with a new cell
Before uplink data transfers when the UE is not time
synchronized with the network
The main counters for this scenario are the following:
pmRaAttCbra
pmRaSuccCbra

1.3 RRC Connection Establishment

Accessibili
ty

RRC connection establishment is used to make the transition from

RRC Idle mode to RRC Connected mode. UE must make the
transition to RRC Connected mode before transferring any
application data, or completing any signaling procedures.
The RRC connection establishment procedure is always initiated
by the UE but can be triggered by either the UE or the network. For
example, the UE triggers RRC connection establishment if the enduser starts an application to browse the internet, or to send an
email. Similarly, the UE triggers RRC connection establishment if the
UE moves into a new Tracking Area and has to complete the
Tracking Area Update signaling procedure. The network triggers the
RRC connection establishment procedure by sending a Paging
message. This could be used to allow the delivery of an incoming
SMS or notification of an incoming voice call.
RRC connection establishment for LTE is relatively simple
compared to RRC connection establishment for UMTS. The UMTS
procedure requires NBAP and ALCAP signaling across the Iub
interface between the Node B and RNC. These signaling protocols

Accessibili
ty (NAS) message
In the case of LTE, the initial Non-Access Stratum
is transferred as part of the RRC connection establishment
procedure. In the case of UMTS, the initial NAS message is
transferred after the RRC connection establishment procedure. The
approach used by LTE helps to reduce connection establishment
delay.
RRC connection establishment configures Signaling Radio Bearer
(SRB) 1 and allows subsequent signaling to use the Dedicated
Control Channel (DCCH) rather than the Common Control Channel
(CCCH) used by SRB 0.
The signaling for RRC connection establishment is shown in below
figure. The entire procedure is completed using only RRC signaling.
A 3-way handshake is used to move the UE into RRC connected
mode

Accessibili
ty

Accessibili
ty
1.5 Initial E-RAB Establishment Success Rate
The Initial Context Setup procedure is triggered by the MME by
sending S1AP message INITIAL CONTEXT SETUP REQUEST. This
message includes information regarding the first E-RAB to set up.
Included is information regarding the security algorithms and
security keys to use.
The RBS applies the security information and informs the UE, using
the SECURITY MODE COMMAND message. The UE responds with
SECURITY MODE COMPLETE. After this point all data between the UE
and RBS is encrypted and control signaling is integrity-protected.
Following successful activation of security, the RBS allocates
resources for the first Data Radio Bearer. Resources for SRB2 are
allocated as well. The RBS configures the UE by sending message
RRC CONNECTION RECONFIGURATION.
The UE responds with RRC CONNECTION RECONFIGURATION
COMPLETE and the procedure is completed after the RBS has sent
INITIAL CONTEXT SETUP RESPONSE to the MME.

Accessibili
ty

Accessibili
ty
1.7 Added E-RAB Establishment Success Rate
Defined as the accessibility success rate for end-user services
which is carried by E-RABs included in the E-RAB setup
procedure.

Accessibili
ty
1.9 S1 Signaling Connection Establishment
The UE finalizes the establishment of the RRC connection by
sending the message RRC Connection Setup Complete to the
eNodeB. The UE indicates the selected PLMN and provides a NAS
message to the eNodeB. In this case the NAS message is Attach
Request.
The Attach Request message is provided to the MME in the Initial
UE Message. The UE is identified either by the GUTI or the IMSI (in
the Attach Request message).
MME sends Authentication Information Request to HSS including
the IMSI to identify the UE/Subscriber. HSS responds with
Authentication Information Answer including the requested number
of Authentication Vectors (Kasme, RAND, AUTN, XRES) used for
security and authentication between the UE and the network. The
MME requests Authentication of the UE by sending the NAS
message Authentication Request to the UE including the selected
RAND and AUTN, using the RRC DL Information Transfer.

Retainability
2.Retainability
Retainability measurements are based on drive tests or statistics.
For the case when a measurement is based on drive test, the
probability that a session is abnormally released is proportional to
the session length. To obtain a measure independent of the session
length, the number of abnormal releases can be normalized with the
session time to calculate the number of abnormal releases per
second.
For the case when a measurement is based on statistics, the formula
provided for abnormal releases per second is normalized with the
time that the UE is active. An active UE in this context is a UE that
has uplink or downlink transmitted data during the last 100 ms.
Reasons for poor Retainability include but are not limited to:
Missing neighbor relations
Poor radio conditions
Badly tuned handover parameters

Retainability
EUTRAN Retainability
KPI

2.1 UE Session Time

It shows the accumulated active session time in a cell for the
measurement period.
Number of session seconds aggregated for UEs in a cell. A UE is
said to be in session if any data on a DRB (UL or DL) has been
transferred during the last 100 ms.

Retainability

Retainability

Figure: MME Initiated UE Context

Release

Retainability
2.2 RBS Initiated E-RAB & UE Context Release with counters
Description

Retainability

Figure: RBS Initiated UE Context

Release

3.DROP SESSIONS
There are several reasons why a session may drop in LTE. However, whether the
session is dropped or not depends on the particular vendor implementation. That
is, the drop may be caused by a UE message or by measurements carried out by
the eNodeB.
Both the UE and the eNodeB may check if the radio link is in-synch.
So. When is the Radio Link in-synch?
The UE is expected to monitor the RS in the downlink. Based on the signal
strength of the Reference Signals (i.e., the RSRP), the UE will determine if it can
decode the PDCCH based on a certain set of parameters that are provided in the
specs. Each UE will have a different RSRP threshold in which it will assume it
cannot read the PDCCH. If the Reference signals have enough strength such that
the UE can decode consistently the PDCCH, then the link is In-Synch.
How do we determine if the Radio Link is out of Synch?
The full procedure for determining if the link has failed due to being out of sync is
shown in the figure next slide. In the picture, there are three parameters shown:
n310: This parameter indicates the number of 200 ms intervals when the UE is
unable to successfully decode the PDCCH due to low RSRP detected. That is, this
parameter indicates the number of times in which the UE cannot successfully
decode 20 consecutive frames in the downlink.
t310: It is a timer, in seconds, used to allow the UE to get back in synchronization
with the eNodeB.

DROP SESSIONS
n311: This parameter indicates the number of 100 ms intervals that the UE must
successfully decode the PDCCH to be back in-synch with the eNodeB. That is, this
parameter indicates the number of times in which the UE must successfully decode
10 consecutive frames in the downlink in order for the UE to assume the radio link is
in-synch.
If the UE detects n310 consecutive out-of-sync indications, it starts the t310 timer. If
the timer expires, the link has failed. If the UE detects n311 consecutive in-sync
indications prior to the t310 timer expiring, then the timer is stopped and the link
has not failed.

DROP SESSIONS
So what happens after the UE detects that the link failed?
If the UE determines that the Radio Link fails, the UE will try to reconnect with an RRC
Connection Reestablishment Request message. There are a number of cases that
could occur based on vendor implementation.
What if the eNodeB does not support RRC Connection Reestablishment?
The case shown in the figure below is the simplest case where the eNB does not
support RRC Connection reestablishment. In this case, the eNB responds with an RRC
Connection Reestablishment Reject message. Simultaneously, the eNB will realize that
the radio link has failed and request the connection to be release to the MME. It first
requests to drop the UE Context or the connection to the UE. The cause value is set to
Radio Connection with UE Lost. The MME will respond with a UE Context Release
Command. At this point, the eNodeB will respond with the UE Context Release
Complete message to the MME and will release the RRC connection with the UE by
sending an RRC Connection Release to the UE. Depending on the RF conditions, the UE
may or may not receive this message.

DROP SESSIONS
In the case of an RRC connection reestablishment success, the following signaling is carried
exchanged.

If the RRC connection gets successfully reestablished, then the session does not get dropped.

DROP SESSIONS

If the RRC connection

reestablishment procedure fails
in one of its steps, then the
eNodeB will send the UE context
release request message to the
MME. Note that the RRC
connection reestablishment
process may fail in several steps.
Below, in the figure, only one
case is shown.

4.Integrity
Integrity
4.1 EUTRAN Latency KPIs
The time it takes to schedule the first packet on the air interface,
determined from the time it was received in RBS.

Integrity

Figure: Downlink Latency

Measurement

Integrity
4.2 EUTRAN Throughput KPIs
The speed at which packets can be transferred once the first packet
has been scheduled on the air interface.

Integrity

Figure: DL DRB Traffic Volume

Integrity

Figure: UL DRB Traffic Volume

Integrity
4.3 EUTRAN Packet Loss KPIs

Packet Loss Rate can be broken down into:

The rate of congestion related packet losses (for example, the
packets that get dropped due to active queue management
functionality).
The rate of non-congestion related packet losses (those are packets
that get
lost Error
in transmission,
Downlink
Packet
Loss Rate for
[%]:example, discarded by some link
layer receiver due to CRC failure).

Uplink Packet Loss Rate [%]:

Integrity

Figure: Uplink Packet Loss Measurement

5.DOWNLINK THROUGHPUT
TROUBLESHOOTING
Below are the Low Throughput causes in the Downlink for LTE networks

BLER (bad coverage)

Downlink Interference (Bad CQI)
MIMO Parameters
Scheduling algorithm
Low Demand
CQI reporting frequency
Other (VSWR, Backhaul capacity)

DOWNLINK THROUGHPUT
TROUBLESHOOTING

Step 1: Identify cell with low DL (downlink) throughput

a) The first thing is to identify those cells with low throughput. This threshold is
defined by network policies and practices (it also depends on design parameters).
Reports should be run for a significant number of days so that data is statistically
valid.

Step 2: Identify Downlink interference

a) Cells with downlink interference are those whose CQI values are low (an exception
to this rule is when most traffic is at the cell edge bad cell location-). Analyze the CQI
values reported by the UE for
1.Transmit Diversity
2.MIMO one layer
3.MIMO two layers
Typical values for transmit diversity oscillate between 7 and 8.
Typical values for MIMO one and two layers oscillate between 10 and 12.
b) If low CQI values are found after a CQI report is obtained, then downlink interference
might be the cause of low throughput.

DOWNLINK THROUGHPUT
TROUBLESHOOTING
Step 3: BLER Values
a) Run a report for BLER in the cells identified. The BLER should be smaller or equal than 10%. If
the value is larger, then, there is an indication of bad RF environment.
b) Typical causes of bad BLER are downlink interference, bad coverage (holes in the network,
etc.)

Step 4: MIMO Parameters

a) Identify the transmission mode of your network. There are seven transmission modes as shown
in the table below

DOWNLINK THROUGHPUT
TROUBLESHOOTING
Step 5: Low Demand
a) Run a report using the counters provided by the OEM to find
1.Maximum number of RRC connections supported per cell (parameter or feature)
2.Maximum number of RRC connections active per cell
3.Average number of RRC connections active per cell
4.Maximum number of users per TTI supported per cell (parameter or feature)
5.Maximum number of users scheduled per TTI in the cell(s) of interest
6.Average number users scheduled per TTI in the cell(s) of interest

b) If the maximum number of RRC connections active per cell is close or equal to
the maximum number of RRC connections supported, then. The cause for low
throughput is load.
c) A high number of scheduled users per TTI does not necessarily mean that
demand is the cause for low throughput.

Step 6: Scheduler Type

a) Find the scheduler types your OEM supports
b) Select the one that is more convenient for the type of cell you are investigating.
Examples of schedulers are: round robin, proportional fairness, maximum C/I, equal
opportunity, etc. OEMs allow you to switch the scheduler in your network but
recommend one in particular.
c) The wrong scheduler may be the reason for bad throughput.

DOWNLINK THROUGHPUT
TROUBLESHOOTING

Step 7: CQI reporting parameters

a) Check if your network is using periodic or aperiodic CQI reporting (or both).
b) Verify the frequency in which the CQI reporting is carried out for periodic
reporting as well as the maximum number of users supported per second.
c) If the value is too small compared with the maximum number of RRC active
connections, then, increase the values of the parameters CQIConfigIndex as well
as RIConfigIndex (deal with in future blog).
d) If your network is not using aperiodic CQI reporting, then enable it.
e) Slow frequencies of CQI reporting might yield bad channel estimations that
prevent the eNodeB from scheduling the right amount of data and Modulation and
Coding Schemes to UE.

Step 7: Other
a) Run a VSWR report or ask your OEM to run it for you.
b) High values of VSWR result in low throughput due to losses.
c) Check your backhaul capacity. Often times, the backhaul links are shared
among multiple RATs. Make sure your backhaul is properly dimensioned.

Mobility
6.Mobility
A common mobility measurement is the handover success rate. It
can be verified by system counters that record the success rate of
handover attempts. Reasons for poor mobility include but are not
limited to:
Missing neighbor relations
Poor radio conditions
Badly tuned handover parameters
If handover is triggered too early, the target cell SINR can be too
weak when handover occurs. If handover is triggered too late, the
source cell SINR can be too low. This can result in an abnormal
release before handover.
Handover hysteresis and time-to-trigger settings are required to
prevent excessive ping-pong handovers. Such behavior increases
signaling, risk of failure, and decreases throughput.

Mobility
Tuning of these parameters may be required in different cells to
find the right balance. For example, rural and fast changing
environments have different requirements. This tuning should be
based on UE measurements during drive tests.
With too little overlap, handover may fail. With too much cell
overlap, higher interference occurs and cell edge throughput can
be reduced. Again, a balance must be achieved by adjusting
overlap margins and cell sizes. This can be achieved with
EUTRAN
Mobility
[%]:
parameters
andSuccess
physical Rate
changes.

Mobility
6.1 Intra RBS Handover Preparation & Execution

Figure: Intra RBS Handover Preparation

Mobility

Figure: Intra RBS Handover Execution

Mobility
6.2 X2 Based Handover Preparation & Execution

Figure: X2 Based Handover Preparation

Mobility

Figure: X2 Based Handover Execution

Mobility
6.3 S1 Based Handover Preparation & Execution

Figure: S1 Based Handover Preparation

Mobility

Figure: S1 Based Handover Execution:

HANDOVER TYPES
The following types of Mobility are supported in EUTRAN:
1.Inter LTE Handover(Between Different MME Pool)
2.Inter LTE Handover(Between SAME MME Pool)
a)Intra eNB Handover
b)Inter eNB Handover
X2 Handover
S1 Handover
3.Inter Frequency Handover
4.IRAT Handover
GSM
UMTS
CDMA(EVDO)

HANDOVER EVENTS

HANDOVER OPTIMIZATIO
There are three ways of optimizing handovers in LTE:
a)Via the modification of the parametersa3offsetandhysteresisa3
b)By changing the parametertimetotriggereventa3
c)Via the modification of the parameterfiltercoefficientfor event a3.
Definitions:
Event A3is defined as a triggering event when a neighbor cell becomes an offset
better than the serving cell. The UE creates a measurement report, populates the
triggering details and sends the message to the serving cell. The parameters that
define the trigger include:
a3offset: This parameter can be found in 3GPP 36.331. It configures the RRC IE a3Offset included in the IE reportConfigEUTRA in the Measurement Configuration IE. The
value sent over the RRC interface is twice the value configured, that is, the UE has to
divide the received value by 2.The role of the offset in Event A3 is to make the serving
cell look better than its current measurement in comparison to the neighbor.
Hysteresisa3: The role of the hysteresis in Event A3 is to make the measured
neighbor look worse than measured to ensure it is really stronger before the UE decides
to send a measurement report to initiate a handover.
timetoTriggera3: The role of ttt in Event A3 is to avoid a ping-pong effect.
CellIndividualoffsetEutran: This parameter is applied individually to each neighbor
cell with load management purposes. The higher the value allocated to a neighbor cell,

HANDOVER OPTIMIZATION
Based on the picture below, event A3 will trigger when:
RSRP(target) > RSRP(Serving) +a3offset + hysteresisa3 cellindividualoffsetEutran
And this condition is valid for timetotriggera3.

HANDOVER OPTIMIZATION
At the expiration oftimetotriggera3, if the UE does not receive an RRC connection
reconfiguration message (handover command) from the eNodeB, then it will start a
timer calledreportingintervala3. At the expiration of this timer, if the conditions
for event A3 are still met and the eNodeB has not responded, then another
measurement report will be sent to the eNodeB. This process will continue until the
eNodeB responds or until a number of measurement reports given by the
parameterreportingamounthave been sent.
Examples:
The table below assumes thatcellindividualoffsetEutranis not used and shows
when the eventa3offset is triggered and when the UE ceases sending measurement
reports.

As it can be seen from the table, eventa3 triggers ata3offset+hysteresisa3

However!!!After the first measurement result, subsequent measurement results can
be sent if the RSRP of the neighbor cell is onlya3offset-hysterisisa3dB stronger!
Hence, weaker neighbors could be reported in the measurements sent by the UE (this

HANDOVER OPTIMIZATION
a)a3offsetshould always be larger thanhysteresisa3if we want UE to handover to cells with an
RSRP at least equal to the RSRP value of its serving cell.
b) Ensuringa3offset > hysteresisa3avoids ping-pongs
c) The higher the value ofa3offset+hysteresisa3the more we drag the calls to neighboring cells.
This is very useful where we have coverage holes (not a one to one deployment scenario on top of
3G cells)
d) The smaller the value ofa3offset+hysteresisa3the faster we release the calls to neighboring
cells. This is useful in those scenarios where a large number of LTE cells exists in a given
geographical area.
e) The higher the value ofa3offset+hysteresisa3the more difficult we make it for calls do
handover to other cells.
Remember, eventa3 triggers ata3offset+hysteresisa3.Subsequent message reports are sent
when the RSRP of the neighbor cell isa3offset-hysteresisa3(See figure below).