Topic: LTE KPIs Tutorial
Target audience: Optimization & Tuning
2012-06-26 | Page 1
Abstract
The purpose of this document is to provide a description on the LTE
KPIs and give troubleshooting guidelines to under - performing
EUTRAN KPIs in the areas of Accessibility, Retainability, Integrity,
Mobility and Availability.
2012-06-26 | Page 2
Contents
1
1.1
2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
3
3.1
3.1.1
3.1.2
3.1.3
4
4.1
Introduction
Purpose of the document
Introduction of Ericsson KPI & Counters
KPI Name
Importance
Scope
Time Resolution
Counters MO Class (Managed Object)
Counters Type
Target Value
Unit
KPI Description
KPI Collection and Process Tools
ITK Overview
Functionality
Architecture
Software Platform
Aggregation on Object and Time
Object Aggregation
2012-06-26 | Page 3
Contents cont…
4.2
4.3
5
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.1.7
5.1.8
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
Time Aggregation
Instruction on the Aggregation
Troubleshooting Guidelines
Accessibility
Random Access
RRC Connection Establishment
RRC Connection Establishment Counters
Initial E-RAB Establishment Success Rate
Initial E-RAB Establishment Success Rate Counters
Added E-RAB Establishment Success Rate
Added E-RAB Establishment Success Rate Counters
S1 Signaling Connection Establishment
Retainability
UE Session Time
MME Initiated E-RAB & UE Context Release with counters Description
RBS Initiated E-RAB & UE Context Release with counters Description
MME & RBS Initiated E-RAB Release Flow Chart
MME & RBS Initiated UE Context Release Flow Chart
2012-06-26 | Page 4
Contents cont…
5.3
5.3.1
5.3.2
5.3.3
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5
5.4.6
5.4.7
5.4.8
5.5
5.5.1
Integrity
EUTRAN Latency KPIs
EUTRAN Throughput KPIs
EUTRAN Packet Loss KPIs
Mobility
Intra RBS Handover Preparation & Execution
X2 Based Handover Preparation & Execution
S1 Based Handover Preparation & Execution
Intra Frequency Handover Preparation & Execution Counters
Inter Frequency Handover Preparation & Execution Counters
Intra-frequency intra-LTE S1 & X2 Handover Flowchart
Inter-frequency intra-LTE S1 & X2 Handover Flowchart
ANR Counters & counter details
Availability
Partial cell availability (node restarts excluded)
2012-06-26 | Page 5
1 Introduction
1.1
Purpose of the document
This document 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.
Monitoring the RAN performance is a very important task for network engineers,
operation and maintenance personnel and management.
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
2012-06-26 | Page 6
2 Introduction of Ericsson KPI & Counters
The “LTE KPIs Description” documents are written with the below format:
2.1 KPI Name
KPI is short for Key Performance Indicator. In general the name of the KPI is stated in
the title of the subparagraph. Here, a sort of ‘short’ name/acronym, is used. The
intent is to provide a clear terminology to reference to each of the proposed
performance indicators.
2.2 Importance
Value: High, Medium, Low. It signifies how critical of the particular KPI to the
network performance.
2012-06-26 | Page 7
2 Introduction of Ericsson KPI & Counters
Cont…
2.3 Scope
Value: Cell, eNodeB or Cluster of cells. It shows the KPI available to be view per cell, per
eNodB or Cluster of cells.
2.4 Time Resolution
Value: 1 hour, 24 hours. Observation period for the particular KPI.
2.5 Counters MO Class (Managed Object)
All the radio network counters from the eNodB (and RBS) are reported from one
Managed Object (MO) Class.
2.6 Counters Type
Counters are used to collect PM statistics Data. Different types of counters are used to
collect observable data.
The are 9 different types of counters available:
2012-06-26 | Page 8
2 Introduction of Ericsson KPI & Counters
Cont…
Peg – a counter that is increase by 1 at each occurrence of a specific activity. Eg:pmBadCovEvalReport
Gauge – a counter that can be increased or decreased depending on the activity in
the system. Eg:- pmPrbUsedDlCcch
Accumulator – a counter that is increased by the value of a sample. It indicates the
total sum of all sample values taken during a certain time. The name of an
accumulator counter begins either with pmSum or pmSumOfSamp. Eg:pmRrcConnLevSum
Scan – a counter that is increased by 1 each time the corresponding accumulator is
increased. It indicates how many samples have been read, and added to the related
accumulator counter. A scan counter can therefore be considered a specific kind of
peg counter. Due to these types of counters, it is possible to get the average value of
all samples by dividing the accumulator counter by the scan counter. The name of a
scan counter begins with pmSamples or pmNoofSamp. Eg:- pmRrcConnLevSamp
2012-06-26 | Page 9
2 Introduction of Ericsson KPI & Counters
Cont…
PDF – a list of range values. A value is sampled (read) periodically. If the value falls
within a certain range, the range counter for that range is increased. All range counter
values are collected and stored in ROP file at the end of the each reporting period.
For example, if SIR values are split into three range : Range1 = [-11 dB to -4 dB],
Range2 = [-4 dB to +4 dB], Range3 = [+4 dB to +20 dB], and a value is read every 3
minutes over a 15 minutes period (values = -10, -3, +5, +5, +6), then the three Range
Counters are reported as RangeCounter1 = 1, RangeCounter2 = 1, RangeCounter3 = 3.
Eg:- pmRadioRecInterferencePwr
Discrete distributed measurements (DDM) – a series of values recorded during a
reporting period. Each series of values may be one of the following measurement
types:
• Accumulated over a measurement period and read at the end of each
measurement period (a gauge or peg counter)
• Averaged over the duration of a measurement period
• Read at a specific time (the measurement time), within the measurement period (at
a specific frame)
At the end of a series of consecutive measurement periods (the reporting period) all
measurement values are collected and stored in a ROP file.
2012-06-26 | Page 10
2 Introduction of Ericsson KPI & Counters
Cont…
For example, if a SIR value is read every 3 minutes over a 15-minutes period (value =
-10, -3, +5, +5, +6), then 5 DDM measurements are reported as MEa1 = -10, Meas2 =
-3, MEass3 = 5, Meas4 = 5, Meas5 = 6.
Calculated – a counter whose value is determined by other counters. The calculation
is performed in the RANOS Statistics database. The ROP files are opened in order to
be transferred into the database and the calculations are made by the database itself
during this process. This means that these counters are not available when the
Statistics Database is not present.
TrigACC - a counter whose value is a sum of all values accumulated during the ROP at
the occurrence of the defined trigger.
TrigSCAN - a counter whose value is a number of occurrences of the defined trigger
during the ROP.
2012-06-26 | Page 11
2 Introduction of Ericsson KPI & Counters
Cont…
2.7 Target Value
Target values are intentionally blank for now and will be updated with values obtained
from live networks
2.8 Unit
The unit of measurement.
2.9 KPI Description
In every KPI description field in document, when possible, every effort is made to
follow the structure below:
Par. 1 Description of the meaning of the KPI and how the formula is built;
Par. 2 Description of all the counters included in the formula and their triggering
conditions;
Par. 3 Eventual comments or notes about KPI inconsistency or statistical limit.
Par. 4 Some tips about aggregation method.
2012-06-26 | Page 12
3 KPI Collection and Process Tools
There are various kinds of KPI collection and processing tools that can be used, for
example ERTT (Ericsson RF Tracking Tool), ITK and etc.
3.1
ITK Overview
3.1.1
Functionality
The purpose of ITK is to provide Ericsson engineers with tools to assist in support and
operations of LTE radio access networks. In addition, the tools should make data
available that can be fed back into the design organization to aid in improvement of
the Ericsson LTE RAN products. The tools provide the following basic areas of
functionality:
• Ability to fetch, process and store statistical counter-based data from the network
elements
• Ability to fetch, process and store event based data from the network elements
• Ability to fetch, process and store configuration data from the network elements
2012-06-26 | Page 13
3 KPI Collection and Process Tools
Cont…
• Flexible web based reporting based on the counter, event and configuration data.
The goals are to provide:
 Web based reporting of network performance KPIs (Key Performance
Indicators).
 eNodeB downtime and restart statistics.
 The architecture provides for the user to define many different kinds of web
based report, using the data fetched into the system.
3.1.2
Architecture
ITK is designed to provide access to the network data from the Ericsson ECN, to allow
Ericsson engineers to access the data. The following elements make this possible:
• Network ITK Tools Server (NITS)- This server is installed directly on the customer’s
O&M network and has IP contact with all managed nodes. This server is tasked with
fetching data from the nodes.
2012-06-26 | Page 14
3 KPI Collection and Process Tools
Cont…
• Ericsson ITK Tools Server (EITS)- This server is installed on the Ericsson Corporate
network (ECN) and has contact with the NITS via an RSG (Remote Support Gateway)
or other form of gateway. Data fetched by the NITS is processed into a database on
the EITS. The EITS provides a web interface which may be accessed by Ericsson
engineers. A single EITS may service multiple customer’s networks (depending on
the number of nodes and the processing capabilities of the server). It is envisaged
that EITS may be installed and maintained on a regional basis by the GSDCs.
• Central ITK Tools Server (CITS)- This server stores aggregated data from multiple
EITS and provides overview level statistics, useful to PLM and the product units. It is
envisaged that PLM and/or PDUs will maintain CITS instances.
2012-06-26 | Page 15
3 KPI Collection and Process Tools
Cont…
3.1.3
Software Platform
The diagram below describes the ITK software platform.
Figure 1 - ITK Architecture
The underlying platform elements (colored light blue in figure 1 above) are installed
as part of the operating system. The following elements are Required:
2012-06-26 | Page 16
3 KPI Collection and Process Tools
Cont…
• Linux Operating System. The ITK project supports the installation of ITK on the
following Linux distributions.
o Centos 4.3 (www.centos.org). Centos is a clone of Red Hat Enterprise Linux.
o Red Hat Enterprise Linux (RHEL – www.redhat.com).
More information on ITK can be found in the link
http://utran01.epa.ericsson.se/itkwiki/ItkProject
2012-06-26 | Page 17
4 Aggregation on Object and Time
KPIs can be correlated to each other or related to elements in the network topology.
The correlation to a certain part of the network topology is often called the
aggregation level. It is important to select the correct aggregation of data to provide
meaningful results for analysis. In brief the aggregation can be based on object and
time.
4.1 Object Aggregation
Object Aggregation is the aggregation of data of lower level Objects to higher level
Objects. The aggregation is based on the topology of the network configuration. The
aggregation would enable the network to be characterized from the individual NE
perspective.
4.2 Time Aggregation
Time Aggregation is the process of aggregating data from lower resolutions to a
higher resolution. Since the data resolution is large, it is necessary to aggregate it to
a higher resolution to save storage space.
2012-06-26 | Page 18
4 Aggregation on Object and Time
Cont…
Aggregation of data based on time provides a snapshot of data at different
resolutions. These resolutions typically include data at Quarter, Hour, Day, Week and
Month and are referred to as Basic or Standard resolutions. However, it is also possible
to have operator definable aggregation period.
The following basic time aggregation steps exist by default:
2012-06-26 | Page 19
4 Aggregation on Object and Time
Cont…
4.3 Instruction on the Aggregation
Peg counter- The peg counter can be aggregated on time or cluster basis to derive
the total number of occurrences of a specific event.
Accumulator- The accumulator counter can be aggregated on time or cluster to
derive the sum of the values over time or area.
Scan- The scan counter is used mainly to derive the average value of the
corresponding accumulator sample. E.g. pmSumMeasuredLoad gives the sum of
samples of the measured load, that is, every time the processor load is sampled, the
counter is incremented by the sampled load. The average process load is obtained by
dividing the measured load by the scan counter pmSamplesMeasuredLoad. To obtain
the average value on eNodeB basis, individual Accumulator counter from each cell
should be sum first before taking the division by the sum of the individual scan
counter of each cell.
2012-06-26 | Page 20
4 Aggregation on Object and Time
Cont…
PDF measurements- The PDF measurements can be used to derive the minimum,
maximum, mean or percentile (e.g. 90% or 95% percentile) values. The mean value
of the samples is done by [value(range 1) x mean(range1) + value(range 2) x
mean(range2) + .. + value(range n) x mean( range n)] / [ value(range1) +
value(range2) +…+ value(range3)]. The inaccuracy of the computed mean value is
due to the last range value being usually infinite and the uneven size of the defined
range. To obtain the average on cluster basis, need to first sum the values from each
range before multiplexing by the mean of the corresponding range and finally
divided by the total counts. An example is given below to compute the 90 percentile
for the counter MyPDF[i] i=0..N:
2012-06-26 | Page 21
5 Troubleshooting Guidelines
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.
5.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
2012-06-26 | Page 22
5 Troubleshooting Guidelines
Cont…
2012-06-26 | Page 23
5 Troubleshooting Guidelines
Cont…
EUTRAN Accessibility KPIs
2012-06-26 | Page 24
5 Troubleshooting Guidelines
Cont…
5.1.1
Random Access
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
Two types of RA procedures are defined in the standard for FDD
CBRA (Contention Based Random Access)
CFRA (Contention Free Random Access)
The main counters for this scenario are the following:
•pmRaAttCbra
•pmRaSuccCbra
2012-06-26 | Page 25
5 Troubleshooting Guidelines
Cont…
Following figure shows a flowchart for the RA procedure.
2012-06-26 | Page 26
5 Troubleshooting Guidelines
Cont…
5.1.2
RRC Connection Establishment
 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 end-user 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 are used to setup a radio link and new transport connection. The flat
network architecture for LTE removes the requirement for these signaling
procedures.
2012-06-26 | Page 27
5 Troubleshooting Guidelines
Cont…
 In the case of LTE, the initial Non-Access Stratum (NAS) message 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
2012-06-26 | Page 28
5 Troubleshooting Guidelines
Cont…
Figure: RRC Connection Establishment
2012-06-26 | Page 29
5 Troubleshooting Guidelines
Cont…
5.1.3
RRC Connection Establishment Counters
2012-06-26 | Page 30
5 Troubleshooting Guidelines
Cont…
Counter Flowcharts
RRC Connection Setup scenario describes both
successful and unsuccessful attempts to set up a
RRC connection for an originating or terminating
call.
The main counters for this scenario are the
following:
•pmRrcConnEstabAtt
•pmRrcConnEstabAttEm
•pmRrcConnEstabAttHpa
•pmRrcConnEstabAttMta
•pmRrcConnEstabAttMos
•pmRrcConnEstabAttMod
•pmRrcConnEstabFailLic
•pmRrcConnEstabSucc
•pmRrcConnEstabSuccEm
•pmRrcConnEstabSuccHpa
2012-06-26 | Page 31
5 Troubleshooting Guidelines
Cont…
5.1.4
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.
2012-06-26 | Page 32
5 Troubleshooting Guidelines
Cont…
Figure: E-RAB Establishment with Initial Context Setup
2012-06-26 | Page 33
5 Troubleshooting Guidelines
Cont…
5.1.5
Initial E-RAB Establishment Success Rate Counters
2012-06-26 | Page 34
5 Troubleshooting Guidelines
Cont…
5.1.6
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.
Figure : E-RAB Establishment with E-RAB Setup Procedure
2012-06-26 | Page 35
5 Troubleshooting Guidelines
Cont…
5.1.7
Added E-RAB Establishment Success Rate Counters
2012-06-26 | Page 36
5 Troubleshooting Guidelines
Cont…
5.1.8
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.
2012-06-26 | Page 37
5 Troubleshooting Guidelines
Cont…
Figure: S1 Signaling Connection Establishment and counters description
2012-06-26 | Page 38
5 Troubleshooting Guidelines
Cont…
Signaling Connection Setup and E-RAB Establishment
This traffic scenario describes both successful and unsuccessful attempts to set up an
S1 connection and to perform an E-RAB establishment.
The main counters for these scenarios are the following:
•pmS1SigConnEstabAtt
•pmS1SigConnEstabSucc
•pmErabEstabAttAdded
•pmErabEstabAttAddedQci
•pmErabEstabAttAddedPa
•pmErabEstabAttInit
•pmErabEstabAttInitQci
•pmErabEstabAttInitPa
•pmErabEstabFailAddedLic
•pmErabEstabFailInitLic
•pmErabEstabSuccAdded
•pmErabEstabSuccAddedQci
•pmErabEstabSuccAddedPa
•pmErabEstabSuccInit
•pmErabEstabSuccInitQci
•pmErabEstabSuccInitPa
•pmErabEstabFailGbrDlEnb
•pmErabEstabFailGbrUlEnb
•pmUeCtxtEstabAtt
•pmUeCtxtEstabSucc
Below figures show flowcharts for the signaling connection setup and the E-RAB
establishment scenarios.
2012-06-26 | Page 39
5 Troubleshooting Guidelines
Cont…
Figure: E-RAB Establishment with Initial
Context Setup Procedure
2012-06-26 | Page 40
Figure: E-RAB Establishment with E-RAB Setup
Procedure
5 Troubleshooting Guidelines
Cont…
5.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
Admission reject, due to lack of licenses
2012-06-26 | Page 41
5 Troubleshooting Guidelines
Cont…
EUTRAN Retainability KPI
5.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.
2012-06-26 | Page 42
5 Troubleshooting Guidelines
Cont…
Figure: UE Session Time
2012-06-26 | Page 43
5 Troubleshooting Guidelines
Cont…
UE Session Time counter
2012-06-26 | Page 44
5 Troubleshooting Guidelines
Cont…
5.2.2
MME Initiated E-RAB & UE Context Release with counters Description
Figure: MME Initiated E-RAB Release
2012-06-26 | Page 45
5 Troubleshooting Guidelines
Cont…
Figure: MME Initiated UE Context Release
2012-06-26 | Page 46
5 Troubleshooting Guidelines
Cont…
MME Initiated E-RAB & UE Context Release counters
2012-06-26 | Page 47
5 Troubleshooting Guidelines
Cont…
5.2.3
RBS Initiated E-RAB & UE Context Release with counters Description
Figure: RBS Initiated E-RAB Release
2012-06-26 | Page 48
5 Troubleshooting Guidelines
Cont…
Figure: RBS Initiated UE Context Release
2012-06-26 | Page 49
5 Troubleshooting Guidelines
Cont…
5.2.4
MME & RBS Initiated E-RAB Release Flow Chart
E-RAB release scenario describes the steps involved in E-RAB Release.
The main counters for this scenario are the following:
•pmErabRelNormalEnb
•pmErabRelAbnormalEnbActHpr
•pmErabRelAbnormalEnb
•pmErabRelAbnormalEnbActTnFail
•pmErabRelAbnormalEnbAct
•pmErabRelAbnormalEnbActUeLost
•pmErabRelAbnormalEnbActCdt
•pmErabRelMme
•pmErabRelAbnormalEnbActHo
Figure: MME Initiated E-RAB Release Flow Chart
2012-06-26 | Page 50
5 Troubleshooting Guidelines
Cont…
Figure: RBS Initiated E-RAB Release Flow Chart
2012-06-26 | Page 51
5 Troubleshooting Guidelines
Cont…
5.2.5
MME & RBS Initiated UE Context Release Flow Chart
This section describes the flowcharts related to User Equipment (UE) context release.
The main counters for this scenario are the following:
•pmUeCtxtRelNormalEnb
•pmUeCtxtRelAbnormalEnb
•pmUeCtxtRelAbnormalEnbAct
•pmUeCtxtRelAbnormalEnbActCdt
•pmUeCtxtRelAbnormalEnbActHo
•pmUeCtxtRelAbnormalEnbActTnFail
•pmUeCtxtRelAbnormalEnbActUeLost
•pmUeCtxtRelMme
•pmUeCtxtRelMmeAct
•pmUeCtxtRelSCEutra
•pmUeCtxtRelSCCdma
•pmUeCtxtRelSCGsm
•pmUeCtxtRelSCWcdma
2012-06-26 | Page 52
5 Troubleshooting Guidelines
Cont…
Figure: MME Initiated UE Context Release Flow Chart
2012-06-26 | Page 53
5 Troubleshooting Guidelines
Cont…
Figure: RBS Initiated UE Context Release Flow Chart
2012-06-26 | Page 54
5 Troubleshooting Guidelines
Cont…
5.3 Integrity
5.3.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.
2012-06-26 | Page 55
5 Troubleshooting Guidelines
Cont…
Figure: Downlink Latency Measurement
2012-06-26 | Page 56
5 Troubleshooting Guidelines
Cont…
Downlink Latency Counters
2012-06-26 | Page 57
5 Troubleshooting Guidelines
Cont…
5.3.2
EUTRAN Throughput KPIs
The speed at which packets can be transferred once the first packet has been
scheduled on the air interface.
2012-06-26 | Page 58
5 Troubleshooting Guidelines
Cont…
Figure: DL DRB Traffic Volume Measurement
2012-06-26 | Page 59
5 Troubleshooting Guidelines
Cont…
DL DRB Traffic Volume Counters
2012-06-26 | Page 60
5 Troubleshooting Guidelines
Cont…
Figure: UL DRB Traffic Volume Measurement
2012-06-26 | Page 61
5 Troubleshooting Guidelines
Cont…
UL DRB Traffic Volume Counters
2012-06-26 | Page 62
5 Troubleshooting Guidelines
Cont…
5.3.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 in
transmission, for example, discarded by some link layer receiver due to CRC failure).
Downlink Packet Error Loss Rate [%]:
Uplink Packet Loss Rate [%]:
2012-06-26 | Page 63
5 Troubleshooting Guidelines
Cont…
Figure: Downlink Packet Loss Measurement
2012-06-26 | Page 64
5 Troubleshooting Guidelines
Cont…
Figure: Uplink Packet Loss Measurement
2012-06-26 | Page 65
5 Troubleshooting Guidelines
Cont…
Packet Loss Counters
2012-06-26 | Page 66
5 Troubleshooting Guidelines
Cont…
5.4 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.
2012-06-26 | Page 67
5 Troubleshooting Guidelines
Cont…
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
parameters and physical changes.
EUTRAN Mobility Success Rate [%]:
2012-06-26 | Page 68
5 Troubleshooting Guidelines
Cont…
5.4.1
Intra RBS Handover Preparation & Execution
Figure: Intra RBS Handover Preparation
2012-06-26 | Page 69
5 Troubleshooting Guidelines
Cont…
Figure: Intra RBS Handover Execution
2012-06-26 | Page 70
5 Troubleshooting Guidelines
Cont…
5.4.2
X2 Based Handover Preparation & Execution
Figure: X2 Based Handover Preparation
2012-06-26 | Page 71
5 Troubleshooting Guidelines
Cont…
Figure: X2 Based Handover Execution
2012-06-26 | Page 72
5 Troubleshooting Guidelines
Cont…
5.4.3
S1 Based Handover Preparation & Execution
Figure: S1 Based Handover Preparation
2012-06-26 | Page 73
5 Troubleshooting Guidelines
Cont…
Figure: S1 Based Handover Execution:
2012-06-26 | Page 74
5 Troubleshooting Guidelines
Cont…
5.4.4
Intra Frequency Handover Preparation & Execution Counters
Intra Frequency Handover Preparation Counters
2012-06-26 | Page 75
5 Troubleshooting Guidelines
Cont…
Intra Frequency Handover Execution Counters
2012-06-26 | Page 76
5 Troubleshooting Guidelines
Cont…
5.4.5
Inter Frequency Handover Preparation & Execution Counters
Inter Frequency Handover Preparation Counters
2012-06-26 | Page 77
5 Troubleshooting Guidelines
Cont…
Inter Frequency Handover Execution Counters
2012-06-26 | Page 78
5 Troubleshooting Guidelines
Cont…
5.4.6
Intra-frequency intra-LTE S1 & X2 Handover Flowchart
This traffic scenario describes successful and failed intra-frequency intra-LTE S1 and
X2 Handover.
The main counters for this scenario are the following:
•pmHoPrepRejInLicRlcUm
•pmHoExeAttLteIntraF
•pmHoExeSuccLteIntraF
•pmHoPrepRejInLicMultiErab
•pmHoPrepAttLteIntraF
•pmBestCellEvalReport
•pmBadCovEvalReport
•pmHoPrepSuccLteIntraF
•pmHoPrepRejInLicConnUsers
•pmHoPrepRejInLicMob
Following figure show flowcharts for the intra-frequency intra-LTE S1 & X2
Handover scenarios
2012-06-26 | Page 79
5 Troubleshooting Guidelines
Cont…
Figure: Intra-Frequency intra-LTE S1 Handover Scenario
2012-06-26 | Page 80
5 Troubleshooting Guidelines
Cont…
2012-06-26 | Page 81
Figure: Intra-Frequency intra-LTE X2 Handover Scenario
5 Troubleshooting Guidelines
Cont…
5.4.7
Inter-frequency intra-LTE S1 & X2 Handover Flowchart
This traffic scenario describes successful and failed inter-frequency intra-LTE S1 and
X2 Handover.
The main counters for this scenario are the following:
•pmHoExeAttLteInterF
•pmHoExeSuccLteInterF
•pmHoPrepAttLteInterF
•pmHoPrepSuccLteInterF
•pmHoPrepRejInLicConnUsers
•pmHoPrepRejInLicMob
•pmHoPrepRejInLicRlcUm
•pmHoPrepRejInLicMultiErab
•pmBestCellEvalReport
•pmBadCovEvalRepor
Following figure show flowcharts for the inter-frequency intra-LTE S1 & X2 Handover
scenario.
2012-06-26 | Page 82
5 Troubleshooting Guidelines
Cont…
2012-06-26 | Page 83
Figure: Inter-Frequency intra-LTE S1 Handover Scenario
5 Troubleshooting Guidelines
Cont…
2012-06-26 | Page 84
Figure: Inter-Frequency intra-LTE X2 Handover Scenario
5 Troubleshooting Guidelines
Cont…
5.4.8
ANR Counters & counter details
Figure: ANR Counters
2012-06-26 | Page 85
5 Troubleshooting Guidelines
Cont…
ANR counter details
2012-06-26 | Page 86
5 Troubleshooting Guidelines
Cont…
5.5 Availability
5.5.1
Partial cell availability (node restarts excluded)
This KPI measures system performance. Since the KPI is measured by the RBS, it does
not include time when the RBS is down, i.e. node restart time is excluded.
The length of time in seconds that a cell is available for service is defined as cell
availability. Cell availability for a cluster of M number of cells during N reporting
periods can be calculated using the following formula. The counters are on cell level.
2012-06-26 | Page 87
5 Troubleshooting Guidelines
Cont…
Cell Downtime
This traffic scenario describes the steps
involved in the Cell Downtime procedure.
The main counters for this scenario are
the following:
pmCellDowntimeAuto
pmCellDowntimeMan
Figure: flowchart for the Cell Downtime procedure
2012-06-26 | Page 88
2012-06-26 | Page 89