01-LTE KPI Introduction
01-LTE KPI Introduction
01-LTE KPI Introduction
1 KPI Introduction
The traffic measurement data and drive test data are the objective basis of the network
optimization, while the human perception is the subjective basis. It is necessary to trace
and analyze signalling messages to locate problems before these problems are solved. It is
obvious that the traffic measurement data provide a very important method to analyze the
network performance. Especially when there is traffic in the network, the traffic
measurement data provide important references and guide for the network optimization.
The integrity and accuracy of the measurement items and the convenience of operations
will directly affect the efficiency of network optimization. Meanwhile, the quality of
measurement items is also a very important factor to measure the effect of network
optimization.
On the other hand, network operators set much store by the traffic measurement data.
The boss of network operators usually learns and judges the running status of networks
according to the visual data obtained from traffic measurement. These visual traffic
measurement data also provide an important basis for the future network capacity
expansion.
The RRC connection setup procedure is triggered by various different causes as identified
by the establishmentCause field in RRCConnectionRequest message: emergency,
highPriorityAccess, mt (Mobile terminating)-Access, mo (Mobile Originating)-Signaling, and
mo-Data. The UE sets the establishmentCause in accordance with the information received
from upper layers. Causes except mo-signaling are categorized as service-related ones. The
mo-signaling cause is a signaling-related cause.
Establishment Cause
Emergency
TheEmergency cause value is used if the EPS Attach Type within the
Attach Request message is set to EPS Emergency Attach. The Emergency
cause value can also be used if the higher layers within the UE indicate the
requirement to establish emergency bearer services, even when the EPS
Attach Type is not set to EPS Emergency Attach.
High Priority Access
For these NAS procedures initiated by UEs of access class 12, 13 or 14 in
their home country, the RRC establishment cause will be set to "High
priority access AC 11 15". For this purpose the home country is defined
as the country of the MCC part of the IMSI, see 3GPP TS 22.011 [1A].
For these NAS procedures initiated by UE of access class 11 or 15 in their
HPLMN (if the EHPLMN list is not present or is empty) or EHPLMN (if the
EHPLMN list is present), the RRC establishment cause will be set to "High
priority access AC 11 15.
Confidential Information of Huawei. No Spreading Without Permission
LTE eRAN8.1 KPI Introduction
This KPI evaluates the RRC setup success rate in a cell or cluster involved.
According to Reference, the RRC connection setup procedure is triggered by various
different causes as identified by the establishmentCause field in RRCConnectionRequest
message: emergency, highPriorityAccess, mt-Access (Mobile terminating), mo-Signaling
(Mobile Originating), and mo-Data. The UE sets the establishmentCause in accordance
with the information received from upper layers. Causes except mo-signaling are
categorized as service-related ones. The mo-signaling cause is a signaling-related cause.
MO-signaling refers to RRC connection setup request result from Attach,Tracking Area
Update,Detach
The counters measure the number of RRC connection setup requests for different causes in
a cell. The RRC Connection Request message is the first RRC signaling message sent from
the UE to the eNodeB. The corresponding counter are incremented by 1 each time the
eNodeB receives an RRC Connection Request message from the UE. Note: The
L.RRC.ConnReq.Att counter is incremented by 1 when the eNodeB receives the message
for the first time. The counter will not be incremented repeatedly, if the eNodeB receives
the message for multiple times.
The counter measures the number of RRC connection setup attempts in a cell. That is, the
counter measures the number of times that the eNodeB sends an RRC Connection Setup
message to the UE after receiving an RRC Connection Request message from the UE. The
RRC Connection Setup message is an RRC signaling message sent from the eNodeB to the
UE. The message is used to inform the UE of the related configuration information and the
result of the RRC connection setup. the corresponding counter is incremented by 1 each
time the eNodeB sends an RRC Connection Setup message to the UE after receiving an
RRC Connection Request message from the UE.
The counters measure the number of successful RRC connection setups for different causes
in a cell. They refer to the number of RRC Connection Setup Complete messages received
by the eNodeB from the UE. The RRC Connection Setup Complete message is an RRC
signaling message sent from the UE to the eNodeB.
The message is used to inform the eNodeB that the RRC connection setup is completed
and informs the eNodeB of the carried NAS signaling information and the information
about MME and PLMN selections. the corresponding counter is incremented by 1 each
time the eNodeB receives an RRC Connection Setup Complete message from the UE
The purpose of this procedure is to re-establish the RRC connection, which involves the
resumption of the Signaling Bearer 1 operation and the re-activation of security.
Possible Reestablishment Causes in the RRC Connection Reestablishment Request Message:
Handover Failure, Reconfiguration Failure, Other Failure
Number of RRC Connection Reestablishment Requests in a Cell:
The counters measure the number of successful RRC connection reestablishments for
different causes in a cell. The RRC Connection Reestablishment Complete message is an
RRC signaling message sent from the UE to the eNodeB. The message is used to inform the
eNodeB that the RRC connection reestablishment is completed. The corresponding counter
is incremented by 1 each time the eNodeB receives an RRC Connection Reestablishment
Complete message from the UE.
The counters measure the number of RRC connection reestablishment failures for different causes in a cell. The
RRC Connection Reestablishment Reject message is an RRC signaling message sent from the eNodeB to the UE.
The message is used to inform the UE that the reestablishment is rejected by the eNodeB. The corresponding
counter is incremented by 1 each time the eNodeB sends an RRC Connection Reestablishment Reject message
after receiving an RRC Connection Reestablishment Request message from the UE.
As shown in point A in Figure 1, the corresponding counter is incremented each time the
eNodeB sends an RRC Connection Reestablishment Reject message after receiving an RRC
Connection Reestablishment Request message from the UE. The counters are measured as
follows:
The L.RRC.ReEstFail.Rej counter is incremented by 1 each time the eNodeB sends
the RRC connection Reestablishment Reject message
The L.RRC.ReEst.ReconfFail.Rej counter is incremented by 1 each time the eNodeB
receives an RRC Connection Reestablishment Request message from the UE and
the Reestablishment Cause information element of the message
is reconfigurationFailure.
The L.RRC.ReEst.HoFail.Rej counter is incremented by 1 each time the eNodeB
receives an RRC Connection Reestablishment Request message from the UE and
the Reestablishment Cause information element of the message is handoverFailure.
The L.RRC.ReEstFail.ResFail counter is incremented by 1 each time the RRC
connection reestablishment fails due to a failed resource allocation.
The L.RRC.ReEstFail.NoCntx counter is incremented by 1 each time the RRC
connection reestablishment fails because UE contexts are unavailable.
As shown in point A in Figure 2, the L.RRC.ReEstFail.NoReply counter is incremented by 1
each time the eNodeB does not receive an RRC Connection Reestablishment Complete
message from the UE within the specified time.
As shown at point A in Figure 3, the L.RRC.ReEstFail.Disc.FlowCtrl counter is incremented
by 1 each time the cell discards an RRC Connection Reestablishment Request message
from a UE because of flow control
The characteristics describe the packet forwarding treatment that an SDF aggregate
receives edge-to-edge between the UE and the PCEF (see figure 6.1.7-1) in terms of the
following performance characteristics:
1 Resource Type (GBR or Non-GBR);
2 Priority;
3 Packet Delay Budget;
4 Packet Error Loss Rate.
An E-RAB is the access layer bearer for carrying service data of users. The E-RAB setup
success rate in a cell directly represents the capability of the cell to provide E-RAB
connection setups for users
The E-RAB is part of the Evolved Packet Service (EPS) bearer. According to 3GPP TS 23.401,
an E-RAB is one or more Service Data Flows between UE and an EPC.
The E-RAB identity remains unique for the UE even if the UE-associated logical S1-
connection (S1 bearer) is released during periods of user inactivity.
UE-triggered E-RAB setup is triggered by the radio bearer setup. Initial Context Setup
Request messages are exchanged between the eNodeB and the MME. If the E-RAB Setup
Request message or Initial Context Setup Request message requires multiple E-RAB setups
at the same time, specific counters are incremented for each E-RAB.
Packet
Packet
QCI Type Priority Delay Example Service
Error Rate
Budget (ms)
-2
1 GBR 2 100 10 Conversational Voice
-3
2 GBR 4 150 10 Conversational Video
-3
3 GBR 3 50 10 Real Time Gaming
-6
4 GBR 5 300 10 Non-Conversational Voice
Non- -6
5 1 100 10 IMS Signaling
GBR
Non- -6
6 6 300 10 Video, TCP Based
GBR
Non- -3 Voice, Video, Interactive
7 7 100 10
GBR Gaming
Non- -6
8 8 300 10 Video, TCP Based
GBR
Non- -6
9 9 300 10 Video, TCP Based
GBR
The counters measure the number of initial E-RAB setup attempts for each service with a
different QCI ranging from 1 to 9 in a cell. The corresponding counter is incremented by 1
each time the eNodeB receives an INITIAL CONTEXT SETUP REQUEST message from the
MME.
The counters measures the number of successful initial E-RAB setups for each service with
a different QCI ranging from 1 to 9 in a cell. the corresponding counter is incremented by
1 each time the eNodeB sends an INITIAL CONTEXT SETUP RESPONSE message to the
MME. If the INITIAL CONTEXT SETUP RESPONSE message contains multiple successful E-
RAB setups at the same time, the corresponding counter is incremented by 1 according to
the QCI of each service.
... ...
1526726678 L.E-RAB.AttEst.QCI.9 Number of E-RAB setup attempts for the service
with QCI of 9 in a cell
These counters measure the number of E-RAB setup attempts for each service with a
specific QCI ranging from 1 to 9 in a cell. The corresponding counter is incremented by 1
each time the eNodeB receives an E-RAB SETUP REQUEST message or an INITIAL CONTEXT
SETUP REQUEST message from the MME.
........... ..............
1526726683 L.E-RAB.SuccEst.QCI.8 Number of successful E-RAB setups for the
service with QCI of 8 in a cell
1526726685 L.E-RAB.SuccEst.QCI.9 Number of successful E-RAB setups for the
service with QCI of 9 in a cell
The counters measures the number of successful E-RAB setups for each service with a
different QCI ranging from 1 to 9 in a cell. The corresponding counter is incremented by 1
each time the eNodeB sends an E-RAB SETUP RESPONSE message or an INITIAL CONTEXT
SETUP RESPONSE message to the MME. If the E-RAB SETUP RESPONSE message or INITIAL
CONTEXT SETUP RESPONSE message contains multiple successful E-RAB setups at the
same time, the corresponding counter is incremented by 1 according to the QCI of each
service.
Total Number of Successful E-RAB Setups
This counter measures the total number of E-RAB setup attempts in the eNodeB cell. The
corresponding counter is incremented each time the eNodeB receives an E-RAB SETUP
REQUEST message or an INITIAL CONTEXT SETUP REQUEST message from the MME. If the
E-RAB SETUP REQUEST message or INITIAL CONTEXT SETUP REQUEST message requires
multiple E-RAB setups at the same time, the corresponding counter is incremented
repeatedly.
This KPI can be used to evaluate the call setup success rate of all services including the
VoIP service in a cell or a cluster. This KPI is calculated based on the KPI of RRC Setup
Success Rate (Service) and the KPI of ERAB Setup Success Rate (All).
Abnormal E-RAB releases can be classified into the following two scenarios:
Scenario 1: When the eNodeB sends an E-RAB Release Indication message to the MME,
the abnormal E-RAB release counter is incremented if the bearer to be released carries data
and the release cause is not "Normal Release", "Detach", "User Inactivity", "CS Fallback
triggered", "UE Not Available for PS Service", or "Inter-RAT Redirection".
Scenario 2: When the eNodeB sends a UE Context Release Request message to the MME,
the abnormal E-RAB release counter is incremented if the bearer to be released carries data
and the release cause is not "Normal Release", "Detach", "User Inactivity", "CS fallback
triggered", "UE Not Available For PS Service", "Inter-RAT redirection", "Time Critical
Handover", "Handover Cancelled".
The counters measure the number of normal E-RAB releases for each service with a
different QCI ranging from 1 to 9 in a cell.
As shown in point A in Figure 1, the corresponding counter is incremented by 1 each time
the eNodeB receives an E-RAB RELEASE COMMAND message from the MME and the
Release Cause information element is Normal Release, Detach, User Inactivity, or cs fallback
triggered. If the E-RAB RELEASE COMMAND message requires multiple E-RAB releases at
the same time, the corresponding counter is incremented by 1 according to the QCI of
each service.
As shown in point A in Figure 2, the eNodeB releases all E-RABs of the UE after receiving a
UE CONTEXT RELEASE COMMAND message from the MME. If the Release Cause
information element of the UE CONTEXT RELEASE COMMAND message is Normal Release,
Detach, User Inactivity, or cs fallback triggered, the corresponding counter is incremented
by 1 according to the QCI of each service.
This counter measures the total number of E-RAB normal releases in the eNodeB cell.
The corresponding counter is incremented by 1 each time the eNodeB receives an E-RAB
RELEASE COMMAND message from the MME and the Release Cause information element
is Normal Release, User Inactivity, Detach, or cs fallback triggered.
The eNodeB releases all E-RABs of the UE after receiving a UE CONTEXT RELEASE
COMMAND message from the MME. If the Release Cause information element of the UE
CONTEXT RELEASE COMMAND message is Normal Release, User Inactivity, Detach, or cs
fallback triggered, the counter is incremented by 1 repeatedly.
Number of normal E-RAB releases for PTT services
Counter ID Counter Name Description
1526736858 L.E-RAB.NormRel.QCI.PTT Number of normal E-RAB releases for PTT
services in a cell
The counters measure the number of abnormal E-RAB releases due to different causes in a
cell. An E-RAB is the access layer bearer for carrying service data of users. The E-RAB
release is a process of releasing the access layer bearer resources of users.
This counter measures the total number of abnormal E-RAB releases in the eNodeB cell.
The corresponding counter is incremented each time the eNodeB receives an E-RAB
RELEASE COMMAND message from the MME and the Release Cause information element
is not Normal Release, User Inactivity, Partial Handover, Handover triggered, successful
handover, or cs fallback triggered. If the E-RAB RELEASE COMMAND message requires
multiple E-RAB releases at the same time, the corresponding counter is incremented
repeatedly.
The eNodeB releases all E-RABs of the UE after receiving a UE CONTEXT RELEASE
COMMAND message from the MME. If the Release Cause information element of the UE
CONTEXT RELEASE COMMAND message is not Normal Release, User Inactivity, Partial
Handover, Handover triggered,successful handover, or cs fallback triggered, the counter is
incremented repeatedly.
The corresponding counter is incremented by 1 each time the eNodeB sends an E-RAB
RELEASE INDICATION message to the MME and the Release Cause information element is
not Normal Release, User Inactivity, Partial Handover, Handover triggered, successful
handover, or cs fallback triggered. If the E-RAB RELEASE INDICATION message requires
multiple E-RAB releases at the same time, the corresponding counter is incremented
repeatedly.
The eNodeB releases all E-RABs of the UE after sending a UE CONTEXT RELEASE REQUEST
message to the MME. If the Release Cause information element of the UE CONTEXT
RELEASE REQUEST message is not Normal Release, User Inactivity, Partial Handover,
Handover triggered, successful handover, or cs fallback triggered, the counter is
incremented repeatedly.
This KPI can be used to evaluate the intra/inter-frequency Handover out success rate in a
cell or a cluster. The intra-frequency handover (HO) includes both inter-eNodeB and intra-
eNodeB.
The intra/inter-frequency handover (HO) includes both inter-eNodeB and intra-eNodeB
scenarios.
During a handover where the source cell and target cell are controlled by the same
eNodeB, as shown in point B, the corresponding counter is incremented by 1 each time
the eNodeB sends an RRC Connection Reconfiguration message to the UE. The counters
are measured as follows:
If the source cell and target cell work at the same frequency, the
L.HHO.IntraeNB.IntraFreq.ExecAttOut counter is incremented by 1.
If the source cell and target cell work at different frequencies, the
L.HHO.IntraeNB.InterFreq.ExecAttOut counter is incremented by 1.
As shown in point C , the corresponding counter is incremented each time the eNodeB
receives an RRC Connection Reconfiguration Complete message from the UE and the
subsequent operations are successful. The counters are measured as follows:
If the source cell and target cell are at the same frequency, the
L.HHO.IntraeNB.IntraFreq.ExecSuccOut counter is incremented by 1.
If the source cell and target cell are at different frequencies, the
L.HHO.IntraeNB.InterFreq.ExecSuccOut counter is incremented by 1.
During such a handover where the source cell and target cell are controlled by different
eNodeBs, as shown in point B in the figure above, the corresponding counter is
incremented each time the source eNodeB sends an RRC Connection Reconfiguration
message to the UE after receiving a HANDOVER REQUEST ACKNOWLEDGE from the target
eNodeB or receiving a HANDOVER COMMAND message from the MME. The counters are
measured as follows:
If the source cell and target cell work at the same frequency, the
L.HHO.IntereNB.IntraFreq.ExecAttOut counter is incremented by 1.
If the source cell and target cell work at different frequencies, the
L.HHO.IntereNB.InterFreq.ExecAttOut counter is incremented by 1.
As shown in point C , the corresponding counter is incremented each time the source
eNodeB receives a UE CONTEXT RELEASE message from the target eNodeB or a UE
CONTEXT RELEASE COMMAND message from the MME. The counters are measured as
follows:
If the source cell and target cell are at the same frequency, the
L.HHO.IntereNB.IntraFreq.ExecSuccOut counter is incremented by 1.
If the source cell and target cell are at different frequencies, the
L.HHO.IntereNB.InterFreq.ExecSuccOut counter is incremented by 1.
During such a handover where the source cell and target cell are controlled by different
eNodeBs, as shown in point B in the figure above, the corresponding counter is
incremented each time the source eNodeB sends an RRC Connection Reconfiguration
message to the UE after receiving a HANDOVER REQUEST ACKNOWLEDGE from the target
eNodeB or receiving a HANDOVER COMMAND message from the MME. The counters are
measured as follows:
If the source cell and target cell work at the same frequency, the
L.HHO.IntereNB.IntraFreq.ExecAttOut counter is incremented by 1.
If the source cell and target cell work at different frequencies, the
L.HHO.IntereNB.InterFreq.ExecAttOut counter is incremented by 1.
As shown in point C , the corresponding counter is incremented each time the source
eNodeB receives a UE CONTEXT RELEASE message from the target eNodeB or a UE
CONTEXT RELEASE COMMAND message from the MME. The counters are measured as
follows:
If the source cell and target cell are at the same frequency, the
L.HHO.IntereNB.IntraFreq.ExecSuccOut counter is incremented by 1.
If the source cell and target cell are at different frequencies, the
L.HHO.IntereNB.InterFreq.ExecSuccOut counter is incremented by 1.
This KPI can be used to evaluate the handover in success rate in a cell or a cluster.
The HO includes both inter-eNodeB and intra-eNodeB scenarios.
This KPI provides the percentage of time of a cell in order to evaluate the degradation of
the network performance caused by the unavailable cells in busy hours on the radio
network.
Duration of Cell Unavailability
The counters measure the duration of cell unavailability due to human factors or non-
human factors. Human factors refer to operation maintenance, include the operator
execute the command on LMT(Local Maintenance Terminal): block cells or de-active
cell.Non-human factors refer to other reasons except operation maintenance, mainly
include: board inner fault, The CPRI link is faulty, The baseband processing unit carrying
services is faulty, The transmit/receive channel of the RF unit is faulty, transport resource
for control plane (S1 signaling link) or user plane (IP path) is unavailable, The license
resources are insufficient, the clock resources are unavailable.
The duration of cell unavailability is sampled every five seconds. If a cell is unavailable, the
corresponding counter is incremented by five at each sampling point accordingly. At the
end of a measurement period, the sum of these sampling results is reported.
This KPI consists of two sub-KPIs: uplink resource block (RB) utilizing rate and downlink RB
utilizing rate. These two sub-KPIs can be used to evaluate the busy-hour DL and UL RB
utilizing rate in each cell or cluster.
The available RB for DL/UL is fixed value according to the system bandwidth.
The uplink PRBs in a cell are occupied by the PUSCH,PRACH and PUCCH in frequency
division mode, with those PRBs at both ends being used by the PUCCH and others in the
middle being used for the PUSCH and PRACH. The total number of PRBs used by the
PUCCH,PRACH and PUSCH is the number of used uplink PRBs. The counter measures the
average number of used uplink PRBs in a cell. It is used to analyze the usage of uplink PRBs.
Formula: None
Unit: bit
Formula: None
Unit: bit
Unit:
Unit:ms
Receive Duration of Uplink PDCP SDUs in a Cell
Counter ID Counter Name Description
This KPI evaluates the cell downlink average throughput when there are data transferring
at downlink. It reflects the cell capacity.
Unit: kbit/s
Counters
Counter ID Counter Name Description
1526728261 L.Thrp.bits.DL Total downlink traffic volume for PDCP SDUs
in a cell
Description
The total bits of successfully received signaling SDUs on SRBs at the PDCP
layer are sampled per second. At the end of a measurement period, the
sum of these sampling results is used as the value of the counter.
Measurement Points
The total bits of successfully received signaling SDUs on SRBs at the PDCP
layer are sampled per second. At the end of a measurement period, the
sum of these sampling results is used as the value of the counter.
FormulaNone
Unitbit
Description
The counter measures the total duration of downlink data transmission in a
cell.
Measurement Points
The duration of downlink data transmission in a cell is sampled per
millisecond. If there is downlink data transmission within a sampling period,
the sampling result is 1 ms. At the end of a measurement period, the sum
of these sampling results is used as the value of the
L.Thrp.Time.Cell.DL.HighPrecision counter.
The internal timer of the eNodeB has a deviation of one period, and
therefore the measurement result of the counter has a deviation.
Formula: None
Unit: ms