Ts 128554v160700p

ETSI TS 128 554 V16.7.
0 (2021-01)
TECHNICAL SPECIFICATION
5G;
Management and orchestration;
5G end to end Key Performance Indicators (KPI)
(3GPP TS 28.554 version 16.7.0 Release 16)
3GPP TS 28.554 version 16.7.0 Release 16 1 ETSI TS 128 554 V16.7.0 (2021-01)
Reference
RTS/TSGS-0528554vg70
Keywords
5G
ETSI
650 Route des Lucioles

F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C

Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:

http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2021.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
Intellectual Property Rights

Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology

In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
Contents
Intellectual Property Rights ................................................................................................................................2
Legal Notice .......................................................................................................................................................2
Modal verbs terminology....................................................................................................................................2
Foreword.............................................................................................................................................................6
1 Scope ........................................................................................................................................................7
2 References ................................................................................................................................................7
3 Definitions and abbreviations ...................................................................................................................7
3.1 Definitions .......................................................................................................................................................... 7
3.2 Abbreviations ..................................................................................................................................................... 7
4 End to end KPI concept and overview .....................................................................................................8
5 KPI definitions template...........................................................................................................................8
6 End to end KPI definitions .......................................................................................................................8
6.1 KPI Overview ..................................................................................................................................................... 8
6.2 Accessibility KPI................................................................................................................................................ 9
6.2.1 Mean registered subscribers of network and network slice through AMF ................................................... 9
6.2.2 Registered subscribers of network through UDM ........................................................................................ 9
6.2.3 Registration success rate of one single network slice ................................................................................... 9
6.2.4 DRB Accessibility for UE services ............................................................................................................... 9
6.2.5 PDU session Establishment success rate of one network slice (S-NSSAI)................................................. 10
6.3 Integrity KPI ..................................................................................................................................................... 10
6.3.1 Latency and delay of 5G networks ............................................................................................................. 10
6.3.1.0 Void....................................................................................................................................................... 10
6.3.1.1 Downlink latency in gNB-DU............................................................................................................... 10
6.3.1.2 Integrated downlink delay in RAN ....................................................................................................... 11
6.3.1.2.1 Downlink delay in NG-RAN for a sub-network .............................................................................. 11
6.3.1.2.2 Downlink delay in NG-RAN for a network slice subnet ................................................................. 11
6.3.1.3 Downlink delay in gNB-DU ................................................................................................................. 11
6.3.1.3.1 Downlink delay in gNB-DU for a NRCellDU................................................................................. 11
6.3.1.3.2 Downlink delay in gNB-DU for a sub-network............................................................................... 12
6.3.1.3.3 Downlink delay in gNB-DU for a network slice subnet .................................................................. 12
6.3.1.4 Downlink delay in gNB-CU-UP ........................................................................................................... 13
6.3.1.4.1 Downlink delay in gNB-CU-UP...................................................................................................... 13
6.3.1.4.2 Downlink delay in gNB-CU-UP for a sub-network ........................................................................ 13
6.3.1.4.3 Downlink delay in gNB-CU-UP for a network slice subnet ............................................................ 14
6.3.1.5 Uplink delay in gNB-DU ...................................................................................................................... 14
6.3.1.5.1 Uplink delay in gNB-DU for a NR cell ........................................................................................... 14
6.3.1.5.2 Uplink delay in gNB-DU for a sub-network ................................................................................... 15
6.3.1.5.3 Uplink delay in gNB-DU for a network slice subnet ....................................................................... 15
6.3.1.6 Uplink delay in gNB-CU-UP ................................................................................................................ 16
6.3.1.6.1 Uplink delay in gNB-CU-UP .......................................................................................................... 16
6.3.1.6.2 Uplink delay in gNB-CU-UP for a sub-network ............................................................................. 16
6.3.1.6.3 Uplink delay in gNB-CU-UP for a network slice subnet ................................................................ 17
6.3.1.7 Integrated uplink delay in RAN ............................................................................................................ 17
6.3.1.7.1 Uplink delay in NG-RAN for a sub-network................................................................................... 17
6.3.1.7.2 Uplink delay in NG-RAN for a network slice subnet ...................................................................... 18
6.3.1.8 E2E delay for network slice .................................................................................................................. 18
6.3.1.8.1 Average e2e uplink delay for a network slice.................................................................................. 18
6.3.1.8.2 Average e2e downlink delay for a network slice ............................................................................. 19
6.3.2 Upstream throughput for network and Network Slice Instance .................................................................. 19
6.3.3 Downstream throughput for Single Network Slice Instance ....................................................................... 20
6.3.4 Upstream Throughput at N3 interface ........................................................................................................ 20
6.3.5 Downstream Throughput at N3 interface.................................................................................................... 20
ETSI
6.3.6 RAN UE Throughput .................................................................................................................................. 20

6.3.6.1 Void....................................................................................................................................................... 20
6.3.6.2 RAN UE Throughput definition............................................................................................................ 20
6.3.6.3 DL RAN UE throughput ....................................................................................................................... 21
6.3.6.3.1 DL RAN UE throughput for a NRCellDU ...................................................................................... 21
6.3.6.3.2 DL RAN UE throughput for a sub-network .................................................................................... 21
6.3.6.3.3 DL RAN UE throughput for a network slice subnet........................................................................ 22
6.3.6.4 UL RAN UE throughput ....................................................................................................................... 22
6.3.6.4.1 UL RAN UE throughput for a NRCellDU ...................................................................................... 22
6.3.6.4.2 UL RAN UE throughput for a sub-network .................................................................................... 23
6.3.6.4.3 UL RAN UE throughput for a network slice subnet........................................................................ 23
6.4 Utilization KPI ................................................................................................................................................. 24
6.4.1 Mean number of PDU sessions of network and network Slice Instance ..................................................... 24
6.4.2 Virtualised Resource Utilization of Network Slice Instance ...................................................................... 24
6.4.3 PDU session establishment time of network slice ...................................................................................... 24
6.4.4 Mean number of successful periodic registration updates of Single Network Slice ................................... 25
6.5 Retainability KPI .............................................................................................................................................. 25
6.5.1 QoS flow Retainability ............................................................................................................................... 25
6.5.1.1 Definition .............................................................................................................................................. 25
6.5.1.2 Extended definition ............................................................................................................................... 26
6.5.2 DRB Retainability ...................................................................................................................................... 26
6.5.2.1 Definition .............................................................................................................................................. 26
6.5.2.2 Extended definition ............................................................................................................................... 27
6.6 Mobility KPI .................................................................................................................................................... 27
6.6.1 NG-RAN handover success rate ................................................................................................................. 27
6.6.2 Mean Time of Inter-gNB handover Execution of Network Slice ............................................................... 27
6.6.3 Successful rate of mobility registration updates of Single Network Slice .................................................. 27
6.6.4 5GS to EPS handover success rate.............................................................................................................. 27
6.7 Energy Efficiency (EE) KPI ............................................................................................................................. 28
6.7.1 NG-RAN data Energy Efficiency (EE) ....................................................................................................... 28
6.7.1.1 Definition .............................................................................................................................................. 28
Annex A (informative): Use cases for end to end KPIs .......................................................................29

A.1 Use case for end-to-end latency measurements of 5G network-related KPI ..........................................29
A.2 Use case for number of registered subscribers of single network-slice related KPI ..............................29
A.3 Use case for upstream/downstream throughput for one-single-network-slice-related KPI....................29
A.4 Use case for mean PDU sessions number in network slice ....................................................................29
A.5 Use case for virtualised resource utilization of network-slice-related KPI ............................................30
A.6 Use case for 5GS registration success rate of one single-network-slice-related KPI .............................30
A.7 Use case for RAN UE throughput-related KPI ......................................................................................30
A.8 Use case for QoS flow retainability-related KPI ....................................................................................30
A.9 Use case for DRB accessibility-related KPI...........................................................................................30
A.10 Use case for mobility KPIs .....................................................................................................................31
A.11 Use case for DRB retainability related KPI ...........................................................................................31
A.12 Use case for PDU session establishment success rate of one network slice (S-NSSAI) related KPI ....31
A.13 Use case for integrated downlink latency in RAN .................................................................................31
A.14 Use case for PDU session Establishment success rate of one single-network-slice instance-related
KPI .........................................................................................................................................................32
A.15 Use case for QoS flow retainability-related KPI ....................................................................................32
A.16 Use case for 5G Energy Efficiency (EE) KPI ........................................................................................32
Annex B (informative): Change history ...............................................................................................34
ETSI
History ..............................................................................................................................................................36
ETSI
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
1 Scope
The present document specifies end-to-end Key Performance Indicators (KPIs) for the 5G network and network slicing.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] Void.
[3] ITU-T Recommendation E.800: "Definitions of terms related to quality of service".
[4] 3GPP TS 24.501: " Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3".
[5] 3GPP TS 38.331: "NR; Radio Resource Control (RRC); Protocol specification".
[6] 3GPP TS 28.552: "Management and orchestration; 5G performance measurements".
[7] 3GPP TS 23.501: " System Architecture for the 5G System; Stage 2".
[8] ETSI ES 203 228 V1.2.1 (2017-04): "Environmental Engineering (EE); Assessment of mobile
network energy efficiency".
[9] 3GPP TS 28.310: "Management and orchestration; Energy efficiency of 5G".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP
TR 21.905 [1].
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
3GPP TR 21.905 [1].
EE Energy Efficiency
kbit kilobit (1000 bits)
RTT Round Trip Time
ETSI
4 End to end KPI concept and overview

The following KPI categories are included in the present document:
- Accessibility (see the definition in [3]).
- Integrity (see the definition in [3]).
- Utilization.
- Retainability (see the definition in [3]).
- Mobility.
- Energy Efficiency.
5 KPI definitions template

a) Name (Mandatory): This field shall contain the name of the KPI.
b) Description (Mandatory): This field shall contain the description of the KPI.
Within this field it should describe if the KPI is focusing on network or user view. This filed should also describe
the logical KPI formula to derive the KPI. For example, a success rate KPI’s logical formula is the number of
successful events divided by all events. This field should also show the KPI unit (e.g., kbit/s, millisecond) and
the KPI type (e.g., mean, ratio).
c) Formula definition (Optional):

This field should contain the KPI formula using the 3GPP defined measurement names.
This field can be used only when the measurement(s) needed for the KPI formula are defined in 3GPP TS for
performance measurements (TS 28.552 [6]). This field shall clarify how the aggregation shall be done, for the
KPI object level(s) defined in d).
d) KPI Object (Mandatory):

This field shall contain the DN of the object instance where the KPI is applicable, including the object where the
measurement is made. The DN identifies one object instance of the following IOC:
- NetworkSliceSubnet
- SubNetwork
- NetworkSlice
- NRCellDU
- NRCellCU
e) Remark (Optional):
This field is for additional information reqquired for the KPI definition,
e.g. the definition of a call in UTRAN.
6 End to end KPI definitions
6.1 KPI Overview

The KPI categories defined in [2] will be reused by the present document.
ETSI
6.2 Accessibility KPI

6.2.1 Mean registered subscribers of network and network slice through
AMF
a) AMFMeanRegNbr.
b) This KPI describe the mean number of subscribers that are registered to a network slice instance. It is obtained
by counting the subscribers in AMF that are registered to a network slice instance. It is an Interger. The KPI type
is CUM.
c)
d) SubNetwork, NetworkSlice
6.2.2 Registered subscribers of network through UDM

a) UDMRegNbr.
b) This KPI describes the total number of subscribers that are registered to a network through UDM. It is
corresponding to the measurement RM.RegisteredSubUDMNbrMean that counts subscribers registered in UDM.
It is an Integer. The KPI type is CUM.
c) UDMRegNbr
∑௎஽ெ
d) SubNetwork
6.2.3 Registration success rate of one single network slice

a) RSR.
b) This KPI describes the ratio of the number of successfully performed registration procedures to the number of
attempted registration procedures for the AMF set which related to one single network slice and is used to
evaluate accessibility provided by the end-to-end network slice and network performance. It is obtained by
successful registration procedures divided by attempted registration procedures. It is a percentage. The KPI type
is RATIO.
c)
 AMF.5GSRegisSucc.Type
RSR =
Type
*100%
 AMF.5GSRegisAtt.Type
Type
NOTE: Above measurements with subcounter .Type should be defined in 3GPP TS 24.501 [4].
d) NetworkSlice
6.2.4 DRB Accessibility for UE services

a) DRB Accessibility
b) This KPI describes the DRBs setup success rate, including the success rate for setting up RRC connection and
NG signalling connection. It is obtained as the succeess rate for RRC connection setup multiplied by the success
rate for NG signalling connection setup multiplied by the success rate for DRB setup. The success rate for RRC
connection setup and for NG signalling connection setup shall exclude setups with establishment cause mo-
Signalling [5]. It is a percentage. The KPI type is RATIO.
ETSI
c) DRBAccessibility 5QI = (∑RRC.ConnEstabSucc.Cause/∑RRC.ConnEstabAtt.Cause) *

(∑UECNTXT.ConnEstabSucc.Cause/∑ UECNTXT.ConnEstabAtt.Cause) *
(DRB.EstabSucc.5QI/DRB.EstabAtt.5QI) * 100
DRB Accessibility SNSSAI = (∑RRC.ConnEstabSucc.Cause/∑RRC.ConnEstabAtt.Cause) *

(∑UECNTXT.ConnEstabSucc.Cause/∑ UECNTXT.ConnEstabAtt.Cause) *
(DRB.EstabSucc.SNSSAI/DRB.EstabAtt.SNSSAI) * 100.
The sum over causes shall exclude the establishment cause mo-Signalling [5].
For KPI on SubNetwork level the measurement shall be the averaged over all NRCellCUs in the SubNetwork
d) SubNetwork, NRCellCU.
6.2.5 PDU session Establishment success rate of one network slice (S-
NSSAI)
a) PDUSessionEstSR.
b) This KPI describes the ratio of the number of successful PDU session establishment request to the number of
PDU session establishment request attempts for 5G network for the SMF which related to one network slice (S-
NSSAI) and is used to evaluate accessibility provided by the end-to-end network slice and network performance.
It is obtained by the number of successful PDU session requests divided by the number of attempted PDU
session requests. It is a percentage. The KPI type is RATIO.
c)
d) NetworkSlice
6.3 Integrity KPI

6.3.1 Latency and delay of 5G networks
6.3.1.0 Void
6.3.1.1 Downlink latency in gNB-DU

a) DLLat_gNB-DU.
b) This KPI describes the gNB-DU part of the packet transmission latency experienced by an end-user. It is used to
evaluate the gNB latency contribution to the total packet latency. It is the average (arithmetic mean) of the time
from reception of IP packet to gNB-DU until transmission of first part of that packet over the air interface, for a
packet arriving when there is no previous data in queue for transmission to the UE. It is a time interval (0.1 mS).
The KPI type is MEAN. This KPI can optionally be split into KPIs per QoS level (mapped 5QI or QCI in NR
option 3) and per S-NSSAI.
c) DLLat_gNB-DU = DRB.RlcSduLatencyDl
or optionally DLLat_gNB-DU.QoS = DRB.RlcSduLatencyDl.QoS where QOS identifies the target QoS quality
of service class.
or optionally DLLat_gNB-DU.SNSSAI = DRB.RlcSduLatencyDl.SNSSAI where SNSSAI identifies the S-NSSAI.
d) NRCellDU
ETSI
6.3.1.2 Integrated downlink delay in RAN
6.3.1.2.1 Downlink delay in NG-RAN for a sub-network

a) DLDelay_NR_SNw.
b) This KPI describes the average packet transmission delay through the RAN part to the UE. It is used to evaluate
delay performance of NG-RAN in downlink for a sub-network. It is the weighted average packets delay from
reception of IP packet in gNB-CU-UP until the last part of an RLC SDU packet was received by the UE
according to received HARQ feedback information for UM mode or until the last part of an RLC SDU packet
was received by the UE according to received RLC ACK for AM mode. It is a time interval (0.1 ms). The KPI
type is MEAN. This KPI can optionally be split into KPIs per QoS level (mapped 5QI or QCI in NR option 3)
and per S-NSSAI.
c) Below are the equations for average “Integrated downlink delay in RAN” for this KPI on SubNetwork level. The
“Integrated downlink delay in RAN” is the sum of average DL delay in gNB-CU-UP of the sub-network
(DLDelay_gNBCUUP_SNw) and the average DL delay in gNB-DU of the sub-network
(DLDelay_gNBDU_SNw):
DLDelay_NR_SNw = DLDelay_gNBCUUP_SNw + DLDelay_gNBDU_SNw
or optionally DLDelay_ NR_SNw.QOS = DLDelay_gNBCUUP_SNw.QOS + DLDelay_gNBDU_SNw.QOS

where QOS identifies the target quality of service class.
or optionally DLDelay_NR_SNw.SNSSAI = DLDelay_gNBCUUP_SNw.SNSSAI +

DLDelay_gNBDU_SNw.SNSSAI where SNSSAI identifies the S-NSSAI.
d) SubNetwork
6.3.1.2.2 Downlink delay in NG-RAN for a network slice subnet

a) DLDelay_NR_Nss.
b) This KPI describes the average packet transmission delay through the RAN part to the UE. It is used to evaluate
delay performance of NG-RAN in downlink for a network slice subnet. It is the weighted average packets delay
from reception of IP packet in gNB-CU-UP until the last part of an RLC SDU packet was received by the UE
was received by the UE according to received RLC ACK for AM mode. It is a time interval (0.1 ms). The KPI
type is MEAN.
c) Below is the equation for average "Integrated downlink delay in RAN" for this KPI on NetworkSliceSubnet
level. The "Integrated downlink delay in RAN" for network slice subnet is the sum of average DL delay in gNB-
CU-UP of the network slice subnet (DLDelay_gNBCUUP_Nss) and the average DL delay in gNB-DU of the
network slice subnet (DLDelay_gNBDU_Nss):
DLDelay_NR_Nss.SNSSAI = DLDelay_gNBCUUP_Nss.SNSSAI + DLDelay_gNBDU_Nss.SNSSAI where

SNSSAI identifies the S-NSSAI that the network slice subnet supports.
d) NetworkSliceSubnet
6.3.1.3 Downlink delay in gNB-DU
6.3.1.3.1 Downlink delay in gNB-DU for a NRCellDU

a) DLDelay_gNBDU_Cell.
b) This KPI describes the average packet transmission delay through the gNB-DU part to the UE. It is used to
evaluate delay performance of gNB-DU in downlink. It is the average packets delay time from arrival of an RLC
SDU at the RLC ingress F1-U termination until the last part of an RLC SDU packet was received by the UE
ETSI
was received by the UE according to received RLC ACK for AM mode. It is a Time interval (0.1 ms). The KPI
type is MEAN. This KPI can optionally be split into KPIs per QoS level (mapped 5QI or QCI in NR option 3)
and per S-NSSAI.
c) Below is the equation for average DL delay in gNB-DU for a NRCellDU:
DLDelay_gNBDU_Cell = DRB.RlcSduDelayDl + DRB.AirIfDelayDl.
and optionally: DLDelay_gNBDU.QOS = DRB.RlcSduDelayDl.QOS + DRB.AirIfDelayDl.QOS where QOS

identifies the target quality of service class.
and optionally: DLDelay_gNB.SNSSAI = DRB.RlcSduDelayDl.SNSSAI + DRB.AirIfDelayDl.SNSSAI where

SNSSAI identifies the S-NSSAI
d) NRCellDU
6.3.1.3.2 Downlink delay in gNB-DU for a sub-network

a) DLDelay_gNBDU_SNw.
evaluate delay performance of gNB-DU in downlink for a sub-network. It is the weighted average packets delay
time from arrival of an RLC SDU at the RLC ingress F1-U termination until the last part of an RLC SDU packet
was received by the UE according to received HARQ feedback information for UM mode or until the last part of
an RLC SDU packet was received by the UE according to received RLC ACK for AM mode. It is a Time
interval (0.1 ms). The KPI type is MEAN. This KPI can optionally be split into KPIs per QoS level (mapped 5QI
or QCI in NR option 3) and per S-NSSAI.
c) Below is the equation for average DL delay in gNB-DU for a sub-network, where
- W is the measurement for the weighted average, one of the following:
- the DL data volume of the NR cell;
- the number of UL user data packets of the NR cell;
- any other types of weight defined by the consumer of KPI
- the #NRCellDU is the number of NRCellDU’s in the SubNetwork.

#

DLDelay_gNBDU_SNw = ∑ .
∑#
. ∗

and optionally KPI on SubNetwork level per QoS and per S-NSSAI:
#

DLDelay_gNBDU_SNw. ܳ‫ ∑ = ܵ݋‬ . .
∑#
. . ∗
.
#

DLDelay_gNBDU_SNw. ܵܰܵܵ‫ ∑ = ܫܣ‬ . .
∑#
. . ∗
.
d) SubNetwork
6.3.1.3.3 Downlink delay in gNB-DU for a network slice subnet

a) DLDelay_gNBDU_Nss.
evaluate delay performance of gNB-DU in downlink for a network slice subnet. It is the weighted average
packets delay time from arrival of an RLC SDU at the RLC ingress F1-U termination until the last part of an
RLC SDU packet was received by the UE according to received HARQ feedback information for UM mode or
until the last part of an RLC SDU packet was received by the UE according to received RLC ACK for AM
mode. It is a Time interval (0.1 ms). The KPI type is MEAN.
c) Below is the equation for average DL delay in gNB-DU for a network slice subnet, where
ETSI
- the number of DL user data packets of the NR cell;
- any other types of weight requested by the consumer of KPI;
- the #NRCellDU is the number of NRCellDU’s associated with the NetworkSliceSubnet.

#

DLDelay_gNBDU_Nss. ܵܰܵܵ‫ ∑ = ܫܣ‬ . .
∑#
.

. ∗
.
6.3.1.4 Downlink delay in gNB-CU-UP
6.3.1.4.1 Downlink delay in gNB-CU-UP

a) DLDelay_gNBCUUP.
b) This KPI describes the average packet transmission delay through the gNB-CU-UP to the gNB-DU. It is used to
evaluate the delay performance of gNB-CU-UP in downlink. It is the average packets delay from reception of IP
packet in gNB-CU-UP until the time of arrival, at the gNB-DU, of the RLC SDU at the RLC ingress F1-U
termination. It is a Time interval (0.1 ms). The KPI type is MEAN. This KPI can optionally be split into KPIs
per QoS level (mapped 5QI or QCI in NR option 3) and per S-NSSAI.
c) Below the equation for average DL delay in a gNB-CU-CP:
DLDelay_gNBCUUP = DRB. PdcpSduDelayDl + DRB.PdcpF1Delay
and optionally: DLDelay_ gNBCUUP.QOS = DRB.PdcpSduDelayDl.QOS + DRB.PdcpF1Delay.QOS where

QOS identifies the target quality of service class.
and optionally: DLDelay_gNBCUUP.SNSSAI = DRB.PdcpSduDelayDl.SNSSAI + DRB.PdcpF1Delay.SNSSAI

where SNSSAI identifies the S-NSSAI.
d) GNBCUUPFunction
e) In non-split gNB scenario, the value of DRB.PdcpF1Delay (optionally DRB.PdcpF1Delay.QOS, and optionally
DRB.PdcpF1Delay.SNSSAI) is set to zero because there are no F1-interfaces in this scenario.
6.3.1.4.2 Downlink delay in gNB-CU-UP for a sub-network

a) DLDelay_gNBCUUP_SNw.
b) This KPI describes the average packet transmission delay through the gNB-CU-UP to the gNB-DU. It is used to
evaluate the delay performance of gNB-CU-UP in downlink for a sub-network. It is the weighted average
packets delay from reception of IP packet in gNB-CU-UP until the time of arrival, at the gNB-DU, of the RLC
SDU at the RLC ingress F1-U termination. It is a Time interval (0.1 ms). The KPI type is MEAN. This KPI can
optionally be split into KPIs per QoS level (mapped 5QI or QCI in NR option 3) and per S-NSSAI.
c) Below is the equation for average UL delay in gNB-CU-UP for a sub-network, where
- the DL data volume in gNB-CU-UP;
- the number of DL user data packets in gNB-CU-UP;
- the # GNBCUUPFunctions is the number of GNBCUUPFunctions’s in the SubNetwork.

#

DLDelay_gNBCUUP_SNw = ∑ .
∑#

. !
∗
ETSI
#

DLDelay_gNBCUUP_SNw. ܳ‫ ∑ = ܵ݋‬ .
∑#

.

. ! "#
. ∗ .
DLDelay_gNBCUUP_SNw. ܵܰܵܵ‫= ܫܣ‬

∑#

!
. . . . ∗ .
∑#

.
d) SubNetwork
e) In non-split gNB scenario, the value of DRB.PdcpF1Delay (optionally DRB.PdcpF1Delay.QOS, and optionally
DRB.PdcpF1Delay.SNSSAI) is set to zero because there are no F1-interfaces in this scenario.
6.3.1.4.3 Downlink delay in gNB-CU-UP for a network slice subnet

a) DLDelay_gNBCUUP_Nss.
b) This KPI describes the average packet transmission delay through the gNB-CU-UP to gNB-DU. It is used to
evaluate the delay performance of gNB-CU-UP in downlink for a network slice subnet. It is the weighted
average packets delay from reception of IP packet in gNB-CU-UP until the time of arrival, at the gNB-DU, of
the RLC SDU at the RLC ingress F1-U termination. It is a Time interval (0.1 ms). The KPI type is MEAN.
c) Below is the equation for average UL delay in gNB-CU-UP for a network slice subnet, where
- the DL data volume in gNB-CU-UP;
- the number of DL user data packets in gNB-CU-UP;
- the # GNBCUUPFunctions is the number of GNBCUUPFunctions’s associated with the

NetworkSliceSubnet.
DLDelay_gNBCUUP_Nss. ܵܰܵܵ‫= ܫܣ‬

∑#

!
. . . . ∗ .
∑#

.
e) In non-split gNB scenario, the value of DRB.PdcpF1Delay.SNSSAI is set to zero because there are no F1-
interfaces in this scenario.
6.3.1.5 Uplink delay in gNB-DU
6.3.1.5.1 Uplink delay in gNB-DU for a NR cell

a) ULDelay_gNBDU_Cell.
b) This KPI describes the average packet transmission delay through the gNB-DU part from the UE in a NR cell. It
is used to evaluate delay performance of gNB-DU in uplink. It is the average packet delay from when an UL
RLC SDU was scheduled, as per the scheduling grant provided, until time when the RLC SDU is sent to PDCP
or CU for split gNB. It is a time interval (0.1 ms). The KPI type is MEAN. This KPI can optionally be split into
KPIs per QoS level (mapped 5QI or QCI in NR option 3) and per S-NSSAI.
c) Below is the equation for average UL delay in gNB-DU for a NRCellDU:
ULDelay_gNBDU_Cell = DRB.RlcDelayUI + DRB.AirIfDelayUI
and optionally: ULDelay_gNBDU. ܳ‫ = ܵ݋‬DRB. RlcDelayUl. ܱܳܵ + DRB. AirIfDelayUl. ܱܳܵ where QOS
ETSI
and optionally: ULDelay_gNBDU. ܵܰܵܵ‫ܫܣ‬ = DRB. RlcDelayUl. ܵܰܵܵ‫ ܫܣ‬+ DRB. AirIfDelayUl. ܵܰܵܵ‫ܫܣ‬ where
SNSSAI identifies the S-NSSAI.
d) NRCellDU
6.3.1.5.2 Uplink delay in gNB-DU for a sub-network

a) ULDelay_gNBDU_SNw.
b) This KPI describes the average packet transmission delay through the gNB-DU part from the UE for a sub-
network. It is used to evaluate delay performance of gNB-DU in uplink for a sub-network. It is the weighted
average packet delay from when an UL RLC SDU was scheduled, as per the scheduling grant provided, until
time when the RLC SDU is sent to PDCP or CU for split gNB. It is a time interval (0.1 ms). The KPI type is
MEAN. This KPI can optionally be split into KPIs per QoS level (mapped 5QI or QCI in NR option 3) and per
S-NSSAI.
c) Below is the equation for average UL delay in gNB-DU for a sub-network, where
- the UL data volume of the NR cell;
- any other types of weight defined by the consumer of KPI
# $ $

ULDelay_gNBDU_SNw = ∑ .
∑#
. ∗

# $ $
ULDelay_gNBDU_SNw. ܳ‫ ∑ = ܵ݋‬ . .
∑#
. . ∗
.
# $ $

ULDelay_gNBDU_SNw. ܵܰܵܵ‫ ∑ = ܫܣ‬ . .
∑#
. . ∗
.
d) SubNetwork
6.3.1.5.3 Uplink delay in gNB-DU for a network slice subnet

a) ULDelay_gNBDU_Nss.
b) This KPI describes the average packet transmission delay through the gNB-DU part from the UE for a network
slice subnet. It is used to evaluate delay performance of gNB-DU in uplink for a network slice subnet. It is the
weighted average packet delay from when an UL RLC SDU was scheduled, as per the scheduling grant
provided, until time when the RLC SDU is sent to PDCP or CU for split gNB. It is a time interval (0.1 ms). The
KPI type is MEAN.
c) Below is the equation for average UL delay in gNB-DU for a network slice subnet, where
ETSI
# $ $

ULDelay_gNBDU_Nss. ܵܰܵܵ‫ ∑ = ܫܣ‬ . .
∑#
.

. ∗
.
6.3.1.6 Uplink delay in gNB-CU-UP
6.3.1.6.1 Uplink delay in gNB-CU-UP

a) ULDelay_gNBCUUP.
b) This KPI describes the average packet transmission delay through the gNB-CU-UP from gNB-DU. It is used to
evaluate delay performance of gNB-CU-UP in uplink. It is the average packet delay from when the RLC SDU is
sent to PDCP or CU for split gNB, until time when the corresponding PDCP SDU was sent to the core network
from gNB-CU-UP. It is a time interval (0.1 ms). The KPI type is MEAN. This KPI can optionally be split into
KPIs per QoS level (mapped 5QI or QCI in NR option 3) and per S-NSSAI.
c) Below the equation for average UL delay in a gNB-CU-CP:
ULDelay_gNBCUUP = DRB. PdcpReordDelayUl + DRB. PdcpF1Delay

and optionally: ULDelay_gNBCUUP. ܳ‫ = ܵ݋‬DRB. PdcpReordDelayUl. ܳ‫ ܵ݋‬+ DRB. PdcpF1Delay. ܳ‫ ܵ݋‬where QOS
and optionally: ULDelay_gNBCUUP. ܵܰܵܵ‫ܫܣ‬ = DRB. PdcpReordDelayUl. ܵܰܵܵ‫ܫܣ‬ + DRB. PdcpF1Delay. ܵܰܵܵ‫ܫܣ‬
where SNSSAI identifies the S-NSSAI.
d) GNBCUUPFunction
e) It is assumed that the F1 uplink delay is the same as the F1 downlink delay. In non-split gNB scenario, the value
of DRB.PdcpF1Delay (optionally DRB.PdcpF1Delay.QOS, and optionally DRB.PdcpF1Delay.SNSSAI) is set to
zero because there are no F1-interfaces in this scenario.
6.3.1.6.2 Uplink delay in gNB-CU-UP for a sub-network

a) ULDelay_gNBCUUP_SNw.
b) This KPI describes the average packet transmission delay through the gNB-CU-UP part from the gNB-DU for a
sub-network. It is used to evaluate delay performance of gNB-CU-UP in uplink for a sub-network. It is the
weighted average packet delay from when the RLC SDU is sent to PDCP or CU for split gNB, until time when
the corresponding PDCP SDU was sent to the core network from gNB-CU-UP. It is a time interval (0.1 ms). The
KPI type is MEAN. This KPI can optionally be split into KPIs per QoS level (mapped 5QI or QCI in NR option
3) and per S-NSSAI.
c) Below is the equation for average UL delay in gNB-CU-UP for a sub-network, where
- the UL data volume in gNB-CU-UP ;
- the number of UL user data packets in gNB-CU-UP ;
- the # GNBCUUPFunctions is the number of GNBCUUPFunctions’s in the SubNetwork.

#

ULDelay_gNBCUUP_SNw = ∑ .
∑#

. ∗

#

ULDelay_gNBCUUP_SNw. ܳ‫∑ = ܵ݋‬ .
∑#

. . ∗
.
.
ETSI
ULDelay_gNBCUUP_SNw. ܵܰܵܵ‫= ܫܣ‬

∑#

. . . . ∗ .
∑#

.
d) SubNetwork
of DRB.PdcpF1Delay (optionally DRB.PdcpF1Delay.QOS, and optionally DRB.PdcpF1Delay.SNSSAI) is set to
zero because there are no F1-interfaces in this scenario.
6.3.1.6.3 Uplink delay in gNB-CU-UP for a network slice subnet

a) ULDelay_gNBCUUP_Nss.
b) This KPI describes the average packet transmission delay through the gNB-CU-UP part from the gNB-DU for a
network slice subnet. It is used to evaluate delay performance of gNB-CU-UP in uplink for a network slice
subnet. It is the weighted average packet delay from when the RLC SDU is sent to PDCP or CU for split gNB,
until time when the corresponding PDCP SDU was sent to the core network from gNB-CU-UP. It is a time
interval (0.1 ms). The KPI type is MEAN. This KPI can optionally be split into KPIs per QoS level (mapped 5QI
or QCI in NR option 3) and per S-NSSAI.
c) Below is the equation for average UL delay in gNB-CU-UP for a network slice subnet, where
- the UL data volume in gNB-CU-UP;
- the number of UL user data packets in gNB-CU-UP;
- the # GNBCUUPFunctions is the number of GNBCUUPFunctions’s associated with the

NetworkSliceSubnet.
ULDelay_gNBCUUP_Nss. ܵܰܵܵ‫= ܫܣ‬

∑#

. . . . ∗ .
∑#

.
of DRB.PdcpF1Delay.SNSSAI is set to zero because there are no F1-interfaces in this scenario.
6.3.1.7 Integrated uplink delay in RAN
6.3.1.7.1 Uplink delay in NG-RAN for a sub-network

a) ULDelay_NR_SNw.
b) This KPI describes the average packet transmission delay through the RAN part from the UE for a sub-network.
It is used to evaluate delay performance of NG-RAN in uplink. It is the weighted average packet delay from
when an UL RLC SDU was scheduled, as per the scheduling grant provided, until time when the corresponding
PDCP SDU was sent to the core network from gNB-CU-UP. It is a time interval (0.1 ms). The KPI type is
MEAN. This KPI can optionally be split into KPIs per QoS level (mapped 5QI or QCI in NR option 3) and per
S-NSSAI.
c) Below are the equations for average "Integrated uplink delay in RAN" for this KPI on SubNetwork level. The
"Integrated uplink delay in RAN" is the sum of average UL delay in gNB-CU-UP of the sub-network
(ULDelay_gNBCUUP_SNw) and the average UL delay in gNB-DU of the sub-network
(ULDelay_gNBDU_SNw):
ULDelay_NR_SNw = ULDelay_gNBCUUP_SNw + ULDelay_gNBDU_SNw
ETSI
or optionally ULDelay_ NR_SNw.QOS = ULDelay_gNBCUUP_SNw.QOS + ULDelay_gNBDU_SNw.QOS

where QOS identifies the target quality of service class.
or optionally ULDelay_NR_SNw.SNSSAI = ULDelay_gNBCUUP_SNw.SNSSAI +

ULDelay_gNBDU_SNw.SNSSAI where SNSSAI identifies the S-NSSAI.
d) SubNetwork
6.3.1.7.2 Uplink delay in NG-RAN for a network slice subnet

a) ULDelay_NR_Nss.
b) This KPI describes the average packet transmission delay through the RAN part from the UE for a network slice
subnet. It is used to evaluate delay performance of NG-RAN in uplink. It is the weighted average packet delay
from when an UL RLC SDU was scheduled, as per the scheduling grant provided, until time when the
corresponding PDCP SDU was sent to the core network from gNB-CU-UP. It is a time interval (0.1 ms). The
KPI type is MEAN. This KPI can optionally be split into KPIs per QoS level (mapped 5QI or QCI in NR option
3) and per S-NSSAI.
c) Below is the equation for average “Integrated uplink delay in RAN” for this KPI on NetworkSliceSubNet level.
The “Integrated uplink delay in RAN” for network slice subnet is the sum of average UL delay in gNB-CU-UP
of the network slice subnet (ULDelay_gNBCUUP_Nss) and the average UL delay in gNB-DU of the network
slice subnet (ULDelay_gNBDU_Nss):
ULDelay_NR_Nss.SNSSAI = ULDelay_gNBCUUP_Nss.SNSSAI + ULDelay_gNBDU_Nss.SNSSAI where

SNSSAI identifies the S-NSSAI that the network slice subnet supports.
6.3.1.8 E2E delay for network slice
6.3.1.8.1 Average e2e uplink delay for a network slice

a) DelayE2EUlNs.
b) This KPI describes the average e2e UL packet delay between the PSA UPF and the UE for a network slice. It is
the weighted average packet delay from the time when an UL RLC SDU was scheduled at the UE until the time
when the corresponding GTP PDU was received by the PSA UPF. The KPI type is MEAN in unit of 0.1 ms.
c) This KPI is the weighted average of UL packet delay between PSA UPF and UE, for all N3 interfaces (modelled
by EP_N3 MOIs) and N9 interfaces (modelled by EP_N9 MOIs) of all PSA UPFs supporting the network slice
(modelled by NetworkSlice MOI) identified by the S-NSSAI.
This KPI is calculated in the equation below, where Wn3 and Wn9 are the measurements for the weighted
average, Wn3 is one of the following:
- the data volume of UL GTP PDUs received by PSA UPF on the N3 interface;
- the number of UL GTP PDUs received by PSA UPF on the N3 interface;
- any other types of weight defined by the consumer of KPI.
And Wn9 is one of the following:
- the data volume of UL GTP PDUs received by PSA UPF on the N9 interface;
- the number of UL GTP PDUs received by PSA UPF on the N9 interface;
ETSI
DelayE2EUlNs =
∑ _.

.∗. ∑ _.

.∗.
∑ _ . ∑ _ .
Where the SNSSAI identifies the S-NSSAI.
d) NetworkSlice.
6.3.1.8.2 Average e2e downlink delay for a network slice

a) DelayE2EDlNs.
b) This KPI describes the average e2e DL packet delay between the PSA UPF and the UE for a network slice. It is
the weighted average packet delay from the time when an GTP PDU has been sent by the PSA UPF until time
when the corresponding RLC SDU was received by the UE. The KPI type is MEAN in unit of 0.1 ms.
c) This KPI is the weighted average of DL packet delay between PSA UPF and UE, for all N3 interfaces (modelled
by EP_N3 MOIs) and N9 interfaces (modelled by EP_N9 MOIs) of all PSA UPFs supporting the network slice
(modelled by NetworkSlice MOI) identified by the S-NSSAI.
This KPI is calculated in the equation below, where Wn3 and Wn9 are the measurements for the weighted
average, Wn3 is one of the following:
- the data volume of DL GTP PDUs transmitted by PSA UPF on the N3 interface;
- the number of DL GTP PDUs transmitted by PSA UPF on the N3 interface;
And Wn9 is one of the following:
- the data volume of DL GTP PDUs transmitted by PSA UPF on the N9 interface;
- the number of DL GTP PDUs transmitted by PSA UPF on the N9 interface;
DelayE2EDlNs =
∑ _.

.∗.. ∑ _.

.∗.
∑ _ . ∑ _ .
Where the SNSSAI identifies the S-NSSAI.
d) NetworkSlice.
6.3.2 Upstream throughput for network and Network Slice Instance

a) UTSNSI.
b) This KPI describes the upstream throughput of one single network slice by computing the packet size for each
successfully received UL IP packet through the network slice during each observing granularity period and is
used to evaluate integrity performance of the end-to-end network slice . It is obtained by upstream throughput
provided by N3 interface from NG-RAN to all UPFs which are related to the single network slice . The KPI unit
is kbit/s and the KPI type is CUM.
c)
d) NetworkSlice, SubNetwork.
ETSI
6.3.3 Downstream throughput for Single Network Slice Instance

a) DTSNSI.
b) This KPI describes the downstream throughput of one single network slice instance by computing the packet size
for each successfully transmitted DL IP packet through the network slice instance during each observing
granularity period and is used to evaluate integrity performance of the end-to-end network slice instance. It is
obtained by downstream throughput provided by N3 interface from all UPFs to NG-RAN which are related to
the single network slice . The KPI unit is kbit/s and the KPI type is CUM.
c)
d) NetworkSlice.
6.3.4 Upstream Throughput at N3 interface

a) N3UpstreamThr.
b) This KPI describes the total number of octets of all incoming GTP data packets on the N3 interface (measured at
UPF) which have been generated by the GTP-U protocol entity on the N3 interface, during a granularity period.
This KPI is used to evaluate upstream GTP throughput integrity performance at the N3 interface. It is obtained
by measuring the GTP data upstream throughput provided by N3 interface from NG-RAN to UPF, during the
granularity period. The KPI unit is kbit/s and the KPI type is MEAN.
c) UGTPTS=SUM (GTP.InDataOctN3UPF)/timeperiod) at UPF
d) NetworkSlice
6.3.5 Downstream Throughput at N3 interface

a) N3DownstreamThr.
b) This KPI describes the total number of octets of all downstream GTP data packets on the N3 interface
(transmitted downstream from UPF) which have been generated by the GTP-U protocol entity on the N3
interface, during a granularity period. This KPI is used to evaluate integrity performance at N3 interface. It is
obtained by measuring the GTP data downstream throughput provided by N3 interface from UPF to NG-RAN,
during the granularity period. The KPI unit is kbit/s and the KPI type is MEAN.
c) DGTPTS=SUM (GTP.OutDataOctN3UPF)/timeperiod) at UPF
d) NetworkSlice
6.3.6 RAN UE Throughput
6.3.6.1 Void
6.3.6.2 RAN UE Throughput definition

To achieve a Throughput measurement (below examples are given for DL) that is independent of file size and gives a
relevant result it is important to remove the volume and time when the resource on the radio interface is not fully
utilized. (Successful transmission, buffer empty in figure 1).
ETSI
Successful transmission,
buffer not empty
The last slot shall
Failed transmission ( ”Block always be
ThpTimeDl removed from
error ”)
calulations since it
Successful transmission,
can be impacted
buffer empty
by packet size of
User Plane (UP) packets.
No transmission, buffer not
empty (e.g. due to contention)
Data arrives to Time (slots)

empty DL buffer
First data is The send buffer is

transmitted to the UE again empty
∑
ThpVolDl = (kbits)
Total DL transferred volume = ∑ + (kbits)
UE Throughput in DL = ThpVolDl / ThpTimeDl (kbits/s)
Figure 1
To achieve a throughput measurement that is independent of bursty traffic pattern, it is important to make sure that idle
gaps between incoming data is not included in the measurements. That shall be done as considering each burst of data
as one sample.
6.3.6.3 DL RAN UE throughput
6.3.6.3.1 DL RAN UE throughput for a NRCellDU

a) DlUeThroughput _Cell.
b) This KPI describes the average DL RAN UE throughput for a NRCellDU. The KPI type is MEAN in kbit per
second. This KPI can optionally be split into KPIs per QoS level (mapped 5QI or QCI in NR option 3) and per S-
NSSAI.
c) Below is the equation for average DL RAN UE throughput for a NRCellDU:
DlUeThroughput _Cell = DRB.UEThpDl;
and optionally: DlUeThroughput _Cell.QOS = DRB.UEThpDl.QOS, where QOS identifies the target quality of
service class;
and optionally: DlUeThroughput _Cell.SNSSAI = DRB.UEThpDl.SNSSAI, where SNSSAI identifies the S-

NSSAI.
d) NRCellDU
6.3.6.3.2 DL RAN UE throughput for a sub-network

a) DlUeThroughput _SNw.
b) This KPI describes the average DL RAN UE throughput for a sub-network. The KPI type is MEAN in kbit per
NSSAI.
c) Below is the equation for average DL RAN UE throughput for a sub-network, where
- W is the measurement for the weighted average, it is one of the following:
ETSI
- a weight defined by the consumer of KPI
∑#!"#$%%&'
(
DlUeThroughput _SNw = #!"#$%%&' )
∑( &"* '+,-.&%
.

∑#!"#$%%&'
(
DlUeThroughput _SNw. ܳ‫= ܵ݋‬
.
#!"#$%%&'
∑( ) /01
&"* '+,-.&%
. /01
.
∑#!"#$%%&'
(

DlUeThroughput _SNw. ܵܰܵܵ‫= ܫܣ‬
.
∑#!"#$%%&' ) 121134
( &"* '+,-.&% 121134
.
.
d) SubNetwork
6.3.6.3.3 DL RAN UE throughput for a network slice subnet

a) DlUeThroughput _Nss.
b) This KPI describes the average DL RAN UE throughput for a network slice subnet. The KPI type is MEAN in
kbit per second.
c) Below is the equation for average DL RAN UE throughput for a network slice subnet, where
∑#!"#$%%&'
(

DlUeThroughput_Nss. ܵܰܵܵ‫= ܫܣ‬
.
#!"#$%%&' ) 121134 , where the SNSSAI identifies the S-NSSAI

∑( &"* '+,-.&%
. 121134
.
that the NetworkSliceSubnet supports.
6.3.6.4 UL RAN UE throughput
6.3.6.4.1 UL RAN UE throughput for a NRCellDU

a) UlUeThroughput_Cell.
b) This KPI describes the average UL RAN UE throughput for a NRCellDU. The KPI type is MEAN in kbit per
NSSAI.
c) Below is the equation for average UL RAN UE throughput for a NRCellDU:
UlUeThroughput _Cell = DRB.UEThpUl;
and optionally: UlUeThroughput_Cell.QOS = DRB.UEThpUl.QOS, where QOS identifies the target quality of
service class;
and optionally: UlUeThroughput_Cell.SNSSAI = DRB.UEThpUl.SNSSAI, where SNSSAI identifies the S-

NSSAI.
d) NRCellDU
ETSI
6.3.6.4.2 UL RAN UE throughput for a sub-network

a) UlUeThroughput_SNw.
b) This KPI describes the average UL RAN UE throughput for a sub-network. The KPI type is MEAN in kbit per
NSSAI.
c) Below is the equation for average UL RAN UE throughput for a sub-network, where
∑#!"#$%%&'
(
UlUeThroughput_SNw = )
∑#!"#$%%&'
( &"* '+,-.'%
.
∑#!"#$%%&'
(
UlUeThroughput_SNw. ܳ‫= ܵ݋‬
.
∑#!"#$%%&' ) /01
( &"* '+,-.'% /01
.
.
∑#!"#$%%&'
(

UlUeThroughput_SNw. ܵܰܵܵ‫= ܫܣ‬
.
#!"#$%%&'
∑( ) 121134
&"* '+,-.'%
. 121134
.
d) SubNetwork
6.3.6.4.3 UL RAN UE throughput for a network slice subnet

a) UlUeThroughput _Nss.
b) This KPI describes the average UL RAN UE throughput for a network slice subnet. The KPI type is MEAN in
kbit per second.
c) Below is the equation for average UL RAN UE throughput for a network slice subnet, where
∑#!"#$%%&'
(

UlUeThroughput_Nss. ܵܰܵܵ‫= ܫܣ‬
.
#!"#$%%&' ) 121134 , where the SNSSAI identifies the S-NSSAI

∑( &"* '+,-.'%
. 121134
.
that the NetworkSliceSubnet supports.
ETSI
6.4 Utilization KPI

6.4.1 Mean number of PDU sessions of network and network Slice
Instance
a) PDUSesMeanNbr.
b) This KPI describes the mean number of PDU sessions that are successfully established in a network slice . It is
obtained by successful PDU session establishment procedures of SMFs which is related to the network slice . It
is an integer. The KPI type is MEAN.
c)
d) NetworkSlice
6.4.2 Virtualised Resource Utilization of Network Slice Instance

a) VirtualResUtilizaiton.
b) This KPI describes utilization of virtualised resource (e.g. processor, memory, disk) that are allocated to a
network slice . It is obtained by the usage of virtualised resource (e.g. processor, memory, disk) divided by the
system capacity that allocated to the network slice . It is a percentage, The KPI type is Ratio.
NOTE: In the present document, this KPI is for the scenario when NF is not shared between different network
slice .
MeanProcessorUsage
c) VRU Processor = *100%
System Capacity Processor
MeanMemoryUsage
VRU Memory = *100%
System Capacity Memory
MeanDiskUsage
VRU Disk = *100%
System Capacity Disk
d) NetworkSlice
6.4.3 PDU session establishment time of network slice

a) PDUEstTime.
b) This KPI describes the time of successful PDU session establishment which related to one single network slice
and is used to evaluate utilization provided by the end-to-end network slice and network performance. It is
obtained by measuring the time between the receipt by SMF from AMF of "
Nsmf_PDUSession_UpdateSMContext Request ", which includes N2 SM information received from (R)AN to
the SMF and the sending of a " Nsmf_PDUSession_CreateSMContext Request or
Nsmf_PDUSession_UpdateSMContext Request PDU Session Establishment Request " message from AMF to
the SMF. It is a time interval (millisecond). The KPI type is MEAN.
c) PDUEstTime = SM.PduSessionTimeMean.SNSSAI
d) NetworkSlice
ETSI
6.4.4 Mean number of successful periodic registration updates of Single

Network Slice
a) RegUpdMeanNbr.
b) This KPI describes the mean number of successfully periodic registration updates in a network slice at the AMF.
It is obtained by summing successful of periodic registration updates at the AMFs which is related to the
network slice after registration accept by the AMF to the UE that sent the periodic registration update request. It
is an integer. The KPI type is MEAN.
c)
d) NetworkSlice
6.5 Retainability KPI

6.5.1 QoS flow Retainability
6.5.1.1 Definition
a) QoSRetain_R1, QoSRetain_R2.
b) This KPI shows how often an end-user abnormally loses a QoS flow during the time the QoS flow is used. It is
obtained by number of QoS flows with data in a buffer that was abnormally released, normalized with number of
data session time units. The unit of this KPI is “active release / second”. The KPI type is MEAN.
c) To measure QoS flow Retainability for a single QoS level (R1) is fairly straight forward.
. . _
1 _ . .oS
_
However to measure the QoS flow Retainability for UEs is not as straight forward. The measurement R1 is
defined to look at the activity level of just one QoS level at the time, so to use this formula and measurements in
an aggregated way to get QoS flow Retainability on UE level will not be accurate (e.g. for an UE with multiple
QoS flows there might be QoS flows that are active at the same time, hence aggregating the QoS level
measurements for session time will give a larger session time than the total UE session time. See picture below).
UE session time: 10 periods (UE1:4, UE2:6)
QoS=X session time: 7 periods (UE1:4, UE2:3)
QoS=Y session time: 5 periods (UE1:0, UE2:5)
QoS Flow
UE1 QoS=X
One activity period
QoS Flow
QoS=X
UE2
QoS Flow
QoS=Y
[t]
Hence a measurement QoS flow Retainability on UE level is defined (R2) to provide a measurement for the
overall QoS flow Retainability.
ETSI
∑ .
.
2
.
d) SubNetwork, NRCellCU
e) The definition of the service provided by 5GS is QoS flows.
6.5.1.2 Extended definition

The retainability rate is defined as:
Number of abnormally released QoS flow with data in any of the buffers
[Releases/Session time]
Active QoS flow Time
Number of abnormally released QoS flow with data in any of the buffers
[Releases/Session time]
To define (from a QoS flow Retainability point of view) if a QoS flow is considered active or not, the QoS flows can be
divided into two groups:
- For QoS flows with bursty flow, a QoS flow is said to be active if there is user data in the PDCP queue in any of
the directions or if any data (UL or DL) has been transferred during the last 100 ms.
- For QoS flows with continuous flow, the QoS flow (and the UE) is always seen as being active in the context of
this measurement, and the session time is increased from the first data transmission on the QoS flow until 100
ms after the last data transmission on the QoS flow.
6.5.2 DRB Retainability
6.5.2.1 Definition
a) DRBRetain
b) This KPI shows how often an end-user abnormally loses a DRB during the time the DRB is active. It is obtained
by number of DRBs that were abnormally released and that were active at the time of release, normalized with
number of data session time units. The unit of this KPI is "active release / second". The KPI type is MEAN.
c) DRB Retainability for a single mapped 5QI level (R1) and for a single S-NSSAI (R1) are defined as:
.
. 5 _
1 _
. .5QI _
and
.
.
_
1 _
. .
I _
d) SubNetwork, NRCellCU
e) The definition of the service provided by 5GS is DRBs.
ETSI
6.5.2.2 Extended definition
To define (from a DRB Retainability point of view) if a DRB is considered active or not, the DRB can be divided into
two groups:
- For DRBs with bursty flow, a DRB is said to be active if there is user data in the PDCP queue in any of the
directions or if any data (UL or DL) has been transferred during the last 100 ms.
- For DRBs with continuous flow, the DRB (and the UE) is always seen as being active in the context of this
measurement, and the session time is increased from the first data transmission on the DRB until 100 ms after
the last data transmission on the DRB.
A particular DRB is defined to be of type continuous flow if the mapped 5QI is any of {1, 2, 65, 66}.
6.6 Mobility KPI

6.6.1 NG-RAN handover success rate
a) GRANHOSR.
b) A KPI that shows how often a handover within NR-RAN is successful, regardless if the handover was made due
to bad coverage or any other reason. This KPI is obtained by successful handovers to the same or another gNB
divided by attempted handovers to the same or another gNB.
ሺ୑୑.ୌ୭୉୶ୣ୍୬୲ୣ୰ୗ୳ୡୡା୑୑.ୌ୭୉୶ୣ୍୬୲୰ୟୗ୳ୡୡሻ ሺ୑୑.ୌ୭୔୰ୣ୮୍୬୲ୣ୰ୗ୳ୡୡା୑୑.ୌ୭୔୰ୣ୮୍୬୲୰ୟୗ୳ୡୡሻ
c)GRANHOSR = ሺ୑୑.ୌ୭୉୶ୣ୍୬୲ୣ୰ୖୣ୯ା୑୑.ୌ୭୉୶ୣ୍୬୲୰ୟୖୣ୯ሻ
× ሺ୑୑.ୌ୭୔୰ୣ୮୍୬୲ୣ୰ୖୣ୯ା୑୑.ୌ୭୔୰ୣ୮୍୬୲୰ୟୖୣ୯ሻ
×
100ሾ%ሿMM.HoExeInterSucc, MM.HoExeIntraSucc, MM.HoExeInterReq, MM.HoExeIntraReq,
MM.HoPrepInterSucc, MM.HoPrepIntraSucc, MM.HoPrepInterReq and MM.HoPrepIntraReq.
6.6.2 Mean Time of Inter-gNB handover Execution of Network Slice

a) InterGNBHOMeanTime.
b) This KPI describes the time of successful Mean Time of Inter-gNB handover which related to one single
network slice and is used to evaluate utilization provided by the end-to-end network slice and network
performance. This KPI is obtained by measuring the time between the receipt by the Source NG-RAN from the
Target NG-RAN of a “Release Resource" and the sending of a " N2 Path Switch Request " message from Source
NG-RAN to the Target NG-RAN over a granularity period. The unit of this KPI is millisecond.
d) Subnetwork
6.6.3 Successful rate of mobility registration updates of Single Network

Slice
a) MobilityRegUpdateSR.
b) This KPI describes the successful rate of mobility registration updates in a network slice e at the AMF. This KPI
is obtained by deviding the number of successful mobility registration updates at the AMFs by number of
mobility registration update requests received by the AMFs of single network slice.
d) NetworkSlice
6.6.4 5GS to EPS handover success rate

a) 5GSEPSHOSR.
ETSI
b) A KPI that shows how often a handover from 5GS to EPS is successful, regardless if the handover was made due
to bad coverage or any other reason. This KPI is obtained by successful handovers from 5GS to EPS system
divided by the total number of handovers attempt’s from 5GS to EPS system.
ሺ୑୑.ୌ୭୓୳୲୉୶ୣହ୥ୱ୘୭୉୮ୱୗ୳ୡୡሻ ሺ୑୑.
c) 5GSEPSHOSR = ሺ୑୑.ୌ୭୓୳୲୉୶ୣହ୥ୱ୘୭୉୮ୱୖୣ୯ሻ
× ሺ୑୑ୌ୭୓୳୲ହ୥ୱ୘୭୉୮ୱ୔୰ୣ୮ୗ୳ୡୡሻ
ୌ୭୓୳୲ହ୥ୱ୘୭୉୮ୱ୔୰ୣ୮ୖୣ୯ሻ
.
× 100ሾ%ሿ
MM.HoOutExe5gsToEpsSucc, MM.HoOutExe5gsToEpsReq, MM.HoOut5gsToEpsPrepSucc,

MM.HoOut5gsToEpsPrepReq.
6.7 Energy Efficiency (EE) KPI

6.7.1 NG-RAN data Energy Efficiency (EE)
6.7.1.1 Definition
a) EEMN,DV.
b) A KPI that shows mobile network data energy efficiency in operational NG-RAN. Data Volume (DV) divided
by Energy Consumption (EC) of the considered network elements. The unit of this KPI is bit/J.
c) EEMN,DV
= ∑౏౗ౣ౦ౢ౛౩

. .
∑౏౗ౣ౦ౢ౛౩

.

- for non-split gNBs;
∑ೄೌ೘೛೗೐ೞ

= (
∑ೄೌ೘೛೗೐ೞ

.
)
- for split-gNBs;
d) SubNetwork
e) The Data Volume (in kbits) is obtained by measuring amount of DL/UL PDCP SDU bits of the considered
network elements over the measurement period. For split-gNBs, the Data Volume is calculated per Interface (F1-
U, Xn-U, X2-U). The Energy Consumption (in kWh) is obtained by measuring the PEE.Energy of the
considered network elements over the same period of time. The samples are aggregated at the NG-RAN node
level. The 3GPP management system responsible for the management of the gNB (single or multiple vendor
gNB) shall be able to collect PEE measurements data from all PNFs in the gNB, in the same way as the other
PM measurements.
ETSI
Annex A (informative):
Use cases for end to end KPIs
A.1 Use case for end-to-end latency measurements of

5G network-related KPI
The end-to-end latency is an important performance parameter for operating 5G network. In some scenarios (e.g.
uRLLC), if end-to-end latency is insufficient, the 5G network customer cannot obtain guaranteed network performance
provided by the network operator. So it is necessary to define end-to-end latency of network related measurement to
evaluate whether the end-to-end latency that network customer requested has been satisfied. A procedure is invoked by
network management system and is used:
- to update the CSMF/NSMF with the end-to-end latency parameter for monitoring;
- to inform the network customer/network operator the end-to-end latency;
- to make CSMF/NSMF aware if the end-to-end latency can meet network customer’s service requirement.
If high end-to-end latency are measured, it is also of benefit to pinpoint where in the chain from application to UE that
the latency occurs.
A.2 Use case for number of registered subscribers of

single network-slice related KPI
Number of registered subscribers of single network slice can be used to describe the amount of subscribers that are
successfully registered, it can reflect the usage of network slice , It is useful to evaluate accessibility performance
provided by one single network slice which may trigger the lifecycle management of the network slice, this kind of KPI
is valuable especially when network functions (e.g. AMF) are shared between different network slice . This KPI is
focusing on both network and user view.
A.3 Use case for upstream/downstream throughput for

one-single-network-slice-related KPI
Measuring throughput is useful to evaluate system load of end to end network slice. If the throughput of the specific
network slice cannot meet the performance requirement, some actions need to be performed to the network slice e.g.
reconfiguration, capacity relocation. So it is necessary to define the IP throughput for one single network slice . This
KPI is focusing on network and user view.
A.4 Use case for mean PDU sessions number in network

slice
It is necessary to evaluate the mean PDU session number in the network slice to indicate system load level. For
example, if the mean value of the PDU sessions is high, maybe the system capacity should be increased. This KPI is
focusing on network view.
ETSI
A.5 Use case for virtualised resource utilization of

network-slice-related KPI
It is necessary to evaluate the current utilization of virtualised resources (e.g. memory and storage utilization) that a
network slice is occupied. If the utilization is larger or smaller than the threshold, maybe some scale in/out operations
will be made by the management system. This KPI is focusing on network and user view.
A.6 Use case for 5GS registration success rate of one

single-network-slice-related KPI
It is necessary to evaluate accessibility performance provided by 5GS. 5GS registration for a UE is important when they
have registered to the network slice . If users or subscribers cannot register to the network slice , they cannot access any
network services in the network slice . This KPI is focusing on network view.
A.7 Use case for RAN UE throughput-related KPI

The UE perceived throughput in NG-RAN is an important performance parameter for operating 5G network. If the UE
throughput of the NR cell cannot meet the performance requirement, some actions need to be performed to the network,
e.g. reconfiguration or capacity increase. So it is necessary to define UE throughput KPI to evaluate whether the end-
users are satisfied. The KPI covers volume large enough to make the throughput measurement relevant, i.e. excluding
data volume of the last or only slot.
The UE throughput KPI covers also "NR option 3" scenarios. Then the gNB is "connected" towards the EPC, and not
towards 5GC.
It is proposed to allow the KPI separated based on mapped 5QI (or for QCI in case of NR option 3).
When network slicing is supported by the NG-RAN, multiple network slices may be supported. The UL and DL UE
throughput for each network slice is then of importance to the operator to pinpoint a specific performance problem.
A.8 Use case for QoS flow retainability-related KPI

QoS flow is the key and limited resource for 5GS to deliver services. The release of the QoS flow needs to be
monitored. QoS flow retainability is a key performance indicator of how often an end-user abnormally losing a QoS
flow during the time the QoS flow is used. This key performance indicator is of great importance to estimate the end
users’ experiences.
A.9 Use case for DRB accessibility-related KPI

In providing services to end-users, the first step is to get access to the service. First after access to the service has been
performed, the service can be used.
The service provided by NG-RAN is the DRB. For the DRB to be successfully setup it is also necessary to setup an
RRC connection and an NG signalling connection.
If an end user cannot access a service, it is hard to charge for the service. Also, if it happens often that an end-user
cannot access the provided service, the end-user might change wireless subscription provider, i.e. loss of income for the
network operator. Hence, to have a good accessibility of the services is important from a business point of view.
A DRB accessibility KPI requires the following 3 measurements:
- RRC connection setup success rate.
- NG signalling connection setup success rate.
ETSI
- DRB setup success rate.
The success rate for RRC connection setup and for NG signalling connection setup shall exclude setups with
establishment cause mo-Signalling, since these phases/procedures occur when there is no request to setup a DRB.
This KPI is available per mapped 5QI and per S-NSSAI, and it assists the network operator with information about the
accessibility provided to their 5G network customers.
A.10 Use case for mobility KPIs

When a service is used it is important that it is not interrupted or aborted. One of the fault cases in a radio system for
this is handovers/mobility.
If a mobility KPI is not considered OK, then the network operator can investigate which steps that are required to
improve the mobility towards their services.
These KPIs can be used for observing the impact on end-users of mobility in NG-RAN and towards other system.
A.11 Use case for DRB retainability related KPI

DRB is the key and limited resource for 5GS to deliver services. Once a QoS flow reaches a gNB it will trigger setup of
a new DRB or it will be mapped to an existing DRB. The decision on how to map QoS flows into new or existing DRBs
is taken at the CU-CP. CU-CP also defines one set of QoS parameters (one 5QI) for the DRB. If a QoS flow is mapped
to an existing DRB, the packets belonging to that QoS flow are not treated with the 5QI of the QoS flow, but they are
treated with the mapped 5QI of the DRB.
The release of the DRB needs to be monitored, so that abnormal releases while the UE is considered in an active
transfer shall be logged. DRB retainability is a key performance indicator of how often an end-user abnormally loses a
DRB during the time the DRB is actively used. This key performance indicator is of great important to estimate the end
users’ experiences. DRBs with bursty flow are considered active if any data (UL or DL) has been transferred during the
last 100 ms. DRBs with continuous flow are always seen as active DRBs in the context of this measurement. A
particular DRB is defined to be of type continuous flow if the mapped 5QI is any of {1, 2, 65, 66}.
The key performance indicator shall monitor the DRB retainability for each used mapped 5QI value, as well as for the
used S-NSSAI(s). DRBs used in 3GPP option 3 shall not be covered by this KPI. For the case when a DRB have
multiple QoS flows mapped and active, when a QoS flow is released it will not be counted as a DRB release (DRB still
active) in this KPI.
A.12 Use case for PDU session establishment success

rate of one network slice (S-NSSAI) related KPI
It is necessary to evaluate accessibility performance provided by 5GS. PDU session Establishment for a UE is important
when it has registered to the network slice. If users or subscribers cannot establish PDU sessions in slice instance, they
cannot access any network services in the network slice. This KPI is focusing on network view.
A.13 Use case for integrated downlink latency in RAN

Following figure captured in clause 4.2.3, 3GPP TS 23.501[x] illustrates the 5G system architecture. The end to end
downlink latency should be measured from Data Network to UE, of which the latency from RAN to UE is an important
part for the latency of this section is closely related to NG-RAN.
ETSI
NSSF NEF NRF PCF UDM AF
Nnssf Nnef Nnrf Npcf Nudm Naf
Nausf Namf Nsmf

AUSF AMF SMF SCP
N2 N4
UE (R)AN N3 UPF N6 DN
N9
The integrated downlink latency in RAN is a key performance parameter for evaluating the packet delay in RAN for
QoS monitoring. This KPI is also an important part of the end-to-end network latency for SLA assurance.
A.14 Use case for PDU session Establishment success

rate of one single-network-slice instance-related KPI
It is necessary to evaluate PDU session establishment time, it can be used to analyse the network service difference
between different RAN locations in one area, which can be used for management area division. This KPI is focusing on
network view.
A.15 Use case for QoS flow retainability-related KPI

QoS Flow is the key and limited resource for 5GS to deliver services. The release of the QoS flow needs to be
monitored. QoS Flow drop ratio is a key performance indicator of how often an end-user is abnormally losing a bearer.
This key performance indicator is of great importance to estimate the end users’ experiences.
The KPI shall be available per QoS group.
From QoS perspective it is important to focus also on call duration as in some cases wrong quality perceived by the end
user is not fully reflected by drop ratio nor retainability KPI. Typical case is when due to poor radio conditions the end
user redials (the call was terminated normally) to the same party to secure the quality. But in this case the drop ratio KPI
will not show any degradation. Secondly, although the call is dropped the end user may or may not redial depending on
dropped call duration compared to the case when the call would be normally released. It is therefore highly
recommended to monitor distribution of duration of normally and abnormally released calls.
A.16 Use case for 5G Energy Efficiency (EE) KPI

Assessment of Energy Efficiency in network is very important for operators willing to control their OPEX and, in
particular, their network energy OPEX.
Mobile Network data Energy Efficiency (EEMN,DV) is the ratio between the performance indicator (DVMN) and the
energy consumption (ECMN) when assessed during the same time frame, see ETSI ES 203 228 [8] clause 3.1 and clause
5.3.
‫ܸܦ‬
‫ܧܧ‬ , !" = ‫ܥܧ‬

where EEMN,DV is expressed in bit/J.
Assessment of EEMN,DV needs the collection of both Data Volumes (DV) and Energy Consumption (EC) of 5G Network
Functions (NF). How this EE KPI can be applied to NG-RAN is specified in clause 4.1 of TS 28.310 [9].
ETSI
Before the network operator takes any action to save network energy OPEX, the network operator needs to know the
energy efficiency of its 5G network.
This KPI needs to be used for observing the impact of NG-RAN on data energy efficiency of 5G access networks.
ETSI
Annex B (informative):
Change history
Change history
Date Meeting TDoc CR Rev Cat Subject/Comment New
version
2018-09 SA#81 Upgrade to change control version 15.0.0
2018-09 SA#81 EditHelp fix 15.0.1
2018-12 SA#82 SP-181041 0001 - F Align title with TS database 15.1.0
2019-03 SA#83 SP-190122 0005 2 F Update KPI subscribers of single network slice instance through 15.2.0
UDM
2019-03 SA#83 SP-190122 0011 2 F Update definition of mean number of PDU sessions KPI 15.2.0
2019-03 SA#83 SP-190111 0007 1 B Add KPI of QoS flow Retainability 16.0.0
2019-03 SA#83 SP-190111 0009 1 B Add DRB Accessibility KPI and Use Case 16.0.0
2019-06 SA#84 SP-190371 0013 - B Add KPI for NG-RAN Handover Success Rate 16.1.0
2019-06 SA#84 SP-190375 0015 1 A Correction of Throughput KPI 16.1.0
2019-09 SA#85 SP-190747 0016 2 B Add KPI for DRB Retainability 16.2.0
2019-09 SA#85 SP-190747 0017 3 B Add a new KPI definition of PDU session Establishment Success 16.2.0
Rate of one network slice (S-NSSAI)
2019-09 SA#85 SP-190751 0020 - A Correction on kbits abbreviation 16.2.0
2019-09 SA#85 SP-190747 0021 1 F Correction of Flow Retainability KPI 16.2.0
2019-09 SA#85 SP-190747 0022 1 F Correction of DRB Accessibility KPI 16.2.0
2019-09 SA#85 SP-190748 0024 2 A Correct the title of KPI 16.2.0
2019-09 SA#85 SP-190747 0025 1 B Add definition of integrated downlink latency in RAN 16.2.0
2019-09 SA#85 SP-190747 0028 2 B Add a new KPI definition of Inter-gNB handover Execution time of 16.2.0
one single network slice
2019-09 SA#85 SP-190747 0029 2 B Add a new KPI definition of PDU session Establishment Time of 16.2.0
one single network slice
2019-09 SA#85 SP-190747 0030 2 B Add new specification requirement related to extended 5QI 1 QoS 16.2.0
Flow Retainability monitoring
2019-12 SA#86 SP-191165 0032 1 B Add 5G Energy Efficiency KPI 16.3.0
2019-12 SA#86 SP-191149 0033 1 B Add a new KPI definition of Mean number of successful periodic 16.3.0
registration updates of Single Network Slice
2019-12 SA#86 SP-191149 0034 1 B Add a new description of KPI that related to successful rate of 16.3.0
mobility registration updates of Single Network Slice
2019-12 SA#86 SP-191150 0036 1 F Update the template of KPI definition for TS 28.554 16.3.0
2020-03 SA#87E SP-200163 0038 1 F Update KPI definitions to align with the new template 16.4.0
2020-03 SA#87E SP-200162 0039 - F Correction of equation color 16.4.0
2020-07 SA#88-e SP-200502 0044 1 F Correction of Downlink latency in gNB-DU KPI 16.5.0
2020-07 SA#88-e SP-200502 0045 - F Removal of the KPI named KPI categories 16.5.0
2020-07 SA#88-e SP-200502 0046 - F Update of KPI template 16.5.0
2020-07 SA#88-e SP-200503 0049 1 B Add KPI on e2e UL delay for network slice 16.5.0
2020-07 SA#88-e SP-200503 0050 1 B Add KPI on e2e DL delay for network slice 16.5.0
2020-07 SA#88-e SP-200503 0051 1 B Add KPIs for UL packet delay in NG-RAN 16.5.0
2020-07 SA#88-e SP-200503 0052 1 B Correction of Integrated downlink delay in RAN KPI 16.5.0
2020-07 SA#88-e SP-200485 0053 1 F Cleanup based on refined slice definitions 16.5.0
ETSI
2020-09 SA#89e SP-200751 0054 1 F Fixing KPIs 16.6.0
2020-09 SA#89e SP-200738 0056 - F Correction of RAN UE throughput KPI 16.6.0
2020-12 SA#90e SP-201059 0060 1 A Correct UDM e2e KPI 16.7.0
2020-12 SA#90e SP-201061 0065 - F Editorial Correction of TS 28.554 16.7.0
2020-12 SA#90e SP-201054 0066 - F Correction and alignment of Retainability KPIs definitions 16.7.0
2020-12 SA#90e SP-201054 0067 - F Add missing KPI for inter system Handover success rate 16.7.0
ETSI
History
Document history
V16.5.0 August 2020 Publication
V16.6.0 November 2020 Publication
V16.7.0 January 2021 Publication
ETSI

Ts 128554v160700p

Uploaded by

Copyright:

Available Formats

Ts 128554v160700p

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

Ts 128554v160700p

Uploaded by

Copyright:

Available Formats

ETSI TS 128 554 V16.7.

650 Route des Lucioles

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C

The present document can be downloaded from:

Intellectual Property Rights

Modal verbs terminology

6.3.6 RAN UE Throughput .................................................................................................................................. 20

Annex A (informative): Use cases for end to end KPIs .......................................................................29

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

- For a specific reference, subsequent revisions do not apply.

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[3] ITU-T Recommendation E.800: "Definitions of terms related to quality of service".

[6] 3GPP TS 28.552: "Management and orchestration; 5G performance measurements".

[9] 3GPP TS 28.310: "Management and orchestration; Energy efficiency of 5G".

3 Definitions and abbreviations

4 End to end KPI concept and overview

- Accessibility (see the definition in [3]).

- Integrity (see the definition in [3]).

- Retainability (see the definition in [3]).

5 KPI definitions template

c) Formula definition (Optional):

d) KPI Object (Mandatory):

6 End to end KPI definitions

6.1 KPI Overview

6.2 Accessibility KPI

6.2.2 Registered subscribers of network through UDM

6.2.3 Registration success rate of one single network slice

6.2.4 DRB Accessibility for UE services

c) DRBAccessibility 5QI = (∑RRC.ConnEstabSucc.Cause/∑RRC.ConnEstabAtt.Cause) *

DRB Accessibility SNSSAI = (∑RRC.ConnEstabSucc.Cause/∑RRC.ConnEstabAtt.Cause) *

6.3 Integrity KPI

6.3.1.1 Downlink latency in gNB-DU

or optionally DLLat_gNB-DU.SNSSAI = DRB.RlcSduLatencyDl.SNSSAI where SNSSAI identifies the S-NSSAI.

6.3.1.2 Integrated downlink delay in RAN

6.3.1.2.1 Downlink delay in NG-RAN for a sub-network

DLDelay_NR_SNw = DLDelay_gNBCUUP_SNw + DLDelay_gNBDU_SNw

or optionally DLDelay_ NR_SNw.QOS = DLDelay_gNBCUUP_SNw.QOS + DLDelay_gNBDU_SNw.QOS

or optionally DLDelay_NR_SNw.SNSSAI = DLDelay_gNBCUUP_SNw.SNSSAI +

6.3.1.2.2 Downlink delay in NG-RAN for a network slice subnet

DLDelay_NR_Nss.SNSSAI = DLDelay_gNBCUUP_Nss.SNSSAI + DLDelay_gNBDU_Nss.SNSSAI where

6.3.1.3 Downlink delay in gNB-DU

6.3.1.3.1 Downlink delay in gNB-DU for a NRCellDU

c) Below is the equation for average DL delay in gNB-DU for a NRCellDU:

DLDelay_gNBDU_Cell = DRB.RlcSduDelayDl + DRB.AirIfDelayDl.

and optionally: DLDelay_gNBDU.QOS = DRB.RlcSduDelayDl.QOS + DRB.AirIfDelayDl.QOS where QOS

and optionally: DLDelay_gNB.SNSSAI = DRB.RlcSduDelayDl.SNSSAI + DRB.AirIfDelayDl.SNSSAI where

6.3.1.3.2 Downlink delay in gNB-DU for a sub-network

- W is the measurement for the weighted average, one of the following:

- the DL data volume of the NR cell;

- the number of UL user data packets of the NR cell;

- any other types of weight defined by the consumer of KPI

- the #NRCellDU is the number of NRCellDU’s in the SubNetwork.

6.3.1.3.3 Downlink delay in gNB-DU for a network slice subnet

- W is the measurement for the weighted average, one of the following:

- the DL data volume of the NR cell;

# $ $

# $ $

# $ $