Nokia Multivendor Optimization Development Project

Nokia Multivendor Optimization
Development Project
Huawei eRAN Performance Analysis Guideline, with Nokia NPM

Hexamatics Servcomm Sdn Bhd
28-6-2017
1 © 2017 Nokia
Huawei eRAN Performance
Analysis Guideline, with Nokia
NPM
Hexamatics Servcomm Sdn Bhd
28-6-2017
2 © 2017 Nokia
Contents
• eRAN Performance KPI Overview
• Accessibility
• Retainability
• Mobility
• Service Integrity
• Utilization
• Availability
• Traffic
• VoLTE
• SRVCC
• Counter Activation
• Counter Query
• NPM4GS
3 © 2017 Nokia
eRAN Performance KPI Overview
4 © 2017 Nokia
The quality of network performance is mainly evaluated by KPI (Key Performance Index)
There are 2 types of KPI’S
1. Drive Test KPI/Stationary Test : Some KPI’S should be attained by drive test, such as coverage KPI, Quality KPI, Latency KPI etc. The measurement results
are coming from drive test tools only.
2. Performance Measurement KPI : Most of the KPI’S are attained by this approach, such as RRC Success rate, Handover Success rate, etc. these KPI’S are
coming from enodeB Performance statistics. The measurement results are coming from M2000, PRS etc.
In this module, we will be discussing on OSS & Performance Measurement KPI’s.

The signaling flow and measurement points are included to help user better understand the performance KPI and troubleshooting.
Two chapters, namely Counter Activation & Counter Query , have been included in this document which provides details on the method to activate counter via
Huawei iManager U2000 and the way to query Performance Counter.
5 © 2017 Nokia
Major KPI’S which are used in daily optimization activity are given below. The counters and formulas for these KPI’S will be explained in KPI Classes.
The KPI sheet (HL6 deliverable attached) contains information on all the KPIS in LTE and VoLTE. It also contains the reports to check for the particular KPI Class.
For More detail information on respective counters and KPI sub classes, Pls. refer to the sheet.
RRC Setup Success Rate (Service/Signaling)

1) Accessibility S1SIG Connection Setup Success Rate
E-RAB Setup Success Rate
Call Setup Success Rate
Call Drop Rate (VoIP)

Service Drop Rate (All)
2) Retainability Service Drop Rate (Always Online)
Minutes Per Drop (All/VoIP)
Major Performance KPI

Intra-Frequency Handover Out Success Rate (All/VoIP)
Inter-Frequency Handover Out Success Rate (All/VoIP)
3) Mobility Inter-FDD TDD Handover Out Success Rate (All/VoIP)
Intra-RAT Handover In Success Rate
Inter-RAT Handover Out Success Rate (LTE to WCDMA/GSM)
CSFB Preparation / Success Rate (LTE to WCDMA/GSM)
Resource Block Utilizing Rate

4) Utilization Uplink Preschedule Resource Block Occupied Rate
Average CPU Load
Note: Pls. refer to excel HL6 KPI Reference Summary.

HL6 KPI reference
summary
6 © 2017 Nokia
eRAN Performance KPI Overview (Contd.)
Major KPI’S which are used in daily optimization activity are given below. The counters and formulas for these KPI’S will be explained
in KPI Classes.
User Downlink/Uplink Average Throughput

Service Downlink/Uplink Average Throughput
5) Service Integrity Cell Downlink/Uplink Average Throughput
Downlink/Uplink Packet Loss Rate (All/VoIP)
Major Performance KPI 6) Availability Radio Network Unavailable Rate
Radio Bearers
7) Traffic Downlink/Uplink Traffic Volume
Average User Number
Maximum User Number
7 © 2017 Nokia
Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• SRVCC
• Counter Query
• NPM4GS
8 © 2017 Nokia
Accessibility
9 © 2017 Nokia
Introduction
Accessibility KPIs are used to measure the probability whether services requested by a user can be accessed within specified tolerances in the given operating
conditions. The service provided by the E-UTRAN is defined as EPS/ERABs. Radio Resource Control (RRC) connection and System Architecture Evolution
(ERAB) setup are the main procedures for accessibility KPIs.
The accessibility KPIs can be calculated per cell or cluster. The KPIs at the cluster level are calculated by aggregating all cell counters of the same cluster.
10 © 2017 Nokia
Accessibility KPIs
• Accessibility KPIs are used to measure the probability that a user accesses the network and requests services in the given operating conditions.
• Radio Resource Control (RRC) connections and System Architecture Evolution (SAE) setups are the main procedures whose performance is measured by
accessibility KPIs.
• Successful attempts compared with total number of attempts for the different parts of the E-RAB establishment.
Accessibility KPIs includes:
• RRC Setup Success Rate (Service)

• RRC Setup Success Rate (Signaling)
• S1SIG Connection Setup Success Rate
• E-RAB Setup Success Rate (VoIP)
• E-RAB Setup Success Rate (All)
• Call Setup Success Rate
11 © 2017 Nokia
RRC Setup Success Rate (Service)
This KPI evaluates the RRC setup success rate using service-related causes in a cell or radio network. RRC connection setup procedure is triggered by different
causes, which are identified in the "establishmentCause" field in an RRC Connection Request message as emergency, highPriorityAccess, mt-Access, mo-
Signaling, mo-Data, or delayTolerantAccess-v1020. The UE sets the establishmentCause in accordance with the information it receives from upper layers. The
mo-signaling cause is a signaling-related cause.
The RRC Setup Success Rate (Service) KPI is calculated based on the counters measured at the eNodeB when the eNodeB receives an RRC Connection
Request message from the UE, as shown in Figure 1. The number of RRC connection attempts is collected by the eNodeB at measurement point A, and the
number of successful RRC connections is counted at measurement point C.
RRC Setup Success Rate (Service)
Name RRC Setup Success Rate (Service)
Object Cell or radio network
Formula RRCS_SRservice = (RRCConnectionSuccessservice/RRCConnectionAttemptservice) x 100%
Associated RRC Setup Success Rate (Service)

Counters =((L.RRC.ConnReq.Succ.Emc + L.RRC.ConnReq.Succ.HighPri + L.RRC.ConnReq.Su
cc.Mt + L.RRC.ConnReq.Succ.MoData + L.RRC.ConnReq.Succ.DelayTol)/
(L.RRC.ConnReq.Att.Emc + L.RRC.ConnReq.Att.HighPri + L.RRC.ConnReq.Att.Mt
+ L.RRC.ConnReq.Att.MoData + L.RRC.ConnReq.Att.DelayTol)) x 100%
Unit/Range Percentage (%)
12 © 2017 Nokia
RRC Setup Success Rate (Signaling)
The RRC Setup Success Rate (Signaling) KPI indicates the RRC setup success rate of the signaling-related cause (mo-signaling) in a cell or radio network.
Like the RRC Setup Success Rate (service), the RRC Setup Success Rate (Signaling) KPI is used to calculate the RRC setup success rate only when the
“EstablishmentCause" field is set to mo-signaling in a cell or radio network.
Name RRC Setup Success Rate (Signaling)

Formula RRCS_SRsignaling = (RRCConnectionSuccesssignaling/RRCConnectionAttemptsignaling) x 100%
Associated Counters RRC Setup Success Rate (Signaling) =(L.RRC.ConnReq.Succ.MoSig/L.RRC.ConnReq.Att.MoSig) x
100%
Table 1: RRC Setup Success Rate (Signaling)
13 © 2017 Nokia
S1SIG Connection Setup Success Rate
This KPI includes counters such as the number of setup attempts of S1 signaling connections related to UEs and the number of successful setups of S1
signaling connections related to Ues.
The S1SIG Connection Setup Success Rate KPI indicates the success rate of signaling connection setups over the S1 interface.
The number of setup times of S1 signaling connections related to UEs is incremented by 1 each time when the eNodeB sends an INITIAL UE MESSAGE to
the MME or receives the first message from the MME. INITIAL UE MESSAGE is the first S1 message that the eNodeB sends to the MME. It contains the
NAS configuration information related to UEs, based on which the MME sets up S1 signaling connections for UEs. The first S1 message sent by the MME
may be INITIAL CONTEXT SETUP REQUEST, DOWNLINK NAS TRANSPORT, or UE CONTEXT RELEASE COMMAND. Receiving any of these
messages indicates that the S1 signaling connection is set up successfully.
S1SIG Connection Setup Success Rate:
Name S1SIG Connection Setup Success Rate

Object Cell/Radio Network
Formula S1SIGS_SR =
(S1SIGConnectionEstablishSuccess/S1SIGConnectionEstablishAttempt) x 100%
Associated S1SIG Connection Setup Success Rate
Counters =(L.S1Sig.ConnEst.Succ/L.S1Sig.ConnEst.Att) x 100%
14 © 2017 Nokia
Associated Counters Related to RRC Setup Success Rate
15 © 2017 Nokia
RRC Setup Major Steps
1. RRC Connection Request in a Cell
2. RRC Connection Setup in a Cell
3. Successful RRC Connection Setup in a Cell
4. RRC Setup Failure in a Cell
5. RRC Connection Reestablishment in a Cell
16 © 2017 Nokia <Document ID: change ID in footer or remove> <Change information classification in footer>
RRC Connection Request in a Cell
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. Causes except mo-signaling are categorized as service-related ones. The mo-signaling cause is a signaling-related cause
17 © 2017 Nokia
RRC Connection Request in a Cell (Contd.)
The Following 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.
RRC Connection Request Counters
Counter Definition
L.RRC.ConnReq.Att Number of RRC Connection Request messages received from the UE in a cell, excluding the number of retransmitted
messages
L.RRC.ConnReq.Att.Emc(times) Number of RRC Connection Request messages received from the UE for the emergency cause in a cell
L.RRC.ConnReq.Att.MoSig(times) Number of RRC Connection Request messages received from the UE for the mo-Signalling cause in a cell
L.RRC.ConnReq.Att.Mt(times) Number of RRC Connection Request messages received from the UE for the mt-Access cause in a cell
L.RRC.ConnReq.Att.HighPri(times) Number of RRC Connection Request messages received from the UE for the highPriorityAccess cause in a cell
L.RRC.ConnReq.Att.MoData(times
) Number of RRC Connection Request messages received from the UE for the mo-Data cause in a cell
18 © 2017 Nokia
RRC Connection Setup in a Cell
Number of RRC Connection Setup Attempts in a Cell:
The below 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
RRC Connection Setup Counter
Counter Definition
L.RRC.ConnSetup Number of RRC Connection Setup messages responses to UE in a cell
20 © 2017 Nokia
Successful RRC Connection Setup in a Cell
• These 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
RRC Connection Setup Counters
Counter Definition
L.RRC.ConnReq.Succ Number of RRC Connection Setup Complete messages received from the UE in a cell
L.RRC.ConnReq.Succ.Emc Number of RRC Connection Setup Complete messages received from the UE for the emergency call cause in a cell
Number of RRC Connection Setup Complete messages received from the UE for the highPriorityAccess cause in a
L.RRC.ConnReq.Succ.HighPri cell
L.RRC.ConnReq.Succ.Mt Number of RRC Connection Setup Complete messages received from the UE for the mt-Access cause in a cell
L.RRC.ConnReq.Succ.MoSig Number of RRC Connection Setup Complete messages received from the UE for the mo-Singnalling cause in a cell
L.RRC.ConnReq.Succ.MoData Number of RRC Connection Setup Complete messages received from the UE for the mo-Data cause in a cell
22 © 2017 Nokia
RRC Setup Failure in a Cell
Possible Reasons:
• Resource Allocation failure (Admission Failure)
• No response from UE (Poor Coverage or Transmission Problem
24 © 2017 Nokia
RRC Setup Failure in a Cell (Contd.)
• L.RRC.SetupFail.ResFail counter is incremented by 1 each time the eNodeB sends an RRC Connection Reject message to the UE due to resource
allocation failure after receiving an RRC Connection Request message from the UE.
• L.RRC.SetupFail.NoReply counter is incremented by 1 each time the eNodeB does not receive an RRC Connection Setup Complete message from the
UE within the specified time. Before that, the eNodeB has sent an RRC Connection Setup message to the UE after receiving an RRC Connection
Request message from the UE.
• L.RRC.SetupFail.Rej counter is incremented by 1 each time the eNodeB sends an RRC Connection Reject message to the UE after receiving an RRC
Connection Request message from the UE.
RRC Setup Failure Counters
Counter Definition
L.RRC.SetupFail.ResFail Number of RRC connection setup failures due to resource allocation failures
L.RRC.SetupFail.NoReply Number of RRC connection setup failures due to no responses from the UE
L.RRC.SetupFail.Rej Number of RRC Connection Reject messages sent to the UE in a cell
25 © 2017 Nokia
RRC Connection Reestablishment in a Cell
27 © 2017 Nokia
RRC Connection Reestablishment in a Cell (Contd.)
• Possible Re-establishment Causes in the RRC Connection Reestablishment Request Message: Handover Failure, Reconfiguration Failure, Other Failures
• The counters measure the number of RRC connection re-establishment requests for different causes in a cell. The RRC Connection Reestablishment
Request message is an RRC signaling message sent by the UE. The message is used to recover the RRC signaling connection. The corresponding
counter is incremented by 1 each time the eNodeB receives an RRC Connection Reestablishment Request message from the UE.
• Note: The L.RRC.ReEst.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.
RRC Connection Reestablishment Attempt Counters
Counter Definition
L.RRC.ReEst.HoFail.Att(times) Number of RRC connection reestablishment requests due to failed handovers

L.RRC.ReEst.ReconfFail.Att(times) Number of RRC connection reestablishment requests due to reconfiguration failures
L.RRC.ReEst.Att(times) Number of RRC connection reestablishment requests
28 © 2017 Nokia
Successful RRC Connection Reestablishments in a Cell:
• The counters measure the number of successful RRC connection reestablishments for different causes in a cell. The RRC Connection Re-establishment
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.
RRC Connection Reestablishment Success Counters
Counter Definition
L.RRC.ReEst.Succ Number of successful RRC connection reestablishments

L.RRC.ReEst.ReconfFail.Succ Number of successful RRC connection reestablishments due to a failed reconfiguration
L.RRC.ReEst.HoFail.Succ Number of successful RRC connection reestablishments due to a failed handover
29 © 2017 Nokia
RRC Connection Reestablishment Failures in a Cell:
Figure 1 and Figure 2 explains how the reestablishment failures occur. Possible reasons are given below.
Possible Reasons:
1. RRC Reconfiguration failure
2. Handover Failure
3. Resource Allocation failure
4. No response from UE
5. No Available UE context in eNodeB
30 © 2017 Nokia
Number of RRC Connection Reestablishment Failures in a Cell:
• The corresponding counter is incremented each time the eNodeB sends an RRC Connection Reestablishment Reject message after receiving an RRC
Connection Re-establishment 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 reconfiguration Failure.
• 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 handover Failure.
• 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.
31 © 2017 Nokia
RRC Connection Reestablishment Failure Counters
Counter Definition
L.RRC.ReEst.ReconfFail.Re
j Number of RRC connection reestablishment failures due to a failed reconfiguration
L.RRC.ReEst.HoFail.Rej Number of RRC connection reestablishment failures due to a failed handover
L.RRC.ReEstFail.ResFail Number of RRC connection reestablishment failures due to failed resource allocations
L.RRC.ReEstFail.NoReply Number of RRC connection reestablishment failures due to no responses from the UE
L.RRC.ReEstFail.NoCntx Number of RRC connection reestablishment failures due to unavailability of UE contexts
L.RRC.ReEstFail.Rej Total number of RRC connection reestablishment rejections
32 © 2017 Nokia
Radio Access Bearer (E-RAB)
Type of bearers:
• Default bearer: With default QCI which is specified in HSS
• Dedicated bearer: With dedicated QCI which is negotiated with PDN-GW and PCRF.
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.
E-RAB is divided into two parts:

• Initial E-RAB
• Dedicated E-RAB
33 © 2017 Nokia
E-RAB Setup Success Rate (All)
Description:
The E-RAB Setup Success Rate (All) KPI indicates the success rate of E-RABs for all services including VoIP. Associated counters are E-RAB setup attempts
and successful E-RAB setups.
E-RAB Setup Success Rate (All)
Name E-RAB Setup Success Rate (All)

Formula ERABS_SR = (ERABSetupSuccess/ERABSetupAttempt) × 100%
Associated Counters E-RAB Setup Success Rate (All) =(L.E-RAB.SuccEst /(L.E-RAB.AttEst - L.E-RAB.FailEst.X2AP) ×
100%
Unit/range %
34 © 2017 Nokia
E-RAB Setup Success Rate (VoIP)
Description:
The E-RAB Setup Success Rate (VoIP) KPI indicates the success rate of E-RAB setups for VoIP services.
VoIP services can be identified based on the QCI information carried in the E-RAB setup request message. Generally, the QCI is 1 for VoIP services.
E-RAB Setup Success Rate (VoIP)
Name E-RAB Setup Success Rate (VoIP)

Object Cell / Radio Network
Formula VoIPERABS_SR = (VoIPERABSetupSucces/VoIPERABSetupAttempt) × 100%
Associated Counters E-RAB Setup Success Rate (VoIP) = (L.E-RAB.SuccEst.QCI.1 / (L.E-
RAB.AttEst.QCI.1 - L.E-RAB.FailEst.X2AP.VoIP)) × 100%
Unit/range %
35 © 2017 Nokia
Associated Counters-Initial E-RAB
36 © 2017 Nokia
Initial E-RAB Setup Attempts in a Cell
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.
Initial E-RAB Attempts Counter
Counter Name Description
L.E-RAB.InitAttEst.QCI.1 Number of initial E-RAB setup attempts for the service with QCI of 1-9 in a cell
-9
37 © 2017 Nokia
Successful Initial E-RAB Setups in a Cell
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.
Initial E-RAB success Counter
L.E-RAB.InitSuccEst.QCI.1 Number of successful initial E-RAB setups for the service with QCI of 1-9 in a cell
-9
38 © 2017 Nokia
Associated Counters: Dedicated E-RAB
39 © 2017 Nokia
E-RAB Setup Attempts 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.
Dedicated E-RAB Attempts Counter
L.E-RAB.SuccEst.QCI.1 -9 Number of successful E-RAB setups for the service with QCI of 1-9 in a cell
L.E-RAB.SuccEst Total number of successful E-RAB setup procedures initiated by UEs
40 © 2017 Nokia
Successful E-RAB Setups in a Cell
The counters measure 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.
Dedicated E-RAB success Counter
L.E-RAB.SuccEst.QCI.1 -9 Number of successful E-RAB setups for the service with QCI of 1-9 in a cell
L.E-RAB.SuccEst Total number of successful E-RAB setup procedures initiated by UEs
41 © 2017 Nokia
Call Setup Success Rate
Description:
The Call Setup Success Rate KPI indicates the call setup success rate for all services, including the VoIP service in a cell or radio network. This KPI is
calculated based on the RRC Setup Success Rate (Service) KPI, the S1 Signaling Connection Setup Success Rate KPI, and the E-RAB Setup Success Rate (All)
KPI.
Call Setup Success Rate:
Name Call Setup Success Rate

Formula CSSR = (RRCConnectionSuccessservice/RRCConnectionAttemptservice) x
(S1SIGConnectionEstablishSuccess/S1SIGConnectionEstablishAttempt) x
(ERABSetupSuccess/ERABSetupAttempt) x 100%
Associated Counters Call Setup Success Rate
=((L.RRC.ConnReq.Succ.Emc + L.RRC.ConnReq.Succ.HighPri + L.RRC.ConnReq.Succ.Mt + L.RRC.ConnReq.Suc
c.MoData + L.RRC.ConnReq.Succ.DelayTol)/
(L.RRC.ConnReq.Att.Emc + L.RRC.ConnReq.Att.HighPri + L.RRC.ConnReq.Att.Mt + L.RRC.ConnReq.Att.MoDat
a + L.RRC.ConnReq.Att.DelayTol)) x (L.S1Sig.ConnEst.Succ/L.S1Sig.ConnEst.Att) x (L.E-RAB.SuccEst/(L.E-
RAB.AttEst - L.E-RAB.FailEst.X2AP)) x 100%
42 © 2017 Nokia
Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• SRVCC
• Counter Query
• NPM4GS
43 © 2017 Nokia
Retainability
44 © 2017 Nokia
Retainability
E-RAB Release
There are two types of E-RAB releases in a cell:

• Normal E-RAB release in a cell
• Released with Normal Procedure, the statistics is based on each QCI Index.
• Abnormal E-RAB release in a cell
• Considered as service (Call) drop, the statistics can be based on different release caused and each QCI Index.
• Possible Causes:
• EPC Failure
• Radio Link Failure
• Handover Failure
• Transport Failure
• Network Congestion
45 © 2017 Nokia
Normal E-RAB Release in a Cell
Normal release cause consists of “Normal Release”, ”Detach”, ”User Inactivity”, or ”cs fallback triggered”
46 © 2017 Nokia
Normal E-RAB Release in a Cell (Contd.)
• 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.
• E-RAB Normal Release for service Counter
L.E-RAB.NormRel.QCI.1 -9 Number of normal E-RAB releases for the service with QCI of 1-9 in a cell
47 © 2017 Nokia
Normal E-RAB Release in a Cell (Contd.)
• 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.
• E-RAB Normal release for eNodeB Counter
L.E-RAB.NormRel Total number of normal E-RAB releases by the eNodeB
48 © 2017 Nokia
Abnormal E-RAB Release In A Cell
Figure above shows the Abnormal release call flow.
49 © 2017 Nokia
Abnormal E-RAB Release In A Cell (Contd.)
Different Causes Abnormal Release Counters
L.E-RAB.AbnormRel.Radio Number of abnormal E-RAB releases due to faults at the radio network layer
L.E-RAB.AbnormRel.TNL Number of abnormal E-RAB releases due to faults at the transport network layer
L.E-RAB.AbnormRel.Cong Number of abnormal E-RAB releases due to network congestion
L.E-RAB.AbnormRel.HOFailure Number of abnormal E-RAB releases due to handover failures
L.E-RAB.AbnormRel.MME Number of abnormal E-RAB releases due to faults in the EPC
50 © 2017 Nokia
Abnormal E-RAB Release In A Cell (Contd.)
• 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 not Normal Release, Detach, 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 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 not Normal Release, Detach, User Inactivity,
Partial Handover, Handover triggered, successful handover, or cs fallback triggered, the corresponding counter is incremented by 1 according to the QCI
of each service.
E-RAB Abnormal Release Counters

L.E-RAB.AbnormRel.QCI.1 -9 Number of abnormal E-RAB releases for the service with QCI of 1-9 in a cell
L.E-RAB.AbnormRel Total number of abnormal E-RAB releases by the eNodeB
51 © 2017 Nokia
Abnormal E-RAB Releases In A Cell (Contd.)
• As shown in point A in Figure 3, 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, Detach, 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 by 1 according to the QCI of each service.
• As shown in point A in Figure 4, 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, Detach, User Inactivity,
Partial Handover, Handover triggered, successful handover, or cs fallback triggered, and in this case when the MME sends UE CONTEXT RELEASE
COMMAND message back to the eNodeB, this counter won`t be incremented repeatedly. If the UE CONTEXT RELEASE REQUEST message requires
multiple E-RAB releases at the same time, the corresponding counter is incremented according to the QCI of each service
52 © 2017 Nokia
Retainability KPI
Description:
Retainability KPIs indicate the network's capability to retain services requested by a user for a desired duration once the user is connected to the services.
Retainability KPIs are important in evaluating whether the system can maintain a certain level of service quality.
Retainability KPIs Include:

• Call Drop Rate (VoIP)
• Service Drop Rate (All)
• Service Drop Rate (Always Online)
• Minutes Per Drop (All)
• Minutes Per Drop (VoIP)
53 © 2017 Nokia
Retainability KPIs
Call Flow for Drop Counting interval Only considering mobile originating call
set up
54 © 2017 Nokia
Description:
The Call Drop Rate (VoIP) KPI indicates the call drop rate for VoIP services, and can be calculated based on the proportion of abnormally released E-RABs for
VoIP services. Each E-RAB contains QoS information. Generally, the QCI is 1 for VoIP services.
Name Call Drop Rate (VoIP)

Formula VoIP_CDR = (VoIPERABAbnormalRelease / VoIPERABRelease) × 100%
Associated Counters Call Drop Rate (VoIP) = (L.E-RAB.AbnormRel.QCI.1 / (L.E-RAB.AbnormRel.QCI.1 + L.E-
RAB.NormRel.QCI.1 + L.E-RAB.NormRel.IRatHOOut.QCI.1)) × 100%
Unit/range %
55 © 2017 Nokia
Description:
The Service Drop Rate (All) KPI indicates the service drop rate of all services (including VoIP).
Name Service Drop Rate (All)

Formula Service_CDR = (ERABAbnormalRelease / ERABRelease) × 100%
Associated Counters Service Drop Rate (All) = (L.E-RAB.AbnormRel / (L.E-RAB.AbnormRel + L.E-
RAB.NormRel + L.E-RAB.NormRel.IRatHOOut)) × 100%
Unit/range %
56 © 2017 Nokia
Service Drop Rate (Always Online)
Description:
The Service Drop Rate (Always Online) KPI indicates the service drop rate (always online) of all services (including VoIP). Similar to the KPI defined in Call
Drop Rate (VoIP).
Service Drop Rate (Always Online)
Name Service Drop Rate (Always Online)

Formula AlwaysOnline_CDR = (ERABAbnormalReleaseOfAlwaysOnline / ERABReleaseOfAlwaysOnline) × 100%
Associated Service Drop Rate (Always Online) = (L.E-RAB.AbnormRel / (L.E-RAB.AbnormRel + L.E-RAB.NormRel + L.E-
Counters RAB.Num.Syn2Unsyn + L.E-RAB.NormRel.IRatHOOut)) × 100%
Unit/range %
57 © 2017 Nokia
Minutes Per Drop (All)
Description:
The Minutes Per Drop (All) KPI indicates the proportion of the data transmission duration to the number of times that services are dropped due to exceptions.
This KPI reflects the average duration that a service drop occurs and is used to evaluate service retainability.
Minutes Per Drop (All)
Name Minutes Per Drop (All)

Formula MPD (All) = TimeOfTranmission / ERABAbnormalRelease
Associated Counters MPD (All) = (L.E-RAB.SessionTime.HighPrecision / (L.E-RAB.AbnormRel ) × 100/1000/60
Unit/range Minute
58 © 2017 Nokia
Minutes Per Drop (VoIP)
Description:
The Minutes Per Drop (VoIP) KPI indicates the proportion of the data transmission duration of VoIP services to the number of times that VoIP services are
dropped due to exceptions. This KPI reflects the average duration that a VoIP service drop occurs and is used to evaluate voice service retainability.
Minutes Per Drop (VoIP)
Name Minutes Per Drop (VoIP)

Formula MPD (VoIP) = TimeOfTranmission / ERABAbnormalRelease
Associated MPD (VoIP) = (L.E-RAB.SessionTime.HighPrecision.QCI1 / (L.E-RAB.AbnormRel.QCI.1) ×
Counters 100/1000/60
Unit/range Minute
59 © 2017 Nokia
Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• SRVCC
• Counter Query
• NPM4GS
60 © 2017 Nokia
Mobility
61 © 2017 Nokia
Mobility KPIs
Mobility KPIs are used to evaluate E-UTRAN mobility performance, which is critical to customer experience. Four categories of mobility KPIs are defined
based on the following handover types: intra-frequency, inter-frequency, inter-duplex-mode, and inter-Radio Access Technology (RAT).
Outgoing HO
• Intra-Frequency Handover Out Success Rate (All)
• Intra-Frequency Handover Out Success Rate (VoIP)
• Inter-Frequency Handover Out Success Rate (All)
• Inter-Frequency Handover Out Success Rate (VoIP)
• Inter-FDD/TDD Handover Out Success Rate (All)
• Inter-FDD/TDD Handover Out Success Rate (VoIP)
• Inter-RAT Handover Out Success Rate (LTE to WCDMA)
• Inter-RAT Handover Out Success Rate (LTE to GSM)
CSFB
• CSFB Preparation Success Rate
• CSFB Success Rate Based Handover (LTE to WCDMA)
• CSFB Success Rate Based Handover (LTE to GSM)
Incoming HO
• Intra-RAT Handover In Success Rate
62 © 2017 Nokia
Mobility KPIs
HO OUT
HO IN
63 © 2017 Nokia
Outgoing Handover
1. Intra-Frequency Handover Out Success Rate (All)
2. Intra-Frequency Handover Out Success Rate (VoIP)
3. Inter-Frequency Handover Out Success Rate (All)
4. Inter-Frequency Handover Out Success Rate (VoIP)
5. Inter-FDD/TDD Handover Out Success Rate (All)
6. Inter-FDD/TDD Handover Out Success Rate (VoIP)
7. Inter-RAT Handover Out Success Rate (LTE to WCDMA)
8. Inter-RAT Handover Out Success Rate (LTE to GSM)
Intra-Frequency Handover Out Success Rate (All)
Description
The Intra-Frequency Handover Out Success Rate KPI indicates the success rate of intra-frequency handovers (HOs) from the local cell to neighboring E-
UTRAN cells.
The intra-frequency HOs are classified into intra- and inter-eNodeB HOs.
Intra-eNodeB outgoing: The Intra-Frequency Handover Out Success Rate KPI indicates the success rate of intra-frequency handovers (HOs) from the local
cell to neighboring E-UTRAN cells. The intra-frequency HOs are classified into intra- and inter-eNodeB HOs.
Intra-eNodeB outgoing HOs can be further classified into :

• HO with RRC connection reestablishment
• HO without RRC connection reestablishment.
Inter-eNodeB Outgoing HO: inter-eNodeB outgoing HOs can be further classified into HO without RRC connection reestablishment, HO with RRC
connection reestablishment to the target cell, and HO with RRC connection reestablishment to the source cell.
Inter-eNodeB outgoing HOs can be further classified into:

• HO without RRC connection reestablishment
• HO with RRC connection reestablishment to the target cell
• HO with RRC connection reestablishment to the source cell
65 © 2017 Nokia
Intra-Frequency Handover Out Success Rate (All) (Contd.)
Intra-Frequency Handover Out Success Rate (All)
Name Intra-Frequency Handover Out Success Rate (All)

Formula IntraFreqHOOut_SR = (IntraFreqHOOutSuccess / IntraFreqHOOutAttempt) × 100%
Associated Counters Intra-Frequency Handover Out Success Rate =
((L.HHO.IntraeNB.IntraFreq.ExecSuccOut + L.HHO.IntereNB.IntraFreq.ExecSuccOut) /
(L.HHO.IntraeNB.IntraFreq.ExecAttOut + L.HHO.IntereNB.IntraFreq.ExecAttOut)) × 100%
Unit/range %
66 © 2017 Nokia
Intra-eNodeB Outgoing HO:
1. Intra-eNodeB outgoing HO without RRC connection reestablishment
Figure 1 illustrates an intra-eNodeB outgoing HO without RRC connection reestablishment, and the source and target cells operate at the same frequency. When
the eNodeB sends an RRC Connection Reconfiguration message containing the handover command to the UE, the eNodeB counts the number of intra-eNodeB
intra-frequency HO outgoing execution attempts in the source cell at point B. When the eNodeB receives an RRC Connection Reconfiguration Complete
message from the UE, the eNodeB counts the number of successful intra-eNodeB intra-frequency outgoing HO executions in the source cell at point C.
67 © 2017 Nokia
Inter-eNodeB Outgoing HO:
2. Inter-eNodeB outgoing HO without RRC connection reestablishment
Figure 3 and Figure 4 illustrate X2- and S1-based outgoing HOs with RRC connection reestablishment to the source cell, respectively, and the source cell and
target cell operate on the same frequency. When the source eNodeB sends an RRC Connection Reconfiguration message containing the handover command to the
UE, the source eNodeB counts the number of intra-frequency outgoing HO execution attempts in the source cell at point B. When the source eNodeB receives a
UE Context Release message from the target eNodeB or receives a UE Context Release Command message from the MME, indicating that the UE successfully
accesses the target cell, the source eNodeB counts the number of successful intra-frequency HO executions in the source cell at point C.
68 © 2017 Nokia
Intra-eNodeB Outgoing HO:
3. Intra-eNodeB outgoing HO with RRC connection reestablishment
Figure 2 illustrates an intra-eNodeB outgoing HO with RRC connection reestablishment, and the source and target cells operate at the same frequency. When
the eNodeB sends an RRC Connection Reconfiguration message containing the handover command to the UE, the eNodeB counts the number of intra-eNodeB
intra-frequency outgoing HO execution attempts in the source cell at point B. When the eNodeB receives an RRC Connection Reestablishment Complete
message from the UE, the eNodeB counts the number of successful intra-eNodeB intra-frequency outgoing HO executions in the source cell at point C.
69 © 2017 Nokia
4. Inter-eNodeB outgoing HO with RRC connection reestablishment to the target cell
target cell operate on the same frequency. When the source eNodeB sends an RRC Connection Reconfiguration message containing the handover command to
the UE, the source eNodeB counts the number of intra-frequency outgoing HO execution attempts in the source cell at point B. When the source eNodeB
receives a UE Context Release message from the target eNodeB or receives a UE Context Release Command message from the MME, indicating that the UE
successfully accesses the target cell, the source eNodeB counts the number of successful intra-frequency HO executions in the source cell at point C.
70 © 2017 Nokia
5. Inter-eNodeB outgoing HO with RRC connection reestablishment to the source cell
target cell operate on the same frequency. When the source eNodeB sends an RRC Connection Reconfiguration message containing the handover command to
the UE, the source eNodeB counts the number of intra-frequency outgoing HO execution attempts in the source cell at point B. When the source eNodeB
receives an RRC Connection Reestablishment Complete message from the UE, the source eNodeB counts the number of successful intra-frequency outgoing
HO executions in the source cell at point C.
71 © 2017 Nokia
Outgoing Handover
Intra-Frequency Handover Out Success Rate (VoIP)
Description
The Intra-Frequency Handover Out Success Rate (VoIP) KPI indicates the success rate of intra-frequency handovers (HOs) from the local cell to neighboring
E-UTRAN cells for VoIP services. The intra-frequency HOs are classified into intra- and inter-eNodeB HOs.
Definition
The Intra-Frequency Handover Out Success Rate (VoIP) KPI is defined in Table 1
Table 1: Intra-Frequency Handover Out Success Rate (VoIP)
Name Intra-Frequency Handover Out Success Rate (VoIP)

Formula IntraFreqHOOut_SR(VoIP) = (IntraFreqHOOutSuccess_VoIP / IntraFreqHOOutAttempt_VoIP) × 100%
Associated Intra-Frequency Handover Out Success Rate (VoIP) =
Counters ((L.HHO.IntraeNB.IntraFreq.ExecSuccOut.VoIP + L.HHO.IntereNB.IntraFreq.ExecSuccOut.VoIP) /
(L.HHO.IntraeNB.IntraFreq.ExecAttOut.VoIP + L.HHO.IntereNB.IntraFreq.ExecAttOut.VoIP)) × 100%
Unit/range %
73 © 2017 Nokia
Intra eNodeB HO Out Success Rate
Associated Counters
Note:
• In HW eNodeB, all the handover attempt statistics is calculated after admission control in target cell, which means HO failure statistics exclude admission
failure.
• The intra/inter-frequency handover (HO) includes both inter-eNodeB and intra-eNodeB scenarios.
74 © 2017 Nokia
Intra eNodeB HO Out Success Rate (Contd.)
As shown at point A, during an intra-eNodeB handover, the L.HHO.IntraeNB.InterFreq.PrepAttOut or L.HHO.IntraeNB.IntraFreq.PrepAttOut counter is
incremented by 1 if The eNodeB decides to perform an intra-eNodeB handover after receiving a measurement report from the UE
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.
75 © 2017 Nokia
Intra eNodeB HO Out Success Rate (Cont.)
Counter Description
L.HHO.IntraeNB.IntraFreq.PrepAttOut Number of intra-eNodeB intra-frequency outgoing handover attempts in a cell
L.HHO.IntraeNB.InterFreq.PrepAttOut Number of intra-eNodeB inter-frequency outgoing handover attempts in a cell
L.HHO.IntraeNB.IntraFreq.ExecAttOut Number of performed intra-eNodeB intra-frequency outgoing handovers in a cell
L.HHO.IntraeNB.InterFreq.ExecAttOut Number of performed intra-eNodeB inter-frequency outgoing handovers in a cell
L.HHO.IntraeNB.IntraFreq.ExecSuccOut Number of successful intra-eNodeB intra-frequency outgoing handovers in a cell
L.HHO.IntraeNB.InterFreq.ExecSuccOut Number of successful intra-eNodeB inter-frequency outgoing handovers in a cell
76 © 2017 Nokia
Outgoing Handover
Inter-Frequency Handover Out Success Rate (All)
Associated Counters (Inter eNodeB
X2 Based Handover
78 © 2017 Nokia
Inter-Frequency Handover Out Success Rate (All) (Contd.)
• As shown at point A in , during an X2-based handover, L.HHO.IntereNB.IntraFreq.PrepAttOut or L.HHO.IntereNB.InterFreq.PrepAttOut counter is
incremented by 1 each time The source eNodeB decides to perform an X2-based blind handover or decides to perform an X2-based handover after the
source cell receives a measurement report from the UE.
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.
79 © 2017 Nokia
Counter Description
L.HHO.IntereNB.IntraFreq.PrepAttOut Number of inter-eNodeB intra-frequency outgoing handover attempts in a cell
L.HHO.IntereNB.InterFreq.PrepAttOut Number of inter-eNodeB inter-frequency outgoing handover attempts in a cell
L.HHO.IntereNB.IntraFreq.ExecAttOut Number of performed inter-eNodeB intra-frequency outgoing handovers in a cell
L.HHO.IntereNB.InterFreq.ExecAttOut Number of performed inter-eNodeB inter-frequency outgoing handovers in a cell
L.HHO.IntereNB.IntraFreq.ExecSuccOut Number of successful inter-eNodeB intra-frequency outgoing handovers in a cell
L.HHO.IntereNB.InterFreq.ExecSuccOut Number of successful inter-eNodeB inter-frequency outgoing handovers in a cell
L.HHO.BlindHO.PrepAttOut Number of outgoing blind handover attempts in a cell
80 © 2017 Nokia
Description
The Inter-Frequency Handover Out Success Rate (All) KPI indicates the success rate of inter-frequency handovers (HOs) from the local cell to neighboring E-
UTRAN cells. The measurement methods of the related counters are similar to those for intra-frequency HOs described in Intra-Frequency Handover Out
Success Rate (All) The only difference is that the source and target cells operate on different frequencies and both work in FDD or TDD mode.
Figure 1 and Figure 2 illustrate intra-eNodeB HOs, and the source and target cells operate on different frequencies. The source eNodeB counts the number of
intra-eNodeB inter-frequency outgoing HO execution attempts in the source cell at point B and counts the number of successful intra-eNodeB inter-frequency
HO executions in the source cell at point C
81 © 2017 Nokia
Table 1 Inter-Frequency Handover Out Success Rate (All)
Name Inter-Frequency Handover Out Success Rate (All)
Formula InterFreqHOOut_SR = (InterFreqHOOutSuccess/InterFreqHOOutAttempt) × 100%
Associated Inter-Frequency Handover Out Success Rate =

Counters ((L.HHO.IntraeNB.InterFreq.ExecSuccOut + L.HHO.IntereNB.InterFreq.ExecSuccOut) /
(L.HHO.IntraeNB.InterFreq.ExecAttOut + L.HHO.IntereNB.InterFreq.ExecAttOut)) × 100%
Unit/range %
82 © 2017 Nokia
Figure 3, Figure 4, Figure 5, Figure 6, Figure 7, and Figure 8 illustrate inter-eNodeB HOs, and the source and target cells operate on different frequencies. The
source eNodeB counts the number of inter-eNodeB inter-frequency outgoing HO execution attempts in the source cell at point B and counts the number of
successful inter-eNodeB inter-frequency HO executions in the source cell at point C.
83 © 2017 Nokia
84 © 2017 Nokia
85 © 2017 Nokia
Description:
The Inter-Frequency Handover Out Success Rate (All) KPI indicates the success rate of inter-frequency handovers (HOs) from the local cell to neighboring E-
Success Rate (All) > Description. The only difference is that the source and target cells operate on different frequencies and both work in FDD or TDD mode.
Figure 1 and Figure 2 illustrate intra-eNodeB HOs, and the source and target cells operate on different frequencies. The source eNodeB counts the number of
intra-eNodeB inter-frequency outgoing HO execution attempts in the source cell at point B and counts the number of successful intra-eNodeB inter-frequency
HO executions in the source cell at point C. Figure 3, Figure 4, Figure 5, Figure 6, Figure 7, and Figure 8 illustrate inter-eNodeB HOs, and the source and target
cells operate on different frequencies. The source eNodeB counts the number of inter-eNodeB inter-frequency outgoing HO execution attempts in the source cell
at point B and counts the number of successful inter-eNodeB inter-frequency HO executions in the source cell at point C.
Definition:
The Inter-Frequency Handover Out Success Rate (All) KPI is defined in Table 1. Note that the number of outgoing HO execution attempts and the number of
successful outgoing HO executions are collected based on the description in Description.
Inter-Frequency Handover Out Success Rate (All)
Name Inter-Frequency Handover Out Success Rate (All)

Formula InterFreqHOOut_SR = (InterFreqHOOutSuccess/InterFreqHOOutAttempt) × 100%
Associated Inter-Frequency Handover Out Success Rate =
Counters ((L.HHO.IntraeNB.InterFreq.ExecSuccOut + L.HHO.IntereNB.InterFreq.ExecSuccOut) /
(L.HHO.IntraeNB.InterFreq.ExecAttOut + L.HHO.IntereNB.InterFreq.ExecAttOut)) × 100%
Unit/range %
86 © 2017 Nokia
87 © 2017 Nokia
88 © 2017 Nokia
Outgoing Handover
Inter-Frequency Handover Out Success Rate (VoIP)
Description:
The Intra-Frequency Handover Out Success Rate (VoIP) KPI indicates the success rate of inter-frequency handovers (HOs) from the local cell to neighboring
E-UTRAN cells for VoIP services. The inter-frequency HOs are classified into intra- and inter-eNodeB HOs. The source and target cells operate on different
frequencies and both work in FDD or TDD mode.
Definition:
Table below defines the Inter-frequency Handover Out Success Rate (VoIP) KPI.
Table 1 Inter-frequency Handover Out Success Rate (VoIP)
Name Inter-frequency Handover Out Success Rate (VoIP)

Formula InterFreqHOOut_SR(VoIP) = (InterFreqHOOutSuccess_VoIP/InterFreqHOOutAttempt_VoIP) × 100%
Associated Counters Intra-Frequency Handover Out Success Rate (VoIP) =
((L.HHO.IntraeNB.InterFreq.ExecSuccOut.VoIP + L.HHO.IntereNB.InterFreq.ExecSuccOut.VoIP) /
(L.HHO.IntraeNB.InterFreq.ExecAttOut.VoIP + L.HHO.IntereNB.InterFreq.ExecAttOut.VoIP)) × 100%
Unit/range %
90 © 2017 Nokia
Outgoing Handover
Inter-FDD/TDD Handover Out Success Rate (All)
Description
The Inter-FDD/TDD Handover Out Success Rate KPI indicates the success rate of inter-duplex-mode handovers (HOs) from the local cell to neighboring E-
Success Rate > Description. The only difference is that the source and target cells work in different duplex modes.
Figure 1 and Figure 2 illustrate intra-eNodeB HOs, and the source and target cells work in different duplex modes. The source eNodeB counts the number of
intra-eNodeB inter-duplex-mode outgoing HO execution attempts in the source cell at point B and counts the number of successful intra-eNodeB inter-duplex-
mode HO executions in the source cell at point C. Figure 3, Figure 4, Figure 5, Figure 6, Figure 7, and Figure 8 illustrate inter-eNodeB HOs, and the source
and target cells work in different duplex modes. The source eNodeB counts the number of inter-eNodeB inter-duplex-mode outgoing HO execution attempts in
the source cell at point B and counts the number of successful inter-eNodeB inter-duplex-mode HO executions in the source cell at point C.
Inter-FDD/TDD Handover Out Success Rate (All)
Name Inter-FddTdd Handover Out Success Rate (All)

Formula InterFddTddHOOut_SR = (InterFddTddHOOutSuccess/InterFddTddHOOutAttempt) × 100%
Associated Counters Inter-FddTdd Handover Out Success Rate =
((L.HHO.IntraeNB.InterFddTdd.ExecSuccOut + L.HHO.IntereNB.InterFddTdd.ExecSuccOut) /
(L.HHO.IntraeNB.InterFddTdd.ExecAttOut + L.HHO.IntereNB.InterFddTdd.ExecAttOut)) × 100%
Unit/range %
92 © 2017 Nokia
Inter-FDD/TDD Handover Out Success Rate (All) (Contd.)
93 © 2017 Nokia
Inter-FDD/TDD Handover Out Success Rate (All) (Contd.)
94 © 2017 Nokia
Outgoing Handover
Inter-FDD/TDD Handover Out Success Rate (VoIP)
Description
The Inter-FDD/TDD Handover Out Success Rate (VoIP) KPI indicates the success rate of inter-duplex-mode outgoing handovers for VoIP services. The source
and target cells work in different duplex modes.
Definition
The Inter-FDD/TDD Handover Out Success Rate (VoIP) KPI is defined in Table 1.
Table 1 Inter-FDD/TDD Handover Out Success Rate (VoIP)
Name Inter-FDD/TDD Handover Out Success Rate (VoIP)

Formula InterFddTddHOOut_SR(VoIP) = (InterFddTddHOOutSuccess_VoIP/InterFddTddHOOutAttempt_VoIP) × 100%
Associated Counters Inter-FDD/TDD Handover Out Success Rate (VoIP) =

((L.HHO.IntraeNB.InterFddTdd.ExecSuccOut.VoIP+L.HHO.IntereNB.InterFddTdd.ExecSuccOut.VoIP) /
(L.HHO.IntraeNB.InterFddTdd.ExecAttOut.VoIP + L.HHO.IntereNB.InterFddTdd.ExecAttOut.VoIP)) × 100%
Unit/range %
96 © 2017 Nokia
Outgoing Handover
Inter-RAT Handover Out Success Rate (LTE to WCDMA)
Description
The Inter-RAT Handover Out Success Rate (LTE to WCDMA) KPI indicates the success rate of handovers from an LTE cell or radio network to WCDMA
networks.
The number of LTE-to-WCDMA HO attempts increases by 1 at point B as shown in Figure 1 after the eNodeB sends a Mobility From EUTRA Command
message to the UE. The number of successful inter-RAT HOs from LTE to WCDMA increases by 1 at point C, where the eNodeB receives a UE Context
Release Command message from the MME after the UE accesses the WCDMA network.
Inter-RAT Handover Out Success Rate (LTE to WCDMA)
Name Inter-RAT Handover Out Success Rate (LTE to WCDMA)

Formula IRATHO_L2W_SR = (IRATHO_L2W_Success/IRATHO_L2W_Attempt) x 100%
Associated Inter-RAT Handover Out Success Rate (LTE to WCDMA)
Counters =(L.IRATHO.E2W.ExecSuccOut/L.IRATHO.E2W.ExecAttOut) x 100%
98 © 2017 Nokia
Outgoing Handover
Inter-RAT Handover Out Success Rate (LTE to GSM)
Description
The Inter-RAT Handover Out Success Rate (LTE to GSM) KPI indicates the success rate of handovers from an LTE cell or radio network to GSM networks
The number of LTE-to-GSM HO attempts increases by 1 at point B as shown in Figure 1 after the eNodeB sends a Mobility From EUTRA Command message
to the UE. The number of successful inter-RAT HOs from LTE to GSM increases by 1 at point C, where the eNodeB receives a UE Context Release Command
message from the MME after the UE accesses the GSM network.
Inter-RAT Handover Out Success Rate (LTE to GSM)
Name Inter-RAT Handover Out Success Rate (LTE to GSM)

Formula IRATHO_L2G_SR = (IRATHO_L2G_Success/IRATHO_L2G_Attempt) x 100%
Associated Inter-RAT Handover Out Success Rate (LTE to GSM)
Counters =(L.IRATHO.E2G.ExecSuccOut/L.IRATHO.E2G.ExecAttOut) x 100%
100 © 2017 Nokia

Associated Counters LTE to WCDMA
101 © 2017 Nokia

Associated Counters LTE to WCDMA (Contd.)
Number of Performed Outgoing Handovers from E-UTRAN to UTRAN:
• As shown at point A, L.IRATHO.E2W.PrepAttOut counter is incremented by 1 each time the eNodeB decides to perform an inter-RAT handover from E-
UTRAN to WCDMA network after the eNodeB receives a measurement report from a UE.
• As shown in point B, L.IRATHO.E2W.ExecAttOut counter is incremented by 1 each time the eNodeB sends a Mobility from EUTRA Command
message to the UE during a handover from E-UTRAN to UTRAN.
• As shown in point C, L.IRATHO.E2W.ExecSuccOut counter is incremented by 1 each time the eNodeB receives a UE CONTEXT RELEASE
COMMAND message from the MME after the UE is handed over from E-UTRAN to UTRAN.
102 © 2017 Nokia

Inter-RAT HO KPIs Summary
Counter Description
Number of Outgoing Handover Attempts from E-UTRAN to UTRAN. The counter is incremented by 1 each time the
eNodeB receives a Measurement Report message from the UE and decides to perform a handover from E-UTRAN to
L.IRATHO.E2W.PrepAttOut UTRAN.
Number of Performed Outgoing Handovers from E-UTRAN to UTRAN. The counter is incremented by 1 each time
the eNodeB sends a Mobility from EUTRA Command message to the UE during a handover from E-UTRAN to
L.IRATHO.E2W.ExecAttOut UTRAN.
Number of Successful Outgoing Handovers from E-UTRAN to UTRAN. The counter is incremented by 1 each time
the eNodeB receives a UE CONTEXT RELEASE COMMAND message from the MME after the UE is handed over
L.IRATHO.E2W.ExecSuccOut from E-UTRAN to UTRAN.
Counter Description
Number of Outgoing Handover Attempts from E-UTRAN to GERAN. The counter is incremented by 1 each time the
eNodeB receives a Measurement Report message from the UE and decides to perform a handover from E-UTRAN to
L.IRATHO.E2G.PrepAttOut GERAN.
Number of Performed Outgoing Handovers from E-UTRAN to GERAN. The counter is incremented by 1 each time
the eNodeB sends a Mobility from EUTRA Command message to the UE during a handover from E-UTRAN to
L.IRATHO.E2G.ExecAttOut GERAN.
Number of Successful Outgoing Handovers from E-UTRAN to GERAN. The counter is incremented by 1 each time
the eNodeB receives a UE CONTEXT RELEASE COMMAND message from the MME after the UE is handed over
L.IRATHO.E2G.ExecSuccOut from E-UTRAN to GERAN.
103 © 2017 Nokia

CSFB
1. CSFB Preparation Success Rate
2. CSFB Success Rate Based Handover (LTE to WCDMA)
3. CSFB Success Rate Based Handover (LTE to GSM)
CSFB Preparation Success Rate
Description
The CSFB Preparation Success Rate KPI indicates the preparation success rate of CS fallback (CSFB) from the E-UTRAN to inter-RAT networks.
The CSFB Preparation can be further classified into: UE in RRC_Idle mode & UE in RRC_Connected mode
UE in RRC_Idle mode
For a UE in RRC_Idle mode, the number of CSFB preparation attempts increases by 1 at point A as shown in Figure 1 after the eNodeB receives an INITIAL
CONTEXT SETUP REQUEST (with CS Fallback Indicator) message from the MME and determines that the request is triggered by a voice service. The
number of successful CSFB preparations increases by 1 at point C, where the eNodeB successfully responses an INITIAL CONTEXT SETUP RESPONSE
message for the request triggered by the voice service.
Name CSFB Preparation Success Rate

Formula CSFB_Preparation_SR =
(CSFB_Preparation_Success/CSFB_Preparation_Attempt) x 100%
Associated CSFB Preparation Success Rate =(L.CSFB.PrepSucc/L.CSFB.PrepAtt) x 100%
Counters
105 © 2017 Nokia

CSFB Preparation Success Rate (Contd.)
UE in RRC_Connected mode
For a UE in RRC_Connected mode, the number of CSFB preparation attempts increases by 1 at point A as shown in Figure 2 after the eNodeB receives a UE
CONTEXT MODIFICATION REQUEST (with CS Fallback Indicator) message from the MME and determines that the request is triggered by a voice service.
The number of successful CSFB preparations increases by 1 at point C, where the eNodeB successfully responses a UE CONTEXT MODIFICATION
RESPONSE message for the request triggered by the voice service.
Name CSFB Preparation Success Rate

Formula CSFB_Preparation_SR =
(CSFB_Preparation_Success/CSFB_Preparation_Attempt) x 100%
Associated CSFB Preparation Success Rate =(L.CSFB.PrepSucc/L.CSFB.PrepAtt ) x 100%
Counters
106 © 2017 Nokia

CSFB
CSFB Success Rate Based Handover (LTE to WCDMA)
Description
The CSFB Success Rate Based Handover (LTE to WCDMA) KPI indicates the success rate of handover-based LTE-to-WCDMA CSFB.
The number of handover-based LTE-to-WCDMA CSFB attempts increases by 1 at point B as shown in Figure 1 after the eNodeB sends a Mobility From
EUTRA Command message to the UE and performs CSFB to a WCDMA network. The number of successful handover-based LTE-to-WCDMA CSFB
executions increases by 1 at point C, where the eNodeB receives a UE CONTEXT RELEASE COMMAND message from the MME after the UE successfully
accesses the WCDMA network.
CSFB Success Rate Based Handover (LTE to WCDMA)
Name CSFB Success Rate Based Handover (LTE to WCDMA)

Formula CSFB_L2W_BasedHO_SR =
(CSFB_L2W_BasedHO_Success/CSFB_L2W_BasedHO_Attempt) x 100%
Associated CSFB Success Rate Based Handover(LTE to WCDMA)
Counters =(L.IRATHO.E2W.CSFB.ExecSuccOut/L.IRATHO.E2W.CSFB.ExecAttOut) x
100%
108 © 2017 Nokia

CSFB
CSFB Success Rate Based Handover (LTE to GSM)
Description
The CSFB Success Rate Based Handover (LTE to GSM) KPI indicates the success rate of handover-based LTE-to-GSM CSFB.
The number of handover-based LTE-to-GSM CSFB attempts increases by 1 at point B as shown in Figure 1 after the eNodeB sends a Mobility From EUTRA
Command message to the UE and performs CSFB to a GSM network. The number of successful handover-based LTE-to-GSM CSFB executions increases by 1
at point C, where the eNodeB receives a UE CONTEXT RELEASE COMMAND message from the MME after the UE successfully accesses the GSM
network.
CSFB Success Rate Based Handover (LTE to GSM)
Name CSFB Success Rate Based Handover (LTE to GSM)

Formula CSFB_L2G_BasedHO_SR =
(CSFB_L2G_BasedHO_Success/CSFB_L2G_BasedHO_Attempt) x 100%
Associated CSFB Success Rate Based Handover(LTE to GSM) =
Counters (L.IRATHO.E2G.CSFB.ExecSuccOut/L.IRATHO.E2G.CSFB.ExecAttOut) x 100%
110 © 2017 Nokia

Incoming Ho
1. Intra-RAT Handover in Success Rate
HO without RRC connection reestablishment
Figure 1 illustrates an intra-eNodeB handover without RRC connection reestablishment. When the eNodeB sends an RRC Connection Reconfiguration
message containing the handover command to the UE, the eNodeB counts the number of intra-eNodeB incoming HO execution attempts in the target cell at
point B. When the eNodeB receives an RRC Connection Reconfiguration Complete message from the UE, indicating that the handover finishes, the eNodeB
counts the number of successful intra-eNodeB incoming HO executions in the target cell at point C.
Name Intra-RAT Handover In Success Rate

Formula Intra-RATHOIn_SR = (Intra-RATHOInSuccess/Intra-RATHOInAttempt) x 100%
Associated Intra-RAT Handover In Success Rate =
Counters [(L.HHO.IntraeNB.ExecSuccIn + L.HHO.IntereNB.ExecSuccIn)/(L.HHO.Intrae
NB.ExecAttIn + L.HHO.IntereNB.ExecAttIn)] x 100%
112 © 2017 Nokia

Intra-RAT Handover In Success Rate (Contd.)
Intra-eNodeB incoming HO with RRC connection reestablishment
Figure 2 illustrates an intra-eNodeB handover with RRC connection reestablishment. When the eNodeB sends an RRC Connection Reconfiguration message
containing the handover command to the UE, the eNodeB counts the number of intra-eNodeB incoming HO execution attempts in the target cell at point B.
When the eNodeB receives an RRC Connection Reestablishment Complete message from the UE, the eNodeB counts the number of successful intra-eNodeB
incoming HO executions in the target cell at point C.
113 © 2017 Nokia

Inter eNodeB Incoming HO
Inter-eNodeB incoming HOs can be further classified into:
• HO with RRC connection reestablishment.
HO without RRC connection reestablishment

Figure 3 and Figure 4 illustrate X2- and S1-based incoming HOs without RRC connection reestablishment, respectively. When the target eNodeB sends a
Handover Request Acknowledge message to the source eNodeB or MME, the target eNodeB counts the number of incoming HO execution attempts in the
target cell at point B. When the target eNodeB receives an RRC Connection Reconfiguration Complete message from the UE and sends a UE CONTEXT
RELEASE message to the source eNodeB or sends a HANDOVER NOTIFY message to the MME to instruct the source eNodeB to release the UE context, the
target eNodeB counts the number of successful incoming HO executions in the target cell at point C.
114 © 2017 Nokia

Inter eNodeB Incoming HO (Contd.)
HO with RRC connection reestablishment:
X2-based incoming HO with RRC connection reestablishment to the target cell
Figure 5 illustrates an X2-based incoming HO with RRC connection reestablishment to the target cell. When the target eNodeB sends a Handover Request
Acknowledge message to the source eNodeB or MME, the target eNodeB counts the number of incoming HO execution attempts in the target cell at point B.
When the target eNodeB receives an RRC Connection Reestablishment Complete message from the UE and then sends a UE CONTEXT RELEASE message
to the source eNodeB to instruct the source eNodeB to release the UE context, the target eNodeB counts the number of successful incoming HO executions in
the target cell at point E.
115 © 2017 Nokia

Inter eNodeB incoming HOs can be further classified into:
• HO with RRC connection reestablishment to the target cell.
Inter eNodeB incoming HO with RRC connection reestablishment to the target cell:
S1-based incoming HO with RRC connection reestablishment to the target cell
Figure 6 illustrates an S1-based incoming HO with RRC connection reestablishment to the target cell. When the target eNodeB sends a Handover Request
Acknowledge message to the source eNodeB or MME, the target eNodeB counts the number of incoming HO execution attempts in the target cell at point B.
When the target eNodeB receives an RRC Connection Reestablishment Complete message from the UE and then sends a HANDOVER NOTIFY message to
the MME to instruct the source eNodeB to release the UE context, the target eNodeB counts the number of successful incoming HO executions in the target
cell at point C.
116 © 2017 Nokia

117 © 2017 Nokia

Number of Intra-eNB incoming handover attempts:
As shown at point A, the L.HHO.IntraeNB.PrepAttIn or counter is incremented by 1 in the target cell each time the eNodeB decides to perform an intra
eNodeB incoming handover after receiving a measurement report from the UE.
During a handover where the source cell and target cell are controlled by the same eNodeB, as shown in point B, L.HHO.IntraeNB.ExecAttIn
counter is incremented by 1 in the target cell each time the eNodeB sends an RRC Connection Reconfiguration message to the UE.
Number of successful intra-eNB incoming handovers:
As shown in point C , the L.HHO.IntraeNB.ExecSuccIn counter is incremented by 1 in the target cell each time the eNodeB receives an RRC Connection
Reconfiguration Complete message from the UE and the subsequent operations are successful
118 © 2017 Nokia

Inter eNodeB (X2) Handover Success rate
119 © 2017 Nokia

Inter eNodeB (X2) Handover Success rate (Contd.)
• The L.HHO.IntereNB.PrepAttIn counter is incremented by 1 in the target cell each time the target eNodeB receives a HANDOVER REQUEST message
from the source eNodeB over the X2 interface OR target eNodeB receives a HANDOVER REQUEST message from the source eNodeB over the S1
interface.
• The source cell and target cell of a handover are controlled by different eNodeBs. As shown in point B, the L.HHO.IntereNB.ExecAttIn is incremented
by 1 in the target cell each time the target eNodeB sends a HANDOVER REQUEST ACKNOWLEDGE message to the source eNodeB over the X2
interface or to the MME over the S1 interface.
• As shown in point C , the L.HHO.IntereNB.ExecSuccIn is incremented by 1 in the target cell each time the target eNodeB sends a UE CONTEXT
RELEASE to the source eNodeB over the X2 interface after receiving a PATH SWITCH ACK message from the MME or the target eNodeB sends a
HANDOVER NOTIFY message to the MME over the S1 interface.
120 © 2017 Nokia

Inter eNodeB (X2) Handover Success rate (Contd.)
Counter Description
L.HHO.IntraeNB.PrepAttIn Number of intra-eNodeB incoming handover attempts in a cell
L.HHO.IntraeNB.ExecAttIn Number of performed intra-eNodeB incoming handovers in a cell
L.HHO.IntraeNB.ExecSuccIn Number of successful intra-eNodeB incoming handovers in a cell

L.HHO.IntereNB.PrepAttIn Number of inter-eNodeB incoming handover attempts in a cell
L.HHO.IntereNB.ExecAttIn Number of performed inter-eNodeB incoming handovers in a cell
L.HHO.IntereNB.ExecSuccIn Number of successful inter-eNodeB incoming handovers in a cell
121 © 2017 Nokia

Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• SRVCC
• Counter Query
• NPM4GS
122 © 2017 Nokia

Service Integrity
123 © 2017 Nokia

Service Integrity KPIs
The service integrity KPIs indicate the E-UTRAN impacts on the service quality provided to the end-user. The service integrity KPIs can be calculated for each
cell or radio network.
• User Downlink Average Throughput

• User Uplink Average Throughput
• Service Downlink Average Throughput
• Service Uplink Average Throughput
• Cell Downlink Average Throughput
• Cell Uplink Average Throughput
• Downlink Packet Loss Rate (All)
• Downlink Packet Loss Rate (VoIP)
• Uplink Packet Loss Rate (All)
• Uplink Packet Loss Rate (VoIP)
124 © 2017 Nokia

User Downlink Average Throughput
Description
The User Downlink Average Throughput KPI indicates the average downlink UE throughput in a cell. According to 3GPP TS 32.450, the throughput
measurement needs to remove the data scheduled in the last TTI before the downlink buffer is empty, as shown in Figure 1.
125 © 2017 Nokia

User Downlink Average Throughput (Contd.)
User Downlink Average Throughput
Name User Downlink Average Throughput

Formula UserDLAveThp = UserDLRmvLastTTITrafficVolume/UserDLRmvLastTTITransferTime
Associated Counters User Downlink Average Throughput =
(L.Thrp.bits.DL - L.Thrp.bits.DL.LastTTI)/L.Thrp.Time.DL.RmvLastTTI
Unit kbit/s
126 © 2017 Nokia

User Uplink Average Throughput
Description
The User Uplink Average Throughput KPI indicates the average uplink UE throughput in a cell.
The throughput measurement needs to remove the data scheduled in the last TTI before the downlink buffer is empty
User Uplink Average Throughput
Name User Uplink Average Throughput

Formula UserULAveThp = UserULLastTTITrafficVolume / UserULLastTTITransferTime
Associated Counters User Uplink Average Throughput =
(L.Thrp.bits.UL - L.Thrp.bits.UE.UL.LastTTI) / L.Thrp.Time.UE.UL.RmvLastTTI
Unit/range kbit/s
127 © 2017 Nokia

Service Downlink Average Throughput
Description
The Service Downlink Average Throughput KPI consists of nine sub-KPIs that are mapped to nine QCIs. These sub-KPIs indicate the busy-hour downlink
(DL) throughput of a service with a specific QCI per user in each cell. The Service Downlink Average Throughput KPI reflects the end-user experience
Definition
The Service Downlink Average Throughput KPI is defined in Table 2. Nine different sub-KPIs exist for each QCI. The formula for each KPI is mapped to its
corresponding counter. Table 1 lists the requirements for services with different QCIs.
Requirements for services with different QCIs
QCI Resource Type Priority Packet Delay Budget Packet Error Loss Example Services
(NOTE 1) Rate (NOTE 2)
1 GBR 2 100 ms 10-2 Conversational Voice
2 4 150 ms 10-3 Conversational Video (Live Streaming)
3 3 50 ms 10-3 Real Time Gaming
4 5 300 ms 10-6 Non-Conversational Video (Buffered Streaming)
5 Non-GBR 1 100 ms 10-6 IMS Signaling
6 6 300 ms 10-6 Video (Buffered Streaming) TCP-based (e.g., www, e-mail,
chat, ftp, p2p file sharing, progressive video, etc.)
7 7 100 ms 10-3 Voice, Video (Live Streaming) Interactive Gaming

8 8 300 ms 10-6
Video (Buffered Streaming) TCP-based (e.g., www, e-mail,
9 9 300 ms 10-6 chat, ftp, p2p file sharing, progressive video, etc.)
128 © 2017 Nokia

Service Downlink Average Throughput (Contd.)
Service Downlink Average Throughput
Name Service Downlink Average Throughput

Formula DLAverageThroughput_QCI_1
DLAverageThroughput_QCI_2
Associated Counters Service Downlink Average Throughput = L.Thrp.bits.DL.QCI.n/L.Thrp.Time.DL.QCI.n
n = 1 to 9
Unit/Range kbit/s
129 © 2017 Nokia

Service Uplink Average Throughput
Description
The Service Uplink Average Throughput KPI consists of nine sub-KPIs that are mapped to nine QCIs. These sub-KPIs indicate the busy-hour uplink (UL)
throughput of a service with a specific QCI per user in each cell. The Service Uplink Average Throughput KPI reflects the end-user experience.
Service Uplink Average Throughput
Name Service Uplink Average Throughput

Formula ULAverageThroughput_QCI_1
ULAverageThroughput_QCI_2
Associated Counters •FDD:Service Uplink Average Throughput = L.Thrp.bits.UL.QCI.n/L.Thrp.Time.UL.QCI.n
•TDD:Service Uplink Average Throughput = L.Thrp.bits.UL.QCI.n/L.Thrp.Time.UL.QCI.n x (Number of uplink
subframes per radio frame/10)
n = 1 to 9
Unit/Range kbit/s
130 © 2017 Nokia

Cell Downlink Average Throughput
Description
The Cell Downlink Average Throughput KPI indicates a cell's average downlink throughput when data is transferring at the downlink. The Cell Downlink
Average Throughput KPI reflects the cell's capacity.
Definition
The Cell Downlink Average Throughput KPI is defined and is calculated based on all the data transferred at the downlink and the time it takes to transfer. The
formula is mapped to its corresponding counters.
Cell Downlink Average Throughput
Name Cell Downlink Average Throughput

Formula CellDLAveThp = CellDLTrafficVolume/CellDLTransferTime
Associated Counters Cell Downlink Average Throughput = L.Thrp.bits.DL/L.Thrp.Time.Cell.DL.HighPrecision
Unit/Range kbit/s
131 © 2017 Nokia

Cell Uplink Average Throughput
Description
The Cell Uplink Average Throughput KPI indicates the average cell uplink throughput when data is transferring at the uplink. The Cell Uplink Average
Throughput KPI reflects the cell's capacity.
Cell Uplink Average Throughput
Name Cell Uplink Average Throughput

Formula CellULAveThp = CellULTrafficVolume/CellULTransferTime
Associated Counters Cell Uplink Average Throughput = L.Thrp.bits.UL/L.Thrp.Time.Cell.UL.HighPrecision
NOTE: For LTE TDD, this formula denotes an instantaneous average throughput without involving the duration
of waiting for scheduling. The uplink-downlink subframe configuration must be considered when operators
compare this average value and the theoretical maximum data rate.
Unit/Range kbit/s
132 © 2017 Nokia

Downlink Packet Loss Rate (All)
Description
The Downlink Packet Loss Rate (VoIP) KPI indicates the downlink packet loss situation of a cell at the PDCP layer. This KPI is calculated based on the number
of dropped PDCP SDUs and the total number of downlink PDCP SDUs transmitted for services carried on DRBs with all QCIs (including the QCI for PTT
services and extended QCIs) in a cell over the Uu interface
Downlink Packet Loss Rate (All)
Name Downlink Packet Loss Rate (All)

Formula DLPacketLossRate (All) = NumOfDlLostPackets / NumberOfDlTransmittedPacket
Associated Counters Downlink Packet Loss Rate (All) = (L.Traffic.DL.PktUuLoss.Loss / (L.Traffic.DL.PktUuLoss.Tot)
× 100%
Unit/range %
133 © 2017 Nokia

Downlink Packet Loss Rate (VoIP)
Description
The Downlink Packet Loss Rate (VoIP) KPI indicates the packet loss situation of a cell at the PDCP layer. The KPI is decided by the number of lost PDCP
SDUs and the total number of downlink PDCP SDUs transmitted for services carried on DRBs with QCI of 1 in a cell over the Uu interface.
Downlink Packet Loss Rate (VoIP)
Name Downlink Packet Loss Rate (VoIP)

Formula DLPacketLossRate (VoIP) = NumOfDlLostPackets / NumberOfDlTransmittedPacket
Associated Counters Downlink Packet Loss Rate (VoIP) =
(L.Traffic.DL.PktUuLoss.Loss.QCI.1 / L.Traffic.DL.PktUuLoss.Tot.QCI.1) × 100%
Unit/range %
134 © 2017 Nokia

Uplink Packet Loss Rate (All)
Description
The Uplink Packet Loss Rate (All) KPI indicates the uplink packet loss situation of a cell at the PDCP layer. This KPI is calculated based on the total number of
dropped uplink PDCP SDUs for services carried on DRBs with all QCIs (including the QCI for PTT services and extended QCIs) and the total number of
packets expected to be received in the uplink.
Uplink Packet Loss Rate (All)
Name Uplink Packet Loss Rate (All)

Formula ULPacketLossRate (All) = NumOfUlLostPackets / NumberOfUlTransmittedPacket
Associated Counters Uplink Packet Loss Rate (All) = (L.Traffic.UL.PktLoss.Loss / (L.Traffic.UL.PktLoss.Tot) ×
100%
Unit/range %
135 © 2017 Nokia

Uplink Packet Loss Rate (VoIP)
Description
The Uplink Packet Loss Rate (VoIP) KPI indicates the uplink packet loss situation of a cell at the PDCP layer for VoIP services. This KPI is calculated based on
the total number of dropped PDCP SDUs for services carried on DRBs with QCI of 1 and the total number of packets expected to be received in the uplink.
Uplink Packet Loss Rate (VoIP)
Name Uplink Packet Loss Rate (VoIP)

Object Cell / Radio Network
Formula ULPacketLossRate (VoIP) = NumOfUlLostPackets / NumberOfUlTransmittedPacket
Associated Counters Uplink Packet Loss Rate (VoIP) =
(L.Traffic.UL.PktLoss.Loss.QCI.1 / L.Traffic.UL.PktLoss.Tot.QCI.1) × 100%
Unit/range %
136 © 2017 Nokia

Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• SRVCC
• Counter Query
• NPM4GS
137 © 2017 Nokia

Utilization
138 © 2017 Nokia

Utilization KPIs
• Resource Block Utilizing Rate
• Uplink Preschedule Resource Block Occupied Rate
• Average CPU Load
139 © 2017 Nokia

Description
The Resource Block Utilizing Rate KPI consists of two sub-KPIs: the uplink resource block (RB) utilizing rate and downlink RB utilizing rate. These two sub-
KPIs indicate the busy-hour DL and UL RB utilizing rates in each cell or radio network.
Definition
The uplink and downlink Resource Block Utilizing Rate KPIs are defined in Table 1.
Name Resource Block Utilizing Rate

Formula RB_URDL = (RB_UsedDL/RB_AvailableDL) x 100%
RB_URUL = (RB_UsedUL/RB_AvailableUL) x 100%
Associated Counters Downlink Resource Block Utilizing Rate =(L.ChMeas.PRB.DL.Used.Avg/L.ChMeas.PRB.DL.Avail) x
100%
Uplink Resource Block Utilizing Rate =(L.ChMeas.PRB.UL.Used.Avg/L.ChMeas.PRB.UL.Avail) x 100%
140 © 2017 Nokia

Uplink Preschedule Resource Block Occupied Rate
Description
The Uplink Preschedule Resource Block Occupied Rate KPI indicates the percentage of uplink RBs allocated to UEs for pre-scheduling. The Uplink
Preschedule Resource Block Occupied Rate KPI can be used to evaluate the impact on uplink RB usage caused by pre-scheduling.
If pre-scheduling is enabled, when there are remaining uplink RBs in a cell, the eNodeB allocates uplink RBs to UEs that have not sent a bandwidth request to
reduce the uplink service delay of these UEs.
Definition
The Uplink Preschedule Resource Block Occupied Rate KPI is defined in Table 1.
Table 1: Uplink Preschedule Resource Block Occupied Rate
Name Uplink Preschedule Resource Block Occupied Rate

Object Cell/Radio Network
Formula PrescheduleRB_URUL = RB_PrescheduleUsedUL/RB_AvailableUL
Associated Counters Uplink Preschedule Resource Block Occupied
Rate= L.ChMeas.PRB.UL.PreSch.Used.Avg/L.ChMeas.PRB.UL.Avail
141 © 2017 Nokia

Average CPU Load
Description
The Average CPU Load KPI indicates the CPU usage during busy hours.
Definition
The Average CPU Load KPI is defined in Table 1. The CPU load is calculated by averaging the CPU usage ratio during the measurement period.
Table 1: Average CPU Load
Name Average CPU Load

Object CPU
Formula MeanCPUUtility
Associated Counters Average CPU Load = VS.BBUBoard.CPULoad.Mean
142 © 2017 Nokia

Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VOLTE
• SRVCC
• Counter Query
• NPM4GS
143 © 2017 Nokia

Availability
144 © 2017 Nokia

Availability KPIs
A cell is available when the eNodeB can provide EPS bearer services. Availability in a cell can be measured when a variety of hardware/software faults occurs
in the cell.
Radio Network Unavailability Rate:
Description
The Radio Network Unavailability Rate KPI indicates the percentage of time when cells in a radio network are unavailable. This KPI is used to evaluate the
deterioration of network performance caused by unavailable cells on the radio network during busy hours.
Definition
The Radio Network Unavailability Rate KPI is defined in Table 1. This KPI is calculated based on the length of time all cell services are unavailable on the
radio network.
Name Radio Network Unavailability Rate

Object Radio network
Formula RAN_Unavail_Rate = (ΣCellUnavailTime/(TheTotalNumberOfCellsInCluster x {SP} x 60)) x 100%
NOTE:"SP" indicates the reporting period for counters in minutes.
Associated Counters Radio Network Unavailability Rate =((L.Cell.Unavail.Dur.Sys + L.Cell.Unavail.Dur.Manual)/(Number of
cells x {SP} x 60)) x 100%
"SP" indicates the reporting period for counters in minutes.
145 © 2017 Nokia

Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• SRVCC
• Counter Query
• NPM4GS
146 © 2017 Nokia

Traffic
147 © 2017 Nokia

Traffic KPIs
Traffic KPIs are used to measure the traffic volume on the LTE Radio Access Network (RAN). Based on traffic types, the traffic KPIs are classified into the
following categories: radio bearers, downlink traffic volume, and uplink traffic volume.
• Radio Bearers
• Downlink Traffic Volume
• Uplink Traffic Volume
• Average User Number
• Maximum User Number
• Resource Block Utilizing Rate
• Radio Bearer Number
• Cell Downlink Average Throughput
148 © 2017 Nokia

Radio Bearers
Description
The Radio Bearers KPI consists of ten sub-KPIs. One KPI corresponds to the total of radio bearers and the other nine correspond to nine QCIs. This set of sub-
KPIs indicates the average number of radio bearers in a cell or radio network. The radio bearer for each QCI is based on the number of active RRC connections
for each QCI, according to the QCI defined in the QoS information.
Definition
The Radio Bearers KPIs are defined in Table 1 and include ten different sub-KPIs. The formula for each KPI is mapped to its corresponding counter.
149 © 2017 Nokia

Radio Bearers (Contd.)
Table 1.Radio Bearers
Name Radio Bearers

Formula RadioBearers
RadioBearers_QCI_1
RadioBearers_QCI_2
RadioBearers_QCI_3
RadioBearers_QCI_4
RadioBearers_QCI_5
RadioBearers_QCI_6
RadioBearers_QCI_7
RadioBearers_QCI_8
RadioBearers_QCI_9
Associated Radio Bearers =L.Traffic.DRB
Counters RadioBearers of QCIn = L.Traffic.DRB.QCI.n
n = 1 to 9
Unit/Range NA
150 © 2017 Nokia

Downlink Traffic Volume
Description
Similar to the Radio Bearers KPI, the Downlink Traffic Volume KPI consists of ten sub-KPIs. One KPI corresponds to the total DRB traffic volume, and the
other nine correspond to nine QCIs. This set of sub-KPIs indicates the downlink traffic volume in a cell, which is measured at the PDCP layer and excludes the
PDCP header.
Definition
The Downlink Traffic Volume KPIs are defined in Table 1 and include ten sub-KPIs. The formula for each KPI is mapped to its corresponding counter.
151 © 2017 Nokia

Downlink Traffic Volume (Contd.)
Table 1.Downlink Traffic Volume
Name Downlink Traffic Volume

Formula DLTrafficVolume
DLTrafficVolume_QCI_1
Associated Counters Downlink Traffic Volume = L.Thrp.bits.DL
Downlink Traffic Volume of QCIn = L.Thrp.bits.DL.QCI.n
n = 1 to 9
Unit/Range bit
152 © 2017 Nokia

Downlink Traffic Volume (Contd.)
Description
The counters measure the total traffic volume of transmitted PDCP SDUs for each service with a specific QCI ranging 1 to 9 in a cell
Measurement point
The size of the payloads in the transmitted PDCP SDUs of each service with a specific QCI is sampled in a cell. At the end of a measurement period, the sum of
these sampling results is used as the value of the corresponding counter.
The downlink traffic volume KPIs consist of nine sub-KPIs mapped to nine QCIs. This group of KPIs can be used to evaluate the DL traffic volume for each
QCI in a cell, which is measured at the RLC layer excluding the RLC header and RLC retransmission.
Downlink Traffic Volume for PDCP SDUs
Associated Counters
L.Thrp.bits.DL Total downlink traffic volume for PDCP SDUs in a cell
L.Thrp.bits.DL.QCI.1 -9 Downlink traffic volume for PDCP SDUs of services with the QCI of 1-9 in a cell
153 © 2017 Nokia

Uplink Traffic Volume
Description
Similar to the Downlink Traffic Volume KPI, the Uplink Traffic Volume KPI consists of ten sub-KPIs. One KPI corresponds to the total of traffic volume for
DRBs, and the other nine correspond to nine QCIs. This set of sub-KPIs indicates a cell's uplink traffic volume. The sub-KPIs are measured at the PDCP layer
and exclude the PDCP header.
Definition
The Uplink Traffic Volume KPIs are defined in Table 1 and include ten sub-KPIs. The formula for each KPI is mapped to its corresponding counter
Table 1.Uplink Traffic Volume

Name Uplink Traffic Volume
Formula ULTraffic Volume
ULTraffic Volume_QCI_1
Associated Counters Uplink Traffic Volume = L.Thrp.bits.UL
Uplink Traffic Volume of QCIn = L.Thrp.bits.UL.QCI.n
n = 1 to 9
Unit/Range bit
154 © 2017 Nokia

Average User Number
Description
The Average User Number KPI indicates the average number of users in RRC_Connected mode in a cell. This value is calculated based on samples. The
eNodeB records the number of users in the cell to be sampled every second and then calculates the average value of these samples throughout the measurement
period.
Definition
The Average User Number KPI is defined in Table 1. The formula is mapped to its corresponding counters.
Table 1.Average User Number
Name Average User Number

Formula AvgUserNumber
Associated Counters Average User Number = L.Traffic.User.Avg
Unit/Range NA
155 © 2017 Nokia

Maximum User Number
Description
The Maximum User Number KPI evaluates the maximum number of users in RRC_Connected mode of a cell in a certain period of time. This value is
calculated based on samples. The eNodeB records the number of users in the cell to be sampled every second and then calculates the maximum value of these
samples throughout the measurement period.
Definition
The Maximum User Number KPI is defined in Table 1. The formula is mapped to its corresponding counters.
Table 1.Maximum User Number
Name Maximum User Number

Formula MaxUserNumber
Associated Counters Maximum User Number = L.Traffic.User.Max
Unit/Range NA
156 © 2017 Nokia

Name Resource Block Utilizing Rate
Formula Resource Block Utilizing Rate
Associated
Counters
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.
157 © 2017 Nokia

Resource Block Utilizing Rate (Cont.)
Average number of used downlink PRBs
• Measurement Point: The number of used downlink PRBs in a cell is sampled per second. At the end of a measurement period, the average of these
sampling results is used as the value of the counter.
Average number of used uplink PRBs

• Measurement Point: The number of used downlink PRBs over the PUCCH in a cell is sampled per second. At the end of a measurement period, the
average of these sampling results is used as the value of the counter.
Associated Counters
L.ChMeas.PRB.DL.Used.Avg Average number of used downlink PRBs
L.ChMeas.PRB.UL.Used.Avg Average number of used uplink PRBs
L.ChMeas.PRB.PUCCH.Avg Average number of used PRBs over the PUCCH
158 © 2017 Nokia

Radio Bearer Number
• The radio bearers KPIs consist of nine sub-KPIs mapped to nine QCIs. This set of KPIs can be used to evaluate the average radio bearers in a cell or a
cluster. The radio bearer for each QCI is based on the number of active RRC connections for each QCI according to the QCI defined in the QoS
information.
• The number of DRBs for services with each QCI ranging from 1 to 9 in a cell is sampled per second. At the end of a measurement period, the maximum
of these sampling results is used as the corresponding counter value
• Number of DRBs in a Cell
Associated Counters

L.Traffic.DRB Number of DRBs in a cell
L.Traffic.DRB.QCI.1 -9 Number of DRBs for the service with QCI of 1-9 in a cell
L.Traffic.DRB.Max.QCI.1-9 Maximum number of DRBs for services with QCI 1-9 in a cell
L.Traffic.DRB.Max Maximum number of DRBs in a cell
159 © 2017 Nokia

Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• SRVCC
• Counter Query
• NPM4GS
160 © 2017 Nokia

VoLTE
161 © 2017 Nokia

VoLTE KPIs
• Accessibility
• Retainability
• Mobility
• Voice QOS
• Voice Quality
• Voice Capacity
• Throughput
162 © 2017 Nokia

VoLTE Basic Call Process
AS
1. Power on a VoLTE UE to initiate an attach
procedure.
2. Start an IMS PDN connection setup procedure to
IMS CSCF
obtain the IMS IP address and set up default
signaling bearers.
3. Enable the UE to register with the IMS network on
the established IMS signaling bearers.
4. The UE initiates an HD voice call or VP call to
SAE-PGW SAE-PGW another VoLTE UE. The P-CSCF initiates dedicated
bearer setup for voice services over the Rx interface.
5. The IMS starts an addressing call to the called party
EPC
MME and triggers a voice bearer setup for the called party.
The called phone rings.
LTE LTE
6. The called party answers the phone and the call is
established.
163 © 2017 Nokia

VoLTE: Accessibility
Description
• The counters measure the number of successful E-RAB setups initiated by UEs for services with a specific QCI ranging from 1 to 9 and the total number
of successful E-RAB setups initiated by UEs in a cell. The E-RAB setup is initiated by a UE when the UE requests a service from the radio network. The
setup is implemented through the initial UE context setup or the E-RAB setup procedure.
• The signaling flows involved in the counter(s) comply with sections 19.2.2.3 and 19.2.2.4 in 3GPP TS 36.300 V10.6.0
Measurement Points
As shown at point B in Figure 1 or Figure 2, the corresponding counter is incremented based on the QCI of each service each time the eNodeB sends an E-
RAB SETUP RESPONSE or an INITIAL CONTEXT SETUP RESPONSE message to the MME. If the E-RAB SETUP RESPONSE or INITIAL CONTEXT
SETUP RESPONSE message reports multiple successful E-RAB setups at the same time, the corresponding counter is incremented by the number of
successful E-RAB setups in the message based on the QCI of each service. In addition, the number of successful E-RAB setups contained in the E-RAB
SETUP RESPONSE and INITIAL CONTEXT SETUP RESPONSE messages is accumulated as the value of the L.E-RAB.SuccEst counter.
164 © 2017 Nokia

VoLTE: Accessibility (Contd.)
E-RAB setup success rates of voice services
Description
Counters used to monitor the E-RAB setup success rates of voice services.
Counter ID Counter Name Counter Description

1526726668 L.E-RAB.AttEst.QCI.1 Number of E-RAB setup attempts initiated by UEs for services with the QCI of 1 in a cell
1526726676 L.E-RAB.AttEst.QCI.5 Number of E-RAB setup attempts initiated by UEs for services with the QCI of 5 in a cell
1526726669 L.E-RAB.SuccEst.QCI.1 Number of successful E-RAB setups initiated by UEs for services with the QCI of 1 in a cell
1526726677 L.E-RAB.SuccEst.QCI.5 Number of successful E-RAB setups initiated by UEs for services with the QCI of 5 in a cell
Number of E-RAB setup attempts initiated by UEs of a specified operator for services with the QCI of 1 in
1526727853 L.E-RAB.AttEst.PLMN.QCI.1
a cell
Number of E-RAB setup attempts initiated by UEs of a specified operator for services with the QCI of 5 in
1526727861 L.E-RAB.AttEst.PLMN.QCI.5
a cell
L.E- Number of successful E-RAB setups initiated by UEs of a specified operator for services with the QCI of 1
1526727854
RAB.SuccEst.PLMN.QCI.1 in a cell
L.E- Number of successful E-RAB setups initiated by UEs of a specified operator for services with the QCI of 5
1526727862
RAB.SuccEst.PLMN.QCI.5 in a cell
Formula
• E-RAB (QCI 1) setup success rate = L.E-RAB.SuccEst.QCI.1/L.E-RAB.AttEst.QCI.1
• E-RAB (QCI 5) setup success rate = L.E-RAB.SuccEst.QCI.5/L.E-RAB.AttEst.QCI.5
• E-RAB (QCI 1) setup success rate for a specific operator = L.E-RAB.SuccEst.PLMN.QCI.1/L.E-
RAB.AttEst.PLMN.QCI.1
• E-RAB (QCI 5) setup success rate for a specific operator = L.E-RAB.SuccEst.PLMN.QCI.5/L.E-
165 © 2017 Nokia
RAB.AttEst.PLMN.QCI.5
Description
The counters measure the number of successful E-RAB setups initiated by UEs for services with a specific QCI ranging from 1 to 9 and the total number of
successful E-RAB setups initiated by UEs in a cell. The E-RAB setup is initiated by a UE when the UE requests a service from the radio network. The setup is
implemented through the initial UE context setup or the E-RAB setup procedure.
The signaling flows involved in the counter(s) comply with sections 19.2.2.3 and 19.2.2.4 in 3GPP TS 36.300 V10.6.0
Measurement Points
As shown at point A in Figure 1, the corresponding counter (L.E-RAB.AbnormRel.eNBTot.QCI.1 to L.E-
RAB.AbnormRel.eNBTot.QCI.9,L.E-RAB.AbnormRel.eNBTot.QCI.65,L.E-
RAB.AbnormRel.eNBTot.QCI.66,L.E-RAB.AbnormRel.eNBTot.QCI.69 or L.E-
RAB.AbnormRel.eNBTot.QCI.70) is incremented based on the QCI of each service when the eNodeB sends an E-
RAB RELEASE INDICATION message to the MME and the release cause is not "Normal Release", "Detach",
"User Inactivity", "Om-Intervention", "CS Fallback triggered", "UE Not Available for PS Service", "Inter-
RAT Redirection", "Successful Handover", or "Redirection towards 1xRTT".
If the eNodeB determines that the E-RAB to be released carries data, the corresponding counter (L.E-
RAB.AbnormRel.QCI.1 to L.E-RAB.AbnormRel.QCI.9, L.E-RAB.AbnormRel.QCI.65, L.E-
RAB.AbnormRel.QCI.66, L.E-RAB.AbnormRel.QCI.69 or L.E-RAB.AbnormRel.QCI.70) is incremented.
If the E-RAB RELEASE INDICATION message requests to release multiple E-RABs at the same time, the
corresponding counter is incremented by the number of requested E-RAB releases in the message based on the QCI
of each service. If the UE is in high-speed movement, the number of abnormal releases of QCI-1 E-RABs is
counted in the L.E-RAB.AbnormRel.QCI.Hst.1 counter.
166 © 2017 Nokia

As shown at point A in Figure 2, when the eNodeB sends a UE CONTEXT RELEASE REQUEST message
to the MME, all E-RABs of the UE are released. In this case, the corresponding counter (L.E-
RAB.AbnormRel.eNBTot.QCI.1 to L.E-RAB.AbnormRel.eNBTot.QCI.9,L.E-
RAB.AbnormRel.eNBTot.QCI.65,L.E-RAB.AbnormRel.eNBTot.QCI.66,L.E-
RAB.AbnormRel.eNBTot.QCI.69 or L.E-RAB.AbnormRel.eNBTot.QCI.70) is incremented by the number
of E-RABs to be released based on the QCI of each service if the release cause is not "Normal Release",
"Detach", "User Inactivity", "Om-Intervention", "CS Fallback triggered", "UE Not Available for PS
Service", "Inter-RAT Redirection", "Time Critical Handover", "Handover Cancelled", or
"Redirection towards 1xRTT".
If the eNodeB determines that the E-RABs to be released carry data, the corresponding counter (L.E-
RAB.AbnormRel.QCI.1 to L.E-RAB.AbnormRel.QCI.9, L.E-RAB.AbnormRel.QCI.65, L.E-
RAB.AbnormRel.QCI.66, L.E-RAB.AbnormRel.QCI.69 or L.E-RAB.AbnormRel.QCI.70) is incremented.
If the UE is in high-speed movement, the number of abnormal releases of QCI-1 E-RABs is counted in the
L.E-RAB.AbnormRel.QCI.Hst.1 counter. If the cause value of an E-RAB release for load-based redirection
is "Reduce load in serving cell", the corresponding counter is not incremented. If multiple E-RABs have
been set up for the UE, the corresponding counters are incremented by the number of E-RABs. When the
MME sends a UE CONTEXT RELEASE COMMAND message to the eNodeB, the corresponding counter
is not incremented repeatedly.
The description about E-RABs with data in a buffer is from the description of "4.2.2.6" chapters in 3GPP TS
36.425 (V10.7.0) and "6.2.1" chapters in 3GPP TS 36.450 (V10.1.0).
167 © 2017 Nokia

VoLTE: Retainability
Description: Counters used to monitor the call drop rates of voice services

1526726686 L.E-RAB.AbnormRel.QCI.1 Number of abnormal E-RAB releases for services with the QCI of 1 in a cell
1526726694 L.E-RAB.AbnormRel.QCI.5 Number of abnormal E-RAB releases for services with the QCI of 5 in a cell
1526726687 L.E-RAB.NormRel.QCI.1 Number of normal E-RAB releases for services with the QCI of 1 in a cell
1526726695 L.E-RAB.NormRel.QCI.5 Number of normal E-RAB releases for services with the QCI of 5 in a cell
L.E- Number of abnormal releases of activated E-RABs of a specified operator for services with the QCI of 1 in a
1526727871
RAB.AbnormRel.PLMN.QCI.1 cell
L.E- Number of abnormal releases of activated E-RABs of a specified operator for services with the QCI of 5 in a
1526727879
RAB.AbnormRel.PLMN.QCI.5 cell
L.E-
1526727872 Number of normal E-RAB releases of a specified operator for services with the QCI of 1 in a cell
RAB.NormRel.PLMN.QCI.1
L.E-
1526727880 Number of normal E-RAB releases of a specified operator for services with the QCI of 5 in a cell
RAB.NormRel.PLMN.QCI.5
Call Drop Formula:

Call drop rate (QCI 1) = L.E-RAB.AbnormRel.QCI.1/(L.E-RAB.AbnormRel.QCI.1 + L.E-RAB.NormRel.QCI.1)
Call drop rate (QCI 5) = L.E-RAB.AbnormRel.QCI.5/(L.E-RAB.AbnormRel.QCI.5 + L.E-RAB.NormRel.QCI.5)
Call drop rate (QCI 1) for a specific operator = L.E-RAB.AbnormRel.PLMN.QCI.1/(L.E-RAB.AbnormRel.PLMN.QCI.1 + L.E-RAB.NormRel.PLMN.QCI.1)
Call drop rate (QCI 5) for a specific operator = L.E-RAB.AbnormRel.PLMN.QCI.5/(L.E-RAB.AbnormRel.PLMN.QCI.5 + L.E-RAB.NormRel.PLMN.QCI.5)
168 © 2017 Nokia

VoLTE: Mobility
Description:
The counters measure the number of successful intra-eNodeB intra-frequency outgoing handovers, the number of successful intra-eNodeB inter-frequency
outgoing handovers, and the number of successful intra-eNodeB inter-duplex-mode outgoing handovers for UEs performing voice services in a cell. If the
source cell and the target cell work on the same frequency and in the same duplex mode, the handover is an intra-frequency handover. If the source cell and the
target cell work on different frequencies and in the same duplex mode, the handover is an inter-frequency handover. If the source cell and the target cell work
in different duplex modes, the handover is an inter-duplex-mode handover.
The signaling flows involved in the counter(s) comply with sections 5.3.5.4 and 5.3.7 in 3GPP TS 36.331 V10.4.0.
Measurement Points
Figure 1 shows an intra-eNodeB handover. Figure 2 shows that the RRC connection is successfully
reestablished for a UE during an intra-eNodeB handover.
As shown at point C in Figure 1, during an intra-eNodeB handover, the corresponding counter is
incremented by 1 each time data in the buffer is forwarded after the target cell receives an RRC
Connection Reconfiguration Complete message from the UE and the eNodeB determines that the
UE is performing services with the QCI of 1.
As shown at point C in Figure 2, during an intra-eNodeB handover, after the RRC connection is
reestablished to the target cell for the UE, the corresponding counter is incremented by 1 each time
the target cell receives an RRC Connection Reestablishment Complete message from the UE and the
eNodeB determines that the UE is performing services with the QCI of 1.
169 © 2017 Nokia

VoLTE: Mobility (Contd.)
Measurement Points
As shown at point C in Figure 2, during an intra-eNodeB handover, after the RRC connection is
reestablished to the source cell for the UE, the corresponding counter is incremented by 1 each time the
source cell receives an RRC Connection Reestablishment Complete message from the UE and the
eNodeB determines that the UE is performing services with the QCI of 1.
The counters are measured as follows:
If the source cell and the target cell work on the same frequency, the
L.HHO.IntraeNB.IntraFreq.ExecSuccOut.VoIP counter is incremented by 1.
If the source cell and the target cell work on different frequencies, the
L.HHO.IntraeNB.InterFreq.ExecSuccOut.VoIP counter is incremented by 1.
If the source cell and the target cell work in different duplex modes, the
L.HHO.IntraeNB.InterFddTdd.ExecSuccOut.VoIP counter is incremented by 1.
170 © 2017 Nokia

Handover Success Rate (VoIP)
Description:
Counters used to monitor the handover success rates of voice services
Formula:
Intra-frequency handover success rates of voice services: (L.HHO.IntraeNB.IntraFreq.ExecSuccOut.VoIP + L.HHO.IntereNB.IntraFreq.ExecSuccOut.VoIP)/

(L.HHO.IntraeNB.IntraFreq.ExecAttOut.VoIP + L.HHO.IntereNB.IntraFreq.ExecAttOut.VoIP)
Inter-frequency handover success rates of voice services: (L.HHO.IntraeNB.InterFreq.ExecSuccOut.VoIP + L.HHO.IntereNB.InterFreq.ExecSuccOut.VoIP)/

(L.HHO.IntraeNB.InterFreq.ExecAttOut.VoIP + L.HHO.IntereNB.InterFreq.ExecAttOut.VoIP)
Inter-mode handover success rates of voice services:

(L.HHO.IntraeNB.InterFddTdd.ExecSuccOut.VoIP + L.HHO.IntereNB.InterFddTdd.ExecSuccOut.VoIP )/
(L.HHO.IntraeNB.InterFddTdd.ExecAttOut.VoIP + L.HHO.IntereNB.InterFddTdd.ExecAttOut.VoIP)
171 © 2017 Nokia

Associated Counters

Number of intra-eNodeB intra-frequency outgoing handover attempts for UEs performing voice
1526729526 L.HHO.IntraeNB.IntraFreq.PrepAttOut.VoIP
services in a cell
Number of intra-eNodeB inter-frequency outgoing handover attempts for UEs performing voice
1526729527 L.HHO.IntraeNB.InterFreq.PrepAttOut.VoIP
services in a cell
Number of inter-eNodeB intra-frequency outgoing handover attempts for UEs performing voice
1526729535 L.HHO.IntereNB.IntraFreq.PrepAttOut.VoIP
services in a cell
Number of inter-eNodeB inter-frequency outgoing handover attempts for UEs performing voice
1526729536 L.HHO.IntereNB.InterFreq.PrepAttOut.VoIP
services in a cell
Number of inter-eNodeB inter-duplex-mode outgoing handover attempts for UEs performing
1526729537 L.HHO.IntereNB.InterFddTdd.PrepAttOut.VoIP
voice services in a cell
Number of intra-eNodeB intra-frequency outgoing handover executions for UEs performing
1526729529 L.HHO.IntraeNB.IntraFreq.ExecAttOut.VoIP
Number of intra-eNodeB inter-frequency outgoing handover executions for UEs performing
1526729530 L.HHO.IntraeNB.InterFreq.ExecAttOut.VoIP
Number of inter-eNodeB intra-frequency outgoing handover executions for UEs performing
1526729538 L.HHO.IntereNB.IntraFreq.ExecAttOut.VoIP
Number of inter-eNodeB inter-frequency outgoing handover executions for UEs performing
1526729539 L.HHO.IntereNB.InterFreq.ExecAttOut.VoIP
172 © 2017 Nokia

Associated Counters

Number of inter-eNodeB inter-duplex-mode outgoing handover executions for UEs
1526729540 L.HHO.IntereNB.InterFddTdd.ExecAttOut.VoIP
performing voice services in a cell
Number of successful intra-eNodeB intra-frequency outgoing handovers for UEs performing
1526729532 L.HHO.IntraeNB.IntraFreq.ExecSuccOut.VoIP
Number of successful intra-eNodeB inter-frequency outgoing handovers for UEs performing
1526729533 L.HHO.IntraeNB.InterFreq.ExecSuccOut.VoIP
Number of successful inter-eNodeB intra-frequency outgoing handovers for UEs performing
1526729541 L.HHO.IntereNB.IntraFreq.ExecSuccOut.VoIP
Number of successful inter-eNodeB inter-frequency outgoing handovers for UEs performing
1526729542 L.HHO.IntereNB.InterFreq.ExecSuccOut.VoIP
L.HHO.IntereNB.InterFddTdd.ExecSuccOut.VoI Number of successful inter-eNodeB inter-duplex-mode outgoing handovers for UEs
1526729543
P performing voice services in a cell
Number of intra-eNodeB inter-duplex-mode outgoing handover attempts for UEs performing
1526729528 L.HHO.IntraeNB.InterFddTdd.PrepAttOut.VoIP
Number of intra-eNodeB inter-duplex-mode outgoing handover executions for UEs
1526729531 L.HHO.IntraeNB.InterFddTdd.ExecAttOut.VoIP
performing voice services in a cell
L.HHO.IntraeNB.InterFddTdd.ExecSuccOut.VoI Number of successful intra-eNodeB inter-duplex-mode outgoing handovers for UEs
1526729534
P performing voice services in a cell
173 © 2017 Nokia

VoLTE Voice Codec
Common speech codec standards for VoIP include the adaptive multirate (AMR) standards stipulated by the 3rd Generation Partnership Project (3GPP) and the
G.7 series standards stipulated by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T).
• AMR: An audio data compression scheme optimized for speech codec. It is now widely used in GERAN and UTRAN. AMR is classified into adaptive
multirate wideband (AMR-WB) and adaptive multirate narrowband (AMR-NB).
• G.711, also known as pulse code modulation (PCM), is primarily used in telephony. It supports a coding rate of 64 kbit/s.
• G.729, known for the high voice quality and low delay, is widely used in various domains of data communications. It supports a coding rate of 8 kbit/s
174 © 2017 Nokia

VoLTE Voice Codec (Contd.)
AMR
According to IR.94 (requirements on IMS video call services by the 3GPP), UEs must support H.264 Level 1.2
video codec. No requirement is enforced on other codec methods. AMR
VoLTE voice package encapsulation Frame
The Real-Time Transport Protocol (RTP) is used to encapsulate AMR packets, which are then transmitted using IP
RTP RTCP SIP/SDP
and UDP protocols.
RTP header
UDP UDP
The basic header of an RTP packet is 12 bytes.
UDP header
IP IP
A UDP packet header is 8 bytes.
E-RAB1 E-RAB2
IP header PDCP PDCP
The IP packet header of IPv4 is 20 bytes. The basic IP packet header of IPv6 is 40 bytes.
Speech Codec Type Size of a Silence Frame (Byte) Size of a Voice Frame (Byte) RLC UM RLC AM
AMR-WB (23.85kbps) 7 61
MAC
AMR-WB (12.65kbps) 7 33
AMR-NB (12.2kbps) 7 32 PHY
175 © 2017 Nokia

Factors Affecting Voice Quality
• The MOS is affected by the following factors: speech codec, E2E transmission delay, jitter, and packet loss rate.
• Speech Codec
Use the ASCOM tool as an example. When the POLQA SWB evaluation method and AMR-WB 23.85 kbit/s are used, the best MOS of a speech sample
is 4.14. When AMR-NB 12.2 kbit/s is used in this scenario, the best MOS is 3.1.
176 © 2017 Nokia

Factors Affecting E2E Transmission Delay
• Speech encoding and decoding delay: Refers to the duration from the time a UE collects voice
at the microphone to the time the voice frames are encoded into AMR-NB or AMR-WB code
streams; or the duration from the time AMR-NB or AMR-WB code streams are decoded into
voice frames to the time the voice is played at the earpiece.
• Air-interface transmission delay: which is affected by the eNodeB scheduling wait time and
error packet retransmission and segmentation.
• CN processing delay: Includes voice packet forwarding delay and voice transcoding delay (For
example, if an LTE UE dials a fixed-line number and the two calling parties use different speed
codec methods, transcoding must be performed by the MGW).
• Transport network delay: Refers to the delay on a transmission device or transmission link
over which a voice IP packet is transmitted.
Factors Affecting Packet Loss Rate and Jitter

• Air-interface signal quality: Poor air-interface quality may increase the packet error rate,
which results in more packet retransmission and segmentation. As a result, the number of lost
packets and jitters increases.
• Load of the eNodeB: When the eNodeB is heavily loaded (the CPU usage is high or the PRB
usage of some high-priority services is high), some voice packets cannot be scheduled in a
timely manner, causing packet loss or jitter.
• Packet loss or jitter on the transport network: which may increase the E2E packet loss rate or
the number of jitters.
177 © 2017 Nokia

VoLTE: Voice QoS
Description:
The counters measure the number of uplink PDCP SDUs discarded for services carried on DRBs per QCI in a cell.The measurement does not involve eMTC
Ues.
Measurement Points
The eNodeB checks whether uplink packets are discarded based on the continuity of PDCP SDU SNs and the number of packets that are discarded each time
the PDCP layer receives an uplink PDCP SDU. The corresponding counter is incremented by the number of discarded uplink PDCP SDUs per QCI. PDCP
SDUs that are discarded for services carried on DRBs with all standardized and extended QCIs and QCI 65,66,69,70 and PTT services are counted in the
L.Traffic.UL.PktLoss.Loss counter.
178 © 2017 Nokia

VoLTE: Voice QoS (Contd.)
Packet Loss Rate Packet Loss Rate
Associated Counters:
1526727961 L.Traffic.UL.PktLoss.Loss.QCI.1 Number of discarded uplink traffic PDCP SDUs for DRB services with QCI 1 in a cell
1526727962 L.Traffic.UL.PktLoss.Tot.QCI.1 Number of expected uplink traffic data packets for DRB services with QCI 1 in a cell
Number of discarded downlink traffic PDCP SDUs for DRB services with QCI 1 in a cell over the
1526727934 L.Traffic.DL.PktUuLoss.Loss.QCI.1
Uu interface
Number of transmitted downlink traffic PDCP SDUs for DRB services with QCI 1 in a cell over the
1526727935 L.Traffic.DL.PktUuLoss.Tot.QCI.1
Uu interface
1526726833 L.PDCP.Tx.Disc.Trf.SDU.QCI.1 Number of downlink traffic SDUs discarded by the PDCP layer for QCI 1 services in a cell
1526727889 L.PDCP.Tx.TotRev.Trf.SDU.QCI.1 Number of transmitted downlink traffic PDCP SDUs for QCI 1 services in a cell
Total number of discarded uplink PDCP SDUs for traffic services with QCI 1 for a specific operator
1526736684 L.Traffic.UL.PktLoss.Loss.PLMN.QCI.1
in a cell
Total number of expected uplink data packets for DRB services with QCI 1 for a specific operator in
1526736686 L.Traffic.UL.PktLoss.Tot.PLMN.QCI.1
a cell
179 © 2017 Nokia

Associated Counters:
Total number of discarded downlink PDCP SDUs for traffic services with QCI 1 for a
1526736737 L.Traffic.DL.PktUuLoss.Loss.PLMN.QCI.1
specific operator in a cell
Total number of expected downlink data packets for DRB services with QCI 1 for a specific
1526736739 L.Traffic.DL.PktUuLoss.Tot.PLMN.QCI.1
operator in a cell
Number of downlink traffic SDUs discarded by the PDCP layer for QCI 1 services for a
1526736680 L.PDCP.Tx.Disc.Trf.SDU.PLMN.QCI.1
specific operator in a cell
Number of transmitted downlink traffic PDCP SDUs for QCI 1 services for a specific
1526736682 L.PDCP.Tx.TotRev.Trf.SDU.PLMN.QCI.1
operator in a cell
Number of uplink PDCP SDUs discarded for QCI 1 services carried on DRBs of cell-edge
1526745995 L.Traffic.UL.FarUE.PktLoss.Loss.QCI.1
UEs in a cell
Number of expected uplink PDCP SDUs for QCI 1 services carried on DRBs of cell-edge
1526745997 L.Traffic.UL.FarUE.PktLoss.Tot.QCI.1
UEs in a cell
L.Traffic.UL.FarUE.PktLoss.Loss.QCI.1.Index Number of uplink PDCP SDUs discarded for QCI 1 services carried on DRBs of cell-edge
1526745996
0 UEs in a cell
180 © 2017 Nokia

Description:
The counters measure the number of uplink PDCP SDUs discarded for services carried on DRBs per QCI in a cell.The measurement does not involve eMTC
Ues.
Measurement Points
The eNodeB checks whether uplink packets are discarded based on the continuity of PDCP SDU SNs and the number of packets that are discarded each time
the PDCP layer receives an uplink PDCP SDU. The corresponding counter is incremented by the number of discarded uplink PDCP SDUs per QCI. PDCP
SDUs that are discarded for services carried on DRBs with all standardized and extended QCIs and QCI 65,66,69,70 and PTT services are counted in the
L.Traffic.UL.PktLoss.Loss counter.
181 © 2017 Nokia

Formula: KPI Name Formula

Uplink packet loss rate on the Uu interface for QCI 1 L.Traffic.UL.PktLoss.Loss.QCI.1/L.Traffic.UL.PktLoss.Tot.QCI.1
Downlink packet loss rate on the Uu interface for QCI 1 L.Traffic.DL.PktUuLoss.Loss.QCI.1/L.Traffic.DL.PktUuLoss.Tot.QCI.1
L.PDCP.Tx.Disc.Trf.SDU.QCI.1/
Downlink PDCP packet discard rate (L.PDCP.Tx.Disc.Trf.SDU.QCI.1 + L.PDCP.Tx.TotRev.Trf.SDU.QCI.1)
Uplink packet loss rate on the Uu interface for QCI 1 of a
specific operator L.Traffic.UL.PktLoss.Loss.PLMN.QCI.1/L.Traffic.UL.PktLoss.Tot.PLMN.QCI.1
Downlink packet loss rate on the Uu interface for QCI 1 of a
specific operator L.Traffic.DL.PktUuLoss.Loss.PLMN.QCI.1/L.Traffic.DL.PktUuLoss.Tot.PLMN.QCI.1
L.PDCP.Tx.Disc.Trf.SDU.PLMN.QCI.1/
Downlink PDCP packet discard rate for a specific operator (L.PDCP.Tx.Disc.Trf.SDU.QCI.1 + L.PDCP.Tx.TotRev.Trf.SDU.PLMN.QCI.1)
Uplink packet loss rate on the Uu interface for QCI 1 in
weak-coverage areas (uplink path loss ranging within [135
dB, inf)) L.Traffic.UL.FarUE.PktLoss.Loss.QCI.1/L.Traffic.UL.FarUE.PktLoss.Tot.QCI.1
Uplink packet loss rate on the Uu interface for QCI in weak-
coverage areas L.Traffic.UL.FarUE.PktLoss.Loss.QCI.1.Index0/L.Traffic.UL.FarUE.PktLoss.Tot.QCI.1.Index0
182 © 2017 Nokia

VoLTE: Voice Quality
Description:
The counters measure the uplink or downlink voice quality of AMR-WB and AMR-NB speech services in a cell when the VQMAlgoSwitch parameter in the
ENodeBAlgoSwitch MO is set to VQM_ALGO_SWITCH_AMR_ON or VQM_ALGO_SWITCH_ADAPTIVE_ON.
Measurement Points
In a voice quality monitoring (VQM) period specified by VQMALGO.VQMAlgoPeriod, the uplink and downlink VQIs of VoLTE UEs running AMR-WB
services and AMR-NB services are calculated. The corresponding counter is incremented by 1 each time the E2E VQI of a VoLTE UE running an AMR-WB
service is at a specified speech quality level. The speech quality can be classified into five levels: Bad, Poor, Accept, Good, and Excellent.
183 © 2017 Nokia

VoLTE: Voice Quality (Contd.)
Average value of E2E VQIs of AMR-WB and AMR-NB services in a cell:
E2E VQI (Average) = L.Voice.E2EVQI.TotalValue/[(L.Voice.E2EVQI.Excellent.Times + L.Voice.E2EVQI.Good.Times + L.Voice.E2EVQI.Accept.Times

+ L.Voice.E2EVQI.Poor.Times + L.Voice.E2EVQI.Bad.Times) x 100]
Average value of E2E VQIs of AMR-WB services in a cell:
AMR-WB E2E VQI (Average) = L.Voice.E2EVQI.AMRWB.TotalValue/[(L.Voice.E2EVQI.AMRWB.Excellent.Times +

L.Voice.E2EVQI.AMRWB.Good.Times
+ L.Voice.E2EVQI.AMRWB.Accept.Times + L.Voice.E2EVQI.AMRWB.Poor.Times + L.Voice.E2EVQI.AMRWB.Bad.Times) x 100]
Average value of uplink VQIs of AMR-WB and AMR-NB services in a cell:
UL VQI (Average) = L.Voice.VQI.UL.TotalValue/[(L.Voice.VQI.UL.Excellent.Times + L.Voice.VQI.UL.Good.Times + L.Voice.VQI.UL.Accept.Times

+ L.Voice.VQI.UL.Poor.Times + L.Voice.VQI.UL.Bad.Times) x 100]
Average value of uplink VQIs of AMR-WB services in a cell:
AMR-WB UL VQI (Average)= L.Voice.VQI.AMRWB.UL.TotalValue/[(L.Voice.VQI.AMRWB.UL.Excellent.Times +

L.Voice.VQI.AMRWB.UL.Good.Times
+ L.Voice.VQI.AMRWB.UL.Accept.Times + L.Voice.VQI.AMRWB.UL.Poor.Times + L.Voice.VQI.AMRWB.UL.Bad.Times) x 100]
184 © 2017 Nokia

Average value of uplink VQIs of EVS services in a cell:
EVS UL VQI (Average) = L.Voice.VQI.EVS.UL.TotalValue/[(L.Voice.VQI.EVS.UL.Excellent.Times + L.Voice.VQI.EVS.UL.Good.Times +

+ L.Voice.VQI.EVS.UL.Accept.Times + L.Voice.VQI.EVS.UL.Poor.Times + L.Voice.VQI.EVS.UL.Bad.Times) x 100
Average value of downlink VQIs of AMR-WB and AMR-NB services in a cell:
DL VQI (Average) = L.Voice.VQI.DL.TotalValue/[(L.Voice.VQI.DL.Excellent.Times + L.Voice.VQI.DL.Good.Times + L.Voice.VQI.DL.Accept.Times

+ L.Voice.VQI.DL.Poor.Times + L.Voice.VQI.DL.Bad.Times) x 100]
Average value of downlink VQIs of AMR-WB services in a cell:
AMR-WB DL VQI (Average) = L.Voice.VQI.AMRWB.DL.TotalValue/[(L.Voice.VQI.AMRWB.DL.Excellent.Times +

+ L.Voice.VQI.AMRWB.DL.Good.Times + L.Voice.VQI.AMRWB.DL.Accept.Times + L.Voice.VQI.AMRWB.DL.Poor.Times + L.Voice.VQI.AMRWB.DL
.Bad.Times) x 100]
Average value of downlink VQIs of EVS services in a cell:
EVS DL VQI (Average) = L.Voice.VQI.EVS.DL.TotalValue/[(L.Voice.VQI.EVS.DL.Excellent.Times + L.Voice.VQI.EVS.DL.Good.Times

+ L.Voice.VQI.EVS.DL.Accept.Times + L.Voice.VQI.EVS.DL.Poor.Times + L.Voice.VQI.EVS.DL.Bad.Times) x 100)
185 © 2017 Nokia

Counters with the voice quality being Excellent

1526728411 L.Voice.VQI.UL.Excellent.Times Number of times uplink voice quality is Excellent
1526728416 L.Voice.VQI.DL.Excellent.Times Number of times downlink voice quality is Excellent
1526732687 L.Voice.VQI.AMRWB.UL.Excellent.Times Number of times uplink voice quality of AMR-WB services is Excellent
1526732692 L.Voice.VQI.AMRWB.DL.Excellent.Times Number of times downlink voice quality of AMR-WB services is Excellent
1526736660 L.Voice.VQI.UL.Excellent.Times.PLMN Number of times uplink voice quality is Excellent for a specific operator in a cell
1526736665 L.Voice.VQI.DL.Excellent.Times.PLMN Number of times downlink voice quality is Excellent for a specific operator in a cell
L.Voice.VQI.AMRWB.UL.Excellent.Times.PL Number of times uplink voice quality of AMR-WB services is Excellent for a specific
1526736670
MN operator in a cell
L.Voice.VQI.AMRWB.DL.Excellent.Times.PL Number of times downlink voice quality of AMR-WB services is Excellent for a specific
1526736675
MN operator in a cell
1526741669 L.Voice.E2EVQI.Excellent.Times Number of times E2E VQIs are Excellent
1526741674 L.Voice.E2EVQI.AMRWB.Excellent.Times Number of times E2E VQIs of AMR-WB services are Excellent
1526745678 L.Voice.VQI.EVS.UL.Excellent.Times Number of times the uplink VQI of EVS services is Excellent
1526745683 L.Voice.VQI.EVS.DL.Excellent.Times Number of times the downlink VQI of EVS services is Excellent
186 © 2017 Nokia

Counters related to the total value of voice quality
1526741679 L.Voice.E2EVQI.TotalValue Total value of E2E VQIs

1526741680 L.Voice.E2EVQI.AMRWB.TotalValue Total value of E2E VQIs of AMR-WB services
1526741681 L.Voice.VQI.UL.TotalValue Total value of uplink VQIs
1526741682 L.Voice.VQI.DL.TotalValue Total value of downlink VQIs
1526741683 L.Voice.VQI.AMRWB.UL.TotalValue Total value of uplink VQIs of AMR-WB services
1526741684 L.Voice.VQI.AMRWB.DL.TotalValue Total value of downlink VQIs of AMR-WB services
1526745688 L.Voice.VQI.EVS.UL.TotalValue Total value of uplink VQIs of EVS services
1526745689 L.Voice.VQI.EVS.DL.TotalValue Total value of downlink VQIs of EVS services
187 © 2017 Nokia

Counters with the voice quality being Good

1526728412 L.Voice.VQI.UL.Good.Times Number of times uplink voice quality is Good
1526728417 L.Voice.VQI.DL.Good.Times Number of times downlink voice quality is Good
1526732688 L.Voice.VQI.AMRWB.UL.Good.Times Number of times uplink voice quality of AMR-WB services is Good
1526732693 L.Voice.VQI.AMRWB.DL.Good.Times Number of times downlink voice quality of AMR-WB services is Good
1526736661 L.Voice.VQI.UL.Good.Times.PLMN Number of times uplink voice quality is Good for a specific operator in a cell
1526736666 L.Voice.VQI.DL.Good.Times.PLMN Number of times downlink voice quality is Good for a specific operator in a cell
L.Voice.VQI.AMRWB.UL.Good.Times.PL Number of times uplink voice quality of AMR-WB services is Good for a specific operator in a
1526736671
MN cell
L.Voice.VQI.AMRWB.DL.Good.Times.PL Number of times downlink voice quality of AMR-WB services is Good for a specific operator in
1526736676
MN a cell
1526741670 L.Voice.E2EVQI.Good.Times Number of times E2E VQIs are Good
1526741675 L.Voice.E2EVQI.AMRWB.Good.Times Number of times E2E VQIs of AMR-WB services are Good
1526745679 L.Voice.VQI.EVS.UL.Good.Times Number of times the uplink VQI of EVS services is Good
1526745684 L.Voice.VQI.EVS.DL.Good.Times Number of times the downlink VQI of EVS services is Good
188 © 2017 Nokia

Counters with the voice quality being Accept

1526728413 L.Voice.VQI.UL.Accept.Times Number of times uplink voice quality is Accept
1526728418 L.Voice.VQI.DL.Accept.Times Number of times downlink voice quality is Accept
1526732689 L.Voice.VQI.AMRWB.UL.Accept.Times Number of times uplink voice quality of AMR-WB services is Accept
1526732694 L.Voice.VQI.AMRWB.DL.Accept.Times Number of times downlink voice quality of AMR-WB services is Accept
1526736662 L.Voice.VQI.UL.Accept.Times.PLMN Number of times uplink voice quality is Accept for a specific operator in a cell
1526736667 L.Voice.VQI.DL.Accept.Times.PLMN Number of times downlink voice quality is Accept for a specific operator in a cell
Number of times uplink voice quality of AMR-WB services is Accept for a specific
1526736672 L.Voice.VQI.AMRWB.UL.Accept.Times.PLMN
operator in a cell
Number of times downlink voice quality of AMR-WB services is Accept for a specific
1526736677 L.Voice.VQI.AMRWB.DL.Accept.Times.PLMN
operator in a cell
1526741671 L.Voice.E2EVQI.Accept.Times Number of times E2E VQIs are Accept
1526741676 L.Voice.E2EVQI.AMRWB.Accept.Times Number of times E2E VQIs of AMR-WB services are Accept
1526745680 L.Voice.VQI.EVS.UL.Accept.Times Number of times the uplink VQI of EVS services is Accept
1526745685 L.Voice.VQI.EVS.DL.Accept.Times Number of times the downlink VQI of EVS services is Accept
189 © 2017 Nokia

Counters with the voice quality being Poor

1526728414 L.Voice.VQI.UL.Poor.Times Number of times uplink voice quality is Poor
1526728419 L.Voice.VQI.DL.Poor.Times Number of times downlink voice quality is Poor
1526732690 L.Voice.VQI.AMRWB.UL.Poor.Times Number of times uplink voice quality of AMR-WB services is Poor
1526732695 L.Voice.VQI.AMRWB.DL.Poor.Times Number of times downlink voice quality of AMR-WB services is Poor
1526732890 L.Voice.NormRel.UL.LowQuality Number of normally released voice calls (poor uplink voice quality)
1526732891 L.Voice.NormRel.DL.LowQuality Number of normally released voice calls (poor downlink voice quality)
1526736663 L.Voice.VQI.UL.Poor.Times.PLMN Number of times uplink voice quality is Poor for a specific operator in a cell
1526736668 L.Voice.VQI.DL.Poor.Times.PLMN Number of times downlink voice quality is Poor for a specific operator in a cell
Number of times uplink voice quality of AMR-WB services is Poor for a specific operator in a
1526736673 L.Voice.VQI.AMRWB.UL.Poor.Times.PLMN
cell
Number of times downlink voice quality of AMR-WB services is Poor for a specific operator in
1526736678 L.Voice.VQI.AMRWB.DL.Poor.Times.PLMN
a cell
1526741672 L.Voice.E2EVQI.Poor.Times Number of times E2E VQIs are Poor
1526741677 L.Voice.E2EVQI.AMRWB.Poor.Times Number of times E2E VQIs of AMR-WB services are Poor
1526745681 L.Voice.VQI.EVS.UL.Poor.Times Number of times the uplink VQI of EVS services is Poor
1526745686 L.Voice.VQI.EVS.DL.Poor.Times Number of times the downlink VQI of EVS services is Poor
190 © 2017 Nokia

Counters with the voice quality being Poor

1526728415 L.Voice.VQI.UL.Bad.Times Number of times uplink voice quality is Bad
1526728420 L.Voice.VQI.DL.Bad.Times Number of times downlink voice quality is Bad
1526732691 L.Voice.VQI.AMRWB.UL.Bad.Times Number of times uplink voice quality of AMR-WB services is Bad
1526732696 L.Voice.VQI.AMRWB.DL.Bad.Times Number of times downlink voice quality of AMR-WB services is Bad
1526732892 L.Voice.UL.Silent.Num Number of times uplink voice call is silent
1526732893 L.Voice.DL.Silent.Num Number of times downlink voice call is silent
1526736664 L.Voice.VQI.UL.Bad.Times.PLMN Number of times uplink voice quality is Bad for a specific operator in a cell
1526736669 L.Voice.VQI.DL.Bad.Times.PLMN Number of times downlink voice quality is Bad for a specific operator in a cell
1526736674 L.Voice.VQI.AMRWB.UL.Bad.Times.PLMN Number of times uplink voice quality of AMR-WB services is Bad for a specific operator in a cell
Number of times downlink voice quality of AMR-WB services is Bad for a specific operator in a
1526736679 L.Voice.VQI.AMRWB.DL.Bad.Times.PLMN
cell
1526741673 L.Voice.E2EVQI.Bad.Times Number of times E2E VQIs are Bad
1526741678 L.Voice.E2EVQI.AMRWB.Bad.Times Number of times E2E VQIs of AMR-WB services are Bad
1526745682 L.Voice.VQI.EVS.UL.Bad.Times Number of times the uplink VQI of EVS services is Bad
1526745687 L.Voice.VQI.EVS.DL.Bad.Times Number of times the downlink VQI of EVS services is Bad
191 © 2017 Nokia

VoLTE: Voice Capacity
Description:
The counters measure the average number of UEs that have data with a specific QCI in the downlink buffer in a cell.
Measurement Points
The counters are measured based on the user state at the sampling time. The number of UEs in RRC_CONNECTED mode that have data in the downlink
buffer with a specific QCI (standardized or extended QCI) in a cell is sampled per millisecond. At the end of a measurement period, the average of these
sampling results is used as the values of the corresponding counters. The sum of these values is used as the value of the L.Traffic.ActiveUser.DL.QCI.Total
counter.
192 © 2017 Nokia

VoLTE: Voice Capacity (Contd.)
Number of UEs with Voice Services
Description:
Counters used to monitor the number of UEs with voice services

1526728456 L.Traffic.ActiveUser.DL.QCI.1 Number of activated UEs with QCI 1 in the downlink buffer
1526728446 L.Traffic.ActiveUser.UL.QCI.1 Number of activated UEs with QCI 1 in the uplink buffer
1526730601 L.Traffic.ActiveUser.DL.QCI.1.Max Maximum number of activated UEs with QCI 1 in the downlink buffer
1526730611 L.Traffic.ActiveUser.UL.QCI.1.Max Maximum number of activated UEs with QCI 1 in the uplink buffer
1526732721 L.Traffic.User.VoIP.Avg Average number of VoIP UEs in a cell
1526732722 L.Traffic.User.VoIP.Max Maximum number of VoIP UEs in a cell
1526736692 L.Traffic.User.VoIP.Avg.PLMN Average number of VoIP UEs of a specific operator in a cell
1526736693 L.Traffic.User.VoIP.Max.PLMN Maximum number of VoIP UEs of a specific operator in a cell
193 © 2017 Nokia

VoLTE: Voice Capacity (Contd.)
Description:
Counters used to monitor the average number of PRBs occupied by voice services

1526730883 L.ChMeas.PRB.DL.DrbUsed.Avg.VoIP Average number of PRBs used by DRBs on the PDSCH for downlink VoIP services
1526730884 L.ChMeas.PRB.UL.DrbUsed.Avg.VoIP Average number of PRBs used by DRBs on the PUSCH for uplink VoIP services
194 © 2017 Nokia

VoLTE: Voice Throughput
The counters measure the following items:
• Number of available CCEs in a cell
• Number of PDCCH CCEs used for uplink DCI in a cell
• Number of PDCCH CCEs used for downlink DCI in a cell (including only downlink PDCCH CCEs in the UE-specific search spaces)
• Number of PDCCH CCEs used for common DCI in a cell (including downlink PDCCH CCEs in the common search spaces such as CCEs used
for power control in semi-persistent scheduling, CCEs used by paging messages, CCEs used by system information, and CCEs used by RAR
messages)
• Number of PDCCH CCEs used for TA measurement in a cell
• Number of PDCCH CCEs used for initial transmitted downlink data in a cell
• Number of PDCCH CCEs used for initial transmitted downlink signaling in a cell
• Number of PDCCH CCEs used for initial transmitted uplink signaling in a cell
• Number of PDCCH CCEs used for initial transmitted downlink MCEs in a cell
• Number of PDCCH CCEs equivalent to the reference power used for DCI.
195 © 2017 Nokia

VoLTE: Throughput (Contd.)
Where,
The L.ChMeas.CCE.DLUsed.DRB counter measures the number of PDCCH CCEs used for initial transmitted data scheduled on DRBs.
The L.ChMeas.CCE.DLUsed.SRB counter measures the number of PDCCH CCEs used for initial transmitted signaling scheduled on SRB0, SRB1, and SRB 2.
The value of the. L.ChMeas.CCE.DLUsedEquivalent or L.ChMeas.CCE.ULUsed.Equivalent counter equals the total power consumed by PDCCH CCEs used
for downlink or uplink DCI divided by the reference power of a CCE, respectively.
The reference power is a fixed power calculated based on the offset of the DCI power related to the cell-specific reference signal power when the PDCCH
carries dedicated DCI if the PdcchPcSwitch option in the DlPcAlgoSwitch parameter is cleared. The cell-specific reference signal power is specified by the
ReferenceSignalPwr parameter.
The counters measure the number of available CCEs in a cell, the numbers of PDCCH CCEs used by uplink DCI (including DCI 0), downlink DCI (including
DCI 1, DCI 1A, DCI 1B, DCI 1C, DCI 1D, DCI 2, DCI 2A, and DCI 2B), and common DCI (including DCI 3 and DCI 3A) in a cell, the number of PDCCH
CCEs used for TA measurement in a cell, the number of PDCCH CCEs used by initial transmitted downlink data in a cell, the number of PDCCH CCEs used
by initial transmitted downlink signaling in a cell, the number of PDCCH CCEs used by initial transmitted downlink MCEs in a cell, and the number of
PDCCH CCEs equivalent to the reference power used by DCI.
196 © 2017 Nokia

Where,
The L.ChMeas.CCE.DLUsed.DRB counter measures the number of PDCCH CCEs used for initial transmitted data scheduled on DRBs.
The L.ChMeas.CCE.DLUsed.SRB counter measures the number of PDCCH CCEs used for initial transmitted signaling scheduled on SRB0, SRB1, and SRB 2.
The value of the L.ChMeas.CCE.DLUsed.Equivalent or L.ChMeas.CCE.ULUsed.Equivalent counter equals the total power consumed by PDCCH CCEs used
for downlink or uplink DCI divided by the reference power of a CCE, respectively.
The reference power is a fixed power calculated based on the offset of the DCI power related to the cell-specific reference signal power when the PDCCH
carries dedicated DCI if the PdcchPcSwitch option in the DlPcAlgoSwitch parameter is cleared. The cell-specific reference signal power is specified by the
ReferenceSignalPwr parameter.
The L.ChMeas.CCE.ULUsed.VoIP counter measures the number of PDCCH CCEs used for uplink VoIP services that are correctly demodulated.
The L.ChMeas.CCE.DLUsed.VoIP counter measures the number of PDCCH CCEs used for downlink VoIP services.
197 © 2017 Nokia

Measurement Points
The following items are measured within a measurement period in a cell:
• Number of available PDCCH CCEs
• Number of PDCCH CCEs used by each category of DCI
• Number of PDCCH CCEs used for different purposes in the downlink
• Numbers of PDCCH CCEs with the CCE power equivalent to the reference power used for uplink and downlink DCI
• Number of PDCCH CCEs allocated for TA measurement
• Numbers of PDCCH CCEs used for uplink and downlink VoIP services
The internal timer of the eNodeB has a deviation of one period, and therefore the measurement result of the counter has a deviation.
198 © 2017 Nokia

Counters used to monitor the total uplink/downlink traffic volume of voice services

1526726776 L.Thrp.bits.UL.QCI.1 Uplink traffic volume for PDCP PDUs of QCI 1 services in a cell
1526726803 L.Thrp.bits.DL.QCI.1 Downlink traffic volume for PDCP SDUs of QCI 1 services in a cell
1526726777 L.Thrp.Time.UL.QCI.1 Receive duration of uplink PDCP PDUs for QCI 1 services in a cell
1526726804 L.Thrp.Time.DL.QCI.1 Transmit duration of downlink PDCP SDUs for QCI 1 services in a cell
1526727849 L.Thrp.bits.UL.PLMN.QCI.1 Uplink traffic volume for PDCP PDUs of QCI 1 services in a cell
1526727850 L.Thrp.Time.UL.PLMN.QCI.1 Receive duration of uplink PDCP PDUs for QCI 1 services in a cell
1526728050 L.Thrp.bits.DL.PLMN.QCI.1 Downlink traffic volume for PDCP SDUs of QCI 1 services in a cell
1526728051 L.Thrp.Time.DL.PLMN.QCI.1 Transmit duration of downlink PDCP SDUs for QCI 1 services in a cell
Formula for Throughput
Class Type KPI Mapped Counters

Service Integrity Average uplink throughput of QCI 1 services L.Thrp.bits.UL.QCI.1/L.Thrp.Time.UL.QCI.1
Service Integrity Average downlink throughput of QCI 1 services L.Thrp.bits.DL.QCI.1/L.Thrp.Time.DL.QCI.1
Service Integrity Average uplink throughput of QCI 1 services for a specific operator L.Thrp.bits.UL.PLMN.QCI.1/L.Thrp.Time.UL.PLMN.QCI.1
Service Integrity Average downlink throughput of QCI 1 services for a specific operator L.Thrp.bits.DL.PLMN.QCI.1/L.Thrp.Time.DL.PLMN.QCI.1
199 © 2017 Nokia

Counters used to monitor the number of PDCCH CCEs used by voice services

1526736735 L.ChMeas.CCE.ULUsed.VoIP Number of PDCCH CCEs used for uplink VoIP services
1526736736 L.ChMeas.CCE.DLUsed.VoIP Number of PDCCH CCEs used for downlink VoIP services
200 © 2017 Nokia

VoLTE: Latency
Counters used to monitor the Latency

1526727907 L.Traffic.DL.PktDelay.Time.QCI.1 Total processing delay of downlink PDCP SDUs for DRB services with the QCI of 1 in a cell
Number of successfully transmitted downlink PDCP SDUs for DRB services with the QCI of 1 in a
1526727908 L.Traffic.DL.PktDelay.Num.QCI.1
cell
High latency will show an issue with end user satisfaction as Voice is more delay sensitive that data traffic.
Check the number of active QCI 1 UEs and total Active UEs in a cell if high latency is experienced on a cell. Also TTI bundling usage needs to be
monitored.
201 © 2017 Nokia

Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• SRVCC
• Counter Query
• NPM4GS
202 © 2017 Nokia

SRVCC
203 © 2017 Nokia

SRVCC
• SRVCC Networking
• SRVCC Procedure
• SRVCC Charging
• SRVCC Deployment
• SRVCC Restrictions and Constraints
204 © 2017 Nokia

SRVCC Networking
E-MSC
Um/Uu Iu-CS/A
BTS/
SGSN Sv
NodeB Iu/Gb
HSS
Gn/S3 S6a
IMS CN
S1-C S11
Uu S1-U SGi
eNodeB S-GW
In the SRVCC solution, the Sv interface need to be added between the MME and the MSC.
In addition, the eNodeB, MME, S-GW/P-GW, PCRF, MSC, and HSS functions need to be enhanced.
After implementing handover decision based on the measurement report sent by the UE, the eNodeB sends a handover request message to the MME.
After receiving the handover request message from the eNodeB, the MME sends the handover request message to the MSC to complete the voice
handover to the GSM/UMTS network.
205 © 2017 Nokia

SRVCC Procedure
Target
UE E-UTRAN MME MSC Server UTRAN/ SCC AS
GERAN
1.Measurement
Reports
2.Handover to UTRAN/GERAN
required
3.Initiates SRVCC for voice

component
4.Handles PS-PS HO 5.CS handover preparation

for non-voice if
6.IMS Service Continuity Procedure
needed
8.To eUTRAN
7.PS HO response to MME
Coordinates SRVCC
(CS resources)
9.Handover CMD and PS HO response
10.Handover
execution
206 © 2017 Nokia

SRVCC Procedure (Contd.)
1. The UE sends a measurement report to the eNodeB, and the eNodeB determines whether handover is supported.
2. After determining to implement handover, the eNodeB sends a handover request message to the MME. After receiving the handover request message, the
MME separates voice from all the bearers.
3. The MME sends a PS to CS handover request message to the MSC.
4. The MME determines whether to implement PS to PS handover according to the target network capability. For emergency services, the MME needs to
send the emergency service indication, IMEI, and E-STN-SR to the MSC over the Sv interface.
5. After receiving the PS to CS handover request message from the MME, the MSC sends a handover request message to the BSS to request radio resources.
6. The target MSC and target RAN set up session resources and start the handover process. Then, the SCC AS starts Session Transfer on the CN side.
7. The target SGSN responds the PS-PS handover request message, and the MSC responds the PS-CS handover request message.
8. After receiving the response messages, the MME sends a handover instruction message to the eNodeB.
9. The eNodeB sends a handover instruction message to the UE.
10. The UE implements the handover to the GSM/UMTS network.
207 © 2017 Nokia

SRCVV Handover Cancellation
eNodeB-Initiated Handover Cancellation
Source UTRAN/ Source SGSN/ MSC Server/

UE IMS
E-UTRAN MME MGW
1. SRVCC procedure started, SRVCC PS to CS request sent to

MSC Server
2. MSC Server initiated Session Transfer procedure with

IMS using STN-SR.
3. Relocation/Handover Cancel
4. PS to CS Cancel Notification
Handover cancellation
procedures (23.009)
5. PS to CS Cancel Notification Ack (Session Transfer started)

6. Session Reestablishment trigger notification
7. re-establish the
session
208 © 2017 Nokia

SRCVV Handover Cancellation (Contd.)
eNodeB-Initiated Handover Cancellation
1. After receiving a request from the UE, the Source eNodeB sends the SRVCC handover request to the MME. Then, the MME sends a PS to CS request to
the MSC server over the Sv interface.
2. After receiving the PS to CS request, the MSC Server sends a handover request to the BSS to require for radio resources.
3. The Source eNodeB sends a handover cancel message after sending a handover request. The cancellation can be triggered in various situations, for
example, due to changes in signal strength or radio resources.
4. After receiving the handover cancellation from the eNodeB, the MME notifies the MSC Server of the handover cancellation.
5. The MSC Server cancels the ongoing SRVCC handover operations. If the MSC Server has instructed the MME to start the SRVCC handover, the MME
instructs the UE to reestablish the IMS session.
6. The UE reestablishes the session
209 © 2017 Nokia

SRVCC KPIs
Description:
The counter measures the number of inter-RAT handover attempts from E-UTRAN to WCDMA network for SRVCC in a cell.
The signaling flows involved in the counter(s) comply with section 8.4.1 in 3GPP TS 36.413 V10.4.0.
Measurement Points
As shown at point A in Figure 1, the L.IRATHO.SRVCC.E2W.PrepAttOut counter is incremented by 1 each time the eNodeB decides to perform an inter-RAT
blind handover from E-UTRAN to WCDMA network or the eNodeB decides to perform an inter-RAT handover from E-UTRAN to WCDMA network for
SRVCC after the eNodeB receives a measurement report from the UE.
210 © 2017 Nokia

Performance Monitoring-SRVCC (Contd.)
Performance counters for monitoring SRVCC to UTRAN
Counter ID Counter Name Description

1526728400 L.IRATHO.SRVCC.E2W.PrepAttOut Number of inter-RAT handover attempts from E-UTRAN to WCDMA network for SRVCC
1526728401 L.IRATHO.SRVCC.E2W.ExecAttOut Number of inter-RAT handover executions from E-UTRAN to WCDMA network for SRVCC
1526728402 L.IRATHO.SRVCC.E2W.ExecSuccOut Number of successful inter-RAT handovers from E-UTRAN to WCDMA network for SRVCC
1526728406 L.IRATHO.SRVCC.E2T.PrepAttOut Number of inter-RAT handover attempts from E-UTRAN to TD-SCDMA network for SRVCC
1526728407 L.IRATHO.SRVCC.E2T.ExecAttOut Number of inter-RAT handover executions from E-UTRAN to TD-SCDMA for SRVCC
1526728408 L.IRATHO.SRVCC.E2T.ExecSuccOut Number of successful inter-RAT handovers from E-UTRAN to TD-SCDMA network for SRVCC
1526728894 L.IRATHO.SRVCC.E2W.MMEAbnormR Number of responses for abnormal causes received by the eNodeB from the MME during inter-
sp RAT handover executions from E-UTRAN to WCDMA network for SRVCC
1526728896 L.IRATHO.SRVCC.E2T.MMEAbnormRs Number of responses for abnormal causes received by the eNodeB from the MME during inter-
p RAT handover executions from E-UTRAN to TD-SCDMA network for SRVCC
211 © 2017 Nokia

LCS-Triggered SRVCC
Description:
The counter measures the number of LCS-triggered CS fallback indicators received by the eNodeB in
a cell.
Measurement points of the following items involve different protocol-defined procedures:
• - Number of CSFB executions
• - Number of CSFB procedures triggered
• - Number of CSFB responses
Therefore, the triggering, response, and execution of a CSFB procedure may be counted in different
measurement periods. In a measurement period, the measurement results of the three items may not
match.
The signaling flows involved in the counter(s) comply with sections 8.3.1 and 8.3.4 in 3GPP TS
36.413 V10.4.0
Measurement Points
As shown at point A in Figure 1, the L.CSFB.LCS.PrepAtt counter is incremented by 1 each time the
eNodeB receives an INITIAL CONTEXT SETUP REQUEST message containing the IE "CS Fallback
Indicator" from the MME and the eNodeB determines that the CSFB procedure is for LCS.
As shown at point A in Figure 2, the L.CSFB.LCS.PrepAtt counter is incremented by 1 each time the
eNodeB receives a UE CONTEXT MODIFICATION REQUEST message containing the IE "CS
Fallback Indicator" from the MME and the eNodeB determines that the CSFB procedure is for LCS.
212 © 2017 Nokia

LCS-Triggered SRVCC (Contd.)
Associated Counters

1526728409 L.CSFB.LCS.PrepAtt Number of LCS-triggered CS fallback indicators received by the eNodeB
1526728410 L.CSFB.LCS.PrepSucc Number of responses sent from the eNodeB to MMEs for CSFB triggered by LCS
1526728753 L.IRATHO.SRVCC.LCS.E2W.PrepAttOut Number of CSFB-based handover attempts from E-UTRAN to WCDMA network for SRVCC
1526728754 L.IRATHO.SRVCC.LCS.E2W.ExecAttOut Number of CSFB-based handover executions from E-UTRAN to WCDMA network for SRVCC
1526728755 L.IRATHO.SRVCC.LCS.E2W.ExecSuccOut Number of successful CSFB-based handovers from E-UTRAN to WCDMA network for SRVCC
1526728759 L.IRATHO.SRVCC.LCS.E2T.PrepAttOut Number of CSFB-based handover attempts from E-UTRAN to TD-SCDMA network for SRVCC
1526728760 L.IRATHO.SRVCC.LCS.E2T.ExecAttOut Number of CSFB-based handover executions from E-UTRAN to TD-SCDMA network for
SRVCC
1526728761 L.IRATHO.SRVCC.LCS.E2T.ExecSuccOut Number of successful CSFB-based handovers from E-UTRAN to TD-SCDMA network for
SRVCC
213 © 2017 Nokia

SRVCC Triggered For Emergency Calls
Description:
The counter measures the number of handover attempts from E-UTARN to WCDMA network for SRVCC triggered for emergency calls in a cell.
The signaling flows involved in the counter(s) comply with section 8.4.1 in 3GPP TS 36.413 V10.4.0.
Measurement Points
As shown at point A in Figure 1, the L.EMC.SRVCC.E2W.PrepAttOut counter is incremented by 1 each time the eNodeB decides to perform a handover from
the E-UTRAN to a WCDMA network for SRVCC triggered for an emergency call.
214 © 2017 Nokia

SRVCC Triggered For Emergency Calls
Associated Counters
1526729517 L.EMC.SRVCC.E2W.PrepAttOut Number of handover attempts from E-UTRAN to WCDMA network for SRVCC triggered for
emergency calls
1526729518 L.EMC.SRVCC.E2W.ExecAttOut Number of handover executions from E-UTRAN to WCDMA network for SRVCC triggered for
emergency calls
1526729519 L.EMC.SRVCC.E2W.ExecSuccOu Number of successful handovers from E-UTRAN to WCDMA network for SRVCC triggered for
t emergency calls
1526729523 L.EMC.SRVCC.E2T.PrepAttOut Number of handover attempts from E-UTRAN to TD-SCDMA network for SRVCC triggered for
emergency calls
1526729524 L.EMC.SRVCC.E2T.ExecAttOut Number of handover executions from E-UTRAN to TD-SCDMA network for SRVCC triggered for
emergency calls
1526729525 L.EMC.SRVCC.E2T.ExecSuccOut Number of successful handovers from E-UTRAN to TD-SCDMA network for SRVCC triggered for
emergency calls
Calculate SRVCC preparation and execution success rates. If the results do not meet the SRVCC performance requirements of an operator, fault isolation
and diagnosis are required. Take monitoring the performance of SRVCC to UTRAN as an example.
The formulas for calculating other success rates are similar to the following:
(L.IRATHO.SRVCC.E2W.ExecSuccOut- L.IRATHO.SRVCC.E2W.MMEAbnormRsp)
/L.IRATHO.SRVCC.E2W.ExecAttOut
L.IRATHO.SRVCC.E2W.ExecAttOut/L.IRATHO.SRVCC.E2W.PrepAttOut
215 © 2017 Nokia

Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• SRVCC
• Counter Query
• NPM4GS
216 © 2017 Nokia

Counter Activation
217 © 2017 Nokia

Counter Activation in Huawei iManager U2000
• Huawei iManager U2000 is well known operation and monitoring tools which can carry out network operation/execution and provide performance data
query function.
• Before a performance data / counter can be queried, it must be activated first in the U2000 in order to generate the values, below shows the step to activate a
counter in U2000.
STEP 1 STEP 2
Click the “Search”

button
218 © 2017 Nokia

Counter Activation in Huawei iManager U2000 (Contd.)
STEP 3 STEP 4
1. Select “All” 1. Select the required period granularity

2. Key in counter name and press “enter” at keyboard 2. If the button is unchecked, it means the counter is inactive, check button of
the counter to activate it accordingly
3. The desired counter will appear and please click on the counter and wait
till the counter is selected automatically at the background 3. After check the button, please “apply” and the counter is activated
219 © 2017 Nokia

How to Export U2000 Performance Measurement Setting
Overview
There are so many NEs on the entire network, how do we collect statistic
on the number of NEs for which the measurement is not set and on the
measurement status of NEs for which the measurement has been set?
The U2000 provides a convenient query method. Even if there are a lot of
NEs for which the measurement has been set and NEs whose
measurement status is abnormal.
Export the Performance Measurement Setting

The following figure showing the performance measurement setting
export procedure.
Notes: If the exported xml is in XML format, you need to use Microsoft
Office Excel to open the file. The files contains the object ID, object
name, function set and subset names and IDs, and periods in which
measurement is set and is not set. in the file, 0,1,2,3, and 4 indicate the
5min,15min,30min,60min and 24hour measurement periods, respectively.
.
220 © 2017 Nokia

How to Export U2000 Performance Measurement Setting (Contd.)
Describes measurement counters, including the following parameters:
• Measperiod: Activated measurement period. It indicates the measurement period for activated counters which will be transferred to U2000 (When turning on
in lower duration period (says 5min), it will load up U2000 capacity)
0 = 5 min
1 = 15 min
2 = 30 min
3 = 60 min
4 = 24 hour
• Unmeasperiod: Inactivated measurement period. It indicates the measurement period for inactivated counters which will not be transferred to U2000
0 = 5 min
1 = 15 min
2 = 30 min
3 = 60 min
4 = 24 hour
• Countertype: describes the type of counters.
0 = KPIs,
1 = Extended Counters,
2 = user-defined counters.
Please refer to the sample excel report (original XML format but open in Excel format)
221 © 2017 Nokia

Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• Counter Query
• NPM4GS
222 © 2017 Nokia

Counter Query
223 © 2017 Nokia

PRS
• Overview
• Engineering Guidelines
• KPI Service
224 © 2017 Nokia

Overview
Definition
Key performance indicators (KPIs) are categorized into system KPIs and customized KPIs. The PRS provides the KPI management function. With this function,
users can browse and filter KPIs, and set the criteria format template. They can also set customized KPIs as required. These KPIs are defined based on extracted
system KPIs and predefined KPIs, and are used to customize report-related configurations.
Benefits
Users can create, modify, and delete customized KPIs, set the criteria format, threshold, and divide-by-zero rule of KPIs, search KPI reference relationships,
import and export KPIs, and set a KPI associated report.
Application Scenario
During routine network monitoring and problem analysis, users can customize KPIs as required to improve operation and maintenance (O&M) efficiency. In
addition, users can customize KPI formulas based on actual services and create KPIs. When performing KPI Analysis or Report Management, users can select a
customized KPI for query and analysis.
Specifications
• Maximum number of nesting layers of KPIs in a KPI formula: 3
• KPI templates can be created in batches, and a maximum of 10 templates can be created for each KPI.
Operation Rights Requirements

Users are authorized to manage KPIs
225 © 2017 Nokia

PRS
• Overview
• KPI Service
226 © 2017 Nokia

Engineering Guidelines
• Counter Query
• Creating a KPI
• Importing or exporting a KPI
• Searching for KPI Reference Relationship
• Advanced
• Activating or Deactivating a KPI
• Configuring an Associated Report
• Querying a Formula
227 © 2017 Nokia

Performance Counter Query using PRS
STEP 1 STEP 2
STEP 3
• Click the drop down and select Object Select the 3G

related type.
• Huawei classifies 4G counters into
4GBTS and Whole Network, therefore,
it is recommended to understand the
counter’s NE type category before
proceed with the data query.
228 © 2017 Nokia

Performance Counter Query using PRS (Contd.)
STEP 4 STEP 5
After selecting the NE type correctly, then select the object type and Search the site/ cell
this selection is depend on the expected result.
229 © 2017 Nokia

STEP 6 STEP 7
230 © 2017 Nokia

STEP 8 STEP 9
231 © 2017 Nokia

Creating a KPI
1. Choose a KPI type, such as All KPI, System KPI,
Portal: Report > KPI Management Custom Normal KPI, Custom Conditional KPI, and
Custom Preaggregated KPI.
2. Click New.
New Formula
232 © 2017 Nokia

Importing a KPI
Set the KPI type to Custom Normal KPI and click Import KPI.
2. Click Import KPI.
1. Set the KPI type to

Custom Normal KPI.
3. Click Browse to select the

KPI file to be imported.
233 © 2017 Nokia

Exporting a KPI: Exporting a KPI by NE Type
Set the KPI type to Custom Normal KPI or Custom Conditional KPI and click Export KPI.
1. Set the KPI type to Custom Normal
KPI or Custom Conditional KPI.
3. Click Export KPI.
2. Select the type of the NE

to be exported.
234 © 2017 Nokia

Exporting a KPI: Exporting a KPI by Object Type
1. Set the KPI type to Custom Normal KPI
or Custom Conditional KPI.
2. Select the type of the

object to be exported.
235 © 2017 Nokia

Exporting a KPI: Exporting a KPI by Function Subset
1. Set the KPI type to Custom Normal
KPI or Custom Conditional KPI.
2. Select a function
subset to be exported.
236 © 2017 Nokia

Exporting a KPI: Exporting a selected KPI
Set the KPI type to Custom Normal KPI or Custom Conditional KPI and click Export KPI. 1. Set the KPI type to Custom
Normal KPI or Custom
Conditional KPI.
2. Select a KPI to be exported.
237 © 2017 Nokia

Searching for KPI Reference Relationship
In the KPI list, select a KPI whose reference relationship needs to be queried and click Search Reference.
2. Click Search Reference.
1. Select a KPI to be queried.
238 © 2017 Nokia

Advanced
Click Advanced and set search criteria , to search KPI list in Combined conditions.
1.Click Advanced.
3.Select a logic and input a keyword.

2. Select a criteria. 4.Click Search
239 © 2017 Nokia

Activating or Deactivating a System KPI- Activating a Specified System KPI
4. Click Activate
KPI.
1. Select Show
inactive KPIs.
2. Select the function 3. Select a system

subset of a KPI to be KPI to be activated.
activated.
4. Select a system KPI to be

activated and click Submit.
240 © 2017 Nokia

Activating or Deactivating a System KPI- Deactivating a Specified
System KPI
2. Click Activate KPI.
1. Select a system KPI

to be deactivated.
3. Deselect a system KPI

to be activated and click
Submit.
241 © 2017 Nokia

Configuring an Associated Report
1. Click the Configure

Associated Report icon.
2. Select a report to be
associated and click OK.
242 © 2017 Nokia

Querying a Formula
1. Select a KPI type, such as Custom
Normal KPI, Custom Conditional KPI,
and Custom Preaggregated KPI.
2. Click the
Query
Formula icon.
243 © 2017 Nokia

Engineering Guidelines
Troubleshooting
Choose Collection > KPI Management in the left pane. On the Collection tab page, set the start time and end time and click Collect to obtain KPI management
logs, as shown in the following figure.
244 © 2017 Nokia

PRS
• Overview
• KPI Service
245 © 2017 Nokia

KPI Service: Centralized Performance Management
Supports multi-RAT and multi-OSS centralized performance management and provides a management capability of up to 4000 equivalent NEs.
246 © 2017 Nokia

KPI Service: Multi-OSS, Multi-RAT, and Multi-Version
The PRS can manage multiple OSS systems at the same time and provides a management capability of up to 400 equivalent NEs.
The PRS supports more than 20 types of NEs on GSM, CDMA, WCDMA, TD-WCDMA, WiMAX, LTE, uBro, and CN networks, and supports the same NE in
multiple versions.
Server Type Management Capability(Equivalent NEs)

RH5885 ≤ 80
HP DL580 ≤ 280
HP DL980 ≤ 800
400
800
ATAE Cluster(PRS RAN 1200
Statistics Performance Visibility) 1600
2000
3200
247 © 2017 Nokia

KPI Service: Centralized Performance Management
Performance Data Aggregation
Time Dimension
 Sum
Monthly  Average .
 Max .
Weekly
 Min .
 Count
Daily …
...
.. .. .. ..
. . . .
Hourly …
Object Dimension
Cell BSC/Cell Group Network
Daily Busy Hour

Hourly Aggregation Data Daily Aggregation Data Weekly Aggregation Data Monthly Aggregation Data
Data
Entire network 31 Days 93 Days 180 Days 106 Weeks 36 months
BSC 31 Days 93 Days 180 Days 106 Weeks 36 months

Cell 31 Days 93 Days 180 Days 106 Weeks 36 months
Solve the conflict between the rapid increase of performance data and the storage time and improve the query efficiency.
248 © 2017 Nokia

KPI Service: E2E Performance Report Customization
Customizing KPI Customizing Generating reports on schedule

Customizing reports
Customizing busy hour rule Excel template Distributing reports automatically
Construct report express: customize KPI and report flexibly, generate and distribute reports automatically.
Bulk copy optimization experience: solidify optimization experience in the customized reports, which are applied in the similar scenarios
249 © 2017 Nokia

KPI Service: E2E Performance Report Customization (Contd.)
KPI Customization
Normal KPI Conditional KPI
For example:
Worst cell ratio = count Cell number in
BSC (if (Traffic Volume on Signaling
Channels (TCH)  0.6Erl and Call Drop
Ratio >3% and congestion rate  5%) /
total Cell number in BSC
Not only the normal KPI but the conditional KPI could be customized as well.
250 © 2017 Nokia

Busy-Hour Rule Customization
PS Throughput
Hot spot
CS Traffic
For example:
PS Throughput:
DOWN_RLC_BLK_TOTAL
CS Traffic:
CELL_KPI_TCH_TRAF_ERL_TRA
F
Suburban
251 © 2017 Nokia

Report Customization
Report style
TOC
TO
OT
CO
CT
TC
Select basic information
252 © 2017 Nokia

Report Customization- Adding a Chart
253 © 2017 Nokia

Report Export Format Customization
• The PRS generates the report file based on the correlated XLS template.
• The report template in XLS format and the scheduled generation and
distribution of reports together provide users with required report results.
Set Template Property
Associate reports with Excel templates to enrich the display function using the
formats, formulas, tables, and macros provided by Excel.
254 © 2017 Nokia

Report Automatic Generation and Distribution
Generate reports on schedule
255 © 2017 Nokia

KPI Service: Efficient Performance Monitoring and Analysis
Powerful Display Function
Table Drill
Chart Filter
256 © 2017 Nokia

KPI Service: Efficient Performance Monitoring and Analysis
KPI Benchmarking
Fixed benchmark Floating benchmark
• Fixed Benchmark • Floating Benchmark

 External Data  Day Series
 System Data  Week Series
257 © 2017 Nokia

KPI Service: Efficient Performance Monitoring and Analysis (Contd.)
KPI Benchmarking
1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9
　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　
Week 1 Week 2 Week 3 Week 4 Week 5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 3 4
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
258 © 2017 Nokia

Flexible Drilling by Multi-Dimension
Object
Drill Down
Network
Drill Down
rtt
ppoor
Ree
R
Cell Group
Drill Up
BSC II
KPP
K
teerr
unnt
Coou
Cell Drill Up
Time
Hour Day Week Month
Drilling up and down by multi-dimension to locate the root cause efficiently
259 © 2017 Nokia

KPI Dashboard: Near Real-time Monitoring
Directly monitor the network status through the dashboard, and analyze the network problems through the correlated theme reports.
260 © 2017 Nokia

KPI Service: Scenario-Oriented Performance Optimization
Fans Park Freeway

.. .. .. ..
. . . .
…
Media Center Stadium

Cell Scenario
Object Group Aggregation
PS Throughput
Stadium
Time
Report
Busy Hour
Report Drilling Week

KPI Day
Counter Hour
261 © 2017 Nokia

KPI Service: Scenario-Oriented Performance Optimization (Contd.)
KPI Insight
Customize KPIs Collect KPIs manually Re-analyze abnormal Classify and analyze
using the U2000. and generate a key KPIs based on the data sources.
monitoring report. data sources.
Clear display of
Perform online
network quality Analyze KPIs
associated analysis
through the
on abnormal KPIs.
correctly.
automatically
generated KPI report.
Traditional method 60 minutes
KPI Insight Efficiency is improved

by 12 folds.
Benefits
• Identifies network problems
quickly. 5 minutes
• Improves analysis efficiency of
engineers.
262 © 2017 Nokia

Contents
• Accessibility
• Retainability
• Mobility
• Utilization
• Availability
• Traffic
• VoLTE
• Counter Query
• NPM4GS
NPM4GS
Overview of NPM4GS
Upcoming slides describe eRAN Performance KPI that are included in NPM4GS documentation.
It is categorized into 10 performance groups namely:
• RRC Performance
• Availability
• PS Performance
• Voice
• HO Performance
• Traffic Performance
• VoLTE Accessibility
• VoLTE Retainability
• VoLTE Usage
• VoLTE Latency
eRAN12.1 Huawei NPM4GS KPI Analysis Template_System Program can be found as per following Ms Excel: eRAN Huawei
NPM4GS System Program Templat
eRAN12.1 Huawei NPM4GS KPI Analysis Template_Accessibility can be found as per following Ms Excel:
eRAN Huawei
NPM4GS Template_Accessibility
RRC Performance
RRC Setup Success:
h4g_1b
h4g_1b (RRC
(RRC setup
setup SR
SR for
for signalling)
signalling)
h4g_2a (RRC setup SR for service)
RRC Setup
Success
RRC Performance
RRC Failures:
RRC
RRC Failures
Failures
h4g_16a
h4g_16a (Res
(Res Alloc)
Alloc)
h4g_17a (No Ue resp)
h4g_18a
h4g_18a (Conn
(Conn Rej)
Rej)
h4g_639a
h4g_639a (SRS
(SRS Res
Res Alloc)
Alloc)
h4g_641a (PUCCH Res Alloc)
h4g_643a
h4g_643a (Flow
(Flow Ctrl
Ctrl msgs)
msgs)
RRC Performance (Contd.)
Report Name RRC Setup success rate for signalling
Huawei KPI ID h4g_1b RRC
100.0 60,000,000
Report Accessibility
90.0
Scope RRC Performance analysis show that RRC Setup Success .
50,000,000
To Get the success, we need to make sure the issues are met timely 80.0
Observation Performing scope identification, KPI trend analysis, and cause resolution-
70.0
1. Determine whether the problem is a top cell problem or network-wide 40,000,000
problem. 60.0
#
2. Analyse the major causes of access failure and come up with priority
options. 50.0 30,000,000
3. Submit a sleeping cell Problem to R&D for analysis.
4. Analyse weather the core access parameters are proper of consistent 40.0
between the eNodeB and MME. 20,000,000
5. Check whether there are device faults that result in access problems or 30.0
any access related alarms are reported.
20.0
6. Check Operation logs are check for any external events. 10,000,000
7. Check version differences and known issues. 10.0
8. Check network planning parameters like TAC, TAL, Subframe
configuration. 0.0 0
9. Check RF Channel for Interference.
8/9/2016
8/6/2016
8/7/2016
8/8/2016
8/10/2016
8/11/2016
8/12/2016
8/13/2016
8/14/2016
10. Check Coverage issues if available around.
11. Check Transmission Issues.
12. Check Capacity or Congestion Issues in the network. RRC setup attempts
Call Setup Success Ratio
Recommendation Use the respective U2000, LMT, NASTAR, PRS and drive test tools to Call Setup Success Ratio including signaling
analyse the issue in the network.
267 © 2017 Nokia

RRC Performance (Contd.)
Report Name RRC Failure details
Huawei KPI ID h4g_16a (Res Alloc)

h4g_17a (No UE resp)
h4g_18a (Conn Rej)
h4g_639a (SRS Res Alloc)
h4g_641a (PUCCH Res Alloc)
h4g_643a (Flow Ctrl msgs)
Report Accessibility
Scope RRC Performance analysis show that RRC Setup & Access performance is below threshold. Detail RRC access failure analysis need to be
done on Rejected RRC connection setup requests. The RNC sends an RRC CONNECTION REJ message after receiving an RRC
CONNECTION SETUP REQUEST message.
Observation
Res Alloc-Check if admission parameters is correct. Consider to enable load balance algorithm. Consider capacity extension
No Ue resp- Check if Ue supports the band.
Conn Rej- Check if admission parameters is correct, Consider to enable load balance algorithm and Consider capacity extension
SRS Res Alloc- No radio resource due to no enough resource for SRS. Check the cell load statue, if its high consider capacity expansion
PUCCH Res Alloc- No radio resource due to no enough resource for SRS. Check the cell load statue, if its high consider capacity
expansion.
Flow ctrl msgs- Poor DL Coverage. Check RSCP and RSRP and perform RF Tuning
Analyze the value of the counters one week before and one week after the congestion. Check whether the resource congestion is caused by
traffic bursts. If the resources are insufficient, expand the network capacity.
Availability
Cell
h4g_180b
h4g_180b (Cell
(Cell Availability)
Availability)
Availability
Availability
Availability (Contd.)
Report Name Cell Availability Cell Availability
Huawei KPI ID h4g_180b 100.0
Report System Program 90.0
Scope
80.0
Even though it is as such not part of the performance assessment, it 70.0

should be verified that the cell availability is within usual range before
finalizing the report as poor operational performance will negatively 60.0
impact the result without reflecting Radio Planning or Radio
%
Optimization quality. 50.0
h4g_180b can be used to monitor cell availability defined as percentage
of time the cells (sec) is in working state. KPI shows specifically the 40.0
availability on times when the cell has not been BLU.
30.0
Observation Provide the Cell Availability Percentage and describe on the
20.0
performance
10.0
Recommendation
Check eNodeB configuration by checking commissioning, cabling and 0.0
correct installation of the units/modules at the eNodeB.
Make sure that environment does not cause the faults.
eNodeB Alarms must be continually monitored and need to be resolved
in order to improve cell availability
. Cell Availability Ratio System Cell Availability Ratio
PS Performance
PS Drop Rate:
Retainability h4g_26a
h4g_26a (E-RAB
(E-RAB Drop
Drop Ratio
Ratio for
for Service)
Service)
PS
PS Failures:
Failures:
h4g_52a (Radio Network Layer Failures)
PS Performance h4g_53a
h4g_53a (Transport
(Transport Network
Network Layer
Layer Failures)
Failures)
h4g_54a
h4g_54a (Network
(Network Congestion)
Congestion)
h4g_55a (Handover Failures)
Accessibility
Accessibility h4g_56a
h4g_56a (EPC
(EPC Failures)
Failures)
PS Setup SR:
h4g_1b
h4g_1b (RRC
(RRC SSR
SSR for
for service)
service)
h4g_2a
h4g_2a (RRC SSR for signalling)
(RRC SSR for signalling)
Setup
Setup Failures:
Failures:
h4g_287a
h4g_287a (reconfiguration)
(reconfiguration)
h4g_288a
h4g_288a (handover)
(handover)
h4g_289a
h4g_289a (resource
(resource allocation)
allocation)
h4g_290a (no reply)
h4g_291a
h4g_291a (rejections)
(rejections)
h4g_292a (unavailability of Ue)
PS Performance (Contd.)
Report Name Packet Call Accessibility and Retainability
Huawei KPI ID h4g_2a (RRC SSR for signalling) 6.00 E-RAB Drop ratio 12,000
h4g_1b (RRC SSR for Service)
h4g_26a (E-RAB Drop Ratio for Service)
5.00 10,000
Report System Program
Scope h4g_2a and h4g_1b Call Setup success ratio. Packet call performance includes 4.00 8,000
all PS calls.
Packet call SSR, including Packet call ends with dedicated resource release.
%
h4g_26a PS Service drop ratio, covers eRAB Active Phase of a call. Packet 3.00 6,000
Session success ratio can be calculated with 100% - PS Service drop ratio
(h4g_26a)
2.00 4,000
Observation < Write here comments – e. g. Is there performance issue with Packet Session
Setup/success > 1.00 2,000
<Packet Session setup ratio is in good level and stable. There is no
performance issues>
<Packet Session success ratio shows average 98,74 which is below 0.00 0
thresholds>
8/7/2016
8/6/2016
8/8/2016
8/9/2016
8/10/2016
8/12/2016
8/14/2016
8/11/2016
8/13/2016
< two week performance stable>
(detail analysis done only in case poor performance)
Recommendation Check neighbour definitions and RF optimisation for main offenders. E-RAB setup attempts
E-RAB Drop Ratio for Service
E-RAB Drop Ratio for Service, always online
PS Performance (Contd.)
Report Name Packet Session Setup Failures (Re-establishment failure)
Huawei KPI ID
h4g_287a (reconfiguration) (A)
h4g_288a (handover) (A)
h4g_289a (resource allocation) (A)
h4g_290a (no reply) (A)
h4g_291a (rejections) (A)
h4g_292a (unavailability of Ue) (A)
h4g_52a (Radio Network Layer Failures) (R)
h4g_53a (Transport Network Layer Failures) (R)
h4g_54a (Network Congestion) (R)
h4g_55a (Handover Failures) (R)
h4g_56a (EPC Failures) (R)
Report Accessibility & Retainability
Scope Packet Session Performance analysis show that PS Session Setup performance is below threshold. Detail Failure analysis is done to
find main source for the problem.
Observation TNL Failures are mostly due to Transmission issues.
Radio link failure due to poor coverage or quality
Network congestion is due to increase in no. of unexpected users out of capacity.
Handover failures are due to frequency clashes (PCI Collision), not good coverage, improper HO attempt due to poor quality,
congestion in the neighbor cell etc.
EPC failures are due to MME overload.
Voice
Retainability:
Retainability:
E-RAB
h4g_708a (E-RAB drop rate)
Retainability Failures:
h4g_1970a
h4g_1970a (Other
(Other reasons)
reasons)
Voice h4g_1972a
h4g_1972a (Other
(Other reasons
reasons due
due to
to RN
RN Layer)
Layer)
h4g_1974a (Other reasons due to TN Layer)
h4g_1976a
h4g_1976a (Insufficient
(Insufficient other
other radio
radio resources)
resources)
Voice (Contd.)
Report Name Voice Retainability
Huawei KPI ID h4g_708a (E-RAB drop rate)

Scope Voice E-RAB drop rate
Observation Check radio parameters, operation logs, device faults, alarms, Interference, Poor Coverage, Handover, Load Capacity, and
Transmission
Recommendation Monitor Poor Coverage and Interfered area
Voice (Contd.)
Report Name ERAB Voice drop reasons
Huawei KPI ID
h4g_1970a (Other reasons)
h4g_1972a (Other reasons due to RN Layer)
h4g_1974a (Other reasons due to TN Layer)
h4g_1976a (Insufficient other radio resources)
Report Retainability
Scope
Retainability analysis show that performance is below threshold. Detail Failure analysis is done to find main source for the problem.
Observation
RN Layer is due to radio network failure like equipment issue, hard reset etc.
TN Layer is due to transmission issue.
Insufficient radio resources like license for less users, Boards not upgraded or wrongly upgraded.
Recommendation
Solve Radio equipment and transmission issues and increase the capacity of the license.
HO Performance
h4g_67b
h4g_67b (Intra
(Intra eNodeB
eNodeB Intra-Frequency
Intra-Frequency OG
OG Handover
Handover Success
Success Ratio)
Ratio)
h4g_68b (Intra eNodeB Inter-Frequency OG Handover Success Ratio)
h4g_853a
h4g_853a (Intra
(Intra eNodeB
eNodeB OG
OG FDD-TDD
FDD-TDD Handover
Handover Success
Success Ratio)
Ratio)
HO
CSFB
CSFB (ALL):
(ALL):
HO Performance h4g_627a
h4g_627a (CS
(CS Fall
Fall back
back Inter-RAT
Inter-RAT Outgoing
Outgoing Handover
Handover Success
Success ratio)
ratio)
CSFB (GSM):
h4g_666a
h4g_666a (E-UTRAN
(E-UTRAN toto GERAN
GERAN CSFB
CSFB Handover
Handover Success
Success Ratio)
Ratio)
CSFB (UMTS):
Others
Others h4g_665a
h4g_665a (E-UTRAN
(E-UTRAN toto WCDMA
WCDMA CSFBCSFB Handover
Handover Success
Success Ratio)
Ratio)
SRVCC (GSM):
h4g_876a (E-UTRAN to GERAN success ratio of inter-RAT SRVCC Outgoing
Handovers
Handovers for
for Emergency
Emergency Calls)
Calls)
SRVCC (UMTS):
h4g_874a (E-UTRAN to WCDMA success ratio of inter-RAT SRVCC Outgoing
Handovers
Handovers for
for Emergency
Emergency Calls)
Calls)
HO Performance (Contd.)
102.0 Intra Frequency Handover 4 000.000
100.0 3 500.000
Report
HO 98.0 3 000.000
Name
Huawei 96.0 2 500.000
h4g_67b (Intra eNodeB Intra-Frequency OG Handover Success Ratio)
KPI ID
Report Mobility 94.0 2 000.000
Scope Intra eNodeB Intra-Frequency OG Handover Success Ratio( >99%)
%
92.0 1 500.000
Observatio Low HO success rate can be due the incomplete neighbor planning
n and non-optimal HO parameters. Decreased HO success rate does not 90.0 1 000.000
directly mean that the call would be dropped, but active set update
requests are not answered. 88.0 500.000
Enable ANR Algorithm to detect new neighbours around
86.0 0.000
Recommen If Poor performance, Check neighbor plan and verify HO parameters
8/9/2016
8/6/2016
8/7/2016
8/8/2016
8/10/2016
8/11/2016
8/12/2016
8/13/2016
8/14/2016
dation (add/drop)
Intra-frequency handover attempts Incoming Handover attempts

Outgoing IntraFHO Succ Ratio Incoming Handover Succ Ratio
Report Inter Frequency Handover

HO
Name
Huawei KPI h4g_68b (Intra eNodeB Inter-Frequency OG Handover Success 100.0 180.000
ID Ratio)
99.0 160.000
Report Mobility 98.0 140.000
Scope Intra eNodeB Inter-Frequency OG Handover Success Ratio>99% 97.0 120.000
%
96.0 100.000
Observation < write here observations – e.g. Number of HO attempts is too low
to be analyzed. > 95.0 80.000
< HO success rate KPI shows average 99% and it is in good level> 94.0 60.000
Low HO success rate can be due the non optimal neighbor
93.0 40.000
planning. Failed HO does not necessary drop, it can simply stay in
the same cell. 92.0 20.000
91.0 0.000
Recommend Check Neighbor plan and consider change layering strategy.
8/6/2016
8/7/2016
8/8/2016
8/9/2016
8/10/2016
8/11/2016
8/12/2016
8/13/2016
8/14/2016
ation
Inter-frequency handover attempts Outgoing InterFHO Succ Ratio
Report Name GSM ISHO
Huawei KPI ID h4g_853a (Intra eNodeB OG FDD-TDD Handover Success Ratio)
Report Mobility
Scope Intra eNodeB OG FDD-TDD Handover Success Ratio should be planned accordingly. Normally the neighbor plan is same for both
the technologies along with parameters. We should make sure the required parameters are properly enabled.
Observation < write here observations – e.g. Number of HO attempts is too low to be analyzed. >
< FDD-TTD HO success rate KPI shows average 98% and it is in good level>
Recommendation Check Neighbor plan and consider change layering strategy. Also Make sure ANR is enabled and respective neighbor
parameters are properly defined.
Report Name CSFB
Huawei KPI ID
h4g_627a (CS Fall back Inter-RAT Outgoing Handover Success ratio)

h4g_666a (E-UTRAN to GERAN CSFB Handover Success Ratio)
h4g_665a (E-UTRAN to WCDMA CSFB Handover Success Ratio)
Report Mobility
Scope
h4g_627a (CS Fall back Inter-RAT Outgoing Handover Success ratio)

h4g_666a (E-UTRAN to GERAN CSFB Handover Success Ratio)
h4g_665a (E-UTRAN to WCDMA CSFB Handover Success Ratio)
over the reporting period in the source cell.
Observation
failures can be due the Target cells capacity issues, for example The parameters should be well defined and make sure there
should be cells with enough capacity.
Layer strategy should be maintained and priority definition should be followed.
Recommendation
Verify BTS configuration and capacity. Add capacity to the fallback cells if needed
281 © 2017 Nokia

Report Name SRVCC on VoLTE
Huawei KPI ID h4g_876a (E-UTRAN to GERAN success ratio of inter-RAT SRVCC Outgoing Handovers for 600
Emergency Calls) Inter RAT Handover
100.0
h4g_874a (E-UTRAN to WCDMA success ratio of inter-RAT SRVCC Outgoing Handovers for
500
Emergency Calls)
Report 98.0
Mobility
400
Scope
h4g_876a (E-UTRAN to GERAN success ratio of inter-RAT SRVCC Outgoing Handovers for 96.0
Emergency Calls) 300
h4g_874a (E-UTRAN to WCDMA success ratio of inter-RAT SRVCC Outgoing Handovers for
#
Emergency Calls)
Should be defined with all reporting methods and parameters enabled. 94.0
200
SRVCC is a solution to provide continuous voice services on LTE networks.
Observation SRVCC is a means of inter-RAT handover (RAT stands for radio access technology). It 92.0 100
enables a smooth session transfer from VoIP over IMS on the LTE network to CS services in
the UTRAN or GERAN. Supports incoming CS handovers for CS only SRVCC on GERAN and
UTRAN inter system. This procedure goes through 4 phases, triggering. Measurement, 90.0 0
decision and execution phase.
8/6/2016
8/8/2016
8/9/2016
8/7/2016
8/12/2016
8/10/2016
8/11/2016
8/13/2016
8/14/2016
Recommendation
Thresholds for Triggering Event B1. In a coverage, service, or load based handover for
SRVCC, the measurement configuration contains HO parameters related to event B1: E-UTRAN to WCDMA attempts of inter-RAT Outgoing handover
B1: Inter RAT neighbor becomes better than threshold
E-UTRAN to GERAN attempts of inter-RAT Outgoing handover
B2: PCell becomes worse than threshold1 and inter RAT neighbor becomes better than
threshold2
282 © 2017 Nokia

Traffic Performance
h4g_101b
h4g_101b (Total
(Total DL
DL Traffic
Traffic Volume)
Volume)
h4g_102a
h4g_102a (DL Traffic Volume
(DL Traffic Volume QCI1)
QCI1)
DL Traffic
Volume
Traffic Performance
UL
UL Traffic
Traffic
Volume
h4g_111b (Total UL Traffic Volume)
h4g_112a (UL Traffic Volume QCI1)
Traffic Performance (Contd.)
Report Name
350.0 eNodeB Traffic 1,200,000.00
Traffic Volume
Huawei KPI h4g_101b (Total DL Traffic Volume) 300.0
h4g_102a (DL Traffic Volume QCI1) 1,000,000.00
ID
h4g_111b (Total UL Traffic Volume)
h4g_112a (UL Traffic Volume QCI1) 250.0
800,000.00
Report Traffic
kbps
200.0
Scope Traffic Volume to calculate on DL and UL
600,000.00
Observation Based on the traffic volume in a enodeB, Capacity 150.0
expansion can be done to achieve the KPI threshold.
Need to make sure all the cells are carrying traffic and 400,000.00
they should be under the congestion threshold. 100.0
Recommendat If Poor performance, Check neighbor plan and make 200,000.00

50.0
ion necessary traffic shift to neighbor cell.
Add Site if the congestion is beyond threshold in the busy
hour. 0.0 0.00
Perform CA and software and hardware addition to the
8/6/2016
8/7/2016
8/8/2016
8/9/2016
8/10/2016
8/12/2016
8/13/2016
8/14/2016
8/11/2016
cell.
eNodeB Transmitted bytes eNodeB Received bytes

Average eNodeB transmit rate Average eNodeB received rate
h4g_97b
h4g_97b (DL
(DL Average
Average Cell
Cell Throughput)
Throughput)
h4g_99a
h4g_99a (DL Peak Cell Throughput)
(DL Peak Cell Throughput)
DL Cell
Throughput
Traffic Performance
UL
UL Cell
Cell
Throughput h4g_98c
h4g_98c (UL
(UL Average
Average Cell
Cell Throughput)
Throughput)
h4g_100a
h4g_100a (UL
(UL Peak
Peak Cell
Cell Throughput)
Throughput)
Average PDCP throughput
Report Name 100,000
Cell Throughput
90,000
Huawei KPI ID
80,000
h4g_97b (DL Average Cell Throughput)
h4g_99a (DL Peak Cell Throughput) 70,000
h4g_98c (UL Average Cell Throughput)
kbit/s
h4g_100a (UL Peak Cell Throughput) 60,000
Report 50,000
System Program
40,000
Scope
DL and UL Average and peak throughput should be mapped 30,000
and constantly watched on enodeB and Cell Level.
20,000
Observation
10,000
Throughput can be low due many reason - poor RF, UE
type& category, Capacity and activated features. 0
Recommendation
Max throughput can be used to evaluate if air interface is

capable providing high throughput
If average throughput saturates it is an indication of a
capacity bottleneck. If max throughput is not achieved a
DL Average Cell Throughput UL Average Cell Throughput
network wide parameter revision is needed
286 © 2017 Nokia

h4g_1999a
h4g_1999a (Average
(Average PRB
PRB usage
usage in
in DL)
DL)
h4g_2000a
h4g_2000a (Average PRB usage in
(Average PRB usage in UL)
UL)
PRB Usage
Traffic Performance
Active
Active Ue
Ue in
in aa
cell h4g_694a
h4g_694a (Average
(Average number
number of
of active
active users
users in
in aa cell)
cell)
h4g_695a
h4g_695a (Average
(Average number
number of
of active
active users
users in
in aa cell)
cell)
PRB usage
PRB Utilization 120.0 80.000
Report Name
70.000
h4g_1999a (Average PRB usage in DL) 100.0
Huawei KPI ID h4g_2000a (Average PRB usage in UL)
60.000
Report Physical Resource Block Utilization 80.0

50.000
%
These KPIs show the average value of the physical 60.0 40.000
Resource Block utilization on DL and UL.
Scope This can be used to find network capacity issues and
possible expansion required 30.000
40.0
20.000
20.0
Network is in good shape in terms of PRB usage. But 10.000
upgrades may be required based on traffic growth
Observation Capacity increase actions taken according to the
0.0 0.000
predefined triggers
Operator defined utilization level not reached/reached

Recommendation Site/cell level monitoring required in high traffic areas DL Used Physical Res Blks UL Used Physical Res Blks
DL Resource Blks Utilization Ratio UL Resource Blks Utilization Ratio
288 © 2017 Nokia

12 average number of active Ues 30.0
Report Name Active Ue in a Cell
Huawei KPI ID h4g_694a (Average number of active users in a cell) 10 25.0

8 20.0
Monitoring Average number of active users, help to estimate
#
Scope - Average user throughput
- HW limits (eNB and also MME level) 6 15.0
Observation 4 10.0
2 5.0
High average number of active UEs should be more closely
monitored because more users may cause performance
degradation
0 0.0
Capacity upgrade required if pre defined average/max
Recommendation number of UE level is reached or the max value saturates
Max number of active users is defined by parameters
(especially by ”MaxUserNumPerCell” the parameter value
should be checked prior to capacity upgrade) Average number of active users in a cell
Average number of active users with data in the Uplink Buffer
Average number of active users with data in the Downlink Buffer
VoLTE Performance
Below are the VoLTE related KPI classes considered:
Accessibility
Retainability
System Program
Usage
Latency
VoLTE Accessibility
h4g_306a
h4g_306a (E-RAB
(E-RAB attempts
attempts for
for QCI1)
QCI1)
E-RAB Setup
VoLTE Accessibility
E-RAB
E-RAB Success
Success
h4g_293a
h4g_293a (E-RAB
(E-RAB Setup
Setup Success
Success Ratio
Ratio for
for QCI1)
QCI1)
VoLTE Accessibility (Contd.)
E_RAB Retainibility per QCI 1 to 4
Report Name Accessibility 9.0
8.0
Huawei KPI ID h4g_293a (E-RAB Setup Success Ratio for QCI1)
7.0
6.0
The KPI measures the VoLTE setup success of the E-RAB between
Scope MME and UE for QCI1 DRBs. 5.0
%
4.0
QCI 1 success ratio is in good level and stable. There is no
performance issues
3.0
Observation QCI 1 success ratio shows average 99.9 which is above thresholds
< two week performance stable> 2.0
1.0
If the value is low there are clear problems with VoLTE Accessibility. 0.0
EPS Bearer connection establishments problems (if RRC SR is good)
Recommendation might indicate Admission control, transport or EPC/IMS network
issues.
Check the dedicated bearer license in MME/SP-GW.
E_RAB retainability ratio for QCI1
VoLTE Retainability
h4g_306a (E-RAB attempts for QCI1)
E-RAB
Attempt
VoLTE Retainability
E-RAB
E-RAB Drop
Drop
Rate
h4g_25a
h4g_25a (E-RAB
(E-RAB Drop
Drop Ratio
Ratio for
for QCI1)
QCI1)
VoLTE Retainability (Contd.)
Report Name Retainability
h4g_306a (E-RAB attempts for QCI1)
Huawei KPI ID h4g_25a (E-RAB Drop Ratio for QCI1)
Scope Top offenders based on ERAB retainability QCI 1, RAN View, RNL failure
QCI 1 ERAB Setup Failure Ratio is in good level and stable. There is no performance issues
QCI 1 ERAB Setup Failure Ratio reasons shows average xx.xx which is below thresholds
Observation < two week performance stable>
Recommendation Analyze the problematic eNBs in detail to find out the reason.
VoLTE Usage
h4g_102a
h4g_102a (DL
(DL Traffic
Traffic Volume
Volume QCI1)
QCI1)
DL Traffic
Volume
VoLTE Usage
UL
UL Traffic
Traffic
Volume
h4g_112a
h4g_112a (UL
(UL Traffic
Traffic Volume
Volume QCI1)
QCI1)
VoLTE Usage (Contd.)
Report Name Usage in a Cell
PDCP volume
250,000
h4g_102a (DL Traffic Volume QCI1)
Huawei KPI ID h4g_112a (UL Traffic Volume QCI1)
System Program 200,000
Report
Monitoring DL and UL traffic, help to estimate
Mbyte
- Average user throughput 150,000
Scope - Capacity used
100,000
If VoLTE users are in good level and stable. There is no performance
or traffic issues.
Observation 50,000
If there is too much VoLTE users there may be some capacity bottle
neck.
0
8/6/2016
8/7/2016
8/8/2016
8/9/2016
8/10/2016
8/11/2016
8/12/2016
8/13/2016
8/14/2016
High number of active VoLTE can cause low user satisfaction in
terms of delay and accessibility (AC issue). High average number
of active Ues for QCI 1 (UL /DL) should be closely monitored.
Recommendation
Capacity upgrade required if traffic load is heavy, BGR traffic need
to be monitored closely
Total DL Traffic Volume Total UL Traffic Volume
VoLTE Latency
h4g_1888a
h4g_1888a (Average
(Average PDCP
PDCP SDU
SDU delay
delay in
in DL
DL
for DRBs with QCI1)
DL Latency
VoLTE Usage
VoLTE Latency (Contd.)
Report Name Average Latency in a Cell
Huawei KPI ID h4g_1888a (Average PDCP SDU delay in DL for DRBs with QCI1)
Scope Monitoring Average Latency of active users in VoLTE
If VoLTE latency is acceptable level and stable. There is no performance issues
If there VoLTE latency is high there may be some congestion issues.
Observation
<two week performance stable to observe latency under 50ms >
High latency will show an issue with end user satisfaction as Voice is more delay sensitive that data traffic.
Check the number of active QCI 1 (or QCI 1-9) UEs and total Active UEs in a cell if high latency is experienced on a cell. Also
Recommendation TTI bundling usage needs to be monitored.
Copyright and confidentiality
The contents of this document are proprietary and Nokia operates a policy of ongoing development. Nokia This document and the product(s) it describes
confidential property of Nokia. This document is reserves the right to make changes and improvements to are protected by copyright according to the
provided subject to confidentiality obligations of the any of the products and/or services described in this applicable laws.
applicable agreement(s). document or withdraw this document at any time
without prior notice. Nokia is a registered trademark of Nokia Corporation.
This document is intended for use of Nokia’s customers Other product and company names mentioned herein
and collaborators only for the purpose for which this The contents of this document are provided "as is". may be trademarks or trade names of their respective
document is submitted by Nokia. No part of this Except as required by applicable law, no warranties of owners.
document may be reproduced or made available to the any kind, either express or implied, including, but not
public or to any third party in any form or means limited to, the implied warranties of merchantability
without the prior written permission of Nokia. This and fitness for a particular purpose, are made in relation
document is to be used by properly trained professional to the accuracy, reliability or contents of this document.
personnel. Any use of the contents in this document is NOKIA SHALL NOT BE RESPONSIBLE IN ANY
limited strictly to the use(s) specifically created in the EVENT FOR ERRORS IN THIS DOCUMENT or for
applicable agreement(s) under which the document is any loss of data or income or any special, incidental,
submitted. The user of this document may voluntarily consequential, indirect or direct damages howsoever
provide suggestions, comments or other feedback to caused, that might arise from the use of this document
Nokia in respect of the contents of this document or any contents of this document.
("Feedback").
Such Feedback may be used in Nokia products and
related specifications or other documentation.
Accordingly, if the user of this document gives Nokia
Feedback on the contents of this document, Nokia may
freely use, disclose, reproduce, license, distribute and
otherwise commercialize the feedback in any Nokia
product, technology, service, specification or other
documentation.
Revision history and metadata
Document ID: Huawei eRAN Performance Analysis Guideline, with Nokia NPM
Document Location:
Organization:
Reviewed Approval
Version Description of charges Date Author Owner Status Reviewed by date Approver date
V1.1 Draft 29-05-2017 Hexamatics Nokia -
V1.2 Draft 20-06-2017 Hexamatics Nokia -
V1.3 Draft 28-6-2017 Hexamatics Nokia
V1.4 Final 3-7-2017 Hexamatics Nokia

Nokia Multivendor Optimization Development Project

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nokia Multivendor Optimization Development Project

Uploaded by

Copyright:

Available Formats

Nokia Multivendor Optimization

Huawei eRAN Performance Analysis Guideline, with Nokia NPM

In this module, we will be discussing on OSS & Performance Measurement KPI’s.

RRC Setup Success Rate (Service/Signaling)

Call Drop Rate (VoIP)

Major Performance KPI

Resource Block Utilizing Rate

Note: Pls. refer to excel HL6 KPI Reference Summary.

User Downlink/Uplink Average Throughput

Major Performance KPI 6) Availability Radio Network Unavailable Rate

Accessibility KPIs includes:

• RRC Setup Success Rate (Service)

RRC Setup Success Rate (Service)

Name RRC Setup Success Rate (Service)

Object Cell or radio network

Formula RRCS_SRservice = (RRCConnectionSuccessservice/RRCConnectionAttemptservice) x 100%

Associated RRC Setup Success Rate (Service)

Unit/Range Percentage (%)

Name RRC Setup Success Rate (Signaling)

Table 1: RRC Setup Success Rate (Signaling)

S1SIG Connection Setup Success Rate:

Name S1SIG Connection Setup Success Rate

RRC Connection Request Counters

RRC Connection Setup Counter

L.RRC.ConnSetup Number of RRC Connection Setup messages responses to UE in a cell

RRC Connection Setup Counters

RRC Setup Failure Counters

RRC Connection Reestablishment Attempt Counters

L.RRC.ReEst.HoFail.Att(times) Number of RRC connection reestablishment requests due to failed handovers

RRC Connection Reestablishment Success Counters

L.RRC.ReEst.Succ Number of successful RRC connection reestablishments

L.RRC.ReEst.HoFail.Rej Number of RRC connection reestablishment failures due to a failed handover

L.RRC.ReEstFail.NoCntx Number of RRC connection reestablishment failures due to unavailability of UE contexts

L.RRC.ReEstFail.Rej Total number of RRC connection reestablishment rejections

E-RAB is divided into two parts:

E-RAB Setup Success Rate (All)

Name E-RAB Setup Success Rate (All)

E-RAB Setup Success Rate (VoIP)

Name E-RAB Setup Success Rate (VoIP)

Initial E-RAB Attempts Counter

Counter Name Description

Initial E-RAB success Counter

Counter Name Description

Dedicated E-RAB Attempts Counter

Counter Name Description

L.E-RAB.SuccEst Total number of successful E-RAB setup procedures initiated by UEs

Dedicated E-RAB success Counter

Counter Name Description

L.E-RAB.SuccEst Total number of successful E-RAB setup procedures initiated by UEs

Call Setup Success Rate:

Name Call Setup Success Rate

There are two types of E-RAB releases in a cell:

• E-RAB Normal Release for service Counter

Counter Name Description

• E-RAB Normal release for eNodeB Counter

Counter Name Description

L.E-RAB.NormRel Total number of normal E-RAB releases by the eNodeB

Figure above shows the Abnormal release call flow.

Different Causes Abnormal Release Counters

Counter Name Description

L.E-RAB.AbnormRel.Cong Number of abnormal E-RAB releases due to network congestion

L.E-RAB.AbnormRel.HOFailure Number of abnormal E-RAB releases due to handover failures

L.E-RAB.AbnormRel.MME Number of abnormal E-RAB releases due to faults in the EPC