5G Radio Optimization engineering guideline
☒Regulated
☐Unregulated
document
document
Version
2.0
Date
January 28, 2020
Author
Poul Larsen
Owner
Poul Larsen
Organization
Global Services / NCS
Approver
Document ID
ULITPALIL5R3-1390467857-6948
Document location
https://nokia.sharepoint.com/sites/NPO/Docs/NP%26P%20Technical%20Doc
umentation/Forms/AllItems.aspx?id=%2Fsites%2FNPO%2FDocs%2FNP%26P
%20Technical%20Documentation%2FRadio%20and%20Backhaul%2F5G%20R
adio%2F5G%20miscellaneous%20material
Change History
Version
Status
Date
Author
Owner
Reviewed by
Reviewed
date
Approver
Approval
date
Description of changes
0.01
Initial
skeleton
6-Sep-2019
Poul Larsen
Poul Larsen
-
-
-
-
First skeleton
1.0
First release 31-Oct-2019
Poul Larsen
Poul Larsen
Chris Johnson
18-Nov-2019 Juha Sarkioja
25-Nov-2019 Many changes
Kyeongtaek Kim
2.0
Approved
28-jan-2020
Poul Larsen
Poul Larsen
28-Jan-2020 ULITPALIL5R3-1390467857-6948
1 / 178
Updated to 5G19A. Numerous changes and
enhancements in existing sections
Internal
© 2020 Nokia
Contents
1
Introduction and scope ..................................................................................................................... 6
1.1
Scope..................................................................................................................................................... 6
1.2
High level description of the steps in the optimization service................................................. 7
1.3
Structure of this guideline ................................................................................................................. 7
2
Background knowledge for optimizing a 5G radio network ..................................................... 10
2.1
Network architecture.......................................................................................................................... 10
2.2
RAN sharing ......................................................................................................................................... 11
2.3
Interworking with LTE......................................................................................................................... 11
2.4
Available radio units ........................................................................................................................... 12
2.5
Feature descriptions ........................................................................................................................... 14
2.6
Various improvements and restrictions in 5G19A ........................................................................ 17
2.7
Parameter description and recommendations ............................................................................. 17
2.8
Current software status...................................................................................................................... 18
2.9
Performance monitoring ................................................................................................................... 19
2.10
Project experiences ............................................................................................................................ 21
2.11
Network design material ................................................................................................................... 21
2.12
Pre-launch optimization material .................................................................................................... 21
2.13
Achievable KPI values......................................................................................................................... 21
3
Prerequisite checks before starting optimization ......................................................................... 23
3.1
Understand the operator’s view of good 5G performance ....................................................... 23
3.2
Understand the limitations imposed by non-RAN factors ......................................................... 23
3.3
EN-DC carrier aggregation strategy ............................................................................................... 24
3.4
Parameter and feature check ........................................................................................................... 25
3.5
Quick initial performance assessment ............................................................................................ 28
3.6
Backhaul capacity................................................................................................................................ 30
3.7
O&M status of the network .............................................................................................................. 30
4
Optimization of RF performance ..................................................................................................... 32
4.1
Introduction.......................................................................................................................................... 32
4.2
Typical issues........................................................................................................................................ 32
28-Jan-2020 ULITPALIL5R3-1390467857-6948
2 / 178
Internal
© 2020 Nokia
4.3
General performance analysis methods ........................................................................................ 33
4.4
General optimization methods ........................................................................................................ 34
4.5
Case: Crossed feeders or sectors .................................................................................................... 35
4.6
Case: Only few EN-DC capable terminals have a 5G radio connection ................................. 36
4.7
Case: Adjust antenna configuration based on 5G beamforming counters ............................ 39
4.8
Case: Use 5G timing advance counters to detect overshooting .............................................. 41
4.9
Case: Using counters to identify areas with bad downlink radio quality................................. 43
4.10
Case: Using counters to identify areas with bad uplink radio quality ...................................... 47
5
Optimization of accessibility ............................................................................................................. 51
5.1
Step A: EN-DC capable UE camps on LTE anchor cell ............................................................... 51
5.2
Step B: LTE RRC connection is established .................................................................................... 53
5.3
Step C: NR PDCP E-RAB and DRB is set up on LTE cell ............................................................. 53
5.4
Step D: Identifying the 5G cell.......................................................................................................... 55
5.5
Step E: SgNB addition ........................................................................................................................ 60
5.6
Step F: RRC reconfiguration ............................................................................................................. 62
5.7
Step G: Switching user plane to gNB.............................................................................................. 63
5.8
Step H: 5G RACH procedure ............................................................................................................ 64
5.9
E2E KPI formulas ................................................................................................................................. 68
6
Optimization of retainability ............................................................................................................. 70
6.1
Release initiated by gNB due to UE 5G inactivity......................................................................... 71
6.2
Release initiated by gNB due to A2 measurement report ......................................................... 72
6.3
Release initiated by gNB due to SgNB-detected 5G radio link failure .................................... 74
6.4
Release initiated by gNB due to UE-detected 5G radio link failure ......................................... 76
6.5
Release initiated by gNB due to abnormal reasons .................................................................... 77
6.6
Release initiated by gNB due to other reasons ............................................................................ 77
6.7
Release initiated by eNB due to normal release .......................................................................... 78
6.8
Release initiated by eNB due to 4G radio link failure.................................................................. 78
6.9
Release initiated by eNB due to 4G handover ............................................................................. 78
6.10
Releases due to gNB / eNB reset .................................................................................................... 79
6.11
Performance indicators...................................................................................................................... 79
28-Jan-2020 ULITPALIL5R3-1390467857-6948
3 / 178
Internal
© 2020 Nokia
7
Optimization of mobility.................................................................................................................... 80
7.1
Moving within the same SSB beam ................................................................................................ 80
7.2
Beam switching ................................................................................................................................... 83
7.3
NSA handover ..................................................................................................................................... 84
8
Capacity management....................................................................................................................... 89
8.1
5G radio interface capacity ............................................................................................................... 89
8.2
5G gNB processing capacity............................................................................................................. 101
8.3
5G Admission Control........................................................................................................................ 101
8.4
LTE radio interface capacity.............................................................................................................. 103
8.5
LTE eNB processing capacity............................................................................................................ 104
8.6
Interface capacity ................................................................................................................................ 104
9
Optimization of throughput ............................................................................................................. 107
9.1
The main factors impacting the throughput ................................................................................. 107
9.2
Performance analysis ......................................................................................................................... 108
9.3
OSS PM counters ................................................................................................................................ 109
9.4
Relevant features ................................................................................................................................ 111
9.5
Frame structure ................................................................................................................................... 126
9.6
Optimization procedure .................................................................................................................... 131
10
Optimization of user plane latency ................................................................................................. 134
10.1
Introduction.......................................................................................................................................... 134
10.2
Typical issues........................................................................................................................................ 135
10.3
Performance analysis ......................................................................................................................... 135
10.4
Dependencies on other sections ..................................................................................................... 138
10.5
Relevant features and parameters .................................................................................................. 139
10.6
UE dependencies ................................................................................................................................ 144
10.7
Optimization procedure .................................................................................................................... 145
11
Optimization of control plane latency ............................................................................................ 148
11.1
Introduction.......................................................................................................................................... 148
11.2
Typical issues........................................................................................................................................ 148
11.3
Performance analysis ......................................................................................................................... 149
28-Jan-2020 ULITPALIL5R3-1390467857-6948
4 / 178
Internal
© 2020 Nokia
11.4
Relevant features and parameters .................................................................................................. 149
12
Impact on legacy LTE performance ................................................................................................ 155
12.1
Impact on LTE performance for non-EN DC capable UEs ......................................................... 155
12.2
Impact on LTE performance for EN-DC capable UEs ................................................................. 155
13
Optimization of specific functionalities........................................................................................... 158
13.1
RACH performance ............................................................................................................................ 158
13.2
5G carrier aggregation ...................................................................................................................... 158
13.3
Ookla Speedtest .................................................................................................................................. 160
13.4
EN-DC downlink throughput issues ................................................................................................ 163
13.5
UE battery life ...................................................................................................................................... 164
13.6
BTS power efficiency .......................................................................................................................... 166
13.7
BTS radiation level .............................................................................................................................. 167
Appendix I
List of 5G RAN features ............................................................................................................ 169
Appendix II
List of LTE EN-DC features ...................................................................................................... 178
28-Jan-2020 ULITPALIL5R3-1390467857-6948
5 / 178
Internal
© 2020 Nokia
1
Introduction and scope
This document is the “engineering guideline” for the 5G Radio Network Optimization service. It covers in
reasonable details the steps which are necessary to optimize the radio part of a Nokia 5G network. The
service description for the radio network optimization services is available here.
As there is still only limited experience from live networks, the discussion of the various optimization areas
is mostly based on theoretical considerations. The document will be kept updated as practical performance
knowledge becomes available.
Since the document is meant to be applicable in all 5G networks, some of the descriptions are rather generic.
The details will vary from network to network, and it is important to have in mind that recommendations for
one type of network cannot be assumed to be valid for another type of network.
Important caveat: There are still numerous implementation issues in the 5G BTS and especially in the 5G
terminals. The performance of some features is unfortunately heavily dependent on the used terminal type
and software and it is recommended to verify that the test results and recommendations in this document
is applicable in the relevant BTS / UE combinations before applying them in the network.
1.1
Scope
The guideline is aligned with the capabilities of the Nokia 4G and 5G BTS. Current version of the guideline
is aligned with the 5G19A release. The full list of LTE19B EN-DC features are listed in Appendix II but only
those LTE19B features which are compatible with 5G19A features are described in this version of the
document.
5G19A means the following capabilities and limitations apply:
•
Non-standalone (NSA) deployment according to 3GPP option 3x. This means that idle mode
behaviour is controlled by the LTE layer and the establishment and maintenance of the RRC
connection is handled by LTE layer.
•
“Split mode” of the user plane is possible, and it can be decided if the user plane traffic should go
via the LTE leg, the 5G leg or both. This decision can be made independently for uplink and downlink
•
5G can be deployed in both FDD and TDD modes
•
In most networks, the 5G will only be deployed on a single frequency band in 5G19A (although
multiple adjacent carriers are possible), and this simplifies the 5G traffic management
•
Analog and digital beamforming are supported. MU-MIMO (multi-user MIMO) is not supported
•
Either Classical BTS or Cloud BTS deployment
•
All voice calls (VoLTE, CSFB) are handled exclusively by the LTE layer
The use of NSA option 3x and the associated dependency on LTE network performance means that some
specific LTE aspects will be covered, namely those related to establishing and maintaining an EN-DC RRC
28-Jan-2020 ULITPALIL5R3-1390467857-6948
6 / 178
Internal
© 2020 Nokia
connection and how to use LTE carrier aggregation to maximize end-user throughput. General LTE
optimization, for example how to maximise the throughput on a LTE carrier by using 4x4 MIMO and
256QAM will not be discussed. The LTE radio optimization Wiki and the LTE optimization guideline can be
consulted with regard to methods to improve LTE throughput.
It is assumed that both the LTE and the 5G BTSs are supplied by Nokia. Although many optimization actions
will be similar for all BTS vendors, the needed features, parameters and network counters will be different if
other vendors are involved.
Only the radio aspects of network optimization will be discussed. The discussion of the “fixed” interfaces
(fronthaul, midhaul (F1) and backhaul (X2, S1) will be limited to their potential impact on end-user latency
and how to do capacity monitoring. Other aspects of planning and optimizing the fixed interfaces is part of
the “Mobile Access design service” – the content of this service can be studied via the delivery kit.
1.2
High level description of the steps in the optimization service
The optimization services will typically consist of the following main activities:
1.
Project setup
2. Initial analysis of configuration and parameters
3. Initial performance analysis
4. Optimizing the basics: RF environment and mobility aspects
5. Optimizing end-user performance. Typically, throughput and latency but perhaps also accessibility
and retainability
Steps 2 and 3 are described in chapter 3 and steps 4 and 5 are described from chapter 4 onwards.
1.3
Structure of this guideline
Chapter 2 contains background information about the Nokia 5G RAN implementation in 5G19A. It lists the
available radio units and the most relevant features to be familiar with before starting a 5G RAN optimization
project. There are also links to recommended parameter values, descriptions on how to do performance
monitoring and links to the material related to the Network Design and Pre-launch optimization services.
Chapter 3 describes the steps needed in the initial network assessment which should be done before the
real optimization starts. This includes parameter consistency checks, quick initial check of the major KPIs as
well as checking that the sites are generally on air without alarms. The intention is partly to clear away any
obvious problems (such as inconsistent parameter settings) before the real work starts, partly to provide
initial guidance on where the performance problems of the network are.
The following chapters then provide details on how to optimize specific aspects of 5G performance. In
practice, these aspects are very much interrelated. For example, high user throughput can be achieved by
28-Jan-2020 ULITPALIL5R3-1390467857-6948
7 / 178
Internal
© 2020 Nokia
using relevant features with recommended parameter values (described in the chapter on throughput
optimization) in an area with good coverage and low interference (described in the RF performance chapter)
and where the network is not congested (described in the capacity management chapter) while making
sure that the connections are using the optimal BTS (described in the mobility optimization chapter). For
descriptive purposes, different aspects are described in their own chapters, but it should be kept in mind
that (almost) everything is depending on everything else. Table 1 provides the overview of the optimization
chapters.
Chapter
Contents
Chapter 4: Optimization
of RF performance
How to ensure that the network foundation, i.e. the basic coverage and
interference situation, is at the optimal level. This section concentrates on
the stationary case. The selection of the optimal beam pattern is also
discussed
Chapter 5: Optimization
of accessibility
What are the 4G and 5G factors which can impact accessibility. Which KPIs
are the most relevant to monitor
Chapter 6: Optimization
of retainability
What are the 4G and 5G factors which can impact retainability. Which KPIs
are the most relevant to monitor
Chapter 7: Optimization
of mobility
Covers the traditional mobility aspects, i.e. changing between cells as well
as the movement inside a cell (beam switching, maintaining good channel
estimate)
Chapter 8: Capacity
management
Describes how to measure current congestion levels and gives suggestions
to how the spectral efficiency and other network resources can be
optimized
Chapter 9: Optimization
of throughput
How to measure throughput in field tests and via KPIs. Which features are
most relevant to optimize and what are the field experiences so far
Chapter 10: Optimization
of user plane latency
How to measure user plane latency in field tests and via interface traces.
KPIs. Which features are most relevant to optimize and what are the field
experiences so far
Chapter 11: Optimization
of control plane latency
How to measure user plane latency in field tests and via interface traces.
KPIs. Which features are most relevant to optimize and what are the field
experiences so far
Chapter 12: Minimizing
impact on legacy LTE
performance
Describes how the 5G EN-DC functionality can potentially impact legacy
LTE services and how the impact can be minimized
Chapter 13: Optimization
of specific functionalities
A collection of specific optimization actions which should be considered
together with the actions described in the main chapters but are more
easily described in their own subsection
Table 1: Overview of the optimization sections
28-Jan-2020 ULITPALIL5R3-1390467857-6948
8 / 178
Internal
© 2020 Nokia
28-Jan-2020 ULITPALIL5R3-1390467857-6948
9 / 178
Internal
© 2020 Nokia
2
Background knowledge for optimizing a 5G
radio network
A certain level of background knowledge is of course needed before starting an optimization project. This
chapter provides some basic background information along with useful links where more details can be
studied.
2.1
Network architecture
The 5G19A release supports the 3GPP “option 3x” deployment, i.e. a LTE cell is used as “anchor cell” where
the RRC connection is first established via the LTE radio link and afterwards a 5G user plane connection is
added on top of the LTE user plane connection. This arrangement is referred to as EUTRAN – NR Dual
Connectivity (EN-DC). In this scenario, the anchor LTE BTS is referred to as the Master eNB (MeNB) while
the 5G BTS is referred to as the Secondary gNB (SgNB). Figure 1 illustrates the network architecture.
The 4G core network (the EPC) continues to be used with minor modifications in the MME and in the SGW.
The LTE cell used as anchor cell needs significant enhanced functionality, so the relevant release and features
must naturally be loaded.
Figure 1: Network architecture in 5G19A RAN release
28-Jan-2020 ULITPALIL5R3-1390467857-6948
10 / 178
Internal
© 2020 Nokia
Optionally, a distributed architecture can be used for the gNB. This means that the gNB is split into a
centralized unit (the CU) and multiple distributed units (DUs) connected via the open F1 interface. The CU
then handles the upper layers of the communication protocol (PDCP and upwards) while the DUs handles
the physical, MAC and RLC layers. In Nokia implementation, this option is called “Cloud BTS” architecture.
Alternatively, the traditional deployment where all the BTS components are located relatively close to the
antennas can be used. This option is called “Classical BTS” in Nokia terminology. 5G19A supports Cloud BTS
deployment only on the 28 GHz and 39 GHz frequency bands.
From a radio network optimization perspective, the main difference between cloud and classical BTS
deployment is that the cloud BTS covers a large geographical area with many cells. This means that the
majority of handover events will be intra-gNB handovers – this was especially important in 5G19 because
this release did not support inter-gNB handover.
2.2
RAN sharing
Starting with 5G19A, it is possible to share the 5G RAN between two operators. The feature 5GC000738:
Multiple PLMN ID support works with classical BTS architecture (but not with Cloud BTS architecture in
5G19A) and allows the use of either MOCN (operators are sharing the spectrum) or MORAN (each operator
has own spectrum).
2.3
Interworking with LTE
The LTE part of the EN-DC procedure plays an important role and cannot be ignored when the 5G radio
network is optimized. Especially the establishment of the connection (accessibility) and the end-user
throughput can be heavily impacted by the LTE performance.
The signalling between the LTE and the 5G BTS takes place via the X2 interface. X2 is an open interface fully
specified by 3GPP, so in principle there is no requirement that the LTE and the 5G BTSs are from the same
vendor. The interworking functionality has been verified in labs but there are not yet any field deployments
where the 5G RAN is not supplied by the same vendor which has provided the anchor LTE layer. This
guideline assumes that there is a single-vendor scenario for 5G RAN and the LTE anchor layer.
Among the aspects which needs to be analysed and optimized are:
•
Ensure that EN-DC capable UEs in idle mode camps on the LTE anchor layer
•
Ensure 5G neighbours are defined for the BTSs in the LTE anchor layer
•
Set parameters such that 5G radio connections are added when there is sufficient 5G radio coverage
and addition attempts are not made when the 5G radio coverage is insufficient
•
Make sure that LTE carrier aggregation works also for UEs with ongoing 5G connection
•
Ensure that the split of user plane data between LTE and 5G radio connections works in the optimal
way
28-Jan-2020 ULITPALIL5R3-1390467857-6948
11 / 178
Internal
© 2020 Nokia
Generally, when performing such an analysis, the parameters, counters and traces needs to be viewed from
both the 4G and the 5G side.
With 5G19A, the “concurrent” operation between LTE and 5G is introduced, i.e. the Radio Unit and the
antenna can be used concurrently for LTE and 5G. This has obvious implications for the site solution but not
really for the radio network optimization, except that the use of the same antenna for LTE and 5G means
that tilt and azimuth adjustments cannot be done independently for LTE and 5G. The big impact on the
radio network optimization comes with the Dynamic Spectrum Sharing feature in 5G19B.
Instead of dedicating a chapter for optimization of the LTE inter-working, the different aspects are discussed
as part of the general performance optimization chapters.
2.4
Available radio units
Figure 2 gives an overview of the available radio units in 5G19A and Table 2 provides more details.
Figure 2: Overview of available radio units
Radio unit
Feature
Frequency band
Antenna type
Comment
AHLOA
5GC000719
600 MHz
4T4R RRH
Concurrent 5G and LTE
AHCA
5GC001152
850 MHz
4T4R RRH
Concurrent 5G and LTE
AHBCC
5GC001150
850 MHz
4T4R RRH
Concurrent 5G and LTE
AHBCB
5GC002028
850 MHz
4T4R RRH
Concurrent 5G and LTE
28-Jan-2020 ULITPALIL5R3-1390467857-6948
12 / 178
Internal
© 2020 Nokia
Radio unit
Feature
Frequency band
Antenna type
Comment
AHFIB
5GC000724
n25 (1900 MHz) &
n66 (1700 MHz)
4T4R RRH
Concurrent 5G and LTE
AAHF
5GC001138
2.496-2.69 GHz
64T64R active antenna
Concurrent 5G and LTE
AAHJ
5GC001210
2.59-2.69 GHz
64T64R active antenna
Concurrent 5G and LTE
AWHHA
5GC001776
2.496–2.690 GHz
4T4R indoor antenna
Small cell, 4 x 250 mW
AWHHC
5GC001649
2.496–2.690 GHz
4T4R indoor antenna
Small cell, 4 x 200 mW
AWHHD
5GC001541
2.515–2.675 GHz
4T4R RRH
Small cell
AWHHF
5GC001707
2.496–2.690 GHz
4T4R RRH
Small cell
AWHHG
5GC001776
2.515–2.675 GHz
2T2R RRH
Small cell
AEQA
5GC000562
3.4 – 3.6 GHz
64T64R active antenna
AEQD
5GC000664
3.6 – 3.8 GHz
64T64R active antenna
AEQB
5GC001783
3.4 – 3.6 GHz
64T64R active antenna
AEQE
5GC002446
3.48 – 3.8 GHz
64T64R active antenna
AEQP
5GC002449
3.41 – 3.7 GHz
64T64R active antenna
AEQN
5GC001822
3.4 – 3.7 GHz
32T32R active antenna
AZQG
5GC001795
3.4 – 3.6 GHz
8T8R RRH
AZQH
5GC001810
3.6 – 3.8 GHz
8T8R RRH
AZQL
5GC001811
3.48 – 3.7 GHz
8T8R RRH
AWHQA
5GC000997
3.4 – 3.6 GHz
4T4R indoor antenna
Small cell
AWHQB
5GC001072
3.6 – 3.8 GHz
4T4R indoor antenna
Small cell
AWHQC
5GC001073
3.3 – 3.6 GHz
4T4R indoor antenna
Small cell
AWHQJ
5GC001648
3.4 – 3.6 GHz
4T4R indoor antenna
Small cell
AWHQE
5GC001157
3.4 – 3.6 GHz
4T4R RRH
Small cell
AWHQF
5GC001274
3.6 – 3.8 GHz
4T4R RRH
Small cell
AWHQG
5GC001278
3.46 – 3.58 GHz
4T4R RRH
Small cell
AHQK
5GC002029
3.4 – 3.7 GHz
DL: 4x4. UL: 2x2 passive
antennas
Repeater
AEUA
5GC000515
28 GHz
2T2R active antenna
AC power
AEUF
5GC001269
28 GHz
2T2R active antenna
DC power
AEUB
5GC000585
28 GHz
2T2R active antenna
AEUD
5GC000855
28 GHz
2T2R active antenna
AEUE
5GC000958
28 GHz
2T2R active antenna
AEWF
5GC001267
39 GHz
2T2R active antenna
AEWB
5GC000586
39 GHz
2T2R active antenna
28-Jan-2020 ULITPALIL5R3-1390467857-6948
13 / 178
Internal
© 2020 Nokia
Radio unit
Feature
Frequency band
Antenna type
AEWD
5GC000856
39 GHz
2T2R active antenna
AEWE
5GC000959
39 GHz
2T2R active antenna
Comment
Table 2: Available radio units. 5G19A RUs in italic. More details are available in the feature descriptions
The 5G active antennas are much more integrated in the overall behaviour of the 5G RAN than what has
been the case for 4G passive antennas, and this means that similar products may have different
performance. For example, a given maintenance package may already give good performance for AEQA,
but a later package is needed to also have good performance for AEQN. This means that parameter
recommendations and measured performance is much more dependent on the used radio unit than what
has been the case for earlier technologies.
The available radio units in future releases are for example available in the 5G RAN roadmap or in the Focal
Point.
2.5
Feature descriptions
There are about 170 new features in 5G19A and about 180 features are inherited from earlier releases. Many
of these are mandatory in the sense that the 5G RAN will not work without them, for example 5GC000836:
SgNB addition and release for NSA option 3X. Other features can be considered as enhancements to the
basic 5G operation, for example 5GC000522: 256 QAM for PDSCH.
The complete list of features available in 5G19A and earlier releases can be found in Appendix I. More
detailed feature descriptions can be found in:
•
Focal Point. This is high level description which also mentions the expected 5G release which the
feature will appear in (this is of course most relevant for future features)
•
Network Engineering trainings. These consist of recorded sessions (which may be outdated since
the feature contents have been changing) and reasonably updated slide decks. From WebNEI,
specific features can be searched
•
DOORS or Gates. This is where the CFAM descriptions are stored
•
Discovery Center. This is the customer documentation
The most relevant features for 5G19A radio optimization are listed in Table 3 and Table 4. The selection
criterium has been that these features are either “enhancement features”, which are not necessarily enabled
in the network or mandatory features where good understanding of the feature algorithms and parameters
is needed.
For some features, it has been decided that instead of implementing the whole feature in the planned
release, some content is moved into the next release. This means that so-called “spillover” features exist, for
example 5GC002090: Spillover from 5GC000578 Direct RRC signaling for NSA (SRB3), where part of the
functionality which was originally intended to be in 5G19A, has been moved to 5G19B. It can sometimes be
28-Jan-2020 ULITPALIL5R3-1390467857-6948
14 / 178
Internal
© 2020 Nokia
difficult to find out exactly what is included in a given 5G19 /5G19A feature – the most updated webNEI
material is probably the best source.
Not all the new 5G19A features are fully implemented in the initial release of 5G19A. Some will only be
completed with the various maintenance packages (MP releases). The release documentation for each of
the 5G19A packages should be studied to understand the status.
Feature id
5GC000475
5GC000478
5GC000479
5GC000480
5GC000510
5GC000511
5GC000512
5GC000517
5GC000522
5GC000523
5GC000526
5GC000527
5GC000531
5GC000532
5GC000533
5GC000535
5GC000570
5GC000572
5GC000605
5GC000720
5GC000762
5GC000772
5GC001070
5GC001094
5GC001116
5GC001127
5GC001208
5GC001304
5GC001725
Feature name
SgNB Addition and Release for NSA mode 3x operation
Radio Link Failure handling for NSA mode 3x operation
UE inactivity handling for NSA mode 3x operation
Radio Admission Control for NSA mode 3x operation
Uplink open loop power control
PRACH control
DL power control
Uplink and Downlink link adaptation
256 QAM for PDSCH
TDD scheduler for Multi-UE support
DL Interference Generation - single cell
Intra-band CA TDD FR2 up to 2 CCs
DL SU adaptive MIMO (2x2)
UL SU adaptive MIMO (2x2)
Digital Beamforming for CPRI based RUs
Analog Beamforming
5G - LTE flow control at X2
Intra-Frequency Inter-DU en-gNB mobility (NSA option 3x, Cloud gNB)
DL SU adaptive 4x4 MIMO (open loop)
Asymmetric carrier aggregation
5G centralized SON PCI management
Common DRX
Bi-periodic 5 slot subframe configuration
Intra-Frequency Intra-DU en-gNB mobility (NSA option 3x)
TD-LTE co-existence subframe configuration
FR2 frame structure 4-1
FR1 frame configuration 4-1
Frame structure enhancement (preamble format B4)
Intra-band CA TDD FR2 up to 4CCs DL
Table 3: Most relevant 5G18A and 5G19 features to study before 5G radio network optimization
Feature id
5GC000573
5GC000575
5GC000578
5GC000726
Feature name
Intra-Frequency Inter en-gNB mobility (NSA option 3x)
Intra-MeNB LTE handover without en-gNB change (NSA Option 3x)
Direct RRC signaling for NSA mode 3x operation
NR-LTE FDD concurrent operation for CPRI RUs
28-Jan-2020 ULITPALIL5R3-1390467857-6948
15 / 178
Internal
© 2020 Nokia
Feature id
5GC000738
5GC000776
5GC000792
5GC000795
5GC000913
5GC000918
5GC000920
5GC000980
5GC001197
5GC001200
5GC001246
5GC001329
5GC001347
5GC001461
5GC001547
5GC001612
5GC001829
5GC001831
5GC001836
5GC001854
5GC001870
5GC001874
5GC001878
5GC001942
5GC001943
5GC001954
5GC001982
5GC001983
5GC002388
5GC002450
5GC002535
Feature name
Multiple PLMN ID support
non GBR service differentiation
FDD Scheduler for Multi-UE support
Multiple DRBs per UE (NSA mode 3x)
QoS Support for Terminated Traffic
Analog Beamforming for eCPRI based RUs
DL 4x4 SU MIMO without beamforming (open loop)
ALD support in gNB for Nokia CPRI radio units
Micro discontinuous Trans. and Recept. (µDTRX) for Energy Efficiency
Dynamic uplink data split mode
AirScale Indoor Radio LTE and NR concurrent operation
EIRP monitor
Additional DMRS configuration
Golden Database (DB) verification
Supplemental downlink cell - FR2
EdenNet support of 5G19A
Spillover from 5GC001094 (intra-DU PSCell change)
Intra-band CA TDD FR2 up to 4CCs DL - 2CCs UL
Spillover from 5GC000480 Radio Admission Control for NSA mode 3x operation
Spillover for basic TDD scheduler for multi-UE support
DL SU adaptive 4x4 MIMO
Non contention based random access
DL Interference Generation - multiple cells
Spillover digital Beamforming for CPRI based RUs
Spillover analog beamforming
Introduction of A2 based SgNB release
L1 algorithm changes - 5G19A
Spillover UL SU adaptive MIMO
Sleeping cell 1, RACH detection
Antenna tilt for 2D GoB (Com. Introduction)
FDM of DMRS and PDSCH
Table 4: Most relevant 5G19A features to study before 5G radio network optimization
Table 5 lists the most relevant EN-DC features on the LTE side.
Feature id
LTE4088
LTE4193
LTE4575
LTE4530
LTE4531
LTE5335
LTE5524
LTE4281
LTE4549
Feature name
LTE-NR Dual Connectivity Option 3X
Dynamic Trigger for LTE-NR DC Option 3X
Blind Carrier Aggregation with LTE-NR DC Option 3X
Inter-SgNB Mobility for LTE-NR DC Option 3X
LTE-NR DC Option 3X: Multiple non-GBR SCG split Bearers
LTE-NR DC Option 3X Enhancements
Ongoing QCI1 prevents EN-DC setup
Intra-eNB handover for LTE-NR DC Option 3X
Flexible LTE CA with EN-DC
28-Jan-2020 ULITPALIL5R3-1390467857-6948
16 / 178
Internal
Release
LTE19
LTE19
LTE19
LTE19A
LTE19A
LTE19A
LTE19A
LTE19B
LTE19B
© 2020 Nokia
Feature id
LTE5150
LTE5510
Feature name
EN-DC capability-based mobility trigger
Stepwise addition of multiple bearers for EN-DC
Release
LTE19B
LTE19B
Table 5: Most relevant LTE EN-DC features. Only those features which are supported also with 5G19A are listed. The full EN-DC
feature list is provided in Appendix II
2.6
Various improvements and restrictions in 5G19A
Some of the improvements which 5G19A brings compared to 5G19 is quite obvious when studying the list
of 5G19A features but others are less obvious, often “hidden” inside feature descriptions or improvement
suggestions. This section attempts to list such “hidden” improvements which are known to the author, as
well as some of the less obvious restrictions in 5G19A
5G19A improvements compared to 5G19:
•
Incremental Redundancy HARQ is taken into use in both uplink and downlink. This means better
and more stable throughput
•
If a small packet is transmitted in uplink, the scheduler can first reduce the MCS down to MCS0 and
then reduce the PRB size down to 3 PRBs. This gives better uplink performance at cell edge
•
If a small packet is transmitted in downlink, the scheduler can reduce to MCS down to MCS0 and
the transmit power can be reduced (to reduce inter-sector interference). DL power reduction is
enabled by default starting from 5G19A_6.28451.297
Restrictions in 5G19A:
•
In case of small downlink packets, the scheduler cannot reduce the number of PRBs
•
4x4 MIMO cannot use closed loop
•
Only 1 UE per slot (FDM multiplexing not available)
•
Scheduling of PDSCH on SSB and CSI-RS not possible
2.7
Parameter description and recommendations
For the “system level” parameters, “golden” parameter sets are available for the various radio units and the
various releases. These can be used as a guideline for the network design but should be used with care due
to different networks having different requirements.
More information can be found in:
•
NPO radio wiki, parameter page. Contains a collection of useful links, incl. the material listed below
•
NIDD. The parameter definitions (parameter names, object, range, default values, descriptions) can
be exported to convenient Excel format
28-Jan-2020 ULITPALIL5R3-1390467857-6948
17 / 178
Internal
© 2020 Nokia
•
MN R&D golden SCF. Excel sheet with info on which parameters which are recommended to be set
different than default values, as well as SCF files
•
Network Engineering’s SCF collection. Collection of SCF files from various networks and test labs
•
NPO’s SCF collection. SCF files from various European 5G projects can be found within the project
specific folders
•
NPO parameter recommendation. Includes the full list of parameters and recommendations on how
the parameters should be set (default values, output from 9955 planning tool, output from IP design,
etc.)
•
MIND parameter database. Maintained by Network Engineering. In addition to the information
available from NIDD, this also has very useful “comments” field, which can be used for asking
questions about a specific parameter in the Yammer ASK community
•
Optimization guideline from GS CS QoE team. Contains an overview of the parameters playing a
key role for the most important performance aspects (accessibility, retainability, usage etc.). Contains
recommended values for different use cases: General, Demo Peak Throughput, Demo Low Latency,
High Traffic, etc. The document is continuously fed by Trials/NPI/NPO team’s feedbacks.
In addition to the normal parameters in the SCF file which are visible and modifiable to the operator, there
are also “hidden” parameters which are stored in the encrypted “Vendor” file and which can only be
inspected and changed by R&D. These parameters are included in the NIDD parameter list and may later
become visible and included in the SCF file.
Also, it is relevant to check the R&D parameters, which are included in the swconfig.txt file. These are mainly
flags for enabling or disabling certain functionalities in early feature implementations. These are not part of
NIDD and will disappear once a given feature has been fully implemented and tested.
2.8
Current software status
It is often worthwhile to read quickly through the release notes related to the specific maintenance package
which is running in the 4G and in the 5G BTSs. Also, the “List of Generic Failures” (LGF) is recommended to
study. This document lists the known failures, describes possible workarounds and informs in which
maintenance release the problem is fixed.
These documents are available in the Discovery Center:
•
Overview of all releases (incl. 5G) with links to additional documentation for each release
•
5G19A P8 release documents
•
List of Generic Failures (as of January 23, 2020)
•
List of Technical Support Notes
28-Jan-2020 ULITPALIL5R3-1390467857-6948
18 / 178
Internal
© 2020 Nokia
2.9
Performance monitoring
Network performance is normally measured either by doing field tests or by analysing OSS counters. Each
method has its own advantages and disadvantages as summarized in Table 6, and consequently both
methods are often used.
Field tests
OSS counters
The end-user experience is directly measured
Difficult to combine counters to match end-user
experience
Tests are only done at certain locations during
certain times
Covers all the users all the time
Performance in very specific locations can be
measured
Performance is typically averaged over a cell
The performance of a specific UE is measured
Average performance of all UEs
Can be done even before network is launched
Certain traffic level required to have statistical
validity
Table 6: Advantages and disadvantages of field tests and OSS counter analysis
When analyzing the measurements, it is important to be aware of the “reproducibility” of the results. This is
straightforward for OSS counters because it is easy to confirm if the results are similar from day to day. For
drive tests, this can be achieved by doing multiple drives of a smaller area (without changing anything in
the network) and confirm if the results from drive to drive are reasonably similar.
It can be a challenge to obtain good reproducibility of stationary field tests. Often, a series of locations are
measured with one parameter set, then the parameters are changed, and the same locations are measured
again. If a location has medium or bad radio link quality, it can be very difficult to return to that location
and achieve same link quality as in the previous test. Often, the change in SINR will outweigh the impact
from the parameter change. It can be easier to test in locations with good radio link quality, because then
the radio link quality just needs to be “good enough”, and a few dBs difference in the link quality doesn’t
matter. However, with the 4x4 MIMO feature, it has become difficult to reproduce results even in good
radio conditions due to the need to not only have a good radio link quality - a good multipath environment
is also needed.
A common problem with drive tests is that many factors (network congestion, road congestion, timing of
traffic lights etc.) can have impact on the results, and if the expected gain of a certain parameter adjustment
is small, it can “disappear in the noise” and lead to wrong conclusions. One solution can be that instead of
driving a standard cluster once, a more focused drive, for example driving between 2 BTSs on a specific
road, can be done many times; this can sometimes give a clearer conclusion on the effect of the change.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
19 / 178
Internal
© 2020 Nokia
2.9.1
Drive test tools
Especially in the early phases of 5G networks where the traffic is very low and the features are not necessarily
working as expected, performing field tests will be an important of optimization activities. Also, Nokia’s first
5G releases have limited functionality for mass tracing, so RF optimization will rely on field tests even in
networks with reasonable traffic levels.
It is recommended to do the first tests with UDP based applications to be able to make a separate clean
measurement of the downlink and of the uplink performance. Once the basic link optimization has been
done, TCP based applications (such as Ookla Speedtest) should be used such that the end-user experience
is characterized (good TCP performance requires both good downlink and good uplink performance in
terms of throughput and latency).
Most commonly used drive test tools are Accuver XCAL, Keysight Nemo and InfoVista TEMS. More
information about these tools are available on the Mass Rollout Tools website.
2.9.2
BTS traces and logs
BTS traces and log files are used not only by Product Line to troubleshoot software bugs but also by NPO
engineers to understand in detail what is happening in certain test scenarios. Until now, these trace
possibilities have been used to analyse specific scenarios where there typically is only one UE active in a
short time. These traces include various system logs but also more familiar traces such as MACTTI and
SHERPA traces.
Some information about the various trace possibilities are available in this slide deck which unfortunately
has not been updated for some time.
For mass traffic analysis, the recommended option is to use Per Call Measurement Data (PCMD) traces.
Basic information was already available in 5G19 and more has been added in 5G19A. There is not yet much
practical experience with using these traces.
In future releases, also MDT traces will be available.
2.9.3
Counters and KPIs
Numerous counters and KPIs are available for performance monitoring. The individual chapters in this
guideline lists the KPIs which are especially relevant for the chapter – more general material on all counters
and KPIs can be found on the counters and KPIs section in the NPO 5G radio wiki.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
20 / 178
Internal
© 2020 Nokia
2.10
Project experiences
Field experiences from numerous 5G projects have already been collected and stored at the NPO 5G radio
wiki’s project material pages. This practice will continue, and it is the intention to not only collect readymade reports from the projects but also extract common learnings on how features and parameters work.
When studying reports from other projects, it should be kept in mind that not only do networks differ in
parameter settings, coverage, mobility and interworking strategies, but there are also differences in UE
population and in exact software packages in the BTSs and in the UEs – and so far, many performance
aspects depends on exactly which UE and which software package is being used. It can therefore not be
taken for granted that a certain configuration which works well in one network can be recommended in
another network.
2.11
Network design material
At least a basic understanding of the network design process is needed before starting the optimization
activities. The network design delivery kit provides such an understanding.
2.12
Pre-launch optimization material
Many of the activities done during the pre-launch optimization (e.g. parameter check and coverage
measurements) are similar to the activities done during the initial assessment phase of an optimization
project. It is therefore recommended to study the pre-launch optimization delivery kit.
2.13
Achievable KPI values
It is important to have a rough idea about the achievable performance before starting the optimization
activities, and especially before making even implicit commitments towards the operator.
There is good reference material related to achievable theoretical throughput in lab conditions. The NR
Throughput Tool is a wonderful tool, which in addition to providing the achievable throughput also allows
the user to play with various system parameters and study their impact on the throughput. The tool can
also consider the impact of features in coming releases. The tool is pretty self-explanatory but there are also
detailed descriptions available here and here. It should be kept in mind that the tool predicts the theoretical
throughput. Practical circumstances such as software implementation errors and radio link transmission
problems can prevent reaching the theoretical maximum.
For user plane and control plane latencies, this spreadsheet allows to enter some details on the network
configuration and calculate the expected breakdown of the various delay components. Test results are
28-Jan-2020 ULITPALIL5R3-1390467857-6948
21 / 178
Internal
© 2020 Nokia
available from multiple field tests (some of these are included in chapters 10 and 11), but nice consolidated
tables have not been made, so there is a bit of detective work involved when trying to predict what can be
achieved even in ideal conditions.
Likewise, there is not yet a consolidated view on how moving from lab environment to field tests degrades
the performance. Some illustrative examples are included in the following chapters, but these should be
viewed exactly as examples and not as consolidated results.
The GS CS QoE team maintains a database where field test performance is collected, analyzed and entered
into a summary spreadsheet. The material is available here.
Live network values of the most important OSS KPIs are available via the Performance Benchmarker 2.0 KPI
database. However, when studying the KPI values, it should be remembered that:
-
In some networks, the majority of the data traffic is probably caused by test engineers and “special
users” such as journalists running around doing speed tests
-
There are still UE performance issues (and also some network performance issues)
This means that the KPI values from live networks should still be considered mainly as examples and not as
target values.
Finally, when Nokia is selling 5G networks, we will normally need to commit to certain KPI values. The
documents stored at this link contains input for the KPI commitment process and they can be useful when
setting the performance expectations.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
22 / 178
Internal
© 2020 Nokia
3
Prerequisite checks before starting optimization
This section describes some of the checks which are recommended to be made before starting the real
optimization service.
3.1
Understand the operator’s view of good 5G performance
It is not obvious what is meant by good 5G performance. Possible interpretations by the operator includes
at least:
•
The time and area where the UE indicates “5G” in the display should be maximized
•
The end-user throughput (for example measured by an application such as Ookla Speedtest) should
be maximized in a given geographical area
•
The end-user throughput (for example measured by an application such as Ookla Speedtest) when
the UE displays “5G” should be maximized
•
Maximal amount of traffic should be offloaded from LTE to 5G, thereby improving performance of
legacy LTE
•
Low latency should be provided
The objectives listed above are to some extend in conflict with each other. For example, the threshold for
adding a 5G radio link (b1ThresholdNrRsrp) can be set low to ensure that the 5G addition will happen in as
big area as possible – but the same parameter can also be set high to ensure that when the UE does use
5G, the 5G radio link will have reasonable quality and therefore the throughput will be high.
It should therefore be clarified with the operator what “good 5G performance” means and when discussing
test results etc., it should be made clear that improvements for one performance indicator can mean
degradation for another indicator.
3.2
Understand the limitations imposed by non-RAN factors
Normally, the operator does not have completely freedom to configure the network, and it should be
understood what kind of restrictions that exist in a given network.
3.2.1
Regulatory restrictions
For TDD networks, the regulating authority will normally have put some restrictions as to what frame
structure which can be used, so interference between networks is avoided. Such restrictions can for example
limit the flexibility between uplink and downlink capacity or the achievable latency. However, it is possible
28-Jan-2020 ULITPALIL5R3-1390467857-6948
23 / 178
Internal
© 2020 Nokia
that such restrictions only apply to the macro layer and for example indoor cells covering a gaming event
can be configured more freely.
For health reasons there are probably also restrictions to how high field strength the general public may be
exposed to, and this can for example limit the use of high-gain beam forming. The 5GC001329: EIRP monitor
feature (5G19A) makes it possible to monitor the actual transmit power while the 5GC002052: EIRP control
feature (5G19B) allows to dynamically control the transmit power so radiation limits are not exceeded.
Section 13.7 has more on this topic.
3.2.2
UE interoperability issues
Many of the 3GPP features are optional to implement in the UE, and it needs to be understood how the
most used UEs in the market behave.
The most important point is which 5G frequency bands that are supported by the UE and which LTE / 5G
band combinations that are supported. Other points such as if the UE can transmit on both LTE and 5G at
the same time, MIMO support, carrier aggregation support etc. are also important.
Note also that the early UE chipsets are not yet supporting even all the mandatory 3GPP features.
Finally, there may be restrictions caused by implementation bugs in the UEs. For example, some early
Samsung UEs are only reporting the RSRP of beam #0 back to the BTS, and this means that the beam
pattern should be chosen such that beam #0 is covering the main part of the cell.
The “Terminal Information Portal” has information about terminal capabilities but only very basic like the
supported bands. The “UE community” also has basic information on NSA EN-DC terminals. It should be
checked directly with the operator what kind of terminals there are in the network and if there are any
known issues with those.
3.2.3
Self-imposed restrictions
Although a certain functionality is available in 5G19A, some operators will not allow to use it before they
have done interoperability tests with especially the main UEs in their network but perhaps also towards the
core and legacy LTE part of their network. It needs to be checked which BTS features that are not yet
“released” by the operator and when the release is expected to happen.
3.3
EN-DC carrier aggregation strategy
The throughput provided to the end user will normally be the combination of LTE and 5G throughput, at
least in the downlink direction. The relative importance of each leg should be understood. If for example
there is a large bandwidth (e.g. 100 MHz) available for the 5G carrier and the LTE network is heavily
28-Jan-2020 ULITPALIL5R3-1390467857-6948
24 / 178
Internal
© 2020 Nokia
congested, the major contributor to the end-user throughput will be the 5G leg, and most of the
optimization effort should be directed towards ensuring a good 5G throughput.
If, on the other hand, the 5G carrier bandwidth is for example only 10 MHz while the LTE carriers combined
have perhaps 40 MHz bandwidth, the 5G throughput will not contribute much to the combined end-user
throughput, and the optimization effort should instead be focused on ensuring that LTE carrier aggregation
is worked correctly also for EN-DC connections, that the X2 network is not dropping packets etc.
3.4
Parameter and feature check
The assessment consists of 3 parts:
-
Confirm that the plan for network-level parameters is reasonable
-
Confirm that the plan for cell-level parameters is reasonable
-
Confirm that the planned parameters have actually been implemented in the network
3.4.1
Confirm that the plan for network-level parameters is reasonable
In this context, network-level parameters are the ones which are expected to have same values for all the
cells / BTSs in the network. Even though it is possible to have different values in different cells or BTSs, the
recommendation for the early networks is to use a harmonized set of values for all cells. Later, it is expected
that certain cells, for example those which cater for high speed trains, will have special settings.
There is not a clear distinction between network-level and cell-level parameters. For example, many
networks are using the same beam pattern in all cells when they launch, but there may already be some
networks which are using different beam patterns to be able to cater for local conditions.
The first step is to find the planned values. There will typically be a spreadsheet with the planned values
which can be used. Sometimes, such a spreadsheet has not been maintained for some time, and the actually
used parameter values may be different. Sometimes it may be better to get the SCF (Site Configuration File)
directly from the BTS.
Next step is to find a good reference set. At least two possibilities exist:
-
Product Line (MN) has a set of recommended values at this location. There are recommendations
for multiple types of configurations (FDD, TDD Classical cm-wave, Classical mm-wave, Cloud mmwave etc.) and for all releases (5G19, 5G19A and 5G19B). Both SCF and Excel formats are available
-
Global NPO has a set of recommended values in this Excel sheet. In addition to listing the
recommended values for the network-level parameters, the sheet also explains from where the
values of cell level parameters should be taken
Final step is then to compare the parameter values from the local network with the Nokia global
recommendations. LTEPAT provides an easy way to compare two SCF files. There will certainly be deviations
28-Jan-2020 ULITPALIL5R3-1390467857-6948
25 / 178
Internal
© 2020 Nokia
between the local network settings and the global recommendations, and it is important to understand the
reason behind the deviations. There may for example be regulatory requirements which are specific to a
given country, or the given operator can have decided to prioritize some use cases (such as low latency)
over others (such as high capacity). Any deviations should be highlighted, and it should be considered how
the impact on network performance is.
To help understand how local choices can impact the parameter choices, the “5G Planning Topics” slide set,
which is available here, should be studied.
In addition to the normal parameters in the SCF file which are visible and modifiable to the operator, there
are also “hidden” parameters which are stored in the encrypted “Vendor” file and which can only be
inspected and changed by R&D. These parameters are included in the NIDD parameter list and may later
become visible and included in the SCF file.
Also, it is relevant to check the R&D parameters, which are included in the swconfig.txt file. These are mainly
flags for enabling or disabling certain functionalities in early feature implementations. These are not part of
NIDD and will disappear once a given feature has been fully implemented and tested. This spreadsheet
contains current recommendations for R&D parameter settings. If discrepancies are found between the
recommendation and the actually used values, they must be discussed with the local care team.
3.4.2
Confirm that the plan for cell level parameters is reasonable
This section concentrates on those cell level parameters which impact the radio performance. This means
for example that the gNB id and cell id principles are not discussed, even though intelligent choices here
will make O&M handling of the network easier. IP parameters are also not discussed.
3.4.2.1
PCI plan
The Physical Cell Identifier (PCI, physCellId) can be chosen from a set of 1008 possible values. These 1008
values are organised into 336 groups of 3. The PSS provides a pointer to the PCI within a group {1 of 3}
while the SSS provides a pointer to the group {1 of 336}. When the PCI values are decided, the following
rules should be followed:
-
Allocate 1 PCI Group per BTS for 3-sector and 2-sector BTS
-
Allocate 2 PCI Groups per BTS for 4-sector, 5-sector and 6-sector BTS
-
Allocate 1 PCI per BTS for single sector BTS
-
PCI should be planned to maximise the re-use distance
-
A UE should never be able to receive the same PCI from multiple cells
-
A specific BTS should not have multiple neighbours with the same PCI
-
PCI Planning co-ordination will be required at operator boundaries
28-Jan-2020 ULITPALIL5R3-1390467857-6948
26 / 178
Internal
© 2020 Nokia
There are several tools available which can be used to validate and optimize the PCI planning:
-
MUSA: NPO-developed optimization tool which is available for all NPO projects. Optimal PCI
planning is done based on the geometrical considerations (distance between BTSs etc.). It is the
intention to evolve the functionality such that also drive test data can be taken into account.
-
EdenNET: SON-product from Nokia Software (NSW)
-
9955: 5G radio network planning tool which is able to provide an optimal PCI planning. The
procedure is described in the 5G Outdoor RF Design Guideline.
-
5G Inspector: Product from Nokia Software (NetAct Performance Manager team), which among
other things can evaluate the PCI planning. High level description is available here.
In general, the same methodologies used for the pre-launch optimization can be applied in this initial
assessment. The pre-launch optimization delivery kit can be read for more details.
3.4.2.2
RSI plan
Root Sequences are used to generate the set of PRACH preambles belonging to each PRACH occasion.
Root Sequence Indices should be allocated to cells with a re-use distance which ensures that a specific cell
never receives PRACH transmissions from a UE which is using the same Root Sequence within another cell.
Root Sequence Index collisions generate unnecessary PRACH load and poor PRACH performance. Although
end-user experience may not be impacted, this scenario should nevertheless be minimized.
There are several tools available which can be used to validate the RSI planning:
-
MUSA: NPO-developed optimization tool which is available for all NPO projects. Optimal RSI
planning is done based on the geometrical considerations (distance between BTSs etc.). It is the
intention to evolve the functionality such that also drive test data can be taken into account.
-
EdenNET: SON-product from Nokia Software
In general, the same methodologies used for the pre-launch optimization can be applied in this initial
assessment. The pre-launch optimization delivery kit can be read for more details.
3.4.2.3
Neighbour plan
4G-5G neighbours are used to set up the NSA 5G connection. In many cases, non-co-located neighbours
need to be defined so some kind of planning is needed. Non-co-located 5G-5G neighbours are needed for
inter-site 5G handovers and must be planned as well. Co-located neighbours (both 4G-5G neighbours and
5G-5G neighbours) are normally always defined but this should of course be confirmed. Both 4G-5G and
5G-5G neighbour plans must be validated.
There are several tools available which can be used to validate the neighbour planning:
28-Jan-2020 ULITPALIL5R3-1390467857-6948
27 / 178
Internal
© 2020 Nokia
-
MUSA: NPO-developed optimization tool which is available for all NPO projects. Optimal 4G-5G
and 5G-5G neighbour planning is done based on the geometrical considerations (distance between
BTSs etc.). It is the intention to evolve the functionality such that also drive test data can be taken
into account.
-
EdenNET: SON-product from Nokia Software
-
9955: 5G radio network planning tool which is able to provide an optimal 5G -5G neighbour
planning. The procedure is described in the 5G Outdoor RF Design Guideline.
-
5G Inspector: Product from Nokia Software (NetAct Performance Manager team), which among
other things can evaluate the 5G-5G neighbour planning. High level description is available here.
In general, the same methodologies used for the pre-launch optimization can be applied in this initial
assessment. The pre-launch optimization delivery kit and the engineering guideline for NSA neighbour
management can be read for more details.
In addition to checking that the relevant neighbour cells are defined in the parameter file, it should also be
checked that the X2 links between the 4G BTS and the 5G BTS are actually available. This process in
described the 5G neighbour assessment Confluence page.
3.4.3
Confirm that the planned parameters are implemented in the network
The actually implemented parameters need to be compared with the planned parameters.
The first step is typically to export the implemented parameters from NetAct into a “raml” xml file.
Alternatively, if there is only a limited set of BTSs, the site configuration file (SCF, also in xml format) can be
taken from each BTS.
The xml file can then be parsed into a spreadsheet with the CM XML parser and manually compared with
the planned parameters. One such XML parser can be downloaded from here.
The LTEPAT offers another way to process the xml file by comparing it with a master file and highlighting
any differences.
It is also possible to use the RADAR tool for automatic comparison between a defined parameter standard
and the exported. Instructions on how to use RADAR as well as recorded presentation session is available
here.
3.5
Quick initial performance assessment
The purpose is to get quick impression of how the network behaves and where the most serious problems
can be found. The check should include the most important KPIs, and especially those KPIs which are
specifically mentioned in the project description.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
28 / 178
Internal
© 2020 Nokia
3.5.1
RF design validation
The general quality of the RF design should be evaluated. Basically, it should be decided if the RF design is
simply bad everywhere or if the RF design in general is sound, but adjustments are needed here and there.
One way to do such a network-wide assessment would be to first load the current network configuration
into the Atoll 9955 planning tool and run the predictions, then allow 9955 to optimize the configuration (for
example keeping the site locations but allowing the antenna azimuths and tilts to be adjusted) and run the
predictions again. If big improvements are seen with the optimized configuration, it should seriously be
considered to spend the money and time to implement the optimized configuration before the feature and
parameter tuning activities are started.
It should be kept in mind that part of the RF design is to have a correct registration of site parameters such
as location, antenna height, azimuth and tilt. If this registration is wrong, the predictions from Atoll 9955 will
of course also be wrong, and – depending on how serious the discrepancies are – the subsequent parameter
design (PCI, RSI, neighbor) may also be wrong. It will probably be prohibitively expensive to send teams to
manually check all the sites in the network, but it should be considered to select a relatively small area and
spend some time to check if the site configuration data looks reasonable. For example, in some countries
there is publicly available information on the site locations for all operators and in many cases, multiple
operators will share the same tower. If for example operator 1 (“our” operator) and operator 2 both use a
specific tower, and the antenna location for our operator is 200 meters away from operator 2’s antennas,
there must be something wrong in a database somewhere. The 3DGL documentation pages also have some
instructions on how to check the antenna placements.
3.5.2
Drive test KPIs
The drive test for initial performance assessment is very similar to the procedure for doing pre-launch cluster
optimization, except that the intention is only to obtain a rough idea about the current performance rather
than do detailed analysis in order to optimize the performance. It is normally only needed to perform the
drive test in a single, representative cluster.
When analysing the data, focus should be on:
-
Throughput (5G alone and 4G-5G combined)
-
Latency
-
Coverage and dominance
-
Handover performance
The pre-launch optimization delivery kit can be read for more details.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
29 / 178
Internal
© 2020 Nokia
3.5.3
OSS KPIs
A good list of relevant KPIs is the content of the “5G RAN system program report”, which is defined as part
of the Reporting Suite’s 5G package. These KPIs are visible in the Jump KPI portal; the 5G19A version of the
system program report is here.
The KPIs should be calculated on area level, with at least hourly resolution and over a period of at least one
week to determine if for example the problems occur mainly in the busy hour or if the network performance
is highly erratic. The KPI values can be compared with the values seen in other networks, for example in the
Performance Benchmarker KPI database (note: there are still only few networks with high number of “real”
5G subscribers, so the values in the KPI database should still be regarded as tentative).
Also, the performance of individual sectors should be calculated and compared with the network average
to determine if the main problems appear on a few individual sites or there is a general performance issue.
3.6
Backhaul capacity
The radio link capacity of a 5G BTS is often considerably higher than the co-located 4G BTS and there is
therefore often a need to expand the S1-U capacity between the gNB and the SGW. It should be checked
with the transmission engineers if all the S1-U links have been configured to have enough capacity.
The X2 interface capacity should also be checked: The EN-DC calls may (depending on parameter settings)
transfer a large amount of data on the X2 links.
In case of Cloud BTS deployments, it may also be relevant to check F1 interface capacity.
3.7
O&M status of the network
The sites within the geographical area that the optimization service covers should preferably all be on air
with stable configuration and no alarms. This may be difficult to achieve in practice, especially in the early
networks where there are ongoing roll-out and frequent parameter tunings.
Table 7 shows the relevant KPIs. Cell availability shows if the cells on the gNB are “on-air”, provided that the
gNB itself is working. If the entire gNB is down for at least one measurement period, there will be a hole in
the counter values, and it will be easy to overlook this. Therefore, the third formula (NR_576a) provides the
“counter availability”. Both formulas must show high values in order to have a network with high availability.
The number of X2 and F1 setup requests can also be used as problem indicators: If the interface goes down
due to some problems, the gNB will try to re-establish the interface, and this will increment the attempt
counters.
Note there are not yet 5G counters available to distinguish between the different unavailability scenarios,
i.e. it is not possible from counters to distinguish for example between the case where the BTS is integrated
but not yet brought on air (“blocked by user”), and the case where the BTS software has unintentionally
28-Jan-2020 ULITPALIL5R3-1390467857-6948
30 / 178
Internal
© 2020 Nokia
crashed. A manual analysis is therefore needed, where the focus is on those BTSs which are supposed to
be on air.
KPI id
KPI name
KPI formula
LTE_5239a
E-UTRAN Cell Availability,
excluding blocked by user state
(BLU)
SAMPLES_CELL_AVAIL / (DENOM_CELL_AVAIL -
NR_5150a
5G Cell availability ratio
SAMPLES_CELL_AVAIL / DENOM_CELL_AVAIL
NR_576a
5G Samples counter availability
ratio
DENOM_CELL_AVAIL / ( 60 x
MEASUREMENT_PERIOD x Number of cells that
report M55601C00001)
NR_5000a
5G Number of incoming X2 setup
request received from LTE eNB
ENDC_X2_SETUP_REQUEST_RECEIVED
NR_278a
5G Number of F1 setup procedure
attempts
F1_SETUP_ATT
SAMPLES_CELL_PLAN_UNAVAIL)
Table 7: KPIs to monitor cell availability
It is also needed to check the current alarm situation in the network. There are not yet any 5G Reporting
Suite reports available for this, so it is recommended to check the status with the Care team.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
31 / 178
Internal
© 2020 Nokia
4
Optimization of RF performance
4.1
Introduction
RF Optimization has always been regarded as the foundation to improve the performance of the network
in order to get the maximum benefits from any subsequent parameter optimization. Checking the coverage
footprint, aiming for good dominance areas, avoiding cross feeders and looking for wrong/not optimized
tilts and azimuths are fundamental areas which should be covered in the beginning of an optimization
service.
Traditionally, the optimization of the physical RF environment (typically changing antenna azimuths and
tilts) are done separately from the following parameter optimization but in the 5G networks, the ability to
control the antenna beam patterns by operator parameters are starting to merge the physical and
parameter optimization activities.
Early in the optimization project (ideally even before the project starts), it should be decided if the RF design
is simply bad everywhere or if the RF design in general is sound, but adjustments are needed here and
there.
One way to do such a network-wide assessment would be to first load the current network configuration
into the Atoll 9955 planning tool and run the predictions, then allow 9955 to optimize the configuration (for
example keeping the site locations but allowing the antenna azimuths and tilts to be adjusted) and run the
predictions again. If big improvements are seen with the optimized configuration, it should seriously be
considered to spend the money and time to implement the optimized configuration before the feature and
parameter tuning activities are started.
4.2
Typical issues
Lack of 5G radio coverage is often the most immediate concern in the early networks. Due to the possibility
to have a parallel 4G radio connection, the loss of the 5G radio link is not necessarily something which must
be avoided at all costs, but there should at least be an effort to provide coverage to the areas where many
5G subscribers are located.
Lack of clear 5G dominance can have negative long-term effects since it will cause an increase in the overall
interference levels in the area once the 5G traffic starts to rise. However, it also has some short-term effects:
-
Inter-gNB handover may not be enabled in the network, so if the 5G radio connection is set up on
a “neighbour BTS” which just happens to provide the best coverage on the spot where the
subscriber is, and the UE then moves into the normal coverage of the closest BTS, then the 5G radio
connection will be dropped
-
The 4G-5G neighbours must be planned and there is no automatic addition of neighbours like there
is in the 4G networks. If a EN-DC connection is started on a given anchor BTS, the UE may be in a
28-Jan-2020 ULITPALIL5R3-1390467857-6948
32 / 178
Internal
© 2020 Nokia
location where it is a 5G BTS further away which actually gives the best coverage, but since such a
5G BTS may not be defined as neighbour to the 4G anchor BTS, the 5G connection will not be
established.
In LTE, crossed feeder cables have been a problem. This is also likely to be a problem in 5G in the cases
where passive antennas are used. Active antennas will not have this problem, but swapped sectors are still
possible.
4.3
General performance analysis methods
The best and most expensive method to find RF problems in the network is to make traditional drive tests.
The methodology is the same as used for pre-launch optimization, and is described in the pre-launch
optimization engineering guideline. Apart from being expensive, there are other major drawbacks of this
method:
-
It is straightforward to measure street coverage but measuring indoor coverage (where the majority
of the subscribers can be expected to be) can be a challenge. Street coverage can be very difficult
to map to real user coverage, especially in a city environment with many high-rise buildings
-
Drive tests give a snapshot of the coverage and interference situation. Especially the interference
will vary dynamically with the traffic load and the location of the users, and the ever-ongoing
changes in the network, such as additions of new sites, will also quickly make drive test results
outdated
-
Measuring the downlink signal as is done in drive tests will not necessarily reveal problems with the
uplink signal. If uplink signal issues are expected, it may be necessary to capture BTS traces
simultaneously with the drive test.
An alternative is to base the analysis on predictions made by a radio network planning tool, such as the
Atoll / 9955. The 5G Outdoor RF Design Guideline describes how to use the 9955 tool and in general how
predicted performance can be calculated. Advantages of this approach is that it is a “desktop exercise” (so
it is cheap) and indoor coverage, even in high-rise buildings, can be estimated. The disadvantage is that
outdated maps or wrong assumptions about building penetration losses will give wrong predictions.
Naturally, mistakes in the site installations, such as wrong antenna azimuths, will not be detected by this
method.
There is some possibility to use network traces for 5G RF optimization. Various PCMD features are available
in 5G19A, and it is also possible to use the EN-DC part of the information available from the 4G Megaplexer
system. There is not yet experience with the uses of such traces for RF optimization. The “Minimization of
Drive Test” (MDT) features will come in later 5G BTS releases.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
33 / 178
Internal
© 2020 Nokia
The rest of this section will be based on the analysis of OSS counters related to RF optimization. In some
cases, it is possible to directly determine from OSS counters what the problem is and how it can be
mitigated, and in other cases OSS counters can be used as a “pointer” to a geographical area which needs
to be analysed further with field tests.
4.4
General optimization methods
Once a problem area has been identified, it must be decided if the best solution is to physically change the
antenna configuration or if a simple parameter change will be sufficient.
Physical antenna changes include:
•
Creation of completely new site, possibly an indoor site
•
Move the antennas
•
Change azimuth angle
•
Change mechanical tilt
The 5G Outdoor RF Design Guideline can be consulted on how these changes can impact the coverage.
Also the general documents in the RF Design RF Field Guides webpage can be of interest.
Relevant parameter changes include:
•
Beam pattern
•
Uplink power control
•
Downlink power control
The relevant features are listed in Table 8. Links to material with detailed discussion on how the parameters
work and how they should be set are available from the NPO 5G radio wiki’s parameter section.
Feature id
5GC000510
5GC000511
5GC000512
5GC000533
5GC000535
Feature name
Uplink open loop power control
PRACH control
DL power control
Digital Beamforming for CPRI based RUs
Analog Beamforming
Table 8: Relevant features for optimizing RF performance
28-Jan-2020 ULITPALIL5R3-1390467857-6948
34 / 178
Internal
© 2020 Nokia
4.5
Case: Crossed feeders or sectors
4.5.1
Description of the issue
Crossed feeders are a well-known problem seen in 2G, 3G and 4G radio network deployments. Crossed
feeders are caused by human error during the site build process. Such errors should have been detected
and corrected either during the single site verification immediately after the site is brought on air or by the
cluster optimization procedure. However, it can probably be expected that some construction errors will go
un-detected and will have to be dealt with during the optimization activities.
In case of active antennas, the possibilities for wrong installation are fortunately limited to sector swaps /
rotations, for example that sector 1 is radiating in the direction that sector 3 is supposed to radiate and vice
versa. This may compromise the PCI, RSI and neighbour cell planning.
When passive antennas are used, there are more complicated possibilities for errors:
•
Swapped sectors like for active antennas
•
Swapped TX / RX feeders, so one radio unit will transmit in sector 1 but receive in sector 2
•
Swapped MIMO feeders, so for example TX1 will transmit in sector 1 and TX2 will transmit in sector
2
•
Combinations of above
4.5.2
Performance analysis
If something is wrong with the transmit paths, drive tests should relatively easily be able to detect the
problems because the PCI plot will not look as expected. Figure 3 shows an example of swapped sectors.
Figure 3: Two examples of swapped sectors when active antennas are in use
28-Jan-2020 ULITPALIL5R3-1390467857-6948
35 / 178
Internal
© 2020 Nokia
Identifying problems with the BTS RX paths are much more difficult. If all the RX paths are wrong, the UL
and DL SINR difference will probably be so big that it is visible via the OSS counters listed in Table 9, but if
only some of the RX paths are swapped, it is questionable if this can be seen via counters.
Counter id
Counter name
Comment
M55301C19000..15
WB_CQI_64TBL_QCI_00..15
Wideband CQI Histogram when UE
reports related to 64QAM table - CQI
Level 0..15
M55301C20000..15
WB_CQI_256TBL_QCI_00..15
Wideband CQI Histogram when UE
reports related to 256QAM table - CQI
Level 0..15
M55303C05001..25
UE_SINR_PUSCH_R1_LEVEL_01..25
M55303C06001..25
UE_SINR_PUSCH_R2_LEVEL_01..25
PUSCH SINR measurements when
Rank 1 and when Rank 2 is in use
Table 9: Counters to detect differences in DL and UL link quality and therefore detect some scenarios with swapped feeders
The LTE optimization guideline has a detailed section on how to detect crossed feeders also in the MIMO
case, and most of the discussion is also relevant for 5G.
4.5.3
Optimization procedure
Once a site installation error is suspected, a site engineering team should be dispatched to the site to
confirm and correct the error.
4.6
Case: Only few EN-DC capable terminals have a 5G radio connection
4.6.1
Description of the issue
In some cases, the 5G cell(s) provide coverage only in part of the 4G cell, and this may not necessarily be
where the subscribers are. Especially the small 5G coverage provided by mmWave deployments can lead
to the situation where many EN-DC capable terminals will not be able to establish a 5G radio connection.
There is also the scenario where there is no 5G cell at all in the vicinity. This analysis can then help in deciding
the most suitable areas for additional 5G roll out.
It should be noted that parameter settings can also prevent EN-DC terminals from establishing the 5G radio
connection – correct choice of anchor LTE layer, 4G/5G neighbour definitions, QCI settings, etc. can all
impact. These are treated in the accessibility discussion in chapter 5. Before making decisions on RF
optimization, it should of course be checked that the lack of 5G radio connections is not caused by non-
28-Jan-2020 ULITPALIL5R3-1390467857-6948
36 / 178
Internal
© 2020 Nokia
optimal parameter settings. Figure 16 shows a good example of what different values of the
b1ThresholdNrRsrp parameter mean for the EN-DC coverage.
4.6.2
Performance analysis
From LTE counters, the number of EN-DC capable terminals can be found. From 5G counters, the number
of 5G radio connections can be found, and if there is a big discrepancy between these two numbers, it is
an indication of possible 5G coverage problems.
KPI id
KPI name
KPI formula
Comment
LTE_6435a
Average number of
UEs capable for
EN-DC
AVG_CAP_UE_SCG / 100
Average number of ENDC UEs with a 4G RRC
connection
LTE_1909b
UE EN-DC
capability utilization
ratio
AVG_UE_CONF_SCG
Should be used with
caution since the
avg_ue_conf_scg
counter is officially not
yet supported (not even
in LTE19B) and seems to
have some
implementation
problems
Share of 4G RRC
connections done
with EN-DC
capable EU
(AVG_CAP_UE_SCG / 100)
5G Average
number of NSA
users
AVE_NUMBER_OF_NSA_USERS /
AVE_NUMBER_OF_NSA_USERS_DENOM
LTE_1907b
NR_5124a
/ AVG_CAP_UE_SCG
/ RRC_CONNECTED_UE_AVG
Table 10: KPI formulas for number of EN-DC users. All formulas are cell level. Note that although avg_ue_conf_scg is available already
from LTE18A software, it is still not officially supported and has not been tested. Field observations indicate there are pro blems with
this counter, so it should not be fully trusted.
Unfortunately, there is not necessarily an easy way to link these numbers because the 4G-5G neighbour
relations often form a n-to-m mesh network (illustrated in Figure 4).
28-Jan-2020 ULITPALIL5R3-1390467857-6948
37 / 178
Internal
© 2020 Nokia
Figure 4: Illustration of 4G-5G neighbour mesh network. EN-DC connections with eNB-25 as anchor BTS are scattered among 5
different gNBs – but the number of users in those 5 gNBs cannot simply be summarized and compared with eNB-25 because each
gNB is also connected to other eNBs
In the special case where there is 1-to-1 relation between 4G BTS and 5G BTS, the number of users in the
two layers can be compared (see example in Figure 5).
Figure 5: Comparison between EN-DC capable terminals with 4G RRC connection and actual 5G radio connections for the case where
there is 1-1 mapping between the 4G anchor cells and the 5G cells
One approach can be to assume that the 5G has “island coverage” and that in practice, all 5G EN-DC
connections for a given 4G BTS will happen in the co-located 5G BTS. This can at least produce a list of
potential problem areas, which can then be investigated in more detail. As part of this investigation, it should
be confirmed that the problems are not due to strange parameterization of the features described in the
accessibility section (chapter 5).
28-Jan-2020 ULITPALIL5R3-1390467857-6948
38 / 178
Internal
© 2020 Nokia
4.6.3
Optimization procedure
Once “problem areas” have been found (i.e. areas where abnormally few of the RRC-connected EN-DC
terminals have a 5G radio connection), the 5G coverage area should be compared with likely locations of
the 4G EN-DC subscribers. This can either be done visually by looking at a map to identify e.g. a shopping
mall, or it can be based on LTE trace tools such as PCMD or MDT.
It can then be evaluated if the existing 5G antennas can be modified to improve 5G coverage, or if a new
5G site (perhaps an indoor site) is needed. Options for modifying existing 5G antennas are:
-
Use another beam pattern
-
Change mechanical tilt
-
Change azimuth angle
-
Move antenna up / down (not always possible)
-
Move antenna to another location (not always possible)
4.7
Case: Adjust antenna configuration based on 5G beamforming counters
4.7.1
Description of the issue
The beampattern of the 5G signal may not provide the optimal coverage when the actual location of the
5G users are considered, and in some cases, the information captured by the 5G beamforming counters
can tell if there is a need for antenna adjustments.
4.7.2
Performance analysis
The most relevant information from BTS counters is how much each beam is used. From the OSS counters,
there is no information about the quality of each beam nor how far away the users of a specific beam are.
Currently, PCMD traces are needed to find more detailed per-beam performance.
Naturally, the counters only work if beamforming is actually enabled in the radio units.
Counter id
Counter name
Comment
M55305C00001..64
DL_SERV_BEAM_ID_BEAM_63
Provides the beam distribution for
PDSCH
M55305C01001..64
UL_SERV_BEAM_ID_BEAM_63
Provides the beam distribution for
PUSCH
Table 11: Counters for PDSCH / PUSCH beam distribution. Used for both analog beamforming (each counter represents one SSB
beam, up to 32 counters are used) and digital beamforming (first 8 counters represent the SSB beams while the rest will in 5G19A
represent the refined beams). Note that for analog beamforming, the mapping between the SSB Resource Indicator (reported by UE
in drive test logs) and the SSB index (used to increment counters) is not straightforward. More details are available in the NPO counter
description document.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
39 / 178
Internal
© 2020 Nokia
The initial postprocessing then simply consists in making histogram charts for each sector and select those
sectors where most of the samples are concentrated in a few beams for further analysis.
4.7.3
Optimization procedure
Once the histogram charts are ready, the sectors where mainly a few beams are used should be examined
manually and it should be considered if changing either the beam pattern or other antenna parameters
may provide better coverage.
For example, if digital beam set #8 is configured, and it is mainly the two middle beams which are used,
and manual map inspection shows single high-rise building in the direction of the two middle beams , it
should be considered to change to beam set #2#2#2#2 (Figure 6)
Figure 6: Scenario where the beam pattern is changed from #8 to #2#2#2#2
Another example is the case where #2#2#2#2 is already in use to cover a high-rise building, but only the
top row of beams is used (Figure 7) and visual inspection indicates that the top floors may not have
coverage. Here it can be considered to up-tilt the antenna in order to also provide coverage to the top
floors (and at the same time reduce coverage for the lower floors which in this case seems not to be needed).
28-Jan-2020 ULITPALIL5R3-1390467857-6948
40 / 178
Internal
© 2020 Nokia
Figure 7: Scenario where uptilting the antenna may improve the performance
It is important to be aware that with the PM counters, it is not easy to distinguish between the case where
certain beams are not much used because there are only few users at the location, and it is therefore a
waste of transmit power to serve the location, and the case where there are actually users at the location,
but the coverage is so bad (e.g. behind a wall) that the radio connection will quickly drop, and the counters
therefore show that the particular beam is not used much. In the latter case, the correct optimization action
is of course to improve the coverage at this location, not to remove it completely.
Options for improving the coverage are:
-
Use another beam pattern
-
Change mechanical tilt
-
Change azimuth angle
-
Move antenna up / down (not always possible)
-
Move antenna to another location (not always possible)
-
Establish new site
The best option needs to be decided on a case-by-case basis. In all cases, it should be carefully analysed if
changing the RF environment may lead to unwanted coverage holes or increased interference.
4.8
Case: Use 5G timing advance counters to detect overshooting
4.8.1
Description of the issue
Terminals used unexpectedly far away from the cell may increase the interference in the network
28-Jan-2020 ULITPALIL5R3-1390467857-6948
41 / 178
Internal
© 2020 Nokia
4.8.2
Performance analysis
The 5G timing advance distribution counters provides information on how far away from the cell that the
terminals are on average, but there is no correlation with the beam id, so the angle cannot be determined
Counter id
Counter name
Comment
M55307C01001..32
TA_RACH_RESP_BIN_01..32
Timing advance during the RACH
procedure (based on preamble TA)
M55307C02001..32
TA_RRC_CON_BIN_01..32
Timing advance during the connection
(based on PUSCH / PUCCH TA)
Table 12: Counters for timing advance. To identify overshooting cells, the RACH TA counters are preferred
One way to analyse the counters is to first summarize values per cell (e.g. over one week) and plot the bin
distribution, then identify those cells which have “island areas” away from the cell centre. Figure 8 shows
such analysis where the left chart shows all the cells in the network with reasonable traffic and the right chart
shows examples of “nice” and “bad” distribution.
Figure 8: Example of Timing Advance distribution from RACH TA counters. The blue curve is "nice" example with all samples close to
the cell center and the red curve is potentially "bad" example with "island coverage" in bin 8.
4.8.3
Optimization procedure
Once potential problem cells have been identified, it is necessary to analyse case by case if there are good
reasons for such a distribution. For example, there may be a city square a bit away from the cell, which
cannot be served by other cells.
When it has been confirmed that the “island coverage” is indeed unintentional overshooting, this should be
removed, either by choosing a different antenna pattern or by increasing the mechanical downtilt of the
antenna. Naturally, it should be considered if the chosen solution may create new problems elsewhere in
the cell.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
42 / 178
Internal
© 2020 Nokia
4.9
Case: Using counters to identify areas with bad downlink radio quality
4.9.1
Description of the issue
Bad downlink radio link quality leads to the use of lower modulation and coding scheme. This reduces the
end-user throughput as well as the network capacity. In extreme cases, the radio connection may even be
broken.
4.9.2
Performance analysis
The analysis can either be directly based on the CQI information coming from the UE’s channel state
information reports, or it can be indirectly based on the chosen modulation and coding scheme (MCS). The
MIMO rank can also be useful. Table 13 summarizes the possibilities and Table 14 lists the relevant counters.
Note that downlink signal level is not available, so it is not possible to directly distinguish between the bad
coverage case and the high interference case – but some indication can be given by analysing the uplink
RSRP level. Broken radio links are not necessarily caused by bad RF conditions but should still be
investigated. The relevant KPIs are listed in Table 15.
Counter group
Pros and cons
CQI: Downlink signal
quality measured by UE
and reported to BTS
Gives directly information about the downlink signal quality. In early
networks, it has been observed that some UE types report wrong values
MCS distribution
Relies on link adaptation algorithm to choose relevant MCS for the given
radio conditions. With short data bursts, the initial MCS becomes
overrepresented. Msg2 and Msg3 uses 64QAM MCS0, so this also becomes
overrepresented. In 5G19A, the scheduler will reduce the MCS if the packet
size is small
Initial BLER
Not a good indicator, since this is more impacted by the ability of link
adaptation to follow the variation in radio conditions rather than the radio
conditions themselves. Also, if small packets are transmitted, the scheduler
may have picked a lower MCS which gives more robust transmission and
therefore lower BLER than what can be expected from radio conditions
MIMO rank
The MIMO rank is partly decided by the signal quality (low SINR means
using lower rank), partly by the multipath environment, and it is not
straightforward to separate the two effects
MIMO rank combined
with MCS distribution
To get full benefit of MIMO, it is not enough to have high rank and good
SINR. The data streams must also be uncorrelated, and the used MCS can
28-Jan-2020 ULITPALIL5R3-1390467857-6948
43 / 178
Internal
© 2020 Nokia
Counter group
Pros and cons
give a hint if this is the case – but note the problems with MCS counters:
There is a dependency on the link adaptation algorithm and traffic patterns
Uplink RSSI
Although not impacting the downlink signal quality, it can be used to
identify the bad downlink coverage cases by assuming that low UL RSSI also
means low DL signal level
Radio link failures
Requires that intra-gNB and inter-gNB handover is enabled to be
reasonably certain that radio link failures only happen where there is bad
5G coverage
Table 13: Pros and cons of the different counter groups to measure downlink radio link quality
Counter id
Counter name
Comments
M55301C19000..15
WB_CQI_64TBL_QCI_00..15
Wideband CQI Histogram when UE
reports related to 64QAM table CQI Level 0..15
M55301C20000..15
WB_CQI_256TBL_QCI_00..15
Wideband CQI Histogram when UE
reports related to 256QAM table CQI Level 0..15
M55300C00000..28
PDSCH_INITX_64TBL_MCS_00..28
M55300C04000..27
PDSCH_INI_256TBL_MCS_00..27
Can be used to calculate MCS
distribution
M55300C01000..28
PDSCH_SUCC_INI_64TBL_MCS_00..28
M55300C05000..27
PDSCH_SUCC_INI_256TBL_MCS_00..27
M55301C09001..02
PDSCH_2TX_RI_01..02
In case 2x2 MIMO is used
M55301C10001..04
PDSCH_4TX_RI_01..04
In case 4x4 MIMO is used
M55301C00000..28
PDSCH_RANK1_64TBL_MCS_00..28
M55301C01000..28
PDSCH_RANK2_64TBL_MCS_00..28
M55301C02000..28
PDSCH_RANK3_64TBL_MCS_00..28
M55301C03000..28
PDSCH_RANK4_64TBL_MCS_00..28
M55301C15000..27
PDSCH_RANK1_256TBL_MCS_00..27
Gives the distribution of the rank
and MCS combinations. If 2x2
MIMO is in use, only rank 1 and
rank 2 counters are used. If 4x4
MIMO is in use, rank 1, rank 2, rank
3 and rank 4 counters are used
M55301C16000..27
PDSCH_RANK2_256TBL_MCS_00..27
M55301C17000..27
PDSCH_RANK3_256TBL_MCS_00..27
M55301C18000..27
PDSCH_RANK4_256TBL_MCS_00..27
M55303C07001..44
UE_SIGNAL_PWR_PUSCH_01..44
28-Jan-2020 ULITPALIL5R3-1390467857-6948
44 / 178
Internal
Can be used to calculate initial BLER
for each MCS
Can be used to deduce downlink
signal level and therefore to
estimate if bad downlink signal
quality is due to bad coverage
© 2020 Nokia
Table 14: Counters which can be used to measure downlink radio link quality.
KPI id
KPI name
KPI formula
Comments
NR_457c
5G Radio link
failure release ratio
(RLF_INITIATED_RNL +
NF1CC_UECTXT_MOD_REQRECD +
RLF_INITIATED_UE_T310_EXPIRY +
RLF_INITIATED_UE_RACH_FAIL +
RLF_INITIATED_UE_MAX_RLC_RETX +
RLF_INITIATED_UE_SRB_INTGRTY_F +
RLF_INITIATED_UE_SCG_CHGE_FAIL +
RLF_INITIATED_UE_SCG_RECNF_F)
A radio link failure
indicates problem with
the radio link quality.
Note: The formula does
not give completely
correct ratio but can still
be used to detect issues
with RLF
/ X2_SGNB_REL_REQUIRED_SENT
NR_5043b
5G Intra gNB intra
frequency PSCell
change total failure
ratio
(INTRA_FR_PSCEL_CH_FAI_TDC_EXP +
INTRA_FR_PSCEL_CH_FAI_MENB_REF +
INTRA_FR_PSCEL_CH_FAI_RES_ALLO) /
(INTRA_FR_PSCEL_CH_FAI_RES_ALLO +
INTRA_FR_PSCEL_CH_ATTEMPT +
INT_FR_PSCEL_CHA_ATT_SRB3)
Handover failures are
often caused by cells not
having sufficient overlap
Table 15: KPI formulas to measure broken radio links
Figure 9 - Figure 11 illustrate how the different KPIs for quantifying the downlink radio link quality can be
correlated:
•
Figure 9: CQI and DL MCS is correlated in the sense that high MCS cannot be achieved in cells with
low CQI. However, in 5G19A with the new scheduler behavior (MCS is lowered for small packets), a
low MCS can be seen both in cells with low CQI and in cells with high CQI
•
Figure 10: When 2x2 DL MIMO is used (network 2), there is clear correlation between CQI and the
rank. However, when 4x4 MIMO is used (network 1), the correlation is not there
•
Figure 11: The PUSCH RSSI is nicely correlated with the QCI in the low-traffic network 2. This indicates
that bad CQI values are related to bad coverage. On the other hand, the correlation is less clear in
the high-traffic network 1, indicating that at least some of the bad CQI values are caused by
interference rather than bad coverage
28-Jan-2020 ULITPALIL5R3-1390467857-6948
45 / 178
Internal
© 2020 Nokia
Figure 9: Examples of DL MCS and CQI correlation from two different networks. Each dot is one cell aggregated over time. Network
1: Commercial traffic, 3.5 GHz, 5G19. Network 2: Test traffic, 600 MHz, 5G19A
Figure 10: Examples of DL rank and CQI correlation from two different networks. Each dot is one cell aggregated over time. Network
1: Commercial traffic, 3.5 GHz, 4x4 MIMO, 5G19. Network 2: Test traffic, 600 MHz, 2x2 MIMO, 5G19A
Figure 11: Examples of PUSCH RSSI and CQI correlation from two different networks. Each dot is one cell aggregated over time.
Network 1: Commercial traffic, 3.5 GHz, 5G19. Network 2: Test traffic, 600 MHz, 5G19A
28-Jan-2020 ULITPALIL5R3-1390467857-6948
46 / 178
Internal
© 2020 Nokia
4.9.3
Optimization procedure
Figure 9 - Figure 11 illustrate nicely that in the early networks, the correlations between different KPIs is not
always as clean as expected, and this underlines the recommendation that RF OSS KPIs should only be used
as indicators for potential problems which then need to be investigated in detail with e.g. drive test activities.
The optimization procedure can therefore be summarized as follows:
1.
From the indicators listed in previous section, find badly performing cells
2. Confirm that the parameter settings of the bad cells are according to the intended settings
3. Based on local knowledge (e.g. looking at a map), decide if there are obvious reasons for the bad
performance
4. Send a field test team to make detailed measurements
5. Based on the detailed measurements, optimize the RF configuration (antenna installation, beam
pattern parameters) and observe the impact on the OSS KPIs
4.10
Case: Using counters to identify areas with bad uplink radio quality
4.10.1
Description of the issue
Bad uplink radio link quality leads to the use of lower modulation and coding scheme. This reduces the enduser throughput as well as the network capacity. For TCP connections (for example web browsing or file
downloading), a poor uplink performance can also limit the downlink performance due to delayed TCP
acknowledgement messages. In extreme cases, the radio connection may even be broken.
4.10.2
Performance analysis
The analysis can either be directly based on the RSSI and SINR measured by the BTS, or it can be indirectly
based on the chosen modulation and coding scheme (MCS). Table 16 summarizes the possibilities and Table
17 lists the relevant counters.
Broken radio links are not necessarily caused by bad RF conditions but should still be investigated. The
relevant KPIs are listed in Table 15.
Counter group
Pros and cons
SINR: Uplink signal
quality measured by the
BTS
Gives directly information about the uplink signal quality
28-Jan-2020 ULITPALIL5R3-1390467857-6948
47 / 178
Internal
© 2020 Nokia
Counter group
Pros and cons
RSSI: Uplink signal level
measured by the BTS
Can be used together with the UL SINR to decide if bad SINR is due to bad
coverage or due to interference
UE signal power
By subtracting the UE signal power from the RSSI, the absolute value of the
noise + interference can in principle be measured
MCS distribution
Relies on link adaptation algorithm to choose relevant MCS for the given
radio conditions. With short data bursts, the initial MCS becomes
overrepresented. Msg2 and Msg3 uses 64QAM MCS0, so this also becomes
overrepresented. In 5G19A, the scheduler will reduce the MCS if the packet
size is small
Initial BLER
Not a good indicator, since this is more impacted by the ability of link
adaptation to follow the variation in radio conditions rather than the radio
conditions themselves. Also, if small packets are transmitted, the scheduler
may have picked a lower MCS which gives more robust transmission and
therefore lower BLER than what can be expected from radio conditions
Radio link failures
Requires that intra-gNB and inter-gNB handover is enabled to be
reasonably certain that radio link failures only happen where there is bad
5G coverage
Table 16: Pros and cons of the different counter groups to measure uplink radio link quality
Counter id
Counter name
Comments
M55303C05001..25
UE_SINR_PUSCH_R1_LEVEL_01..25
UL SINR measured by the BTS
M55303C06001..25
UE_SINR_PUSCH_R2_LEVEL_01..25
M55303C08001..18
UE_SINR_PUCCH_LEVEL_01..18
M55303C07001..44
UE_RSSI_PUSCH_LEVEL_01..44
M55303C09001..44
UE_RSSI_PUCCH_LEVEL_01..44
M55303C10001..44
UE_SIGNAL_PWR_PUSCH_01..44
By subtracting the UE signal power
from the RSSI, the absolute level of
noise and interference can in
principle be calculated
M55302C00000..28
PUSCH_CP_INI_64TBL_MCS_00..28
Can be used to calculate MCS
distribution
M55302C01000..28
PUSCH_CP_INIRETX_64TBL_MCS_00..28
Can be used to calculate initial
BLER for each MCS
UL RSSI measured by the BTS. Can
be used to estimate if bad up
signal quality is due to bad
coverage
Table 17: Counters which can be used to measure uplink radio link quality
28-Jan-2020 ULITPALIL5R3-1390467857-6948
48 / 178
Internal
© 2020 Nokia
Figure 12: Example of RSSI / SINR correlation from one network, each dot is one cell aggregated over 24 hours. Top-100 cells plotted,
3.5 GHz, 5G19. The absence of samples with low SINR and high RSSI shows that uplink performance in this network is limited by
coverage, not by interference.
Figure 13: Examples of PUSCH SINR and PUSCH MCS correlation from two different networks. Each dot is one cell aggregated over
time. Network 1: Commercial traffic, 3.5 GHz, 5G19. Network 2: Test traffic, 600 MHz, 5G19A. It is surprising that network 2 (5G19A)
doesn’t have cases with low MSC and high SINR (the expected small UL packet size should result in selection of low MCS) – this could
perhaps be due to the nature of test traffic
4.10.3
Optimization procedure
In the early networks, the correlations between different KPIs is not necessarily as clean as expected, and
the recommendation is that RF OSS KPIs should only be used as indicators for potential problems which
then needs to be investigated in detail with e.g. drive test activities. Note that since the problem is with the
uplink signal, a BTS trace will typically also be needed to understand the full situation.
The optimization procedure can therefore be summarized as follows:
1.
From the indicators listed in previous section, find bad performing cells
2. Confirm that the parameter settings of the bad cells are according to the intended settings
28-Jan-2020 ULITPALIL5R3-1390467857-6948
49 / 178
Internal
© 2020 Nokia
3. Based on local knowledge (e.g. looking at a map), decide if there are obvious reasons for the bad
performance
4. Send a field test team to make detailed measurements with simultaneous tracing on the BTS side
5. Based on the detailed measurements, optimize the RF configuration (antenna installation, beam
pattern parameters) and observe the impact on the OSS KPIs
28-Jan-2020 ULITPALIL5R3-1390467857-6948
50 / 178
Internal
© 2020 Nokia
5
Optimization of accessibility
This chapter covers the events from the UE is in RRC idle mode on a 4G cell until the 5G RACH procedure
has been completed on the 5G cell. There is heavy interaction between the LTE eNB and the 5G gNB during
this process.
The various steps in the process are described in Table 18. The details are described in the following sections.
The last section of the chapter describes how feasible it is to measure the full accessibility procedure with a
few KPIs.
Live network experience is still that unusual accessibility problems sometimes disappear by doing a site
reset.
Step
Content
Major dependencies
A
EN-DC capable UE camps on LTE
anchor cell
LTE parameter settings, LTE radio conditions
B
LTE RRC connection is established
LTE radio conditions
C
NR PDCP E-RAB and DRB is set up on
LTE cell
HSS subscription settings, LTE radio conditions
D
UE measures good enough 5G radio
signal (optionally skips this step and
goes directly to E)
LTE parameter settings, 5G radio conditions
E
SgNB addition
5G gNB, 5G admission control
F
UE gets info on 5G radio configuration
through the RRC reconfiguration
procedure
LTE radio conditions
G
The user plane is set up in the 5G gNB
(SN transfer and E-RAB modification)
4G eNB, 5G gNB, EPC
H
5G RACH procedure is completed
5G radio conditions
Table 18: The needed steps to set up a 5G radio connection
5.1
Step A: EN-DC capable UE camps on LTE anchor cell
Feature id
Feature name
LTE490
Subscriber profile ID selective neighbor cell list
LTE487
Idle Mode Load Balancing
LTE1677
Idle Mode Mobility Balancing Extensions
28-Jan-2020 ULITPALIL5R3-1390467857-6948
51 / 178
Internal
© 2020 Nokia
Feature id
Feature name
LTE2166
Dedicated Idle Mode Mobility Priorities
LTE2050
Load Triggered Idle Mode Load Balancing
LTE2051
Measurement Based Idle Mode Load Balancing
LTE5150
EN-DC capability based mobility trigger
Table 19: Relevant features to study when deciding on the LTE anchor carrier strategy
The operator can decide if all the 4G carrier frequencies can act as the LTE anchor for EN-DC connections,
or if only a subset of the 4G carriers can have this role – typically a single 4G carrier. If only selected 4G
carriers can act as anchor carriers, the LTE mobility profile parameters should be set so EN-DC capable UEs
with a 5G subscription will camp on the LTE anchor carrier when they are in idle mode. This can in principle
be achieved by using mobility profiles based on a combination of UE capability and subscriber profile id
(SPID).
The LTE parameterization is relatively complex and must take the legacy LTE layer strategy into account.
The NPO parameter material contains material which provides detailed description of the relevant
parameters.
It should be noted that lab tests have indicated that basing the selection of the LTE cell only on the UE
capability will not work – SPID must also be taken into use (case id = CAS-266372-G6M0, LTE19A). It is
currently not clear if and when this behaviour will be corrected.
In LTE19B, the LTE5150: EN-DC capability based mobility trigger feature can be used to move EN-DC capable
users to a specific carrier by doing a handover immediately after the RRC connection is established.
The LTE cell level KPIs in Table 20 can show in which LTE layer that the EN-DC capable UEs are establishing
LTE RRC connections. The values of these KPIs should be checked for each LTE layer and it should be
confirmed that the result is according to the planned strategy.
KPI id
KPI name
KPI formula
LTE_6435a
Average number of UEs capable for EN-DC
AVG_CAP_UE_SCG / 100
LTE_1907b
Share of 4G RRC connections done with ENDC capable EU
(AVG_CAP_UE_SCG / 100) /
RRC_CONNECTED_UE_AVG
LTE_6429a
E-UTRAN Initial E-RAB Setup Attempts for
MCG bearer with NR PDCP
ERAB_STP_ATT_MCG_NR_PDCP
Table 20: LTE KPIs to follow to confirm EN-DC capable UEs use the intended LTE layer
28-Jan-2020 ULITPALIL5R3-1390467857-6948
52 / 178
Internal
© 2020 Nokia
Layer
Share of LTE_6429 (NR ERAB
setup attempts)
L0800
50%
L1800
4%
L2100
39%
L23TD1
4%
L23TD2
3%
Others
0%
Table 21: Example of number of NR ERAB setup attempts from the different LTE layers. In this network, L2100 is the main anchor
layer and LTE0800 is used in low coverage locations. Most of the NR ERABs are set up from these two layers as designed.
5.2
Step B: LTE RRC connection is established
There is nothing EN-DC specific in this step. No specific parameters to set and no specific counters to follow
the performance. PCMD or Emil traces are needed to show the specific performance for EN-DC UEs. Legacy
LTE optimization procedures should be applied.
5.3
Step C: NR PDCP E-RAB and DRB is set up on LTE cell
During this step, an E-RAB is established between the UE and the MME. As part of the E-RAB, a DRB is
established between the UE and the eNB. There are specific EN-DC counters in the LTE eNB to monitor the
establishment of the E-RAB and the DRB. The associated KPI formulas are listed in Table 22.
KPI id
KPI name
KPI formula
LTE_6430a
E-UTRAN Initial E-RAB Setup Success
Ratio for MCG bearer with NR PDCP
ERAB_STP_SUCC_MCG_NR_PDCP /
ERAB_STP_ATT_MCG_NR_PDCP
LTE_6646a
E-UTRAN Additional E-RAB Setup
Success Ratio for MCG bearer with NR
PDCP
ERAB_ADD_STP_SUCC_MCG_NR_PDCP
/ ERAB_ADD_STP_ATT_MCG_NR_PDCP
LTE_6650a
E-UTRAN Initial DRB Setup Success Ratio
for MCG bearer with NR PDCP
DRB_INI_STP_SUCC_MCG_NR_PDCP /
DRB_INI_STP_ATT_MCG_NR_PDCP
LTE_6652a
E-UTRAN Additional DRB Setup Success
Ratio for MCG bearer with NR PDCP
DRB_ADD_STP_SUCC_MCG_NR_PDCP
/ DRB_ADD_STP_ATT_MCG_NR_PDCP
Table 22: LTE KPIs to monitor the establishment of E-RAB and DRB for EN-DC connections
28-Jan-2020 ULITPALIL5R3-1390467857-6948
53 / 178
Internal
© 2020 Nokia
The DRB setup is a subset of the E-RAB setup, so if the DRB setup success ratio is low, the LTE radio
conditions should be investigated. If the E-RAB setup success ratio is lower than the DRB setup success ratio,
the signalling between the eNB and the core network should be investigated.
Successful E-RAB setup does not necessarily lead to an attempt to establish a 5G radio link:
•
The UE must have an EPS Bearer which has a QCI which is enabled for EN-DC and an ARP value
within the range enabled for EN-DC
•
The UE must not have an ‘NR Restriction’ flag included within its Handover Restriction List
•
The LTE5524: Ongoing QCI1 Prevents EN-DC Setup feature will prevent the 5G secondary cell
addition as long as there is a VoLTE call ongoing (see more details in chapter 12)
•
If LTE4575: Blind Carrier Aggregation with LTE-NR DC Option 3X is enabled, a failing LTE carrier
aggregation means that the 5G secondary cell addition will not happen (see more details in section
9.4.2)
•
In 5G19 / LTE19, only a single bearer can be configured as an EN-DC split bearer. 5G19A / LTE19A
makes it possible to configure multiple non-GBR bearers as split bearers (see the list of relevant
features in Table 23). Note that with LTE19A, all the bearers must be established before the SgNB
addition happens – with LTE19B, it is possible to add more bearers after the SgNB addition has
happened
Feature id
Feature name
Release
5GC000795
Multiple DRBs per UE -NSA mode 3x
5G19A
LTE4531
LTE-NR DC Option 3X: Multiple non-GBR SCG split Bearers
LTE19A
LTE5510
Stepwise addition of multiple bearers for EN-DC
LTE19B
Table 23: Features related to multiple split bearers per UE
A more complicated problem is the case where there are many 5G additions and releases within the same
LTE RRC connection. This can for example happen if the LTE 1819: Data Session Profiling feature is active
and has allocated a longer inactivity timer to a UE with frequent state transitions. A new DRB identity is
allocated every time the 5G is added (i.e. the 5G DRB is created) or removed (i.e. the LTE DRB is created).
There is a maximum of 32 DRB identities, and once this number is reached, the 5G addition is blocked.
Workarounds for this problem include:
•
Deactivating LTE1819 and make sure that the 4G inactivity timer is not much higher than the 5G
inactivity timer
•
Enable 5G intra-cell handover to reset the DRB numbering when necessary. This is done in LTE19
and LTE19A by setting bit #2 in the temporary dataVolThreshold parameter to “1”
28-Jan-2020 ULITPALIL5R3-1390467857-6948
54 / 178
Internal
© 2020 Nokia
5.4
Step D: Identifying the 5G cell
It is possible to use “blind addition” when identifying the 5G cell which should be used for the 5G part of
the connection. This is an attractive choice in the scenarios where latency is important, and it can be taken
for granted that there is 5G radio coverage – for example an indoor cell or when using LTE and 5G on the
same frequency band with the same antennas.
However, the typical scenario is that measurement-based addition is used, i.e. the 4G BTS provides the UE
with information about the 5G cells and how they should be measured, and the UE then reports back to
the 4G BTS when it has found as suitable cell.
In both cases, at least one 4G – 5G neighbour must be defined. The LNADJGNB object defines the neighbour
relationship for a specific 5G BTS which allows the X2 connection to be setup between the 4G and 5G BTS.
As a minimum, an instance of the object should be created for the co-sited 5G BTS. The requirement for
additional LNADJGNB depends upon the 4G /5G operating bands and the site density. An example strategy
could be to create LNADJGNB instances for at least the first tier of neighbouring 5G BTS. The LNRELGNBCELL
objects pointing towards 5G cells can then be added as 5G Secondary Cell Group (SCG) cells. The minimum
requirement is to add the co-sited co-sectored 5G cell. If separate antennas are used for 4G and 5G then
azimuths may be different, so it is recommended to also add co-sited non-co-sectored 5G cells. The
engineering guideline for NSA neighbour management can be read for more details.
Table 24 lists the most relevant parameters.
Parameter
Object
Range
Default
Recommended
actDynTrigLteNrDualConnectivity LNBTS
False (0), True (1)
False (0)
True (1)
b1TriggerQuantity
NRDCDPR
RSRP, RSRQ
-
RSRP
b1ThresholdNrRsrp
NRDCDPR
-140 to -43 dBm
-
-120 dBm, see
also below
b1ThresholdNrRsrq
NRDCDPR
-20 to -3 dB
-
Empty
hysB1ThresholdRsrp
NRDCDPR
0 to 15 dB
2 dB
2 dB
hysB1ThresholdRsrq
NRDCDPR
0 to 15 dB
2 dB
Empty
b1TimeToTriggerRsrp
NRDCDPR
0 to 1520 ms
256 ms
256 ms, see also
below
b1TimeToTriggerRsrq
NRDCDPR
0 to 1520 ms
256 ms
Empty
dataVolThreshold
NRDCDPR
Bit pattern
1024
---
Table 24: Parameters to control measurement-based SgNB addition
The two main parameters to be tuned are the RSRP threshold and the time-to-trigger.
b1ThresholdNrRsrp:
28-Jan-2020 ULITPALIL5R3-1390467857-6948
55 / 178
Internal
© 2020 Nokia
Too high RSRP threshold means that potential 5G radio connections will not be attempted to be set up; this
will reduce the end-user throughput and prevent the off-loading from 4G to 5G. Too low RSRP threshold
means the UE will report a 5G cell which has so bad radio link that either the RACH procedure cannot be
completed, or the connection will quickly drop.
The following points need to be considered when deciding the value of the b1ThresholdNrRsrp:
•
The 5G bandwidth relative to the aggregated 4G bandwidth: If 5G bandwidth is large, for example
100 MHz, even poor 5G radio link conditions can give significant improvements in the combined
4G/5G end-user throughput. On the other hand, if the 5G bandwidth is perhaps only 10 MHz while
the aggregated LTE bandwidth is maybe 30 MHz, the throughput contribution from a poor 5G radio
link is only marginal. It can therefore be argued that b1ThresholdNrRsrp should be relatively high if
the 5G bandwidth is relatively small.
•
New 5G19A feature 5GC001954: Introduction of A2 based SgNB release allows to release a 5G
connection if the 5G RSRP drops below a certain threshold. The b1ThresholdNrRsrp must be set
higher than the A2 threshold in order to avoid a ping-pong effect between continuously establishing
and releasing the 5G radio connection.
•
If the 5G addition is attempted at too low RSRP values, there may be a series of failed 5G RACH
procedures. Not only does this mean that the 5G leg of the connection will not be established – it
is also possible that the LTE leg will suffer from reduced throughput. This effect is illustrated in Figure
14.
•
If the 5G addition is allowed to take place at low RSRP values, it is more likely that the 5G connection
will quickly drop. This can lead to worse values of the retainability KPIs but can potentially also mean
that the LTE throughput will suffer, for example if packets are dropped when the user plane
connection from the SGW is switched back to the eNB
•
The b1ThresholdNrRsrp is only related to the downlink signal strength, but a reasonable uplink
quality is also needed for the 5G RACH to succeed and to keep the 5G radio link. A suitable safety
margin should therefore be added to the b1ThresholdNrRsrp value.
If the objective is to maximise the time-on-5G, the threshold should be set relatively low. If the objective is
to maximise the end-user throughput, the threshold should be set so 5G is used when the 5G radio link is
good enough to give significant throughput improvement but at the same time prevent the use of 5G when
the 5G radio link is so bad that there is risk of continuous 5G RACH failures or 5G radio link drops and
therefore a risk of jeopardizing the LTE throughput. Field tests are probably necessary to determine the best
settings of b1ThresholdNrRsrp in a given network.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
56 / 178
Internal
© 2020 Nokia
Figure 14: Illustration of the danger with too low RSRP threshold for the SgNB addition. In this case, there is ongoing connection with
both 5G and 4G data transfer. When the 5G connection is broken due to low RSRP, the UE repeatedly tries to perform SgNB addition
and this results in unstable 4G throughput. The 4G throughput only stabilizes when 5G RSRP is so low that SgNB additions are no
longer attempted. Lab tests, 5G19.
Figure 15: Illustration of how increased B1 RSRP threshold (from -120 dBm to -116 dBm) lead to reduced RACH failure ratio and higher
combined 4G/5G application throughput without significantly reducing the time-on-5G. Cluster drive test, 5G19A, 600 MHz
28-Jan-2020 ULITPALIL5R3-1390467857-6948
57 / 178
Internal
© 2020 Nokia
Figure 16: Illustration of how reduced B1 RSRP threshold from -105 dBm to -116 dBm lead to increased 5G footprint. Cluster drive test,
5G19, 2.6 GHz
b1TimeToTriggerRsrp:
If the time-to-trigger is set too high, the control plane latency (the time to establish the 5G radio connection)
may be unacceptably high. If the time-to-trigger is set too low, it increases the risk that a SgNB addition is
done even though the 5G radio link is not good enough. Low control plane latency is important not just for
the initial set up of the connection but also as a workaround in case 5G handover is not enabled, and a
release followed by a quick establishment on another sector is the alternative.
Furthermore, if it is desired to use 4G carrier aggregation together with 5G to maximise the end-user
throughput (feature LTE4575: Blind Carrier Aggregation with LTE-NR DC Option 3X), the 4G carrier
aggregation must have taken place before the SgNB addition. Increasing the time-to-trigger is one way to
achieve this (another way is to either speed up the 4G carrier aggregation or use the “CRL30195 feature” to
ignore the B1 measurements until the LTE carrier aggregation has been completed, see the throughput
optimization discussion in chapter 9).
If the “CRL30195 feature” is used, it should be noted that it has been observed in LTE19A that the LTE4575
blind carrier aggregation does not happen if there is only a small amount of downlink data to be sent (when
doing FTP upload, when doing small pings or opening a small webpage like Google.com), and since LTE
carrier aggregation does not happen, the SgNB addition also does not happen, even though the UE sends
B1 measurement reports. This problem will be fixed in a future release.
Finally, the new 5G19A / LTE19A features for multiple 5G bearers per UE (see the feature list in Table 23)
require that all the bearers have been set up before the SgNB addition happens. A large value of the timeto-trigger helps in ensuring that this condition is met. The LTE5510: Stepwise addition of multiple bearers for
EN-DC feature (LTE19B) allows to add additional bearers after the SgNB addition has happened for the first
bearer.
b1TimeToTriggerRsrp
640 ms
320 ms
80 ms
5G SCG addition time (ms)
820 ms
460 ms
320 ms
28-Jan-2020 ULITPALIL5R3-1390467857-6948
58 / 178
Internal
© 2020 Nokia
Table 25: Average 5G SCG addition time with different b1TimeToTriggerRsrp settings. Scenario is that 5G handover is not enabled, the
5G connection has just dropped in one 5G sector and is then established again in a neighbor sector. The 4G connection is kept , so
waiting for LTE carrier aggregation etc. is not needed when setting up the 5G connection again. Cluster drive test, LTE19A / 5G19A,
600 MHz.
dataVolThreshold:
This parameter was originally introduced to provide a triggering mechanism for 5G Scell Addition based
upon data volume. This functionality is now planned for LTE20A (LTE5003: Data buffer trigger for EN-DC)
and the parameter is instead used as a bitmap to control multiple other functionalities.
Bit 0 decides if measurement gaps are configured to allow the UE to do B1 measurements. If measurement
gaps are enabled, the UE will use 6 ms every 40 ms to do the measurements. Furthermore, the last 4 ms
before a measurement cannot be used by the scheduler, so the effective LTE throughput penalty is 10 / 40
= 25%.
This impact is relatively small for UE within 5G coverage because the gaps are only active for about 1 second.
On the other hand, the impact is significant for UE outside 5G coverage because the gaps are then
continuous.
Figure 14 shows one example of the impact of measurement gaps: On the left side, where there is good 5G
RSRP and an ongoing 5G radio connection, the UE does not do B1 measurements. LTE throughput is
something like 50 Mbps during this time. On the far right side, where 5G RSRP is so low that SgNB addition
is not attempted, the UE is doing B1 measurements. LTE throughput is something like 40 Mbps during this
time. This means that the measurement gaps give a reduction of ~20 % in the LTE throughput, which is
close to the expectations (10 / 40 = 25%).
Another example is shown in Figure 17 where FTP download was used to quantify the effect of measurement
gaps on the LTE throughput.
Figure 17: Effect of measurement gaps on LTE throughput. Enabling measurement gaps reduces the LTE throughput by 25%. Carrier
Aggregation across L800/L1800/L2100. Stationary field trial in good radio conditions. LTE19A.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
59 / 178
Internal
© 2020 Nokia
Experience so far has shown that at least the Samsung S10 and the Xiaomi MIX 3 do not need such
measurement gaps and the measurement gaps can therefore be disabled to avoid the impact on 4G
throughput. However, in a given network it should either be confirmed that none of the UEs in the market
require measurement gaps, or the bit 0 should be kept at “0” to make sure that measurement gaps are
configured.
The success ratio of step D can be judged by comparing the number of successfully established E-RABs
with the number of SgNB addition requests as depicted in Table 26.
KPI id
KPI name
KPI formula
LTE_xxx
Share of EN-DC E-RABs which result in SgNB
addition request
SCG_ADD_PREP_ATT /
ERAB_STP_SUCC_MCG_NR_PDCP
Table 26: KPI to monitor the success ratio of step D
5.5
Step E: SgNB addition
Almost all the actions of this step take place inside the gNB. Neither the 4G nor the 5G radio interface is
involved at all, so very high success ratios are expected. The detailed steps are as follows:
1.
eNB sends SgNB addition request on X2 interface
2. gNB receives SgNB addition request on X2 interface
3. gNB-CU makes Admission Control for CU
4. gNB-CU sends UE context setup request on F1
5. gNB-DU receives UE context setup request on F1
6. gNB-DU makes Admission Control for DU
7. gNB-DU sets up the UE context
8. gNB-DU confirms to CU (via F1 interface) that the UE context has been set up
9. gNB-CU receives confirmation on F1 interface that the UE context has been set up
10. gNB-CU confirms to eNB (via X2 interface) that the SgNB addition has been done
11. eNB receives confirmation on X2 interface that the SgNB addition has been done
There are counters and KPIs available to follow each step. These are listed in Table 27 and Table 28.
Counter id
Counter name
Step
M8080C0
SCG_ADD_PREP_ATT
1
M55110C00034
X2_SGNB_ADD_REQ_REC
2
M55114C00001
SGNB_NSA_ADMISSION_REQ
3
M55114C00002
SGNB_NSA_ADMISSION_SUCC
3
M55114C00003
SGNB_NSA_NGBR_DRB_REQ
3
M55114C00004
SGNB_NSA_NGBR_DRB_SUCC
3
28-Jan-2020 ULITPALIL5R3-1390467857-6948
60 / 178
Internal
© 2020 Nokia
Counter id
Counter name
Step
M55114C00005
SGNB_NSA_RAC_REJ_DUE_TO_CPUE
3
M55114C00006
SGNB_NSA_RAC_REJ_DUE_TO_NSA
3
M55114C00007
SGNB_NSA_RAC_REJ_DUE_TO_NGBR
3
M55113C01001
NF1CC_UECTXT_STP_REQSENT
4
M55117C01001
NF1CD_UECTXT_STP_REQRECD
5
M55115C00002
SGNB_DU_NSA_ADMISSION_REQ
6
M55115C00003
SGNB_DU_NSA_ADMISSION_SUCC
6
M55115C00004
SGNB_DU_NSA_ADMISSION_UNSUCC
6
M55115C00005
SGNB_DU_NSA_ADMISSION_NO_PUCCH
6
M55117C01002
NF1CD_UECTXT_STP_RESPSENT
8
M55117C01003
NF1CD_UECTXT_STP_QCINOTSUPP
8
M55117C01004
NF1CD_UECTXT_STP_IPNOTSUPP
8
M55117C01005
NF1CD_UECTXT_STP_FAILMISC
8
M55113C01002
NF1CC_UECTXT_STP_RESPRECD
9
M55113C01003
NF1CC_UECTXT_STP_QCINOTSUPP
9
M55113C01004
NF1CC_UECTXT_STP_IPNOTSUPP
9
M55113C01005
NF1CC_UECTXT_STP_FAILMISC
9
M55112C00002
X2_SGNB_ADD_REQ_ACK_SENT
10
M55112C00010
X2_SGNB_ADD_REQ_REJ_SENT
10
M55112C01002
NX2CC_BEARER_FAIL_TYP_NOT_SUPP
10
M55112C01003
NX2CC_BEARER_FAIL_SEC_NOT_SUPP
10
M55112C01004
NX2CC_BEARER_FAIL_QCI_NOT_SUPP
10
M55112C01005
NX2CC_BEARER_FAIL_IP_NOT_SUPP
10
M55112C01006
NX2CC_BEARER_FAIL_MISC
10
M55112C01501
X2_SGNB_REQ_REJ_MISSING_UE_CAP
10
M8080C1
SCG_ADD_PREP_FAIL_SGNB
11
M8080C2
SCG_ADD_PREP_FAIL_T
11
M8080C3
SCG_ADD_PREP_SUCC
11
Table 27: Counters to monitor the progress of the SgNB addition
28-Jan-2020 ULITPALIL5R3-1390467857-6948
61 / 178
Internal
© 2020 Nokia
KPI id
KPI name
KPI formula
Step(s)
NR_5014a
5G Radio admission
success ratio for NSA
user
sgnb_nsa_admission_succ /
sgnb_nsa_admission_req
3
NR_454a
5G Radio admission
success ratio for NSA
user per DU (SgNB
Addition)
sgnb_du_nsa_admission_succ /
sgnb_du_nsa_admission_req
6
NR_189a
5G UE context setup
success ratio per DU
nf1cd_uectxt_stp_respsent /
nf1cd_uectxt_stp_reqrecd
5 to 8
NR_5009a
5G UE context setup
success ratio
nf1cc_uectxt_stp_resprecd /
4 to 9
5G SgNB addition
preparation success
ratio
x2_sgnb_add_req_ack_sent /
E-UTRAN SgNB
Addition Preparation
Success Ratio per SCG
split bearer
scg_add_prep_succ / scg_add_prep_att
NR_5004b
LTE_6631a
nf1cc_uectxt_stp_reqsent
2 to 10
(x2_sgnb_add_req_ack_sent +
x2_sgnb_add_req_rej_sent)
1 to 11
Table 28: Main KPIs which cover the SgNB addition procedure. More detailed KPI formula exist which cover the various failure causes.
Most of these steps are not relevant for optimization activities – only the Admission Control procedure
might be of interest. The reasons that Admission Control may reject a connection and possible mitigation
actions are discussed in the capacity management chapter (chapter 8).
5.6
Step F: RRC reconfiguration
After the eNB has received the SgNB Addition Request Acknowledge message on X2 (containing
information to UE about the 5G radio configuration), the eNB forwards this information to UE (in RRC
Connection Reconfiguration message), waits for acknowledgement and then forwards the acknowledgment
to the gNB:
28-Jan-2020 ULITPALIL5R3-1390467857-6948
62 / 178
Internal
© 2020 Nokia
Figure 18: RRC reconfiguration procedure
The most critical part of this procedure is the communication between the UE and the eNB over the 4G
radio interface. Guard timers are running on both 4G (rrcGuardTimer) and 5G (tDCoverall) sides, and the
values of these timers should be aligned.
Parameter
Object
Range
Default
Recommended
rrcGuardTimer
LNBTS
100...30000 ms
2000 ms
2000 ms
tDCoverall
NRBTS
100...5000 ms
2000 ms
Same as
rrcGuardTimer
Table 29: Parameters related to RRC reconfiguration procedure
KPi id
KPI name
KPI formula
NR_5005a
5G SgNB reconfiguration success ratio
X2_SGNB_RECONF_ACK_RECEIVED
/ (X2_SGNB_RECONF_RECEIVED +
X2_SGNB_RECONF_T)
LTE_6633a
E-UTRAN SgNB Addition DRB Establishment
Success Ratio per SCG split bearer
DRB_SCG_ADD_SUCC /
DRB_SCG_ADD_ATT
Table 30: KPIs related to RRC reconfiguration procedure
5.7
Step G: Switching user plane to gNB
In this step, the eNB informs the gNB about the exact place in the PDCP data stream where gNB takes
responsibility (the Sequence Number is transferred) and the eNB informs the EPC that the user plane
connection between RAN and EPC should be switched from eNB to gNB. There are no relevant optimization
actions during this step except monitoring the performance.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
63 / 178
Internal
© 2020 Nokia
KPi id
KPI name
KPI formula
NR_5016a
5G Status Transfer received ratio during
SgNB addition
X2_SN_STATUS_TRANSFER_RECEIVED /
E-UTRAN SgNB Addition Completion
Success Ratio per SCG split bearer
SCG_ADD_COMPLETION_SUCC /
SCG_ADD_COMPLETION_ATT
LTE_6637b
(X2_SN_STATUS_TRANSFER_RECEIVED +
X2_SN_STATUS_TRANSFER_T)
Table 31: KPIs for monitoring the user plane switch to gNB
5.8
Step H: 5G RACH procedure
The RACH procedure is initiated by the RRC Reconfiguration procedure described in step F, but this is not
the only RACH scenario. Handover and other procedures are also using the RACH procedure to establish
or re-establish the radio connection.
In 5G19A, there is the choice between using the legacy 5G19 contention-based RACH procedure or using
the new 5G19A 5GC001874: Non contention based random access procedure (contention-free RACH
procedure based on dedicated preambles). Figure 19 illustrates the differences between the two options.
Figure 19: Signaling flow for contention-free and contention-based RACH for NSA deployment
The contention-free procedure is preferred because this is faster and more reliable. There is no activation
flag for the contention-free feature, but it can be controlled by defining how many preambles that are
dedicated for contention-free access. If dedicated preambles are not available, contention-based RACH will
be done.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
64 / 178
Internal
© 2020 Nokia
Generally, the success ratio of the RACH procedure is impacted by the radio link quality, the RSI (Root
Sequence Indicator) planning and the RACH parameter settings. In practice, also the UE implementation
has been seen to have impact. The process to ensure good uplink and downlink radio link quality is
discussed in chapter 4. The process to evaluate the RSI planning is briefly described in section 3.4.2.2. The
specific RACH performance analysis is described below.
The main RACH parameters are listed in Table 32.
Parameter
Object
Range
Default
b1ThresholdNrRsrp
NRDCDPR
-156...-29
dBm
b1TimeToTriggerRsrp
NRDCDPR
0 to 5120
ms
256 ms
256 ms
zeroCorrelationZoneConfig
NRCELL
0...15, step 1
13
Planning value
prachRootSequenceIndex
NRCELL
0...837, step
1
0
Planning value
prachConfigurationIndex
NRCELL
0...255, step
1
0
Planning value
totalNumberOfRAPreambles
NRCELL
1..64
64
64
cbraPreamblesPerSsb
NRCELL
4..64
64
64
msg1FrequencyStart
NRCELL
0...36, step 1
0
Planning value
initialPreambleReceivedTargetPower
NRCELL
-200...-74,
step 2 dBm
-104 dBm
-104 dBm
powerRampingStep
NRCELL
0, 2, 4, 6 dB
2 dB
2 dB
preambleTransMax
NRCELL
3, 4, 5, 6, 7,
8, 10, 20, 50,
100, 200
10
10
pfaTargetPRACH (hidden parameter in
“vendor” file)
NRBTS
1%, 0.1%,
0.05%,
0.01%
0.05%
0.05%
See discussion in
section 5.4
prachTresholdOffsetDb (R&D
parameter in “swconfig” file)
raContentionResolutionTmr
28-Jan-2020 ULITPALIL5R3-1390467857-6948
65 / 178
Recommended
2 dB
NRCELL
Internal
Sf8..sf64
Sf64
Sf64
© 2020 Nokia
Parameter
Object
Range
raResponseWindow
NRCELL
Sl10..sl80
Default
Recommended
FR1: sl20
FR2: sl80
maxHarqMsg3Tx
NRCELLGRP
1..8
5
5
Table 32: Main RACH performance parameters
Possible Optimization actions:
•
Increase the b1ThresholdNrRSRP and/or the b1TimeToTriggerRsrp parameters. A stronger and more
stable 5G RSRP level makes it more likely that the RACH procedure will succeed. This will also help
on the retainability KPI but will reduce the area of the network where 5G is used
•
Use combination of msg1FrequencyStart and prachConfigurationIndex to separate the PRACH in the
frequency domain (msg1FrequencyStart) and in the time domain (prachConfigurationIndex), at least
for cells belonging to the same gNB.
•
Tune pfaTargetPRACH and prachTresholdOffsetDb parameters in such a way that the probability of
receiving a preamble sent from a UE in the cell is maximized but at the same time, the risk of
receiving a “ghost” preamble (either noise-generated or from a UE in another cell) is minimized.
Note that any improvement is probably only related to the counter-based KPI value. Real users
(such as a drive test tool) will probably not see any impact. There is not yet extensive experience
with the best settings.
The relevant KPI formulas are listed in Table 33.
KPI id
KPI name
KPI formula
Comment
NR_5013a
5G
Contention
based RACH
setup success
ratio
RA_MSG3_RECEP /
Not the perfect formula
because ghost preambles will
normally cause this formula to
show bad values. Also not
possible to distinguish between
SgNB additions and handovers
NR_xxx
RA_ATT_CONT_A_PRMBL_SSB_00..63
RA_MSG3_RECEP /
X2_SGNB_ADD_REQ_ACK_SENT
28-Jan-2020 ULITPALIL5R3-1390467857-6948
66 / 178
Internal
RA_MSG3_RECEP includes
handover but
X2_SGNB_ADD_REQ_ACK_SENT
does not. This means the
formula is only useful in a
network where the amount of
handover is small compared to
© 2020 Nokia
KPI id
KPI name
KPI formula
Comment
the number of SgNB addition
requests
NR_5011a
5G
Contention
free RACH
setup success
ratio
RA_COMP_DED_PRMBL /
RA_ATT_DED_PRMBL_SSB_00 ..63
Table 33: KPIs to monitor 5G RACH performance
Table 34: Example of how increasing the b1ThresholdNrRSRP lead to better RACH success ratio. Cluster drive test, 600 MHz, 5G19A
Figure 20: Example of the impact PRACH frequency diversity obtained via msg1FrequencyStart (changing from same
msg1FrequencyStart in all cells to different values in each cell within a gNB). 3.5 GHz, 5G19
28-Jan-2020 ULITPALIL5R3-1390467857-6948
67 / 178
Internal
© 2020 Nokia
Figure 21: Example on how the PRACH success ratio has improved by tuning the BTS thresholds for distinguishing between ghost
preambles and real preambles. 3.5 GHz, 5G19. Note that the improvement only happens in the counter-based KPI value. End-users
will probably not see any difference.
5.9
E2E KPI formulas
Ideally, the number of started connection attempts in the 4G BTS should be compared with the number of
successfully ended RACH procedures in the 5G BTS. This is straightforward as long as there is a 1-to-1
relation between 4G BTS and 5G BTS, but in practice, the 4G-5G neighbour relations often form a n-to-m
mesh network (illustrated in Figure 22). Since the counters are per BTS and not per adjacency, it is therefore
difficult to construct a KPI formula which spans both 4G and 5G activities. Instead, separate 4G and 5G
formulas are listed in Table 35.
Figure 22: Illustration of 4G-5G neighbour mesh network. EN-DC connections with eNB-25 as anchor BTS are scattered among 5
different gNBs – but the number of users in those 5 gNBs cannot simply be summarized and compared with eNB-25 because each
gNB is also connected to other eNBs
28-Jan-2020 ULITPALIL5R3-1390467857-6948
68 / 178
Internal
© 2020 Nokia
KPI id
KPI name
KPI formula
Comment
LTE_6984a
E-UTRAN Total
SgNB Addition
Success Ratio per
SCG split bearer
SCG_ADD_COMPLETION_SUCC /
SCG_ADD_PREP_ATT
From eNB sends SgNB
Addition Request (i.e. the
UE has reported strong
enough 5G signal) until the
EPC has switched the user
plane to gNB
NR_5020c
5G NSA call
accessibility, 5G
side
X2_SGNB_RECONF_ACK_RECEIVED /
(X2_SGNB_ADD_REQ_ACK_SENT +
X2_SGNB_ADD_REQ_REJ_SENT)
From gNB receives SgNB
Addition Request until the
gNB has received the
SgNB Reconfiguration
Complete message (i.e.
before 5G RACH
procedure has been
completed)
Table 35: KPIs to monitor E2E accessibility
28-Jan-2020 ULITPALIL5R3-1390467857-6948
69 / 178
Internal
© 2020 Nokia
6
Optimization of retainability
The retainability (i.e. the ability to retain a connection until it is normally ended) is one of the most used
metrics used to assess network performance. However, it can easily be argued that as long as there are only
data calls (non-voice calls) in the network, metrics such as the throughput are more important.
In fact, abnormally terminated connections are not necessarily bad: A fast drop followed by a fast reestablishment also gives good end-user throughput performance. Especially if handover is not enabled in
the network, it may be better to quickly drop a bad connection and hope the re-establishment happens on
a better cell. Also, from capacity perspective, it can be argued that bad 5G radio links should be released
so the 5G resources are mainly used by UEs in good radio conditions (which can then use higher MCS and
MIMO rank). Such early releases can be achieved either by using the A2 release criteria or by tuning the
radio link failure parameters such that radio link failures are more likely to happen.
Figure 23: Example of application throughput improvement by deliberately increasing the drop ratio. By changing from default RLF
settings (t310 = 2000 ms, n310 = n10) to more aggressive settings (t310 = 1000 ms, n310 = n6), the 5G radio link is more likely to be
released in bad radio conditions (RLF ratio went from 8.2% to 14.2%) and the average application throughput is therefore higher.
Cluster drive test, FTP download, 600 MHz, 5G19A.
Nevertheless, most operators are regarding the retainability as one of their most important performance
indicators.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
70 / 178
Internal
© 2020 Nokia
As for the accessibility, the situation must be viewed from both the eNB and from the gNB perspective, and
both network elements can initiate the release of the 5G radio connection.
•
•
gNB release scenarios:
o
UE inactivity (this is viewed as normal release)
o
A2 release (5G RSRP becomes bad)
o
SgNB-detected 5G radio link failure
o
UE-detected 5G radio link failure (communicated via eNB via RRC connection)
o
Abnormal reasons (PDCP Count Rollover or GTP-U Error)
o
gNB reset / partial reset
o
Possibly other scenarios
eNB release scenarios
o
Normal release (inactivity, release of the call, detach)
o
eNB reset / partial reset
o
4G radio link failure
o
4G handover (if EN-DC handover is not supported)
o
Possibly other scenarios
In the following subsections, each release scenario is first explained individually, and the final subsection
discusses the overall KPI formulas.
The share of 5G releases due to radio link failures is depending on the B1 threshold for establishing 5G radio
links. If a low B1 threshold is selected, such that SgNB additions are attempted in very bad 5G RSRP areas,
there is naturally a higher risk that the 5G radio link will soon be terminated due to radio link failure.
From counter perspective, the 5G radio connection is seen as established when the gNB has received the
SgNB Reconfiguration Complete message from the eNB. Note that this message comes before the 5G RACH
procedure has been completed, i.e. a failure in the RACH procedure is regarded as a dropped call rather
than a failed call establishment.
6.1
Release initiated by gNB due to UE 5G inactivity
The SgNB will treat the UE as inactive if there is no 5G data received or transmitted and if there is no data
in the buffer for a given time period. When the inactivity timer expires in the SgNB, it sends SgNB Release
Required message to the MeNB with the cause value User Inactivity. The MeNB acknowledges this message
with a SgNB Release Confirm and proceeds with a UE Context Release command to the gNB which then
releases the 5G connection.
The value of the inactivity timer is a compromise between releasing the connection quickly and thereby
using less resources from admission control perspective (especially PUCCH capacity) and less UE battery
power and keeping the connection longer and thereby avoid the need for doing another SgNB addition if
more packets are arriving.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
71 / 178
Internal
© 2020 Nokia
The inactivity timer value also impacts the value of many of the drop ratio formulas. With a long inactivity
timer, it is more likely that the radio connection will drop before the connection is released due to inactivity;
if the timer is decreased, there is higher chance that it will be released instead of dropping. For the enduser, it doesn’t matter if an idle connection is released due to inactivity or due to radio link failure but the
KPI formula values for retainability will be impacted.
Parameter
Object
Range
Default
actInactDetNSAUe
NRBTS
False
(0), False (0)
True (1)
True (1)
nsaInactivityTimer
NRBTS
1..7200
seconds
10 seconds
10 seconds
Recommended
Table 36: Parameters related to 5G inactivity detection
Counter id
Counter name
Comment
M8080C7
SCG_TOT_REL_INIT_SGNB
Total releases, eNB perspective
M8080C9
SCG_TOT_REL_INIT_MENB
M55112C00005
X2_SGNB_REL_REQ_RECEIVED
M55112C00007
X2_SGNB_REL_REQUIRED_SENT
M8080C6
SCG_NOR_REL_INIT_SGNB_INACT
M55112C02001
SGNB_RELEASE_REQ_UE_INACT
Total releases, gNB perspective
Releases due to 5G inactivity,
eNB and gNB perspective
Table 37: Counters related to 5G inactivity releases
6.2
Release initiated by gNB due to A2 measurement report
Feature id
Feature name
5GC001954
Introduction of A2 based SgNB release
In 5G19A, the 5GC001954: Introduction of A2 based SgNB release feature makes it possible to release the 5G
radio link when the 5G RSRP becomes lower than a certain threshold. The advantages of releasing the 5G
radio link when RSRP is bad include:
•
If 5G/5G handovers are not supported, it may be better to release a bad 5G radio link and hope
there is already a neighbour cell with better link available
28-Jan-2020 ULITPALIL5R3-1390467857-6948
72 / 178
Internal
© 2020 Nokia
•
If 5G link is bad, there will be RLC retransmissions (so packet delays) and this can lead to delayed
TCP acks and therefore reduced TCP throughput, so it may be better to release the 5G link and rely
on a good LTE performance
•
Retainability KPIs get better-looking values
The 5GC001954 only introduces the A2 release functionality. Full implementation (including proper
parameters and PM counters) comes with 5GC002177: A2 based SgNB release in 5G19B. Limitations in
5GC001954 includes:
•
No PM counters
•
Only RSRP-based A2 measurement is supported
•
No own parameters. The A2 threshold relies on an offset in dB added to the RSRP Threshold1 of A5
•
The operator does not have the possibility to configure the A2 offset nor to activate/deactivate the
A2 based SgNB release functionality
•
Since the A2 threshold results from a fixed offset applied to A5 threshold1, modifying A5 threshold1
will also modify the A2 threshold. If needed, the gNB may be configured to only use an A3
measurement for mobility purposes, and the A5 threshold1 may then freely be modified by the
operator in order to tune the A2 threshold without impact to mobility measurements.
Parameter
Object
Range
Default
Recommended
A5MeasEnabled
NRCELL
None,
RSRP,
RSRQ,
combinations
None
None
a5Threshold1SsbRsrp
NRCELL
0..127
A2ReleaseOffset
R&D parameter
-127 ...127
a5HysteresisSsbRsrp
NRCELL
0…30
a5TimeToTriggerSsbRsrp
NRCELL
Numerous values
See notes below
-5 dB
-5 dB
Table 38: 5G19A parameters related to A2 release
When selecting the desired A2 threshold, the following factors need to be taken into account:
•
Is there interference? If yes, then the RSRP thresholds need to be modified
•
How is the DL / UL link balance? The DL RSRP threshold may need to be offset to compensate for
a bad UL
•
If 5G has large bandwidth and LTE is heavily congested, it can be better to keep 5G even if there
are some delays in the TCP packets. On the other hand, if 5G has small bandwidth and LTE is used
for the majority of the data transfer, it is probably better to release 5G quickly to avoid that the LTE
part of the connection starts to suffer from TCP problems
28-Jan-2020 ULITPALIL5R3-1390467857-6948
73 / 178
Internal
© 2020 Nokia
•
A2 release threshold must be aligned with B1 establishment threshold, such that “ping-pong”
establishments/releases are avoided
Above points mean that different networks and perhaps even different cells within a network should select
different values of the A2 threshold. In the few networks where this feature is used, the A2 threshold is
roughly in the -105 dBm to -110 dBm range.
In 5G19A, an A2 release will only increment the counter for total number of SgNB-initiated releases. An
indirect way of monitoring the impact of A2 releases is that the counter for “lost UEs” will be reduced (since
a call in marginal radio conditions will be released via A2 measurements rather than dropping).
Counter id
Counter name
Comments
M55112C00007
X2_SGNB_REL_REQUIRED_SENT
Will be incremented by all SgNB-initiated
releases, incl. A2 release
M55112C00502
SGNB_REL_SN_REQ_UE_LOST
Will not be incremented by A2 release. Since
the alternative to A2 release is often a
dropped connection, it can be expected that
this counter will decrease when A2 release is
enabled in the network
Table 39: Counters relevant to monitor when A2 release is enabled in the network
6.3
Release initiated by gNB due to SgNB-detected 5G radio link failure
The SgNB can detect radio link failure (RLF) if the PUCCH messages are not arriving as expected (either DL
HARQ feedback or CSI reports), or if the maximum number of RLC retransmissions has been reached.
When the SgNB detects RLF, a control timer is started, and during the waiting time, data could be switched
to LTE leg of the split bearer. After timer expiry, if radio link has not recovered, the SgNB will release the UE
context by sending an SgNB-initiated SgNB release with the cause value ‘Radio Connection with UE lost’ to
the MeNB. This means that:
•
Not all radio link failures cause the radio link to be terminated. This means that the PM counters
may show higher values than the actual drops
•
During the waiting time, additional RLF reasons may happen, including UE-detected radio link
failures. This means that one dropped connection may increment multiple different RLF counters
The underlying cause for these releases is bad radio link quality. The procedures for detecting and improving
the radio link quality are described in chapter 4. It is also possible to control with parameters how quickly
the gNB declares radio link failure – these parameters are listed in Table 40. In some network configurations
(for example if the 5G bandwidth is small compared to the aggregated LTE bandwidth) it is desirable to
quickly release a bad 5G radio link, in other configurations (for example if the LTE contribution to the
28-Jan-2020 ULITPALIL5R3-1390467857-6948
74 / 178
Internal
© 2020 Nokia
throughput is negligible due to congested LTE network or small LTE bandwidth) it is better to keep the 5G
connection as long as possible.
SgNB-detected radio link failures are not visible in drive test logs. BTS PM counters or BTS / interface traces
are needed for performance analysis.
Parameter
Object
Range
Default
Recommended
75 (5G19A MP0.1)
0
(see
below)
actGnbInitRlf
rdRlpDetCsiBsi
R&D parameter
0 (5G19A MP1.0)
tRLFindForDU
NRBTS
300 ms to 3000 ms 300 ms (0)
2000 ms (8)
tWaitingRlRecover
NRBTS
0 ms to 60000 ms
500 ms (3)
500 ms (3)
maxRetxThreshold
NRBTS
1..32
16
32
notes
Table 40: Parameters to control how quickly the gNB declares radio link failure
In 5G19A, the scheduler can reduce the PUSCH allocation down to 3 PRBs if the uplink radio link quality is
bad. This makes the PUSCH link more robust than the PUCCH format 2 radio link, and there is therefore a
risk that the SgNB will unnecessarily declare radio link failure due to missing PUCCH messages.
It is therefore recommended to disable RLF due to missing CSI reports by setting R&D parameter
rdRlpDetCsiBsi to zero. RLF due to missing HARQ Ack /Nack will still be enabled but this is not a problem
since these messages use the more robust PUCCH format 0.
Counter id
Counter name
Comment
M8080C7
SCG_TOT_REL_INIT_SGNB
Total releases, eNB perspective
M8080C9
SCG_TOT_REL_INIT_MENB
M55112C00005
X2_SGNB_REL_REQ_RECEIVED
M55112C00007
X2_SGNB_REL_REQUIRED_SENT
M55112C00502
SGNB_REL_SN_REQ_UE_LOST
Includes both SgNB-detected
and UE-detected RLFs
M55116C00004
RLF_INITIATED_RNL
M55113C01006
NF1CC_UECTXT_MOD_REQRECD
Radio link failures detected by
gNB. Note that these do not
necessarily lead to release of the
connection. Note that same
connection may trigger both
counters. M55116C00004:
PUCCH failures.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
75 / 178
Internal
Total releases, gNB perspective
© 2020 Nokia
Counter id
Counter name
Comment
M55113C01006: Max RLC retrans
exceeded
Table 41: Counters related to SgNB-detected radio link failure
6.4
Release initiated by gNB due to UE-detected 5G radio link failure
If the UE detects that the 5G radio link appears to be broken, it informs the MeNB via SCG Failure Information
message, and the MeNB passes the information to the SgNB. The SgNB may try to recover the situation
with a PSCell change. If the PSCell change is successful, the radio connection will be resumed. If not, the
radio connection will be released.
The underlying cause for these releases is bad radio link quality. The procedures for detecting and improving
the downlink radio link quality are described in chapter 4. It is also possible to control with parameters how
quickly the UE declares radio link failure – these parameters are listed in Table 42. In some network
configurations (for example if the 5G bandwidth is small compared to the aggregated LTE bandwidth) it is
desirable to quickly release a bad 5G radio link, in other configurations (for example if the LTE contribution
to the throughput is negligible due to congested LTE network or small LTE bandwidth) it is better to keep
the 5G connection as long as possible. Figure 23 shows an example where fast detection of radio link failures
lead to worse retainability but better user throughput.
Parameter
Object
Range
Default
Recommended
T310
NRBTS
0 ms to 6000 ms
2000 ms
2000 ms
N310
NRBTS
1 to 20
10
10
N311
NRBTS
1 to 10
1
1
preambleTransMax
NRCELL
3 to 200
n10 (6)
n10 (6)
maxRetxThreshold
NRBTS
1 to 32
16
32
Table 42: Parameters to control how the UE detects radio link failure
Counter id
Counter name
Comment
M8080C7
SCG_TOT_REL_INIT_SGNB
Total releases, eNB perspective
M8080C9
SCG_TOT_REL_INIT_MENB
M55112C00005
X2_SGNB_REL_REQ_RECEIVED
M55112C00007
X2_SGNB_REL_REQUIRED_SENT
M55112C00502
SGNB_REL_SN_REQ_UE_LOST
28-Jan-2020 ULITPALIL5R3-1390467857-6948
76 / 178
Internal
Total releases, gNB perspective
Includes both SgNB-detected
and UE-detected RLFs
© 2020 Nokia
Counter id
Counter name
Comment
M55116C00008
RLF_INITIATED_UE_T310_EXPIRY
M55116C00010
RLF_INITIATED_UE_MAX_RLC_RETX
DL radio link failures, detected
by UE
M55116C00011
RLF_INITIATED_UE_SRB_INTGRTY_F
M55116C00009
RLF_INITIATED_UE_RACH_FAIL
M55116C00012
RLF_INITIATED_UE_SCG_CHGE_FAIL
RACH failures detected by UE
Table 43: Counters related to UE-detected 5G radio link failures
6.5
Release initiated by gNB due to abnormal reasons
In 5G19, the “abnormal” reasons can be one of the following two reasons
•
PDCP count rollover
•
GTP-U error
Neither of these reasons can be influenced by radio optimization and there are no parameters to control
this. In live networks, only a very small ratio of the connections (<0.01%) is released due to this scenario.
Counter id
Counter name
Comment
M8080C7
SCG_TOT_REL_INIT_SGNB
Total releases, eNB perspective
M8080C9
SCG_TOT_REL_INIT_MENB
M55112C00005
X2_SGNB_REL_REQ_RECEIVED
M55112C00007
X2_SGNB_REL_REQUIRED_SENT
M55112C01001
NX2CC_UE_RELEASE_ABNORMAL
Total releases, gNB perspective
Table 44: Counters related to downlink 5G abnormal releases
6.6
Release initiated by gNB due to other reasons
From PM counter analysis, it can be seen that a rather large part of the connections (15% in one network)
is requested to be released due to reasons not captured explicitly in the PM counters. X2 trace analysis can
be a first step in understanding what is happening, but this will not necessarily give an unambiguous answer
(one possible release cause is for example “Misc-unspecified”.
There is not yet a full understanding of the possible failure scenarios and therefore also not understanding
of what can be done to reduce these releases.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
77 / 178
Internal
© 2020 Nokia
6.7
Release initiated by eNB due to normal release
The eNB normal releases include the normally ended calls as well as the calls where both the 4G and the
5G inactivity counters are triggered. Also, the UE detach procedure is counted as a normal release.
Counter id
Counter name
Comment
M8080C7
SCG_TOT_REL_INIT_SGNB
Total releases, eNB perspective
M8080C9
SCG_TOT_REL_INIT_MENB
M55112C00005
X2_SGNB_REL_REQ_RECEIVED
M55112C00007
X2_SGNB_REL_REQUIRED_SENT
M8080C8
SCG_NOR_REL_INIT_MENB_NAS
Total releases, gNB perspective
Normal eNB release
Table 45: Counters related to normal eNB release
6.8
Release initiated by eNB due to 4G radio link failure
When the eNB releases the 4G connection due to a 4G radio link failure, it will also release the 5G radio link
connection. There are no specific counters for eNB releases due to 4G radio link failure, but the number of
abnormal eNB releases (also including for example releases due to 4G handover) can be calculated by
subtracting
the
normal
releases
(SCG_NOR_REL_INIT_MENB_NAS)
from
the
total
releases
(SCG_TOT_REL_INIT_MENB). There are no counters in the 5G BTS to distinguish between normal and
abnormal eNB-initiated releases.
6.9
Release initiated by eNB due to 4G handover
In 5G19, handover of EN-DC connections between 4G cells was not possible, so whenever the eNB executed
a 4G handover, it would also instruct the gNB to release the 5G connection. In 5G19A, the features
5GC000575: Intra-MeNB LTE handover without en-gNB change (NSA Option 3x) and LTE4281: Intra-eNB
handover for LTE-NR DC Option 3X enable intra-MeNB handovers but not yet inter-MeNB handovers.
There are no specific counters for eNB releases due to 4G handover, but the number of abnormal eNB
releases (also including for example 4G radio link failures) can be calculated by subtracting the normal
releases (SCG_NOR_REL_INIT_MENB_NAS) from the total releases (SCG_TOT_REL_INIT_MENB). There are
no counters in the 5G BTS to distinguish between normal and abnormal eNB-initiated releases.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
78 / 178
Internal
© 2020 Nokia
6.10
Releases due to gNB / eNB reset
When either the eNB or the gNB requests a reset or partially reset of the X2 connection (either due to
configuration changes or software crash), ongoing connections are also released.
Such releases can be minimized by limiting those configuration changes which require site reset to the low
traffic periods. In live networks, only a very small ratio of the connections is released due to this scenario.
Counter id
Counter name
Comment
M8080C7
SCG_TOT_REL_INIT_SGNB
Total releases, eNB perspective
M8080C9
SCG_TOT_REL_INIT_MENB
M55112C00005
X2_SGNB_REL_REQ_RECEIVED
M55112C00007
X2_SGNB_REL_REQUIRED_SENT
M55110C00019
X2_UEREL_INCOMING_RESET
M55110C00020
X2_UEREL_INCOMING_RESET
M55110C00027
X2_UEREL_INC_PARTIAL_RESET
M55110C00028
X2_UEREL_OUT_PARTIAL_RESET
Total releases, gNB perspective
Table 46: Counters related to releases caused by eNB / gNB reset
6.11
Performance indicators
Retainability KPI formulas are currently being revised. They will be included in a later version of the
document.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
79 / 178
Internal
© 2020 Nokia
7
Optimization of mobility
This chapter discusses how mobility impacts the performance and how features and parameter settings can
be used to ensure good performance even in the case of mobile users. Mobility is here understood in a
very broad context and the discussion is split into the following three scenarios:
-
Using the same SSB beam while moving, so channel estimates etc. become outdated
-
Switching between two SSB beams
-
Switching between sectors (handover)
7.1
Moving within the same SSB beam
Mobility within the same SSB beam can cause degraded performance due to:
•
Outdated channel estimate makes it difficult for the receiver to decode the signal
•
Fast moving UEs introduce a Doppler shift in the radio transmission
•
Varying radio conditions require the link adaptation algorithm to change the coding ratio
The outdated channel estimation case mainly covers the scenario where the channel estimation becomes
outdated because the UE has moved since the last channel estimate was done. In principle, a stationary UE
located near moving objects (e.g. cars) will also cause the channel estimate to be outdated, but this is
probably of less significance compared to moving the UE itself. In any case the end result will be the same:
Outdated channel estimate.
The effect of an outdated channel estimate is first of all that it will be difficult for the BTS and the UE to
correctly decode the transmitted data and secondly that the BTS cannot make timely decisions on how to
change of transmission methods, for example if another MCS should be taken into use.
This means that retransmissions are needed, or the radio link is not exploited to its maximum and this
ultimately leads to reduced end-user throughput. However, it is not straightforward to separate mobility
issues from all the other factors which can cause low throughput.
Figure 24 shows that it is possible from drive test measurement to see if there is an impact, because the
correlation with UE speed can be shown, but with most other data sources (e.g. PM counters), there is no
information about the UE speed, and the effects from mobility can therefore not be isolated. Even with drive
test measurements, the impact of moving surroundings cannot be quantified.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
80 / 178
Internal
© 2020 Nokia
Figure 24: Correlation between PDSCH throughput and UE speed. Movement introduces clear degradation in throughput. 3.5 GHz,
5G19, no additional DMRS symbol
Figure 24 shows the correlation between PDSCH throughput and UE speed in the case the 5G19A feature
5GC001347: Additional DMRS configuration is not enabled. It can be seen that the throughput degrades as
the UE moves faster, and it is expected that enabling the additional DMRS symbol will help. Figure 25 is
from another network where the additional DL DMRS symbol is used; in this case, the throughput is more
or less independent of the UE speed and this could be because the additional DMRS is in use. However, the
two charts cannot be directly compared due to the different carrier frequency, the different BTS release, the
different area etc. Still, it is expected that the additional DMRS will improve performance for mobile users,
so it is recommended to have it activated even though it also brings a penalty in terms of increased
overhead.
Figure 25: Correlation between PDSCH throughput and UE speed when additional DL DMRS symbol is used. There is no significant
degradation when the UE moves faster. 5G19A, 600 MHz, suburban area
28-Jan-2020 ULITPALIL5R3-1390467857-6948
81 / 178
Internal
© 2020 Nokia
The link adaptation algorithm is used to adapt the coding scheme to the changing radio conditions. If the
receiver cannot decode the signal due to outdated channel estimate, the link adaptation will compensate
by choosing a lower MCS with more robust coding of the signal. Likewise, the impact of the Doppler effect
caused by fast moving UEs or the movement of the UE into areas with worse RF coverage is handled by the
link adaptation algorithm. The speed and accuracy of the algorithm can be controlled by parameters.
Table 47 lists some of the relevant parameters which may be tuned for optimal handling of mobile UEs. The
recommended value is based on achieving best overall performance, not necessarily the best performance
for mobile users. It is therefore possible (and even likely) that specific cells with a large share of mobile users
can benefit from other settings. No systematic investigation of the best settings has been done yet.
The RF performance KPIs listed in chapter 4 can be used to evaluate the mobility performance, but it is not
straightforward to separate mobility issues from stationary issues using the PM counters.
Parameter name
Object
Range
Default
Recommended
csiReportPeriodicity
NRCELLGRP
20, 40, 80, 160,
320 slots
320 slots
320 slots
csirsTrackingPeriod
NRCELL
Off, equal to
ssBurstSetPeriod,
10 – 80 ms
80 ms
80 ms
ullaDeltaSinrMax
NRCELL
0...15, step 0.1
3
10
ullaDeltaSinrMin
NRCELL
-15...0, step 0.1
-3
-15
ullaDeltaSinrStepdown
NRCELL
0...1.000, step
0.001
0.25
0.25
dllaDeltaCqiMax
NRCELL
0...15, step 0.1
3
15
dllaDeltaCqiMin
NRCELL
-15...0, step 0.1
-3
-15
dllaDeltaCqiStepdown
NRCELL
0...1.000, step
0.001
0.25
0.25
ulDMRSAdditionalPosition
NRCELL
0, 1, 255
(automatic)
255
255, expect for
low-band FDD (0)
dlDMRSAdditionalPosition NRCELL
0, 1, 255
(automatic)
255
255, expect for
low-band FDD (0)
Table 47: Parameters which impact the performance during mobility
28-Jan-2020 ULITPALIL5R3-1390467857-6948
82 / 178
Internal
© 2020 Nokia
7.2
Beam switching
5G19A beamforming features use “Grid-of-Beams” which implies that when the UE moves across the cell, it
must continuously be assessed if a better beam is available and if needed execute a beam switch procedure.
In 5G19A, the UE will measure the RSRP of each SSB beam and report the best beam back to the gNB in
the Uplink Control Information. Beam switch will take place when the filtered RSRP of a new beam is larger
than the RSRP of the source beam by a certain threshold.
The beam switch procedure is done on Layer 2 by signalling a new Transmission Configuration Indicator
(TCI) state to the UE. The switch procedure is lossless by itself but if the beams are widely separated, the
area between them may have worse RF conditions and therefore a dip in throughput can occur.
The use of beams and the beam switching procedure can be monitored by the counters listed in Table 48.
So far, there are no experiences with optimizing the beam switch procedure.
Counter id
Counter name
Comments
M55305C03001..64
BEAM_CHANGE_0_0..7_7
M55305C04001..64
FAIL_BEAM_CHANGE_BIN1..64
M55305C05001..64
BEAM_CHANGE_TARGET_BIN1..64
M55305C06001..64
FAIL_BEAM_CHANGE_TARGET_BIN1..64
Attempts and failure counters for
beam changes. Full 8x8 mesh if 8
SSB beams or less, otherwise
separate counters for source and
target beams
M55305C07001..64
BEST_SECONDBEST_0_0..7_7
Best and second best beam
histogram – can be used to
understand which beams are
overlapping. Only if 8 or less SSB
beams are used
M55305C08001..16
RSRP_DIFF_SECOND_BEST_BIN1..16
RSRP difference between best and
second best beam. Can be used to
quantify beam overlap
M55305C11001..13
TIME_BEAM_BIN_1..13
Distribution of the time that the UEs
stays in the same beam. Can be
used to quantify UE mobility
M55305C13001
BEAM_TOGGLES
The number of beam toggles, i.e.
the when beam is changed back to
a beam which was used just before
this current serving beam
Table 48: Counters to monitor the beam switching procedure
28-Jan-2020 ULITPALIL5R3-1390467857-6948
83 / 178
Internal
© 2020 Nokia
7.3
NSA handover
Feature id
Feature name
Release
5GC000572
Intra-Frequency Inter-DU en-gNB mobility (NSA option 3x, Cloud gNB
5G19
5GC001094
Intra-Frequency Intra-DU en-gNB mobility (NSA option 3x)
5G19
LTE4530
Inter-SgNB Mobility for LTE-NR DC Option 3X
LTE19A
5GC000573
Intra-Frequency Inter en-gNB mobility (NSA option 3x)
5G19A
5GC000575
Intra-MeNB LTE handover without en-gNB change (NSA Option 3x)
5G19A
LTE4281
Intra-eNB handover for LTE-NR DC Option 3X
LTE19B
Table 49: Handover features in 5G19A and LTE19B
Handover scenario
5G feature
LTE feature
5G intra-SgNB
5GC000572, 5GC001094
N/A
5G inter-SgNB (intra-freq)
5GC000573
LTE4530
4G intra-MeNB
5GC000575
LTE4281
Table 50: Supported handover scenarios and needed 5G / LTE feature combinations
Table 49 lists the handover features which are available in 5G19A and LTE19B and Table 50 shows how these
features can be combined so various handover scenarios are possible. For example:
•
Drive around one 4G / 5G site: In this case there is a need to change both the 4G sector and the
5G sector but no need to change the eNB or the gNB. The eNB will – based on legacy LTE handover
parameters – decide when to change the 4G sector and the gNB will – based on 5G handover
parameters listed below – decide when to change the 5G sector. Either the 4G sector or the 5G
sector will be changed first depending on radio conditions and parameter values. The two sectors
will not be changed at exactly the same time
•
Drive from one 4G / 5G site to another 4G / 5G site: In this case there is a need to change both the
eNB and the gNB, and there are three options depending on the radio conditions and the
parameter settings:
o
5G SgNB is first changed. Then 4G MeNB is changed, but because EN-DC Inter-MeNB
handover is not yet supported, the 5G radio link will be released and a new 5G radio link
will have to be set up at the new eNB. The 4G connection is simply handed over
o
4G MeNB is first changed, but because EN-DC Inter-MeNB handover is not yet supported,
the 5G radio link will be released. The new 5G radio link will then (depending on radio
conditions) be set up on the old SgNB and subsequently handed over to the new SgNB, or
it will be set up directly on the new SgNB
28-Jan-2020 ULITPALIL5R3-1390467857-6948
84 / 178
Internal
© 2020 Nokia
Note that if a certain handover procedure is not supported and the 5G connection is therefore released
and established again, the control plane latency (the time to establish a new 5G radio bearer) becomes
important to minimize the impact to the user. See the discussion in chapter 11 for more details.
The optimization of the handover procedure consists of two steps
•
Ensure that the relevant neighbors are defined
•
Choose a good set of values for the handover parameters. The settings are a compromise between
partly conflicting objectives
o
Handover should not happen so late that degraded radio link quality reduces the
throughput or even leads to a dropped connection
o
There should not be more handovers than necessary in order to minimize the gaps in data
transfer during the handover
This spreadsheet has information about the expected data interruption time when doing handover.
Summarized numbers are presented in Table 51:
Approximate gap in data
transfer
Scenario
SRB3 in use?
Intra-DU
Yes
35 ms
No
40 ms
Yes
32 ms
No
37 ms
---
55 ms
Intra-gNB
Inter-gNB
Table 51: Expected duration of the data transfer interruptions when doing 5G-5G handover
Both 5G-5G neighbors and 4G-5G neighbors need to be defined. Co-sited neighbors should always be
defined – the need for additional tiers depend among other things on the used frequency bands for 4G
and 5G. The Neighbor Analysis Engineering Guideline describes how to select and define the needed
neighbors, incl. an introduction to the MUSA tool.
Once the neighbors have been defined, there are numerous parameters which control the decision to
change from one sector to another. Some of these parameters are common for all the neighbors, some
can be set individually for each neighbor. Roughly, the parameters can be grouped as:
1.
Instructions for converting beam-level measurements into cell-level measurements
2. Instructions for when the UE should start measurements and how to apply layer-3 filtering
3. Parameters related to A3 handover (“Neighbor becomes Offset better than Special Cell”)
28-Jan-2020 ULITPALIL5R3-1390467857-6948
85 / 178
Internal
© 2020 Nokia
4. Parameters related to A5 handover (“Special Cell becomes worse than threshold1 and neighbor
becomes better than threshold2”). Note that some of the A5 parameters are re-used in the
5GC001954: Introduction of A2 based SgNB release (see the discussion in section 6.2)
5. Individual offset for each defined neighbor cell
Table 52 lists the parameters related to 5G – 5G handovers. The handover procedure for the 4G part of the
EN-DC connection is controlled by legacy 4G parameters.
Group
Parameter
Object
Range
Default
Recommended
1
nroSsbToAverage
NRCELL
2...64, step 1
-
1
absThreshSsbRsrpConsolidation
NRCELL
0...127, step 1
-
1
absThreshSsbRsrqConsolidation
NRCELL
0...127, step 1
-
2
sMeasConfigSsbRsrp
NRCELL
0...127, step 1
-
-50 dBm (106)
2
filterCoeffSsbRsrp
NRCELL
Numerous values
fc4
fc4
2
filterCoeffSsbRsrq
NRCELL
Numerous values
fc4
fc4
3
a3MeasEnabled
NRCELL
0:none; 1:rsrp;
2:rsrq;
3:rsrpAndRsrq;
0:none
RSRP (1)
4:rsrpCombined;
5:rsrqCombined
3
a3OffsetSsbRsrp
NRCELL
-30...30, step 1
-
4 dB
3
a3OffsetSsbRsrq
NRCELL
-30...30, step 1
-
-
3
a3HysteresisSsbRsrp
NRCELL
0...30, step 1
-
0 dB
3
a3HysteresisSsbRsrq
NRCELL
0...30, step 1
-
-
3
a3TimeToTriggerSsbRsrp
NRCELL
Numerous values
-
256 ms
3
a3TimeToTriggerSsbRsrq
NRCELL
Numerous values
-
-
4
a5MeasEnabled
NRCELL
0:none; 1:rsrp;
2:rsrq;
3:rsrpAndRsrq;
0:none
None (0)
4:rsrpCombined;
5:rsrqCombined
4
a5Threshold1SsbRsrp
NRCELL
0...127, step 1
-
-
4
a5Threshold1SsbRsrq
NRCELL
0...127, step 1
-
-
4
a5Threshold2SsbRsrp
NRCELL
0...127, step 1
-
-
4
a5Threshold2SsbRsrq
NRCELL
0...127, step 1
-
-
4
a5HysteresisSsbRsrp
NRCELL
0...30, step 1
-
-
28-Jan-2020 ULITPALIL5R3-1390467857-6948
86 / 178
Internal
© 2020 Nokia
Group
Parameter
Object
Range
Default
Recommended
4
a5HysteresisSsbRsrq
NRCELL
0...30, step 1
-
-
4
a5TimeToTriggerSsbRsrp
NRCELL
Numerous values
-
-
4
a5TimeToTriggerSsbRsrq
NRCELL
Numerous values
-
-
5
cellIndividualSsbRsrpOffset
NRREL
-24 dB to 24 dB
0 dB
0 dB
5
cellIndividualSsbRsrqOffset
NRREL
-24 dB to 24 dB
0 dB
0 dB
Table 52: 5G parameters related to control of the handover procedure. The 4G EN-DC handovers are controlled by legacy 4G
parameters. Note that A5 parameters also partly control the A2 release procedure
The most important of the 4G and 5G EN-DC handover KPIs are listed in Table 53 and Table 54. In addition
to these, there are also more detailed KPIs available which pinpoints where the failure has happened. In
contrast to legacy LTE, there are not counters available per neighbor relation – trace tools are needed for
such detailed analysis. There is not yet much experience with using these KPIs.
When evaluating the performance with the KPIs listed in Table 53 and Table 54, it is important to understand
that it is only possible to follow if the handover is successful; it is not possible to evaluate if the handover is
started at the right time. This introduces a risk for sub-optimization: If for example the time-to-trigger
parameter is set to a large value, the probability that the neighbor cell is strong enough is high, and the
handover success ratio is high – but there is also a risk that the radio link quality degrades before the
handover is attempted, so the throughput decreases or even that the connection drops. Therefore, also the
throughput aspect as well as the retainability needs to be included when analyzing handover performance.
KPI id
KPI name
KPI formula
NR_5041b
5G Intra gNB intra frequency PSCell
change preparation success ratio
(INTRA_FR_PSCEL_CH_ATTEMPT +
INT_FR_PSCEL_CHA_ATT_SRB3) /
(INTRA_FR_PSCEL_CH_ATTEMPT +
INT_FR_PSCEL_CHA_ATT_SRB3 +
INTRA_FR_PSCEL_CH_FAI_RES_ALLO )
NR_5042b
5G Intra gNB intra frequency PSCell
change total success ratio
(INTRA_FR_PSCEL_CH_ATTEMPT +
INT_FR_PSCEL_CHA_ATT_SRB3 INTRA_FR_PSCEL_CH_FAI_TDC_EXP INTRA_FR_PSCEL_CH_FAI_MENB_REF )
/(INTRA_FR_PSCEL_CH_ATTEMPT +
INT_FR_PSCEL_CHA_ATT_SRB3 +
INTRA_FR_PSCEL_CH_FAI_RES_ALLO )
NR_5044b
5G Average duration of executed intra
gNB intra frequency PSCell changes
(INTRA_FR_PSCEL_CH_TOT_DURAT/10) /
(INTRA_FR_PSCEL_CH_ATTEMPT +
INT_FR_PSCEL_CHA_ATT_SRB3 INTRA_FR_PSCEL_CH_FAI_MENB_REF INTRA_FR_PSCEL_CH_FAI_TDC_EXP)
28-Jan-2020 ULITPALIL5R3-1390467857-6948
87 / 178
Internal
© 2020 Nokia
KPI id
KPI name
KPI formula
NR_5034a
5G Inter gNB handover success ratio
for NSA (source cell)
X2_SGNB_CHG_CONF_RECEIVED /
X2_SGNB_CHG_REQD_SENT)
NR_5074a
5G Inter gNB intra frequency PSCell
change total success ratio on target
gNB
X2_SGNB_RECONF_ACK_SN_CH_RCVD /
X2_SGNB_ADD_REQ_SN_CH_RCVD
NR_50a
5G Radio admission success ratio for
NSA user in handover
SGNB_NSA_HO_ADMISSION_SUCC /
SGNB_NSA_HO_ADMISSION_REQ
Table 53: Most relevant KPIs to monitor the 5G part of the EN-DC handover procedure. KPIs for failure reasons are also available
KPI id
KPI name
KPI formula
LTE_6826a
E-UTRAN Total SgNB Addition Success
Ratio due to successful SN Initiated
SgNB Change procedure
SGNB_ADD_CHANGE_COMPL_SUCC /
SGNB_CHANGE_CONF
LTE_6809a
E-UTRAN SgNB Modification for intraeNB HO Success Ratio
SGNB_MOD_SUCC_IA_HO /
SGNB_MOD_ATT_IA_HO
LTE_6817a
E-UTRAN Intra eNB Total HO Success
Ratio for EN-DC capable UEs with at
least one MCG NR-PDCP bearer
established
INTRA_ENB_HO_SUCC_MCG /
INTRA_ENB_HO_PREP_MCG
LTE_6822a
E-UTRAN Intra eNB Total HO Success
Ratio for EN-DC capable UEs with at
least one SCG NR-PDCP bearer
established
INTRA_ENB_HO_SUCC_SCG /
INTRA_ENB_HO_PREP_SCG
Table 54: Most relevant KPIs to monitor the 4G part of the EN-DC handover procedure. KPIs for failure reasons are also available
28-Jan-2020 ULITPALIL5R3-1390467857-6948
88 / 178
Internal
© 2020 Nokia
8
Capacity management
Capacity management consists of measuring the current capacity utilization and handle the areas where
there are capacity bottlenecks. The capacity areas which needs to be monitored include:
•
5G radio interface capacity
•
5G gNB processing capacity
•
5G admission control
•
LTE radio interface capacity (due to increased load from EN-DC connections)
•
LTE eNB processing capacity (due to increased load from EN-DC connections)
•
Interface capacity (X2, S1, F1)
The capacity utilization must be measured during the busy period. Naturally, different parts of the network
have different busy periods, for example day time in office areas versus evening time in entertainment areas.
Even within a specific area, it is possible there is a difference between uplink busy period and downlink busy
period. Such differences need to be taken into account when monitoring the capacity utilization.
Normally a time granularity of 15 minutes is enough to get valid results.
8.1
5G radio interface capacity
Ensuring that there is enough 5G radio interface means that both the signalling channels (PRACH, PDCCH,
PUCCH) and the data channels (PDSCH and PUSCH) need to be managed. The main optimization effort
with 5G19A features consists in achieving a good radio link quality, so high modulation and coding schemes
can be used. The RF optimization actions described in chapter 4 are therefore a necessary foundation for
managing the 5G radio interface capacity.
Obviously lack of PDSCH and PUSCH capacity can directly affect the offered throughput but capacity
problems on the signalling channels can also negatively impact the throughput because such congestion
can prevent the data channels from being fully utilized.
Spectral efficiency is often used as a measure for the overall efficiency of a given radio technology. Section
8.1.6 discusses various ways to measure 5G spectral efficiency and how it can be improved.
Network Engineering has made a comprehensive slide set which discusses many of the aspects of 5G radio
interface capacity.
8.1.1
PRACH
To be included later.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
89 / 178
Internal
© 2020 Nokia
8.1.2
PDCCH
In 5G19A, there can only be one UE allocated in a given slot. This means that the UE can use the whole
bandwidth of the PDCCH, and there is no risk of overloading the PDCCH.
Capacity management of PDCCH is therefore not relevant in 5G19A.
8.1.3
PUCCH
In 5G19A, the following PUCCH formats are supported:
•
PUCCH short format 0: transmission over 1 symbol with 1 or 2 UCI bits. It can be used for HARQ
Ack/Nack feedback
•
PUCCH short format 2: transmission over 1 symbol (over 1 to 16 PRBs) with 3 to 50 UCI bits. It can
be used for: HARQ Ack/Nack, SR detection and CSI reports
The number of HARQ Ack/Nack messages sent on the PUCCH is proportional to the number of downlink
PDSCH blocks. HARQ Ack/Nack messages have the highest priority on PUCCH, and since the frame patterns
are designed in such a way that each PDSCH slot will always have the needed PUCCH symbol for HARQ
Ack/Nack, this part of the PUCCH will never be congested.
The number of SR detection and CSI reports depends on the number of connected UEs and on the
csiReportPeriodicity parameter. If csiReportPeriodicity has been set to a low value (so CSI reports are often
sent), it is very possible that the maximum cell capacity is reached, and the admission control will then reject
new admission requests.
PUCCH congestion is therefore only caused by too many CSI reports, not by HARQ feedback.
There is a counter to monitor the PUCCH usage (PUCCH_OFDM_SYMBOLS), but since this counter does
not distinguish between using a PUCCH symbol for HARQ Ack/Nack and using it for CSI report, it is not so
useful for capacity monitoring. Instead, the number of connected users should be used to judge how loaded
the PUCCH is, and the admission control counters will tell when the capacity limit has been reached.
The PUCCH capacity monitoring procedure is as follows:
•
Calculate the PUCCH CSI capacity from the various parameters controlling the frame structure
•
Calculate the number of CSI reports per user from the csiReportPeriodicity parameter
•
From above two points, calculate how many users which can be simultaneous connected
•
Monitor the number of connected users to judge how close the cell is to the PUCCH capacity limit
•
Monitor the admission control counters to see when the PUCCH capacity limit is exceeded
If the PUCCH capacity becomes a bottleneck, the only practical counter-measure is to increase the
periodicity of the CSI reports.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
90 / 178
Internal
© 2020 Nokia
Note that in 5G19A, the periodicity of the scheduling requests is also decided by the csiReportPeriodicity.
This means that a low user plane latency in the cell cannot simply be achieved by having a short schedule
request period, because this will increase the number of CSI reports and congest the PUCCH. Instead, using
proactive UL scheduling is normally a better approach to low latency.
The calculation method for the maximum number of connected UEs is described in the PUCCH part of the
webNEI 5G19/19A gNBNSA capacity aspects. An example calculation is shown in Table 55.
Table 55: Example of how different parameter values decide the maximum number of connected users
KPI id
KPI name
KPI formula
NR_5124a
5G Average number of
NSA users
ave_number_of_nsa_users /
ave_number_of_nsa_users_denom
NR_5125a
5G Maximum number of
NSA users
peak_number_of_nsa_users
NR_xxx
Admission rejection ratio
due to lack of PUCCH
resources
SGNB_DU_NSA_ADMISSION_NO_PUCCH /
SGNB_DU_NSA_ADMISSION_REQ
M55308C03004 Number of used PUCCH
symbols
PUCCH_OFDM_SYMBOLS
Table 56: Counters and KPIs to monitor PUCCH capacity
Figure 26 illustrates why the PUCCH_OFDM_SYMBOLS counter is not so useful for PUCCH capacity
monitoring. First, to create a utilization KPI, the number of available PUCCH symbols must be found.
There is no counter for this, so this must be manually calculated based on the frame structure. In this case,
the network uses FDD with SCS = 15 kHz, and the number of available PUCCH symbols in each 15-min
28-Jan-2020 ULITPALIL5R3-1390467857-6948
91 / 178
Internal
© 2020 Nokia
monitoring period is 1 530 000. For each cell and each 15-min measurement period, the PUCCH utilization
can then be calculated and plotted.
From the plot, it can be seen that there are cases with few users and high PUCCH utilization. This is driven
by the HARQ feedback messages and is not a concern, since the PDSCH capacity will run out before the
PUCCH capacity. It can also be seen that for a given number of users, there is a certain minimum PUCCH
utilization (illustrated by the red line on the second chart). This is driven by the CSI reporting and is the
real PUCCH capacity limit. In the case of FDD, only one of the two PUCCH symbols in the slot can be used
for CSI reporting, so the maximum PUCCH utilization (due to CSI reporting) is 50%, after which the
admission control will stop further requests. However, since the PUCCH_OFDM_SYMBOLS counter doesn’t
distinguish between HARQ feedback and CQI reporting, the calculated overall PUCCH utilization can be
anywhere between 50% and 100% before the capacity limit is reached.
Although it is possible to use the number of PDSCH blocks to calculate the number of HARQ feedback
messages and subtract these from the PUCCH utilization in order to reach a “CSI-PUCCH utilization”, it is
much simpler to just calculate the number of connected users and compare this with the capacity.
Figure 26: PUCCH utilization. Same data on the two plots, just different y-axis scale. Each dot is one cell during 15 minutes. FDD 600
MHz, 5G19A
8.1.4
PDSCH
8.1.4.1
Introduction
The PDSCH capacity utilization is directly impacted by the amount of user traffic, and any capacity problems
will immediately be translated into decreased end-user throughput.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
92 / 178
Internal
© 2020 Nokia
8.1.4.2
Performance analysis
The most important performance indicator is to know how much of the available PDSCH capacity which is
used. This will immediately tell if there are capacity problems or not. In case there are capacity problems, it
is needed to know how many of the slots are available for PDSCH and how efficiently a PDSCH slot is being
used.
The PDSCH capacity utilization can be measured either based on the number of PDSCH slots or based on
the number of PDSCH PRBs. In 5G19A, a given PDSCH slot is allocated to a single UE, and normally the full
number of PRBs are allocated. However, the allocation for the msg2 (which is part of the RACH procedure)
is only 48 PRBs, and since the remaining PRBs in the msg2 slot cannot be used by other UEs, the PRB
utilization will be misleading. In 5G19A, it is thus recommended to use the PDSCH slot utilization as the main
PDSCH capacity KPI.
Target values for the PDSCH slot utilization is still to be verified. Based on LTE experiences, the preliminary
busy hour / busy cell target value is set to 40% when averaged over 15 minutes.
The number of available PDSCH slots is to some degree under the control of the operator and should
therefore also be measured. This is straightforwardly calculated as the number of PDSCH slots out of all the
downlink and uplink slots.
The efficiency of a PDSCH slot depends on how good the RF conditions are and how the parameters are
set. The signal quality KPI formulas in chapter 4 and the cell throughput KPI formulas provided in chapter 9
show many details – in this section only the high-level view is provided.
Ultimately, a congested PDSCH means that the end-user throughput is degraded because the capacity is
shared between multiple users. This is one of the factors which decide the value of the user throughput
formula.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
93 / 178
Internal
© 2020 Nokia
Figure 27: Example from a city where average PDSCH load is not high, but still a good handful of cells reach more than 50% utilization
during their most busy 15-min period. Dominant use case is Fixed Wireless Access where it is not uncommon that even a single user
can use the capacity of a whole cell. In this case, the degradation of the user throughput as the PDSCH slot utilization increases is not
dramatic. 5G19A, 2.6 GHz.
KPI id
KPI name
KPI formula
Comment
NR_5110a
5G Usage ratio of
PDSCH data slots over
all DL data slots
DATA_SLOT_PDSCH /
DL_DATA_SLOTS
Main PDSCH capacity
indicator. Preliminary
threshold is <40% in
busy hour
NR_125a
5G DL data slot ratio
DL_DATA_SLOTS / (DL_DATA_SLOTS
Formula is only relevant
for TDD networks.
Determined by
parameter settings.
TDD networks typically
have values in the 70%
- 75% range
+ UL_DATA_SLOTS + SSB_SLOTS
+ PRACH_SLOTS)
NR_471a
5G Average number of
scheduled UEs per slot
in DL
TOTAL_COSCHED_UE_PDSCH /
DATA_SLOT_PDSCH
NR_5090a
5G Active cell MAC
PDU throughput on
PDSCH on initial HARQ
transmissions
8*
(PDSCH_INI_VOL_64TBL_MCS00..28
+
PDSCH_INI_VOL_256TBL_MCS00..27)
28-Jan-2020 ULITPALIL5R3-1390467857-6948
94 / 178
Internal
Depends on the radio
interface quality. High
rank, high MCS and
© 2020 Nokia
KPI id
KPI name
NR_578a
NR_5100a
KPI formula
Comment
/ PDSCH_OFDM_SYMBOLS_TIME
low BLER will generate
high KPI values
5G MAC PDU Cell
throughput on PDSCH
considering the
accumulated time of
frames with data slots
used for PDSCH
(8 *
(PDSCH_INI_VOL_64TBL_MCS00..28
+
PDSCH_INI_VOL_256TBL_MCS00..27)
Depends on the radio
interface quality as well
as the number of slots
available for PDSCH
5G Average MAC layer
user throughput in
downlink
(8 *
(PDSCH_INI_VOL_64TBL_MCS00..28
+
PDSCH_INI_VOL_256TBL_MCS00..27)
/ 1000000) /
/ DATA_SLOT_PDSCH_TIME) *
(DL_DATA_SLOTS /
(MEAS_PERIOD_NR_MAC_PDU_TPUT
/ (DATA_SLOT_PDSCH_TIME /
DATA_SLOT_PDSCH)))
Impacted by radio link
quality, SSB and UL slot
overhead and multiple
simultaneous users
(ACC_UE_DL_DRB_DATA * 20 *
(DATA_SLOT_PDSCH_TIME /
1000000) / DATA_SLOT_PDSCH)
Table 57: Relevant OSS KPI formula to show the PDSCH capacity situation
8.1.4.3
Optimization procedure
If the performance analysis shows there is a problem with PDSCH capacity, now or in the near future, the
following mitigation actions should be considered:
•
Reduce the overhead from non-PDSCH slots and symbols. This means decreasing the share of UL
slots and the share of SSB slots (which carries SSB blocks and the TRS). Table 81 lists the relevant
parameters. Naturally, increasing the share of PDSCH blocks will lead to reduced performance in
other areas
•
Keep a bigger share of the traffic on the LTE PDSCH. This is most likely not a good choice for the
early 5G networks, as the LTE PDSCH is likely to be more congested than the 5G PDSCH. Table 68
lists some of the relevant parameters
•
Increase the efficiency of the PDSCH by optimizing the RF performance and using throughput
enhancement features such as 4x4 MIMO and 256QAM. Chapter 4 and chapter 9 describe how to
do this
•
Use the A2 release criteria to terminate connections with bad and inefficient radio link
•
Build more 5G BTSs in the area
28-Jan-2020 ULITPALIL5R3-1390467857-6948
95 / 178
Internal
© 2020 Nokia
8.1.5
PUSCH
8.1.5.1
Introduction
The PUSCH capacity utilization is naturally directly impacted by the amount of uplink user traffic, however,
in practice the downlink user traffic is also playing a role because the uplink capacity in TDD networks is
typically small enough that a substantial part of it is used to transfer the uplink acknowledgements for
downlink traffic (the volume of the TCP acknowledgement messages is typically ~1% of the TCP payload).
This means that PUSCH capacity problems can impact uplink end-user throughput as well as downlink enduser throughput.
8.1.5.2
Performance analysis
The most important performance indicator is to know how much of the available PUSCH capacity which is
used.
This will immediately tell if there are capacity problems or not. In case there are capacity problems, it is
needed to know how many of the slots which are available for PUSCH and how efficiently a PUSCH slot is
being used.
The PUSCH capacity utilization can be measured either based on the number of PUSCH slots or based on
the number of PUSCH PRBs.
In 5G19A, a given PUSCH slot is allocated to a single UE, and normally the full number of PRBs are allocated.
However, if there is only a small amount of data to be sent or if the radio link quality is particularly bad, the
scheduler may allocate as few as 3 PRBs in order to maximize the robustness of the transmission. Since the
remaining PRBs in the PUSCH slot cannot be used by other UEs, the PRB utilization will be misleading.
Similarly, the allocation for the msg3 (which is part of the RACH procedure) is only 48 PRBs, and this again
means the PRB utilization figure will be misleading, especially if there are many msg3 messages compared
to normal PUSCH traffic. In 5G19A, it is therefore better to base the PUSCH utilization measurement on the
PUSCH slot utilization.
In future releases, the scheduler will have the possibility to schedule multiple UEs in the same slot, and then
it is necessary to base the PUSCH utilization measurements on the PUSCH PRB utilization.
A problem common for both PUSCH slot and PUSCH PRB utilization figures is that the use of proactive UL
scheduling will inflate the utilization, even though such scheduling has lower priority than “real” scheduling,
so it should be ignored from a capacity perspective. There are no direct counters to take proactive UL
scheduling into account, but indirectly it can be compensated by looking at the ratio between MAC SDU
volume (does not contain proactive UL scheduling volume) and MAC PDU volume (contains proactive UL
scheduling volume). Figure 28 shows example of a cell with high “real” use of the PUSCH, and the high
PUSCH utilization figure is therefore a real concern and another cell with high PUSCH utilization but hardly
28-Jan-2020 ULITPALIL5R3-1390467857-6948
96 / 178
Internal
© 2020 Nokia
any “real” uplink traffic. An easy way to take this into account is to multiply the measured PUSCH utilization
with the ratio between MAC SDU and PDU volume.
Figure 28: Examples of two cells with high PUSCH utilization but only the left cell carries high volume of real traffic
Figure 29: PUSCH slot utilization. Raw figures are per cell and per 15 min period. The bar chart shows the distribution. When looking
at the whole PUSCH allocation (blue bars), about 50% of the samples have either 0% or 1% utilization. When subtracting proactive
UL scheduling (orange bars), no cells have more than 1% allocation. 5G19
Target values for the PUSCH slot and PRB utilization are still to be verified. Based on LTE experiences, the
preliminary busy hour / busy cell target value should be set to 50% when averaged over 15 minutes.
The number of available PUSCH slots is to some degree under the control of the operator and should
therefore also be measured. This is straightforwardly calculated as the number of PUSCH slots out of all the
downlink and uplink slots.
The efficiency of a PUSCH slot depends on how good the RF conditions are and how the parameters are
set. The signal quality KPI formulas in chapter 4 and the cell throughput KPI formulas provided in chapter 9
show many details – in this section only the high-level view is provided.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
97 / 178
Internal
© 2020 Nokia
Ultimately, a congested PUSCH means that the end-user throughput (uplink and possibly downlink as well)
is degraded because the capacity is shared between multiple users. This is one of the factors which decide
the value of the user throughput formula.
KPI id
KPI name
KPI formula
NR_577a
5G PUSCH slot
utilization
compensated for
proactive UL
scheduling
(DATA_SLOT_PUSCH / UL_DATA_SLOTS) * Main 5G19A PUSCH
(UL_MAC_SDU_VOL_DTCH /
capacity indicator.
Preliminary
PUSCH_CP_INI_VOL_64TBL_MCS00…28)
threshold is <50%
NR_126a
5G UL data slot ratio
UL_DATA_SLOTS / (DL_DATA_SLOTS
+ UL_DATA_SLOTS + SSB_SLOTS
+ PRACH_SLOTS)
NR_472a
5G Average number
of scheduled UEs per
slot in UL
TOTAL_COSCHED_UE_PUSCH /
DATA_SLOT_PUSCH
NR_5091a
5G Active cell MAC
PDU throughput on
PUSCH on initial
HARQ transmissions
8 * PUSCH_CP_INI_VOL_64TBLMCS00..28
5G MAC PDU Cell
throughput on
PUSCH considering
the accumulated
time of frames with
data slots used for
PUSCH
8 * PUSCH_CP_INI_VOL_64TBLMCS00..28
5G Average MAC
layer user
throughput in uplink
(8 *
PUSCH_CP_INI_VOL_64TBLMCS00..28/
1000000) /
NR_579a
NR_5100a
/ PUSCH_OFDM_SYMBOLS_TIME
/ DATA_SLOT_PUSCH_TIME) *
(UL_DATA_SLOTS /
(MEAS_PERIOD_NR_MAC_PDU_TPUT /
(DATA_SLOT_PUSCH_TIME /
DATA_SLOT_PUSCH)))
(ACC_UE_UL_DRB_DATA * 20 *
(DATA_SLOT_PUSCH_TIME / 1000000) /
DATA_SLOT_PUSCH)
Comment
Only relevant for
TDD networks.
Determined by
parameter settings.
TDD networks
typically have values
in the 17 % - 19%
range
Depends on the
radio interface
quality. High rank,
high MCS and low
BLER will generate
high KPI values
Depends on the
radio interface
quality as well as the
number of slots
available for PUSCH
Impacted by radio
link quality, RACH
and DL slot
overhead and
multiple
simultaneous users
Table 58: Relevant OSS KPI formula to show the PUSCH capacity situation
28-Jan-2020 ULITPALIL5R3-1390467857-6948
98 / 178
Internal
© 2020 Nokia
8.1.5.3
Optimization procedure
If the performance analysis shows there is a problem with PUSCH capacity, now or in the near future, the
following mitigation actions should be considered:
•
Reduce the overhead from non-PUSCH slots and symbols. This means decreasing the share of DL
slots and the share of RACH slots and possibly disabling the additional UL DMRS symbol. Table 81
lists the relevant parameters. Naturally, increasing the share of PUSCH blocks will lead to reduced
capacity on PDSCH and PRACH
•
Keep a bigger share of the traffic on the LTE PUSCH. In most FDD LTE networks, the PUSCH is
generally not so heavy loaded, so this can be realistic option. Table 68 lists the relevant parameters.
In particular, make sure that the ulDataPath parameter has been set to “ulOverLTENr”
•
Increase the efficiency of the PUSCH by optimizing the RF performance. Chapter 4 and chapter 9
describe how to do this
•
Use the features 5GC001200: Dynamic uplink data split mode and 5GC001954: Introduction of A2
based SgNB release to release the connection when the radio link quality becomes bad
•
8.1.6
Build more 5G BTSs in the area
Spectral efficiency
Spectral efficiency is a measure for how efficient a given radio technology can utilize the radio interface.
One of the aims of the 3GPP 5G standard is that the 5G spectral efficiency should be significantly higher
than what is achievable in LTE.
Spectral efficiency is measured in bits / second / Hz when the focus is mainly on the radio technology itself
and in bits / second / Hz / km2 when the network topology (use of small cells etc.) needs to be included.
Optimization of spectral efficiency is in practice the same as optimizing the achievable cell throughput,
which is described in detail in chapter 9.
In 5G19A, the average spectral efficiency will not be high. This is because one slot cannot be allocated to
more than one UE, and if there is only a small amount of data to be transmitted, the scheduler will choose
a low MCS to get as robust transmission as possible, and this will result in a low spectral efficiency.
There are several ways to define how the throughput part of the spectral efficiency should be calculated.
Throughput is basically data volume over time. Data volume can as one extreme be measured as the actual
transmitted bits that goes out on the radio interface and as the other extreme, only the bits that reaches
the application layer are measured. The difference between these two extremes are decided by the number
of retransmissions and the protocol overhead. Likewise, the time can be measured as anything between the
duration of the PxSCH symbols used for the transmission and the time between the application starts and
stops the data transmission. The difference between these two extremes is for example caused by the split
into downlink and uplink transmission slots in TDD network and the time needed to transmit the various
reference signals.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
99 / 178
Internal
© 2020 Nokia
The current Nokia KPI formulas cover two combinations of data volume and transmit time. The formulas
are listed in Table 59 and their characteristics are as follows:
NR_5108a & NR_5109a:
•
Measures the data volume as the actual transmitted bits (on MAC layer). Bits used for physical layer
error protection are not counted
•
All retransmissions are counted, i.e. retransmissions will not degrade the spectral efficiency
•
Bits caused by protocol overhead are counted, i.e. bad “protocol efficiency” will not degrade the
spectral efficiency
•
Only those symbols which are actually used for PxSCH transmission are included in the time
duration, i.e. using many resources for reference signals such as DMRS or SSB will not degrade the
spectral efficiency
•
Reaching a high value requires the radio conditions to be good so that the link adaptation chooses
a high rank and a high MCS
•
Transmission bandwidth is taken into account in a rather convoluted way in the denominator
•
Provides the highest value for spectral efficiency which is possible with available PM counters, so
should be the default choice when comparing with values from other vendors
NR_571a & NR_572a:
•
Measures the data volume on the RLC layer. This means that small coding schemes, low rank and
HARQ and RLC retransmissions will degrade the spectral efficiency
•
Data volume generated by higher layer retransmissions (PDCP, TCP, application layer) is counted,
so such retransmissions will not degrade the spectral efficiency
•
Only the slots used for PxSCH transmission are included in the time duration, so if the slot is used
completely for something else (SSB, RACH, UL when calculating the DL figure and vice versa), it will
not degrade the spectral efficiency
•
Symbols used for something else (DMRS, SRS) will degrade spectral efficiency
•
Transmission bandwidth is taken into account in a rather convoluted way in the denominator
•
Gives good comparison to legacy LTE formula. LTE formula counts data volume on PDCP level, but
PDCP counters are not available on cell level in 5G19A. The highest cell-level protocol counters in
5G19A are the “RLC Low” counters
KPI id
KPI name
KPI formula
NR_5108a
5G Spectral efficiency in downlink
8 * SUM(PDSCH_INIRE_VOL_64TBL_MCS00..28
+ PDSCH_INIRE_VOL_256TBL_MCS00..27) /
(PDSCH_OFDM_SYMBOLS_TIME * 180 *
(PRB_USED_PDSCH /
DATA_SLOT_PDSCH_TIME))
NR_5109a
5G Spectral efficiency in uplink
8*
SUM(PUSCH_CP_INIRE_VOL_64TBL_MCS00..28)
/ (PUSCH_OFDM_SYMBOLS_TIME * 180 *
28-Jan-2020 ULITPALIL5R3-1390467857-6948
100 / 178
Internal
© 2020 Nokia
KPI id
KPI name
KPI formula
(PRB_USED_PUSCH /
DATA_SLOT_PUSCH_TIME))
NR_571a
5G Spectral efficiency in downlink
from the RLC volume and data slot
time
8 * SUM(DL_RLC_VOL_TX_L_QOS_GRP_01..20) /
(180 * PRB_USED_PDSCH)
NR_572a
5G Spectral efficiency in uplink from
the RLC volume and data slot time
8 * SUM(UL_RLC_VOL_RX_L_QOS_GRP_01..20 /
LTE_5747a
DL Spectral efficiency
PDCP_SDU_VOL_DL * 8 / PRB_USED_PDSCH /
180
LTE_5748a
UL Spectral efficiency
PDCP_SDU_VOL_UL *8 / PRB_USED_PUSCH /
180
(180 * PRB_USED_PUSCH)
Table 59: KPI formulas to measure spectral efficiency. Many others are possible
Figure 30: Example of downlink spectral efficiency values. 5G19, 3.5 GHz TDD
8.2
5G gNB processing capacity
This will be included in a later version of the document
8.3
5G Admission Control
Feature id
Feature name
5GC000480
Radio Admission Control for NSA mode 3x operation
5GC001836
Spillover from 5GC000480 Radio Admission Control for NSA mode 3x operation
Table 60: Features related to radio admission control. 5G19A features in italic
28-Jan-2020 ULITPALIL5R3-1390467857-6948
101 / 178
Internal
© 2020 Nokia
The purpose of the Radio Admission Control (RAC)feature is to protect L1 and L2 resources against high
load. High load may be caused by high utilization of radio resources or due to L1 or L2 processing power
need. In 5G19A, admission control is also responsible for selecting the best combination of carriers in case
5G carrier aggregation is in use.
In 5G19A, the radio admission control is performing the following checks:
•
Number of active UEs operating in NSA mode 3x per 5G cell group (NRCELLGRP) (cell group =
multiple cells on different carrier frequencies covering the same sector)
•
Number of active UEs operating in NSA mode 3x per 5G cell (NRCELL)
•
Number of non-GBR DRBs of active UEs operating in NSA mode 3x per 5G cell group (NRCELLGRP)
The admission control is performed when a new connection is established and when there is an incoming
handover. With default parameter values, these two procedures have equal priority, but by defining a
“buffer” which can only be used for handover, higher priority can be given to incoming handovers.
The thresholds are given by the parameters listed in Table 61.
Parameter
Object
Range
Default
Recommended
maxNumOfUsersPerCell
NRCELL
0…250
250
250
maxNumOfUsers
NRCELLGRP
0…500
500
500
maxNumOfNonGBRBearers
NRCELLGRP
0…500
500
500
addNumOfHoUsers
NRCELLGRP
0…500
0
0
addNumOfNonGBRBearersHo
NRCELLGRP
0…500
0
0
maxNumOfSCellAlloc
NRCELL
0…250
250
250
Table 61: Admission control parameters
Additionally, the admission control will check if there is enough PUCCH capacity to send the CSI reports
from the UEs to the BTS. Depending on the setting of the csiReportPeriodicity parameter, admission control
rejections can happen with a relatively small number of users, and in practice, this kind of admission control
rejection is the only one seen in the early 5G networks (see also section 8.1.3 about PUCCH capacity
management).
The admission control behaviour can be monitored via the KPIs in Table 62.
KPI id
KPI name
KPI formula
NR_5124a
5G Average number of NSA users
AVE_NUMBER_OF_NSA_USERS /
AVE_NUMBER_OF_NSA_USERS_DENOM
NR_5125a
5G Maximum number of NSA users
PEAK_NUMBER_OF_NSA_USERS
NR_5014a
5G Radio admission success ratio for
NSA user
SGNB_NSA_ADMISSION_SUCC /
SGNB_NSA_ADMISSION_REQ
NR_50a
5G Radio admission success ratio for
NSA user in handover
SGNB_NSA_HO_ADMISSION_SUCC /
SGNB_NSA_HO_ADMISSION_REQ
28-Jan-2020 ULITPALIL5R3-1390467857-6948
102 / 178
Internal
© 2020 Nokia
KPI id
KPI name
KPI formula
NR_51a
5G Non-GBR DRB radio admissions
success ratio for NSA user in
handover
SGNB_NSA_NGBR_DRB_HO_SUCC /
SGNB_NSA_NGBR_DRB_HO_REQ
NR_272a
5G Radio admission rejection ratio
per cause lack of CP-UE capacity
SGNB_NSA_RAC_REJ_DUE_TO_CPUE /
SGNB_NSA_ADMISSION_REQ
NR_273a
5G Radio admission rejection ratio
per cause lack of non-GBR capacity
SGNB_NSA_RAC_REJ_DUE_TO_NGBR /
SGNB_NSA_ADMISSION_REQ
NR_274a
5G Radio admission rejection ratio
per cause lack of NSA user capacity
SGNB_NSA_RAC_REJ_DUE_TO_NSA /
SGNB_NSA_ADMISSION_REQ
NR_xxx
5G radio admission rejections due to
lack of PUCCH capacity
SGNB_DU_NSA_ADMISSION_NO_PUCCH /
SGNB_DU_NSA_ADMISSION_REQ
Table 62: Relevant KPI formulas when monitoring admission control behavior. See also the PUCCH utilization discussion in section
8.1.3
8.4
LTE radio interface capacity
8.4.1
Introduction
There are several reasons why the 5G network may cause congestion on the LTE radio interface:
-
The EN-DC parameters may be configured such that only specific LTE bands can be used as the
EN-DC anchor band. This approach means that the LTE parameters should be set so that the ENDC capable devices with 5G subscription are pushed to the EN-DC anchor band. This means that
traffic on non-5G bearers will load the LTE anchor band
-
In order to maximise the user throughput, the user data for 5G subscribers is normally transferred
simultaneously on both 5G and LTE radio interfaces. It is possible that 5G subscribers have a much
higher subscription quota than LTE subscribers, and therefore use applications which transfer much
more data than the normal LTE subscriber profile. This may then create a higher load on the LTE
leg.
-
The 5G radio coverage may not be as extensive as the LTE coverage, which means that at the LTE
cell edges (where the spectral efficiency is bad), there will be more 5G users (with bandwidth-hungry
applications) who cannot get a 5G radio connection and which therefore instead load the LTE
channels.
8.4.2
Performance analysis
The normal procedures for monitoring LTE radio capacity should be followed. These are described in the
material stored here.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
103 / 178
Internal
© 2020 Nokia
In addition, the amount of 5G user plane traffic on the X2 should be observed. The relevant KPIs are
described in the following section on X2 capacity management.
8.4.3
Optimization actions
The normal procedures for optimizing LTE radio capacity should be followed. These are described in the
material stored here.
In addition, it should be considered to use only the 5G radio interface rather than both 5G and LTE radio
interfaces. This will reduce the end-user throughput but will help on the LTE congestion.
Aiming for a fast establishment of the 5G link (for example by not waiting for the LTE carrier aggregation to
happen before the SgNB addition takes place) will increase the offload from LTE to 5G. Also, adjusting the
B1 / A2 threshold such that 5G is being used even in locations with bad 5G RSRP can help to offload the
LTE network.
Increasing the 5G coverage will also help.
8.5
LTE eNB processing capacity
The normal procedures for monitoring and optimizing LTE eNB processing capacity should be followed.
These are described in the material stored here.
8.6
Interface capacity
The utilization of the various fixed interfaces (F1, X2, S1) cannot be adequately monitored with BTS counters
because the end-to-end capacity of the interfaces is not known to the BTS, and because the BTS does not
know the traffic that the interface may carry from other sources.
From BTS counters, it is only possible to monitor how much the given BTS contributes to the interface load.
In the available KPI formulas, the contribution from management plane and control plane traffic is assumed
to be negligible, so only the user plane traffic is included.
In the formulas in Table 63, only the average load during the measurement period is calculated. For some
of the interfaces, there are also counters for the load during the highest-loaded second, but these counters
are per QoS group, and since different QoS groups cannot be expected to peak in the same second, the
counters cannot simply be summed. Still, for a given QoS group, there can be value in comparing the
average load with the peak load, so the “max” counters are listed in Table 64.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
104 / 178
Internal
© 2020 Nokia
KPI id
KPI name
KPI formula
NR_xxx
Average S1 DL
throughput (Mbps)
8 * (DL_PDCP_VOL_RCV_S1U_QOS_GRP_01..20) /
(PERIOD_DURATION * 60 * 1000)
NR_xxx
Average S1 DL
packets per second
DL_PDCP_SDU_RCV_S1U_QOS_GRP_01..20 /
(PERIOD_DURATION * 60)
NR_xxx
Average S1 UL
throughput (Mbps)
8 * (UL_PDCP_VOL_SNT_S1U_QOS_GRP_01..20) /
(PERIOD_DURATION * 60 * 1000)
NR_xxx
Average S1 UL
packets per second
UL_PDCP_SDU_SNT_S1U_QOS_GRP_01..20 /
(PERIOD_DURATION * 60)
NR_371a
5G PDCP SDU
throughput received
over F1-U in DL at
gNB-DU
8 * (DL_PDCP_VOL_RCV_F1_QOS_GRP_01..20)
NR_xxx
Average F1 DL
packets per second at
gNB-DU
DL_PDCP_NUM_RCV_F1_QOS_GRP_01..20 /
MEAS_PERIOD_DU_NR_F1_REPORT
NR_392a
5G PDCP SDU
throughput in uplink
over F1-U at gNB-DU
8 * (UL_PDCP_VOL_SNT_F1_QOS_GRP_01..20)
NR_xxx
Average F1 UL
packets per second at
gNB-DU
UL_PDCP_NUM_SNT_F1_QOS_GRP_01..20 /
MEAS_PERIOD_DU_NR_F1_REPORT
NR_xxx
Average X2 DL
throughput (Mbps)
8* (DL_PDCP_VOL_SNT_X2_QOS_GRP_01..20)
NR_xxx
Average X2 DL
packets sent per
second
DL_PDCP_NUM_SNT_X2_QOS_GRP_01..20) /
MEAS_PERIOD_NR_X2_REPORT
NR_xxx
Average X2 UL
throughput (Mbps)
8* (UL_PDCP_VOL_RCV_X2_QOS_GRP_01..20)
Average X2 UL
packets received per
second
(UL_PDCP_NUM_RCV_X2_QOS_GRP_01..20) /
MEAS_PERIOD_NR_X2_REPORT
NR_xxx
/ (1000 * MEAS_PERIOD_DU_NR_F1_REPORT)
/ (1000 * MEAS_PERIOD_DU_NR_F1_REPORT)
/ (1000 * MEAS_PERIOD_NR_X2_REPORT)
/ (1000 * MEAS_PERIOD_NR_X2_REPORT)
Table 63: KPI formulas to calculate average interface traffic
Interface
Max counter
Matching average counter
S1 DL
MAX_DL_VOL_TX_NSA_QOS_GRP_xx
DL_VOL_TX_NSA_QOS_GRP_XX /
(PERIOD_DURATION * 60 * 1000)
28-Jan-2020 ULITPALIL5R3-1390467857-6948
105 / 178
Internal
© 2020 Nokia
Interface
Max counter
Matching average counter
S1 UL
MAX_UL_VOL_RX_NSA_QOS_GRP_xx
UL_VOL_RX_NSA_QOS_GRP_XX /
(PERIOD_DURATION * 60 * 1000)
F1 DL
MAX_DL_PDCP_RCV_F1_QoS_GRP_xx
DL_PDCP_VOL_RCV_F1_QOS_GRP_XX
/ (1000 * MEAS_PERIOD_DU_NR_F1_REPORT)
F1 UL
MAX_UL_PDCP_SNT_F1_QoS_GRP_xx
UL_PDCP_VOL_SNT_F1_QOS_GRP_XX
/ (1000 * MEAS_PERIOD_DU_NR_F1_REPORT)
X2 DL
MAX_DL_PDCP_SNT_X2_QOS_GRP_xx
DL_PDCP_VOL_SNT_X2_QOS_GRP_XX)
/ (1000 * MEAS_PERIOD_NR_X2_REPORT)
X2 UL
MAX_UL_PDCP_RCV_X2_QOS_GRP_01
UL_PDCP_VOL_RCV_X2_QOS_GRP_XX)
/ (1000 * MEAS_PERIOD_NR_X2_REPORT)
Table 64: Counters to compare maximum and average interface throughput per QoS group
28-Jan-2020 ULITPALIL5R3-1390467857-6948
106 / 178
Internal
© 2020 Nokia
9
Optimization of throughput
Throughput can be thought of in terms of user throughput (where the target is to maximise the throughput
delivered to the end user) and cell throughput (where the target is to maximise the combined throughput
that a cell can deliver to all the users in the cell). Many of the actions to increase the throughput are working
on both the user and on the cell throughput, so this chapter will discuss both topics.
The cell throughput discussions in this chapter will only be concerned with the 5G cell throughput. For
optimization of the LTE cell throughput, the LTE optimization guideline should be consulted. On the other
hand, the user throughput is normally considered to include both the 5G and the LTE throughput. The
discussions in this chapter will include how to aggregate LTE carriers with 5G carriers, but the performance
of the LTE carriers themselves will not be discussed.
9.1
The main factors impacting the throughput
The first prerequisite for good throughput performance is a good radio link quality. If the radio link quality
is good, higher coding schemes will be used, and this directly impacts both user and cell throughput. In
order to have good radio link quality, the basic RF environment must be optimized (described in chapter 4)
and it must be ensured that the mobility functionality is in place so the UE gets the maximum benefit of the
RF environment (described in chapter 7).
Especially for the user throughput, the amount of traffic in the network plays a big role, because the network
capacity is shared among the users. In 5G19A, there are not so many possibilities to change the way that
capacity is being shared among the users, so the description of capacity management in chapter 8 mainly
deals with how to measure the current capacity utilization. In case the control channels are overloaded, also
the cell throughput will be reduced because it will not be possible to use all the available capacity on the
data channels.
Both the user plane and the control plane latency impact the achievable user throughput. Especially when
using short TCP data transfers (for example Ookla Speedtest), it is important to minimize the “TCP slow
start” period and a low user plane latency helps with this. If connections are dropped due to lack of
handover, the “re-establishments” must be fast to minimize the interruption time. Chapters 10 and 11 discuss
user plane and control plane latency. See also section 13.3 for an example of how a long TCP slow start
impacts Ookla throughput results.
There are also specific features which aims at enhancing either general cell throughput or specific user
throughput. These features will be discussed in the following sections.
The configuration of the TDD frame structure decides how many slots and symbols there are available for
data transmissions and how many slots which are used for signalling overhead. The available parameters
and their impact are discussed in section 9.4.6.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
107 / 178
Internal
© 2020 Nokia
Finally, the UE capabilities and implementation plays a big role. Not only can there be differences in the UE
capability for example with regard to carrier aggregation, it has also been observed that some UEs disable
5G functionality when the battery is low (early WNC implementation) or when the temperature is high (early
Samsung implementation).
9.2
Performance analysis
Throughput performance is normally measured either by doing field tests or by analysing OSS counters.
Each method has its own advantages and disadvantages as discussed in section 2.9 and consequently both
methods are often used.
9.2.1
Field tests
Field tests in “ideal test conditions” are typically used to verify the benefits from features such as carrier
aggregation or low signalling overhead, while drive tests are needed to measure the performance of the
features which work differently in good or bad radio conditions such as 256QAM or MIMO.
In many cases, the “ideal test conditions” can be in a lab environment as well as on a live site, as long as it
is assured there is no other traffic on the live site and the RF conditions are “good enough” with high signal
strength and low interference. It is in most cases straightforward to go to a site and find a good test location.
However, when 4x4 MIMO is tested, it is not enough to simply have one good radio signal: There must be
two strong signals available (each signal can provide two MIMO layers due to cross polarized transmission),
and these signals must furthermore also be uncorrelated. In practice, it can be very difficult especially in
5G19 to find the “sweet spot” where rank 4 can be achieved with high coding scheme, and even when a
sweet spot is found, only small adjustments of the UE (moving it a few centimetres) can drastically change
the performance. This makes stationary field measurements highly unreliable - a lab setup with a fading
simulator is much better suited for testing 4x4 MIMO.
When measuring the achievable throughput, it is very important that the transmit buffer (in the BTS or in
the UE) is kept “full”, meaning there are always packets waiting to be scheduled, so the packet scheduler in
the BTS do not need to schedule empty slots because there is nothing to transmit. Reasons for not achieving
the full buffer condition include:
•
The “TCP slow start” period is ongoing. Work-around: Use UDP transmissions or be sure to transfer
large files
•
The TCP connection has reached its maximum throughput (determined by TCP parameter settings
and the RTT). Work-around: Use UDP transmissions, multiple parallel TCP connections or tune TCP
parameters
•
The link from the gNB to the SGW is overloaded. Work-around: Expand the link capacity
•
The link from the core network to the public application server is overloaded. Work-around: Use
dedicated test server close to the SGW
28-Jan-2020 ULITPALIL5R3-1390467857-6948
108 / 178
Internal
© 2020 Nokia
•
The firewall is restricting the throughput to servers outside the PLMN. Work-around: Use dedicated
test server inside the firewall.
•
The computer used for testing is either not powerful enough or it is loaded with various background
applications which reduces the performance. Work-around: Use a dedicated “clean” laptop for field
tests
•
Etc.
Many operators require that the “Ookla Speedtest” application is able to show high throughput results, and
it is therefore mandatory to measure the throughput performance with this tool. Speedtest is a very
convenient and easy-to-use tool, and it can be expected that many end-users will also be running Speedtest.
The problem is that if Speedtest shows bad results, it is not immediately obvious if there is an issue with the
radio network or if the problem lies somewhere else. See also the discussion in section 13.3 on how Ookla
Speedtest works and some hints to optimize the performance.
The recommended test procedure is to first do the throughput measurements with a UDP-based tool such
as iPerf using a dedicated test server as close to the EPC as possible. This will eliminate many of the nonradio reasons for low throughput and it also provides a continuous data stream which can be used for
stability tests and drive tests. Downlink and uplink throughput should be tested separately. Once good UDP
performance has been achieved, Speedtest can then be used to confirm that also end-users will experience
good performance.
Table 65: Field tests in same location with UDP, FTP and Speedtest. Note that especially the Speedtest results are lower than the UDP
throughput. This illustrates that it can be misleading to rely completely on Speedtest results.
When evaluating test results, the NR throughput tool provides helpful information of the physical layer
throughput achievable in perfect radio conditions given the bandwidth, number of carriers, MIMO mode
etc.
9.3
OSS PM counters
There are PM KPI formulas available for both cell throughput and for user throughput. However, with 5G19A
counters, it is not straightforward to calculate the combined user throughput in case of carrier aggregation
(either LTE/5G aggregation or 5G carrier aggregation).
Both cell throughput and user throughput depend upon the type of traffic loading the network, e.g. network
traffic dominated by smart phone keep-alive packets tends to reduce measured throughputs.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
109 / 178
Internal
© 2020 Nokia
Since carrier aggregation is part of 5G from the beginning, the cell throughput from all the carriers (i.e. from
all the cells) should be aggregated to sector level.
User throughput depends on the number of active connections in the cell. User throughput will therefore
decrease as the number of active connections increase, i.e. the cell resources are shared amongst all
connections.
The throughput formulas can generally be viewed as data volume over time. The “data volume“can be
measured on the different layers (MAC, RLC, PDCP), on the different interfaces (S1, F1, X2) and with or
without retransmissions. The “time” can be measured as the whole measurement period (typically 5 or 15
minutes) or during the “active” time (either the number of PDSCH / PUSCH slots or even the number of
PDSCH / PUSCH symbols which are used for transmissions).
Table 66 lists the most relevant KPI formulas. For brevity, only the downlink throughput formulas are
included. Many others are available in the Jump portal or described in the NPO counter material
KPI id
KPI name
KPI formula
UL
equivalent
Comments
NR_5090a
5G Active cell
MAC PDU
throughput on
PDSCH on initial
HARQ
transmissions
(8*(PDSCH_INI_VOL_64TBL_MCS00..28 +
PDSCH_INI_VOL_256TBL_MCS00..27))
NR_5091a
Slot format, SSB overhead etc
has not impact since only the
PDSCH symbol time is used.
Use of low MCS or many HARQ
retransmissions will produce
low values. In 5G19, padding
means huge throughput
increase compared to higher
layers
5G MAC PDU
Cell throughput
on PDSCH
considering the
accumulated
time of frames
with data slots
used for PDSCH
((8*(PDSCH_INI_VOL_64TBL_MCS00..28 +
PDSCH_INI_VOL_256TBL_MCS00..27))
NR_579a
Large overhead from e.g. SSB
will decrease the value of this
formula
NR_423a
5G Average High
RLC efficient
data throughput
in downlink
without
retransmissions
on DU
(8* (DL_RLC_VOL_TX_H_QOS_GRP_01..20
+ DL_RLC_VOL_RETX_H_QOS_GRP_01..20))
/ (1000 * DATA_SLOT_PDSCH_TIME)
NR_425a
Based on RLC layer throughput
---
X2 throughput
8*
(DL_PDCP_VOL_SNT_X2_QOS_GRP_01..20)
---
Useful to analyse how the
throughput is split between LTE
(via X2) and 5G (via F1)
---
Useful to analyse how the
throughput is split between LTE
(via X2) and 5G (via F1)
NR_578a
/ PDSCH_OFDM_SYMBOLS_TIME
/ DATA_SLOT_PDSCH_TIME)
*
(DL_DATA_SLOTS /
(MEAS_PERIOD_NR_MAC_PDU_TPUT /
(DATA_SLOT_PDSCH_TIME /
DATA_SLOT_PDSCH)))
/ (1000 * MEAS_PERIOD_NR_X2_REPORT)
---
F1 throughput,
CU level
8 * (DL_VOL_SNT_F1_QoS_GRP_01..20)
/ (1000 *
MEAS_PERIOD_NR_F1_CU_REPORT)
28-Jan-2020 ULITPALIL5R3-1390467857-6948
110 / 178
Internal
© 2020 Nokia
KPI id
KPI name
KPI formula
UL
equivalent
Comments
NR_5100a
5G Average
MAC layer user
throughput in
downlink
(8*(PDSCH_INI_VOL_64TBL_MCS00..28 +
PDSCH_INI_VOL_256TBL_MCS00..27) /
1000000) / (ACC_UE_DL_DRB_DATA * 20 *
(DATA_SLOT_PDSCH_TIME / 1000000) /
DATA_SLOT_PDSCH)
NR_5001a
Measures the time that there is
data in the UE’s downlink
buffer. This includes the time
where DL transmission is not
possible due to UL slots, SSB
slots and similar, but does not
include the idle time where
there is a RRC connection but
no data to be sent. There are
numerous reasons for low
values: Multiple simultaneous
users, low MCS, HARQ
retransmissions, frame structure
is chosen so there are many UL
slots or there is high overhead
from SSB / TRS signals
Table 66: KPI throughput formulas. All units in Mbps
9.4
Relevant features
9.4.1
Basic EN-DC carrier aggregation
Feature id
Feature name
LTE4088
LTE-NR Dual Connectivity Option 3X
LTE4193
Dynamic Trigger for LTE-NR DC Option 3X
5GC000475
SgNB Addition and Release for NSA mode 3x operation
5GC000570
5G - LTE flow control at X2
5GC001200
Dynamic uplink data split mode
5GC001954
Introduction of A2 based SgNB release
Table 67: Features related to basic EN-DC carrier aggregation. New 5G19A features in italic
Apart from making 5G connections possible at all in NSA deployments, the basic EN-DC features also allow
to transfer data simultaneous on both LTE and 5G side, and this will potentially increase the throughput.
The most important parameters are listed in Table 68. The best settings for some of the parameters is not
immediately obvious, so more details are provided in the discussion below the table. There is also EN-DC
knowledge sharing material on Confluence, which provides useful comments about best parameter settings.
In the early networks, several performance problems have appeared when using downlink split mode –
these are discussed in more details in section 13.4.
Naturally, the capacity and performance of the LTE layer (use of 4x4 MIMO, 256QAM, good radio link
quality) is important, but this is outside the scope of this document – instead the LTE optimization guideline
should be consulted.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
111 / 178
Internal
© 2020 Nokia
Parameter
Object
Range
Default
Recommended
dataVolThreshold (not relevant,
see notes)
NRDCDPR
1 to 65 536
kBytes
1024 kBytes
---
actDynTrigLteNrDualConnectivit
y
LNBTS
False / true
False (0)
True (1)
b1TriggerQuantity
NRDCDPR
RSRP, RSRQ
RSRP
RSRP
b1ThresholdNrRsrp
NRDCDPR
-156...-29 dBm
b1TimeToTriggerRsrp
NRDCDPR
0 to 5120 ms
256 ms
256 ms
dlFlowControlAlgo
NRBTS
nokiaFlowControl
,
3gppFlowControl
nokiaFlowCont
rol
3gppFlowContro
l
dlDataSplitMode
NRBTS
dlOverF1U,
dlOverX2U ,
dlOverF1UX2U
dlOverF1UX2U
dlOverF1UX2U
dlDataSplitGainThreshold
NRBTS
1% - 100%
5%
5%
actDlDataForwardingX2
NRBTS
False / true
True
True
actDlDataForwardingX2Limit
NRBTS
False / true
False
False
maxTransferDelayX2
NRBTS
1...100 ms
20 ms
20 ms
minThFlowCtrlX2
NRBTS
1..20 Mbps
1 Mbps
1 Mbps
dddsPeriodX2
NRBTS
5..50 ms
10 ms
10 ms
queuingDelayDiscardEnabled
NRBTS
False / true
True
False
pdcpBufDiscardThreshold
NRBTS
100 to 100000
20000
25000
initialDLTrafficRouting
NRBTS
initDLoverF1U /
initDLoverX2U
initDLoverX2U
initDLoverX2U
ulDataPath
NRBTS
ulOverLte,
ulOverNr,
ulOverLteNr
ulOverLteNr
cmWave:
ulOverLteNR;
mmWave:
ulOverLte
ulDataSplitThreshold
NRBTS
Numerous
possibilities
100 (infinity)
100 (infinity)
actDynUlDataSplitMode
NRCELL
False / true
False
False
rloSinrThreshold
NRCELL
-20…30 dB
0 dB
-4.5 dB
rloPathLossThreshold
NRCELL
80…160 dB
130 dB
130 dB
rlResumeSinrThreshold
NRCELL
-20…30 dB
10 dB
-3 dB
rlResumePathLossThreshold
NRCELL
80…160 dB
110 dB
110 dB
28-Jan-2020 ULITPALIL5R3-1390467857-6948
112 / 178
Internal
See notes
© 2020 Nokia
Parameter
Object
Range
Default
Recommended
rloConsecDtxThreshold
NRCELL
1…10
2
2
rloDtxRatioThreshold
NRCELL
1…100
50
50
a5Threshold1SsbRsrp
NRCELL
---
---
See notes
l2IngressRate
EQM
0 to 25 Gbps
---
10 Gbps
Table 68: Main parameters to control the behavior of the split bearer functionality
dataVolThreshold: The original intention of this parameter was to only allow EN-DC capable UEs with a large
amount of data to transfer to use 5G. However, this functionality has been postponed until in LTE20A
(LTE5003: Data buffer trigger for EN-DC). In LTE19 and LTE19A, the bit pattern of this parameter is instead
used to control
•
If measurement gaps are configured for B1 measurements (see section 5.4 and chapter 12)
•
If intra-cell HO is performed when data bearer id has run low (see section 5.3 )
•
If ongoing VoLTE calls influences EN-DC setup (see section 12)
This parameter is not present in LTE19B.
ulDataPath: This parameter determines if the user plane data is sent via the 5G leg, via the LTE leg or via
both legs simultaneously. Factors to take into consideration when deciding on the value include:
•
Uplink link budget: If the 5G carrier frequency is (much) higher than the LTE anchor carrier
frequency, it can be difficult to achieve good enough uplink 5G SINR. Especially for mmWave
frequencies this can be a challenge and using LTE to carry the uplink user plane data can reduce
the problem
•
Is 5GC001200: Dynamic uplink data split mode available? If yes, this provides another way to avoid
potential uplink SINR issues
•
Latency: If “ulOverLTE “is used, user plane latency will be higher because the UL packets gets
additional delay from the transmission on X2 interface. A higher latency may also lead to lower TCP
throughput because the TCP slow start period is prolonged
•
LTE congestion: If the LTE uplink anchor carrier is congested, it may be better to avoid loading it
further
•
Achievable UL throughput: Although the LTE anchor carrier will typically have smaller bandwidth
than the 5G carrier, the LTE may use FDD transmission so the full bandwidth can be used for uplink
transmission, and therefore the available uplink LTE bandwidth can be higher than the uplink part
of the 5G TDD signal
•
UE capabilities: Not all UEs support simultaneous transmission on LTE and 5G. If not, they will use
5G even if ulDataPath has been set to “ulOverLteNr”
Probably the best settings will be to use “ulOverLteNr“ to maximize uplink throughput and latency in good
radio conditions and rely on 5GC001200: Dynamic uplink data split mode to save the performance in bad
28-Jan-2020 ULITPALIL5R3-1390467857-6948
113 / 178
Internal
© 2020 Nokia
radio conditions. However, it needs to be verified that this is really the case in the network. Figure 31 shows
an example where using “ulOverNR” unexpectedly lead to so bad performance that even the downlink
throughput was degraded (TCP protocol was used in this case, so bad uplink performance causes delay in
TCP ack messages which in turn causes the server to throttle the downlink throughput).Figure 32 shows
another example where the uplink throughput has been measured while walking away from the 5G site into
an area with no 5G coverage. This was first done with “ulOverNR” and then with “ulOverLTE”. The results
from this particular network shows that the “ulOverLTE” setting gives higher throughput even in good 5G
coverage and the difference gets bigger as the 5G coverage deteriorates.
Note that if ulDataPath is set to “ulOverLTE”, the uplink 5G radio channels will still be used to carry:
•
PUSCH: UL RLC acknowledgements for the downlink RLC data
•
PUSCH: Power Headroom Reports (PHR)
•
PUSCH: Dummy data packets in case proactive UL scheduling is used
•
PUCCH: Periodic CSI reports
Figure 31: Comparison of Ookla Speedtest performance with different values of the ulDataPath parameter. Reason for the bad
performance with UL-over-NR is not completely understood but could be due to a UE issue. 5G19A, 600 MHz
28-Jan-2020 ULITPALIL5R3-1390467857-6948
114 / 178
Internal
© 2020 Nokia
Figure 32: Comparison of uplink throughput when ulDataPath is set to “ulOverLTE” and when it is set to “ulOverNR”. Walktest away
from a single 5G site, 3.5 GHz, 5G19.
dlDataSplitMode: Generally, it is recommended to set this parameter to “dlOverF1UX2U”, so the DL user
throughput is maximized. However, numerous problems have been observed in early networks when the
downlink data is sent via X2 interface, so if the 5G bandwidth is large compared to the 4G bandwidth, the
end-user throughput can actually be higher and more stable if the “dlOverF1U” setting is used. These
problems are described in more details in section 13.4. During optimization, data transfer must be tried with
both settings, and if the “dlOverF1UX2U” setting gives worse results, further troubleshooting must be done.
Note that if the 5G bandwidth is much smaller than the aggregated LTE bandwidth (this is typically the case
when 5G is deployed in low-band FDD frequencies), it is not a practical option to use “dlOverF1U” because
the downlink throughput will suffer too much.
actDynTrigLteNrDualConnectivity: In most cases, this feature should be enabled. The main reason is that if
SgNB addition is attempted with a very low 5G radio signal, the 4G throughput will be degraded while the
UE is unsuccessfully trying to complete the 5G RACH procedure. This is illustrated in Figure 14.
b1ThresholdNrRsrp should therefore be set to a value such that it is likely that the UE is able to complete
the 5G RACH procedure without problems (see section 5.4 for examples of different settings). However, in
some scenarios, it will be almost certain that there is sufficient 5G coverage. This could for example be
certain indoor cells, or macro cells where the 5G is on the same frequency and using the same antennas as
the LTE anchor cell. For latency purposes, it can in these cases be considered to disable the feature and do
a fast, blind addition.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
115 / 178
Internal
© 2020 Nokia
a5Threshold1SsbRsrp: In 5G19A, this parameter (together with R&D parameters) controls the behavior of
5GC001954: Introduction of A2 based SgNB release, i.e. the release of the 5G leg if the 5G RSRP becomes
bad. It is likely that if the 5G link is bad, there will be RLC retransmissions (which causes packet delays) and
this can lead to delayed TCP acks and therefore reduced TCP throughput. It may be better to release the
5G connection in such a scenario and rely on a good LTE performance.
KPI id
KPI name
KPI formula
NR_5140b
5G F1 data split ratio in downlink
DL_VOL_SNT_F1_QoS_GRP_01..20 /
(DL_VOL_SNT_F1_QoS_GRP_01..20 +
DL_PDCP_VOL_SNT_X2_QOS_GRP_01..20)
NR_5141b
5G F1 data split ratio in uplink
UL_VOL_RCV_F1_QoS_GRP_01..20 /
(UL_VOL_RCV_F1_QoS_GRP_01..20 +
UL_PDCP_VOL_RCV_X2_QOS_GRP_01..20)
Table 69: Most relevant KPIs to monitor the basic EN-DC carrier aggregation. F1 interface counters are also available in case of
Classical BTS configuration (the F1 is an internal interface in that case)
9.4.2
LTE carrier aggregation
If the 5G bandwidth is small, for example only 10 MHz, it is important that LTE carrier aggregation can be
done, otherwise it is quite likely that LTE handsets can achieve higher throughput than 5G handsets. For
example, a LTE handset may be able to aggregate 20 MHz + 15 MHz + 5 MHz, while a 5G handset can
only aggregate 10 MHz (5G) + 20 MHz (LTE anchor carrier).
Feature id
Feature name
LTE4575
Blind Carrier Aggregation with LTE-NR DC Option 3X
CRL-30195
EN-DC LTE CA Optimization For xL19A
LTE4549
Flexible LTE CA with EN-DC
Table 70: Features related to LTE carrier aggregation on EN-DC connections
LTE4575 allows to aggregate several downlink LTE carriers when an EN-DC connection is in use. It does not
allow to aggregate uplink carriers. Not all possible band combinations are allowed by 3GPP when EN-DC is
in use, and of the 3GPP band combinations, not all may be supported by the UE. The parameter guideline
material has more details on the possible band combinations. From this, it can be deduced how useful the
feature will be in a given network with a given UE.
In LTE19 and LTE19A implementations, the LTE carrier aggregation needs to be done before the SgNB
addition. If the SgNB addition is very fast, the LTE carrier aggregation will not take place. It can therefore be
necessary to either speed up the LTE carrier aggregation or delay the SgNB addition. From lab tests with
28-Jan-2020 ULITPALIL5R3-1390467857-6948
116 / 178
Internal
© 2020 Nokia
one operator, the conclusion is that the best method is to delay the SgNB addition. This naturally has the
negative consequence that a larger part of the data will be transferred on LTE where even the combined
carrier aggregation throughput may be lower than the achievable 5G throughput.
If the 5G bandwidth is large (e.g. 100 MHz) and if only smaller data amounts need to be transferred (for
example when using Ookla Speedtest), there is therefore an argument that the SgNB addition should
happen as fast as possible, even if it means that LTE carrier aggregation then does not happen. This also
means that a higher part of the LTE traffic is offloaded to 5G. On the other hand, if the 5G bandwidth is
small (e.g. 10 MHz), it may be better to do the LTE carrier aggregation first, even if it means that Ookla
Speedtest finishes before the SgNB addition takes place.
In LTE19B, LTE4549: Flexible LTE CA with EN-DC means that delaying the SgNB addition is no longer needed.
Table 71 lists the parameters which can be tuned.
Parameter
Object
Range
Default
Alternative values
actCAggrLteNrDualConnec
tivity
LNBTS
disabled,
blind_CA_LTE_NR,
enhanced_CA_LTE_NR
Disabled
blind_CA_LTE_NR,
enhanced_CA_LTE
_NR
tmpActFeat1
LNBTS
Bitmap of 32 bits
All 0’s
Set bit 3 and bit 4
(see notes below)
b1TimeToTriggerRsrp
NRDCD
PR
0 to 5120 ms
256 ms
512 ms, 1024 ms,
2560 ms
sCellActivationMethod
LNBTS
nonGBRBufferBased,
blind,
nonGBRBufferBasedStep
Wise
nonGBRBuffe
rBased
Blind
sCellActivationCyclePeriod
LNBTS
0.001 s – 16 s
2s
0.5 s
scellActivationLevel
LNBTS
0.1 TTI – 20 TTI
1 TTI
0.1 TTI
Table 71: Parameters which can be used to tune the LTE carrier aggregation procedure
In LTE19A, the CRL-30195: EN-DC LTE CA Optimization For xL19A allows the eNB to ignore B1 measurement
reports from the UE until the LTE carrier aggregation has happened. This is done by changing the
tmpActFeat1 bit pattern such that bit 3 (prevents 5G SCell Addition until 4G CA is configured) and bit 4
(prevents 4G Secondary Cell release due to inactivity while 5G Secondary Cell is configured) is set. Note that
it is important to keep this feature deactivated at sites where 4G Carrier Aggregation is not supported
otherwise 4G BTS will never trigger 5G Secondary Cell Addition.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
117 / 178
Internal
© 2020 Nokia
As shown in Figure 33, the LTE carrier aggregation can take several seconds, so it needs to be carefully
considered if the benefits of LTE carrier aggregation can compensate for the delay in SgNB addition.
Figure 33: Example of SgNB addition time in cases where CRL30195 forces the eNB to wait with SgNB addition until the LTE carrier
aggregation is complete (“HO1” – “HO4” cases). The LTE carrier aggregation can take several seconds. 5G19A / LTE19A.
The easiest way to determine if the LTE carrier aggregation happens is to use a drive test tool, where the
used LTE carriers can be directly observed. The LTE carrier aggregation counters do not distinguish between
legacy LTE connections and EN-DC connections, so the behaviour of EN-DC connections will likely be
hidden.
9.4.3
5G carrier aggregation
Feature id
Feature name
5GC000527
Intra-band Carrier Aggregation TDD FR2 up to 2CCs
5GC000720
Asymmetric Carrier Aggregation
5GC001725
Intra-band Carrier Aggregation TDD FR2 up to 4CCs DL
5GC001547
Supplemental downlink cell - FR2
5GC001831
Intra-band CA TDD FR2 up to 4CCs DL - 2CCs UL
5GC001836
Spillover from 5GC000480 Radio Admission Control for NSA mode 3x operation
Table 72: Features related to 5G carrier aggregation. 5G19A features in italic
The achievable throughput roughly scales with the available bandwidth. This means that if for example 4 x
100 MHz is available instead of 100 MHz, the achievable throughput is quadrupled. Note that this is the case
in both good and bad radio conditions. This makes the carrier aggregation features a very efficient and
easy way to increase the throughput, and these should be used in all the cases where the bandwidth is
available for the operator.
These features, their parameters and how to monitor their performance is described in more detail in section
13.2. In 5G19A, they only work on the 28 GHz and the 39 GHz bands.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
118 / 178
Internal
© 2020 Nokia
9.4.4
Link adaptation
Feature id
Feature name
5GC000517
Uplink and Downlink link adaptation
5GC000522
256 QAM for PDSCH
5GC001347
Additional DMRS configuration
5GC001875
Spillover - 256QAM
Table 73: Features related to 5G link adaptation. 5G19A features in italic. 5GC001875 is introduced only to test some cases which were
not tested in 5G19
The link adaptation algorithm makes the selected modulation and coding scheme follow the changing radio
link conditions. This is important especially for the scenario where the UE is moving and is discussed in more
detail in the chapter on mobility optimization. However, especially the initial coding scheme can have an
impact upon the throughput performance. This is because many data transfers are very short and do not
allow time for the MCS to ramp upwards from the initial value. It is necessary to be conservative with the
initial value because it is applied prior to the gNB having good knowledge of the radio conditions.
The min / max / stepdown parameters decide how quickly and how well the MCS follows the radio
conditions. It is possible that cells with high mobility UEs may benefit from other settings than cells with
mainly stationary UEs but systematic tests have not yet been carried out.
In 5G19, it is only the radio conditions which decide the MCS. If there is only a small packet to be sent, which
would fit into e.g. a MCS0 transport block, and the radio conditions allow a higher MCS, it will be the high
MCS that is chosen, and the rest of the transport block is simply filled with padding bits.
In 5G19A, the scheduler will downgrade the MCS if a small packet needs to be transmitted and, in this way,
achieve a more robust transmission. Furthermore, the uplink PRB allocation can be reduced to achieve even
more robust transmission and the downlink transmit power can be reduced so interference towards other
cells is minimized.
The basic link adaptation feature (5GC000517) can choose between QPSK, 16QAM and 64QAM modulation
for PDSCH and PUSCH and in all frequency bands. 5GC000522 allows to also choose 256QAM for PDSCH
in the sub-6 GHz frequency range. It should be noted that when 256QAM is enabled, the consequence is
not only that 256QAM modulation becomes possible, but the whole mapping table between radio link
conditions and modulation and coding scheme is changed.
Practical experience from early 5G19 networks has shown that it is difficult to achieve 256QAM modulation
together with 4x4 MIMO. The consensus is that 5G19’s use of a single DMRS symbol is not enough to allow
the UE to create a channel estimate which is accurate enough for 256QAM. In some cases, the throughput
has even decreased when the 256QAM mapping table is activated. Although it is the official
recommendation, there is no clear evidence in 5G19 that activating 256QAM will improve the throughput
performance when it is used together with 4x4 MIMO. However, there is clear benefit of 256QAM if only
2x2 MIMO is used.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
119 / 178
Internal
© 2020 Nokia
In 5G19A, it is possible to use one additional symbol for the DMRS. When additional DMRS symbol is
configured, the system performance is improved but with a cost of higher reference signal overhead. The
performance improvement comes from better channel estimation and frequency offset estimation. If higher
256 QAM MCSs cannot be reached by UEs using only one DMRS, then usage of the additional DMRS may
increase the throughput by up to~20% by enabling use of higher modulation order. If UE is not moving
and has no big frequency offset, the additional DMRS would reduce throughput due to higher reference
signal overhead (up to 14%, depending on the slot configuration).
Parameter
Object
Range
Default
Recommended
ullaIniMcs
NRCELL
0 – 28
0
0
dllaIniMcs
NRCELL
0 – 28
3
3
ullaBlerTarget
NRCELL
1% - 99%, step 1%
10%
3%
dllaBlerTarget
NRCELL
1% - 99%, step 1%
10%
10%
ullaDeltaSinrMax
NRCELL
0...15, step 0.1
3
15
ullaDeltaSinrMin
NRCELL
-15...0, step 0.1
-3
-15
ullaDeltaSinrStepdown
NRCELL
0...1.000, step 0.001
0.25
0.25
dllaDeltaCqiMax
NRCELL
0...15, step 0.1
3
15
dllaDeltaCqiMin
NRCELL
-15...0, step 0.1
-3
-15
dllaDeltaCqiStepdown
NRCELL
0...1.000, step 0.001
0.25
0.25
actDl256Qam
NRCELL
Disabled / enabled
Disabled
FR1: Enabled
dlQam256PowerBackoffSub6
NRCELL
0.0...10.0, step 0.1 dB
1.5 dB
Between 0 dB and
3 dB, depending
on RU
ulDMRSAdditionalPosition
NRCELL
0, 1, 255 (automatic)
255
255, expect for
low-band FDD (0)
dlDMRSAdditionalPosition
NRCELL
0, 1, 255 (automatic)
255
255, expect for
low-band FDD (0)
Table 74: Parameters related to link adaptation
Measurement id
Measurement name
Contents
M55300
NR DL HARQ
M55302
NR UL HARQ
For each MCS, the number of transport blocks is
counted: Initial transmissions, successful initial
transmissions, failed transmissions, so the MCS
distribution and the initial and residual BLER can be
calculated
28-Jan-2020 ULITPALIL5R3-1390467857-6948
120 / 178
Internal
© 2020 Nokia
Measurement id
Measurement name
Contents
M55301
NR DL Signal Quality
Level
Counters for MCS transmitted blocks for each MIMO
rank
M55303
NR UL Signal Quality
Level
M55304
NR MAC PDU
throughput
Volume (initial and retransmitted) for each MCS
Table 75: Measurements containing counters related to link adaptation. The individual counters are too numerous to list
9.4.5
MIMO
Feature id
Feature name
5GC000531
DL SU adaptive MIMO
5GC000532
UL SU adaptive MIMO
5GC000605
DL SU adaptive 4x4 MIMO (open loop)
5GC000920
DL 4x4 SU MIMO without beamforming (open loop)
5GC001870
DL SU adaptive 4x4 MIMO
5GC001983
Spillover UL SU adaptive MIMO
Table 76: Features related to 5G MIMO. 5G19A features in italic
In principle, MIMO promises similar advantages as carrier aggregation: Instead of using more carriers, MIMO
transmits multiple “layers” within the same carrier and in this way the throughput can be boosted. The crucial
difference is that where carrier aggregation is not depending on radio conditions, MIMO definitely depends
on the radio conditions.
In 5G19A, only single-user MIMO is supported. The main focus in the early networks is to increase the user
throughput, but the user of multiple layers is of course also providing a cell capacity benefit.
With downlink 2x2 MIMO, the practical network behavior is straightforward: When the UE is close to the site
in good radio conditions, rank 2 is used because a single beam can carry two uncorrelated layers due to
cross polarization. When the UE is at cell edge in bad radio conditions, it becomes more advantageous to
transmit the same data stream is both paths and rank 1 is used. This is illustrated in Figure 35.
With 4x4 MIMO (optionally used for PDSCH in sub-6 GHz frequencies) the behavior is more complex,
because two beams are needed in order to have 4 layers, and the “sweet spots” where two uncorrelated
beams are available with good radio link quality are not big, so do not have big impact on OSS KPIs and
they are hard to find when doing field testing. Some projects have even resorted to creating their own
sweet spot by placing reflectors (parked cars) around the UE. The use of additional DMRS symbol in 5G19A
seems to have made it easier to get simultaneously high rank and high MCS.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
121 / 178
Internal
© 2020 Nokia
If passive antennas not supporting beamforming are used, the 5GC000920: DL 4x4 SU MIMO without
beamforming (open loop) feature must be used to get the 4x4 MIMO benefits. There is not yet experience
with using this feature.
For 2x2 MIMO, it is possible to choose between open loop and closed loop feedback. When closed loop
feedback is used, the UE is suggesting the best pre-coding matrix in order to minimize the correlation
between the layers. Generally, it is recommended to use closed-loop feedback, but there can hypothetically
be some scenarios where the open-loop feedback gives better performance, for example where the
feedback is unreliable due to very fast changing channel conditions. In 5G19A, 4x4 MIMO is only available
with “open loop” feedback. The use of closed loop feedback (i.e. with the UE suggesting the best pre-coding
matrix to the BTS) is expected to be available in 5G19B.
Generally, the use of 4x4 MIMO gives better performance than 2x2 MIMO, so it is definitely recommended
to use the feature, but high occurrence of rank 4 should not be expected in 5G19, especially not in
combination with high MCS. Increasing the rank 4 share has so far mostly been done by R&D optimization
of the antenna beam patterns.
Note: All the smartphone UEs currently available in the market (as of January 2020) have only one single
5G Tx meaning that they have only one transmit antenna for 5G (and usually another common one for
4G/3G/2G). These UEs cannot perform UL MIMO2x2, and will be limited to UL MIMO1x2 (1 Tx at UE side +
2 Rx at gNB side).
5GC001983: Spillover UL SU adaptive MIMO enables UL 2x2 MIMO in the BTS. Trial functionality will come
with the 5G19A MP2.0 package.
Parameter
Object
Range
Default
Recommended
dlMimoMode
NRCELL
30:2x2 Closed Loop Spatial
Multiplexing;
2x2 Closed Loop
Spatial
Multiplexing
cmWave: 4x4 or
4x2 Open Loop
Spatial
Multiplexing
40:4x4 or 4x2 Closed Loop
Spatial Multiplexing;
mmWave: 2x2
Closed Loop
Spatial
Multiplexing
50:2x2 Open Loop Spatial
Multiplexing;
60:4x4 or 4x2 Open Loop
Spatial Multiplexing
ulMimoMode
NRCELL
20: Closed loop Spatial
Multiplexing (2x2)
nrCellType
NRCELL
20: 2DL0UL
28-Jan-2020 ULITPALIL5R3-1390467857-6948
122 / 178
Internal
FDD: 2x2 Closed
Loop Spatial
Multiplexing
Closed loop
Spatial
Multiplexing (2x2)
Closed loop
Spatial
Multiplexing (2x2)
Aligned with
settings of
© 2020 Nokia
Parameter
Object
Range
Default
21: 2DL1UL
22: 2DL2UL
Recommended
dlMimoMode and
ulMimoMode
24: 2DL4UL
42: 4DL2UL
44: 4DL4UL
82: 8DL2UL
84: 8DL4UL
88: 8DL8UL
168: 16DL8UL
1616:16DL16UL
Table 77: MIMO parameters. Closed loop 4x4 is not supported in 5G19A
Figure 34: Drive test around a 2.6 GHz AAHF site where the PDSCH rank is plotted. 5G19.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
123 / 178
Internal
© 2020 Nokia
Figure 35: Lab test, AZQL, 5G19, DL 2x2 MIMO. It can be observed that when the RSRP decreases, downlink rank changes from rank
2 to rank 1
Counter id
Counter name
Comment
M55301C09001..2
PDSCH_2TX_RI_00..02
M55301C10001..4
PDSCH_4TX_RI_01..04
Used to calculate the share
of each rank
M55303C04001..2
PUSCH_CP_2TX_RI_01..02
M55301C04000..03
PDSCH_RANK1_PMI_00..03
M55301C05000..02
PDSCH_RANK2_PMI_00..02
M55303C02000..05
PUSCH_CP_RANK1_PMI_00..05
M55303C03000..02
PUSCH_CP_RANK1_PMI_00..02
M55301C00000..28
PDSCH_RANK1_64TBL_MCS_00..28
M55301C01000..28
PDSCH_RANK2_64TBL_MCS_00..28
M55301C02000..28
PDSCH_RANK3_64TBL_MCS_00..28
M55301C03000..28
PDSCH_RANK4_64TBL_MCS_00..28
M55303C00000..28
PUSCH_CP_RANK1_64TBL_MCS_00..28
M55301C15000..28
PDSCH_RANK1_256TBL_MCS_00..28
M55301C16000..28
PDSCH_RANK2_256TBL_MCS_00..28
M55301C17000..28
PDSCH_RANK3_256TBL_MCS_00..28
28-Jan-2020 ULITPALIL5R3-1390467857-6948
124 / 178
Internal
Used to calculate the share
of each possible precoding matrix
For each rank, the MCS
distribution can be
calculated
© 2020 Nokia
Counter id
Counter name
M55301C18000..28
PDSCH_RANK4_256TBL_MCS_00..28
M55303C01000..28
PUSCH_CP_RANK2_64TBL_MCS_00..28
Comment
Table 78: Most relevant counters to study MIMO behavior
Figure 36: Example of MSC distribution for the four PDSCH ranks, Drive test around single 2.6 GHz AAHF site, 5G19. Note the different
y-scale charts: Rank 1 and rank 2 are only used very little
9.4.6
QoS-based scheduling
Feature id
Feature name
5GC000776
non GBR service differentiation
Table 79: Features related to QoS-based scheduling
From 5G19A onwards, it is possible to use 5GC000776: non GBR service differentiation to provide higher
priority to certain QoS classes. This means that a particular QoS class (identified by its QCI) can be scheduled
more frequently (and therefore get higher throughput) at the expense of the other QoS classes. This feature
works for both downlink and uplink scheduling.
The feature only has an effect if there is actually congestion in the cell, i.e. if 2 or more UEs are waiting to
be scheduled in the same slot. The feature can increase (or decrease) the user throughput. The cell
throughput is not changed.
Parameter
Object
Range
Default
Recommended
actNonGbrServiceDiff
NRBTS
False / true
False
True
28-Jan-2020 ULITPALIL5R3-1390467857-6948
125 / 178
Internal
© 2020 Nokia
Parameter
Object
Range
Default
Recommended
qciTab5Nsa3x: schedulWeight
NRBTS
1...100, step 1
40
40
qciTab6Nsa3x: schedulWeight
NRBTS
1...100, step 1
20
20
qciTab7Nsa3x: schedulWeight
NRBTS
1...100, step 1
10
10
qciTab8Nsa3x: schedulWeight
NRBTS
1...100, step 1
5
5
qciTab9Nsa3x: schedulWeight
NRBTS
1...100, step 1
1
1
qciTab69Nsa3x: schedulWeight
NRBTS
1...100, step 1
40
40
qciTab70Nsa3x: schedulWeight
NRBTS
1...100, step 1
30
30
qciTab79Nsa3x: schedulWeight
NRBTS
1...100, step 1
15
15
Table 80: Parameters related to QoS-based scheduling. High scheduling weight means high priority (frequent scheduling)
There are no PM counters which directly can be used to monitor the effect of QoS-based scheduling. The
user plane counters for the upper protocol layers are available for each QoS group, and it can for example
be monitored how much payload is transferred or how many packets are dropped. However, for low
congestion levels it will probably be difficult to see the impact (if one particular UE is not scheduled in a
given slot due to low QoS priority, it may simply get a slot a few ms later).
9.5
Frame structure
The maximum achievable downlink throughput is depending on how many slots and symbols there are
available for PDSCH. Likewise, the maximum achievable uplink throughput is depending on how many slots
and symbols there are available for PUSCH. The configuration of the frame structure has therefore an impact
on the achievable throughput. Table 81 lists the relevant parameters. Some of them, for example frame
structure type and UL:DL ratio, are typically fixed for a given network (at least in the macro layer – it is
possible that special, well-isolated cells such as indoor cells may have their own settings), while others, like
SS Burst Set period and CSI-RS tracking period, can be tuned across the network.
The NR throughput tool (explained in more details in Network Engineering material on Theoretical
throughput and impacting factors in 5G) allows to calculate the achievable throughput with a given frame
structure. The tool makes it easy to calculate the negative effects of a higher signalling overhead but does
not give information about the benefits. For field tests in good, stationary radio conditions, the more slots
that are used for PDSCH / PUSCH transmission, the higher the throughput will be. On the other hand, it is
often needed to also have good performance at cell edge and in mobility situations. For example, using a
single beam (and therefore a single set of SSB) will give high throughput in good radio conditions, but in
order to serve the cell edge, it may be better to use for example 8 beams to provide better coverage despite
the higher SSB overhead. There are various parameters which impact the scheduling of non-PDSCH / nonPUSCH blocks; there are no “best values”, since values that optimize one aspect, for example throughput in
stationary conditions, will jeopardize other aspects, for example throughput in mobility scenarios. Table 81
28-Jan-2020 ULITPALIL5R3-1390467857-6948
126 / 178
Internal
© 2020 Nokia
lists the most important parameters and Table 82 and Table 83 show impact of selected settings on the
theoretical throughput in good radio conditions.
Parameter
Range
Impacts
Considerations
frameStructureType
1:flexible;
2:semiStatic;
3:tdLte
DL & UL
Probably fixed for all macro cells
ulDlDataSlotRatio
3:7, 1:4
DL & UL
Probably fixed for all macro cells
guardPeriodLength
1, 2, 3, 4 symbols
DL
Probably fixed for all macro cells
numberOfTransmittedSsBlocks
1 – 32 beams
DL
Match with desired number of
beams
SSBurstSetPeriod
10 - 160
DL
High values mean slower
acquisition / detection times.
Recommendation: 10 for single
beam, 20 for multiple beams
PRACHConfigurationIndex
Many possibilities
UL
Depends on frame structure and
desired RACH capacity
csirsTrackingPeriod
Off, equal to
ssBurstSetPeriod,
10 – 80 ms
DL
The higher the period, the less
updated will the UE’s CSI
measurements be.
Recommendation: 80 ms
ulDMRSAdditionalPosition
0, 1, 255
(automatic)
DL
dlDMRSAdditionalPosition
0, 1, 255
(automatic)
UL
Using additional symbol for DMRS
improves the receivers channel
estimate and therefore the
performance, especially in dynamic
conditions
Table 81: Most relevant parameters which impact the scheduling of non-PDSCH / non-PUSCH blocks. The “recommended” value is
typically a compromise between conflicting aspects and the best value needs to be decided from network to network. Although the
first three parameters will probably be fixed in the macro layer, it is possible to have different values in well-isolated cells, e.g. indoor
cells.
UL:DL slot ratio
Nbr of beams
SS Burst set period
DL throughput (Mbps)
3:7
1
10 ms
641
3:7
1
160 ms
707
3:7
8
10 ms
504
3:7
8
160 ms
690
1:4
1
10 ms
769
1:4
1
160 ms
835
28-Jan-2020 ULITPALIL5R3-1390467857-6948
127 / 178
Internal
© 2020 Nokia
UL:DL slot ratio
Nbr of beams
SS Burst set period
DL throughput (Mbps)
1:4
8
10 ms
620
1:4
8
160 ms
818
Table 82: Theoretical downlink throughput in good radio conditions depending on parameter settings. Values only selected for
illustrative purposes. The reader is encouraged to try different values in the throughput calculation tool. Assumption for other
parameters: FR1, semi-static, guard period = 2 OFDM symbols, CSI-RS tracking period = 40 ms, 100 MHz bandwidth, DL 2x2 MIMO,
256QAM, single carrier, 0% BLER
UL:DL slot ratio
Nbr of beams
PRACH configuration index
UL throughput (Mbps)
3:7
1
98
221
3:7
1
162
161
3:7
8
98
221
3:7
8
162
161
1:4
1
98
141
1:4
1
162
80
1:4
8
98
141
1:4
8
162
80
Table 83: Theoretical uplink throughput in good radio conditions depending on parameter settings. Values only selected for illustrative
purposes. The reader is encouraged to try different values in the throughput calculation tool. Assumptions for other parameters: FR1,
semi-static, guard period = 2 OFDM symbols,100 MHz bandwidth, UL 2x2 MIMO, 64QAM, single carrier, 0% BLER. Note that number
of beams do not impact UL throughput (although there is impact on RACH capacity)
Figure 37 shows an example where the performance with 2 beams is compared to the performance with 6
beams. The data is collected by drive testing in a small cluster. Using six beams (with either beamset_6 or
beamset_5_1) gives better RF performance (better S/N) but the extra SSB overhead caused by using 6 beams
means that the throughput is actually degraded. It is possible that indoor users are benefitting more from
the better RF signal but at least from drive test perspective, it is better to use few beams. This illustrates that
it is not always obvious how the frame structure should be defined, and local tests are often needed.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
128 / 178
Internal
© 2020 Nokia
Figure 37: Drive test in 3.5 GHz cluster. The performance using two beams versus six beams is compared. 5G19A PT3.3. Six beams
give better RF signal but less throughput due to the increased SSB overhead.
9.5.1
Multiplexing between control information and PDSCH / PUSCH data
Feature id
Feature name
5GC002535
FDM of DMRS and PDSCH
Table 84: Features to multiplex control information and PDSCH / PUSCH data
In most cases, it is not possible to multiplex the data carried by PDSCH or PUSCH channels into the slots
with carry reference signals or other control information. This means that the “signaling overhead” can be
rather large. Features addressing this issue is planned for the later 5G BTS releases but there are already
some possibilities in 5G19 and 5G19A.
Multiplex DMRS and PDSCH:
5GC002535: FDM of DMRS and PDSCH is a late addition to 5G19A which allows to multiplex PDSCH data
into the symbol used for DMRS. This is only possible in the following conditions:
•
FDD cells
•
256QAM is used
•
Only 2x2 MIMO in use
28-Jan-2020 ULITPALIL5R3-1390467857-6948
129 / 178
Internal
© 2020 Nokia
When DMRS is not multiplexed with data in the same symbol it is boosted by 3dB assuring good
demodulation performance also in "deep" coverage. However, the throughput is reduced. When DMRS is
multiplexed with data in the same symbol the throughput is increased but there is no 3dB boosting.
Therefore, FDM will be limited to 256QAM modulation and coding schemes in 5G19A because it is assumed
that for 256QAM usage the SINR is already at a high level not endangering demodulation performance due
to coverage.
The throughput gain in perfect radio conditions (256QAM always in use, no negative impact from the lack
of 3 dB power boosting) is 5% when 1 DMRS symbol is used and 10% when 2 DMRS symbols are used. The
achievable gain in live networks is not yet clear.
The feature is enabled by R&D parameter.
Multiplex UE CSI reports with UL HARQ ACK / NACK:
With default settings in 5G19, the CSI reports sent by the UE cannot be multiplexed with uplink HARQ
ACK/NACK: the gNB avoids scheduling in downlink if the corresponding uplink ACK/NACK would fall in the
same slot as a CSI report. This may have a high impact (up to 8%) on downlink throughput depending on
the value of csiReportPeriodicity (i.e. on the number of times CSI reports need to be sent).
To address this, FGCR 2650 Support of mux SR HARQ ACK CSI PUCCH same Symbol was added in late 5G19
to allow the multiplexing of SR, ACK/NACK and CSI report on the same PUCCH symbol. This needs to be
enabled by swconfig.txt file with following flag: 0x10003E=1 (and possibly 0x460181=1).
Even if FGCR 2650 is enabled, DL scheduling can still be impacted, due to “PR474594 : New Problem
Reported (5G19,, B Major,[5G19][classical][AEQD]DL Throughput falls down by around 8% when
csiReportPeriodicity = slots40)”: FGCR 2650 was not correctly coded, and multiplexing of SR, ACK/NACK and
CSI report is possible only if the number of bits is below 11.
In 5G19A, this multiplexing is enabled by default.
Figure 38: Illustration of the FGCR2650 problem: The slots marked with yellow are not used for PDSCH transmission because the UL
HARQ Ack/Nack would fall in a PUCCH symbol scheduled to be used for CSI reporting. This is only happening in 5G19.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
130 / 178
Internal
© 2020 Nokia
9.6
Optimization procedure
First, consider if the settings of the parameters described in the section 9.5 is the right compromise – on
network level as well as on individual cell level. For example, it might be possible that cells with mainly static
UEs can use longer SSB burst set period than cells with high-speed UEs.
Then perform the next level of performance analysis and decide if the main factor behind low throughput
is:
-
RF performance (see chapter 4 on RF performance optimization)
-
Congestion (see chapter 8 on capacity management)
-
Problems with mobility such as link adaptation or handover (see chapter 7 on mobility optimization)
-
User traffic pattern, e.g. chatting (small packets) versus high-definition streaming (large packets)
The KPIs listed in Table 85 can help in this analysis, although they are most useful when it comes to analysing
the pure 5G performance. If the LTE contribution to the user’s overall EN-DC throughput is important, it is
difficult to rely on PM counters alone because factors like how fast the LTE carrier aggregation happens
become important – currently only drive tests give the needed visibility for this.
KPI id
KPI name
Comment
NR_581a
Average MCS, DL 64QAM table
NR_582a
Average MCS, DL 256QAM table
NR_xxx
Average MCS, UL 64QAM table
---
MCS distribution, DL 64QAM table
---
MCS distribution, DL 256QAM
table
---
MCS distribution, UL 64QAM table
Low MCS results in low throughput. One likely
reason for low MCS is bad radio link conditions.
Another, especially in low traffic network, can
be the transmission of msg2 / msg3 which is
done with MCS0 in 5G19A. In case of many
small data transmissions, the initial MCS also
has a role. In 5G19A, MCS0 is used to transmit
small packets. Use the MCS distribution to
remove the effect of initial MCS settings and the
use of MSC0
NR_5054a
5G Initial BLER in downlink
transmissions in PDSCH
NR_5056a
5G Initial BLER in PUSCH using
64QAM MCS table
NR_5055a
5G Residual Block Error Ratio
(BLER) for PDSCH
NR_5057a
5G Residual BLER in PUSCH using
64QAM MCS table
NR_56a
5G DL RLC PDU retransmission
ratio by High RLC
NR_57a
5G UL RLC PDU retransmission
ratio requested by High RLC
28-Jan-2020 ULITPALIL5R3-1390467857-6948
131 / 178
Internal
These KPIs can indicate problems with the link
adaptation settings. Initial BLER shows the BLER
of the first transmission and should be related
to the BLER target parameter in the link
adaptation algorithm. Residual BLER shows the
status when all the allowed HARQ
retransmissions have been used – if residual
BLER is not 0%, retransmissions on the RLC
layer are needed
One reason for RLC retransmissions is that the
HARQ retransmission procedure has not
succeeded in delivering error-free blocks, and
this indicate problems in either the link
© 2020 Nokia
KPI id
KPI name
Comment
adaptation algorithm or simply very bad radio
link conditions
NR_583a
Share of different DL MIMO ranks
Use of high MIMO ranks means higher
throughput. However, especially for 4x4 MIMO,
it might be difficult to achieve high use since
this depends heavily on the multipath
conditions
NR_xxx
Average number of DL SCells
NR_xxx
Average number of UL SCells
This tells how well carrier aggregation is
working
NR_471a
5G Average number of scheduled
UEs per slot in DL
NR_472a
5G Average number of scheduled
UEs per slot in UL
NR_5042b
5G Intra gNB intra frequency
PSCell change total success ratio
Having more than 1 UE scheduled in the same
slot is a sign of congestion limiting the possible
connection throughput
Reliable handover procedure is often a
requirement in order to be able to maintain
good radio link quality and therefore high
throughput
Table 85: KPIs which can be helpful in identifying the causes for low throughput
If handover between 5G cells (either intra-gNB or inter-gNB) is not enabled, a possible scenario is that the
5G radio link quality is bad even though there is a better signal available from the neighbor cell. In such a
case, it will be better to release the existing connection and rely on B1 measurements to establish a new
connection to the neighbor cell.
Such a release can be triggered by 5GC001954: Introduction of A2 based SgNB release (see section 6.2) or
by adjusting the parameters for radio link failure detection such that the connection is quickly dropped due
to radio link failure.
Figure 39 illustrates how forcing a faster radio link failure (by reducing t310 from 2000 ms to 1000 ms and
reducing n310 from n10 to n6) resulted in higher end-user throughput during cluster drive test. This is
probably an extreme case because the 5G carrier frequency was 600 MHz (thus ensuring good overlap
between 5G cells for outdoor users) and 5G handover was not yet enabled in the network. This combination
makes it likely that a moving UE will relatively often experience 5G cell dragging.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
132 / 178
Internal
© 2020 Nokia
Figure 39: Improvement of end-user throughput by accelerating the detection of radio link failures. Note: No 5G handovers enabled
in the network. Cluster drive test. 5G19A, 600 MHz.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
133 / 178
Internal
© 2020 Nokia
10 Optimization of user plane latency
10.1
Introduction
User plane latency describes how long time it takes to send a packet with user information. The potential
low latency in 5G networks is often highlighted as one of the key advantages which 5G has over LTE.
Although achieving very low latency is not yet possible with the Nokia BTS (the “minislot” feature is required
for this), some operators have already started to pay attention to the user plane latency and wants to at
least understand the factors which may cause high latency.
Low latency is not only relevant for those services where a fast feedback to the user is needed (such as
virtual reality or robotic control) – all cases where TCP is used for the data transfer (web browsing, Ookla
Speedtest) can benefit from a low latency because this shortens the “TCP slow start” period.
Discussing latency can lead to much confusion because there are many different aspects. The important
points to be clear about are listed here:
•
This section is about user plane latency, where it is assumed that there is already a radio connection
available. If this is not the case (for example a ping is sent to a UE in idle mode), the radio connection
must first be established. The time to establish the connection is normally referred to control plane
latency and is not normally not considered to be part of the user plane latency
•
In many cases, the main concern is about the average latency, but there are also cases where it is one
of the percentiles, for example the 99% percentile which is important. Generally speaking, the average
latency can be improved via features and parameters while the high percentiles can be improved by
having a good RF and mobility performance
•
Latency can refer to both one-way latency and round-trip-time. Field measurements are typically
measuring round-trip-time because this is easier while features and parameters often only impacts
either downlink or uplink one-way-latency
•
Users are mostly interested in the end-to-end latency, and this is also the easiest to measure in field
tests, but to understand and improve the performance, it is necessary to break the E2E latency down
into components, for example RAN, core network and Internet/server components. This document
focuses on the RAN latency, which covers the path from the UE to the S1 interface. The reason that also
the midhaul (between DU and CU) is covered even though this really belongs to the Mobile Access
optimization service, is that it is difficult to exclude the midhaul component from the measurements
It is assumed that the packet size is relatively small such that the full packet can be transmitted in the first
available slot, even when the lowest MCS0 is used. If large amount of data needs to be quickly transmitted,
it is the throughput which should be optimized.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
134 / 178
Internal
© 2020 Nokia
10.2
Typical issues
The achievable latency strongly depends on how frequent the UE and the BTS are allowed to transmit. This
is determined by the network configuration, where factors such as slot duration, RACH configuration etc.
together decide how frequent transmission opportunities appear. Some of these factors, for example slot
duration, are often outside the control of the operator while others, like the scheduling interval, can be
more freely chosen by the operator, and it can even be expected that various configurations will be used in
the network.
Once a transmission opportunity appears, there is a certain probability that it will be allocated to another
user. As the traffic level in the cell rises, the probability for collision also rises and the latency for especially
the high percentile values increases.
Once the packet has been transmitted, it is important that it reaches the receiver without any need for
retransmissions. Retransmissions can happen in MAC and RLC layers (for example due to sudden
degradation of the radio link quality), in the PDCP layer (for example as a result of shifting the data stream
from one BTS to another) or in the higher layers like TCP layer (for example due to loss of the radio link).
In the early networks, it has been seen that there is also dependency on the UE implementation. For
example, the HiSilicon chip set can use the same slot for the UL RLC Ack (sent as response to the downlink
ping) and the ping reply. The Qualcomm chipset (Snapdragon X50) does not do this, and this means a few
ms faster ping RTT for the HiSilicon chipset.
10.3
Performance analysis
10.3.1
Field tests
An easy way to measure E2E RTT is to use the ping application. The pings can either be UE-originated or
server-originated. If possible, a S1-U trace should be taken, so the delays in the RAN can be isolated:
•
UE-originated pings: RAN RTT = E2E RTT (from UE log) – core/server RTT (from S1 trace)
•
Server-originated pings: RAN RTT directly visible in S1 trace
If S1 tracing is not possible during field tests, some other means should be used to determine the likely RTT
from S1 to the server, for example by pinging the server from the gNB-CU. If measurements are not available
at all, a 1 ms RTT between S1 and server can be assumed if the core network and the server is located close
to the BTS.
Note that synchronizing the S1 trace with the UE trace is not needed as long as it is only the RTT that needs
to be measured. Such synchronization is only needed if one-way latency must be measured.
Current experience with partly immature terminals is that test parameters like packet size, intervals between
pings, bypassing the operating system etc. all have impact on the measured RTT. A consensus has not yet
been reached on the “best practice” for doing ping tests.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
135 / 178
Internal
© 2020 Nokia
In order to properly characterize the “tail” of the latency distribution (for example the 99% percentile), a
large number of samples are needed, for example 1000 samples for the 99% percentile and 10000 samples
for the 99.9% percentile.
The Speedtest application is a popular tool for measuring the achievable throughput and consequently it is
also often used as a “quick-and-dirty” latency measurement tool. Speedtest measures RTT by sending a
small number of TCP packets (9 – 12 packets?) to a server and measure how fast the TCK acknowledgements
arrive. Speedtest then reports the acknowledgement with the smallest RTT. Since it is the smallest RTT that
is reported and not the average RTT, it can be expected that changing the scheduling parameters will not
have big impact.
Field tests are normally done with small packet sizes, for example 32 bytes. If larger packet sizes are used,
the initial uplink transmission may be segmented and sent in multiple RLC PDUs. The reason is that the
default resource allocation for proactive UL scheduling is for 60 bytes (16 PRBs if MCS0 is used). Such a
segmentation will of course lead to a higher transmission delay.
The disadvantages of doing field tests include at least following:
•
Costs
•
Not measuring the same locations as where the subscribers are (it can for example be difficult to
get access to indoor locations)
•
Unless there is already a test team in the field, there is no immediate feedback on the impact of
optimization actions
10.3.2
Interface traces
The most relevant interface to trace is the S1-U between the gNB and the SGW. By analysing the “TCP
handshake” timestamps, it is possible to calculate the RAN RTT and the core/server RTT for every started
TCP connection (Figure 40).
28-Jan-2020 ULITPALIL5R3-1390467857-6948
136 / 178
Internal
© 2020 Nokia
Figure 40: Illustration of how TCP handshake can be used to calculate RAN and core/server RTT
Since the RTT of every connection is available, it is straightforward to construct latency distributions. It may
even be possible to capture enough information to aggregate the data per UE type (based on IMEI) or per
a certain subscriber range (based on IMSI).
Figure 41: Example of TCP handshake latency from one city aggregated to gNB level. Only 20 worst gNBs shown. Observe the big
difference between median latency and 95th percentile latency. SCS = 120 kHz, 5G19A
10.3.3
PM counters
There are 5G PM counters to measure the following latency components:
•
PDCP delay
•
RLC delay
•
F1 delivery delay (note: estimated delay, not a measurement)
•
X2 delivery delay (note: estimated delay, not a measurement)
28-Jan-2020 ULITPALIL5R3-1390467857-6948
137 / 178
Internal
© 2020 Nokia
From live network values, it is not clear if these counters will be useful in practice for measuring the latency,
so it is currently not recommended to put too much trust in them. Instead, the main use of PM counters
should be to investigate the causes of high latency, such as congestion or packet retransmissions. Further
details are available in the relevant sections of this guideline.
In 4G, the “TWAMP” counters (listed in Table 86) can be used to measure the RTT between the eNB and
other network elements, for example the SGW or an application server. In many networks, the gNB is colocated with the eNB, and the same SGW is used for both 4G and 5G traffic. In these cases, the 4G RTT,
which TWAMP counters can measure, can be assumed to be the same as the RTT between the 5G BTS and
the server.
Counter id
Measurement
Network element name
NetAct name
M51132C0
LTE TWAMP Statistics
avgRTT_15Min
avgRTT_15Min
M51132C1
LTE TWAMP Statistics
maxRTT_15Min
maxRTT_15Min
M51132C2
LTE TWAMP Statistics
minRTT_15Min
minRTT_15Min
M51132C3
LTE TWAMP Statistics
lostTwampMessages
lostTwampMessages
M51132C4
LTE TWAMP Statistics
txTwampMessages
txTwampMessages
Table 86: LTE TWAMP RTT counters which in some scenarios can be used to estimate the 5G RTT. Similar 5G counters are expected
to come in 5G21B
10.4
Dependencies on other sections
Optimization of user plane latency touches the subjects discussed in almost all the other sections of this
guideline:
•
Good RF performance can minimize the number of HARQ and RLC retransmissions. Being able to
keep the 5G radio bearer prevents the delay that comes if the radio bearer has to be re-established
(chapter 4)
•
In case the connection is broken during data transfer, it is important to have low control plane
latency to quickly re-establish the connection (chapter 11)
•
Having well-working mobility procedures in place help to avoid coming into situations where the
RF performance is bad (chapter 7)
•
Good settings for the LTE/5G interworking procedures help to avoid unnecessary use of the LTE
network with its higher air interface latency (chapter 9.4.1)
•
High network capacity minimizes the risk of packet collisions (chapter 8)
It should be noted that all the above points are expected to mainly improve the tail of the latency
distribution. The average latency values are likely to be mostly determined by parameter settings.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
138 / 178
Internal
© 2020 Nokia
10.5
Relevant features and parameters
This section discusses the features and specific parameters which can be expected to have impact on the
RTT. In most cases, it will be the average RTT that is impacted – the tail of the latency distribution is more
likely to be impacted by the quality of the radio links or by congestion.
Also, some field test results are provided. There are many possible combinations between parameter values,
test setup and UEs and rather than comparing all test results from all networks, it is therefore needed to
look isolated at each set of test results – trying to compare between different tests will give too much
uncertainty.
10.5.1
Operating band
With 5G19A, the operating frequency band determines the subcarrier spacing, which in turns determines
the slot duration:
•
600 MHz: 15 kHz SCS, 1 ms slot duration
•
2.6 GHz and 3.5 GHz: 30 kHz SCS, 0.5 ms slot duration
•
28 GHz and 39 GHz: 120 kHz SCS, 0.125 ms slot duration
The shorter slot duration in the mmWave bands lead to shorter median RTT, but this is not something that
the operator can control. It is mentioned here as a reminder that test results from networks with different
slot duration cannot be directly compared.
Note: Early test results do not show the expected difference between the operating bands: 15 ms – 17 ms
RAN RTT has been measured for both 3.5 GHz and mmWave frequencies. This probably just illustrates that
RTT is depending on many things and comparing across networks is difficult.
10.5.2
Cloud versus Classical BTS, F1 topology
In case of classical BTS, the F1 interface is inside the Airscale box, and it can be assumed the delay will be
negligible. In case of cloud BTS, the F1 topology may have measurable impact. The recommended delay
one-way latency on F1 is in the 1 ms – 2 ms range but the transport network used for F1 may not be
dedicated for 5G, and at least in principle there can be excessive delay for some DUs, either because there
are many hops or because of congestion. This may impact both the median RTT and the tail of the RTT
distribution.
The extra latency caused by external F1 interface should also be kept in mind when comparing measurement
results between Classical and Cloud BTS deployments.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
139 / 178
Internal
© 2020 Nokia
10.5.3
EN-DC configuration and topology
If the ulDataPath parameter has been set to “ulOverLte”, the transmission of uplink user plane data (either
the ping request in case of MO ping or the ping reply in case of MT ping) will be sent with the LTE radio
interface and forwarded to the gNB via the X2 link.
Depending on the scheduling parameters in LTE, this may generate an additional delay. If the LTE network
is congested, the delay can be even higher (although LTE networks are not likely to be congested in the
uplink, there is still a need to send the downlink RLC ack messages).
The X2 interface performance will potentially also have an impact on the delay and packet loss, especially if
the LTE and the 5G BTSs are not co-located.
In one network, a 10 ms higher ping RTT has been observed when the uplink data path is set to “ulOverLte”
(40 ms versus 30 ms).
10.5.4
FDD versus TDD
When TDD is used to separate uplink and downlink transmissions, there is a need to wait with transmission
until the appropriate uplink or downlink slot is available, and this will on average introduce a delay especially
for the uplink transmissions. When FDD is used, there is no need to wait for a slot with the correct
transmission direction, so the additional delay is avoided.
10.5.5
TDD frame structure
The TDD frame structure, especially the interval between the uplink slots, influences how fast a packet can
be sent / received on the air interface. In some countries, it is the national regulator which decides the frame
structure (in order to minimize inter-operator interference) but in other cases the operator may have some
freedom to select the frame structure. All macro sites can be expected to have same frame structure (to
avoid interference between sites) but it is in principle possible to have special frame structure optimized for
latency in isolated micro cells, for example in mines or indoor cells in factories.
The frame structure will impact the median RTT.
The following combinations are possible in 5G19A:
Feature
Frequency
Band
frameStructureType
ulDlDataSlotRatio
Resulting UL:DL slot
ratio during 10 slots
5GC001127
FR2
Semi-static
1:4
2:8
5GC001070
FR1
Semi-static
3:7
3:7
5GC001208
FR1
Semi-static
1:4
2:8
28-Jan-2020 ULITPALIL5R3-1390467857-6948
140 / 178
Internal
© 2020 Nokia
Feature
Frequency
Band
frameStructureType
ulDlDataSlotRatio
Resulting UL:DL slot
ratio during 10 slots
5GC001116
FR1
TD-LTE
N/A
2:8
Table 87: Possible TDD frame structures in 5G19A and their UL:DL slot ratios
Test results:
frameStructureType
ulDlDataSlotRatio
RTT (ms)
TD-LTE (3 ms)
N/A
16.5
Semi-static
1:4
14.2
Semi-static
3:7
14.5
Table 88: Results from customer lab. 32B ping, SCS = 30 kHz, pre-P7 software. The changing of the UL:DL slot ratio only has minimal
impact
Figure 42: FiVe RTT tests, stationary conditions, 32B, SCS = 30 kHz, only RAN RTT is plotted. TD-LTE (3 ms) and semi-static (1:4) is
compared. The semi-static frame has slightly faster RTT.
Note that the frame structure also impacts the number of possible beams, the possible RACH formats and
the achievable DL and UL throughput. The parameter guidelines have further discussions on this topic.
10.5.6
Connected mode DRX
Connected mode DRX (5GC000772) uses DRX to allow the UE to conserve battery power by only listening
occasionally to the PDCCH. The negative consequence of using DRX is that if the UE has gone into sleep
mode, it will take longer time to transfer a packet to the UE. The downlink one-way latency is thus increased.
The behaviour of the feature (sleep time etc.) can be controlled by parameters (Table 89).
Parameter
Object
actCDrx
NRCELL
28-Jan-2020 ULITPALIL5R3-1390467857-6948
141 / 178
Range
Internal
Default
Recommended
Deactivated (0)
True (1)
© 2020 Nokia
drxInactivityTimer
NRCELL
0 ms – 80 ms
10 ms (8)
10 ms (8)
drxLongCycle
NRCELL
10 ms – 80 ms
40 ms (3)
40 ms (3)
drxOnDurationTimer
NRCELL
1 ms – 80 ms
10 ms (7)
10 ms (7)
Table 89: Main parameters associated with the Connected Mode DRX feature. Note that DRX parameters need to be consistent with
the CSI Reporting period: The CSI Reporting period must be greater than or equal to the DRX long cycle duration, i.e.
csiReportPeriodicity >= drxLongCycle. This ensures that the UE can be DRX active whenever it is necessary to send a periodic CSI
report. If this consistency check is not obeyed, there will be UE Context Modification Failures at the BTS.
It is the median downlink latency which is impacted by this feature. There are not yet test results which show
how various parameter combinations impact on battery life and latency.
10.5.7
UL scheduling
The Scheduling Request period impacts system latency, i.e. UE have longer average wait times if the
Scheduling Request period is high. The Scheduling Request is transmitted by the UE on the PUCCH during
uplink subframes.
In 5G19A, the Scheduling Request Period is set equal to the CSI Reporting Period and both is controlled by
the csiReportPeriodicity parameter. This leads to a trade-off between latency and CSI reporting overhead:
Small value improves latency but increases the CSI reporting overhead which can cause PUCCH capacity
problems. The default value of 320 slots is relatively large, e.g. 320 slots with 30 kHz subcarrier spacing is
160 ms, whereas 4G typically uses a Scheduling Request period of 10 or 20 ms. To avoid PUCCH capacity
problems (see also the discussion in section 8.1.3), it is recommended to keep the default value of 320 slots
and instead rely on proactive uplink scheduling to achieve reasonable latency.
4G experience has demonstrated that Proactive Scheduling has negative impact upon uplink interference
levels and throughput due to the requirement for the UE to send dummy bits if it does not have anything
else to send in a proactively scheduled slot. To avoid this, 3GPP has introduced the possibility in 5G to use
“Dynamic Grant Skipping”, but this functionality is not part of 5G19A. This means that a low value of the
scheduling interval helps to achieve good latency but at the same time causes drain on the UE battery as
well as increased interference because the UE will send dummy bits if it does not have anything else to
transmit. However, PUSCH capacity will not suffer because pro-actively scheduled PUSCH slots have low
priority in the scheduler. Specific cells where low latency is particularly desired, for example cells covering a
gaming convention, can be set to have especially low proactive schedule interval.
If ulDataPath has been set to “ulOverLte”, it is not clear if proactive UL scheduling should be enabled. There
is certainly a cost because the UE will send dummy blocks in the proactively scheduled 5G PUSCH slots and
therefore the UE battery life will be reduced. On the other hand, the transmission of the uplink RLC Ack on
the PUSCH (in response to the downlink RLC blocks) will happen faster. There are not yet test results
available which quantifies this aspect.
It is the median uplink latency which is impacted.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
142 / 178
Internal
© 2020 Nokia
Parameter
Object
Range
Default
Recommended
csiReportPeriodicity
NRCELLGRP
20 – 320 slots
320 slots
320 slots
actProactUlScheduling
NRCELLGRP
False / true
False (0)
True (1)
ulSchedTimeInterval
NRCELLGRP
0.2...1000
4
4 ms (40)
Table 90: Parameters to control UL scheduling.
Test results:
csiReportPeriodicity
RTT with packet size = 64 RTT with packet size = 1400
bytes (ms)
bytes (ms)
40
37
38
80
43
58
160
70
97
320
176
176
Table 91: Average ping RTT measured in FiVe network, SCS = 30 kHz, 5G19 P8 (5G19_5.3835.983). No proactive UL
ulSchedTimeInterval
Minimum
Disabled
Average
Maximum
93
4 ms
8
13
23
10 ms
8
15
26
20 ms
8
20
43
Table 92: Ping RTT with different ulSchedTimeInterval. SCS = 30 kHz, csiReportPeriodicity = slots320, single UE, lab test
10.5.8
Link adaptation
The default BLER target of the link adaptation algorithm is 10%, and this means in principle that 10% of the
packets on the MAC layer needs to be re-transmitted.
In 5G19, where padding is used for small packets instead of MCS reduction, this should in principle mean
that 10% of the packets will be delayed. In 5G19A, where the MCS (and even the UL PRB allocation) will be
reduced if a small packet is to be transmitted, the MCS for small ping packets will probably be so robust
that HARQ retransmissions are generally not needed.
In 5G19, it can therefore be considered to use lower BLER target in specific cells where the tail of the latency
distribution is important. Such an approach is unlikely to have any effect in 5G19A. It is also unlikely to have
28-Jan-2020 ULITPALIL5R3-1390467857-6948
143 / 178
Internal
© 2020 Nokia
much impact on the average RTT. Using low BLER target may at the same time result in reduced throughput
and reduced spectral efficiency.
Parameter
Object
Range
Default
Recommended
dllaBlerTarget
NRCELL
1% - 99%
10%
10% (0.1)
ullaBlerTarget
NRCELL
1% - 99%
10%
3% (0.03)
Table 93: Parameters to control BLER target and therefore influence the amount of HARQ retransmissions
Test results:
dllaBlerTarget
ullaBlerTarget
RTT, 64 bytes RTT, 400 bytes RTT,
1400
(ms)
(ms)
bytes (ms)
10%
5%
21
39
39
10%
3%
20
39
39
5%
3%
20
39
39
Table 94: Average ping RTT measured in FiVe network, SCS = 30 kHz, 5G19 P8 (5G19_5.3835.983). csiReportPeriodicity = 40 slots.
The BLER target does not have impact on average RTT.
10.6
UE dependencies
It has been observed that the ping RTT to a large degree is depending on which UE that is used for the
testing. There are at least two reasons for this:
•
UE capabilities: For example, if the UE is able to use the same PUSCH slot to send both the UL RLC
Ack for the downlink ping and the uplink ping reply.
•
UE performance issues: For example, if the UE is not transmitting with high enough uplink power
Ping tests in the field as well as in the lab should therefore preferably be done with multiple UE chip sets.
Figure 43: Detailed view of how DL and UL slots are used when doing a MT ping. Left chart is for Qualcomm X50 chipset, right chart
is for HiSilicon chipset. It can be seen that the HiSilicon chipset combines the UL RLC Ack for the downlink ping and the uplink ping
reply into the same UL slot, and thereby gaining about 5 ms. Lab test, 3.5 GHz, 5G19A
28-Jan-2020 ULITPALIL5R3-1390467857-6948
144 / 178
Internal
© 2020 Nokia
Figure 44: Examples of ping RTT times with different handsets. Note that the Qualcomm chipset ("MTP" and "Xiaomi") behavior is
very different from HiSilicon ("Huawei") and Samsung chipsets. Drive test, MO ping, pro-active scheduling enabled, 3.5 GHz, 5G19A.
10.7
Optimization procedure
If there is need to improve the average latency, it seems that significant improvements will only be possible
by activating features and adjusting parameters. In 5G19A, such tuning will impact all the traffic and it is
possible that the negative consequences (for example more UE battery consumption if proactive UL
scheduling is using aggressive values) cannot be accepted in the general network. If this is the case, it can
be considered if there are specific cells (indoor factory cells, cells covering mining operations), where it is
acceptable to have worse performance in some respects if it means that the latency can be improved.
If there is a need to improve the tail of the latency distribution, the major things to check will probably be:
•
Congestion (even low congestion level means that packets are now and then colliding). Table 95
contains test results which illustrate the impact of radio link congestion.
•
Handover problems
•
Frequent use of LTE to transfer the packets. In practice, this will probably be due to loss of 5G radio
link, so the 5G radio link failures should be investigated. Field tests with SCS = 120 kHz have shown
~10 ms additional RTT delay when the uplink is using LTE radio interface instead of 5G
•
Bad RF performance in general. Figure 45 shows drive test measurements in mature LTE networks,
where the relatively small areas with bad coverage is heavily degrading the 99.9% percentile
performance. Of course, if the areas with bad 5G coverage are relatively large, also the average
latency will be impacted. In one 5G network it has been observed that a HARQ retransmission means
about 3 – 5 ms additional delay and a RLC retransmission means additional 100 ms delay (SCS = 30
kHz, 5G19A).
28-Jan-2020 ULITPALIL5R3-1390467857-6948
145 / 178
Internal
© 2020 Nokia
In the special case of Cloud BTS deployment, it should be investigated how much latency varies between
the DUs, and it should be attempted to correlate such variation with the topology and load of the F1
transport network.
Note that as long as the UE is in reasonable 5G radio conditions and handovers are not needed, mobility
as such should not impact the latency, since even the lowest coding scheme will be able to transfer the full
packet in a single slot. This is illustrated in Figure 46.
Test conditions
Median RTT
99% RTT
No background traffic
12 ms
16 ms
10 Mbps UDP
13 ms
24 ms
50 Mbps UDP
13 ms
42 ms
250 Mbps UDP
15 ms
118 ms
TCP
50 ms
117 ms
Table 95: FiVe test results with single UE in stationary conditions. SCS = 30 kHz, constant UL scheduling, BTS SW = pre-P7
(5G19_5.3835.322). TCP throughput reached about 400 Mbps. Note that the average latency is not really impacted until the radio link
load is high (250 Mbps) while the 99% latency is immediately impacted with just 10 Mbps / 400 Mbps = 2.5% radio link load.
Figure 45: Delay measurements from drive testing in three live LTE networks. Average delay = ~15 ms; 99% delay (“10 -2”) = ~30 ms;
99.9% delay (“10-3”) = 250 – 300 ms.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
146 / 178
Internal
© 2020 Nokia
Figure 46: FiVe field tests, comparison between stationary and mobility results. SCS = 30 kHz, pre-P7 5G19 software. The drive route
was within a single 5G cell and all the route was in reasonable 5G coverage. There is no significant difference between the three tests.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
147 / 178
Internal
© 2020 Nokia
11 Optimization of control plane latency
11.1
Introduction
Control plane latency describes how long time it takes to establish a 5G radio connection.
The starting point is typically that the UE is in RRC idle mode and the ending point is normally when the UE
has completed the 5G RACH procedure. This means that the LTE RRC establishment time (impacted for
example by the idle mode DRX parameter settings (in case of mobile terminated connections) or core
network security settings) have an impact. However, in this document the generic LTE delay components
will not be discussed except that they will be present in the field test results.
Especially in NSA deployments, where the radio connection needs to be established via the 4G RRC
connection, the establishment time is so long that the first few packets of the user plane traffic are often
sent via the LTE radio link rather than via the 5G radio link. Sometimes, there is requirement to meet a
certain user plane latency when starting from RRC idle mode. Intuitively, this would be the sum of the 5G
control plane latency and the 5G user plane latency, but in practice, the first packets have already been sent
and received on the LTE radio interface (RTT for example ~200 ms from RRC idle) before the setup of the
5G radio has been completed (for example 400 ms). If “Idle mode Ping RTT” is discussed, it is therefore
important that it is clear exactly what is meant
Control plane latency is especially important if 5G handover functionality is not fully implemented and the
connection will have to be released and set up again when moving from one 5G sector to another. A high
control plane latency will in such cases lead to reduced average 5G throughput.
Typical applications used by end-users to test the network throughput performance (such as Ookla
Speedtest) make their measurements only during a few seconds, and a high control plane latency can mean
that the throughput measurement can be completed before the 5G carrier has been added.
The interest is normally about the average latency rather than the tail of the distribution.
11.2
Typical issues
If the UE is within the 5G coverage, the biggest impact on the control plane latency is whether or not blind
or measurement-based SgNB is used. If the UE is in marginal 5G coverage, it can be expected that this will
also cause an increase in the control plane latency because multiple access attempts may be needed.
There are also scenarios where the SgNB is intentionally delayed, either because LTE Carrier Aggregation
needs to be completed or because there is ongoing VoLTE call.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
148 / 178
Internal
© 2020 Nokia
11.3
Performance analysis
There are no counters to measure the control plane latency, so some kind of tracing will be needed, either
in the UE or in the BTS. Tracing of both LTE and 5G messages are needed – these will typically be directly
available from the UE (possibly from two different log files) but from the BTS, it will be necessary to trace in
both the 4G and in the 5G BTS.
The starting message is either the 4G preamble or the 4G RRC Connection Request. The ending message
is the 5G RACH “msg3” message.
One of the causes of long control plane latency can be that the first call setup attempt is not successful. PM
counters can be used to measure the accessibility in the 5G cells, and analysis of these counters may be
able to explain long latencies. The relevant counters and KPIs are discussed in the Accessibility section of
this document.
11.4
Relevant features and parameters
Feature id
Feature name
Release
LTE4193
Dynamic Trigger for LTE-NR Option 3X
LTE19
LTE4575
Blind Carrier Aggregation with LTE-NR DC Option 3X
LTE19
LTE5524
Ongoing QCI1 prevents EN-DC setup
LTE19A
5GC000795
Multiple DRBs per UE -NSA mode 3x
5G19A
LTE4531
LTE-NR DC Option 3X: Multiple non-GBR SCG split Bearers
LTE19A
LTE4549
Flexible LTE CA with EN-DC
LTE19B
LTE5510
Stepwise addition of multiple bearers for EN-DC
LTE19B
5GC001874
Non contention based random access
5G19A
Table 96: Features relevant when analyzing control plane latency
The relevancy of the features listed in Table 96 is shortly as follows:
•
LTE4193 enables dynamic triggering of the SgNB addition, such that addition is only attempted in
areas with a certain minimum 5G coverage. This means that the UE needs to measure the 5G
coverage and report back to the 4G BTS before SgNB can happen, and this naturally takes a certain
time
•
In most networks, the operator will have multiple LTE bands and maximum end user throughput is
achieved if LTE Carrier Aggregation is in place. With the basic LTE CA feature (LTE4575), the LTE
carrier aggregation needs to be in place before the SgNB can happen, and LTE4575 can be
parameterized such that the UE B1 measurement reports are ignored until the SgNB has taken place.
With LTE19B feature LTE4549, it is no longer needed to delay the SgNB addition.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
149 / 178
Internal
© 2020 Nokia
•
LTE4531 and 5GC000795 allow the UE to have multiple EN-DC DRBs, but these DRBs must be set
up before the SgNB addition takes place and there may be a requirement to delay the SgNB
addition. With LTE5510, this requirement disappears.
•
LTE5524 delays the SgNB if there is ongoing VoLTE call in order to avoid any impact to the VoLTE
call quality. Waiting until the VoLTE call is completed can of course have a rather large impact on
the SgNB addition delay.
•
5GC001874 (contention free random access) allows faster and more reliable access than the 5G19
contention based random access
In principle, the frequency of the RACH occurrences (within the subframe and divided over the number of
beams) plays a role for how fast the UE can send the 5G preamble. Also, the periodicity of the SSB burst set
can impact the time it takes for the UE to synchronize to the 5G cell. In both cases, the impact is probably
negligible compared to the total duration of the access procedure and can probably be ignored until the
Standalone functionality becomes available.
Parameter
Object
Range
Default
Recommended
ssBurstSetPeriod
NRCELLGRP
10 – 160 ms
10 ms
20 ms
prachConfigurationIndex
NRCELL
Numerous
values
38
Depends on
frame structure
and use case
numberOfTransmittedSsBlocks
NRCELLGRP
1 – 32 beams
1
Match with
desired nrb of
beams
Table 97: SSB / RACH periodicity parameters which theoretically can impact the control plane latency, but which are probably only
relevant when SA functionality is available
The general 5G accessibility should also be investigated, since low accessibility leads to repeated
establishment attempts and therefore increased control plane latency.
11.4.1
LTE4193: Dynamic Trigger for LTE-NR DC Option 3X
Parameter
Object
actDynTrigLteNrDualConnectivity
LNBTS
b1TimeToTriggerRsrp
NRDCDPR
b1TimeToTriggerRsrq
NRDCDPR
Range
Default
Recommended
False (0)
True (1)
0 to 5120 ms
256 ms
256 ms
0 to 5120 ms
256 ms
256 ms
Table 98: Most relevant parameters in the LTE4193 feature. Note that these parameters are defined in the eNB
28-Jan-2020 ULITPALIL5R3-1390467857-6948
150 / 178
Internal
© 2020 Nokia
Test results:
Intuitively, blind addition should be faster than measurement-based addition. In pre-P7 5G19 packages, this
was not the case because even though the eNB would not configure the UE to do 5G measurements, it
would still be waiting for the measurement reports until a guard timer expired, and this caused additional 1
second delay. This was fixed in the P7 version of 5G19 (Pronto PR430607) for some radio units, for example
AEQD. However, other radio units, for example AZQL, has been seen to have the same problem even in
5G19 P8 releases).
actDynTrigLteNrDualConnectivity
b1TimeToTriggerRsrp
Test condition
Average latency
False
N/A
Stationary
462 ms
True
?
Stationary
1461 ms
False
N/A
Drive tests
417 ms
True
?
Drive tests
1248 ms
Table 99: Control plane latency with and without measurement-based SgNB addition. FiVe field tests, AEQD,
FL19_ENB_0000_000172_000072. The b1TimeToTrigger parameter not known but may have been set to the default 256 ms. Blind
SgNB addition is clearly faster than measurement-based addition.
Figure 47: Control plane latency with and without measurement-based SgNB addition. AZQL, FL19_ENB_0000_020118_000000. Blind
addition takes longer than measurement-based addition. LTE BTS software bug expected.
Although the general recommendation is to use measurement-based addition (to avoid switching the user
plane to the gNB if the 5G radio connection is not likely to be established), it can be considered to disable
the LTE4193 feature (i.e. use blind SgNB addition) in cells where faster 5G control plane latency is required
and/or where the 4G and the 5G radio coverage can be expected to be similar.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
151 / 178
Internal
© 2020 Nokia
It can also be considered to shorten the time-to-trigger, albeit at the expense of more failed 5G RACH
procedures (because there is higher risk that there was just a single “spike” increase in the 5G RSRP) and
possibly problems with 4G carrier aggregation (see discussion in section 9.4.2) and multiple DRB use (see
below). Shows the behavior with different time-to-trigger values.
Table 100: SgNB addition time with different time-to-trigger values. Drive tests, 5G19A, 600 MHz
11.4.2
LTE Carrier Aggregation features (LTE4575 / LTE4549)
In most networks, the operator will have multiple LTE bands and maximum end user throughput is achieved
if LTE Carrier Aggregation is in place. With the basic LTE CA feature (LTE4575), the LTE carrier aggregation
needs to be in place before the SgNB can happen, and LTE4575 can be parameterized such that the UE B1
measurement reports are ignored until the LTE carrier aggregation has taken place. With LTE19B feature
LTE4549, it is no longer needed to delay the SgNB addition. The parameter settings of these features as well
as some relevant measurements are discussed in section 9.4.2.
Note that this issue is only relevant if both the 4G and the 5G connections need to be set up. If the 4G
connection and the needed carrier aggregation has already been set up, the SgNB addition will not be
delayed. This could for example be if 5G handover is not enabled, and the UE moves from coverage area
of one 5G sector to another 5G sector while staying in the coverage of the same LTE sector. In this scenario
the 5G radio link will be released (or dropped) in the old 5G sector and a new 5G radio link will be established
in the new 5G sector – but the 4G connection will be maintained.
If LTE Carrier Aggregation is seen as less important (if for example the available LTE bandwidth is negligible
compared to the 5G bandwidth), the LTE4575 can instead be parameterized so SgNB addition takes place
as soon as a suitable 5G cell is found.
Table 101: Illustration of the increased control plane latency when waiting for LTE carrier aggregation to happen. When waiting for
LTE CA, SgNB addition time is 2 – 7 seconds. Without waiting, SgNB addition is ~850 ms. b1TimeToTriggerRsrp = 640 ms, 5G19A,
600 MHz
28-Jan-2020 ULITPALIL5R3-1390467857-6948
152 / 178
Internal
© 2020 Nokia
If LTE4575 is parameterized such that the UE B1 measurement reports are ignored until the LTE carrier
aggregation has taken place, it should be noted that it has been observed in LTE19A that the LTE4575 blind
carrier aggregation does not happen if there is only a small amount of downlink data to be sent (when
doing FTP upload, when doing small pings or opening a small webpage like Google.com), and since LTE
carrier aggregation does not happen, the SgNB addition also does not happen, even though the UE sends
B1 measurement reports. This problem will be fixed in a future release.
11.4.3
Multiple DRB features (5GC000795 / LTE4531 / LTE5510)
LTE4531 and 5GC000795 allow the UE to have multiple EN-DC DRBs, but these DRBs must be set up before
the SgNB addition takes place and there may be a requirement to delay the SgNB addition.
When the E-RAB bearers are setup between the UE and the core network, there are two options:
•
All E-RAB bearers are requested to be set up in the S1AP: INITIAL CONTEXT SETUP REQUEST
message
•
The initial context setup message covers only a single E-RAB and the rest of the E-RABs are set
up via the S1AP: E-RAB SETUP REQUEST message
If the first option is used, the SgNB addition can take place immediately. If the second option is used, the
SgNB addition should be delayed until the additional E-RABs have been set up. This delay can be achieved
by using a high value of the b1TimeToTriggerRsrp parameter.
There is not yet good view of how long b1TimeToTriggerRsrp should be.
Note that this issue is only relevant if both the 4G and the 5G connections need to be set up. If the 4G
connection with all the needed E-RABs and DRBs has already been set up, the SgNB addition will not need
to be delayed. This could for example be if 5G handover is not enabled, and the UE moves from coverage
area of one 5G sector to another 5G sector while staying in the coverage of the same LTE sector. In this
scenario the 5G radio link will be released (or dropped) in the old 5G sector and a new 5G radio link will be
established in the new 5G sector – but the 4G connection will be maintained.
With LTE5510 in LTE19B, additional E-RABs can be set up even after the SgNB addition has taken place.
11.4.4
LTE5524: Ongoing QCI1 prevents EN-DC setup
VoLTE traffic (QCI 1 EPS Bearer) is always routed through the 4G BTS. There may be a negative impact upon
VoLTE performance if a UE is simultaneously configured with a VoLTE bearer at the 4G BTS and a non-GBR
data bearer at the 5G BTS. This feature prevents 5G Secondary Cell Addition when there is an ongoing
28-Jan-2020 ULITPALIL5R3-1390467857-6948
153 / 178
Internal
© 2020 Nokia
VoLTE call. Depending on the duration of the ongoing VoLTE call, the delay in executing the SgNB addition
procedure can therefore be considerable. This feature is described in more details in chapter 12.
11.4.5
5GC001874: Non contention based random access
The introduction of the contention-free random access procedure can potentially speed up the 5G RACH
procedure:
•
Msg3 is not used in contention-free scenario so the whole procedure is faster compared to the
contention-based scenario. This will impact the average latency
•
When contention-based random access is used, it is possible that two UEs will select the same
preamble and the random access procedure will therefore not work for one of them. The failing
UE will need to pick another preamble and try again, and this generates an extra delay.
Contention-free access avoids this issue. This issue will impact the tail of the latency distribution
•
A shorter random access procedure means less risk of radio failures during the procedure and
therefore less risk of having to start again from beginning. This issue will impact the tail of the
latency distribution
There are not yet live network experiences with contention-free random access. It is doubtful if the speed
improvements will be significant compared with the other delays in the SgNB addition procedure.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
154 / 178
Internal
© 2020 Nokia
12 Impact on legacy LTE performance
12.1
Impact on LTE performance for non-EN DC capable UEs
12.1.1
LTE layering strategy
When EN-DC functionality is enabled in the network, the operator may choose to only allow certain LTE
layers to be used as anchor carriers for the EN-DC connections. This means there is a need to push ENDC UEs onto certain LTE layers.
In theory, it should be possible to do this based on the UE capability, but in practice, it seems that also the
subscriber profile id (SPID) is needed, and some operators are reluctant to use this due to added
complexities in the core network. The solution can then be to push all UEs, regardless if they are EN-DC
capable or not, onto the desired LTE layer, and this can therefore change the performance also of the
non-EN DC UEs.
Even if the combination of UE capability and SPID is used such that it is only EN-DC capable UEs which
are pushed to a certain LTE layer, this LTE layer can start to suffer from increased congestion, and this will
also hit the non-EN DC capable UEs which happen to use that particular LTE layer.
12.1.2
LTE congestion
5G users may transfer considerably more data than LTE users due to higher quota on their subscriptions
and the use of more bandwidth-hungry applications. Especially when the UE is outside 5G coverage, this
behaviour can cause increased loading of the LTE radio interface, and this will also hit the non-EN DC
users. This scenario is briefly discussed in section 8.4.
On the other hand, it is also possible that offloading the heavy users to the 5G layer means less load on
the 4G layer and therefore better performance for the non-EN DC users.
The X2 interface will probably start to carry significantly more traffic when EN-DC is enabled in the
network, and this can potentially disrupt legacy LTE procedures such as inter-eNB handover.
12.2
Impact on LTE performance for EN-DC capable UEs
12.2.1
Measurement gaps
When an EN-DC capable UE establishes a RRC connection on a eNB configured for EN-DC operation, it is
by default instructed to use measurement gaps to perform the B1 measurements. This means that the
achievable LTE throughput is reduced by approximately 25%. This effect is present especially if there is no
28-Jan-2020 ULITPALIL5R3-1390467857-6948
155 / 178
Internal
© 2020 Nokia
5G signal in the area. Not all UEs on the market require measurement gaps to be able to perform B1
measurements, and it is possible to disable the measurement gaps. This is discussed in more details in
section 5.4.
12.2.2
Performance during failed RACH procedures
If the 5G addition is attempted at too low RSRP values, there may be a series of failed 5G RACH
procedures. Not only does this mean that the 5G leg of the connection will not be established – it is also
possible that the LTE leg will suffer from reduced throughput. This happens only at the edge of the 5G
cell. This effect is discussed in section 5.4.
12.2.3
LTE carrier aggregation
The use of EN-DC carrier aggregation brings some restrictions to the use of the pure LTE carrier
aggregation procedures, and in some scenarios, a UE with EN-DC connection will not have LTE carrier
aggregation. The interaction between the various Nokia features is discussed in section 9.4.2. In addition,
the UE itself may have limitations on the possible LTE carrier aggregation possibilities when it is in EN-DC
mode.
12.2.4
VoLTE performance
Feature id
Feature name
LTE5524
Ongoing QCI1 prevents EN-DC setup
Table 102: Features related to improved VoLTE performance
There may be a negative impact upon VoLTE performance if a UE is simultaneously configured with a
VoLTE bearer at the 4G BTS and a non-GBR data bearer at the 5G BTS. This can happen if the UE does
not support dynamic power sharing between 4G and 5G and may result in a limitation of the uplink LTE
transmit power and therefore worse VoLTE performance.
LTE5524: Ongoing QCI1 prevents EN-DC setup allows to prevent an EN-DC setup when there is an
ongoing QCI1 call. Note that the opposite situation, that an existing EN-DC connection will be released
when a new QCI1 connection is established, is not supported. In LTE19A; the feature only works with the
QCI1 (VoLTE) calls. In LTE19B, also the QCI65 and QCI66 bearers used for public safety is taken into
account.
In LTE19A, the feature is controlled via a temporary parameter, and in LTE19B, a dedicated parameter is
taken into use.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
156 / 178
Internal
© 2020 Nokia
Parameter
Object
Range
Default
tmpActFeat1
LNBTS
Bitmap of 32 bits
all 0’s
Recommended
Bit 0: Non-emergency QCI1 calls
Bit 1: Emergency QCI1 calls
actVoLteNoEnDc
LNBTS
0
1
2
3
4
5
6
7
disabled
non-emergency QCI1 calls
emergency QCI1 calls
all QCI1 calls
QCI65 and QCI66 calls
QCI65/66 and nonemergency QCI1
QCI65/66 and emergency
QCI1
QCI65/66 and all QCI1
calls
disabled (0)
Table 103: Parameters to control LTE5524
28-Jan-2020 ULITPALIL5R3-1390467857-6948
157 / 178
Internal
© 2020 Nokia
13 Optimization of specific functionalities
This chapter is a collection of miscellaneous topics which are not important or complicated enough to
warrant their own chapter but on the other hand cannot easily be included in any of the other chapters.
13.1
RACH performance
To be included later
13.2
5G carrier aggregation
The maximum channel bandwidth in 5G19A is 100 MHz, and since some operators have large bandwidths
available in the 28 GHz and 39 GHz bands, 5G carrier aggregation is needed to fully exploit the available
bandwidth. In 5G19A, carrier aggregation is supported only for FR2, i.e. 28 GHz or 39 GHz. The relevant
features are listed in Table 104.
Feature id
Feature name
5GC000527
Intra-band Carrier Aggregation TDD FR2 up to 2CCs
5GC000720
Asymmetric Carrier Aggregation
5GC001725
Intra-band Carrier Aggregation TDD FR2 up to 4CCs DL
5GC001547
Supplemental downlink cell - FR2
5GC001831
Intra-band CA TDD FR2 up to 4CCs DL - 2CCs UL
5GC001836
Spillover from 5GC000480 Radio Admission Control for NSA mode 3x operation
Table 104: Features related to 5G carrier aggregation. 5G19A features in italic
The aim of 5G carrier aggregation is to provide higher throughput for a single UE. In 5G19, up to 400 MHz
bandwidth can be allocated to a single UE. The carriers do not need to be contiguous as long as they are
in the same frequency band.
A particular UE may not necessarily support carrier aggregation. This is checked by the gNB by inspecting
the UE Capability IE before deciding to execute carrier aggregation for the UE. In 5G19A, there is no
mechanism allowing to add another SCell(s) for the UE during the ongoing connection –all possible SCells
are configured only once, during the Initial Context Setup procedure.
Only FR2 intra-band carrier aggregation (contiguous and non-contiguous) is supported in 5G19A. The
configuration of the carrier aggregation is done during the SgNB addition, i.e. step-wise carrier aggregation
is not yet supported.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
158 / 178
Internal
© 2020 Nokia
Supplemental Downlink Carrier (SDLC) functionality is introduced with 5G19A feature 5GC001547:
Supplemental downlink cell -FR2. It allows the configuration of 5G cells deployed in DL-only mode. In
contrast to regular DL/UL cell deployments, SDLC does not allow for uplink service - at least one cell in the
cell group must have DL / UL capabilities while the rest of the cells can be DL-only. However, the DL-only
cells are still configured with the usual mix of DL slots, UL slots and special slots. The benefit of DL-only cells
is that they require less processing resources in the BTS and for example the 5GC001824: 4 cells per
ABIL/ASOD in FR2 requires the use of DL-only cells.
Parameter
Object
Range
Default
Recommended
actCarrierAggregation
NRBTS
False, True
False
True
maxNumScellsDl
NRBTS
1 to 3
3
3
maxNumScellsUl
NRBTS
1
1
2
sCellActivationMethod
NRBTS
Blind, BufferBased,
BufferAndRLQualityBased
BufferBased
BufferBased
maxNumOfUsersPerCell
NRCELL
0..250
250
0 if DL-only cell
nrCellType
NRCELL
20:2DL0UL;
2DL0UL if DLonly cell,
otherwise
2DL2UL
21:2DL1UL;
22:2DL2UL;
24:2DL4UL;
42:4DL2UL;
44:4DL4UL;
82:8DL2UL;
84:8DL4UL;
88:8DL8UL;
168:16DL8UL;
1616:16DL16UL
pathlossDeltaActSCellDl
NRBTS
[0 .. 20], step 1
3
N/A
mcsDeactSCellDl
NRBTS
[1 .. 15], step 1
3
N/A
pathlossDeltaActSCellUl
NRBTS
[0 .. 20], step 1
3
N/A
mcsDeactSCellUl
NRBTS
[1 .. 15], step 1
3
N/A
Table 105: Parameters to control carrier aggregation. The last 4 parameters are only used if the activation method is
bufferAndRLQualityBased
28-Jan-2020 ULITPALIL5R3-1390467857-6948
159 / 178
Internal
© 2020 Nokia
Measurement id
Measurement name
Carrier aggregation counters
M55114
Central unit (CU) Radio admission
control measurement
CU admission control attempts and
successes for 1 to 7 additional carriers
M55115
Distributed unit (DU) Radio
admission control measurement
DU admission control attempts and
successes for 1 to 7 additional carriers
M55316
NR Carrier Aggregation Distributed
Unit (gNB-DU)
Average and maximum number of UEs
using CA per number of SCells
Table 106: Main measurements with Carrier Aggregation counters. Individual counters are too numerous to list
KPI id
KPI name
KPI formula
NR_216a
5G Average number of UEs
with an PSCELL or SCELL
activated in downlink
UE_PSCELL_ACT_SCELL_DL /
SAMPLE_CNT_DL_UE_AMOUNT
NR_217a
5G Average number of UEs
with an PSCELL or SCELL
activated in uplink
UE_PSCELL_ACT_SCELL_UL /
SAMPLE_CNT_UL_UE_AMOUNT
NR_xxx
Average number of DL SCells
(PSCELL_UE_1_ACT_SCELL_DL + 2 *
PSCELL_UE_2_ACT_SCELL_DL + 3 *
PSCELL_UE_3_ACT_SCELL_DL + 4 *
PSCELL_UE_4_ACT_SCELL_DL + 5 *
PSCELL_UE_5_ACT_SCELL_DL + 6 *
PSCELL_UE_6_ACT_SCELL_DL + 7 *
PSCELL_UE_7_ACT_SCELL_DL) / (PSCELL_UE_0-7_ACT_SCELL_DL)
NR_xxx
Average number of UL Scells
(PSCELL_UE_1_ACT_SCELL_UL + 2 *
PSCELL_UE_2_ACT_SCELL_UL + 3 *
PSCELL_UE_3_ACT_SCELL_UL + 4 *
PSCELL_UE_4_ACT_SCELL_UL + 5 *
PSCELL_UE_5_ACT_SCELL_UL + 6 *
PSCELL_UE_6_ACT_SCELL_UL + 7 *
PSCELL_UE_7_ACT_SCELL_UL) / (PSCELL_UE_0-7_ACT_SCELL_UL)
Table 107: Main KPIs to monitor carrier aggregation functionality. Many more KPI formulas exist.
13.3
Ookla Speedtest
Ookla Speedtest (speedtest.net) is a web service that provides free analysis of connection data rate and
latency. It is widely used by Nokia test engineers, operator test engineers and journalists and bloggers to
give quick impression of the network performance. Many operators are specifically demanding that Ookla
speedtest will show good performance when used in their networks.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
160 / 178
Internal
© 2020 Nokia
13.3.1
How Ookla Speedtest works
Ping/Jitter: This test is performed by measuring the time it takes for the server to reply to a request from
the user's client. The client sends a message to the server. Upon receiving that message, the server sends
a reply back. The round-trip time is measured is measured in ms. The test is repeated approximately 10
times. The lowest value determines the value of the reported latency and the variation between the values
determinates the jitter.
This means that the scheduling parameters which determine the “waiting time” will not necessarily have
much impact on the reported latency because these parameters will tend to impact the average latency,
not the minimum latency.
Download: The client establishes multiple TCP connections with the server (fallback to HTTP is also
possible). The client requests the server to send an initial chunk of data. The client calculates the real-time
speed of the transfers, then adjusts the chunk size and buffer size based on this calculation to maximize
usage of the network connection. As the chunks are received by the client, the client will request more
chunks throughout the duration of the test. During the first half of the test, the client will establish extra
connections to the server if it determines additional threads are required to more accurately measure the
download speed. The test ends once the configured amount of time has been reached. All samples are
sorted by speed. The two fastest results are removed as well as the bottom 1/4 which is left (which is
approximately 22% of the total). Everything else is then averaged.
Since TCP protocol is in use, it is crucial that the TCP acks are being sent. This again means that a bad
uplink connection will degrade the downlink throughput. Also, the TCP slow-start means that it is
important not to have high control plane and user plane latencies in order to avoid that the test is
completed before the TCP slow start phase has been passed.
Upload: The client establishes multiple TCP connections with the server over the defined port (fallback to
HTTP is also possible) and sends an initial chunk of data. The client calculates the real-time speed of the
transfers and adjusts the chunk size and buffer size based on it to maximize usage of the network
connection, and requests more data. As the chunks are received by the server, the client will send more
chunks throughout the duration of the test. During the first half of the test, the client will establish extra
connections to the server if it determines additional threads are required to more accurately measure the
upload speed. The test ends once the configured amount of time has been reached. The two fastest
results are removed as well as the bottom 1/4 which is left (which is approximately 22% of the total).
Everything else is then averaged.
Similar to the download test, the use of TCP protocol means that the opposite transmission direction (in
this case the downlink direction) works well in order to achieve good upload performance. Again, the TCP
slow-start means than control plane and user plane latencies can have high impact.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
161 / 178
Internal
© 2020 Nokia
13.3.2
How to improve Ookla Speedtest performance
The path to the server and the server itself should have good performance without congestion, high load,
high latency etc. Many operators improve performance by deploying their own speedtest server close to
their PGW. This doesn’t help on long S1-U connections, but unless the S1-U latency is extremely high, it is
probably mainly the latency results that will suffer.
If establishing the 5G connection takes multiple seconds (this can happen if the use of LTE4575: Blind
Carrier Aggregation with LTE-NR DC Option 3X means that SgNB addition only happens after LTE carrier
aggregation is complete), the download test may end before or soon after the 5G connection is available.
Chapter 11 discusses the possibilities to improve the control plane latency.
User plane latency plays naturally a big role for the ping latency results. For download and upload tests, a
high user plane latency is not necessarily an issue: If the control plane latency is low, there will probably be
enough time to overcome the TCP slow start even with high user plane latency, but if the 5G connection
establishment is already delayed, a high user plane latency can then be the final factor that is preventing
to reach high throughput. Chapter 10 discusses the possibilities to improve the user plane latency. See
example on Figure 48.
Since the “reverse direction” plays a role in getting good TCP performance, especially the EN-DC uplink
performance should be analysed. It may be possible to get better uplink throughput and therefore better
Speedtest download results by using only the LTE leg for the uplink user plane. See section 9.4.1 for some
discussion on this topic.
Finally, the overall throughput performance of course needs to be on a good level. Chapter 9 lists the
different actions to take in this regard.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
162 / 178
Internal
© 2020 Nokia
Figure 48: Slow ramp-up during Ookla Speedtest Download. The 5G throughput is still rising when the test is terminated and
therefore a bad performance is reported. Slow ramp-up caused by combination of waiting for LTE carrier aggregation and high user
plane latency. 600 MHz, 5G19A
13.3.3
Processing Speedtest results
Speedtest results are often postprocessed simply by taking a screenshot after a test and then either
directly include the screenshot in the test report or manually enter the results into a table.
If there are many test results, for example after a couple of days’ drive testing, a more convenient way is
to use the “upload” option in the app to mail a spreadsheet with the latest results (typically covering
multiple days) to an email address. The data can then easily be postprocessed.
13.4
EN-DC downlink throughput issues
Most operators want to be able to demonstrate as high downlink throughput as possible when using a 5G
UE, and this means that both the LTE leg and the 5G leg should be able to contribute, i.e. the
dlDataSplitMode parameter should be set to “dlOverF1UX2U”.
The importance of this depends on factors like available 5G bandwidth, possibility of LTE carrier aggregation,
LTE congestion level etc., but theoretically it is in all cases expected that split mode operation will bring a
benefit in downlink end-user throughput.
However, the experience is that with TCP traffic, the end-user throughput can be degraded when using split
mode compared to use either pure LTE or pure 5G downlink transmission. The explanation is probably that
when split mode is enabled, some TCP packets are lost in the X2 transmission. This means that when the
UE combines the LTE and 5G data streams, it will detect that some TCP packets are missing, and it will
request the server for retransmission. The server will interpret this as congestion and reduce the downlink
transmission speed.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
163 / 178
Internal
© 2020 Nokia
Possible reasons for TCP packet drops in this scenario include:
•
5G BTS software problems. Numerous prontos have been opened on this topic. Some corrections
are already available in the latest BTS releases
•
X2 transmission problems. In some cases it has been demonstrated that linking eNB and gNB with
direct cable gives much better performance than using the X2 transmission network. This approach
of course only works for co-located sites
The initial investigation can be based on:
•
Use field test equipment to compare UDP and TCP performance in split mode and in 5G-only mode.
It is expected that when UDP is used, the 5G MAC / RLC throughput is the same regardless whether
split mode or 5G-only mode is used. When TCP is used, it is possible that the 5G MAC / RLC
throughput is reduced and becomes unstable when switching from 5G-only mode to split mode. If
this happens, a possible explanation is packet drops in the X2 transmission
•
Use wireshark to capture at least the UE TCP layer and examine if the use of split mode leads to
TCP retransmissions. Optionally, also wireshark capture at X2 and at S1 interfaces can help in
understanding where the packets are dropped
In some cases, the problems are present regardless of the location and can be found be stationary testing
in a single location or even in test lab. In other cases, there seems to be a dependency on X2 performance,
so the problems may not be detectable in all locations.
There is EN-DC knowledge sharing material on Confluence, which provides useful comments about best
parameter settings. Also EN-DC learnings has relevant information.
13.5
UE battery life
The importance of minimizing the UE power consumption depends on the UE type. For CPEs (Customer
Premises Equipment, used in Fixed Wireless Access use case) which are normally connected to a mains
outlet, the power consumption is not important in practice. For smartphones, the battery life time is certainly
important for the user, but it is not yet clear if the 5G radio network configuration has significant impact on
the battery life or if other factors, such as the screen power consumption in practice is much higher. For
battery-driven IoT devices such as smart meters, the power consumption will be very important, but it is
unlikely that such devices will appear in 5G networks in the near future.
This section discusses those 5G network configuration aspects which have most impact on the power
consumption of the UE.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
164 / 178
Internal
© 2020 Nokia
Generally, it is not possible to directly measure the power drain on test terminals so more time consuming
methods such as charging the battery to 100% and observe how long it takes to be reduced to 50% must
be used. Due to this, there is not much experience with the features and parameters described in this section
in practice impact on battery life.
13.5.1
Inactivity timer
As long as the UE is in connected mode, it consumes power. Even when it is not transferring user plane
data, the UE needs to decode PDCCH symbols and transmit CSI reports. If proactive UL scheduling is used,
it will also need to transmit dummy data on the PUSCH. Therefore, a reduction of the 5G inactivity timer
(and of the 4G inactivity timer as well) will lead to lower UE power consumption.
On the other hand, too short inactivity timers mean increased user plane latency and more signalling in the
network. The inactivity timers are discussed in section 6.1 in the Retainability Optimization chapter and listed
in Table 36.
13.5.2
Connected Mode DRX
The use of connected mode DRX allows the UE to only monitor part of the slots for PDCCH information for
UL and DL grants. The UE is provided with parameters such that “active” and “sleep” periods are defined,
and the UE can then power down during the sleep periods and in this way potentially save some battery
power. On the other hand, since the UE is only reachable during the active periods, the average downlink
latency is increased. Also, the restrictions imposed on the network on when it can transmit to a given UE
means that the network capacity can be reduced.
There is not yet good knowledge of the positive aspects (i.e. the reduction in power consumption) of
Connected Mode DRX. The Network Engineering training on the feature (5GC000772 Common DRX)
includes simulation results for the negative aspects (longer delay and lower network capacity) with different
parameter settings. The C-DRX parameters are listed in Table 89 and discussed in chapter 10.
13.5.3
Proactive uplink scheduling
Proactive uplink scheduling allows the UE to by-pass the normal schedule request procedure. The gNB will
simply proactively assign transmission slots to a given UE. This means that the uplink latency can be
significantly reduced. However, a side effect in 5G19A is that the UE must transmit something in each of
these assigned slots. If it does not have user data to transmit, it must transmit dummy bits. Such transmission
of dummy bits will naturally increase the UE power consumption, as well as the overall interference level in
the network. The shorter the period between assigned transmission slots, the higher the UE power
consumption can be expected to be.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
165 / 178
Internal
© 2020 Nokia
Especially if ulDataPath has been set to “ulOverLTE”, it can be considered to disable proactive UL scheduling
on 5G because uplink user data will anyway be transmitted via the LTE leg.
There is not yet good knowledge of how serious the increased power consumption is. The parameters for
proactive UL scheduling are listed in Table 90 and discussed in chapter 10.
13.5.4
RF environment
A good RF environment will probably in general minimize the UE power consumption: Lower transmit power
can be used and the possibility of using higher coding schemes means that the transfer time for a given
amount of data will be shorter, and this is expected to lead to less power consumption in the UE.
However, it is possible that for some services (e.g. video streaming), a bad RF environment will not lead to
longer data transfer times but instead to reduced amount of data transfer, for example by reducing the
resolution when playing video clips. This means that the baseband part of the UE will have less data to
process, and it is possible that this out-weighs the increased power needed in the RF part of the UE.
13.6
BTS power efficiency
Feature id
Feature name
5GC001197
Micro discontinuous Trans. and Recept. (µDTRX) for Energy Efficiency
Table 108: Features related to BTS power efficiency
Since electricity is a major factor for operators’ operating expenses, 3GPP designed the 5G standard such
that the BTSs can operate with a high degree of power efficiency. From 5G19A onwards, various features
will be introduced to improve BTS power efficiency.
The 5GC001197: Micro discontinuous Trans. and Recept. (µDTRX) for Energy Efficiency feature allows to switch
off the RX/TX paths of the radio units for the symbol duration if no data is going to be received / sent.
28-Jan-2020 ULITPALIL5R3-1390467857-6948
166 / 178
Internal
© 2020 Nokia
Figure 49: Estimated power consumption when uDTX is in use. With 10% traffic load, there is a power saving of about 100 W / 400 W
= 25%
The feature does not have an activation flag and is activated by default. It supports only radio units with
eCPRI interface operating in the mmWave frequency band.
In 5G19A, it is not possible to directly measure the BTS power consumption. Counters for this will come with
the 5GC000433: Embedded Power Meter for Energy Efficiency feature, which will be available in a later
release.
13.7
BTS radiation level
Feature id
Feature name
5GC001329
EIRP monitor
Table 109: Features related to the monitoring and control of the BTS radiation levels
5G19A brings the first step towards a better control of the BTS transmit power when active antennas are in
use. 5GC001329: EIRP monitor brings counters to monitor the actual transmitted power and future releases
will bring features that allow better control of the transmitted power (5GC002052: EIRP control).
5GC001329 allows to define up to 60 “cell segments” and counters can then be used to monitor the power
transmitted towards each of these segments. It is also possible to monitor the transmitted power per beam
and the total transmitted power in the cell.
Counter id
Counter name
M55324C00000
EIRP_SAMPLES
28-Jan-2020 ULITPALIL5R3-1390467857-6948
167 / 178
Internal
© 2020 Nokia
Counter id
Counter name
M55324C00101..160
EIRP_SEGMENT_1..60
M55324C00200..260
MAX_EIRP_SEGMENT_0..60
M55324C00300..360
EIRP_CONTROL_SEGMENT_0..60
M55324C00400..463
ACTUAL_TX_POWER_BEAM_ID_0..63
M55324C00464
ACTUAL_TX_POWER_CELL
Table 110: Counters related to 5GC001329. The "control" counters will probably (?) not show values before 5G19B
Cell segments are configured using parameters:
-
MRBTS/NRBTS/NRCELL/eirpControl/numOfSegmentAzimuthEdges in range 0..9
-
MRBTS/NRBTS/NRCELL/eirpControl/segmentAzimuthEdge table with 1-degree granularity
-
MRBTS/NRBTS/NRCELL/eirpControl/numOfSegmentElevationEdges in range 0..5
-
MRBTS/NRBTS/NRCELL/eirpControl/segmentElevationEdge table with 1-degree granularity
In total, up to 60 cell segments may be configured with a minimum distance between two azimuth edges
of 10 degrees and 3 degrees between two elevation edges
28-Jan-2020 ULITPALIL5R3-1390467857-6948
168 / 178
Internal
© 2020 Nokia
Appendix I List of 5G RAN features
Feature id
Feature name
5GC000102
5GC000157
5GC000159
5GC000160
5GC000165
5GC000167
5GC000169
5GC000174
5GC000180
5GC000235
5GC000236
5GC000250
5GC000265
5GC000268
5GC000269
5GC000270
5GC000275
5GC000276
5GC000296
5GC000305
5GC000307
5GC000309
5GC000310
5GC000311
5GC000314
5GC000315
5GC000316
5GC000317
5GC000318
5GC000320
5GC000321
5GC000324
5GC000325
5GC000326
5GC000343
5GC000348
5GC000349
5GC000353
5GC000372
5GC000374
5G Node B Status display
Support NetAct connectivity
5G NodeB state management
5G Node B Radio Access Point Hardware Management in NMS
Performance management generic mechanism
Fault Management general flow and mechanism
5G Node B basic faults indication
5G Node B Software management
5G Node B Temperature management
gNB Configuration Management from Web Element Manager
gNB Object Model
Event logging on gNB
5G Node B Firewall on DU
Security for Ethernet Ports on DU
Linux Hardening on gNB
LINUX System account permissions on gNB
AirScale Common ASIK
AirScale Capacity ABIL
VNF CU on Third Party Infrastructure 1
Secure Boot for DU
Transport IPV4/IPv6 stack enhancement
Support of F1 interface over IPv4 or IPv6
M Plane over IPv4
M-plane over IPv6
Synchronization Hub
Sync Hub Direct Forward
5G Node B Synchronization Mode Support
1PPS&ToD Sync from Sync Hub Master
1PPS&ToD Sync from External GNSS Receiver
Synchronization Holdover Support
NTP based Time synchronization on CU
Operator Account Management on gNB
Nokia Service Account Management on gNB
OAM Transport Layer Security (TLS 1.2) Support on CU & DU
VNF Lifecycle management
5G Node B Hardware Monitoring in Web Element Manager
5G Performance counter for transport plane
QSFP+ for Fronthaul LL interface
5G Node B Web User Interface
5G Management with NSP and WPS
28-Jan-2020 ULITPALIL5R3-1390467857-6948
169 / 178
Internal
© 2020 Nokia
Feature id
Feature name
5GC000378
5GC000380
5GC000381
5GC000382
5GC000385
5GC000390
5GC000407
5GC000418
5GC000425
Beamforming Run-Time Calibration for 3rd Gen RF
10GBase-SR Optical GE Interface
Small Form Factor Pluggable SFP/SFP+/SFP28 slot
10GBase-LR Optical GE Interface
1000Base-SX Optical GE Interface
Vendor Certificate Management for DU
Log file scrambling for US-NSA
AMOB outdoor sub-rack for 5G
TDD lower layer support - 100 MHz cell bandwidth
5G Transport, Synchronization and Security Features rebasing on ASIK for Classical 5G
NodeB
X2 Management for NSA mode 3x operation
SgNB Addition and Release for NSA mode 3x operation
UE inactivity handling for NSA mode 3x operation
Radio Admission Control for NSA mode 3x operation
F1 link management
UE capability handling for NSA mode 3x operation
Classical BTS introduction
User Plane Performance counters for 18A
Control Plane Performance counters for 18A
L3 Non Standalone call with data transmission
Uplink open loop power control
DL power control
AEUA AirScale MAA 2T2R 512AE n257
Master Information Block
TDD scheduler for Multi-UE support
Analog Beamforming
5G18A operability functionality porting to classical BTS deployment
Ethernet termination
Ciphering of U-plane (NSA option 3x)
VNF Airframe compatibility matrix
VNF CU capacity and configuration
ASIK and ABIK for cloud BTS
Performance & Capacity Targets 5G18A
5G - LTE flow control at X2
TRS Support of NSA interfaces (X2 and S1-U) over IPv4 / IPv6
3GPP specification baseline Rel. 15 06/2018
5G DU configurations
CPRI fronthaul interface
AirScale Subrack AMIA
F1-U interface
ABIL & ASIK - new SW deployment
Multiple VLAN interfaces
AirScale Common ASIKA
AirScale Capacity ABIK
5GC000426
5GC000474
5GC000475
5GC000479
5GC000480
5GC000481
5GC000482
5GC000496
5GC000503
5GC000504
5GC000509
5GC000510
5GC000512
5GC000515
5GC000521
5GC000523
5GC000535
5GC000540
5GC000541
5GC000543
5GC000547
5GC000548
5GC000555
5GC000569
5GC000570
5GC000577
5GC000580
5GC000608
5GC000619
5GC000623
5GC000630
5GC000631
5GC000647
5GC000649
5GC000660
28-Jan-2020 ULITPALIL5R3-1390467857-6948
170 / 178
Internal
© 2020 Nokia
Feature id
Feature name
5GC000662
5GC000666
5GC000669
5GC000697
5GC000718
5GC000863
5GC000872
5GC000897
5GC000922
5GC000943
5GC001082
5GC001127
5GC001182
5GC001199
5GC001267
5GC001269
5GC001359
5GC001506
GNSS Receiver FYGM
Snapshot for 5GNB
Support of intra node gNB checks in WPS
AirPhone LTE-emulation for NSA
F1 cell management
ASIK and ABIL for cloud BTS
AMIC AirScale Indoor Mounting kit for DCM
gNB deployment - 5G18A
5GNB Compliances
E2E L2 call with NSA L3 in test mode
Classical gNB software Management
FR2 frame structure 4-1
5G CU single server for DU colocation - trial
gNodeB-DU with FDSW pre-delivery
AEWF AirScale MAA 2T2R 512AE n260
AEUF AirScale MAA 2T2R 512AE n257
5G18A Classical BTS Performance and Capacity
AEHA AirScale MAA 64T64R 128AE B41 200W
Table 111: 5G18A features
Feature id
Feature name
5GC000170
5GC000256
5GC000264
5GC000313
5GC000323
5GC000341
5GC000352
5GC000386
5GC000387
5GC000388
5GC000391
5GC000414
5GC000429
5GC000478
5GC000499
5GC000507
5GC000511
5GC000517
5GC000522
5GC000526
5GC000527
5GC000531
5GC000532
5G Node B recovery
License Management for 5G
IPsec on Backhaul
Timing over Packet with Phase Synchronization
Operator Certificate Management & Multi Layer of CA
Reducing gNB reset during gNB reconfiguration
GNSS receiver FYGC
1000Base-LX Optical GE Interface
1000Base-ZX Optical GE Interface
1000Base-BX Optical GE Interface
IPv6 for S Plane
5G DU configurations
AirScale Sub-rack sharing
Radio Link Failure handling for NSA mode 3x operation
PM reporting time improvement (5min)
Fault triggered snapshot
PRACH control
Uplink and Downlink link adaptation
256 QAM for PDSCH
DL Interference Generation - single cell
Intra-band CA TDD FR2 up to 2 CCs
DL SU adaptive MIMO
UL SU adaptive MIMO
28-Jan-2020 ULITPALIL5R3-1390467857-6948
171 / 178
Internal
© 2020 Nokia
Feature id
Feature name
5GC000533
5GC000551
5GC000562
5GC000572
5GC000583
5GC000584
5GC000605
5GC000609
5GC000624
5GC000625
5GC000636
5GC000645
5GC000664
5GC000683
5GC000684
5GC000703
5GC000719
5GC000720
5GC000757
5GC000758
5GC000762
5GC000769
5GC000772
5GC000794
5GC000846
5GC000848
5GC000869
5GC000886
5GC000898
5GC000921
5GC000952
5GC001009
5GC001025
5GC001070
5GC001075
5GC001077
5GC001094
5GC001097
5GC001116
5GC001138
5GC001179
5GC001208
5GC001210
5GC001213
5GC001253
Digital Beamforming for CPRI based RUs
Transfer Troubleshooting snapshot to Netact
AEQA AirScale MAA 64T64R 192AE B42 200W
Intra-Frequency Inter-DU en-gNB mobility (NSA option 3x, Cloud gNB)
Secure Key and File Storage for Radio Unit
RU Module Certificate Management
DL SU adaptive 4x4 MIMO (open loop)
ToP with Phase Sync Resiliency
10/25GBase-SR Optical GE Interface
10/25GBase-LR Optical GE Interface
3GPP specification baseline Rel. 15 09/2018 and NBC NSA 12/2018
5G Cloud OAM restart improvement
AEQD AirScale MAA 64T64R 128AE B43 200W
CU VNF architecture, configuration and capacity 5G19
VNF Airframe compatibility Matrix
5G DU configurations
AHLOA AirScale Dual RRH 4T4R B12/n71 240W
Asymmetric carrier aggregation
User Plane Performance counters for 19
Control Plane Performance counters for 19
5G centralized SON PCI management
Licensing Management framework for 5G
Common DRX
5G Node B Tracing mechanism for User Plane
5G19 Performance and Capacity - WM Classical BTS - NSA
BTS Fronthaul CPRI 7 - SFP+/SFP28 Dual Fiber Base Line
80 Mhz cell bandwidth for cmWave
Secondary RAT data volume reporting
gNB deployment - 5G19
Performance and Capacity - WM Cloud - NSA
Recovery for Classical gNB
E1 interface preparation
NR-LTE concurrent operation for CPRI TDD MAA radios
Bi-periodic 5 slot subframe configuration
60 Mhz cell bandwidth for cmWave
40 Mhz cell bandwidth for cmWave
Intra-Frequency Intra-DU en-gNB mobility (NSA option 3x)
Basic PCMD For NSA
TD-LTE co-existence subframe configuration
AAHF AirScale MAA 64T64R 128AE B41 120W
BTS Fronthaul CPRI 7 - QSFP+/QSFP28 Base Line
FR1 frame configuration 4-1
AAHJ AirScale MAA 64T64R 128AE B41 120W
Transport Reference Configurations
Loader and validator for migration from MZOAM to cOAM
28-Jan-2020 ULITPALIL5R3-1390467857-6948
172 / 178
Internal
© 2020 Nokia
Feature id
Feature name
5GC001304
5GC001326
5GC001492
5GC001640
5GC001725
5GC001844
5GC002017
5GC002203
5GC002204
Frame structure enhancement
Monthly system upgrade
AEQN AirScale MAA 32T32R 96AE n78 80W (CPRI w/o BF)
Remote access to gNB based on NCF
Intra-band CA TDD FR2 up to 4CCs DL
AHQK 5G Airscale RIU (CPRI) 1Cell 2x2 MIMO
AZQG (CPRI) 2x2 DL MIMO
AZQL (CPRI) 2x2 DL MIMO
AZQH (CPRI) 2x2 DL MIMO
Table 112: 5G19 features
Feature id
5GC000092
5GC000181
5GC000300
5GC000319
5GC000370
5GC000371
5GC000375
5GC000392
5GC000399
5GC000506
5GC000519
5GC000544
5GC000553
5GC000560
5GC000561
5GC000573
5GC000575
5GC000578
5GC000579
5GC000585
5GC000586
5GC000613
5GC000614
5GC000616
5GC000646
5GC000682
5GC000716
5GC000719
5GC000724
5GC000726
5GC000738
5GC000739
Feature name
5G Node B Plug and Play
HW addition and removal without service impact
VNF High Availability foundation for C-plane
Flexible Sync Input Priority
Tracing for Control Plane step 1
gNB recovery log collecting
5G Performance Monitoring for CPRI Link
IPsec on F1
eCPRI Fronthaul interface
Remote Syslog for continuous log storage
QoS Aware Ethernet Switch
Ciphering and Integrity Protection of C-Plane (NSA option 3x)
eCPRI Transport
eCPRI Sync Slave RU
eCPRI Sync Master Support
Intra-Frequency Inter en-gNB mobility (NSA option 3x)
Intra-MeNB LTE handover without en-gNB change (NSA Option 3x)
Direct RRC signaling for NSA mode 3x operation
Long fiber support for CPRI fronthaul
AEUB AirScale MAA 2T2R 512AE n257
AEWB AirScale MAA 2T2R 512AE n260
EAC support on gNB
Link Diagnostic and Monitoring
7750-SR as Security Gateway
GNSS receiver AYGA
VNF CU on Third Party Infrastructure, Generic approach
5G DU configurations, mmWave-eCPRI
AHLOA AirScale Dual RRH 4T4R B12/n71 240W
AHFIB AirScale Dual RRH 4T4R n25/n66 320W
NR-LTE FDD concurrent operation for CPRI RUs
Multiple PLMN ID support
Frequency Sync Mode Support
28-Jan-2020 ULITPALIL5R3-1390467857-6948
173 / 178
Internal
© 2020 Nokia
Feature id
5GC000763
5GC000776
5GC000782
5GC000792
5GC000795
5GC000836
5GC000847
5GC000849
5GC000850
5GC000851
5GC000855
5GC000856
5GC000894
5GC000913
5GC000918
5GC000920
5GC000928
5GC000940
5GC000951
5GC000958
5GC000959
5GC000978
5GC000980
5GC000997
5GC000998
5GC001028
5GC001037
5GC001072
5GC001073
5GC001074
5GC001091
5GC001121
5GC001145
5GC001146
5GC001150
5GC001152
5GC001157
5GC001161
5GC001177
5GC001187
5GC001188
5GC001197
5GC001200
5GC001246
5GC001274
Feature name
5G centralized SON PRACH management
non GBR service differentiation
Additional security algorithms for ciphering of U-Plane (NSA option 3x)
FDD Scheduler for Multi-UE support
Multiple DRBs per UE (NSA mode 3x)
FDD lower layer support - 5-20 MHz cell bandwidth
BTS Fronthaul CPRI 7 - 10GE SFP+ Dual Fiber Base Line
BTS Fronthaul CPRI 7 - 10GE SFP+ Single Fiber
BTS Fronthaul CPRI 7 - 10GE SFP+ CWDM
BTS Fronthaul CPRI 7 - 10/25GE SFP28 Single Fiber
AEUD AirScale MAA 2*2T2R 256AE n257
AEWD AirScale MAA 2*2T2R 256AE n260
Source based routing
QoS Support for Terminated Traffic
Analog Beamforming for eCPRI based RUs
DL 4x4 SU MIMO without beamforming (open loop)
AHPMDA AirScale Tri RRH 2T2R n8/n20/n28 240W
gNB configurable identifier
Tracing for control plane step 2
AEUE AirScale MAA 2*2T2R 256AE n257
AEWE AirScale MAA 2*2T2R 256AE n260
CU VNF Geo Redundancy with NSP
ALD support in gNB for Nokia CPRI radio units
AWHQA AirScale Indoor Radio n78 (B42) ASiR-pRRH
DU configurations, legacy FDD CPRI Radios (I)
Backplane Interfaces for Subrack Sharing
Conformance Test and Type Approval
AWHQB AirScale Indoor Radio n78 (B43) ASiR-pRRH
AWHQC AirScale Indoor Radio n78 (3.3-3.6GHz) ASiR-pRRH
Offline validation in NetAct
AirScale Indoor Radio NR operation
AMOD outdoor sub-rack for 5G
Classic gNB supporting basic common OAM (L3 call)
Common OAM on classical gNB
AHBCC AirScale Dual RRH 4T4R n5/13 320W
AHCA AirScale RRH 4T4R n5 160W
AirScale Micro 4T4R n78 40W AWHQE
Plug-in radio SW interface for CPRI
DU Configuration AirScale Indoor Radio SFN configuration
ASOD Add-on 5G Compact Baseband Unit (limited avail.)
AirScale Indoor Radio ASiR-sHUB (APHA)
Micro discontinuous Trans. and Recept. (µDTRX) for Energy Efficiency
Dynamic uplink data split mode
AirScale Indoor Radio LTE and NR concurrent operation
AirScale Micro 4T4R n78 40W AWHQF
28-Jan-2020 ULITPALIL5R3-1390467857-6948
174 / 178
Internal
© 2020 Nokia
Feature id
5GC001278
5GC001311
5GC001329
5GC001335
5GC001336
5GC001340
5GC001347
5GC001355
5GC001417
5GC001427
5GC001457
5GC001461
5GC001496
5GC001515
5GC001525
5GC001526
5GC001535
5GC001541
5GC001542
5GC001543
5GC001544
5GC001545
5GC001546
5GC001547
5GC001612
5GC001618
5GC001625
5GC001626
5GC001638
5GC001639
5GC001648
5GC001649
5GC001650
5GC001655
5GC001656
5GC001681
5GC001684
5GC001699
5GC001700
5GC001707
5GC001776
5GC001779
5GC001783
5GC001784
5GC001795
Feature name
AirScale Micro 4T4R n78 40W AWHQG
AirScale Indoor Radio Daisy Chaining 4G and 5G ASiR-pRRH
EIRP monitor
Migration from MZ OAM to cOAM for classical gNB
3GPP Baseline for 19A release
CM and Fault ID adaptation for 5G cOAM migration
Additional DMRS configuration
AWHHA AirScale Indoor Radio n41 ASiR-pRRH
DU Configuration AirScale Indoor Radio SFN configuration for 40MHz 60MHz and 80MHz
5G DU configurations, ASOD eCPRI mmWave (limited avail.)
System Upgrade to 5G19A
Golden Database (DB) verification
gNB deployment - 5G19A
Airscale Capacity ABIL HW evolution
Common OAM functional equivalence to 5G19 classical gNB Pack 1
Common OAM functional equivalence to 5G19 classical gNB Pack 2
TLDA snapshot decoding and snapshot documentation
AirScale Micro 4T4R n41 80W AWHHD
Common OAM functional equivalence to 5G19 classical gNB Pack 3
Common OAM functional equivalence to 5G19 classical gNB Pack 4
Common OAM functional equivalence to 5G19 classical gNB Pack 5
Common OAM functional equivalence to 5G19 classical gNB Pack 6
Common OAM functional equivalence to 5G19 classical gNB Pack 7
Supplemental downlink cell - FR2
EdenNet support of 5G19A
AirScale Indoor Radio dual-port Ethernet extender (APHD)
Common OAM functional equivalence to 5G19 classical gNB Pack 2.2
5G DU configurations, CPRI
Common OAM functional equivalence to 5G19 classical gNB Pack 3.2
Common OAM functional equivalence to 5G19 classical gNB Pack 3.3
AWHQJ AirScale Indoor Radio n78 (B42) ASiR-pRRH with external antennas
AWHHC AirScale Indoor Radio n41 ASiR-pRRH with external antennas
Configurable frame structure for ASiR
Common OAM functional equivalence to 5G19 classical gNB Pack 4.2
Common OAM functional equivalence to 5G19 classical gNB Pack 4.3
Debug trace improvement
HW activation license for ASiR-pRRH Tx power
AirScale 4G+5G mRRH Enclosure (FMWV)
Common OAM functional equivalence to 5G19 classical gNB Pack 5.2
AirScale Micro 4T4R n41 80W AWHHF
AirScale Micro 2T2R n41 200W AWHHG
Limit configuration impact of DU addition
AEQB AirScale MAA 64T64R 192AE B42 200W (CPRI)
5G19A Performance and Capacity
AZQG AirScale RRH 8T8R n78 320W (CPRI)
28-Jan-2020 ULITPALIL5R3-1390467857-6948
175 / 178
Internal
© 2020 Nokia
Feature id
5GC001802
5GC001804
5GC001810
5GC001811
5GC001821
5GC001822
5GC001823
5GC001824
5GC001825
5GC001829
5GC001830
5GC001831
5GC001836
5GC001845
5GC001854
5GC001857
5GC001860
5GC001864
5GC001867
5GC001870
5GC001874
5GC001875
5GC001876
5GC001878
5GC001879
5GC001880
5GC001897
5GC001898
5GC001933
5GC001934
5GC001942
5GC001943
5GC001954
5GC001982
5GC001983
5GC002009
5GC002028
5GC002029
5GC002154
5GC002194
5GC002275
5GC002276
5GC002388
5GC002446
5GC002449
Feature name
Enhanced cloud software management
Basic PCMD user plane
AZQH AirScale RRH 8T8R n78 320W (CPRI)
AZQL AirScale RRH 8T8R n78 320W (CPRI)
5G DU configurations, additional cmWave-CPRI
AEQN AirScale MAA 32T32R 96AE n78 80W (CPRI)
CPRI extension to SFP for broadband
4 cells per ABIL/ASOD in FR2
CU VNF architecture, configuration and capacity 5G19A
Spillover from 5GC001094 (intra-DU PSCell change)
Spillover 5GC001009 E1 interface Concurrency handling & Error indication
Intra-band CA TDD FR2 up to 4CCs DL - 2CCs UL
Spillover from 5GC000480 Radio Admission Control for NSA mode 3x operation
CU VNF compatibility Matrix 5G19A
Spillover for basic TDD scheduler for multi-UE support
Spillover 5GC000580 3GPP specification baseline Rel. 15 06/2018
AirScale BBU Support of DAS via CPRI-N Interface
Transport reference configuration
Secondary RAT data volume reporting for multiple DRBs
DL SU adaptive 4x4 MIMO
Non contention based random access
Spillover - 256QAM
Spillover from 5GC00772 Common DRX
DL Interference Generation - multiple cells
User plane performance counters for 5G19A
Control plane performance counters for 5G19A
BTS Fronthaul CPRI 7 - 10/25GE SFP+/SFP28 Dual Fiber Base Line
BTS Fronthaul CPRI 7 - 10/25GE QSFP+/QSFP28 Base Line
AAHJ 60 MHz carrier support
Frame structure spill-over content handling
Spillover digital Beamforming for CPRI based RUs
Spillover analog beamforming
Introduction of A2 based SgNB release
L1 algorithm changes - 5G19A
Spillover UL SU adaptive MIMO
AEQA 60 & 80 MHz carrier support
AHBCB AirScale Dual RRH 4T4R n5/B29 240W
AHQK 5G Airscale RIU (CPRI) 4x4 MIMO & 2Cell 2x2 MIMO
AZQM AirScale RRH 8T8R n77 160W (CPRI-Trial only)
NSP support of Classical 5G with COAM architecture for VzW
ASOD/ASIK commissioning - early deployment procedure
ASOD/ASIK commissioning - PnP phase 1 procedure
Sleeping cell 1, RACH detection
AEQE AirScale MAA 64T64R 192AE n78 200W (Com. Introduction)
AEQP AirScale MAA 64T64R 192AE n78 200W (Com. Introduction)
28-Jan-2020 ULITPALIL5R3-1390467857-6948
176 / 178
Internal
© 2020 Nokia
Feature id
5GC002450
5GC002535
Feature name
Antenna tilt for 2D GoB (Com. Introduction)
FDM of DMRS and PDSCH
Table 113: 5G19A features
28-Jan-2020 ULITPALIL5R3-1390467857-6948
177 / 178
Internal
© 2020 Nokia
Appendix II
Feature id
LTE4088
LTE4193
LTE4575
LTE4744
LTE4824
LTE5176
LTE4461
LTE4530
LTE4531
LTE4572
LTE4873
LTE5335
LTE5524
LTE4281
LTE4549
LTE5115
LTE5150
LTE5190
LTE5407
LTE5510
LTE5558
List of LTE EN-DC features
Feature name
LTE-NR Dual Connectivity Option 3X
Dynamic Trigger for LTE-NR DC Option 3X
Blind Carrier Aggregation with LTE-NR DC Option 3X
gNB Initiated EN-DC Configuration Update
NR-LTE concurrent operation for TDD MAA radios with split mode
3GPP R15 December 2018 for EN-DC
NR-LTE FDD concurrent operation for CPRI RUs
Inter-SgNB Mobility for LTE-NR DC Option 3X
LTE-NR DC Option 3X: Multiple non-GBR SCG split Bearers
Idle mode mobility to 5G SA
Secondary RAT Data Usage Report for EN-DC
LTE-NR DC Option 3X Enhancements
Ongoing QCI1 prevents EN-DC setup
Intra-eNB handover for LTE-NR DC Option 3X
Flexible LTE CA with EN-DC
NR-LTE concurrent operation with 32TRx split mode on ABIC
EN-DC capability based mobility trigger
X2 partial reset with gNB
LTE-NR Dynamic Spectrum Sharing phase I
Stepwise addition of multiple bearers for EN-DC
S1 Handover for LTE-NR DC option 3X
Release
LTE19
LTE19
LTE19
LTE19
LTE19
LTE19
LTE19A
LTE19A
LTE19A
LTE19A
LTE19A
LTE19A
LTE19A
LTE19B
LTE19B
LTE19B
LTE19B
LTE19B
LTE19B
LTE19B
LTE19B
Table 114: LTE EN-DC features
28-Jan-2020 ULITPALIL5R3-1390467857-6948
178 / 178
Internal
© 2020 Nokia