5G Mobility and Traffic Management

Guideline

Document Number Revision

2/154 43-LZA 701 6017 Uen J
Copyright

© Ericsson AB 2019 - 2020. All rights reserved. No part of this document may be reproduced in
any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress
in methodology, design and manufacturing. Ericsson shall have no liability for any error or
damage of any kind resulting from the use of this document.

Trademark List

All trademarks mentioned herein are the property of their respective owners. These are shown
in the document Trademark Information.
 5G Mobility and Traffic Management Guideline

Contents
1 Purpose ............................................................................................ 5

2 Scope ............................................................................................... 5

3 Definitions ........................................................................................ 6

4 Mobility and Connectivity Overview ............................................. 10

4.1 5G Connectivity Options .................................................................. 10
4.2 Frequency Ranges & Bands ............................................................ 11
4.3 Ericsson Spectrum Sharing (ESS) ................................................... 12
4.4 Mobility States ................................................................................. 13
4.5 5G Status Icon on UE ...................................................................... 16
4.6 Measurement Quantities.................................................................. 18
4.7 Connected Mode Measurements ..................................................... 19

5 Connectivity and Bearers – NSA .................................................. 26

5.1 Radio Bearer Types – NSA.............................................................. 26
5.2 Radio Bearer Transitions – NSA ...................................................... 27
5.3 Split Bearer User Plane Functions – NSA ........................................ 29
5.4 Downlink Carrier Aggregation – NSA ............................................... 36
5.5 Uplink Carrier Aggregation – NSA ................................................... 38

6 Mobility and Connectivity Procedures – NSA.............................. 40

6.1 Idle Mode Procedures – NSA .......................................................... 41
6.2 Data Bearer Setup and Release Procedures – NSA ........................ 42
6.3 NR Coverage-Triggered Mobility Procedures – NSA ....................... 55
6.4 VoLTE Procedures – NSA ............................................................... 59
6.5 CS Fallback Procedures – NSA ....................................................... 64
6.6 LTE Coverage-Triggered Mobility Procedures – NSA ...................... 65
6.7 LTE Load-Triggered Mobility Procedures – NSA ............................. 69

7 Mobility and Connectivity Procedures – SA ................................ 71

7.1 Idle Mode Procedures – SA ............................................................. 71
7.2 Connected Mode Procedures – SA.................................................. 75
7.3 Interworking Between LTE and NR SA ............................................ 82

8 LTE Anchor Carrier Management – NSA...................................... 85

8.1 Choosing Suitable Anchor Carriers – NSA....................................... 85
8.2 Steering 5G UEs to an Anchor Carrier – NSA.................................. 89
8.3 Steering non-5G UEs away from an Anchor Carrier ...................... 114
8.4 Configuring SPID for Anchor Carrier Control ................................. 115
8.5 Configuring QCI for 5G Users ........................................................ 117

9 Appendix 1 – Mobility Features .................................................. 120

9.1 Software Value Packages and Features ........................................ 120
9.2 eNodeB Features .......................................................................... 122
9.3 gNodeB Features .......................................................................... 154
9.4 MME Features ............................................................................... 157

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 3 (179)
 5G Mobility and Traffic Management Guideline

10 Appendix 2 – Mobility Trigger Levels ......................................... 159

10.1 Idle Mode....................................................................................... 159
10.2 Connected Mode ........................................................................... 168

11 Appendix 3 – Mobility KPIs ......................................................... 174

11.1 Key Performance Indicators – NSA ............................................... 174
11.2 Additional Performance Indicators – NSA ...................................... 174
11.3 Key Performance Indicators – SA .................................................. 176
11.4 Additional Performance Indicators – SA ........................................ 176

12 Appendix 4 – Configuration Profiles .......................................... 178

13 Appendix 5 – Release History..................................................... 179

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 4 (179)
 5G Mobility and Traffic Management Guideline

1 Purpose
This document provides guidelines on developing customized mobility and traffic
management strategies for Ericsson 5G network deployments. The strategies are designed
to maximize the benefit for 5G capable users whilst maintaining or improving service
quality for legacy users.

The current Ericsson solution supports both standalone (SA) and non-standalone (NSA)
5G deployments:

• Standalone (SA) 5G: UEs connect to the 5G core (5GC) using the 3GPP New Radio
(NR) Radio Access Technology (RAT) for 5G. This is also known as Option 2.

• Non-standalone (NSA) 5G: UEs connect to the Evolved Packet Core (EPC) using
both LTE and NR, using the 3GPP configuration EN-DC (also known as Option 3x).
This option is called non-standalone because UEs that are connected to the network
through NR also have a connection through LTE.

This document covers both these deployment options, and therefore encompasses mobility
on both NR and LTE. It also covers the Ericsson Spectrum Sharing (ESS) solution, where
the same spectrum is dynamically shared between NR and LTE.

2 Scope
This document covers the 2020 Q4 release of LTE and NR software (referred to in this
document as “the current release”). Changes from previous releases are summarized in
Section 13.

NOTE: Always check the release notes for variations in functionality; for example, some
functionality may be introduced in different releases for high band and low band,
or for a dedicated NR carrier and an ESS carrier.

This document covers both of the 5G options supported by Ericsson, namely Standalone
5G (SA) and Non-standalone 5G (NSA).

The focus is on Radio Access Network functionality. However, core network functionality is
covered at a high level where relevant.

LTE functionality is covered only where relevant for the 5G solution; the remainder is
covered in the CPI document LTE Mobility and Traffic Management Guideline.

Recommended parameter values are provided for common deployment cases in the CPI
document RAN Parameter Recommendations. This guideline provides recommended
values only for cases which fall outside that document.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 5 (179)
 5G Mobility and Traffic Management Guideline

3 Definitions
The following conventions are used in this document:

• Names of MO classes, structures, attributes and their values are shown in courier
font.

• Names of features are shown in italics.

The following terms and acronyms are used in this document:

Term Definition
5GC 5G Core
5QI 5G Quality of Service Indicator
5G_Idle_Go These acronyms refer to the five anchor management
5G_Idle_Stay strategies which are defined in this document. The
5G_HO_Go strategies are used to maximize EN-DC availability, by
steering EN-DC capable UEs towards LTE cells which
5G_Cov_Stay
are capable of acting as anchors for EN-DC.
5G_LB_Stay
ANR Automated Neighbor Relations
ASGH Advanced Subscriber Group Handling
BIC The feature Basic Intelligent Connectivity
BNR The feature Best Neighbor Relations for Intra-LTE Load
Management
CAIMC The feature Capability-Aware Idle Mode Control
CC Component Carrier
CPI Customer Product Information
CS Circuit Switched
CSM The feature Cell Sleep Mode
CSI Channel State Information
DL Downlink
DRB Data Radio Bearer
eLTE Evolved LTE. In eLTE, the eNodeB is connected to the
5GC, as defined in 3GPP Rel-15. Relevant only for 5G
deployment options 4, 5 and 7; which are not required
by Ericsson 5G solutions.
EN-DC EUTRAN-NR Dual Connectivity. This is also known as
Option 3x.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 6 (179)
 5G Mobility and Traffic Management Guideline

Term Definition
ENDCHO An inter-frequency handover on LTE which is triggered
by one of the following features: EN-DC Triggered
Handover During Setup, EN-DC Triggered Handover
During Connected Mode Mobility or Basic EN-DC
Triggered Handover During Setup. The purpose of
ENDCHO is to move the UE to an LTE cell which is
better suited to provide it with EN-DC.
eNodeB, eNB The eNodeB provides LTE user plane and control plane
protocol terminations towards the UE and is connected
via the S1 interface to the EPC.
EPC Evolved Packet Core
EPS Evolved Packet System
ESM EPS Subscription Manager
ESS Ericsson Spectrum Sharing. An Ericsson 5G solution
where spectrum is dynamically shared between an NR
carrier and an LTE carrier.
FAJ Prefix given to an Ericsson value package number or
feature number
gNodeB, gNB The gNodeB provides NR user plane and control plane
protocol terminations towards the UE and is connected
via the NG interface to the 5GC.
Note: In this document the term gNodeB is also used to
refer to the NR Node in an EN-DC context, even though
EN-DC does not involve connection to the 5GC.
HARQ Hybrid Automatic Repeat Request
HRL Handover Restriction List
HSS Home Subscriber Server
IMMCI Idle Mode Mobility Control Information
IMS IP Multimedia Subsystem
KPI Key Performance Indicator
LTE Long Term Evolution (4G Radio Interface Standard)
MAC Media Access Control
MBB Mobile Broadband
MCG Master Cell Group
MCPC The feature Mobility Control at Poor Coverage
MCPTT Mission Critical Push-To-Talk
MLSTM The feature Multi-Layer Service-Triggered Mobility
MME Mobility Management Entity
MN Master Node (eNodeB in an EN-DC deployment)
MR-DC Multi-RAT Dual Connectivity
(EN-DC is one type of MR-DC)
NAS Non-Access Stratum

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 7 (179)
 5G Mobility and Traffic Management Guideline

Term Definition
NCGI NR Cell Global Identity
NSA Non-standalone 5G.
A 5G deployment option where UEs connect to the
network using both LTE and NR RATs. The Ericsson
NSA solution uses the 3GPP configuration EN-DC; also
known as Option 3x, along with LTE (Option 1).
NR New Radio (5G Radio Interface Standard)
Option 1 Terms used to describe UE to network connectivity
Option 2 options. Option 1 is LTE, Option 2 is NR, Option 3x is
Option 3x EN-DC.
PDCP Packet Data Convergence Protocol
PDSCH Physical Downlink Shared Channel
PI Performance Indicator
PLMN Public Land Mobile Network
PRB Physical Resource Block
PSCell Primary Cell in Secondary Cell Group
PUSCH Physical Uplink Shared Channel
QCI Quality of Service Class Identifier
RAT Radio Access Technology
RLC Radio Link Control
RLF Radio Link Failure
RRC Radio Resource Control
RTT Round Trip Time
S-NSSAI Single-Network Slice Selection Assistance Information
SA Standalone (5G)
A 5G deployment option where UEs connect to the core
network using the NR RAT. Also known as Option 2.
SCell Secondary Cell (for Carrier Aggregation)
SCG Secondary Cell Group
SGNB Secondary gNodeB
SGSN Serving GPRS Support Node
SINR Signal to Interference and Noise Ratio
SN Secondary Node (gNodeB in an EN-DC deployment)
SPID Subscriber Profile ID for RAT/Frequency Priority
SRB Signaling Radio Bearer
SRVCC Single Radio Voice Call Continuity
SSB Synchronization Signal and Physical Broadcast
Channel Block
SSLM The feature Service Specific Load Management

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 8 (179)
 5G Mobility and Traffic Management Guideline

Term Definition
SS-RSRP Synchronization Signal Reference Signal Received
Power
SS-RSRQ Synchronization Signal Reference Signal Received
Quality
STM The feature Subscriber Triggered Mobility
TAC Tracking Area Code
UE User Equipment
UL Uplink
VoIP Voice over IP
VoLTE Voice over LTE
VoNR Voice over NR

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 9 (179)
 5G Mobility and Traffic Management Guideline

4 Mobility and Connectivity Overview

This section provides an overview of concepts and functionality which are fundamental to
understanding 5G mobility and traffic management.

4.1 5G Connectivity Options

In standardizing 5G, 3GPP defines six options for how a single UE is connected to the
network at a given point in time, see Table 4-1. The options are differentiated by the
following characteristics:

• The core network used

Either the Evolved Packet Core (EPC) or the 5G Core (5GC)

• The Master Radio Access Technology (RAT)

The Master RAT terminates the Control Plane from the core network. It is either LTE,
New Radio (NR) or Evolved LTE (eLTE).

• The Secondary RAT

This Secondary RAT supplies additional user plane resources. Not all options have a
Secondary RAT.
Table 4-1 – UE Connectivity Options
Connectivity Core Master Secondary 3GPP
Option Network RAT RAT Term
Option 1 EPC LTE - LTE
Option 3 EPC LTE NR EN-DC
Option 2 5GC NR - NR
Option 4 5GC NR eLTE NE-DC
Option 5 5GC eLTE - eLTE
Option 7 5GC eLTE NR NGEN-DC

In a given network deployment, a base station may support more than one option
simultaneously, with individual UEs connected by different options or even combinations of
options.

The current Ericsson release supports three of the six options:

• Option 1: This is legacy LTE.

• Option 2: This is the NR Standalone (SA) option for 5G, where the UE connects to the
5GC using only one RAT, namely New Radio (NR).

• Option 3x: This is a non-standalone (NSA) option, where the UE connects to the
Evolved Packet Core (EPC) using both the LTE and NR RATs. Option 3x is one of the
three alternatives for Option 3, EUTRA-NR Dual Connectivity (EN-DC). In Option 3x,
the Master Node (the eNodeB) terminates the control plane from the MME (S1-AP),
and the Secondary Node (NR Node) terminates the user plane (S1-U). Option 3x is
used together with Option 1 in the Ericsson NSA solution for 5G.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 10 (179)
 5G Mobility and Traffic Management Guideline

These three options are shown in Figure 4-1.

Figure 4-1 – 5G Connectivity Options

This document uses the term NSA and SA as follows:

• NSA: Refers to the Ericsson solution for non-standalone 5G, which uses a combination
of Option 3x and Option 1. How these options are used together in the NSA solution is
described in Section 5.

• SA: Refers to the Ericsson solution or standalone 5G, which uses Option 2 only.

4.2 Frequency Ranges & Bands

4.2.1 Standardized Ranges FR1, FR2

3GPP 38.101 defines two Frequency Ranges (FRs) for NR:

Table 4-2 – Frequency Ranges
Frequency Range Definition
FR1 410 – 7125 MHz
FR2 24250 – 52600 MHz

The 3GPP specifications sometimes have separate requirements for the two ranges.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 11 (179)
 5G Mobility and Traffic Management Guideline

4.2.2 Low, Mid and High-Band

Additionally, the Ericsson radio products refer to the following frequency ranges:

Low-band (FDD) < 6 GHz

Legacy & new spectrum For example: 1.8 GHz or 2.1 GHz

Mid-band (TDD) < 6 GHz

Legacy & new spectrum For example: 3.5 GHz

High-band (TDD) > 24 GHz (mm wave)

New spectrum For example: 28, 39 GHz

In the current software revision, NSA is supported on all three bands and SA is supported
on low and mid-band spectrum.

4.3 Ericsson Spectrum Sharing (ESS)

Ericsson Spectrum Sharing (ESS) is a solution to enable efficient NR deployment in LTE
FDD frequency bands. With ESS, an NR carrier and an LTE carrier are deployed
simultaneously on the same frequency, using the same Ericsson Radio System equipment.
This avoids the need for a dedicated NR carrier, facilitating rapid deployment of wide area
5G coverage and enabling a smooth transition between LTE and NR as the network
evolves. ESS is supported with both NR NSA and SA.

ESS dynamically shares the LTE spectrum with NR NSA and/or NR SA, of bandwidth 10,
15 or 20 MHz. The split of PRBs between LTE and NR is adjusted every millisecond in
response to offered traffic variations on the two technologies, as shown in Figure 4-2.

Figure 4-2 – Ericsson Spectrum Sharing Between LTE and NR

ESS requires that the LTE and NR carriers have the same bandwidth and center
frequency. In case of NR NSA, the anchor for the ESS NR carrier must be an LTE carrier
on another frequency; it cannot be the LTE carrier on the ESS frequency.

ESS requires support in the UE, using the toolbox of UE capabilities for spectrum sharing
between NR and LTE defined by 3GPP in Release 15.4.0.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 12 (179)
 5G Mobility and Traffic Management Guideline

ESS causes a small reduction in LTE capacity due to NR overhead. However, ESS allows
a smooth transition from LTE to NR which is not possible if the carrier is instead statically
re-farmed from LTE to NR.

4.4 Mobility States

With the introduction of 5G SA, there are two core networks:

• EPC: The Evolved Packet Core, which is used for LTE and 5G NSA

• 5GC: The 5G Core, which is used for 5G SA

Each of these core networks has two functionalities that manage the state of the UE.

The first functionality manages registration of the UE on the network. In EPC this
functionality is called EPS Mobility Management (EMM) and in 5GC it is called Registration
Management (RM). In both EMM and RM there are two states, deregistered and
registered:

• Deregistered: The UE is not in contact with the network. It is turned off, out of
coverage, etc.

• Registered: The UE is known to the network and can send or receive traffic when
required.

The second functionality manages the signaling connection between the UE and core. In
EPC this functionality is called EPS Connection Management (ECM) and in 5GC it is called
Connection Management (CM). In both ECM and CM there are two states, idle and
connected:

• Idle: In idle mode, the UE does not consume radio resources (other than paging
channel) and must transition to connected state before sending or receiving traffic

• Connected: In connected mode, the UE location is known at a cell level and can send
data to or receive data from the network, and so is consuming radio resources.

The terminology used to describe these states is slightly different in the EPC and the 5GC.
The differences are shown in Figure 4-3; blue for the EPC and orange for the 5GC.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 13 (179)
 5G Mobility and Traffic Management Guideline

Figure 4-3 – UE Mobility States in EPC and 5GC

4.4.1 ECM-IDLE/CM-IDLE, Idle Mode

In idle mode, all UE related information in the radio network is released. This reduces load
in the eNodeB or gNodeB during long periods of inactivity. The core network retains the UE
context and information about established bearers, but there is no explicit signaling
between the UE and the core network.

However, the UE is still in EMM-REGISTERED/RM-REGISTERED state, indicating that it is

attached to the network and may transition to connected mode in response to a paging
request, user activity or other reason, without having to perform a full attach procedure.

An eNodeB or gNodeB does not know how many UEs are camped within its coverage area
in idle mode. The location of an idle UE is only known within a Tracking Area List, which is
a group of Tracking Areas configured in the core network. Idle mode reselection
parameters are broadcast in each cell, and a UE is responsible for evaluating nearby cells
and camping on the correct cell as determined by the broadcasted parameters. A UE which
moves into a cell which is not in the current Tracking Area List must change to connected
state to signal this to the network (via a Tracking Area Update), before returning to idle
again.

In idle mode the UE is responsible for selecting and reselecting between cells, frequencies
and access technologies, using information broadcast by the eNodeB or gNodeB.

Further information on idle mode procedures is provided in Section 6 for NSA and Section
7 for SA.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 14 (179)
 5G Mobility and Traffic Management Guideline

4.4.2 ECM-CONNECTED/CM-CONNECTED, Connected Mode

In connected mode the UE makes no mobility decisions and responsibility is transferred to

the network; an exception to this is the RRC re-establishment procedure, where a UE may
relocate to a new cell due to a radio link failure whilst in connected mode.

A UE can be instructed (via RRC Reconfiguration messaging) to report certain mobility

events, such as when the serving cell signal drops below a particular level. This, in turn,
causes the network to take further action, such as instructing the UE to configure further
measurements or perform a handover.

Further information on connected mode procedures is provided in Section 6 for NSA and
Section 7 for SA.

4.4.3 RRC State

There is also a UE state which is managed by RAN, namely the RRC state; RRC-IDLE,
RRC-CONNECTED or RRC_INACTIVE.

• RRC-IDLE: The UE has no signaling connection to RAN. This state is used in both LTE
and NR SA.

• RRC-CONNECTED: The UE has a signaling connection to the RAN. This state is used
in both LTE and NR SA.

• RRC-INACTIVE: The UE has a suspended connection to RAN. This state is used only
for NR SA as it requires a 5GC. RRC-INACTIVE state is not implemented in the current
release of the Ericsson 5G solution.

These RRC states are shown in Figure 4-4 for NR SA.

Figure 4-4 – RRC States in NR SA

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 15 (179)
 5G Mobility and Traffic Management Guideline

4.5 5G Status Icon on UE

Network operators and UE vendors require some way of indicating to the end user that 5G
service is potentially available, for example by displaying a 5G icon on the phone’s screen.
The criteria for displaying a 5G icon are not standardized by 3GPP and it is up to the UE
vendor and operator to decide under what conditions a 5G indication should be displayed.
The decision is straightforward in a 5G SA deployment: the UE can display the 5G icon
whenever the serving master RAT is NR. However, in an NSA deployment (EN-DC), the
UE is not always aware whether 5G service is available, as the UE camps on LTE in idle
mode and the control plane is on LTE in connected mode.

To assist the UE in idle mode for NSA EN-DC, 3GPP have standardized a 1-bit indication
per cell and PLMN called upperLayerIndication-r15 that is broadcast in LTE SIB2. This bit
can be used by the network operator to indicate that 5G service is potentially available to
an EN-DC capable UE. However, the bit can be set independently of the functionality
actually provided by the cell or related cells. As such, the operator decides whether to set
the bit and the UE decides how the bit impacts the display of any 5G indication. This bit is
the only 3GPP agreed mechanism for determining the availability of 5G when camped on
LTE in idle mode. In connected mode the EN-DC capable UE has additional information to
determine whether 5G service is potentially available. For example, the UE can consider
whether it is configured with measurements to detect NR coverage, whether it has actually
detected NR coverage and whether it has any bearers connected to an NR cell.

The GSM Association (GSMA) recommends one configuration as a default for determining
whether to display the 5G status icon. The configuration is shown in Table 4-3. GSMA
submitted this recommendation to 3GPP in a liaison statement (SP-190216, LS Reply to
3GPP RAN on Work Status of 5GSI). The table can be summarized to a single, simple
recommendation; show the indication if the LTE cell supports NSA, otherwise don’t show it.
This implies; set the upper layer indication to ON when the LTE cell supports NSA, and
OFF otherwise.
Table 4-3 - GSMA Recommendations for the UE Indication
State UE Indication
1. Idle under or connected to LTE cell not supporting NSA 4G
2. Idle under or connected to LTE cell supporting NSA and
5G
no detection of NR coverage
3. Connected to LTE only under LTE cell supporting NSA
5G
and detection of NR coverage
4. Idle under LTE cell supporting NSA and detection of NR
5G
coverage
5. Connected to LTE + NR under LTE cell supporting NSA 5G

Figure 4-5 summarizes the recommendation for displaying the 5G icon in an example NSA
network deployment. The top pane shows the coverage from the NR and LTE cells, and in
which LTE cells EN-DC is enabled and the upperLayerIndication-r15 bit is set. The lower
pane shows where the 5G Icon will be ON and OFF, given the UE state (shown in black on
the left) and the GSMA state (circled). The example assumes that the operator has chosen
not to enable EN-DC in the LTE cell on the right, due to the poor NR coverage.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 16 (179)
 5G Mobility and Traffic Management Guideline

Figure 4-5 – Example of 5G Icon Configuration in an NSA Network

It is up to the network operator, UE vendor and possibly regulators to determine whether

the GSMA recommendations are followed or not. Additionally, a vendor could choose to
use different icons for different states, for example a hollow icon to indicate 5G is
potentially available and a solid icon to indicate 5G is being used, or different icons such as
5G and 5G+ for further differentiation.

The upper layer indication can be set either manually or automatically. If

EUtranCellFDD/TDD.upperLayerAutoConfEnabled = true, then it is set
automatically by the feature Basic Intelligent Connectivity as described in Section 9.2.1.4,
otherwise it is set manually using the parameters shown in Table 4-4.
Table 4-4 - Parameters for Controlling the upperLayerIndication-r15
MO Parameter Description
EUtranCellFDD/ primaryUpperLayerInd Indicates whether
EUtranCellTDD upperLayerIndication-r15 is set for the
PLMN identified by
ENodeBFunction.eNodeBPlmnId
(ON/OFF)
EUtranCellFDD/ additionalUpperLayerIndList Indicates whether
EUtranCellTDD upperLayerIndication-r15 is set for any
additional PLMN identities that may be
broadcast in SIB1.
(ON/OFF)

Note: For certain UE implementations, NAS signaling (containing NR restriction) can

prevent an EN-DC capable UE from displaying any 5G icon even if upperLayerIndication-
rel15 in SIB2 is correctly received in the UE.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 17 (179)
 5G Mobility and Traffic Management Guideline

4.6 Measurement Quantities

To assist with managing mobility, 5G UEs can make measurements of both the NR and
LTE radio environments. In idle mode, UEs use the results of the measurements to make
mobility decisions autonomously. In connected mode, UEs send the results to the network,
which makes the decisions.

The LTE measurements are unchanged from legacy LTE and are described in the LTE
Mobility and Traffic Management Guideline.

The NR measurements are standardized in 3GPP TS 38.215. Six radio signal

measurement quantities are defined. Three are based on measurements of the secondary
synchronization signal (which is part of the SSB block) and three are based on the CSI
reference signal (CSI-RS). The measurement quantities are called SS_RSRP, SS_RSRQ,
SS-SINR, CSI-RSRP, CSI-RSRQ and CSI-SINR.

In the current software release, the NR measurement quantities that are used for triggering
mobility decisions are SS_RSRP and SS_RSRQ. These are explained below.

4.6.1 SS_RSRP: Synchronization Signal Reference Signal Received Power

The NR downlink is divided into a time-frequency grid of slots and resource blocks, which
are further divided into a time-frequency grid of resource elements. A pre-defined subset of
these resource elements is used to carry the secondary synchronization signal.

SS_RSRP is defined as the linear average over the power contributions (in [W]) of the
resource elements that carry secondary synchronization signals. In other words, SS_RSRP
is the average received power of a single reference signal resource element. SS_RSRP is
measured by the UE and is reported to the network via measurement reports when
required.

SS_RSRP indicates signal strength but does not strongly indicate signal quality. A user
close to multiple cells may have strong SS_RSRP but a poor-quality signal (low downlink
SS-SINR) due to interference, potentially leading to a degraded experience. SS_RSRP has
a reporting range from -156 dBm to -31 dBm. This is greater than the range in LTE, to
accommodate additional variations due to beamforming.

SS_RSRP is similar to RSRP in LTE and is used for similar purposes. However, the values
are not necessarily directly comparable, due to differences in the link budgets and power
configurations of the two systems, and the use of beamforming.

4.6.2 SS_RSRQ: Synchronization Signal Reference Signal Received Quality

SS_RSRQ measures the ratio of SS_RSRP to all downlink received power. It is calculated
as (N x SS_RSRP) / NR carrier RSSI, where N is the number of resource blocks in the NR
carrier RSSI measurement bandwidth. The measurements of SS_RSRP and RSSI are
made over the same set of resource blocks in the frequency domain. SS_RSRQ has a
reporting range from -43 dB to +20 dB.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 18 (179)
 5G Mobility and Traffic Management Guideline

SS_RSRQ is intended to represent the downlink signal quality. However, since the
denominator (RSSI) includes power from all sources, SS_RSRQ is impacted not only by
other cell interference, external interference and thermal noise (which all degrade signal
quality) but also by the traffic load on the serving cell (which does not degrade signal
quality). Furthermore, when beamforming is used, the impact of traffic load on measured
RSSI varies depending on whether the measuring UE is covered by any transmitting
beams or not. SS_RSRQ also depends on the configuration of SSB and the number of
symbols and time over which RSSI is measured, see 3GPP 36.214 and 38.215. These
impacts make it difficult to determine suitable triggering levels for SS_RSRQ and it is
therefore not recommended as a triggering quantity.

4.7 Connected Mode Measurements

Connected mode measurements are configured in the UE via dedicated RRC messages,
which instruct the UE to set up, evaluate and report a measurement event. For SA, the
measurements are configured by the gNodeB. For NSA, some measurements are
configured by the eNodeB and some by the gNodeB. When an event is triggered, the UE
sends a measurement report to the network which can then trigger a mobility action.

Measurements on NR cells are defined in 3GPP TS 36.331 and TS 38.331, and contain
several elements in common: a triggering quantity, a filtering coefficient, a threshold value,
a hysteresis and a timer before triggering.

UEs in connected mode are required to perform any configured measurements when the
RSRP drops below sMeasure. There are two sMeasure parameters, one configured in
the eNodeB and the other in the gNodeB. See Section 10.2.1 for further information.

4.7.1 Triggering Quantity

In the current software release, the triggering quantity in NR can be either SS_RSRP or
SS_RSRQ:

• SS_RSRP is the default and is recommended for events A2 (to detect poor NR
coverage), B1 (to detect NR coverage when the UE is on LTE) and A3 (for NR intra-
frequency mobility).

• SS_RSRQ is not recommended as a triggering quantity, for the reasons detailed in

Section 4.6.2.

In the gNodeB the triggering quantity for measurements on NR frequencies is set with the
following parameters:

• (gNB)ReportConfigA2.triggerQuantity

• (gNB)ReportConfigA3.triggerQuantity

The possible values for these parameters are: 0(RSRP) for SS_RSRP or 1(RSRQ) for
SS_RSRQ.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 19 (179)
 5G Mobility and Traffic Management Guideline

In the eNodeB the triggering quantity for measurements on NR frequencies is set with the
following parameters:

• (eNB)ReportConfigB1GUtra.triggerQuantityB1

• (eNB)ReportConfigB1NR.triggerQuantityB1NR

The possible values for these parameters are: 0(SS_RSRP) for SS_RSRP or
1(SS_RSRQ) for SS_RSRQ.

4.7.2 Filter Coefficients

All connected mode UE measurements are filtered at both Layer 1 and Layer 3 by the UE
before event evaluation and reporting.

The Layer 1 filter is UE implementation specific.

The Layer 3 filter is a simple exponential filter with a factor of 1/(2k/4), where k is the filter
coefficient as defined in 3GPP 36.331 and 38.331:

• A value of 0 indicates that the measured result is only Layer 1 filtered

• A value of 4 (default) corresponds to a weighting of 1/(24/4) = 0.5, that is, the next
filtered value is the average of the new measurement and the last filtered value

• A value of 8 corresponds to a weighting of 0.25, that is, the next filtered value is the
weighted sum of 25% of the new measurement and 75% of the last filtered value

The value of k is set as follows:

• For Event B1, a fixed value of k = 4 is used for both SS_RSRP and SS_RSRQ

• For NR Events A2 and A3, the value of k is configurable in the gNodeB, using the
following parameters:

– UeMeasControl.filterCoefficientNrRsrp for SS_RSRP

– UeMeasControl.filterCoefficientNrRsrq for SS_RSRQ

Larger values of k make the filter less responsive, reducing the impact of momentary fading
at the cost of a longer time-to-trigger the event.

4.7.3 Threshold, Hysteresis and Time-To-Trigger

Figure 4-6 provides a generic example to explain how the event threshold, hysteresis and
time-to-trigger together control event triggering.

In this example, the event is triggered by a rising signal, for example Event B1 (IRAT
Neighbor Becomes Better than Threshold) which could be either SS_RSRP or SS_RSRQ.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 20 (179)
 5G Mobility and Traffic Management Guideline

Figure 4-6 – Event Triggering Process

Notes for Figure 4-6:

• The undulating line represents the signal after filtering has been applied.

• The threshold and the hysteresis combine to determine the “entering level” and the
“leaving level”.

• The “entering level” in this example is equal to the threshold plus the hysteresis. When
the signal is above the entering level continually for timeToTrigger the event is
“entered” and the first measurement report is triggered (sent by the UE to the eNodeB).

• Once the event has been entered, the report is re-sent every reportInterval, up to a
total of reportAmount times, or until the event is “left”.

• The “leaving level” in this example is equal to the threshold minus the hysteresis. When
the signal is below this level continually for timeToTrigger the event is “left”. This can
trigger a reportOnLeave to be sent, but this is not normally configured. No further
reports are sent once the event has been left.

• The entering level and the timeToTrigger together control when the event is first sent. If
the threshold and hysteresis are changed but the entering level remains the same, then
the first report is sent at the same point.

• A shorter timeToTrigger results in the event being entered more easily, and more
reports being sent. timeToTrigger is typically set between 40 ms and 640 ms
depending on the event.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 21 (179)
 5G Mobility and Traffic Management Guideline

4.7.4 Measurement Gaps

Measurement gaps are periods of time when UE reception, and possibly transmission, are
suspended to allow the UE to perform a measurement on a frequency which is not being
used by the UE.

For the intra-frequency Event A3 on NR, UEs do not require measurement gaps.

For Event B1 on NR, measurement gaps depend on the 3GPP frequency range (defined in
Section 4.2.1). Measurement gaps are mandatory for FR1, and for FR2 if the UE requires
it, as indicated in the capability information. However, some early UEs do not require
measurement gaps.

4.7.5 Measurement Events

This section describes the event-based measurements used by UEs to evaluate NR

coverage, for both SA and NSA. The LTE measurements are described the in the LTE
Mobility and Traffic Management Guideline.

Note that the UE capability for simultaneous measurements is limited; see 3GPP TS
36.133 Section 8.2 and 3GPP TS 38.133 Section 9.1.4.

4.7.5.1 Event A1: Serving Becomes Better than Threshold

Event A1, as shown in Figure 4-7, is used to detect good NR SCell coverage for DL Carrier
Aggregation SCell for both SA and NSA in FR1. It is measured on the SCell and triggers
SCell activation (MAC layer). See Section 10.2.8 for the trigger level formulas.

Figure 4-7 – Event A1 – Serving Becomes Better than Threshold

4.7.5.2 Event A2: Serving Becomes Worse than Threshold

Event A2, as shown in Figure 4-8, is used to detect poor NR cell coverage for SA, NSA and
downlink carrier aggregation.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 22 (179)
 5G Mobility and Traffic Management Guideline

Figure 4-8 – Event A2 – Serving Becomes Worse than Threshold

For SA, the A2 event is measured on the PCell and triggers the NR coverage-triggered
release-with-redirect to LTE procedure. See Section 7.2.3 for the procedure and Section
10.2.5 for the trigger level formulas.

For NSA, the A2 event is measured on the PSCell and triggers the NR coverage-triggered
secondary node release procedure. See Section 6.3.3 for the procedure and Section
10.2.7 for the trigger level formulas.

For DL Carrier Aggregation (CA) in Frequency Range 1 (FR1), the A2 event is measured
on the SCell and triggers SCell deactivation (MAC layer). See Section 10.2.8 for the trigger
level formulas. It is not used for CA in FR2.

4.7.5.3 Event A3: Neighbor NR Cell Becomes Offset Better than Serving Cell

Event A3, shown in Figure 4-9, is used to detect when a neighboring intra-frequency NR
cell becomes offset better than the serving cell. This measurement event is configured
using the ReportConfigA3 MO in the gNodeB.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 23 (179)
 5G Mobility and Traffic Management Guideline

Figure 4-9 – Event A3 – Neighbor Becomes Offset Better than Serving Cell

This event is used for both SA and NSA mobility:

• SA: when the event is triggered the UE sends a measurement report to the gNodeB,
which triggers the intra-frequency handover procedure described in Section 7.2.2.

• NSA: the UE sends a measurement report via the eNodeB to the gNodeB, which
triggers the intra-frequency PSCell change procedure described in Section 6.3.1.

The full formula (showing all parameters involved with this event) is provided in Section
10.2.4.

4.7.5.4 Event A6: Neighbor Becomes Offset Better than SCell

Event A6, shown in Figure 4-10, is used for DL Carrier Aggregation for both SA and NSA to
trigger a change of SCell in FR1. It is similar to event A3, but whereas event A3 is used for
the primary cell, event A6 is used to find better SCells within a given frequency layer. See
Section 10.2.8 for the trigger level formulas.

Figure 4-10 – Event A6 – Neighbor Becomes Offset Better than SCell

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 24 (179)
 5G Mobility and Traffic Management Guideline

4.7.5.5 Event B1: IRAT Neighbor Becomes Better than Threshold

Event B1, shown in Figure 4-11, is used to detect acceptable NR coverage.

Figure 4-11 – Event B1 – IRAT Neighbor Becomes Better than Threshold

Upon satisfying Event B1 the UE sends a measurement report to the eNodeB. It is used for
two purposes in the Ericsson 5G solution:

• SN Addition for NSA and EN-DC Triggered Handover:

The ReportConfigB1GUtra MO in the eNodeB is used to configure Event B1 for
detecting acceptable NR coverage before an EN-DC bearer is set up (NR NSA). See
Section 10.2.2 for more information on the parameters involved with this event.

• Release-with-redirect from LTE to NR SA:

The ReportConfigB1NR MO in the eNodeB is used to configure Event B1 for
detecting acceptable NR coverage before a release-with-redirect to SA is triggered for
a NR SA capable UE. See Section 10.2.3 for more information involved with this event.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 25 (179)
 5G Mobility and Traffic Management Guideline

5 Connectivity and Bearers – NSA

This section describes how UEs connect to the network in Ericsson’s 5G NSA solution,
with a strong emphasis on the underlying radio bearers and how they are managed. The
concepts presented here are used in extensively in Section 6, which describes mobility and
connectivity procedures and strategies, and Section 8, which describes anchor carrier
management strategies.

5.1 Radio Bearer Types – NSA

The UE connects to the radio network using two different types of radio bearer:

• Signaling Radio Bearer (SRB): The SRB transports Layer 3 signaling to and from the
UE in connected mode. In NSA, the SRB is carried over the LTE RAT (the Master RAT)
via the eNodeB.

• Data Radio Bearer (DRB): A DRB transports Layer 3 user plane data to and from the
UE. In connected mode the UE has one or more DRBs.

In NSA, DRBs are described by two characteristics:

• The node which terminates the S1-U interface from the core:

– Master Node (MN) or

– Secondary Node (SN)

• The cell groups which provide the resources for the bearer over the air interface:

– Master Cell Group (MCG) or

– Secondary Cell Group (SCG)

– Split (both MCG and SCG provide resources)

The MCG has one primary cell (PCell) and, if LTE carrier aggregation is configured (see
Section 5.4), one or more secondary cells (SCells).

The SCG also has one primary cell (PSCell) and, if NR carrier aggregation is configured
(see Section 5.4), one or more secondary cells.

In the NSA solution, there are three types of DRB:

• MN Terminated MCG DRB

• SN Terminated MCG DRB

• SN Terminated Split DRB

The SRB and the three DRB types are shown in Figure 5-1.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 26 (179)
 5G Mobility and Traffic Management Guideline

Figure 5-1 – Bearer Types in an EN-DC Capable Network

Which DRBs a UE can use depends on its capability:

• UEs which are not EN-DC capable (legacy LTE UEs) can use one or more MN
Terminated MCG DRBs only.

• EN-DC capable UEs can use one or more MN terminated DRBs, or one or more SN
terminated DRBs, or combinations of the two. However, the network does not configure
the UE simultaneously with two different types of SN Terminated DRB (that is an SN
Terminated Split DRB and an SN Terminated MCG DRB).

5.2 Radio Bearer Transitions – NSA

In response to mobility or service triggers, the network sets up and releases bearers and
initiates transitions between them. The possible transitions between the bearer types for
bearers that are allowed to be split bearers are shown in Figure 5-2. In addition, the UE
can be released to idle mode from any bearer state.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 27 (179)
 5G Mobility and Traffic Management Guideline

Figure 5-2 - Bearer Type Transitions for EN-DC

Notes for Figure 5-2:

1 Initial context setup, incoming handover and RRC re-establishment result in the setup
of an MN Terminated MCG DRB.
2 SN addition involves reconfiguring an MN terminated MCG DRB into an SN terminated
split DRB when the preconditions for EN-DC are fulfilled. The SN addition is typically
either configuration-based or measurement-based, but may not be in the case of LTE
intra-cell handover. If it is measurement-based, then the UE is configured with an
Event B1 measurement to detect NR coverage and SN addition occurs when an Event
B1 report is received from the UE. Event B1 is further described in Section 4.7.5.5.
3 SCG release occurs when a bearer is set up that prevents other bearers being
configured as SN Terminated Split DRBs, for example at VoLTE call setup. SCG
resources for all SN Terminated split DRBs are released but the PDCP context is kept.
4 SCG addition is triggered by reception of a B1 measurement. The B1 measurement is
started, for example, when a VoLTE bearer (which prevents other bearers being
configured as SN terminated Split DRBs) is released. All SN Terminated MCG DRBs
make this transition at the same time.
5 There are two SN release transitions, both labelled with 5. The transition from the SN
Terminated Split DRB state is triggered by NR radio link failure, LTE mobility events or
RRC connection re-establishment. The transition from the SN Terminated MCG Bearer
state is triggered only by LTE mobility or RRC connection re-establishment events (as

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 28 (179)
 5G Mobility and Traffic Management Guideline

there are no SCG resources in this case). All SN Terminated DRBs make this
transition at the same time.

If the UE has multiple bearers, then all bearers do not necessarily make the same
transitions at the same time; more details are provided in Section 6.

5.3 Split Bearer User Plane Functions – NSA

This section describes the functions which control the flow of user data over an SN
Terminated Split Bearer.

A split bearer has two sets of radio resources:

• Master Cell Group (MCG) resources in the Master Node (eNodeB)

• Secondary Cell Group (SCG) resources in the Secondary Node (gNodeB)

These two sets of resources are served by a common PDCP entity located in the
Secondary Node, as shown in Figure 5-3.

Figure 5-3 - SN Terminated Split Bearer Resources

The PDCP entity controls the flow of user data over the MCG and SCG resources using
the following features and functions:

• Uplink / Downlink Decoupling

The feature Uplink-Downlink Decoupling enables uplink and downlink user data
transmissions to be sent independently over LTE or NR. For example, the downlink can
use NR while the uplink uses LTE.

• Downlink User Plane Switching

This function enables fast switching of downlink user plane data between MCG and
SCG resources (effectively between LTE and NR) in response to varying NR radio
quality.

• Uplink User Plane Switching

This function enables fast switching of uplink user plane data between MCG and SCG
resources (effectively between LTE and NR) in response to varying NR radio quality.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 29 (179)
 5G Mobility and Traffic Management Guideline

• Downlink User Plane Aggregation

This function enables simultaneous use of both MCG and SCG resources for downlink
user data transmission when required by data flow and allowed by NR radio quality.

• Uplink User Plane Aggregation

This function enables simultaneous use of both MCG and SCG resources for uplink
user data transmission when required by data flow.

• Flow Control
This function controls the flow of data over MCG and SCG resources to manage the
latencies and minimize packet reordering during aggregation.

These functions exist within the context of a split bearer, until SN or SCG release occurs,
as described in Section 6.2.5.

In addition to the downlink and uplink user plane aggregation described above, the MCG
and SCG can each support Downlink Carrier Aggregation on the cells within their
respective cell groups, as described in Section 5.4, and Uplink Carrier Aggregation as
described in Section 5.5.

The above functions are described in more detail in the following sections.

5.3.1 Uplink-Downlink Decoupling

The feature Uplink-Downlink Decoupling enables uplink and downlink user data
transmissions to be sent independently over LTE or NR. For example, the downlink can
use NR while the uplink uses LTE. This improves NR coverage by simultaneously taking
advantage of the high peak data rate and low-latency of the NR downlink, and the strong
coverage of the low-band LTE uplink.

Figure 5-4 – Coverage Extension Due to EN-DC Uplink-Downlink Decoupling

Note that whenever user data is sent on the NR downlink, the associated uplink signaling
(for example the Layer 1 and Layer 2 HARQ feedback and RLC Status Reports) is carried
on the NR uplink. This means that simultaneous uplink transmission on NR and LTE can
occur regardless of whether NR or LTE is used for uplink user data.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 30 (179)
 5G Mobility and Traffic Management Guideline

5.3.2 Downlink User Plane Switching

Downlink user plane switching allows the downlink user plane to be switched dynamically
between MCG and SCG resources based on the estimated SINR of the NR downlink. The
SINR is estimated using CQI feedback from the UE.

Downlink user plane switching is illustrated in Figure 5-5.

Figure 5-5 – Downlink User Plane Switching

Notes for Figure 5-5:

1 Initially, when an SN Terminated Split Bearer is established (for example due to
reception of a B1 measurement report), the downlink user plane uses SCG (NR)
resources. The SCG resources continue to be used while the NR DL SINR remains
acceptable.
2 When the NR DL SINR falls below NRCellDU.endcDlNrLowQualThresh, an
immediate switch to the MCG (LTE) resources is triggered. This switch is also
triggered if CQI reports are not received successfully from the UE. Any unsent data is
forwarded to the eNodeB for transmission.
3 Even if the NR DL SINR becomes acceptable again (above
NRCellDU.endcDlNrLowQualThresh + NRCellDU.endcDlNrQualHyst), a
switch back to the SCG (NR) resources cannot occur until the prohibit timer expires.
4 When the GNBCUUPFunction.endcDlNrRetProhibTimer expires, and if the
quality remains acceptable, a switch back to the SCG (NR) resources is triggered. Any
unsent data is forwarded to the gNodeB for transmission.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 31 (179)
 5G Mobility and Traffic Management Guideline

If the UE has more than one SN Terminated Split Bearer, all are switched at the same time
and use the same downlink resources.

A downlink user data flow at the PDCP layer requires an uplink signaling flow at Layer 1
and Layer 2, for example HARQ and RLC Status Reports. This uplink signaling is carried
on the same cell group as the downlink data flow:

• The Layer 1 and Layer 2 signaling associated with the SCG downlink user plane is
always carried on the SCG uplink.

• The Layer 1 and Layer 2 signaling associated with the MCG downlink user plane is
always carried on the MCG uplink.

5.3.3 Uplink User Plane Switching

Uplink user plane switching allows the uplink user plane to be switched dynamically
between MCG and SCG resources based on the NR uplink Layer 1 SINR, measured by
the gNodeB. It is enabled at cell level with the parameter
NRCellDU.endcUlLegSwitchEnabled.

The uplink user plane switch involves reconfiguration of the UE via RRC, unlike the
downlink user plane switch which does not require the UE to be reconfigured.

Uplink user plane switching is illustrated in Figure 5-6.

Figure 5-6 – Uplink User Plane Switching

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 32 (179)
 5G Mobility and Traffic Management Guideline

Notes for Figure 5-6:

1 The resource initially used for the uplink is configured in the gNodeB with the
parameter QciProfileEndcConfigExt.initialUplinkConf (either MCG or
SCG). This is signaled to the UE via RRC at SN addition. In this example the
parameter is set to SCG. If uplink user plane switching is disabled, the initial selection
is kept statically throughout the lifetime of the SN Terminated Split Bearer.
2 When the estimated NR UL SINR falls below NRCellDU.endcUlNrLowQualThresh,
an RRC reconfiguration to MCG (LTE) resources is triggered. The estimated SINR is
normalized to the maximum achievable SINR; that which would be measured if the UE
were using only a single resource block. This normalization must be considered when
setting endcUlNrLowQualThresh. For example, if the minimum requirement for
acceptable NR performance is N resource blocks with a SINR of X dB on each of those
resource blocks, then endcUlNrLowQualThresh should be set to X + 10 * log10(N).
In other words, the threshold should be increased by 3 dB for each doubling of the
number of required resource blocks.
3 Even if the NR UL SINR becomes acceptable again (above
NRCellDU.endcUlNrLowQualThresh + NRCellDU.endcUlNrQualHyst), a
switch back to SCG (NR) resources cannot occur until the prohibit timer expires.
4 When the GNBCUUPFunction.endcUlNrRetProhibTimer expires, and the quality
remains acceptable, a switch back to SCG (NR) resources is triggered.

If the UE has more than one SN Terminated Split Bearer, all are switched at the same time
and use the same uplink resources.

An uplink user data flow at the PDCP layer requires a downlink signaling flow at Layer 1
and Layer 2, for example HARQ and RLC status reports. This downlink signaling is carried
on the same cell group as the uplink data flow:

• The Layer 1 and Layer 2 signaling associated with the SCG uplink user plane is always
carried on the SCG downlink.

• The Layer 1 and Layer 2 signaling associated with the MCG uplink user plane is always
carried on the MCG downlink.

5.3.4 Downlink User Plane Aggregation

The licensed feature LTE-NR Downlink Aggregation (FAJ 121 4912) enables transmission
of downlink user plane data simultaneously on both the MCG and SCG resources of an SN
Terminated Split Bearer. Different packets are sent on the two cell groups. The feature
improves the end user throughput.

Figure 5-7 illustrates the transitions involved with LTE-NR Downlink User Plane
Aggregation, and how this function interacts with downlink user plane switching (described
previously in Section 5.3.2).

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 33 (179)
 5G Mobility and Traffic Management Guideline

Figure 5-7 – Downlink User Plane Aggregation and Switching for a Split Bearer

Notes for Figure 5-7:

1 Good NR DL SINR (derived from the CQI measured on the Primary SCell) triggers a
switch from MCG to SCG resources (see Section 5.3.2).
2 Poor NR DL SINR or a lack of CQI reports triggers a switch to MCG resources only
(see Section 5.3.2).
3 DL aggregation is triggered for a SN Terminated Split Bearer when the NR DL SINR is
good enough for the SCG to be used (see Section 5.3.2) and if the PDCP packets are
waiting in the PDCP buffer for longer than GNBCUUPFunction.dcDlAggActTime.

4 Downlink aggregation is stopped and returned to downlink using only SCG resources if
the PDCP buffer is emptied (all packets sent and acknowledged) and kept empty for a
time of GNBCUUPFunction.dcDlAggExpiryTimer.

5 Downlink aggregation is stopped and returned to downlink using only MCG resources if
NR DL SINR is poor or there is a lack of CQI reports.

In addition to the transitions shown, an NR radio link failure may occur in any of the three
states, leading to SN Release and transition to an MN Terminated MCG Bearer.

The feature LTE-NR Downlink Aggregation is enabled by setting the

attribute featureState to ACTIVATED in the FeatureState=CXC4012273 MO
instance.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 34 (179)
 5G Mobility and Traffic Management Guideline

5.3.5 Uplink User Plane Aggregation

The licensed feature LTE-NR Uplink Aggregation (FAJ 121 5091) enables transmission of
uplink user plane data (PDCP layer) simultaneously on both the MCG and SCG resources
of an SN Terminated Split Bearer. The feature improves the end user throughput.

Uplink user plane aggregation and switching work together as shown in Figure 5-8.

• UL User Plane Switching is described in Section 5.3.3, and determines whether the
primary uplink path is SGC or MCG depending on the SINR. The decision to change
the primary path is made by the eNodeB and signaled to the UE via RRC.

• UL User Plane Aggregation determines whether the UE sends uplink data on only the
primary cell group or on both cell groups. This decision is made by the UE, depending
on the amount of data in the UL PDCP buffer.

Figure 5-8 – Uplink User Plane Aggregation and Switching for a Split Bearer

The threshold for using uplink aggregation is set with the parameter
GNBCUCPFunction.QciProfileEndcConfigExt.ulDataSplitThreshold. When
the amount of data in the UE uplink PDCP buffer equals or exceeds this threshold, then the
UE splits the uplink data and sends uplink PDCP PDUs on both the MCG and the SCG
paths. Otherwise, the UE sends the data only on the primary path, as determined by uplink
user plane switching.

If ulDataSplitThreshold is set to 0, the uplink data split is always active for capable
UEs. If set to -1, the split is not allowed. If left empty, a value of 3200 bytes is used.

The feature LTE-NR Uplink Aggregation is enabled by setting the

attribute featureState to ACTIVATED in the FeatureState=CXC4012375 MO
instance.

To use uplink user plane aggregation, the UE must be capable of uplink EN-DC
aggregation (3GPP IE splitDRB-withUL-Both-MCG-SCG).

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 35 (179)
 5G Mobility and Traffic Management Guideline

5.3.6 Flow Control

Flow control manages the flow of downlink PDCP packets over the MCG (LTE) and SCG
(NR) user plane paths for split bearers. Its objective is to make the PDCP packets arrive in
the correct order at the UE, even though they are delivered over two different paths. This
minimizes the need for PDCP packet reordering in the UE during downlink user plane
switching and aggregation.

Flow control is executed in the common PDCP entity, which is located in the gNodeB for a
split bearer. It measures the PDCP packet latency on the MCG and SCG user plane paths
and compares the measured values with the target values configured in
GNBCUUPFunction.dlPdcpSpsTargetTimeLTE (for the MCG) and
GNBCUUPFunction.dlPdcpSpsTargetTimeNR (for the SCG). The recommended value
for both of these parameters is 25 ms.

Based on the result of the comparison, flow control takes the following actions
(independently on the MCG and SCG paths):

• If the measured latency does not exceed the target value, then flow control takes no
action; it sends packets received from S1-U down to the RLC layer immediately.

• If the measured latency exceeds the target, then flow control limits the flow rate
towards the relevant RLC entity and the remaining packets are buffered to be sent
later. This eventually reduces the measured latency till it is once again below the target
value.

By taking these actions, flow control minimizes both the need for packet forwarding at
downlink user plane switching and packet reordering in the UE.

5.4 Downlink Carrier Aggregation – NSA

In addition to the Downlink User Plane Aggregation described in Section 5.3.4, the MCG
and SCG can each support Downlink Carrier Aggregation on the cells within their
respective cell groups.

Downlink carrier aggregation is implemented on the MAC and Physical Layer (L1). It is
supported for all three bearer types:

• MN Terminated MCG Bearer

• SN Terminated Split Bearer

• SN Terminated MCG Bearer

DL carrier aggregation (on the MAC and Physical Layer) can be used in combination with
downlink and uplink user plane aggregation (on the PDCP Layer), as the two functions are
independent.

In the current release, the following DL carrier aggregation Component Carrier (CC)
configurations are supported for SN Terminated Split Bearers:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 36 (179)
 5G Mobility and Traffic Management Guideline

Table 5-1 – Downlink Aggregation Support

NR Band LTE Carriers NR Carriers
Low-band (FDD) 6 CC 1 CC
Mid-band (TDD) 6 CC 1 CC
High-band (TDD) 6 CC 8 CC*

* Simultaneous use of the optional features NR 8CC DL Carrier Aggregation

High-Band and LTE-NR Downlink Aggregation adds additional load to the baseband
hardware and may not provide the maximum aggregated peak rate over the MCG and
SCG resources. Refer to the CPI document LTE-NR Downlink Aggregation for more
information.

Note that inter-band carrier aggregation (between frequency bands) within NR is not
supported in the current release.

Figure 5-9 illustrates the aggregation functionality available on high-band NR. For LTE DL
carrier aggregation, the RLC entity in the MN interacts with multiple HARQ-entities on the
MAC layer, one per CC. The MAC layer is also responsible for scheduling and multiplexing
of all CCs. Similar handling applies to NR DL carrier aggregation.

Figure 5-9 – Downlink Carrier Aggregation (High-Band Example)

For Downlink carrier aggregation on LTE, the MCG consists of one primary cell (PCell) and
one or more secondary cells (SCells), each on a different frequency. The SCell activation
and deactivation thresholds can be controlled separately for EN-DC connections, using the
following parameters in the CarrierAggregationFunction MO:
dcSCellActDeactDataThres, dcSCellActDeactDataThresHyst and
dcSCellDeactDelayTimer.

For Downlink carrier aggregation on NR, the SCG consists of one primary secondary cell
(PSCell) and one or more secondary cells, each on a different frequency.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 37 (179)
 5G Mobility and Traffic Management Guideline

5.5 Uplink Carrier Aggregation – NSA

In addition to the Uplink User Plane Aggregation described in Section 5.3.3, Uplink Carrier
Aggregation within the SCG cells is also supported.

Uplink Carrier Aggregation enables aggregation of 50+50 MHz or 100+100 MHz in

contiguous spectrum only.

Uplink Carrier Aggregation is implemented on the MAC and Physical Layer (L1).
It can be used in combination with downlink and uplink user plane aggregation (on the
PDCP Layer), as the two functions are independent.

When there is data demand that can benefit from additional bandwidth, the second uplink
carrier can be activated by the gNodeB as secondary carrier (SCell) to the UE. Only user
data is transferred on the secondary carrier.

In the current release, the following UL carrier aggregation Component Carrier (CC)
configurations are supported for NSA for SN Terminated Split Bearers:

Table 5-2 – Uplink Aggregation Support

NR Band LTE carriers NR carriers*
Low-band (FDD) 1 CC 1 CC
Mid-band (TDD) 1 CC 1 CC
High-band (TDD) 1 CC 2 CC

* The aggregated NR carriers must be contiguous and within the same frequency band.

Note that inter-band carrier aggregation (between frequency bands) within NR is not
supported in the current release.

Figure 5-10 illustrates the aggregation functionality available on high-band NR. For NR UL
carrier aggregation, the RLC entity in the MN interacts with multiple HARQ-entities on the
MAC layer, one per CC. The MAC layer is also responsible for scheduling and multiplexing
of all CCs.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 38 (179)
 5G Mobility and Traffic Management Guideline

Figure 5-10 – Uplink Carrier Aggregation (High-Band Example)

For Uplink Carrier Aggregation on NR, the SCG consists of one Primary Secondary Cell
(PSCell) and one secondary cell, each on a different frequency within the same frequency
band.

UL Carrier Aggregation does not impact Uplink User Plane Switching behavior, since user
plane switching considers only the PSCell SINR, not the SCell.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 39 (179)
 5G Mobility and Traffic Management Guideline

6 Mobility and Connectivity Procedures – NSA

This section describes NSA mobility and connectivity procedures. The procedures are
triggered by one of the following changes:

• Service activity (for example establishing or releasing a data or voice bearer)

• Changes in NR coverage (for example leading to intra-frequency mobility or radio link

failure)

• Changes in LTE coverage (for example leading to intra-frequency, inter-frequency or

inter-RAT mobility, or radio link failure)

• Load management by the eNodeB (for example leading to inter-frequency handover)

In some cases, the procedure depends on which radio bearers are in place when the
procedure is triggered.

Figure 6-1 shows an example of a series of NSA procedures for a UE moving through
network with a single LTE layer and a single NR layer. The first procedure (on the left) is
triggered by the establishment of a data bearer. Subsequent procedures are triggered by
changes in NR and LTE coverage as the UE moves from left to right. The indicated
sections provide more detail on each procedure. This simple example shows only a small
subset of the procedures covered in this section; for example, it does not show EN-DC
triggered handover, which can be used to move the UE between LTE layers to provide
better access to EN-DC.

Figure 6-1 - Example of NSA Mobility Procedures

The following procedure descriptions assume that the default DRB is mapped to QCI9. If
not, then replace all references to QCI9 with the appropriate QCI.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 40 (179)
 5G Mobility and Traffic Management Guideline

6.1 Idle Mode Procedures – NSA

In NSA, UEs in idle mode camp on LTE and follow legacy LTE procedures, for example:

• PLMN Selection

• System information acquisition

• Cell selection and reselection (intra-frequency, inter-frequency and inter-RAT)

• Tracking area updates and paging

These procedures are described in the LTE Mobility and Traffic Management Guideline.

Those aspects of idle mode behavior which are new with NSA are described in the
following sections.

6.1.1 Upper Layer Indication – NSA

In NSA, UEs camp on LTE in idle mode, so they are not necessarily aware that the
selected cell is EN-DC capable or that NR coverage exists. The network can, however,
advise UEs that 5G service is potentially available by broadcasting an “upper layer
indication” in system information. This indication is used by UEs when deciding whether to
display a 5G status icon. The upper layer indication is described in detail in 4.5.

6.1.2 Idle Mode Reselection – NSA

In NSA, the default idle mode reselection behavior of EN-DC capable UEs mirrors that of
legacy LTE UEs (as described in the LTE Mobility and Traffic Management Guideline).

To obtain different idle mode reselection behavior for EN-DC capable UEs, two features
are available:

• Capability-Aware Idle Mode Control (CAIMC)

• Subscriber Triggered Mobility (STM)

Guidelines on how to use these two features for this purpose are provided in Section 8.2.1.

NR cells which support NSA only (not SA) do not provide idle mode services. UEs do not
attempt to camp on NSA only cells, for the following reasons:

• UEs which are capable of NSA only (not SA) do not reselect to the NR cells in idle
mode as they are not capable of doing so.

• UEs which are capable of SA and are camped on the LTE network in idle mode do not
reselect to the NR cells because the LTE cells are not configured to instruct UEs to
measure the NR frequencies for idle mode reselection.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 41 (179)
 5G Mobility and Traffic Management Guideline

• UEs which are capable of 5G standalone operation and enter the NR coverage area
without camping on LTE first, are prevented from attempting to camp on the NSA-only
cells because a Tracking Area Code (TAC) is not broadcast from these cells.

In a network which supports both NSA and SA, UEs in idle mode are permitted to reselect
to the NR cells and camp on them, as described in Section 7.1.

6.2 Data Bearer Setup and Release Procedures – NSA

This section describes the NSA procedures associated with establishing and releasing a
data bearer for transferring MBB data. VoLTE procedures are covered in Section 6.3.4.

6.2.1 UE EN-DC Capability Enquiry – NSA

Before the eNodeB can configure a UE with EN-DC, it needs to know which EN-DC band
combinations the UE supports. The eNodeB obtains this information from the MME if
available. If not, or if the information received from the MME does not cover the bands of
interest, then the eNodeB sends a UE capability enquiry (with rat-type: eutra-nr, nr) to the
UE.

This capability enquiry includes a list of NR bands (those defined within the
GUtranSyncSignalFrequency instances) and a list of LTE bands (those defined within
the EUtranFrequency instances). The UE responds with those band combinations that it
supports; it does not include band combinations containing bands which fall outside those
two lists.

For each GUtranSyncSignalFrequency, the eNodeB uses the following rules to

determine which NR bands to include in the capability enquiry:

• If GUtranSyncSignalFrequency.band = -1, then all of the bands defined in the

GUtranSyncSignalFrequency.bandList are included. The bandList is
generated automatically by the eNodeB and includes all of the possible overlapping
bands for the configured GUtranSyncSignalFrequency.arfcn.

• If GUtranSyncSignalFrequency.band is set to a value other than -1, then only this

band is included. The band can only be set to values which appear in the bandList.
This option can be used to limit the size of the capability enquiry message which is sent
to the UE.

The GUtranSyncSignalFrequency MO instances can be created either manually or

automatically by the system:

• Manual Creation of GUtranSyncSignalFrequency

When GUtranSyncSignalFrequency is created manually, the band attribute is
automatically set to -1. If desired, it can then be manually changed to one of the values
in the automatically created GUtranSyncSignalFrequency.bandList.

• Automatic Creation of GUtranSyncSignalFrequency

The system automatically creates GUtranSyncSignalFrequency MO instances
when an X2 link is set up between an eNodeB and a gNodeB. In this case the band

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 42 (179)
 5G Mobility and Traffic Management Guideline

attribute is automatically set to the first element in the ENDC-X2SetupResponse-

>Served NR Cell Information->FreqBandList, which is sent from the gNodeB to the
eNodeB during the X2 setup. This list is taken from NRCellDU.bandListManual if it
is configured, or from NRCellDU.bandList if the manual list is not configured. The
bandList is generated automatically by the gNodeB to include all possible
overlapping bands, in ascending order; so the first element in the bandList is always
the band with the lowest band number.

6.2.2 Data Bearer Setup from Idle Mode – NSA

Data bearer setup from idle mode typically occurs when there is MBB data to be sent on
either the uplink or the downlink.

When the UE enters connected mode, the following bearers are set up in the eNodeB and
the UE:

• An SRB for signaling.

• A Master Node Terminated Master Cell Group Data Radio Bearer (MN Terminated
MCG DRB). The QCI used for this bearer is operator configurable; a typical value is
QCI9.

• If the UE is registered in the IMS network then an IMS signaling DRB is also set up,
using QCI5. This is also an MN Terminated MCG DRB.

Figure 6-2 - Bearer Setup from Idle Mode for an IMS-registered UE

Data bearers are always initially set up as MN Terminated MCG Bearers. This type of
bearer provides LTE (MCG) resources only. NR (SGC) resources are added, if allowed, by
a subsequent SN addition procedure, which converts the bearer to an SN Terminated Split
Bearer, as described in Section 6.2.3.

6.2.3 Secondary Node Addition – NSA

Secondary Node (SN) addition is the procedure used to make NR resources available to a
UE that already has LTE resources. The procedure includes adding a Secondary Cell
Group (SCG) by converting one or more MN Terminated MCG Bearers into SN Terminated
Split Bearers, as shown in Figure 6-3 and Figure 6-4.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 43 (179)
 5G Mobility and Traffic Management Guideline

Figure 6-3 – Secondary Node Addition, Single Bearer Example

Figure 6-4 – Secondary Node Addition, Multiple Bearer Example

Secondary Node Addition is either configuration-based or measurement-based.

Configuration-based involves a blind setup to a pre-configured NR cell. Measurement-
based involves UE measurements to detect and report coverage from NR cells. Which is
used depends on whether the LTE cell is configured with a reference to an NR cell.

The NR cell reference is defined with the following attribute:

• EUtranCellFDD.extGUtranCellRef

• EUtranCellTDD.extGUtranCellRef

If extGUtranCellRef is defined, then SN addition is configuration-based in the following

cases:

• Initial context setup

• Incoming handover

Otherwise SN addition is always measurement-based.

Measurement-based SN addition uses the B1 measurement to detect coverage from NR

cells. Which frequency(s) are measured, and in what sequence is described in detail in
Section 9.2.1. The parameters controlling the B1 measurement triggering level are detailed
in Section 10.2.2.

6.2.3.1 Prerequisites for SN Addition

The following are prerequisites for SN addition:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 44 (179)
 5G Mobility and Traffic Management Guideline

1 The feature Basic Intelligent Connectivity is activated.

2 UE is EN-DC capable. UE capability IE en-DC-r15 is set to "supported".
3 The establishmentCause IE in the RRCConnectionRequest message is not set to
emergency.
4 The "NR Restriction in EPS as Secondary RAT" information element is not present in
the received Handover Restriction List.

Or the "NR Restriction in EPS as Secondary RAT" information element is present in

the received Handover Restriction List and the feature Enhanced NR Restriction is
activated. In this case, SN addition is allowed on FR1 (low-band and mid-band NR
carriers) but not on FR2 (high-band NR carrier).
5 At least one PLMN ID matches. The PLMNs for which EN-DC is supported must be
configured in the endcAllowedPlmnList per LTE cell. If endcAllowedPlmnList is
empty, then EN-DC is not allowed in that LTE cell. At setup, the PLMNs received from
the MME in the HRL are compared with the PLMN IDs configured in the
endcAllowedPlmnList of the serving LTE cell. If at least one PLMN ID matches,
EN-DC is allowed for the UE. If no HRL is received from the MME, EN-DC is allowed
for the UE if the ENodeBFunction.eNodeBPlmnId is listed in the
endcAllowedPlmnList.

6 An EN-DC band combination exists, meeting the following requirements:

– The EN-DC band combination is included in the MR-DC Capabilities signaled from
the UE to the eNodeB.

– The band combination has the same LTE band as the serving LTE cell.

– The band combination has the same NR band as one external NR cell defined and
hosted by a gNodeB with X2 connectivity.

– The UE indicates support for simultaneousRxTxInterBandENDC for the band

combination.
7 Criteria related to VoLTE and MCPTT. If the NR band in the selected band
combination is low or mid-band (FR1), then at least one of the following conditions is
met:

– None of the bearers established for this UE has serviceType = VoIP or PTT (for
example, VoLTE and Mission Critical Push to Talk)

– The UE indicates support for Dynamic Power Sharing for the selected EN-DC band
combination.

– The attribute endcSplitAllowedNonDynPwrShUe is true

8 Split is allowed for at least one bearer:

– For at least one bearer, ARP value of the bearer > meNodeBS1TermReqArpLev of
that same bearer. Refer to Section 6.3.4 for details.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 45 (179)
 5G Mobility and Traffic Management Guideline

9 No bearer prevents other bearers from being split. In other words, all bearers allow
other bearers to be split:

– For all bearers, ARP value of the bearer > splitNotAllowedUeArpLev of that
same bearer. Refer to Section 6.3.4 for details.
10 The UE uplink connection is not in TTI bundling mode.

In addition to these prerequisites, there is a mechanism to inhibit SN addition while a

mobile originated voice call (with the establishment cause set to mo-VoiceCall in the RRC
Connection Request) is being set up:

• If ENodeBFunction.endcSplitAllowedMoVoice = true then this mechanism

does not apply and SN addition is not impacted.

• If ENodeBFunction.endcSplitAllowedMoVoice = false then SN addition is

inhibited at Initial Context Setup and the guard timer
ENodeBFunction.tMoVoiceBearerEstSupervision is started. This guard timer
inhibits SN addition until it is stopped by one of the following events:

– The MO voice call is successfully setup, or

– The MO voice call establishment fails, or

– The guard timer expires (default 2 s)

• When this inhibition stops, the other prerequisites for SN addition (listed above) are
applied.

6.2.3.2 Preventing SN Addition for Subscribers Without a 5G Subscription

Operators may wish to prevent subscribers without a 5G subscription from accessing 5G

resources, even when the subscriber’s UE is 5G capable. This can be achieved with the
MME feature NR Access Control. This feature controls access to NR NSA at the subscriber
level.

To indicate whether a particular UE should be restricted from accessing NR NSA, NR

Access Control uses the “NR Restriction in EPS as Secondary RAT” Information Element
(IE). This IE is optionally included in the Handover Restriction List (HRL) which is sent from
the MME to the eNodeB over S1-AP, or between eNodeBs over X2-AP at handover. The
MME includes the IE and sets its value to NRrestrictedinEPSasSecondaryRAT if the HSS
restricts the UE from using NR NSA, or if the UE’s IMSI falls within an IMSI range which is
configured with a restriction in the MME itself. By default, the IE is not included and access
to NR NSA is not restricted.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 46 (179)
 5G Mobility and Traffic Management Guideline

Figure 6-5 – Handover Restriction List and NR Restriction

How the NR restriction IE is handled by the eNodeB depends on whether the eNodeB
feature Enhanced NR Restriction is active or not:

• Enhanced NR Restriction not active:

– UEs without the NR restriction IE can access all NR bands

– UEs with the NR restriction IE cannot access any NR bands

• Enhanced NR Restriction active:

– UEs without the NR restriction IE can access all NR bands

– UEs with the NR restriction IE can access EN-DC only on FR1 (low-band and mid-
band) NR carriers, not on FR2 (high-band) NR carriers.

The Enhanced NR Restriction feature therefore allows an operator who has both FR1 and
FR2 to reserve the FR2 spectrum for “prioritized” users only; namely users that do not have
the NR restriction. This feature is provided because 3GPP currently has no support for
band-level restriction of FR1 and FR2 resources.

6.2.3.3 Preventing SN Addition for Misbehaving UEs

Some EN-DC capable UEs may misbehave when configured with split bearers. To avoid
split bearers being configured for such UEs, the eNodeB feature Differentiated UE
Handling can be used. This feature allows the operator to treat UEs differently based on
the device type. The device type is communicated from the MME to the eNodeB via the
Masked International Mobile Equipment Identity Software Version (IMEISV).

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 47 (179)
 5G Mobility and Traffic Management Guideline

The IMEISV contains:

• The Type Allocation Code (TAC), used to identify the device type

• The masked serial number (SNR), masked to prevent identification of the end user

• Software version number (SVN), used to identify the software version in use by the UE

The Differentiated UE Handling feature provides a framework to control which IMEISVs can
use split bearer. Two approaches are possible per feature:

• Disallow split bearer for problematic devices only (blacklist), or

• Allow split bearer for certain devices only (whitelist)

Disallow Split Bearer for Problematic Devices Only (blacklist)

Use the following steps to disallow split bearer use on problematic devices only, and allow
it on all other capable devices:

• First, allow by default:

– Include the value 6 (FEATURE_NAME7, Basic Intelligent Connectivity) in the array

ImeisvTable.listOfFeaturesDefaultOn

• Second, disallow on problematic devices:

– Configure ImeisvProfile.listOfTacSvSns with the details of the problematic

devices.

– Include the value 6 (FEATURE_NAME7, Basic Intelligent Connectivity) in the array

ImeisvProfile.listOfFeaturesToTurnOff

Allow Split Bearer for Certain Devices Only (whitelist)

Use the following steps to allow split bearer only on certain devices, for example the
devices used in a trial:

• First, disallow by default:

– Include the value 6 (FEATURE_NAME7, Feature Basic Intelligent Connectivity) in

the array ImeisvTable.listOfFeaturesDefaultOff

• Second, allow on non-problematic devices:

– Configure ImeisvProfile.listOfTacSvSns with the details of the allowed

devices.

– Include the value 6 (FEATURE_NAME7, Feature Basic Intelligent Connectivity) in

the array ImeisvProfile.listOfFeaturesToTurnOn

Note that any one feature must only be included in either the blacklist or whitelist, not both.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 48 (179)
 5G Mobility and Traffic Management Guideline

6.2.3.4 Preventing SN Addition on ESS Carriers for Non-Compliant UEs

When a UE reports an ESS NR cell in the Event B1, before attempting SN addition the
gNodeB checks that the UE is capable of EN-DC on an ESS NR cell. To be capable, the
UE must support:

• Rate matching around LTE CRS

• DMRS symbol locations that do not collide with LTE CRS

If the UE does not support all these capabilities, the gNodeB rejects the SN addition
Request. If other (non-ESS) NR frequency(s) are configured, then the UE continues to
search for a suitable NR cell on those.

To prioritize non-ESS carriers over ESS carriers, set endcB1MeasPriority to a higher

value on the non-ESS carrier (which typically has a larger bandwidth). See section 9.2.1 for
more information on setting endcB1MeasPriority.

6.2.3.5 Secondary Node Addition Failure

The procedure to add a secondary node may fail. One cause of failure is an unsuccessful
random access on the NR cell. Random access for SN addition is supervised by the timer
GNBDUFunction.Rrc.t304, which is set in the gNodeB and signaled to the UE in the
RRC Reconfiguration message. If t304 expires before the random access is successfully
completed, then the UE reports a radio link failure (RLF) to the eNodeB.

If SN addition fails, the PDCP is moved from the SN (gNodeB) back to the MN (eNodeB),
which includes reconfiguring the SN Terminated Split Bearer to an MN Terminated MCG
Bearer. The eNodeB then configures a B1 measurement in the UE to detect NR coverage
(regardless of whether the eNodeB uses configuration-based or measurement-based SN
addition) and, if a B1 report is received from the UE, the eNodeB reattempts SN addition.

6.2.3.6 EN-DC Triggered Handover (ENDCHO)

A UE is typically provided with EN-DC service using the serving LTE cell. However, if
another LTE cell is better suited to provide the UE with EN-DC, then it can be moved to
that cell using EN-DC triggered handover (ENDCHO).

Another LTE cell is better suited to provide the UE with EN-DC in the following cases:

• The UE cannot use the serving LTE cell for EN-DC, for example because the cell is not
capable of EN-DC, or because the UE does not support the EN-DC band combinations
available on the cell. The UE can, however, use another LTE cell for EN-DC.

• The UE can use the serving LTE cell for EN-DC, but the UE does not have coverage
from the required NR frequency(s). However, the UE does have coverage from a lower
priority NR frequency that the UE can use for EN-DC if it moves to another LTE cell.

• The UE can use the serving LTE cell for EN-DC and the UE has coverage from the
required NR frequency(s). However, the UE also has coverage from a higher priority
NR frequency that it can use for EN-DC if it moves to another LTE cell.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 49 (179)
 5G Mobility and Traffic Management Guideline

ENDCHO functionality is provided by the features shown in Table 6-1 and Figure 6-6. See
the indicated sections for more detail.
Table 6-1 – EN-DC Triggered Handover Features
Node Measurements
Feature Name Trigger
Type Configured
EN-DC Triggered Handover During
Baseband Connection setup B1 and A5
Connection Setup (Section 9.2.13)
Basic EN-DC Triggered Handover During
DU Connection setup A5 only
Connection Setup (Section 9.2.14)
Incoming handover
EN-DC Triggered Handover During
Baseband and RRC B1 and A5
Connected Mode Mobility (Section 9.2.16)
re-establishment
Inter Vendor EN-DC Triggered Handover Connection setup,
Baseband B1 and A5
During Setup (Setion 9.2.19) Incoming handover

Figure 6-6 – EN-DC Triggered Handover Procedures

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 50 (179)
 5G Mobility and Traffic Management Guideline

Notes for Figure 6-6:

• UE A - EN-DC Triggered Handover During Setup

– Assume that the serving LTE cell does not support EN-DC, because the
endcAllowedPlmnList is empty. Assume also that it is configured with a
GUtranFreqRelation, which allows the NR frequency to be measured for
ENDCHO.

– The ENDCHO procedure is triggered when the UE performs an initial context setup

– The eNodeB configures the UE with an A5 measurement to detect coverage from

an EN-DC capable LTE cell, and a B1 measurement to detect coverage from NR.

– When the B1 report is received, it is stored and the eNodeB waits for the A5 report.

– If the A5 report is received within 240 ms of the B1 report, then eNodeB instructs
the UE to perform the ENDCHO. If the A5 report is received after this time expires
then it cannot be used in combination with that B1 report for ENDCHO.

– Upon receiving the incoming handover, the eNodeB initiates SN addition using the
forwarded B1 measurement results.

• UE B - Basic EN-DC Triggered Handover During Setup

– This is similar to the UE A case, but the serving LTE cell is on a DU node, which
does not support EN-DC.

– The eNodeB configures the UE with an A5 measurement only. B1 is not used.

– When the A5 report is received, the eNodeB instructs the UE to perform the
handover.

– Upon receiving the incoming handover, the target eNodeB configures a B1

measurement in the UE to detect NR coverage.

– When the B1 report is received the eNodeB initiates SN addition.

• UE C - EN-DC Triggered Handover During Connected Mode Mobility

– This is similar to the UE A case, but the triggers for ENDCHO are incoming
handover and RRC re-establishment rather than initial context setup. After this, the
process is the same.

6.2.4 Data Bearer Addition – NSA

The addition of an MBB data bearer is triggered by subscriber activity, for example when
the subscriber starts an application requiring QoS treatment which is different from that of
the default bearer.

Additional bearers are set up as either MN or SN terminated as follows:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 51 (179)
 5G Mobility and Traffic Management Guideline

• If the additional bearer is allowed to be configured as an SN Terminated bearer, then it

is set up to match any pre-existing SN Terminated bearers, either as an SN Terminated
Split DRB or as an SN Terminated MCG DRB.

• If the additional bearer is not allowed to be configured as an SN Terminated bearer,

then it is set up as an MN Terminated MCG DRB.

• If the additional bearer prevents other bearers from being configured as split bearers,
then any pre-existing SN Terminated Split DRBs are reconfigured as SN Terminated
MCG DRBs.

• Setting up a mix of additional bearer types is supported.

• For a virtual gNodeB (vPP), additional bearers are always set up as MN Terminated
MCG DRBs.

Figure 6-7 shows an example where two additional bearers are set up, one as an SN
Terminated Split DRB and one as an MN Terminated MCG DRB. In this example none of
the bearers prevent other bearers from being configured as split.

Figure 6-7 - Bearer Addition Procedure

6.2.5 Secondary Node Release (keeping Master Node) – NSA

Secondary Node Release, keeping the Master Node, can be initiated either by the Master
Node or the Secondary Node.

The Master Node initiates a Secondary Node release in the following cases:

• MN receives SCGFailureInformationNR message from the UE, due to Radio Link

Failure

• MN detects LTE mobility due to intra-cell, intra-frequency or inter-frequency

The Secondary Node initiates a Secondary Node release in the following cases:

• SN detects expiry of the Random Access Supervision Timer or failure in another part of
the SCG Addition process

• SN detects that RLC exceeds its maximum downlink retransmission

• SN detects NR cell lock

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 52 (179)
 5G Mobility and Traffic Management Guideline

• SN receives an A2 critical report from the UE, as described in 6.3.3.

Secondary Node Release, keeping the Master Node, is not triggered by inactivity; inactivity
causes release to idle mode, as described in 6.2.6.2.

When the SN is released, any SN terminated bearers are transitioned to MN Terminated

MCG Bearers, as shown in Figure 6-8. The eNodeB then configures a B1 measurement in
the UE to detect NR coverage and, if a B1 report is received from the UE, the eNodeB
attempts SN addition.

Figure 6-8 - SN Release - Split Bearer Example

6.2.6 Release to Idle Mode – NSA

UE release from connected mode to idle mode is triggered by either the MME or the
eNodeB. Reasons for the eNodeB to trigger a release are UE inactivity or LTE Radio Link
Failure.

For inactivity, the procedure depends on the bearers in use by the UE. There are two
cases:

• UE with only Master Node (MN) terminated bearers

• UE with one or more Secondary Node (SN) terminated bearers

In both cases the release decision is taken by the MN (eNodeB). However, when the UE
has an SN terminated bearer, the eNodeB obtains assistance from the SN. The following
sections provide more detail on these two cases.

At release to idle mode, the feature Capability-Aware Idle Mode Control can be used to
alter the idle mode reselection behavior of UEs, for example to steer EN-DC capable UEs
towards EN-DC capable LTE carriers. This is described in Section 8.2.1.1.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 53 (179)
 5G Mobility and Traffic Management Guideline

6.2.6.1 Inactivity Release – UE with only MN terminated bearers

If the UE has only MN terminated bearers (no SN terminated bearers), then the inactivity
release is identical to that for legacy LTE. The eNodeB releases the UE if no data has been
sent in the uplink or the downlink on any DRB for a period of at least
Rcs.tInactivityTimer (set in the eNodeB) and no NAS message has been sent or
received for at least 4 seconds.

6.2.6.2 Inactivity Release – UE with an SN terminated bearer

If the UE has one or more SN terminated bearers, then both the MN (eNodeB) and the SN
(gNodeB) monitor UE activity. The monitoring is performed at the PDCP layer. The MN
monitors the activity of any MN terminated DRBs. The SN monitors the activity of SN
terminated DRBs and informs the eNodeB of the results over the X2-AP interface.

The node responsible for actually releasing a UE due to inactivity is the eNodeB. It
releases the UE when all DRBs (both MN and SN terminated) have been inactive for a
period of at least Rcs.tInactivityTimer (set in the eNodeB) and no NAS message
has been sent or received for at least 4 seconds. To achieve this, the following processes
are followed.

SN (gNodeB) Inactivity Monitoring

The SN considers a UE inactive if all SN terminated DRBs have been inactive in both the
uplink and the downlink for a period of at least 5 seconds (hardcoded). The SN informs the
MN (eNodeB) of the UE inactivity by sending the notification SGNB Activity Notification
(inactive) over the X2-AP interface.

The SN considers a UE active if any SN terminated DRB has any activity in either the
uplink or downlink. The SN informs the MN (eNodeB) of the UE activity by sending the
notification SGNB Activity Notification (active) over the X2-AP interface.

The SN does not initiate release based on inactivity. It simply notifies the eNodeB of the
activity, and the eNodeB determines when to release the UE.

MN (eNodeB) Inactivity Monitoring

The UE is released to idle mode when the eNodeB decides that the DRBs (both MN and
SN terminated) are inactive and NAS signaling has not occurred for at least 3 seconds.

The eNodeB uses the following rules to decide whether a DRB is inactive:

• Any MN terminated DRB is considered inactive by the eNodeB when no data has been
transmitted in either the uplink or the downlink on that DRB for at least
Rcs.tInactivityTimer.

• All SN terminated DRBs are considered inactive by the eNodeB when the notification
SGNB Activity Notification (inactive) is received by the eNodeB and an additional
waiting time has elapsed without receiving an active notification. The additional waiting
time is zero if Rcs.tInactivityTimer = 4s, or else it is
Rcs.tInactivityTimer – 5s.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 54 (179)
 5G Mobility and Traffic Management Guideline

Figure 6-9 summarizes the procedure for release due to inactivity for a UE with both an MN
terminated MCG DRB and an SN terminated split DRB.

Figure 6-9 - Release due to Inactivity - Split Bearer Example

6.3 NR Coverage-Triggered Mobility Procedures – NSA

This section covers mobility procedures that are triggered by changes in NR coverage.

6.3.1 NR Intra-Frequency PSCell Change – NSA

This procedure is enabled by the gNodeB feature NR Mobility (FAJ 121 5041), Section
9.3.3.1.

Two NR cells are considered intra-frequency if they have matching SSB definitions,
meaning they have identical values for the following attributes:

• NRCellDU.ssbDuration

• NRCellDU.ssbFrequency

• NRCellDU.ssbOffset

• NRCellDU.ssbPeriodicity

• NRCellDU.ssbSubCarrierSpacing

Note, however, that the two cells do not need to have the same bandwidth
(bSChannelBwDL and bSChannelBwUL) to be considered intra-frequency, as shown in
Figure 6-10.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 55 (179)
 5G Mobility and Traffic Management Guideline

Figure 6-10 – Intra-Frequency and Inter-Frequency Examples

NR intra-frequency PSCell change is triggered by the gNodeB when an NR A3 report is

received from the UE (forwarded by the eNodeB). The procedure is shown in Figure 6-11.

Figure 6-11 – NR Intra-Frequency PSCell Change

Notes for Figure 6-11:

1 Serving SN receives (via the eNodeB) an NR Event A3 report from the UE
2 Serving SN initiates a PSCell change

For the PSCell change to be performed the following must be fulfilled:

• Target cell must be configured in the serving SN (NRCellCU or ExternalNRCellCU

with matching nRPCI exists)

• An NRCellRelation between the serving and reported cell exists

• Parameter NRCellRelation.isHoAllowed = true for the target NR cell

• The MCG PCell must be capable of acting as an LTE anchor cell for the target NR cell,
that is it must have a GUtranCellRelation to the target NR cell

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 56 (179)
 5G Mobility and Traffic Management Guideline

If the PCI reported in the Event A3 does not have a corresponding neighbor relation or if
NRCellRelation.isHoAllowed = false for the neighbor relation, the PSCell change
cannot be initiated. Then the outcome is determined by the setting of
endcActionA3EvalFail:

• If ReportConfigA3.endcActionA3EvalFail = IGNORE, then the existing EN-DC

configuration is kept, and Cell A remains the PSCell.

• If ReportConfigA3.endcActionA3EvalFail = RELEASE, then an SN initiated

SN Release is triggered and the eNodeB configures a B1 measurement in the UE.

All NR neighbor relations must be manually configured as ANR for intra-frequency

NR relations is not supported in the current software release. Figure 6-12 shows the
managed objects involved.

Figure 6-12 – Managed Objects for NR Neighbor Configuration

Notes for Figure 6-12:

1 This solid line indicates that the NRCellRelation MO is a child of the NRCellCU
MO.
2 This dashed line indicates an intra-gNodeB relation. For example, a relation from
NRCellCUA to NRCellCUB consists of an NRCellRelation which is a child of
NRCellCUA and contains an nRCellRef attribute pointing to NRCellCUB.

3 This dashed line indicates an inter-gNodeB relation. For example, a relation from
NRCellCUA to ExternalNRCellCUC consists of an NRCellRelation which is a
child of NRCellCUA and contains an nRCellRef attribute pointing to
ExternalNRCellCUC.

6.3.2 NR Radio Link Failure – NSA

NR Radio Link Failure (RLF) can be detected by either the UE or the gNodeB.

If the UE detects NR RLF, via one of the following conditions, then the eNodeB initiates SN
release:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 57 (179)
 5G Mobility and Traffic Management Guideline

• Random access during SN addition procedure fails (GNBDUFunction.Rrc.t304

expires)

• RLC UL delivery failure. The number of UL RLC retransmissions exceeds

GNBDUFunction.DataRadioBearer.ulMaxRetxThreshold

• Out of synchronization (t310-Expiry). The UE is configured to monitor the SSB for

Radio Link Monitoring purposes and counts “in-synch” and “out-of-synch” indications.

– GNBDUFunction.Rrc.n310 consecutive “out-of-synch” indications starts timer

T310 (set by GNBDUFunction.Rcs.t310)

– GNBDUFunction.Rrc.n311 consecutive “in-synch” indication stops timer T310

– RLF occurs when T310 expires

If the gNodeB detects NR RLF, via the following condition, then the gNodeB initiates SN
release:

• RLC DL delivery failure. The number of DL RLC retransmissions exceeds

GNBDUFunction.DataRadioBearer.dlMaxRetxThreshold

6.3.3 NR Coverage-Triggered Secondary Node Release – NSA

This procedure is enabled by the gNodeB feature LTE-NR Dual Connectivity (FAJ 121
4908), Section 9.3.1.

To detect critical NR coverage, the gNodeB configures the UE with an A2 measurement

event when an EN-DC connection is set up. The event triggers when the measured
SS-RSRP of the serving PSCell falls below threshold – hysteresis/10 for
timeToTrigger (as configured in the structure McpcPSCellProfile.rsrpCritical).
This causes the UE to send an A2 measurement report to the Secondary Node, which
initiates SN release.

The A2 critical release threshold must be set below the B1 SN addition threshold. If not,
SN addition could be immediately followed by critical release, or critical release could be
immediately followed by another SN addition. For full details on the parameters involved
with these two thresholds, see Section 10.2.7 (for the A2) and Section 10.2.2 (for the B1).

This functionality is enabled by setting NRCellCU.mcpcEnabled = true, and

McpcPSCellProfile.rsrpCriticalEnabled = true. The McpcPSCellProfile
class is described in Section 12.

6.3.4 NR Intra-Frequency SCell Change – NSA

NR intra-frequency SCell Change in FR1 is triggered by the gNodeB when an NR A6 report

is received from the UE (forwarded by the eNodeB). The procedure is shown in Figure
6-13.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 58 (179)
 5G Mobility and Traffic Management Guideline

Figure 6-13 – NSA Intra-frequency SCell Change

Notes for Figure 6-13:

1 Serving SN receives (via the eNodeB) an Event A6 report for NR SCell B from the UE
2 Serving SN deconfigures NR SCell A and configures and activates NR SCell B

For the SCell change to be performed the following must be fulfilled:

• The target cell must be configured in the serving SN (NRCellCU or

ExternalNRCellCU with a matching nRPCI)

• An NRCellRelation between the NR PSCell and NR SCell B with:

– NRCellRelation.sCellCandidate = ALLOWED

– The read-only parameter NRCellRelation.caStatusActive is true when

using the feature NR DL Carrier Aggregation for Coverage Extension for FDD /
TDD carrier aggregation.

All NR neighbor relations for carrier aggregation must be manually configured.

6.4 VoLTE Procedures – NSA

In the current NR NSA solution, VoLTE continues to be carried over the LTE network only.

VoLTE uses two bearers with the following QoS Class Identifier (QCI) values:

• A signaling bearer (QCI5)

• A voice data bearer (QCI1)

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 59 (179)
 5G Mobility and Traffic Management Guideline

The eNodeB prevents the QCI1 bearer from being configured as an EN-DC split bearer, as
3GPP standards do not allow it.

Other bearers, such as QCI9, may still be configured as split bearers, even when VoLTE is
present. However, the recommended configuration is to disallow split bearers when the UE
has a VoLTE connection, to ensure VoLTE performance is maintained. This is best
achieved with the following settings:

• Disallow Split Bearers with VoLTE

Assign EndcProfilePredefined = 3 to QCI’s used for VoIP services (e.g. QCI1 and
QCI2). This predefined profile has the following settings:

– meNbS1TermReqArpLev = 15
The VoLTE bearer cannot have an ARP greater than 15, so this setting disallows
split for the VoLTE bearer.

– splitNotAllowedUeArpLev =15
The VoLTE bearer cannot have an ARP greater than 15, so this setting disallows
split for all bearers.

Note that the ARP scale is reversed: a low priority bearer has a high ARP value.

• Inhibit SN Addition During MO Voice Setup

Set ENodeBFunction.endcSplitAllowedMoVoice = false. This introduces an
additional mechanism to inhibit SN addition while a mobile originated voice call is being
set up from idle mode. It does not cover mobile terminated voice calls.

The above settings are a subset of the criteria considered for SN addition, which are fully
described in Section 6.2.3.1.

6.4.1 VoLTE Setup from Idle Mode – NSA

The procedure for setting up VoLTE from idle mode is unchanged by the deployment of
EN-DC. Both of the VoLTE bearers (QCI1 and QCI5) and the data bearer (for example
QCI9) are set up as MN Terminated MCG Bearers, as shown in Figure 6-14.

Figure 6-14 - VoLTE Setup from Idle Mode

For mobile originated voice calls, there is a mechanism to inhibit SN addition for a
configurable guard time while the call is set up; see Section 6.2.3.1 for details.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 60 (179)
 5G Mobility and Traffic Management Guideline

6.4.2 Setup in Connected Mode – NSA

The procedure for setting up VoLTE from connected mode depends on the pre-existing
data bearers. Three examples are provided here, assuming a pre-existing default data
bearer of one of the following types:

• MN Terminated MCG Bearer

• SN Terminated Split Bearer

• SN Terminated MCG Bearer

6.4.2.1 VoLTE Setup with Pre-Existing MN Terminated MCG Bearer

This procedure is unchanged from the legacy LTE procedure. The VoLTE bearer for voice
data (QCI1) is set up as an MN Terminated MCG Bearer, as shown in Figure 6-15.

Figure 6-15 - VoLTE Setup with MN Terminated MCG Bearer

If B1 measurements for SN addition are in place when the VoLTE bearer is set up, then the
measurements are removed.

6.4.2.2 VoLTE Setup with Pre-Existing SN Terminated Split Bearer

The procedure for adding VoLTE to an existing SN Terminated Split Bearer depends on
whether a split bearer is allowed for the UE when a VoLTE bearer is present, as detailed in
Section 6.3.4. The recommended configuration is disallowed, to ensure VoLTE
performance is maintained.

Split Bearers with VoLTE Not Allowed

If split bearers with VoLTE are not allowed, then VoLTE call setup is handled as shown in
Figure 6-16. The VoLTE setup triggers the removal of the SCG for the QCI9 bearer but the
PDCP layer remains in the secondary node and the bearer becomes an SN Terminated
MCG Bearer. At the next mobility event the PDCP layer is moved to the master node, and
the bearer becomes an MN Terminated MCG Bearer.

In this context, the “next mobility event” is one of the following:

• LTE intra or inter-frequency handover

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 61 (179)
 5G Mobility and Traffic Management Guideline

• LTE intra-cell handover that is performed by EN-DC capable UEs when one of the
following events occurs:

– TTI bundling activation or deactivation

– E-RAB setup when there are no available DRB IDs on the same security key

– Security key change

Figure 6-16 - VoLTE Setup with Split Bearer Not Allowed

Split Bearers with VoLTE Allowed

If split bearers with VoLTE are allowed, then the VoLTE QCI1 bearer is set up as normal
MN Terminated MCG Bearer and the QCI9 split bearer is not impacted, as shown in Figure
6-17.

Figure 6-17 - VoLTE Setup with Split Bearer Allowed

6.4.2.3 VoLTE Setup with Pre-Existing SN Terminated MCG Bearer

This case can only arise when an SN terminated MCG bearer is in place (see Section
6.4.2.2) and then the VoLTE connection is released and set up again. In this case the QCI1
bearer is simply added, leaving the other bearers unchanged as shown in Figure 6-18.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 62 (179)
 5G Mobility and Traffic Management Guideline

Figure 6-18 - VoLTE Setup with SN Terminated MCG Bearer

6.4.3 VoLTE Release – NSA

When a VoLTE connection is released, the overall procedure depends on which bearers
are in place at the time. Three examples are provided here:

• VoLTE with MN Terminated MCG Bearer

• VoLTE with SN Terminated MCG Bearer

• VoLTE with SN Terminated Split Bearer

VoLTE Release with MN Terminated MCG Bearer

This is the most likely case. The QCI1 bearer is removed and, assuming split bearer is
allowed for the UE (see Section 6.3.4), a B1 measurement is configured in the UE. Upon
reception of a B1 report, the MN Terminated MCG Bearer is reconfigured as a split bearer.
This is shown in Figure 6-19.

Figure 6-19 - VoLTE Release with MN Terminated MCG Bearer

VoLTE Release with SN Terminated MCG Bearer

This case is similar to the case of the MN Terminated MCG Bearer. The QCI1 bearer is
removed and, assuming split bearer is allowed for the UE (see Section 6.3.4), a B1
measurement is configured in the UE. Upon reception of a B1 report, the SN Terminated
MCG Bearer is reconfigured as a split bearer. This is shown in Figure 6-20.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 63 (179)
 5G Mobility and Traffic Management Guideline

Figure 6-20 - VoLTE Release with SN Terminated MCG Bearer

If a new bearer is set up while an SN Terminated MCG Bearer is in place (as shown in the
middle configuration above), then the new bearer is set up as an MN Terminated MCG
Bearer. When a B1 report is received, then the existing SN Terminated MCG Bearer is
converted to an SN Terminated Split Bearer as shown in the right-hand side of Figure 6-20.
The new bearer, however, remains as an MN Terminated MCG Bearer, even if split bearer
is allowed for this new bearer.

VoLTE Release with SN Terminated Split Bearer

This case can only arise if split bearer is allowed with VoLTE. The QCI1 bearer is removed,
leaving the SN Terminated Split Bearer in place. This is shown in Figure 6-21.

Figure 6-21 - VoLTE Release with SN Terminated Split Bearer

6.4.4 VoLTE Single Radio Voice Call Continuity (SRVCC) – NSA

The procedure for SRVCC depends whether the UE is configured with an SN terminated
bearer or not. If it is not, then the procedure is identical to that for legacy LTE. If it is, then
the SN terminated bearer is released at SRVCC.

6.5 CS Fallback Procedures – NSA

This section describes procedures that are initiated by a CS fallback event.

6.5.1 CS Fallback from Idle Mode – NSA

The procedure for CS fallback from idle mode is unchanged by the deployment of EN-DC
and is identical to that for legacy LTE.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 64 (179)
 5G Mobility and Traffic Management Guideline

6.5.2 CS Fallback from Connected Mode – NSA

The procedure for CS fallback from connected mode depends whether the UE is
configured with an SN terminated bearer or not.

• If it is, then the SN terminated bearer is released at RRC connection release (in the
case of CS fallback based on release-with-redirect) or at outgoing IRAT handover (in
the case of PSHO-Based CS Fallback to UTRAN).

• If not, then the procedure is identical to that for legacy LTE.

If measurement-based CS Fallback is activated, the NR B1 measurements are stopped (if

ongoing).

Otherwise the procedure is identical to that for legacy LTE.

6.6 LTE Coverage-Triggered Mobility Procedures – NSA

This section describes procedures that are triggered by changes in LTE coverage,
including intra-frequency, inter-frequency and inter-RAT handover, connection
re-establishment and radio link failure. In the current release, all LTE handover cases
trigger MN initiated SN release as part of the handover procedure.

6.6.1 Intra-LTE Handover – NSA

The procedure for intra-LTE handover depends on the data bearers that are in place when
the handover is triggered. Three examples are provided here, assuming the following
bearers:

• MN Terminated MCG Bearer

• SN Terminated Split Bearer

• SN Terminated MCG Bearer with VoLTE

The procedures cover both intra and inter-frequency handover within LTE.

6.6.1.1 Intra-LTE Handover with MN Terminated MCG Bearer

The procedure for intra-LTE handover with an MN Terminated MCG Bearer is shown in
Figure 6-22. This case can arise, for example, if the serving LTE cell (A in this case) is not
capable of EN-DC. The first part of the procedure, the LTE handover itself, is identical to
that for legacy LTE. The second part of the procedure shows the case where SN addition
occurs on the target cell. Possible alternatives are that SN addition does not occur (for
example because the target cell is not capable of EN-DC) or that EN-DC triggered
handover occurs (for example because an LTE cell on another frequency is better suited to
provide EN-DC).

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 65 (179)
 5G Mobility and Traffic Management Guideline

Figure 6-22 – Intra-LTE Handover with MN Terminated MCG Bearer without VoLTE

Notes for Figure 6-22:

1 eNodeB receives Event A3 or Event A5 report from the UE
2 eNodeB initiates intra-frequency or inter-frequency handover on LTE
3 If Cell B is EN-DC capable and split bearer is allowed for the UE, then the eNodeB (for
Cell B) configures B1 measurement report in the UE
4 eNodeB receives Event B1 report from the UE
5 eNodeB initiates secondary node addition and secondary cell group addition

The above procedure assumes that the target cell uses measurement-based SN addition.
If the target cell uses configuration-based SN addition, then after the handover in Step 2
the target eNodeB attempts to set up EN-DC on the configured NR cell, without
measurements.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 66 (179)
 5G Mobility and Traffic Management Guideline

6.6.1.2 Intra-LTE Handover with SN Terminated Split Bearer

The procedure for intra-LTE handover with an SN Terminated Split Bearer is shown in
Figure 6-23. This example shows the case where SN addition occurs on the target cell.
Possible alternatives are that SN addition does not occur (for example because the target
cell is not capable of EN-DC) or that EN-DC triggered handover occurs (for example
because an LTE cell on another frequency is better suited to provide EN-DC).

Figure 6-23 – Intra-LTE Handover with SN Terminated Split Bearer

Notes for Figure 6-23:

1 eNodeB receives Event A3 or Event A5 report from the UE
2 eNodeB initiates secondary node release, including secondary cell group release
3 eNodeB initiates intra-frequency or inter-frequency handover on LTE
4 eNodeB configures B1 measurement report in the UE, if the target LTE cell is also EN-
DC capable.
5 eNodeB receives Event B1 report from the UE
6 eNodeB initiates secondary node addition, including secondary cell group addition

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 67 (179)
 5G Mobility and Traffic Management Guideline

The above procedure assumes that the target cell uses measurement-based SN addition.
If the target cell uses configuration-based SN addition, then after the handover in Step 3
the target eNodeB attempts to set up EN-DC on the configured NR cell (according to Step
6).

6.6.1.3 Intra-LTE Handover with SN Terminated MCG Bearer & VoLTE

An intra-LTE handover with an SN Terminated MCG Bearer with VoLTE arises from the
following sequence of events:

• An SN Terminated Split Bearer is set up

• VoLTE call is setup, but split bearer is not allowed with VoLTE (default configuration).
This causes the SN Terminated Split Bearer to be reconfigured as an SN Terminated
MCG Bearer.

• The next mobility event is an LTE Event A3 or A5

Assuming that this sequence occurs, the resulting handover procedure is shown in Figure
6-24.

Figure 6-24 – Intra-LTE Handover with SN Terminated MCG Bearer

Notes for Figure 6-24:

1 eNodeB receives Event A3 or Event A5 report from the UE
2 eNodeB initiates SN release
3 eNodeB initiates intra or inter-frequency handover on LTE

Note that after Step 3, the presence of the VoLTE bearer prevents the eNodeB from
configuring the UE with an Event B1 to detect NR coverage. The B1 is configured only
when the VoLTE connection is released.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 68 (179)
 5G Mobility and Traffic Management Guideline

6.6.2 IRAT Handover – NSA

If an IRAT handover is triggered, the procedure is the same as for IRAT handover in legacy
LTE, with the exception that the Secondary Node is released, including any Secondary Cell
Group resources.

6.6.3 LTE Radio Link Failure – NSA

If an LTE Radio Link Failure is triggered, the procedure is the same as for legacy LTE, with
the addition that if a split bearer is configured then the Secondary Node is released,
including any Secondary Cell Group resources.

6.6.4 LTE RRC Connection Re-establishment – NSA

If an LTE connection re-establishment is triggered, the procedure is the same as for legacy
LTE, with the addition that if a split bearer is configured then the Secondary Node is
released, including any Secondary Cell Group resources.

After a successful connection re-establishment, if all the prerequisites for SN addition are
fulfilled then the eNodeB sets up an Event B1 measurement in the UE to facilitate SN
addition. Measurement-based SN addition is always used, even if the cell is configured for
configuration-based SN addition.

6.7 LTE Load-Triggered Mobility Procedures – NSA

In a network which supports EN-DC, connected mode load balancing procedures are
different for the following three cases of UEs:

• UEs that are not EN-DC capable

• UEs that are EN-DC capable and have an SN Terminated Split Bearer configured.

• UEs that are EN-DC capable but do not have an SN Terminated Split Bearer
configured

The following sections provide more detail on load-triggered mobility for these three cases.

6.7.1 LTE Load-Triggered Mobility – Non EN-DC Capable UEs – NSA

Load-triggered mobility for UEs that are not capable of EN-DC is unchanged from legacy
LTE behavior.

6.7.2 LTE Load-Triggered Mobility – UEs With Split Bearer Configured – NSA

Load-trigged mobility is disabled for UEs with an SN Terminated Split Bearer configured.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 69 (179)
 5G Mobility and Traffic Management Guideline

6.7.3 LTE Load-Triggered Mobility – EN-DC Capable UEs Without Split Bearer –
NSA

Load-triggered mobility can be disabled for UEs that are capable of EN-DC but do not have
an SN Terminated Split Bearer configured. This is done with the parameter
LoadBalancingFunction.lbAllowedForEndcUe.

If lbAllowedForEndcUe = false, then load-triggered mobility is not allowed:

• This setting is recommended by Ericsson.

• It prevents load management features from configuring measurements in EN-DC

capable UEs without a split bearer, which disables load-triggered handover.

If lbAllowedForEndcUe = true, then load-triggered mobility is allowed:

• Load-triggered inter-frequency handovers follow the same procedures as coverage-

triggered inter-frequency handovers, as detailed in Section 6.6.1.

• Load-triggered inter-RAT handovers follow the same procedures as coverage-triggered

inter-RAT handovers, as detailed in Section 6.6.2.

The parameter lbAllowedForEndcUe applies to the following features:

• Inter-Frequency Load Balancing

• Inter-Frequency Offload

• Inter-RAT Offload to WCDMA

• Carrier Aggregation-Aware IFLB

• UE Throughput-Aware IFLB

• Limited Uplink-Aware IFLB

• Best Neighbor Relations for Load Management

The parameter lbAllowedForEndcUe does not apply to the features Load-Based

Distribution at Release (LBDAR) or Evolved Load-Based Distribution at Release
(ELBDAR). These features can, however, be overridden for EN-DC capable UEs by the
feature Capability-Aware Idle Mode Control (Section 9.2.9).

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 70 (179)
 5G Mobility and Traffic Management Guideline

7 Mobility and Connectivity Procedures – SA

This section describes mobility and connectivity procedures for SA. The SA procedures are
simpler than the NSA procedures as they involve only one Radio Access Technology
(RAT).

7.1 Idle Mode Procedures – SA

Procedures performed by UEs in idle mode include:

• PLMN Selection

• System information acquisition

• Cell selection and reselection (intra-frequency, inter-frequency and inter-RAT)

• Tracking area updates and paging

This section focuses on cell selection and reselection, as these are most relevant for
mobility and traffic management. The following simplifying assumptions are made:

• Higher priority PLMN offsets do not apply,

• The UE is capable of the maximum transmit power allowed in the cell and

• Speed dependent scaling does not apply.

These assumptions typically apply in most cases.

7.1.1 Cell Selection – SA

Cell selection is the idle mode procedure performed by the UE to find a suitable cell on
which to camp, after PLMN selection or after return from connected mode to idle mode.
UEs which are capable of both LTE and NR SA can select cells on either LTE or NR SA.
UEs which are capable only of SA can select cells only on SA.

The UE can select an NR SA cell when:

SS_RSRPNR > (gNB)NRCellDU.qRxLevMin

and

SS_RSRQNR > (gNB)NRCellDU.qQualMin

For LTE, similar conditions apply; see Section 10.1.1. for details.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 71 (179)
 5G Mobility and Traffic Management Guideline

7.1.2 Cell Reselection – SA

Cell reselection is the procedure followed by the UE to change the cell on which it is
camped, when it finds a better cell. It is performed autonomously by the UE, using the
parameters broadcast in the system information messages of the cell on which it is
camped. Cell reselection can be intra-frequency, inter-frequency, or inter-RAT if the UE is
capable of both RATs, for example LTE and NR SA.

To perform cell reselection, the UE measures the serving cell and other cells on the same
frequency, and potentially also cells on other frequencies on the same RAT or other RATs.
The frequencies to be measured, the conditions under which to measure them and the
criteria for reselection are communicated to the UE in system information.

A detailed description of the parameters governing idle mode selection is provided in

Section 10.1.

7.1.2.1 Criteria to Conduct Measurements for Intra-Frequency Cell Reselection

Before the UE can reselect between cells on the same frequency, it must be measuring the
cells.

If camped on NR SA, the UE must perform intra-frequency measurements when:

SS_RSRPNR < (gNB)NRCellDU.qRxLevMin

+ (gNB)NRFreqRelation.sIntraSearchP

or

SS_RSRQNR < (gNB)NRCellDU.qQualMin

+ (gNB)NRFreqRelation.sIntraSearchQ

If the above conditions are not met, then the UE may choose not to perform intra-
frequency measurements.

If camped on LTE, similar criteria are applied; see Section 10.1.2 for details.

7.1.2.2 Intra-Frequency Cell Reselection

Given that the UE is camping on NR SA and the intra-frequency measurements are being
performed, intra-frequency cell reselection occurs when:

SS_RSRPtarget - SS_RSRPsource > (gNB)NRCellCU.qHyst

and

SS_RSRPtarget > (gNB)NRFreqRelation.qRxLevMin

and

SS_RSRQtarget > (gNB)NRFreqRelation.qQualMin

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 72 (179)
 5G Mobility and Traffic Management Guideline

for a time of (gNB)NRFreqRelation.tReselectionNR, (default 2 s)

To ensure equal cell size in idle and connected modes, set qHyst equal to the connected
mode handover margin, which is ReportConfigA3.offset +
ReportConfigA3.hysteresis (see Section 10.2.4). This decreases the risk of
immediate handover after RRC connection setup. Typically, qHyst is set to 4 dB. Note that
the current software revision does not provide cell relation level offsets for idle mode
reselection.

Figure 7-1 illustrates intra-frequency reselection behavior. The heavy black lines in the
diagram represent decreasing signal strength measured by the UE. The blue arrows show
the mobility behavior of the UE in response to the configured thresholds: diagonal as it
moves within a cell from good to poor coverage, and then vertical as it reselects to a
different cell.

Figure 7-1 – Idle Mode Intra-frequency NR SA Cell Reselection

If the UE is camped on LTE, similar criteria apply; see Section 10.1.3 for details.

7.1.2.3 Absolute Priorities

To control cell reselection between different frequencies and RATs in idle mode, absolute
priorities are used. The absolute priority is set by the parameter
cellReselectionPriority per frequency relation (for example NRFreqRelation or
EUtranFreqRelation). The settable values are 0 to 7; the higher the value, the higher
the priority. For EUtranFreqRelation, the value can also be set to empty, which means
it is not included in SIB5 and is unavailable for reselection. Note that a cell always has a
frequency relation to its own frequency, which determines the priority for that frequency.

Inter-frequency and inter-RAT measurements and cell reselection depend on whether the
absolute priority of the neighbor frequency is lower than, equal to, or higher than that of the
serving frequency. 3GPP have intentionally made IRAT comparisons with equal priorities
non-valid, so this must not be configured.

7.1.2.4 Criteria to Conduct Measurements for Inter-Frequency and Inter-RAT Cell

Reselection

In idle mode, the UE must always measure frequencies with higher

cellReselectionPriority than the serving frequency.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 73 (179)
 5G Mobility and Traffic Management Guideline

If camped on NR SA, the UE must measure frequencies with

cellReselectionPriority equal to or lower than the current frequency when:

SS_RSRPNR < (gNB)NRCellDU.qRxLevMin

+ (gNB)NRCellCU.sNonIntraSearchP

or

SS_RSRQNR < (gNB)NRCellDU.qQualMin

+ (gNB)NRCellCU.sNonIntraSearchQ

If sNonIntraSearchP or sNonIntraSearchQ is empty, then the UE applies the default

value of infinity (always measure).

If the above conditions are not met, then the UE can choose not to measure equal or lower
priority frequencies.

Similar criteria apply when the UE is camped on LTE; see Section 10.1.4 for details.

7.1.2.5 Inter-Frequency and Inter-RAT Cell Reselection

The criteria for cell reselection between NR SA and LTE depend on whether NR SA has a
higher or lower priority than LTE; they cannot have the same priority. Typically, NR SA
would be assigned a higher priority if it is expected to outperform LTE. Otherwise, if for
example NR SA has limited bandwidth, then the operator may choose to assign NR SA a
lower priority than LTE.

This section presents the case where NR SA has a higher priority than LTE. Other cases
(for example where NR SA has a lower priority, or the case of inter-frequency reselection)
are similar; refer to Sections 10.1.6 to 10.1.9 for details.

Given that NR SA has a higher cellReselectionPriority than LTE, reselection from

NR SA to LTE occurs when:

SS_RSRPNR < (gNB)NRCellCU.qRxLevMin

+ (gNB)NRCellCU.threshServingLowP

and

RSRPLTE > (gNB)EUtranFreqRelation.qRxLevMin

+ (gNB)EUtranFreqRelation.threshXLowP

for a time of (gNB)EUtranFreqRelation.tReselectionEUtra (default 2 s).

Reselection from LTE to NR SA occurs when:

SS_RSRPNR > (eNB)GUtranFreqRelation.qRxLevMin

+ (eNB)GUtranFreqRelation.threshXHigh

for a time of (eNB)EUtranCellFDD.systemInformationBlock24.

tReselectionNR (default 2 s).

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 74 (179)
 5G Mobility and Traffic Management Guideline

Idle mode reselection to NR SA frequencies is enabled by information broadcast to UEs

in SIB24. SIB24 does not include NR frequencies with
GUtranFreqRelation.cellReselectionPriority = -1.

The above formulas assume that reselection is based on SS_RSRP and RSRP. This is the
case if threshServingLowQ is not included in system information. If it is included, then
reselection will be based on SS_RSRQ and RSRQ; see Sections 10.1.6 to 10.1.9 for
details.

The above reselection criteria are illustrated by Figure 7-2. The heavy black lines in the
diagram represent decreasing signal strength measured by the UE. The blue arrows show
the mobility behavior of the UE in response to the configured thresholds: diagonal as it
moves within a cell from good to poor coverage, and then vertical as it reselects to a
different cell.

Figure 7-2 – Cell Reselection Between NR SA and LTE (assuming NR has higher priority)

The criteria for inter-frequency reselection are similar to those for inter-RAT reselection,
except that equal cellReselectionPriority is allowed for two frequencies on the
same RAT; see Section 10.1.5 to 10.1.7 for more information.

7.2 Connected Mode Procedures – SA

7.2.1 Release-With-Redirect from LTE to NR SA

This procedure is enabled by the eNodeB feature NR Coverage-Triggered NR Session

Continuity (FAJ 121 4983), Section 9.2.2.

Release-with-redirect provides a mechanism to move UEs in connected mode from LTE to

NR SA. It is triggered at RRC connection setup; that is after initial connection setup,
incoming handover or RRC re-establishment. To check for NR SA coverage the eNodeB
configures Event B1 measurements in the UE. If coverage is found, the UE sends an Event
B1 report to the eNodeB, which triggers a release-with-redirect to the reported frequency.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 75 (179)
 5G Mobility and Traffic Management Guideline

The number of B1 measurements configured for release-with-redirect is limited to

UeMeasControl.maxMeasNR (the default is 5). The priority for including NR frequencies
is set with the parameter GUtranFreqRelation.connectedModeMobilityPrio, from
7 (highest) to 0 (lowest). The value -1 means the frequency is excluded; set this value on
NR frequencies which are capable of NSA only, not SA.

For a UE to be configured with Event B1, for the purpose of release-with-redirect, the
following must be fulfilled:

• The parameter UeMeasControl.rwrToNRAllowed = true

• The UE does not have a voice bearer (serviceType: VOIP, PTT or MC_SIGNALING)

• The UE does not have an EN-DC bearer

• The UE supports NR SA on at least one of the NR frequencies with

connectedModeMobilityPrio not equal to -1. The UE indicates its support by
including frequencies in the capability SupportedbandListNR-SA in UE-EUTRA-
Capability Information Element (IE).

• The UE does not have the value NRrestrictedin5GS in the “NR restriction in 5GS” IE in
its Handover Restriction List (HRL).

• At least one of the serving or any equivalent PLMNs in the UE’s HRL matches any
PLMN in the GUtranFreqRelation.allowedPLMNList and at least one of these
matching PLMNs does not have the value 5GCForbidden in the “Core Network Type
Restrictions” IE in the HRL. This check is not applied if
GUtranFreqRelation.allowedPLMNList is empty.

The parameters used to control triggering of this B1 event are provided in Section 10.2.3.

There are three possibilities for configuring the sequence of B1 measurements: measure
periodically, measure forever and measure once. All three sequences begin when the UE
sets up an RRC connection and are shown in Figure 7-3.

• Measurements will be performed forever if

UeMeasControl.nrB1MobilityTimerLessTtt = -1, or if not then,

• Measurements will be performed only once if

UeMeasControl.waitForResumeNRMeas = -1, or if not then,

• Measurements will be performed periodically, because in this case

UeMeasControl.nrB1MobilityTimerLessTtt not equal to -1 and
UeMeasControl.waitForResumeNRMeas not equal to -1.

These measurements are stopped if a measurement report is received, or EN-DC is set up,
or a voice bearer is set up.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 76 (179)
 5G Mobility and Traffic Management Guideline

Figure 7-3 – Event B1 Measurement Sequence for RwR to NR SA

The default value for waitForStartNRMeas is 6000 (6 second). If both NSA and SA are
deployed, this allows time for EN-DC measurements to complete before starting
measurements for release-with-redirect to NR SA. More specifically, starting NR SA
measurements immediately after RRC connection setup would have limited value for the
following reasons:

• If SA has the highest priority in idle mode, then UEs are pushed to NR SA in idle mode
via the cell reselection priority settings. So, if the UE performs an RRC connection
setup on LTE, then it is likely that NR SA coverage is not available. It is therefore
reasonable to allow some time for the UE radio conditions to change before starting
measurements. Also, if NR NSA is deployed in addition to NR SA, then waiting for this
time allows EN-DC measurements to complete first.

• If LTE has the highest priority in idle mode (for example because NSA is preferred to
SA), then any EN-DC measurement setup process should preferably complete before
starting measurements for NR SA. To ensure this happens, set
waitForStartNRMeas to the longest expected time to complete B1 EN-DC
measurements, according to Section 9.2.1.1.

The key MOs and parameters required to configure release-with-redirect from LTE to NR
SA are shown in Figure 7-4.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 77 (179)
 5G Mobility and Traffic Management Guideline

Figure 7-4 – Key MOs and Parameters for Release-With-Redirect to NR SA

7.2.2 Intra-Frequency Handover – SA

This procedure is enabled by the gNodeB feature NR Mobility (FAJ 121 5041), Section
9.3.3.3.

NR intra-frequency handover is triggered by the gNodeB when an NR A3 report is received

from the UE.

For the handover to be performed the following must be fulfilled:

• The reported NR cell must be configured in the gNodeB (an NRCellCU or

ExternalNRCellCU with matching nRPCI exists)

• An NRCellRelation between the serving and reported cell exists

• Parameter NRCellRelation.isHoAllowed = true for the reported NR cell

• If RAN Slicing Framework is active, the target cell must

– belong to the same PLMN as the serving cell and

– support at least one S-NSSAI used by the UE in the serving cell

All NR neighbor relations must be manually configured as ANR for intra-frequency is not
supported in the current software release.

The parameters used to control triggering of the A3 Event are provided in Section 10.2.4.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 78 (179)
 5G Mobility and Traffic Management Guideline

7.2.3 Release-With-Redirect from NR SA to LTE

This procedure is enabled by the gNodeB feature NR Mobility (FAJ 121 5041), Section
9.3.3.4.

To detect poor NR SA coverage, the UE is configured with an Event A2 measurement

when a data bearer is set up.

When the coverage of the NR cell falls below the defined threshold the UE will send an A2
measurement report. When the event is triggered, the UE sends a report to the gNodeB,
which releases the UE and redirects it to the selected LTE frequency.

When selecting the LTE frequency, the frequencies are ranked by

EUtranFreqRelation.connectedModeMobilityPrio. The LTE frequency with
highest priority, that is supported by the UE, is selected. If more than one frequency has
the highest priority, then the frequency with the lowest ARFCN is selected. A frequency
cannot be selected if connectedModeMobilityPrio is set to empty.

Frequencies can be excluded for a particular UE by including either PLMN or RAT

restrictions in the Mobility Restriction List, which is received from the 5G core. For this
exclusion to work, the EUtranFreqRelation.allowedPlmnList must not be empty.

If no valid frequency can be found, release with redirect is not performed.

The parameters used to control triggering of the Event A2 are provided in Section 10.2.5.

To avoid toggling between LTE and NR SA in connected mode, set the trigger level for
release-with-redirect from LTE to NR SA (Event B1, Section 10.2.3), higher than the trigger
level for release-with-redirect from NR SA to LTE (Event A2, Section 10.2.5).

Also, to ensure that the UE is not immediately redirected to LTE after entering connected
mode, align the idle and connected mode cell sizes. To do this, assuming that NR SA has
a higher cellReselectionPriority than LTE, set the trigger level for idle mode
reselection from NR SA to LTE (threshXLowP, Section 10.1.9) higher than or equal to the
trigger level for release-with-redirect from NR SA to LTE (Event A2, Section 10.2.5).

7.2.4 Voice Fallback from NR SA to LTE

This procedure is enabled by the gNodeB feature EPS Fallback to IMS Voice (FAJ 121
5059), Section 9.3.6.

In case the UE or 5G network does not support Voice over NR (VoNR), a voice call
initiated or received in the 5G network will trigger a fallback to LTE. The fallback will be
performed as a release-with-redirect without measurements.

The LTE frequencies that are candidate for fallback are ranked by
EUtranFreqRelation.voicePrio. The LTE frequency with highest priority, that is
supported by the UE, is selected. If more than one frequency has the highest priority, then
the frequency with the lowest ARFCN is selected. A frequency cannot be selected if
voicePrio is set to empty.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 79 (179)
 5G Mobility and Traffic Management Guideline

Frequencies can be excluded for a particular UE by including either PLMN or RAT

restrictions in the Mobility Restriction List, which is received from the 5G core. For this
exclusion to work, the EUtranFreqRelation.allowedPlmnList must not be empty.

If no valid frequency can be found, release-with-redirect is not performed.

7.2.5 Emergency Voice Call Fallback from NR SA to LTE

This procedure is enabled by the gNodeB feature Service Request-Based Emergency

Fallback (FAJ 121 5166), Section 9.3.7.

Service request-based emergency fallback is triggered when a UE, in either idle or

connected mode, sends a Service Request (NAS) to the 5GC that indicates an emergency
call. 5GC will in turn send an Emergency Fallback Indicator to gNodeB which will perform a
release-with-redirect without measurements to LTE.

The LTE frequencies that are candidate for fallback are ranked by
EUtranFreqRelation.eutranFallbackPrioEc. The LTE frequency with highest
priority, that is supported by the UE, is selected. If more than one frequency has the
highest priority, then the frequency with the lowest ARFCN is selected. A frequency cannot
be selected if eutranFallbackPrioEc is set to empty.

Frequencies can be excluded for a particular UE by including either PLMN or RAT

restrictions in the Mobility Restriction List, which is received from the 5G core. For this
exclusion to work, the EUtranFreqRelation.allowedPlmnList must not be empty.

If no valid frequency can be found, the UE is released without redirection.

7.2.6 Intra-Frequency SCell Change – SA

NR intra-frequency SCell change in FR1 is triggered by the gNodeB when an NR A6 report

is received from the UE. The procedure is shown in Figure 7-5.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 80 (179)
 5G Mobility and Traffic Management Guideline

Figure 7-5 – SA Intra-frequency SCell Change

Notes for Figure 7-5:

1 Serving gNodeB receives an Event A6 report for NR SCell B from the UE
2 Serving gNodeB deconfigures NR SCell A and configures and activates NR SCell B

For the SCell change to be performed the following must be fulfilled:

• The target cell must be configured in the serving gNodeB (NRCellCU or

ExternalNRCellCU with a matching nRPCI)

• An NRCellRelation between the NR PCell and NR SCell B with:

– NRCellRelation.sCellCandidate = ALLOWED

– The read-only parameter NRCellRelation.caStatusActive is true when

using the feature NR DL Carrier Aggregation for Coverage Extension for FDD /
TDD carrier aggregation.

All NR neighbor relations for carrier aggregation must be manually configured.

7.2.7 Preventing a Non-ESS Capable UE from Using an SA ESS Cell

Before a UE is allowed to use an ESS NR cell, the gNodeB checks that the UE is capable
of ESS by verifying that the UE supports:

• Rate matching around LTE CRS

• DMRS symbol locations that do not collide with LTE CRS

UEs which are not capable of ESS are prevented from using ESS cells as follows:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 81 (179)
 5G Mobility and Traffic Management Guideline

• At initial access to an ESS cell, the UE is ordered to do a blind release with redirect to
the LTE frequency with the highest connectedModeMobilityPrio. To prevent the
UE from returning to the ESS frequency in idle mode, the release message includes
the information element deprioritisationReq.

• At incoming handover to an ESS cell, the handover request is rejected in the

preparation phase.

• At carrier aggregation Scell addition, an ESS cell is not configured as a Scell for a non-
ESS capable UE.

7.3 Interworking Between LTE and NR SA

Typically, NR SA will be deployed as an overlay to an established LTE network. It is
therefore important to consider the interworking between the two technologies. Although
the existing LTE network is likely to have multiple layers, the interworking functionality can
be illustrated with the simple two-layer network shown in Figure 7-6.

Figure 7-6 – Simple Two-Layer Network with LTE and NR SA

To ensure stable behavior, the idle and connected mode thresholds for IRAT mobility
between NR SA and LTE must be coordinated with each other. Figure 7-7 shows the
relevant thresholds, assuming that NR SA has a higher cellReselectionPriority
than LTE. The circled numbers refer to regions of signal strength on NR SA and LTE; see
the notes following the figure.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 82 (179)
 5G Mobility and Traffic Management Guideline

Figure 7-7 – IRAT Mobility Thresholds for LTE and NR SA

Notes for Figure 7-7:

1 In this region NR SA performance is good and UEs are actively pushed towards NR
SA, both in idle mode (by reselection to a higher priority carrier) and connected mode
(by release-with-redirect).
2 In this region NR SA performance is still reasonable; not good enough to actively push
UEs from LTE to NR SA and not poor enough to move UEs back to LTE.
3 In this region NR SA performance is poor. Provided LTE signal strength is reasonable,
UEs are pushed to LTE in idle mode. At the poorest end of this region, UEs are also
pushed to LTE in connected mode, via release-with-redirect, regardless of LTE signal
strength.
4 In this region NR SA is effectively unusable. UEs cannot camp on NR SA.
5 In this region LTE performance is good to reasonable. UEs can be pushed to this
region when NR SA performance is poor.
6 In this region LTE is usable, but performance is poor. UEs only camp in this region if
they cannot camp on NR SA.
7 In this region LTE is effectively unusable. UEs cannot camp on LTE.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 83 (179)
 5G Mobility and Traffic Management Guideline

The boundaries between these regions in Figure 7-7 are set by the parameters shown.
While the figure shows the purpose of the parameters, and the relationship between them,
it does not provide recommended values. The best values depend on several factors such
as: the number of layers in each RAT, the bandwidth of the layers, the carrier aggregation
possibilities and the cell edge performance. Ideally, the thresholds are set so that UEs
leave NR when LTE performance is likely to be better. Recommended parameter values
are provided for common deployment cases in the CPI document RAN Parameter
Recommendations.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 84 (179)
 5G Mobility and Traffic Management Guideline

8 LTE Anchor Carrier Management – NSA

The Ericsson implementation for NSA allows any LTE carrier to be used as an anchor for
EN-DC. In a given network deployment, however, some carriers may be unsuitable for use
as anchors. Criteria for choosing suitable anchor carriers are provided in Section 8.1.

If EN-DC is not deployed on all LTE carriers or if UEs do not support EN-DC on all the
deployed band combinations, then a UE may find itself on an LTE carrier which cannot
provide it with EN-DC service. To obtain EN-DC service, the UE must be moved to an
appropriate LTE anchor carrier. If the existing mobility and traffic management strategy
does not accomplish this, then the strategy needs to be changed when 5G is deployed.
Section 8.2 explains how it can be changed to steer EN-DC capable UEs towards an
appropriate anchor carrier. Subsequent sections provide additional information configuring
anchor management solutions.

8.1 Choosing Suitable Anchor Carriers – NSA

The following sections present criteria for determining whether an LTE carrier is suitable for
use as an anchor for EN-DC.

8.1.1 Standardized EN-DC Band Combinations

The allowed band combinations for EN-DC operation are specified in 3GPP TS 38.101-3.

If an LTE carrier has no allowed band combinations with any of the deployed NR bands,
then it cannot be used as an anchor carrier with those carriers.

Note, however, that some bands overlap, and a physical frequency can be contained in
more than one band. With the feature Multiple Frequency Band Indicator, additional band
combinations can become available, and if one of those supports EN-DC then the LTE
carrier can be used as an anchor accordingly (refer to Section 9.2.1.3).

8.1.2 UE support of EN-DC Band Combinations

The UE reports its supported list of EN-DC band combinations in the IE UE-MRDC-
Capability as specified in 3GPP TS 38.331. Refer to Section 6.2.1 for how the eNodeB
requests this information.

Many UEs do not support EN-DC inter-band combinations that share the same UE power
amplifier, due to RF limitations when transmitting on both UL carrier frequencies.

A typical UE implementation is expected to share the same power amplifier for bands
within each one of the following band groups:

• FDD bands below 1 GHz

• FDD bands above 1 GHz

• TDD bands below 6 GHz

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 85 (179)
 5G Mobility and Traffic Management Guideline

EN-DC inter-band combinations that fall within one of these band groups are unlikely to be
supported by all UEs. For example, UEs are unlikely to support an EN-DC combination
where both the NR and LTE carriers are below 1GHz.

Note that intra-band EN-DC is allowed in 3GPP TS 38.101-3 for specific bands, for
example within B41.

In a given network deployment, it is possible that a particular LTE carrier has no EN-DC
band combinations that are likely to be supported by UEs. If so, that carrier is unsuitable for
use as an anchor carrier.

8.1.3 UE Support of Simultaneous Reception and Transmission

The UE indicates its support of simultaneous reception and transmission

(simultaneousRxTxInterBandENDC) on each EN-DC band combination using the IE
MRDC-Parameters, as specified in 3GPP TS 38.331.

UE support for simultaneous reception and transmission is a pre-requisite for setting up

EN-DC on that band combination. In a given network deployment, it is possible that a
particular LTE carrier has no EN-DC combinations on which UEs are likely to support
simultaneous reception and transmission. If so, that carrier is unsuitable for use as an
anchor carrier.

Note, however, that if a UE supports a band combination then it typically also supports
simultaneous reception and transmission on that band combination.

8.1.4 Potential IM Interference and Single UL Allowed

UEs that transmit simultaneously on two different frequencies (for example an LTE and an
NR frequency) may generate 2nd and 3rd order intermodulation (IM) products. If these IM
products fall within a receive band being used by the UE, then they can interfere with the
reception of the downlink. If the interference is strong enough, then it could impact
performance. Similar interference can be caused by harmonics of a single uplink
frequency.

This problem can occur on some EN-DC band combinations, where the simultaneous
transmission on LTE and NR frequencies may cause IM products that fall within the LTE
downlink receive band, causing interference.

Such IM interference can be avoided by not transmitting on both frequencies at the same
time. 3GPP has therefore provided a mechanism by which a UE can request single uplink
transmission on potentially problematic EN-DC band combinations. Such potentially
problematic combinations are marked as “Single UL Allowed” in 3GPP 38.101-3. UEs
request single uplink transmission on a particular EN-DC combination using the IE MRDC-
Parameters (singleUL-Transmission), as specified in 3GPP TS 38.331.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 86 (179)
 5G Mobility and Traffic Management Guideline

However, it is important to note that the NW is not mandated to follow the UE’s indication
and use single UL TX, whereas the UE is mandated to support dual UL TX even for Single
UL Allowed combinations. In current release, the Ericsson EN-DC implementation does not
consider the request for single UL TX and does not perform any coordination between LTE
and NR UL scheduling. Using single UL TX would inevitably impact performance compared
to dual UL TX, since LTE and NR UL transmissions would be divided in time.

An EN-DC combination that is marked as “Single UL Allowed” is only potentially

problematic. Whether it actually presents a risk in a given network deployment depends on
exactly which frequencies are used by the operator and whether their IM products fall on
the DL carrier in use.

Take the example of LTE Band 3 and NR Band 78. Figure 8-1 shows a potentially
problematic case, where the IM products fall across the used LTE downlink. Figure 8-2
shows a non-problematic case, where the IM products fall into unused spectrum.
Furthermore, for IM interference to be a potential problem, the NR UL, the LTE UL and the
LTE DL all need to be transmitting at the same time. The probability of this happening may
be low. Finally, if interference ends up impacting performance, then MAC layer link
adaption works to mitigate the impact.

Figure 8-1 - Example of Frequencies with Potentially Problematic IM Interference

Figure 8-2 - Example of Frequencies with Non-Problematic IM

In summary, even if the risk is low, the operator may wish to avoid EN-DC combinations
that are marked as Single UL Allowed, when the specific frequencies being used pose an
IM risk. If this avoidance results in the exclusion of all the valid EN-DC combinations for a
particular LTE carrier, then that carrier should not be used as an anchor carrier.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 87 (179)
 5G Mobility and Traffic Management Guideline

8.1.5 Baseband Support for EN-DC

EN-DC requires that the LTE carrier is deployed using baseband hardware that supports
EN-DC, namely a baseband unit of the Ericsson Radio System (ERS) family (for example
5212, 5216, 6318, 6620, 6630). Older baseband units (for example DUS41) should be
upgraded to ERS or, where there is a mix of old and new baseband, the LTE anchor
carriers can be hosted by the ERS baseband nodes and the non-anchor carriers by the
older baseband.

8.1.6 Ericsson Spectrum Sharing (ESS)

With ESS, the LTE spectrum is dynamically shared with NR NSA and/or NR SA. However,
an LTE cell cannot be used as an anchor for an NR cell on the same frequency. This
excludes the ESS carrier from being used as an anchor for itself. The anchor cell must be
on another LTE frequency.

The ESS carrier can, however, be used as an anchor for some other NR carrier, for
example a mid-band NR carrier. If doing so, consider the limitations of an ESS carrier:

• In the current software revision, some LTE features cannot be used on an ESS carrier;
refer to the release notes for more detail.

• The ESS LTE carrier has lower capacity than a dedicated LTE carrier of the same
bandwidth.

These limitations impact the overall performance for the legacy LTE, EN-DC and NR SA
users on ESS carriers. If alternative anchor carriers are available, better overall
performance may be obtained by steering LTE traffic away from the ESS carrier. Doing so
is easier if the ESS carrier is not used as an anchor, because both EN-DC Triggered
Handover and Capability-Aware Idle Mode Control are more effective at moving traffic from
a non-anchor to an anchor than from one anchor to a better anchor.

For these reasons, even when the ESS carrier can be used as an anchor for another NR
NSA carrier, the operator may choose not to do so.

8.1.7 Other Considerations for Anchor Carrier Selection

In multi-layer LTE networks, the following points can also be considered when deciding
whether to allow a particular carrier to be used as an anchor.

• Load: To ensure the best possible performance for EN-DC users, it may be desirable
to avoid using a very heavily loaded LTE carrier as an EN-DC anchor.

• Coverage: To minimize reconfigurations due to LTE intra-frequency or inter-frequency

handovers, avoid using carriers that do not have contiguous coverage as anchor
carriers.

• UL capacity: To improve uplink performance, use carriers with a larger bandwidth (for
example 20 MHz rather than 5 MHz) as anchors

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 88 (179)
 5G Mobility and Traffic Management Guideline

8.2 Steering 5G UEs to an Anchor Carrier – NSA

If EN-DC is not deployed on all LTE carriers or if UEs do not support EN-DC on all the
deployed band combinations, then UEs may be served by LTE carriers which cannot
provide them with EN-DC service. To give these UEs access to EN-DC they must be
steered to an appropriate anchor carrier. This steering is best done selectively, so that UEs
that are not capable of EN-DC are not impacted. This section describes a strategy to
achieve this.

The strategy has five components, which can be implemented in various combinations,
depending on the required control. For example, it is possible to implement only those
components that control idle mode mobility, leaving connected mode mobility unchanged.

The components of the strategy are listed below, and illustrated in Figure 8-3:

5G_Idle_Go Push 5G UEs from non-anchor to anchor in idle mode

5G_Idle_Stay Discourage 5G UEs moving from anchor to non-anchor in idle mode

5G_Ho_Go Encourage 5G UEs to perform a handover from non-anchor to anchor, or

from anchor to a better anchor

5G_Cov_Stay Prevent or discourage 5G UEs from performing coverage-triggered

handover from anchor to non-anchor

5G_LB_Stay Prevent or discourage 5G UEs from performing IFLB-triggered handover

from anchor to non-anchor

Figure 8-3 – Strategy Components for Steering 5G UEs

All of these strategy components require a way to differentiate 5G UEs from non-5G UEs.
There are three possible differentiation mechanisms:

UE Capability The UE informs the eNodeB of its EN-DC capabilities and this, together
with NR subscription information, can be used to impact mobility behavior.

SPID Subscriber Profile ID for RAT/Frequency Priority

The SPID is a number from 1 to 256 which is set per subscriber in the
HSS. It is sent from the HSS to the MME and from there to the eNodeB
where it can be used to impact mobility behavior. One or more SPID
values can be used to differentiate 5G subscribers from non-5G
subscribers.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 89 (179)
 5G Mobility and Traffic Management Guideline

QCI Quality of Service Class Indicator

The QCI is a number from 1 to 255 which is set per subscriber and APN in
the HSS (by means of an additional ContextId per APN). It is sent from the
HSS to the MME and from there to the eNodeB where it can be used to
impact mobility behavior. One or more QCI values can be used to
differentiate 5G subscribers from non-5G subscribers.

In the strategies presented here, these mechanisms are used together with one or more of
the following eNodeB features to control mobility behavior:

BIC Basic Intelligent Connectivity

This feature provides the basic functionality needed for EN-DC. It also allows
control of load-triggered mobility based on whether the UE is EN-DC capable;
which is the functionality relevant here.

CAIMC Capability-Aware Idle Mode Control

This set of features encourage UEs to camp on frequencies which are EN-DC
capable. They do so by altering the idle mode reselection priorities at RRC
connection release, using the Idle Mode Mobility Control Information (IMMCI).

ENDCHO EN-DC Triggered Handover During Setup

Basic EN-DC Triggered Handover During Setup
EN-DC Triggered Handover During Connected Mode Mobility
These features provide the functionality to move a connected mode UE to a
cell that is suited, or better suited, to provide it with EN-DC.

STM Subscriber Triggered Mobility

This feature enables mobility behavior to be adapted based on the SPID value

MLSTM Multi-Layer Service-Triggered Mobility

This feature enables coverage-triggered mobility thresholds to be adapted at
the QCI and frequency relation level.

SSLM Service Specific Load Management

This feature enables load-triggered mobility behavior to be adapted based on
the QCI value

MCPC Mobility Control At Poor Coverage

This feature enables more flexible control of coverage-triggered mobility using
inner and outer search zones.

Table 8-1 describes how the differentiation mechanisms and features (blue cells) can be
combined to build a solution for each strategy component. Each blue cell represents a
possible solution for the strategy component; some strategy components have more than
one possible solution.
Table 8-1 – Solutions for Steering 5G UEs
Strategy Mechanism for Differentiating 5G UEs
Component UE Capability SPID QCI
5G_Idle_Go CAIMC STM -
5G_Idle_Stay CAIMC STM -
5G_Cov_Stay - STM & MCPC MLSTM
5G_HO_Go ENDCHO STM & MCPC MLSTM
5G_IFLB_Stay BIC STM SSLM

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 90 (179)
 5G Mobility and Traffic Management Guideline

Each of the possible solutions in Table 8-1 is described in detail in the following sections.
Solution descriptions which involve SPID or QCI assume that unique SPID or QCI values
are assigned for 5G subscribers. However, if this is not the case, Sections 8.4 and 8.5
provide details on how to do so.

8.2.1 Anchor Control Strategy – 5G_Idle_Go and 5G_Idle_Stay

This section presents solutions for the 5G_Idle_Go and 5G_Idle_Stay strategies. Their
purpose is to push 5G UEs from a non-anchor to an anchor in idle mode (5G_Idle_Go),
and to discourage 5G UEs from moving from an anchor carrier to a non-anchor carrier in
idle mode (5G_Idle_Stay). These two strategies are implemented together in a single
5G_Idle strategy. Two solutions for the 5G_Idle strategy are described here, as shown in
Table 8-2. Both solutions impact only 5G UEs.
Table 8-2 – Solutions for 5G_Idle
Solution Mechanism for Features Comments
Number Differentiating Used
5G Subscribers
1 UE Capability CAIMC This is the simplest solution and the easiest to
implement. It uses the CAIMC features in the
eNodeB to modify the idle mode cell reselection
priorities for 5G subscribers. The modified priorities
are determined by the features, based on the pre-
existing priorities, the EN-DC capability of the UE,
and the EN-DC capability of the potential target
frequencies. This makes CAIMC a good solution
when some UEs do not support all deployed band
combinations. CAIMC (baseband node version)
can use hit rate statistics to make the solution more
coverage aware. Also, since CAIMC differentiates
5G subscribers based on UE capability, it is not
necessary to configure subscriber differentiation
information in the core network.
2 SPID STM This solution uses the STM feature in the eNodeB
to modify the idle mode reselection priorities for 5G
subscribers. The modified priorities are configured
manually, giving increased control. 5G subscribers
are differentiated using SPID, which must be
defined in the core network. UE EN-DC capability
is not considered by this solution, so it is more
appropriate when only a single EN-DC band
combination is implemented.

Both CAIMC and STM work by overriding the idle mode reselection priorities sent in the
SIB messages. However, these features do not override the thresholds associated with
priority-based reselection. For both solutions, it is therefore important to check that the
following thresholds have appropriate settings:

• EUtranCellFDD/TDD.sib3.sNonIntraSearch – serving cell threshold for starting

measurements on a lower priority frequency

• EUtranCellFDD/TDD.threshServingLow – serving cell threshold for reselection

towards a lower priority frequency.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 91 (179)
 5G Mobility and Traffic Management Guideline

• EUtranFreqRelation.threshXLow – target cell threshold for reselection to a lower

priority frequency.

• EUtranFreqRelation.threshXHigh – neighbor cell threshold for reselecting

towards a higher priority frequency

8.2.1.1 5G_Idle Solution Based on CAIMC (Solution 1)

The features Capability-Aware Idle Mode Control (for baseband nodes) and Basic
Capability-Aware Idle Mode Control (for DU nodes) encourage EN-DC capable UEs to
camp on a frequency which they can use for EN-DC. They do so by altering the cell
reselection priorities used by the UE to reselect between frequencies in idle mode. These
features can therefore be used to provide a solution for the 5G_Idle_Go and 5G_Idle_Stay
strategies. This section describes how. It assumes the reader is familiar with the
functionality of CAIMC; as described in Sections 9.2.9 and 9.2.10.

The first step when considering an anchor carrier management solution is to assess
whether a solution is actually required. Consider the example in Figure 8-4. While it may
not reflect the network being considered, this example introduces conceptual tools which
can be applied to other cases.

Figure 8-4 – EN-DC Service Availability Given Various Anchor Configurations

In this example, there are two LTE coverage layers on low band frequencies (LLow1 and
LLow2) and an LTE capacity layer on a higher band frequency (LHi). The two coverage
layers have equal cell reselection priority (6) and the capacity layer has a higher priority (7).
This “priority carrier configuration” is explained in the LTE Mobility and Traffic Management
Guideline; it pushes UEs towards the capacity layer in idle mode. UEs which are within the
coverage of LHi (A and B) will camp on it, while UEs that are not (C, D, E and F) will be
distributed between LLow1 and LLow2 according to signal strength and load balance.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 92 (179)
 5G Mobility and Traffic Management Guideline

The example shows four possibilities for anchor carrier configuration, and for each
configuration it shows where the existing priority carrier configuration will place the UEs.
Two types of UEs are shown; the orange UEs support EN-DC and the grey UEs don’t. The
existing mobility configuration does not differentiate between them.

High-Band Anchor
The only UE which is both capable of EN-DC and within coverage of the EN-DC
anchor carrier is UE A. As it is already placed on LHi by the existing priority settings,
a 5G_Idle solution is not needed.

Low-Band Anchor
UEs A, C and E are all EN-DC capable and are within coverage of the EN-DC
anchor carrier. However, only UE E has access to EN-DC with the existing priority
settings. UEs A and C are camped on carriers which do not support EN-DC. In this
case a 5G_Idle solution is needed.

Low- and High-Band Anchors

UEs A, C and E are all EN-DC capable and are within coverage of an EN-DC anchor
carrier. However, UE C is camped on LLow2 and so does not have access to EN-
DC. Once again, a 5G_Idle solution is needed.

All Anchors
In this case EN-DC capable UEs always have access to EN-DC and no 5G_Idle
solution is needed, assuming that all the UEs support a relevant band combination
on all LTE carriers. If this assumption is not appropriate, then a 5G_Idle Solution is
needed.

The impact of the CAIMC solution on the “Low Band Anchor” case is shown in Figure 8-5.
CAIMC has moved UEs A and C to LLow1, where they can obtain EN-DC service. Non
EN-DC capable UEs (B, D and F) have not been impacted.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 93 (179)
 5G Mobility and Traffic Management Guideline

Figure 8-5 – CAIMC Solution for Low Band Anchor Case

The impact of the CAIMC solution on the “Low and High Band Anchors” case is shown in
Figure 8-6. In this figure an additional aspect is shown, namely the EN-DC band
combinations supported by the UE. Three cases are considered: support for only
LLow1+NR1 (orange), support for only LHi+NR2 (purple), and support for both (orange and
purple). UEs which do not support EN-DC are not shown in this figure.

Under the legacy behavior, UEs C, D, E, F and J end up on carriers which they cannot use
for EN-DC. When the CAIMC solution is applied, UEs C, D and F are moved to carriers
which they can use for EN-DC. UEs E and J remain without EN-DC because they are not
within coverage of LHi, which is the only EN-DC anchor they support.

UE A is shown on LHi. However, it is capable of EN-DC on both LHi and LLow1, so CAIMC
could place it on either frequency, depending on which is higher prioritized. The priority is
decided by CAIMC based on either hit rate or EN-DC capable cell count, as described in
9.2.9. Which frequency is actually prioritized depends on factors such as: the number of
EN-DC capable cells on each frequency, the amount of cell overlap and the distribution of
UEs, both geographically and amongst the network layers. Note that CAIMC always gives
the serving frequency the highest priority if the UE and cell combination is EN-DC capable.
This makes the CAIMC solution “sticky”; once the UE is on an appropriate EN-DC capable
frequency, the priorities assigned by CAIMC will aim to keep the UE on that frequency.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 94 (179)
 5G Mobility and Traffic Management Guideline

Figure 8-6 – CAIMC Solution for Low and High Band Anchor Case

These examples show that anchor carrier management is a complex and multi-dimensional
problem, impacted by cell capability, UE capability, layer configuration, coverage and the
existing mobility strategy. The CAIMC solution for 5G_Idle considers all of these
dimensions to determine the required frequency priorities in an automated way.

To configure the CAIMC solution for 5G_Idle:

• Ensure the license key is installed in the node and set

FeatureState=CXC4012371.featureState = ACTIVATED

• For CAIMC to consider a cell as EN-DC capable, the feature Basic Intelligent
Connectivity must be activated on the cell’s eNodeB. This applies to both the eNodeB
on which CAIMC is implemented and other eNodeBs. Also, the
endcAllowedPlmnList must be configured.

• To exchange the EN-DC capability of cells between eNodeBs, both eNodeBs must be
Ericsson and an X2 link is required. To allow the automatic creation of the appropriate
X2 links and cell relations, activate the feature Automated Neighbor Relations.

• If the feature Subscriber Triggered Mobility is active, and CAIMC is to override it, set
RATFreqPrio.ueCapPrioAllowed = true on any RATFreqPrio MOs whose
spidList includes SPID values used for 5G subscribers.

• If independent control of t320 is required for CAIMC (and override the value in Rrc),
create the UePolicyOptimization MO and set its t320 attribute as required.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 95 (179)
 5G Mobility and Traffic Management Guideline

• For CAIMC to consider hit rates for frequency ranking, activate one of the following
features: Best Neighbor Relations for Intra-LTE Load Management (BNR) or Cell
Sleep Mode (CSM).

Note that CAIMC considers UE EN-DC band combination only on baseband nodes (where
the feature Capability Aware Idle Mode Control is used). On DU nodes, the feature Basic
Capability Aware Idle Mode Control is used, and this does not consider UE EN-DC band
combination capability.

Note also that the hit rate used by CAIMC is impacted by the measurement report settings
used by BNR or CSM. For example, for BNR to measure a “hit” the A5 IFLB thresholds 1
and 2, including any frequency specific offsets, must be satisfied. CSM, on the other hand,
uses the ReportStrongestCells measurement, which does not have associated signal
strength thresholds. The measured hit rate is also impacted by the distribution of UEs
amongst the layers. For example, if the idle mode or load balancing configuration has
already moved a large proportion of UEs to a particular frequency, then the hit rate towards
that frequency will be artificially low.

8.2.1.2 5G_Idle Solution Based on SPID and STM (Solution 2)

This solution uses the feature Subscriber Triggered Mobility (STM) to implement the
5G_Idle_Go and 5G_Idle_Stay strategies. In this solution, 5G UEs are differentiated from
non-5G users by their SPID value. Only the 5G UEs are impacted by this solution.

The feature Subscriber Triggered Mobility enables the configuration of special cell
reselection priority values for each SPID, which override the values that are broadcast in
System Information. When a UE transits from RRC_CONNECTED to RRC_IDLE mode,
STM checks whether the cell reselection priorities for the UE’s SPID differ from the
priorities broadcast in system information. If they differ, the RRC CONNECTION RELEASE
message from the eNodeB to the UE includes a list of dedicated cell reselection priorities.
These dedicated priorities override the priorities broadcast in the system information for a
time set by the parameter RATFreqPrio.t320.

Note that the cell reselection priorities are configured differently in system information
versus STM:

• In system information the priorities are configured per EUtranFreqRelation, which

means they can be set differently for each combination of source cell and target
frequency.

• In STM the priorities are configured per frequency, for the entire eNodeB. This means
that all the relations pointing to a given frequency, from all cells in the eNodeB, have
the same priority. With STM, it is therefore not possible to configure a “relative” cell
reselection strategy, where the priorities depend on the cell on which the UE is
camped; for example the “Sticky Carrier” configuration described in the LTE Mobility
and Traffic Management Guideline.

Furthermore 3GPP 36.304 states that “If priorities are provided in dedicated signaling, the
UE shall ignore all the priorities provided in system information”.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 96 (179)
 5G Mobility and Traffic Management Guideline

To ensure complete control over prioritization, configure STM with

cellReselectionPriority values for all frequencies on all RATs (LTE, WCDMA and
GSM) that the UE should consider for cell reselection. This is done with the structures
underlying freqPrioListEUTRA, freqPrioListUTRA, and
freqGroupPrioListGERAN.

Even when STM is used, reselection from one frequency to another still requires an
EUtranFreqRelation to be present between the source cell and the target frequency. If,
in a given network deployment, some relations have not been defined (for example to
control mobility paths or to reduce complexity) then reselection cannot occur. For any
desired reselection paths, relations must therefore be created if missing.

To illustrate this solution, consider the following network example:

• The operator has two different types of 5G subscribers and these are identified by
SPID values 5 and 20

• Three LTE frequencies:

– earfcn: 1350, the preferred anchor frequency

– earfcn: 6300, the secondary anchor frequency

– earfcn: 3750, non-anchor frequency to be selected only if the anchor frequencies

are not good enough

• One UTRAN frequency:

– arfcn: 10638, to be assigned with lower priority respect to LTE layers

The solution can be implemented with the following configuration steps:

1 Assign a SPID value for 5G subscribers in the HSS (see 8.4). In this example, the two
5G subscriber groups are assigned SPID=5 and SPID=20.
2 Create a RATFreqPrio object in the MO SubscriberProfileID[0 to 8]. In this
example RATFreqPrio[0] is created.

3 Include the 5G SPID values (for example SPID=5 and 20) in the
RATFreqPrio.spidList[0 to 20] attribute. A given SPID value can only be included
in one RATFreqPrio MO.

4 Set the timer RATFreqPrio.t320 = 180 (180 minutes, the maximum). The dedicated
frequency prioritization is valid for 180 minutes after the UE switches from connected
to idle mode. Given the frequent connection establishments triggered by typical
devices, this is more than enough to guarantee a stable prioritization.
5 Configure the structured attribute RATFreqPrio.freqPrioListEUTRA [0 to 24]. For
each frequency it is possible to define several attributes to control different mobility
rules (idle mode, connected mode, load balancing, etc.) This solution involves only two
of these attributes: arfcnValueEUtranDl which identifies the frequency and
cellReselectionPriority which sets the priority.
Assign the highest priority to the preferred anchor layer:
freqPrioListEUTRA[0].arfcnValueEUtranDl = 1350

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 97 (179)
 5G Mobility and Traffic Management Guideline

freqPrioListEUTRA[0].cellReselectionPriority = 7
Assign a lower priority to the secondary anchor frequency:
freqPrioListEUTRA[1].arfcnValueEUtranDl = 6300
freqPrioListEUTRA[1].cellReselectionPriority = 6
Assign an even lower priority to the non-anchor frequency:
freqPrioListEUTRA[2].arfcnValueEUtranDl = 3750
freqPrioListEUTRA[2].cellReselectionPriority = 5

6 Configure the structured attribute RATFreqPrio.freqPrioListUTRA [0 to 64] to

define the priority of UTRAN layers. It is possible to configure up to 65 frequencies.
Assign priority 3, lower than the LTE layers, to the UTRAN frequency:
freqPrioListUTRA[0].arfcnValueUtranDl = 10638
freqPrioListUTRA[0].cellReselectionPriority = 3

This example is illustrated in Figure 8-7.

Figure 8-7 – Example Solution for 5G_Idle_Go and 5G_Idle_Stay

8.2.2 Anchor Control Strategy – 5G_Cov_Stay

This section presents solutions for the 5G_Cov_Stay strategy. Its purpose is to prevent or
discourage 5G UEs from performing coverage-triggered handovers from an anchor carrier
to a non-anchor carrier.

Three possible solutions are described here, as shown in Table 8-3.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 98 (179)
 5G Mobility and Traffic Management Guideline

Table 8-3 – Solutions for 5G_Cov_Stay

Solution Mechanism for Features Comments
Number Differentiating Used
5G Subscribers
1 SPID STM This SPID-based solution completely prevents
handover from anchor carriers to non-anchor
carriers. It is a simple solution, but it is not suitable
for anchor carriers which have coverage holes.
2 SPID STM, This SPID-based solution uses the MCPC feature to
MCPC create two search zones. In the inner search zone,
UEs search for suitable coverage from anchor
carriers only. In the outer search zone UEs search
for suitable coverage from all carriers. This two-
stage search helps UEs to remain on an anchor
carrier. This solution does not completely prevent
handover to non-anchor carriers, so it can be used
even on anchor carriers with coverage holes.
However, it is more complex than Solution 1.
3 QCI MLSTM This QCI-based solution uses the MLSTM feature to
introduce offsets to delay the handover from anchor
carriers to non-anchor carriers, so that handover
amongst anchor carriers is given priority. This is a
very simple solution, and it can be used even on
anchor carriers with coverage holes. But it requires
the use of QCI as a differentiation mechanism.

In all three solutions, only 5G subscribers are impacted. The behavior of non-5G
subscribers is not impacted.

8.2.2.1 5G_Cov_Stay Solutions Based on SPID and STM (Solutions 1 and 2)

This section presents solutions for the 5G_Cov_Stay strategy, based on the feature
Subscriber Triggered Mobility (STM). They use SPID to differentiate 5G from non-5G
subscribers.

STM enables the connected mode frequency priorities (connectedModeMobilityPrio

and voicePrio) to be modified per frequency based on SPID, using the MO
RATFreqPrio. The values in RATFreqPrio override the values in
EUtranFreqRelation, which are normally used. This functionality can be used to modify
the coverage-triggered inter-frequency handover behavior to provide two possible
solutions; one which prevents handover of 5G UEs completely (Solution 1 in Table 8-3),
and another which discourages it (Solution 2 in Table 8-3).

Solution 1 – Prevent Handover

Coverage-triggered handover to non-anchor carriers is completely prevented for data-only

connections by setting freqPrioListEUTRA.connectedModeMobilityPrio = -1 on
the non-anchor frequencies. Optionally, handover is also completely prevented for VoLTE
connections, by setting freqPrioListEUTRA.voicePrio = -1. Handover to the anchor
frequencies is left unaffected, by leaving these two parameters at their default values
of -1000 for the anchor frequencies. This means these parameters are ignored, and the
values in EUtranFreqRelation are used, as normal.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 99 (179)
 5G Mobility and Traffic Management Guideline

To prevent this solution from impacting idle mode mobility, set

cellReselectionPriority = -1000 in all freqPrioListEUTRA,
freqPrioListUTRA and freqGroupPrioListGERAN structures.

These settings are summarized in Figure 8-8, for the same example as used in 8.2.1.1.

Figure 8-8 – SPID-Based Solution for 5G_Cov_Stay (Prevent Handover)

Configuration for this 5G_Cov_Stay solution is very simple if the 5G_Idle_Go and
5G_Idle_Stay solutions (described in Section 8.2.1.1) are already implemented. The only
additional change is to set connectedModeMobilityPrio = -1 on the non-anchor
frequencies.

This solution is not recommended for anchor carriers which have coverage holes; that is if
the coverage-triggered handover from anchor to non-anchor is required to maintain
service. In this case Solution 2 is recommended.

Solution 2 – Discourage Handover

This solution is similar to Solution 1, except that coverage-triggered handover to non-

anchor carriers is discouraged rather than prevented. This solution is preferable if on
anchor carriers with coverage holes.

In this solution, the feature Mobility Control at Poor Coverage is used to create two search
zones in anchor cells; an inner and an outer search zone. The outer search zone is
equivalent to the pre-existing single search zone. The inner search zone is a new search
area, which is used only by 5G UEs to search for better coverage from other anchor
carriers.

The search zones of the anchor cells are shown in Figure 8-9. Referring to the diagram on
the right, as 5G UEs move out of good coverage (green) they first enter the inner search
zone (yellow), where they search for coverage from anchor carriers only. If suitable
coverage is not found amongst the anchor carriers, then the 5G UEs eventually enter the
outer search zone (red) where they search for coverage from all LTE carriers and from
other RATs. Non-5G UEs are not impacted by this solution; they search for coverage from
all carriers in the outer search zone only.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 100 (179)
 5G Mobility and Traffic Management Guideline

Figure 8-9 – SPID-Based Solution for 5G_Cov_Stay (Discourage Handover)

Inner and outer search zones are created for RSRP by setting the attribute
a2OuterSearchThrRsrpOffset to a value lower than 0. For example, setting this
parameter to -3 dB creates an outer search zone which begins 3 dB below the inner search
zone, which is set by a1a2SearchThresholdRsrp. RSRP is the recommended trigger
quantity, for the reasons outlined in the LTE Mobility and Traffic Management Guideline.
However, RSRQ can also be used, in which case the search zones for RSRP and RSRQ
function independently.

To determine which frequencies are searched in the inner and outer search zones the
parameter lowPrioMeasThresh is used. This parameter is compared with
connectedModeMobilityPrio and voicePrio as follows:

• For UEs with only data connections:

If connectedModeMobilityPrio < lowPrioMeasThresh then the frequency is
searched in the outer search zone only; otherwise the frequency is searched in both
search zones.

• For UEs with VoLTE connections:

If voicePrio < lowPrioMeasThresh then the frequency is searched in the outer
search zone only; otherwise the frequency is searched in both search zones.

To set the connectedModeMobilityPrio and voicePrio values differently for 5G

users and non-5G users, the feature Subscriber Triggered Mobility is used:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 101 (179)
 5G Mobility and Traffic Management Guideline

• Non-5G subscribers, use the values that are set in the normal way in the MO
EUtranFreqRelation

• 5G subscribers use the values that are set per frequency using the feature Subscriber
Triggered Mobility, in the MO RATFreqPrio.

Example settings for this solution are provided in Table 8-4 and Figure 8-10; building on
the example given for the idle mode solution in 8.2.1.1.
Table 8-4 – Settings for SPID-Based Solution for 5G_Cov_Stay (Discourage Handover)
MO Parameter Value Comment
ReportConfigSearch a1a2SearchThresholdRsrp -115 Assuming previous value
was -118 dBm, raise the value
by 3dB to allow the inner
search zone to begin 3 dB
earlier.
ReportConfigSearch a2OuterSearchThrRsrpOffset -3 Set outer search zone
boundary 3dB below inner
search zone boundary (at the
previous search zone level of -
118 dBm).
UeMeasControl lowPrioMeasThresh 5 Frequencies with a priority less
than this value are searched in
the outer search zone only.
EUtranFreqRelation connectedModeMobilityPrio 4 For non-5G UEs, all LTE
frequencies are searched in
the outer search zone only.
EUtranFreqRelation voicePrio 4 For non-5G UEs, all LTE
frequencies are searched in
the outer search zone only.
UtranFreqRelation connectedModeMobilityPrio 3 For non-5G UEs, all UTRAN
frequencies are searched in
the outer search zone only.
UtranFreqRelation voicePrio 3 For non-5G UEs, all UTRAN
frequencies are searched in
the outer search zone only.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 102 (179)
 5G Mobility and Traffic Management Guideline

Figure 8-10 – Settings for SPID-Based Solution for 5G_Cov_Stay (5G UEs)

The solution presented above assumes that there is more than one anchor carrier in the
network. If there is only a single anchor carrier, then a different solution is needed. The
solution is then to delay the handover from the anchor carrier to the non-anchor carrier(s)
by setting the outer search zone lower than the pre-existing search zone. This is shown in
Figure 8-11; once again, these search zones are implemented in anchor cells only.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 103 (179)
 5G Mobility and Traffic Management Guideline

Figure 8-11 – SPID Based Solution for 5G_Cov_Stay (Single Anchor Case)

The solutions presented here assume that the pre-existing mobility strategy uses only a
single search zone. If the pre-existing mobility strategy already uses inner and outer search
zones, then the solutions presented here need to be adapted to suit.

8.2.2.2 5G_Cov_Stay Solution Based on QCI and MLSTM (Solution 3)

The previous two solutions for 5G_Cov_Stay used SPID to differentiate 5G subscribers
from non-5G subscribers. This solution uses QCI to differentiate, along with the feature
Multi-Layer Service-Triggered Mobility (MLSTM) allowing more flexible control.

This solution assumes that dedicated QCI values are assigned for 5G subscribers, as
described in Section 8.5.

MLSTM provides a way to modify the search zone thresholds (Event A2) and the inter
frequency handover thresholds (Event A5) per QCI, cell and frequency relation.

In this solution, for example, assume 5G subscribers are assigned QCI 25, and handover
to non-anchor carriers is to be delayed by 3 dB relative to handover to anchor carriers. This
is achieved by the configuration shown in Figure 8-12.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 104 (179)
 5G Mobility and Traffic Management Guideline

Figure 8-12 – QCI-Based Solution for 5G_Cov_Stay

With this solution it is possible to differentiate mobility per service, not just per subscriber.
This is an advantage if 5G subscribers are allowed to activate dual connectivity only for a
specific QCI (for example allowed for QCI 9 but not for QCI 6 and 7). In these cases, it is
convenient to tailor the solution per QCI. If different QCIs have different offsets, then the
offset used is the one from the QCI with the highest
UeMeasControl.prioOffsetPerQci.

8.2.3 Anchor Control Strategy – 5G_HO_Go

The section presents solutions for the 5G_HO_Go strategy. The purpose of this strategy is
to encourage 5G UEs to move from a non-anchor carrier to an anchor carrier, or from an
anchor to a better anchor, in connected mode. This strategy is not always required
because devices typically switch back and forth between idle and connected modes
frequently, and when in idle mode they can be pushed to an anchor carrier with the
5G_Idle_Go strategy described in Section 8.2.1. However, for some specific traffic cases
(long data sessions, benchmarking surveys, demos, etc.) this connected mode strategy
can be useful to speed up the movement of UEs to the anchor carrier.

Three solutions are available, as shown in Table 8-5.

Table 8-5 – Solutions for 5G_HO_Go
Solution Mechanism for Features Comments
Number Differentiating 5G Used
Subscribers
1 UE Capability ENDCHO This solution uses the EN-DC triggered
handover features to move the UE to an LTE cell
that is better suited to provide it with EN-DC. It is
the only solution which considers UE EN-DC
band combination support. It is also the simplest
solution as it does not require SPID or QCI
configuration.
2 QCI MLSTM This QCI-based solution uses the MLSTM
feature to introduce offsets to the measurement
and handover thresholds for 5G UEs. The offsets
cause UEs to hand over sooner. This is a
relatively simple solution, but it requires the use
of QCI as the differentiation mechanism.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 105 (179)
 5G Mobility and Traffic Management Guideline

Solution Mechanism for Features Comments

Number Differentiating 5G Used
Subscribers
3 SPID STM, This SPID-based solution uses the MCPC
MCPC feature to create two search zones. The inner
search zone is used to push 5G UEs from non-
anchor to anchor carriers. The outer search zone
is used for normal coverage-triggered handovers
for non-5G UEs. This is a more complex
solution, but it does not require QCI.

8.2.3.1 5G_HO_Go Solution Based on ENDCHO (Solution 1)

This section presents a solution for the 5G_HO_Go strategy, based on the EN-DC
triggered handover (ENDCHO) features. ENDCHO is used to move a connected-mode UE
to a cell which is better suited to provide it with EN-DC; that is an anchor or a better
anchor.

The functioning and configuration of ENDCHO are described in detail in Section 9.2.13. In
addition to the information in that section, note the following points for configuring the
5G-HO-Go strategy:

• Ensure a GUtranFreqRelation exists for each NR frequency to be measured by

ENDCHO and set endcB1MeasPriority to indicate the priorities for measurement.

– For example, to ensure that the UE searches for frequency NR1 before frequency
NR2, set endcB1MeasPriority to 7 for NR1 and 5 for NR2 (not 6). This ensures
that NR1 is sent in the first RRC reconfiguration message, and NR2 in the second.

– For example, to ensure that the UE searches for frequency NR1 before frequency
NR2, set endcB1MeasPriority to 7 for NR1 and 5 for NR2 (not 6). This ensures
that NR1 is sent in the first RRC reconfiguration message, and NR2 in the second.

• Set maxMeasB1Endc to control the number of NR frequencies to be included in each

RRC reconfiguration message. The default value is 3.

• Depending on the pre-existing mobility strategy and the use of ANR, some or all of the
required LTE relations may already be in place. However, confirm that
EUtranFreqRelation and EUtranCellRelation MOs are defined for any
potential targets.

• Set EUtranFreqRelation.endcHoFreqPriority to indicate the measurement

priority for the LTE frequencies. This determines which LTE frequencies are included in
the RRC reconfiguration messages if not all can be included.

• Set UeMeasControl.endcMeasTime and

ReportConfigB1GUtra.timeToTriggerB1 to obtain the desired measurement
time for each LTE priority group.

• Set UeMeasControl.endcMeasRestartTime to control if periodical B1

measurement periods should be used.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 106 (179)
 5G Mobility and Traffic Management Guideline

• To set up the A5 measurement, ENDCHO uses the parameters described in Section

10.2.6.

8.2.3.2 5G_HO_Go Solution Based on QCI and MLSTM (Solution 2)

This section presents a solution for the 5G_HO_Go strategy, based on QCI and the feature
Multi-Layer Service-Triggered Mobility (MLSTM).

Coverage-triggered inter-frequency handover is normally used to handle poor serving cell

coverage. However, in this solution it is used to proactively push 5G UEs from a non-
anchor frequency to an anchor frequency, even when serving cell coverage is good. To do
this, the feature Multi-Layer Service-Triggered Mobility (MLSTM) is used to offset the A2
and A5 thresholds for the QCIs corresponding to 5G users. The offsets cause the inter-
frequency measurements and handovers to be triggered earlier. This solution assumes that
dedicated QCI values are assigned for 5G subscribers, as described in Section 8.5.

For example, assume 5G subscribers are assigned QCI 25, and handover from non-anchor
to anchor carriers is advanced by 100 dB (the maximum possible). This is achieved by the
configuration shown in Figure 8-13. The a1a2ThrRsrpQciOffset ensures that
measurements are started even when in good serving cell coverage, and the
a5Thr1RsrpFreqQciOffset ensures that the handover is triggered even when in good
serving cell coverage.

Figure 8-13 – QCI-Based Solution for 5G_HO_Go

Note that A5 Threshold 2, which specifies the required target cell signal strength, is not
modified by this solution. Assuming that this threshold is set at an appropriate value, it
ensures that handover occurs only when the target cell signal strength is acceptable. This
solution can therefore be used even when the anchor carrier has coverage holes.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 107 (179)
 5G Mobility and Traffic Management Guideline

8.2.3.3 5G_HO_Go Solution Based on SPID, STM and MCPC (Solution 3)

This section presents a solution for the 5G_HO_Go strategy, based on the features
Subscriber Triggered Mobility (STM) and Mobility Control at Poor Coverage (MCPC). It
uses SPID to differentiate 5G from non-5G subscribers.

This solution is similar to Solution 2, the SPID-based solution for 5G_Cov_Stay (presented
in Section 8.2.2.1). Both solutions use MCPC to create inner and outer search zones,
which are used differently by 5G and non-5G subscribers. Furthermore, both solutions use
STM, to differentiate 5G and non-5G subscribers based on SPID. The difference between
the two solutions is how the search zones are used.

The search zones in this solution are implemented in the non-anchor cells, as shown in
Figure 8-14. Referring to the diagram on the right, the good coverage zone (green) is
configured to be extremely small, so that all UEs are either in the inner search zone
(yellow) or outer search zone (red). In the inner search zone, 5G UEs search for coverage
from anchor frequencies but non-5G UEs do not search. In the outer search zone, all UEs
search for coverage from all potential target carriers (LTE and other RATs).

Figure 8-14 – SPID-Based Solution for 5G_HO_Go

The boundary between the good coverage zone and the inner search zone is determined
by the parameter a1a2SearchThresholdRsrp, which is set to its maximum value of -44
dBm in this solution (to make the good coverage zone extremely small). The boundary
between the inner search zone and the outer search zone is aligned with the pre-existing
search zone boundary, for example -118 dBm. This is achieved by the following settings:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 108 (179)
 5G Mobility and Traffic Management Guideline

Inner-Outer Search Zone Boundary

= a1a2SearchThresholdRsrp + a2OuterSearchThrRsrpOffset
= -44 dBm + (-74) dBm = -118 dBm

To ensure that handovers can be triggered in both inner and outer search zones,
ReportConfigA5.a5Threshold1Rsrp is set equal to
ReportConfigSearch.a1a2SearchThresholdRsrp, namely -44 dBm. This high
setting ensures that the source cell threshold for A5 triggering is always satisfied, so that
the UE sends the A5 report as soon as the target cell threshold (a5Threshold2Rsrp) is
met. The target cell threshold is left at the pre-existing value.

Apart from these parameters, the configuration of 5G_HO_Go is identical to that of

5G_Cov_Stay; refer to Table 8-4 and Figure 8-10 for details.

8.2.4 Anchor Control Strategy – 5G_LB_Stay

This section presents solutions for the 5G_LB_Stay strategy. The purpose of this strategy
is to prevent 5G UEs from performing load-triggered handover from an anchor carrier to a
non-anchor carrier. This has two benefits:

• It helps to ensure 5G UEs remain on a carrier which offers EN-DC capability.

• It limits the number of inter-frequency handovers performed by 5G UEs. This is

beneficial because, in the current release, each LTE handover results in the temporary
release of NR resources, even handovers where both the source and the target are
anchor carriers (refer to Section 6.6).

Three solutions are available, using different differentiation mechanisms and features, as
shown in Table 8-6.
Table 8-6 – Solutions for 5G_LB_Stay
Solution Mechanism Features Comments
Number for Used
Differentiating
5G
Subscribers
1 UE Capability BIC This feature uses the parameter
lbAllowedForEndcUe in the feature Basic
Intelligent Connectivity to prevent all load-
triggered handovers for EN-DC capable UEs.
2 SPID STM This SPID-based solution uses the feature
Subscriber Triggered Mobility to prevent load-
triggered handovers from anchor to non-anchor
carriers, or even between anchor carriers.
3 QCI SSLM This QCI-based solution uses the feature
Service Specific Load Management to prevent
load-triggered handovers at the frequency
relation level. Alternatively, the handovers can
be discouraged, but not prevented, by adjusting
A5 thresholds.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 109 (179)
 5G Mobility and Traffic Management Guideline

8.2.4.1 5G_LB_Stay Solution Based on UE Capability and BIC (Solution 1)

This section presents a solution for the 5G_LB_Stay strategy, based on a single
parameter, LoadBalancingFunction.lbAllowedForEndcUe. This parameter is
provided by the feature Basic Intelligent Connectivity (BIC).

By setting lbAllowedForEndcUe = false, all load management actions, including Inter

Frequency Load Balancing and IRAT Offload, are prevented for EN-DC capable UEs which
do not have an SN Terminated Split Bearer set up. Those UEs which do have an SN
terminated bearer set up are excluded from all load management actions anyway,
regardless of how this parameter is set (see Section 6.7).

This solution is best when the number of 5G UEs is low compared with the number of non-
5G UEs, so that 5G UEs can be safely ignored for the purposes of load management,
without risking congestion.

8.2.4.2 5G_LB_Stay Solution Based on SPID and STM (Solution 2)

This section presents a solution for the 5G_LB_Stay strategy, based on the feature
Subscriber Triggered Mobility (STM). STM allows load management actions to be disabled
for each target frequency, using SPID to differentiate between 5G and non-5G subscribers.
This solution is more flexible than the solution based on UE Capability and BIC, which does
not provide control at the frequency level.

The solution can be considered an extension of the SPID based solution for 5G_Cov_Stay.
Example settings are provided in Figure 8-15; building on the example given for the idle
mode solution in Section 8.2.1.2.

In this example load-triggered mobility towards non-anchor frequencies and other RATs is
prevented, but load-triggered mobility towards anchor frequencies is allowed. Note,
however, that each LTE handover results in the temporary release of NR resources, can
impact end user experience. To avoid this impact, this solution can be modified to disable
load-triggered mobility for all target frequencies for 5G users.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 110 (179)
 5G Mobility and Traffic Management Guideline

Figure 8-15 – 5G_LB_Stay Solution Based on SPID and STM

8.2.4.3 5G_LB_Stay Solution Based on QCI and SSLM (Solution 3)

This section presents a solution for the 5G_LB_Stay strategy, based on the feature Service
Specific Load Management (SSLM). It uses QCI to differentiate 5G from non-5G
subscribers.

SSLM enhances control of the UE selection process for Inter-Frequency Load Balancing,
Inter-RAT Offload to WCDMA and Inter-Frequency Offload.

This solution offers two advantages over the solution based on SPID and Subscriber
Triggered Mobility:

• UEs are differentiated by QCI, which allows the active service to be taken into account,
not just the 5G subscription

• As an alternative to completely preventing load-triggered mobility, it is possible to

merely discourage handover, by using offsets to modify the target cell handover
threshold (A5 Threshold 2).

The MOs and parameters used for implementing this solution are presented in Figure 8-16.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 111 (179)
 5G Mobility and Traffic Management Guideline

Figure 8-16 – 5G_LB_Stay Solution Based on QCI and SSLM

8.2.5 Overall Anchor Carrier Management Example

The previous sections presented solutions for each individual anchor control strategy,
using a variety of differentiation mechanisms and features.

This section presents an overall solution which is based on the UE capability aware
features only, namely Basic Intelligent Connectivity (BIC), the EN-DC triggered handover
features (ENDCHO) and Capability-Aware Idle Mode Control (CAIMC). Solutions which
use the UE capability aware features are recommended because the alternative solutions
involving SPID or QCI are more complex to configure. In addition, capability aware
solutions adjust to individual UE capabilities or changes in the deployed NSA network,
rather than being statically configured for a particular UE subscription.

The overall solution is as follows:

• 5G_Idle_Go The feature CAIMC is used to push 5G UEs from a non-anchor to an

anchor in idle mode.

• 5G_Idle_Stay The feature CAIMC is used to discourage 5G UEs moving from an

anchor to a non-anchor in idle mode

• 5G_Ho_Go The ENDCHO features are used to move 5G UEs in connected

mode from a non-anchor to an anchor, of from an anchor to better
anchor

• 5G_LB_Stay The feature BIC is used to prevent or discourage 5G UEs from

performing IFLB-triggered handover from an anchor to a non-anchor.

The interaction between the features BIC, ENDCHO and CAIMC is shown at a high level in
Figure 8-17.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 112 (179)
 5G Mobility and Traffic Management Guideline

Figure 8-17 – Interaction between UE Capability-Aware Features

Notes for Figure 8-17:

1 When a connection is first set up, BIC and ENDCHO work in parallel to determine
whether to perform SN addition on the serving cell, perform handover to another LTE
cell which can provide EN-DC, or use LTE only.
2 If ENDCHO is performed (5G-HO-Go), the source eNodeB forwards the B1
measurement report to the target eNodeB, which then initiates SN addition on the
corresponding NR cell if it is configured for EN-DC.
3 BIC is also responsible for inhibiting load-triggered handover for EN-DC capable UEs
(5G-LB-Stay), which means the UE will stay on the serving cell until coverage-
triggered intra-frequency or inter-frequency handover occurs.
4 When the data transfer finishes and the inactivity timers expire (see Section 6.2.6),
CAIMC decides whether to override the cell reselection priorities provided in system
information with new, dedicated priorities when it releases the UE to idle mode (5G-
Idle-Stay and 5G-Idle-Go).

8.2.5.1 UE Capability Aware Features – Selection of Frequencies

The features BIC, ENDCHO and CAIMC all contain functionality to select frequencies,
considering the UE capability. However, they use somewhat different criteria. This section
summarizes the main differences.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 113 (179)
 5G Mobility and Traffic Management Guideline

• BIC configures B1 measurements for SN addition on the serving cell.

– The key criteria for selecting NR frequencies are:

• NR frequencies from band combinations supported for EN-DC by the UE

• GUtranFreqRelation.endcB1MeasPriority not equal to -1

– The priority for measuring an NR frequency is determined by

GUtranFreqRelation.endcB1MeasPriority.

• ENDCHO: configures both B1 and A5 to facilitate LTE handover to a cell the UE can
use for EN-DC.

– The key criteria for selecting NR and LTE frequency combinations are:

• The NR frequency cannot be used for EN-DC on the serving LTE cell (because
the UE does not support the required band combination)

• The LTE and NR frequency combination is supported by the UE for EN-DC

• GUtranFreqRelation.endcB1MeasPriority not equal to -1

• EUtranFreqRelation.endcHoFreqPriority not equal to -1

– The priority for including NR frequencies in the RRC message(s) is determined by

endcB1MeasPriority. The priority for including LTE frequencies, if not all
relevant frequencies can be included, is determined by endcHoFreqPriority.

• CAIMC: provides the UE with the IMMCI at connection release, to indicate the
frequencies and priorities for idle mode reselection.

– The key criteria for selecting frequencies are:

• UE supports at least one EN-DC band combination with the LTE frequency

• EUtranFreqRelation.cellReselectionPriority not equal to -1

• Frequency has at least one EN-DC capable cell

– Top priority is given to the serving cell frequency if the UE can use the serving cell
for EN-DC. Other frequencies are prioritized either on hit rate, or on EN-DC
capable cell count, or using
EUtranFreqRelation.cellReselectionPriority if all else is equal.

8.3 Steering non-5G UEs away from an Anchor Carrier

Steering non-5G UEs away from an LTE anchor carrier, is not normally necessary because
an anchor carrier may be used by both 5G capable and non-5G capable UEs. So, in most
cases, the pre-existing mobility strategy can be retained, and it continues to govern the
behavior of non-5G UEs and of 5G UEs not covered by one of the 5G strategy components
in Section 8.2.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 114 (179)
 5G Mobility and Traffic Management Guideline

However, there are valid reasons for steering non-5G UEs when EN-DC is deployed, for
example to prevent a low bandwidth anchor carrier from becoming overloaded. In this case
the baseline mobility configuration is used to steer the non-5G UEs as required. To prevent
5G UEs being impacted, the baseline strategy can be overridden with the desired 5G
strategy components in Section 8.2, namely: 5G_Idle_Stay, 5G_Cov_Stay and
5G_LB_Stay.

8.4 Configuring SPID for Anchor Carrier Control

Some of the solutions for anchor carrier control involve using the Subscriber Profile ID for
RAT/Frequency Priority (SPID) to differentiate between 5G and non-5G users. The SPID is
a number from 1 to 256 which is set per subscriber in the HSS. It is sent from the HSS to
the MME and from there to the eNodeB where it can be used to impact mobility behavior.
One or more SPID values can be used to differentiate 5G subscribers from non-5G
subscribers.

To use SPID, it must be configured in the HSS, the MME and the eNodeB. This section
explains how to do so.

8.4.1 Configuring SPID in the HSS

The HSS ESM Profile object contains information about the ESM User data.

The SPID associated with a subscriber profile is specified via the attribute
hss-EsmRatFreqSelPriorId within the c class.

To use SPID to differentiate 5G subscribers from non-5G subscribers, they must be

assigned different SPID values. If SPID is already in use for other purposes, then to retain
full differentiation a new 5G SPID value must be created for every existing SPID value. An
example is given in Figure 8-18.

Figure 8-18 – Duplicating SPID Values for 5G Introduction

For further information on this feature refer to the HSS Feature Description EPS Subscriber
Data Handling in ESM.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 115 (179)
 5G Mobility and Traffic Management Guideline

8.4.2 Configuring SPID in the MME

The MME receives SPID information from the HSS and forwards it to the eNodeB during
connection setup and S1 handover. The MME can overwrite the SPID values assigned by
the HSS, for specific IMSI number series. This is the recommended way to set the SPID for
incoming roamers, overwriting the values from their own HSS.

8.4.3 Configuring SPID in the eNodeB

The eNodeB receives the SPID for a UE from the MME during connection setup or another
eNodeB during handover. The SPID is then available to a number of features to impact
mobility, resource allocation and flexible counter functions. The features of relevance for
this guideline are Subscriber Triggered Mobility and Flexible Counters.

8.4.3.1 Subscriber Triggered Mobility

The feature Subscriber Triggered Mobility (STM) enables individual control of mobility
characteristics for a User Equipment (UE) based on SPID.

SPID is made accessible to STM through two MO classes, RATFreqPrio and

HoWhiteList. These MOs contain lists of SPID values that receive special treatment for
certain mobility functions.

RATFreqPrio is the MO relevant to this guideline. Up to 9 instances of RATFreqPrio

can be created. Each instance contains attributes and structures that control how mobility
is handled for the list of SPID values defined in that instance. The subset of structures and
attributes referred to in this guideline are shown in Figure 8-19.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 116 (179)
 5G Mobility and Traffic Management Guideline

Figure 8-19 – RATFreqPrio MO

8.5 Configuring QCI for 5G Users

Some of the solutions for anchor carrier control involve using the Quality of Service Class
Identifier (QCI) to differentiate between 5G and non-5G users. There are two options for
assigning QCI values for 5G users:

• Assign QCI in the HSS

• Remap QCI Using ASGH Framework

8.5.1 Assign QCI in the HSS

In this option, the QCI associated with 5G subscribers is specified in the HSS using an
additional ContextId of the current APN configuration.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 117 (179)
 5G Mobility and Traffic Management Guideline

8.5.2 Remap QCI Using ASGH Framework

In this option, rather than assigning 5G subscribers specific QCI values in the HSS, they
are instead assigned specific SPID values in the HSS. The Advanced Subscriber Group
Handling (ASGH) Framework in the eNodeB then uses the SPID values to offset the QCI
values for 5G users. Finally, these remapped QCI values can be used to modify mobility
behavior for 5G subscribers. This makes both SPID and QCI available for differentiating 5G
users, and improves the flexibility for adapting mobility behavior.

ASGH maps a connected UE into a specific profile (a subscriber group). It is possible to

define up to 6 subscriber groups (MO SubscriberGroupProfile[0..5]).

The mapping is done using four independent criteria, configured for each
SubscriberGroupProfile. A connected UE will be mapped into a subscriber group if
all of the following conditions are met:

• bearerTriggerList – The UE must have at least one combination of ARP and QCI
which matches an entry in the bearerTriggerList. The ARP and QCI values are
sent by the core network. In the bearerTriggerList, the value 0 indicates a match
for all ARP or QCI values. Up to 6 combinations of ARP and QCI can be included in the
list.

• spidTriggerList – The SPID of the UE must match one of the SPID values in the
spidTriggerList. Up to 6 SPID values can be included in the list. The value 0 in the
spidTriggerList matches UEs without any assigned SPID. If the
spidTriggerList is empty, the SPID condition is always fulfilled.

• customTriggerList – This list adds additional conditions, but by default this is not
used as customTriggerType is set to TRIGGER_NOT_USED by default.

• cellTriggerList – This list specifies the cellId(s) that the SubscriberGroupProfile

applies to. If the list is empty (default), then all cellId(s) are included.

If all four lists are empty, all UEs match. If no list is empty, UE must match at least one
value in each list.

Each trigger list is evaluated independently every time the bearer of a subscriber is set up,
modified, or released. If a subscriber fulfills more than one SubscriberGroupProfile,
only the SubscriberGroupProfile with the highest priority applies. The priority is
defined by the parameter SubscriberGroupProfile[x].profilePriority.

Once the UE is assigned to a specific profile group according the above criteria, some
parameters of the connection can be modified, including remapping the QCI 6, 7, 8 and 9
into an operator defined QCI. This is controlled by four SubscriberGroupProfile
parameters:

• qciOffsetForQCI6 = 0 [0, 4..250]

• qciOffsetForQCI7 = 0 [0, 3..250]

• qciOffsetForQCI8 = 0 [0, 2..250]

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 118 (179)
 5G Mobility and Traffic Management Guideline

• qciOffsetForQCI9 = 0 [0, 1..250]

Figure 8-20 and Figure 8-21 illustrate QCI mapping using ASGH. In this example, 5G
subscribers are assigned SPID values 5 and 20 in the HSS. For these subscribers QCI 9 is
remapped to QCI 20 by applying an offset of 11.

Figure 8-20 – Remapping QCI using SPID

An operator-defined QCI is created corresponding to the newly created QCI 20, copying
any parameters from QCI 9 which do not need to be changed.

Figure 8-21 – Defining an Additional QCI Profile

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 119 (179)
 5G Mobility and Traffic Management Guideline

9 Appendix 1 – Mobility Features

9.1 Software Value Packages and Features

A Software Value Package consist of a number of FAJ features that are bundled and
offered together. An overview of the features referred to in this guideline, is provided for
eNodeB features in Table 9-1 and gNodeB features in Table 9-2. Note, however, that CPI
sometimes includes eNodeB functionality in gNodeB feature descriptions (and vice versa)
to provide a more complete understanding.
Table 9-1 – RAN Features and Software Value Packages for eNodeB
Node Value Package Feature name Licensed
Type
eNodeB LTE Base Package Mobility Control at Poor Coverage Yes
(FAJ 801 0400) (FAJ 121 3013)
eNodeB LTE Base Package Subscriber Triggered Mobility Yes
(FAJ 801 0400) (FAJ 121 1788)
eNodeB LTE Base Package ASGH Framework No
(FAJ 801 0400) (FAJ 121 4795)
eNodeB LTE Base Package Flexible Counters No
(FAJ 801 0400) (FAJ 121 4669)
eNodeB LTE Base Package Multiple Frequency Band Indicators Yes
(FAJ 801 0400) (FAJ 121 3054)
eNodeB Service Based Mobility Multi-Layer Service-Triggered Mobility Yes
(FAJ 801 0433) (FAJ 121 4124)
eNodeB Service Based Mobility Service-Specific Load Management Yes
(FAJ 801 0433) (FAJ 121 3047)
eNodeB Intelligent Connectivity Basic Intelligent Connectivity Yes
(FAJ 801 1013) (FAJ 121 4843)
eNodeB Intelligent Connectivity NR Coverage-Triggered NR Session Yes
(FAJ 801 1013) Continuity
(FAJ 121 4983)
eNodeB Intelligent Connectivity Capability-Aware Idle Mode Control Yes
(FAJ 801 1013) (FAJ 121 5073)
eNodeB Intelligent Connectivity EN-DC Triggered Handover During Yes
(FAJ 801 1013) Setup
(FAJ 121 5097)
eNodeB Intelligent Connectivity EN-DC Triggered Handover During Yes
(FAJ 801 1013) Connected Mode Mobility
(FAJ 121 5243)
eNodeB Intelligent Connectivity Enhanced NR Restriction Yes
(FAJ 801 1013) (FAJ 121 5212)
eNodeB Basic NR Mobility Support Basic Capability-Aware Idle Mode Yes
(FAJ 801 1018) Control
(FAJ 121 5123)

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 120 (179)
 5G Mobility and Traffic Management Guideline

Node Value Package Feature name Licensed

Type
eNodeB Basic NR Mobility Support Basic EN-DC Triggered Handover Yes
(FAJ 801 1018) during Setup
(FAJ 121 5125)
eNodeB Inter-Vendor Load Inter-Vendor Capability-Aware Idle Yes
Management Mode Control
(FAJ 801 0416) (FAJ 121 5160)
eNodeB Inter-Vendor Load Inter-Vendor EN-DC-Triggered Yes
Management Handover During Setup
(FAJ 801 0416) (FAJ 121 5236)
eNodeB Multi-carrier Load TM9 Capability-Aware Idle Mode Yes
Management Control
(FAJ 801 0427) (FAJ 121 5153)
eNodeB Self-Organizing Networks Automated Neighbor Relations Yes
(FAJ 801 0435) (FAJ 121 0497)

Table 9-2 – RAN Features and Software Value Packages for gNodeB
Node Value Package Feature name Licensed
Type
gNodeB NR RAN Base Package LTE-NR Dual Connectivity No
(FAJ 801 4002) (FAJ 121 4908)
gNodeB NR RAN Base Package Uplink-Downlink Decoupling No
(FAJ 801 4002) (FAJ 121 4909)
gNodeB NR RAN Base Package NR Mobility No
(FAJ 801 4002) (FAJ 121 5041)
gNodeB NR RAN Base Package EPS Fallback to IMS Voice No
(FAJ 801 4002) (FAJ 121 5059)
gNodeB NR RAN Base Package Service Request-Based Emergency No
(FAJ 801 4002) Fallback (FAJ 121 5059)
gNodeB Peak Rate Evolution Value LTE-NR Downlink Aggregation Yes
Package (FAJ 121 4912)
(FAJ 801 4005)
gNodeB Peak Rate Evolution Value LTE-NR Uplink Aggregation Yes
Package (FAJ 121 5091)
(FAJ 801 4005)
gNodeB RAN Slicing RAN Slicing Framework Yes
(FAJ 801 4015) (FAJ 121 5095)
gNodeB Peak Rate Evolution Value NR DL Carrier Aggregation Yes
Package (FAJ 121 5201)
(FAJ 801 4005)
gNodeB Advanced Coverage NR DL Carrier Aggregation for Yes
Extension Coverage Extension
(FAJ 801 4006) (FAJ 121 5202)

The minimum requirement to offer and enable Dual Connectivity (EN-DC) services is the
following RAN Software Value Packages:

• LTE Base Package (FAJ 801 0400)

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 121 (179)
 5G Mobility and Traffic Management Guideline

• NR RAN Base Package (FAJ 801 4002)

• Intelligent Connectivity (FAJ 801 1013)

Note that Dual Connectivity also requires MME features, as described in Section 9.4.

Together these packages provide the necessary functions to run EN-DC including the
gNodeB operating system, configuration, and signaling and traffic functions between the
eNodeB, gNodeB, UE and Core.

9.2 eNodeB Features

This section summarizes features implemented in the eNodeB that are important for 5G
Mobility & Traffic Management.

9.2.1 Basic Intelligent Connectivity (FAJ 121 4843)

This is a licensed eNodeB feature in the value package Intelligent Connectivity (FAJ 801
1013).

The Basic Intelligent Connectivity feature (BIC) introduces the basic support for EN-DC in
the eNodeB, enabling a non-standalone 5G deployment. The corresponding feature on the
gNodeB side is LTE-NR Dual Connectivity (FAJ 121 4908).

The feature covers the fundamental interaction between LTE and NR in the EN-DC
context; for example, configuring the UE with B1 measurements for measurement-based
SN addition, setting up and releasing SN terminated bearers and providing the upper layer
indication for NR services.

9.2.1.1 Configuring the eNodeB for SN Addition

The key MOs and parameters required for SN addition are shown in Figure 9-1.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 122 (179)
 5G Mobility and Traffic Management Guideline

Figure 9-1 – Key MOs and Parameters for SN Addition

Notes for Figure 9-1:

• A GUtranFreqRelation MO must be defined for each NR frequency that is to be

measured for SN addition; namely those frequencies which are used for PSCells.

– If a GUtranFreqRelation MO is defined to an NR frequency which cannot be

used for NSA PSCells, then endcB1MeasPriority must be set to -1 on that
relation. This will prevent the frequency being measured for SN addition. This
applies to frequencies which are used only for NSA secondary cells and
frequencies used only for SA.

• For SN addition to succeed, the serving LTE cell must have a GUtranCellRelation
to the reported NR cell.

– Although a GUtranCellRelation is not required for configuration-based SN

addition, some procedures always use measurement-based SN addition, so a
GUtranCellRelation should still be defined even when using configuration-
based SN addition.

– In high-band only one NR cell is allowed to be a PSCell per sector, where a sector
is defined as the cells that are linked to the same SectorEquipmentFunction
MO. The gNodeB assumes that the PSCell is on the carrier with the lowest ARFCN
among the UL capable carriers (that is NRSectorCarrier.txDirection =
DL_AND_UL). When configuring EN-DC in the eNodeB, GUtranCellRelation
MOs shall be configured towards the allowed PSCells only, no other cells.

– To facilitate PSCell change, it is recommended that all high-band PSCells use the
same frequency.

• To prevent EN-DC on a cell (including incoming EN-DC triggered handover) but still
allow outgoing EN-DC triggered handover, use the following configuration:

– Configure an empty endcAllowedPlmnList on the cell

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 123 (179)
 5G Mobility and Traffic Management Guideline

– Define GUtranFreqRelation MOs to the NR frequencies on which EN-DC

triggered handover is required and set endcB1MeasPriority to a value other
than -1.

9.2.1.2 B1 Measurements for SN Addition

This section describes the rules used for configuring B1 measurements for SN addition,
including determining which NR frequency(s) are measured, in what order, for how long
and with what measurement gap configuration. If EN-DC triggered handover is active, then
it will configure measurements in parallel with the SN addition measurements described
here; see 9.2.13 for more detail on how the two interwork.

To configure B1 measurements for SN addition, the prerequisites for SN addition, listed in

Section 6.2.3.1, must be met.

The priority for including frequencies in B1 is determined by

GUtranFreqRelation.endcB1MeasPriority, which can be set from -1 to 7. The
highest priority is 7, the lowest is 0, and -1 means the frequency is not measured.
Frequencies with the same priority are selected randomly.

The value of endcB1MeasPriority is used to assign each frequency to a priority group:

Table 9-3 – Priority Groups for B1 Measurements
Priority Group endcB1MeasPriority
1 7, 6
2 5, 4
3 3, 2, 1, 0
NA -1

To configure the measurements in the UE, the eNodeB uses RRC Reconfiguration
messages. It sends up to three messages, and it uses the endcB1MeasPriority priority
groups to determine which frequencies to include in each message:

• First Message: includes up to maxMeasB1Endc frequencies from the highest priority

group which is not empty.

• Second Message: includes up to maxMeasB1Endc unmeasured frequencies from

priority groups 1 and 2, or from priority group 3 if there are no unmeasured frequencies
left in groups 1 and 2.

• Third Message: includes up to maxMeasB1Endc unmeasured frequencies from priority

groups 1, 2 and 3.

Table 9-4 gives examples of how frequencies are chosen for inclusion in the three RRC
Reconfiguration messages. The examples assume the listed frequencies are EN-DC
capable and supported by the UE, and that maxMeasB1Endc = 2.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 124 (179)
 5G Mobility and Traffic Management Guideline

Table 9-4 – Selecting Frequencies for EN-DC B1 RRC Reconfiguration Messages

Example 1 Example 2 Example 3
Freq Priority RRC Freq Priority RRC Freq Priority RRC
(Group) Msg (Group) Msg (Group) Msg
NR1 7 (1) 1 NR1 7 (1) 2 NR1 4 (2) 1
NR2 6 (1) 1 NR2 7 (1) 1 NR2 0 (3) 2
NR3 5 (2) 2 NR3 7 (1) 1 NR3 -1 (-) -
NR4 4 (2) 2 NR4 5 (2) 2
NR5 3 (3) 3 NR5 3 (3) 3
NR6 2 (3) 3 NR6 0 (3) 3
NR7 1 (3) -

Notes for Table 9-4:

• Example 1: The first message includes the priority group 1 frequencies, and the
second message includes the priority group 2 frequencies. The third message can
include only two of the three priority group 3 frequencies.

• Example 2: The first message includes two randomly chosen priority 7 frequencies.
The second message includes the remaining priority 7 frequency goes and the group 2
frequency. Message 3 includes the two remaining group 3 frequencies.

• Example 3: The first message includes the only frequency in the highest priority
group, which is group 2. The second message includes the group 3 frequency. The
frequency with a priority of -1 is not sent.

The sequencing of the RRC Reconfiguration messages is shown in Figure 9-2.

Figure 9-2 – RRC Reconfiguration Messages Sequence for EN-DC B1

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 125 (179)
 5G Mobility and Traffic Management Guideline

If a measurement reconfiguration message contains two or more NR frequencies with

different endcB1MeasPriority values (e.g. 7 and 6) then the eNodeB has additional
control to increase the probability that the higher priority frequency is used. Specifically, if
the first received B1 report contains a cell from the lower priority frequency, then the
eNodeB waits for endcB1MeasWindow for a B1 report containing a cell from the higher
priority frequency. If it is received before this time expires, then SN addition using the
higher priority frequency occurs. Otherwise, when the timer expires, SN addition using the
lower priority frequency occurs. This is illustrated in Figure 9-3, for the case of a
measurement reconfiguration message which contains a priority 7 frequency and a priority
6 frequency.

Figure 9-3 – Handling Simultaneous Measurement of Multiple endcB1MeasPriority Values

Notes for Figure 9-3:

Case 1: If a B1 report for a valid priority 7 cell is received first, then the eNodeB initiates
SN addition immediately.

Case 2: If a B1 report for a valid priority 6 cell is received first and a B1 report for a valid
priority 7 cell is received within endcB1MeasWindow, then the eNodeB initiates SN
addition using the priority 7 cell.

Case 3: If a B1 report for a valid priority 6 cell is received first and then
endcB1MeasWindow expires, the eNodeB initiates SN addition using the priority 6 cell.

Case 4: If a B1 report for a valid priority 6 cell is received first and then endcMeasTime +
timeToTriggerB1 expires, the eNodeB initiates SN addition using the priority 6 cell.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 126 (179)
 5G Mobility and Traffic Management Guideline

Given the above, there are two ways to prioritize one NR frequency over another:

• Different endcB1MeasPriority, same priority group (e.g. 7 and 6)

This option allows the frequencies to be measured simultaneously and uses
endcB1MeasWindow to advantage the higher priority frequency.
It improves the setup time for the lower priority frequency, in case coverage from the
higher priority frequency is not found. However, if endcB1MeasWindow is running,
then any B1 and A5 reports received for ENDCHO are ignored. This is a problem only if
the highest prioritized frequency is one which requires ENDCHO for the UE to access
it. In this case, the ENDCHO can be blocked by a B1 report for a lower priority
frequency that can be used for SN addition on the serving cell.

• Different endcB1MeasPriority, different priority groups (e.g. 7 and 5)

With this option the two frequencies are measured sequentially; the higher priority
frequency is measured for the full endcMeasTime before starting measurements on
the lower priority frequency, giving a stronger guarantee on priority. Also, unlike the
previous option, a B1 measurement report from a lower priority frequency cannot block
the B1 or A5 measurement reports for higher priority ENDCHO frequency.

There are three possibilities for configuring repetition patterns of the above RRC
sequences, namely: measure forever, measure once than stop and measure periodically,
as shown in Figure 9-4. The chosen pattern is used for EN-DC setup and ENDCHO.

• Measure forever:
If endcMeasTime = -1, then only the first RRC Reconfiguration is sent, and this
measurement continues indefinitely.

• Measure once then stop:

If endcMeasTime is set to a value other than -1 and endcMeasRestartTime = -1
(timer inactive, wait forever), then only one set of up to three RRC measurements is
configured (as previously described). After this, no more B1 measurements are started
until a new trigger occurs; for example, LTE Handover, NR Radio Link Failure and A2
Critical SN Release.

• Measure periodically:
If both endcMeasTime and endcMeasRestartTime are set to values other than -1,
then measurements will be performed periodically, as governed by those timers.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 127 (179)
 5G Mobility and Traffic Management Guideline

Figure 9-4 – Event B1 Repetition Patterns for EN-DC setup and ENDCHO

These measurements are stopped if EN-DC is set up.

• If B1 measurements are ongoing and an event occurs which violates the prerequisites
for SN addition (Section 6.2.3.1), for example a VoLTE bearer is set up, then the B1
measurements are removed.

• If waiting time endcMeasRestartTime between B1 measurement occasions is

running and a VoLTE bearer is setup, then the waiting time endcMeasRestartTime
is cancelled.

• The removal of B1 measurements is not triggered by the UE entering poor LTE

coverage, for example by entering the MCPC search zone and sending an A2 report.

If required, a measurement gap is used. The gap is set by the highest priority frequency
which requires a gap in each RRC Reconfiguration message. If another frequency requires
a gap, then it will only be measured if its SSB falls within the configured gap. Measurement
gaps are mandatory for FR1 frequency bands but for FR2 frequency bands measurement
gaps are used only if the UE requires it.
Table 9-5 – Parameters for Controlling B1 Measurements
Attribute Values Description
(RAT, MO) (default)
[units]
maxMeasB1Endc 1 to 8 The maximum number of concurrent B1
(LTE, UeMeasControl) (3) measurement configurations on NR frequency
for ENDC
endcB1MeasPriority -1, 0 to 7 NR frequency priority for EN-DC measurements.
(LTE, GUtranFreqRelation) (4) Highest priority is 7. Lowest priority is 0.
Value -1 means that the frequency is excluded.
Frequencies with the same priority are selected
randomly.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 128 (179)
 5G Mobility and Traffic Management Guideline

Attribute Values Description

(RAT, MO) (default)
[units]
endcMeasTime -1, 40 to Time for which UE performs measurements
(LTE, UeMeasControl) 120000 requested in each RRC reconfiguration
(2000) [ms] message for EN-DC. Value -1 means infinity.
timeToTriggerB1 0 to 5120 (0) Time-to-trigger value for event B1.
(LTE, ReportConfigB1GUtra) discrete
values,
[ms]
endcB1MeasWindow 0, 40 to 2000 Time duration waiting for other B1 measurement
(LTE, UeMeasControl) (40) [ms] reports after receiving first B1 measurement
report.
endcMeasRestartTime -1, 0 to Time to wait for next B1 array (up to three
(LTE, UeMeasControl) 240000 batches of B1 measurement configuration) for
(-1) [ms] EN-DC. Value -1 means B1 Array will not be
restarted.
endcAwareMfbiIntraCellHo true, false If true, all overlapping bands of serving LTE PCell
(LTE, ENodeBFunction) (false) are considered EN-DC setup and intra-cell handover
to change band is performed if required.
If false, only the primary LTE PCell band is
considered.

This section has focused primarily on the configuring the sequence of B1 measurements.
Configuring the effective trigger level for the B1 measurements is covered in Section
10.2.2.

Refer to the CPI document Basic Intelligent Connectivity for more information.

9.2.1.3 Multiple Frequency Band Indicator for EN-DC Setup

To enable overlapping LTE bands to be used for EN-DC setup, set

ENodeBFunction.endcAwareMfbiIntraCellHo = true. This allows the eNodeB to
consider overlapping LTE bands when determining which band combinations are
supported by both the UE and eNodeB, and therefore which NR frequencies the UE must
measure for SN addition (using B1).

When a B1 report is received from the UE, and the UE does not support EN-DC on this NR
frequency combined with the primary LTE band, then the eNodeB triggers an intra-cell
handover to an overlapping LTE band which the UE supports for EN-DC, and SN addition
proceeds.

If SN release occurs, then the eNodeB moves the UE back to the band it was using before
EN-DC setup. For example, consider the case of an LTE intra-frequency handover, when
the UE is using EN-DC on an overlapping band. The sequence of events is:

• eNodeB receives report for Event A3

• SN release and intra-cell handover from overlapping band to previously used band
(e.g. primary band)

• Legacy LTE intra-frequency handover

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 129 (179)
 5G Mobility and Traffic Management Guideline

• Intra-cell handover to overlapping band, B1 measurement configuration and SN

addition

Note that SCG release (and addition) does not trigger the band change.

9.2.1.4 Automatic Update of Upper Layer Indication

As described in Section 4.5 - 5G Status Icon on UE, the upper layer indication tells the UE
that 5G NSA service is potentially available in the area, so that the UE can display a 5G
icon. The upper layer indication can be set either manually or automatically (by BIC) for
each PLMN defined in the LTE serving cell as follows:

• To enable automatic update, set

EUtranCellFDD/TDD.upperLayerAutoConfEnabled = true

• If automatic update is enabled:

– The eNodeB sets the upper layer indication (per PLMN) to true when:

• The PLMN exists in the EUtranCellFDD/TDD.endcAllowedPlmnList, and

• The PLMN exists in ExternalGUtranCell.plmnIdList referenced by

GUtranCellRelation

– Otherwise the eNodeB sets it to false

– The automatically configured values for each PLMN are stored in the read-only
attribute EUtranCellFDD/TDD.upperLayerAutoConfIndList. The first listed
value corresponds to ENodeBFunction.eNodeBPlmnId, and the subsequent
values to the PLMN list contained in
EUtranCellFDD/TDD.additionalPlmnList.

– The automatic process is typically triggered when a GUtranCellRelation is

added or removed, but it can also be triggered by other configuration changes. If
this process results in a change to a broadcasted upper layer indication value, then
a SIB2 update is triggered to advise the UE.

• If automatic update is disabled:

– The upper layer indication is set manually, using the attributes

EUtranCellFDD/TDD.primaryUpperLayerInd and
EUtranCellFDD/TDD.additionalUpperLayerIndList.

• Note that for both manual and automatic updates, the upper layer indication can be
configured only on PLMNs which are allowed in the serving LTE cell, namely those
contained in ENodeBFunction.eNodeBPlmnId and
EUtranCellFDD/TDD.additionalPlmnList.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 130 (179)
 5G Mobility and Traffic Management Guideline

9.2.2 NR Coverage-Triggered NR Session Continuity (FAJ 121 4983)

This is a licensed eNodeB feature in the value package Intelligent Connectivity (FAJ 801
1013).

It enables mobility of NR Standalone (NR SA) capable UEs from LTE to NR SA when
coverage becomes acceptable. The feature enables mobility in both idle mode and
connected mode:

• In idle mode, the feature enables the broadcast of NR SA frequencies in SIB24, so that
NR SA capable UEs can reselect from LTE to NR SA. See Section 7.1 for more detail.

• In connected mode, the feature allows UEs which are capable of NR SA to be re-
directed to NR SA, when NR SA coverage becomes acceptable. See Section 7.2.1 for
more detail.

To be capable of NR SA, UEs must support 3GPP R15.4.

Refer to the CPI document NR Coverage-Triggered NR Session Continuity for more

information.

9.2.3 Subscriber Triggered Mobility (FAJ 121 1788)

Subscriber Triggered Mobility (STM) is a licensed eNodeB feature in the LTE Base
Package (FAJ 801 0400). It enables the mobility behavior of a UE to be modified based on
its Subscriber Profile ID (SPID) value. The SPID is received by the RBS over the S1
interface and is specific to a UE, applying to all its radio bearers.

In this guideline, STM is used to modify the mobility behavior of 5G UEs to steer them
towards an appropriate LTE anchor carrier, as described in Section 8.

In addition, STM can be used to modify the idle mode cell reselection priorities and the
connected mode mobility priorities for NR SA frequencies, using the
RATFreqPrio.FreqPrioNR MO.

9.2.4 ASGH Framework (FAJ 121 4795)

This is an unlicensed eNodeB feature in the LTE Base Package (FAJ 801 0400).

The ASGH framework relies on three separate features:

• An unlicensed feature that puts the framework in place, allowing the configuration of
the detection criteria, QCI remapping and observability

• The licensed ASGH Performance Package (FAJ 121 4796) that enables the
modification of all UE-level parameters, except for prescheduling parameters

• The licensed ASGH-Based Prescheduling (FAJ 121 4797) that enables the
modification of prescheduling parameters

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 131 (179)
 5G Mobility and Traffic Management Guideline

In this guideline, ASGH is used to re-map the QCI values of 5G subscribers into different,
operator defined QCI values. This facilitates the use of QCI-based features, such as Multi-
Layer Service-Triggered Mobility or Service Specific Load Management, in 5G mobility and
traffic management solutions.

9.2.5 Mobility Control at Poor Coverage (FAJ 121 3013)

Mobility Control at Poor Coverage (MCPC) is a licensed eNodeB feature in the LTE Base
Package (FAJ 801 0400).

It builds on the legacy Session Continuity features to provide more control over mobility
triggered by poor coverage. In this guideline, it is used for some of the anchor carrier
management strategies. Refer to the LTE Mobility and Traffic Management Guideline for
additional information on using this feature in the mobility strategy.

9.2.6 Multi-Layer Service-Triggered Mobility (FAJ 121 4124)

Multi-Layer Service-Triggered Mobility (MLSTM) is a licensed eNodeB feature in the

Service Based Mobility Value Package (FAJ 801 0433).

It allows mobility thresholds to be tailored per frequency and/or per QCI (so per service) by
adding offsets. It requires the feature Mobility Control at Poor Coverage to be active, as
well as the relevant session continuity feature (for example Coverage-Triggered Inter-
Frequency Session Continuity). This feature supersedes the Service-Triggered Mobility
feature, and overrides it if both features are activated. In this guideline, it is used for some
of the anchor carrier management strategies. Refer to the LTE Mobility and Traffic
Management Guideline for further information on using this feature in the mobility strategy.

9.2.7 Service Specific Load Management (FAJ 121 3047)

Service Specific Load Management is a licensed eNodeB feature in the value package
Service Based Mobility (FAJ 801 0433).

This feature provides control over how certain services (for example VoIP) are treated by
load balancing and offload. In this guideline, it is used for some of the anchor carrier
management strategies. Refer to the LTE Mobility and Traffic Management Guideline for
further information on using this feature in the mobility strategy.

9.2.8 Flexible Counters (FAJ 121 4669)

Flexible Counters is an unlicensed eNodeB feature in the LTE Base Package (FAJ 801
0400). It introduces the possibility to apply operator-defined filters on certain counters, so
that they peg for only a subset of events. This enables the creation of KPIs which focus on
EN-DC users. It is also possible to combine filters, for example EN-DC, QCI and SPID
filters, to obtain further differentiation.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 132 (179)
 5G Mobility and Traffic Management Guideline

Three levels of filtering are available for the EN-DC. The included levels are set by the
parameter PmFlexCounterFilter.endcFilterMin. For example, if this parameter is
set to 1, then the counter is stepped if the EN-DC state is either ENDC_NR_MATCHED or
ENDC_NR_ACTIVE.

• 0 (ENDC_NR_CAPABLE)
The UE is confirmed to be capable of EN-DC.

• 1 (ENDC_NR_MATCHED)
B1 measurements for EN-DC are configured in the UE.

• 2 (ENDC_NR_ACTIVE)
ENDC is active for the UE.

9.2.9 Capability-Aware Idle Mode Control (FAJ 121 5073)

Note: This licensed eNodeB feature is for Baseband Radio Nodes. The corresponding
feature for DU Radio Nodes is Basic Capability-Aware Idle Mode Control (Section 9.2.10).

The purpose of Capability-Aware Idle Mode Control (CAIMC) is to encourage EN-DC

capable UEs to camp on a frequency which they can use for EN-DC. This is achieved by
altering the cell reselection priorities used by the UE to reselect between frequencies in idle
mode; higher priorities are given to EN-DC capable frequencies. The altered priorities are
sent from the eNodeB to the EN-DC capable UEs at RRC connection release, in the
IdleModeMobilityControlInfo (IMMCI) information element. These priorities override the cell
reselection priorities which are broadcast in System Information, for a time of t320. The
value of t320 is taken from the UePolicyOptimization MO if it is defined, and from the
Rrc MO if not.

CAIMC does not impact UEs which meet any of the following conditions:

• UE is not EN-DC capable (en-DC-r15 UE capability IE is not set to supported)

• UE has the value NRrestrictedinEPSasSecondaryRAT in the “NR Restriction in EPS as

Secondary RAT” IE in its Handover Restriction List (HRL), regardless of whether the
feature Enhanced NR Restriction (Section ) is activated or not.

• UE is qualified to be prioritized by the NR Coverage-Triggered NR Session Continuity

feature UE. A UE is qualified if:

– The feature NR Coverage-Triggered Session Continuity is enabled, and

– The UE is SA capable, and

– UE does not have the value NRrestrictedin5GS in the “NR restriction in 5GS” IE in
the UE’s HRL, and

– GUtranFreqRelation.allowedPLMNList is empty, or

– At least one of the serving or any equivalent PLMNs in the UE’s HRL matches any
PLMN in the GUtranFreqRelation.allowedPLMNList, and

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 133 (179)
 5G Mobility and Traffic Management Guideline

– At least one of these matching PLMNs does not have the value 5GCForbidden in
the “Core Network Type Restrictions” IE in the HRL

• UE is Category M

• UE is involved with CSFB or RWR

If the UE has a SPID value assigned to it, then the following additional checks are
performed:

• If Subscriber Triggered Mobility (STM) is active and the SPID value is found in the
spidList of a RATFreqPrio instance, then the behavior depends on the setting of
ueCapPrioAllowed in that RatFreqPrio instance:

– If ueCapPrioAllowed = true, then CAIMC can determine the IMMCI

– If ueCapPrioAllowed = false, then STM determines the IMMCI

• If Preferential Traffic Management (PTM) is active and the SPID value is found in the
spidList of any PtmSubscriberGroup and the spidList of the corresponding
RATFreqPrio instance, then CAIMC has no impact on the UE.

CAIMC considers an LTE frequency to be EN-DC capable for a particular UE if all of the
following conditions are met:

• The UE supports an EN-DC band combination which uses the LTE frequency. (Section
6.2.1 explains how the eNodeB obtains the UE capability information.)

• The corresponding EUtranFreqRelation.cellReselectionPriority attribute

is not -1

• If the Shared LTE RAN feature is active, then at least one PLMN from
EUtranFreqRelation.allowedPlmnList matches a PLMN in the UE’s HRL. If the
HRL is not available, then this condition is not applied.

• The frequency has at least one EN-DC capable cell. An EN-DC capable cell is one
where the following conditions are met:

– At least one of the serving or equivalent PLMN identities listed in the UE’s HRL
matches one of the identities configured in the potential target cell’s
endcAllowedPlmnList. If the UE’s HRL is not available, the
ExternalENodeBFunction.eNodeBPlmnId is used instead. Note that to
exchange EN-DC cell relation capability over X2, both eNodeBs must be Ericsson.

– BIC is enabled in the cell’s eNodeB

If no EN-DC capable frequencies remain after applying the above conditions, then CAIMC
does not send the IMCCI, and therefore does not impact the UE.

When determining frequency priorities, CAIMC also considers coverage probability, giving
higher priority to EN-DC capable frequencies that the UE is more likely to find. To consider
coverage, CAIMC ranks frequencies based on either hit rate or on cell counts:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 134 (179)
 5G Mobility and Traffic Management Guideline

• Hit Rate Ranking

If UePolicyOptimization.coverageAwareImc = true and either the Best
Neighbor Relations for Intra-LTE Load Management (BNR) feature or the Cell Sleep
Mode (CSM) feature is active, then CAIMC uses the hit rate statistics from the active
feature to rank frequencies. If both features are active, then CAIMC uses the hit rates
from BNR. For ranking, CAIMC uses the hit rate of EN-DC capable cells, aggregated at
the frequency level. The hit rate on any one frequency can range from 0% to 100%.
The sum of hit rates over all frequencies can exceed 100% if frequencies have
overlapping coverage.

• Cell Count Ranking

If UePolicyOptimization.coverageAwareImc = false or if neither BNR nor
CSM is active, then, for ranking, CAIMC uses the number of EN-DC capable neighbor
cells on each frequency.

When determining priorities to send in the IMMCI, CAIMC uses the following rules:

• If the combination of UE and serving cell is EN-DC capable, then the serving cell
frequency is assigned the highest priority (7).

• Frequencies with higher hit rates (or cell counts) are given higher priority. Frequencies
with equal hit rates (or cell counts) are given equal priority. Non EN-DC capable
frequencies are given lower priority.

• Where possible, the priority order set by

EUtranFreqRelation.cellReselectionPriority (SIB priority) is followed. If
insufficient priorities are available, then the lowest available priority is used for the
remaining frequencies.

• Other RATs are given the very lowest priority; for example, 0 if there is only one other
RAT, or 0 and 1 if there are two. Different RATs are never allocated the same priority.
When determining the priorities amongst different RATs, SIB priority order is followed.
If a RAT has more than one priority in SIB, then the highest is used to determine
priority order.

• Frequencies with cellReselectionPriority set to -1 are not included in IMMCI.

• For EN-DC capable UEs, CAIMC overrides the features LBDAR and ELBDAR if either
of those features is active

An example of how CAIMC assigns cell reselection priorities in IMMCI is provided in Table
9-6.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 135 (179)
 5G Mobility and Traffic Management Guideline

Table 9-6 – CAIMC Frequency Ranking – Example 1

Frequency EN-DC SIB Aggregated CAIMC
Capable Priority Hit Rate Priority
LTE 1 No 7 - 4
LTE 2 Yes 6 20% 5
LTE 3 Yes 5 50% 6
LTE 4 Yes 4 80% 7
LTE 5 No 3 - 3
(Serving Cell)
LTE 6 No Not included - Not included
(priority = -1) (priority = -1)

Notes for Table 9-6

• LTE 4 has the highest hit rate, so it gets the highest priority.

• LTE 5, the serving frequency, gets the lowest priority as the serving cell is not EN-DC
capable and the frequency has a lower SIB priority than the LTE 1 frequency, which is
also not EN-DC capable.

• LTE 6 is not included in SIB or in IMMCI as it has a cell reselection priority of -1.

A more complex example of how CAIMC assigns cell reselection priorities in IMMCI is
provided in Table 9-7.
Table 9-7 – CAIMC Frequency Ranking – Example 2
Frequency EN-DC SIB Aggregated CAIMC
Capable Priority Hit Rate Priority
LTE 1 Yes 7 30% 2
LTE 2 Yes 6 - 7
(Serving Cell)
LTE 3 Yes 5 50% 3
LTE 4 Yes 5 60% 4
LTE 5 Yes 4 60% 4
LTE 6 Yes 4 70% 5
LTE 7 Yes 3 80% 6
LTE 8 No 3 - 2
UTRAN 1 No 2 - 1
GERAN No 1 - 0
UTRAN 2 No 0 - 1

Notes for Table 9-7.

• LTE 2 is the frequency of the serving cell, which is EN-DC capable, so this frequency
gets the highest priority. The serving frequency does not have a hit rate.

• Other EN-DC capable frequencies are ranked below the serving frequency. LTE 4 and
LTE 5 get the same priority as they have the same hit rate.

• The two UTRAN frequencies get the same priority, which is higher than GSM because
the highest SIB priority for UTRAN is higher than the SIB priority for GSM.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 136 (179)
 5G Mobility and Traffic Management Guideline

• There are not enough priorities for all frequencies to have a unique priority, so LTE 1
and LTE 8 get the same priority even though one is EN-DC capable and the other is
not.

If both the features Capability Aware Idle Mode Control (CAIMC) and TM9 Capability
Aware Idle Mode Control (TM9 CAIMC) are active, then the parameter
UePolicyOptimization.ueCapPrioList determines how frequencies are prioritized.
Table 9-8 provides some examples, assuming a UE which is capable of both EN-DC and
TM9. This table uses the following terms to describe the frequencies:

• EN-DC(NW+UE): Frequency is supported for EN-DC by both the network and the UE

• EN-DC(NW): Frequency is supported for EN-DC by the network but not the UE

• TM9: Frequency is supported for TM9 by the network and the UE

• Other: All remaining frequencies

Table 9-8 – Example of Frequency Ranking with both CAIMC and TM9 CAIMC Active
ueCapPrioList Frequency Order in IMMCI
empty Legacy ranking is used
(no priority for EN-DC or TM9 capable frequencies)
[ENDC] EN-DC(NW+UE), EN-DC(NW), Other
[TM9] TM9, Other
[TM9, ENDC] TM9, EN-DC(NW+UE), EN-DC(NW), Other
[ENDC, TM9] EN-DC(NW+UE), EN-DC(NW), TM9, Other
(default) This also the default behavior if the
UePolicyOptimization MO is not defined.

CAIMC is triggered only when a DRB is released; for example, it does not trigger as a
result of a Tracking Area Update.

9.2.10 Basic Capability-Aware Idle Mode Control (FAJ 121 5123)

Note: This licensed eNodeB feature is for DU Radio Nodes. The corresponding feature for
Baseband Radio Nodes is Capability-Aware Idle Mode Control (Section 9.2.9).

This feature is similar to corresponding Baseband Radio Node feature (CAIMC, Section
9.2.9). The difference is that in this DU version of the feature, the eNodeB does not check
which EN-DC band combinations the UE supports. It is therefore possible that the IMMCI
assigns the highest priority to an EN-DC capable LTE frequency that the UE cannot use for
EN-DC.

9.2.11 Inter-Vendor Capability-Aware Idle Mode Control (FAJ 121 5160)

Note: This licensed eNodeB feature is for Baseband and DU Radio Nodes.

This feature extends the two features Capability-Aware Idle Mode Control (for Baseband
Radio Nodes) and Basic Capability-Aware Idle Mode Control (for DU Radio Nodes) to
include EN-DC-capable cells of other vendors.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 137 (179)
 5G Mobility and Traffic Management Guideline

To indicate whether an external cell is EN-DC capable, the parameter

endcAllowedPlmnList in the MOs ExternalEUtranCellFDD/TDD is used. How this
parameter is set depends on whether the cell is inter-vendor or not, and how the
ExternalEutranCellFDD/TDD is created. This is described in Table 9-9:
Table 9-9 – Handling of endcAllowedPlmnList
Information Created by Handling of endcAllowedPlmnList
available over X2?
No Operator Must be configured manually
(inter-vendor case) ANR or X2 Automatically set with information from
EUtranFrequency.extEndcAllowedPlmnListPolic
y (where this list is populated) at the time the external cell
is created. Otherwise it must be configured manually.
Yes (both eNodeBs Operator Set automatically through X2 information
must be Ericsson) ANR or X2 Set automatically through X2 information

See the feature description in CPI for further information.

9.2.12 TM9 Capability-Aware Idle Mode Control (FAJ 121 5153)

Note: This licensed eNodeB feature is for Baseband Radio Nodes.

This feature is similar to the feature Capability-Aware Idle Mode Control (CAIMC, Section
9.2.9) but rather than targeting EN-DC capable UEs, it targets TM9 capable UEs. Its
purpose is to encourage TM9 capable UEs to camp on a frequency which they can use for
TM9. As with CAIMC, the feature alters the cell reselection priorities used by the UE to
reselect between frequencies in idle mode; higher priorities are given to TM9 capable
frequencies. Priorities are determined by hitrate statistics if either of the features Best
Neighbor Relations for Intra-LTE Load Management or Cell Sleep Mode is active and the
parameter UePolicyOptimization.coverageAwareImc = true. If not, priorities are
determined by the count of TM9 capable cells on each frequency.

If both the features Capability Aware Idle Mode Control and TM9 Capability Aware Idle
Mode Control are active, then the parameter UePolicyOptimization.ueCapPrioList
determines whether EN-DC or TM9 is given priority, as described in 9.2.9.

See the feature description in CPI for further information.

9.2.13 EN-DC Triggered Handover During Setup (FAJ 121 5097)

The purpose of EN-DC triggered handover (ENDCHO) is to move the UE to another LTE
cell which is better suited to provide it with EN-DC. Another cell is better suited in the
following cases:

• The UE cannot use the serving LTE cell for EN-DC, for example because the cell is not
capable of EN-DC, or because the UE does not support the EN-DC band combinations
available on the cell. The UE can, however, use another LTE cell for EN-DC.

• The UE can use the serving LTE cell for EN-DC, but the UE does not have coverage
from the required NR frequency(s). However, the UE does have coverage from a lower
priority NR frequency that the UE can use for EN-DC if it moves to another LTE cell.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 138 (179)
 5G Mobility and Traffic Management Guideline

• The UE can use the serving LTE cell for EN-DC and the UE has coverage from the
required NR frequency(s). However, the UE also has coverage from a higher priority
NR frequency that it can use for EN-DC if it moves to another LTE cell.

There are four licensed eNodeB features which provide ENDCHO functionality:
1 EN-DC Triggered Handover During Setup – FAJ 121 5097

This feature is for Baseband Radio Nodes. It provides ENDCHO which is triggered at
initial context setup. It uses B1 measurements to check for coverage from NR target
frequencies and A5 measurements to check for coverage from target LTE frequencies.
If coverage from a suitable NR and LTE frequency combination is found, then
ENDCHO is performed and the B1 measurement report is forwarded to the target cell
during the LTE handover.
2 EN-DC Triggered Handover During Connected Mode Mobility – FAJ 121 5243

This feature is for Baseband Radio Nodes. It is similar to EN-DC Triggered Handover
During Setup, except that it triggers ENDCHO at incoming intra-frequency, inter-
frequency, inter-RAT handover and at RRC connection re-establishment, rather than at
setup. It also uses B1 and A5 measurements to check for coverage. This feature is
further described in Section 9.2.16.
3 Basic EN-DC Triggered Handover During Setup – FAJ 121 5125

This feature is for DU radio nodes and, as suggested by its name, is a basic version of
EN-DC Triggered Handover During Setup. The primary difference is that this basic
version does not configure B1 measurements to check for NR coverage; only A5
measurements are configured. This feature is further described in Section 9.2.14.
4 Inter Vendor EN-DC Triggered Handover During Setup – FAJ 121 5125

This feature is for Baseband Radio Nodes and applies only when the UE cannot setup
EN-DC in the serving cell. The feature enables EN-DC Triggered Handover to a cell
that is either an inter vendor (non-Ericsson) cell or an Ericsson external cell which has
no X2 link with the source LTE cell. The triggering points are initial context setup and
incoming handover (LTE and IRAT). The B1 measurement report is forwarded to the
target cell during the LTE handover. This feature is further described in Section 9.2.19.

The rest of this section describes functionality that is relevant primarily to features 1 and 2
above. It explains how the ENDCHO and Basic Intelligent Connectivity features work
together to determine whether to perform SN addition on the serving cell, or perform EN-
DC triggered handover, or use LTE only. A high-level overview of this process is shown in
Figure 9-5.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 139 (179)
 5G Mobility and Traffic Management Guideline

Figure 9-5 – Interaction between SN addition and ENDCHO processes

To determine whether ENDCHO is possible, the serving eNodeB searches for suitable
combinations of target LTE and NR frequencies. A combination is considered suitable for
ENDCHO if all of the following conditions are met:

• The serving LTE cell must have a GUtranFreqRelation to the target NR frequency,
with GUtranFreqRelation.endcB1MeasPriority not equal to -1. This allows the
NR frequency to be measured, either for SN addition or for ENDCHO.

• The NR frequency has not been selected by BIC as suitable for SN addition on the
serving LTE cell. An NR frequency cannot be selected as a candidate for both SN
addition and ENDCHO, it is selected for either one or the other. An NR frequency is
suitable for SN addition if:

– endcAllowedPlmnList is not empty and a PLMN match is found with the UE as

described in Section 6.2.3.1

– The band combination is supported by the UE

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 140 (179)
 5G Mobility and Traffic Management Guideline

• The serving LTE cell must have an EUtranFreqRelation to the target LTE
frequency, with EUtranFreqRelation.endcHoFreqPriority not equal to -1. This
allows the target LTE frequency to be measured.

• The UE must support EN-DC on a band combination which includes both the target NR
and target LTE frequencies.

• The UE must not have an NR restriction on the target NR band, considering the feature
Enhanced NR Restriction as follows:
Table 9-10 – ENDCHO handling of NR Restriction
UE has “NR Restriction in EPS as Enhanced NR ENDCHO Allowed?
Secondary RAT” present in HRL? Restriction
feature state
Not present - Yes
Present Not active No
Present Active Yes, to NR low and mid-band
No, to NR high-band

• At least one “EN-DC capable” cell must exist on the target LTE frequency. To be
considered “EN-DC capable”, the cell must support EN-DC on a PLMN which can be
used by the UE. More specifically, at least one of the serving or equivalent PLMN
identities listed in the UE's HRL must match one of the identities configured in the
endcAllowedPlmnList of at least one cell on the target LTE frequency. If the HRL is
not available, the ExternalENodeBFunction.eNodeBPlmnId is used instead.

– For cells on the serving eNodeB, the endcAllowedPlmnList contained in the

EUtranCellFDD or EUtranCellTDD MO is used.

– For cells on another eNodeB, the endcAllowedPlmnList in the

ExternalEUtranCellFDD or ExternalEUtranCellTDD MO is used. This list is
populated automatically when the X2 link is configured between the two eNodeBs,
provided that the feature Basic Intelligent Connectivity is active in the other LTE
cell.

– Note that no check is made to confirm that the “EN-DC capable” cell is actually
configured to support EN-DC with the target NR frequency. The only requirement is
the PLMN match, described above.

If no suitable combinations of target LTE and NR frequencies are found, then ENDCHO is
not possible. In this case, measurements are configured for SN addition on the current
serving cell only (assuming this is possible, as described in Section 9.2.1).

If at least one suitable combination of target LTE and NR frequencies is found, ENDCHO is
possible. The eNodeB then configures B1 measurements to detect coverage from NR cells
and A5 measurements to detect coverage from the LTE cells. These measurements use
the same framework as the measurements for SN addition, described in Section 9.2.1:

• The B1 and A5 measurements are configured together in the same RRC

reconfiguration messages.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 141 (179)
 5G Mobility and Traffic Management Guideline

– Note that in the current software revision, ENDCHO requires that the feature
Dynamic SCell Selection for Carrier Aggregation is active, because the functionality
contained in that feature enables the configuration of the A5 measurements.

• The B1 and A5 measurements for ENDCHO are configured in a similar way to the
measurements for SN addition on the serving cell. This is described in full detail in
Section 9.2.1.2, with particular reference to the RRC reconfiguration sequences (shown
in Figure 9-2) and the repetition patterns (shown in Figure 9-4).

• When prioritizing NR frequencies for B1 measurement, no distinction is made between

frequencies which have been chosen for ENDCHO and frequencies which have been
chosen for SN addition on the serving cell. They are all ranked together using the
priorities set in GUtranFreqRelation.endcB1MeasPriority; 7 is the highest
priority, 0 is the lowest priority and -1 means that the frequency is excluded.

• The B1 measurements use the parameters configured in ReportConfigB1GUtra, for

example: b1ThresholdRsrp, hysteresisB1 and timeToTriggerB1, along with
any offset configured in GUtranFreqRelation. See Section 10.2.2 for more detail.

• For the A5 measurements, the priority for including LTE frequencies is determined by
the parameter EUtranFreqRelation.endcHoFreqPriority; 7 is the highest
priority, 0 is the lowest priority and -1 means that the frequency is excluded.

• The A5 measurements use the parameters configured in the MO

ReportConfigA5EndcHo, for example: a5Threshold1Rsrp, a5Threshold2Rsrp,
hysteresisA5, timeToTriggerA5. It is possible to use RSRQ for triggering A5, by
setting triggerQuantityA5 = RSRQ. However, RSRP is recommended. See Section
10.2.6 for more detail.

Figure 9-6 gives an example of how the eNodeB chooses the frequencies to include in
each message. In this example, the serving cell uses frequency LTE2, which is configured
for EN-DC with frequency NR2 only.

Figure 9-6 – EN-DC Triggered Handover During Setup – How eNodeB Chooses
Frequencies

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 142 (179)
 5G Mobility and Traffic Management Guideline

Notes for Figure 9-6:

1 List the NR frequencies which have a GUtranFreqRelation MO configured under
the serving LTE cell. Order them by
GUtranFreqRelation.endcB1MeasPriority. Include the priority group of each
frequency (as explained in Section 9.2.1.1.) and the frequency band. In this example,
frequency NR3 is contained in two NR bands (n77 and n78).
2 List the band combinations supported by the UE for EN-DC.
3 Eliminate those NR bands which are not supported by the UE for EN-DC, namely n77
and n51.
4 Eliminate those NR frequencies which are not included in any band supported by the
UE for EN-DC, namely NR4.
5 List the LTE frequencies which have an EUtranFreqRelation MO configured from
the serving LTE cell with endcHoFreqPriority not equal to -1.

6 Eliminate those LTE bands which are not supported by the UE for EN-DC, namely b28.
7 Eliminate those LTE frequencies which are not included in any band supported by the
UE for EN-DC, namely LTE5.
8 Eliminate any LTE frequencies which have no EN-DC capable cells; assume LTE4 in
this example.
9 Eliminate the frequency of the serving LTE cell; LTE2 in this example. EN-DC triggered
handover is not required for this frequency.
10 By combining the tables in steps 1, 2 and 5, list the NR and LTE frequency
combinations which remain valid for EN-DC, and the NR frequencies which remain
valid for SN addition. For example, looking at the yellow highlighted cells, frequency
NR1 is in NR band n260 which the UE can use with LTE bands b1 and b5 for EN-DC,
and these bands have EN-DC capable frequencies LTE1 and LTE3 implemented in
the network. Note that NR2 is configured for EN-DC on the serving LTE cell, so no
matching LTE frequencies are listed against NR2.
11 Combine the NR and LTE frequencies into a maximum of three RRC reconfiguration
messages to the UE, using the Priority Group rules described in Section 9.2.1.2. In this
example, the first message contains the priority group 1 NR frequencies and the
matching LTE frequencies. The second message contains the priority group 2 NR
frequencies, and the matching LTE frequency. Up to maxMeasB1Endc NR frequencies
can be included in each message. The number of LTE frequencies which can be
included is more complicated to determine; refer to the LTE Mobility and Traffic
Management Guideline for more details. If not all of the LTE frequencies can be
included, endcHoFreqPriority is used to prioritize. Note that the same LTE
frequency can be included in more than one RRC reconfiguration message.

When the eNodeB receives the B1 and A5 measurement reports, it evaluates them using
the following procedure:

• When the eNodeB receives a B1 report, it immediately initiates SN addition if both the
UE and serving cell support EN-DC with the reported frequency. If not, the eNodeB

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 143 (179)
 5G Mobility and Traffic Management Guideline

stores the B1 report and waits for an A5 report that results in a valid band combination
for ENDCHO.

• When the eNodeB receives an A5 report, it determines whether the report contains a
valid LTE target cell. To be valid, the following conditions must be met:

– Given that the UE has sent the report, the triggering condition (based on either
RSRP or RSRQ, as set by triggerQuantityA5) is already satisfied. However, if
reportQuantityA5 = BOTH, then the eNodeB also checks that the non-triggering
quantity (the quantity that triggerQuantityA5 is not set to) is also satisfied. This
is fully described in Section 10.2.6.

– A B1 report for one or more NR frequencies has already been received, within the
report interval of NR B1 (which is fixed at 240 ms). To allow the B1 to arrive first,
set the time to trigger for the A5 longer than that of the B1.

– The UE is capable of an EN-DC band combination which includes the reported LTE
frequency and one of the abovementioned NR frequencies.

– The reported LTE cell is “EN-DC capable”; in other words, at least one of the
serving or equivalent PLMN identities listed in the UE’s HRL matches one of the
identities configured in the target cell’s endcAllowedPlmnList. If the HRL is not
available, the ExternalENodeBFunction.eNodeBPlmnId is used instead.

– If the reported LTE cell is hosted by the serving eNodeB, then prerequisites for SN
addition on the cell must be satisfied.

– If the reported LTE cell is hosted by another eNodeB, then there is no check to
confirm that the reported LTE cell supports EN-DC with the reported NR cell or any
cell on the reported NR frequency. If it does not, then it may not be possible to set
up EN-DC once the LTE handover has been performed.

– isHoAllowed = true and mobilityStatus.available = true on the

EUtranCellRelation

– The HRL of the UE allows a handover to the cell.

– The reported target cell is not blocked due to Cell Soft Lock

– If multiple LTE cells in a measurement report satisfy the above criteria, then the one
with the highest RSRP or RSRQ (depending on triggerQuantityA5) is
selected.

• If a voice bearer is introduced and an FR1 B1 measurement is in place, then all of the
B1 and A5 measurements in the corresponding RRC reconfiguration message are
removed, for both FR1 and any FR2 measurements which may be present, and the
measurements are not reconfigured if the voice bearer is removed.

In addition, the eNodeB checks the following conditions for the UE:

• MBMS interest indication for the UE is not set to the serving frequency.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 144 (179)
 5G Mobility and Traffic Management Guideline

• The guard timer for mobile originated voice calls is not running for the UE (refer to
Section 6.2.3.1)

If a valid LTE target cell is found and the above-listed UE conditions are met, then the
eNodeB instructs the UE to perform the EN-DC triggered handover. During the LTE
handover, all valid B1 measurement reports (one per NR frequency) are forwarded to
target LTE cell. Valid means that less than reportIntervalB1 has elapsed since the
report was received.

After completion of incoming ENDCHO, the forwarded B1 measurements are used for SN
addition, assuming that the relevant prerequisites are met. If the forwarded measurements
contain multiple frequencies, then the eNodeB uses endcB1MeasPriority to prioritize
amongst them. In the case of equal priorities, a round-robin algorithm is used.

If SN addition using the forwarded B1 measurement result fails, then the eNodeB starts
new B1 measurements following the normal procedure for SN addition.

If configuration-based SN addition is used in the target LTE cell

(EUtranCellFDD/TDD.extGUtranCellRef is set), then the eNodeB does not use the
forwarded B1 information. Instead, EN-DC setup is performed using configuration-based
SN addition.

9.2.13.1 ENDCHO – Interaction of UE Capability, Priority and Coverage

Figure 9-7 provides examples of how EN-DC behaves in the complex case of a multi-layer,
multi-priority network, with varying NR coverage and differing UE capabilities.

Figure 9-7 – ENDCHO – Interaction of UE Capability, Priority and Coverage

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 145 (179)
 5G Mobility and Traffic Management Guideline

Notes for Figure 9-7:

• Both LTE cells (LTE1 and LTE2) are configured for EN-DC with both NR cells (NR1
and NR2). NR2 is configured with a higher endcB1MeasPriority (7) than NR1 (5).

• The figure shows four UEs, (A, B, C and D) in different positions (1, 2, 3, and 4). The
EN-DC combinations supported by the UEs are indicated by the colors. For example,
UE D supports all EN-DC combinations, whereas UE A only supports LTE2 + NR1.

The behavior of each UE is shown in Table 9-11.

Table 9-11 – ENDCHO – Interaction of UE Capability, Priority and Coverage
UE Measurement Order Behavior
UE_A1 1) B1→NR2 UE reports NR2 and sets up EN-DC on serving cell.
UE_A2 1) B1→NR2 UE has no coverage from NR2, the measurement times out
and EN-DC cannot be set up.
UE_A3 1) B1→NR2 + A5→LTE2 UE reports NR2 and LTE2 and performs ENDCHO
UE_A4 1) B1→NR2 + A5→LTE2 UE reports LTE2 but has no coverage from NR2, the B1
measurement times out and EN-DC cannot be set up.
UE_B1 1) B1→NR1 + A5→LTE1 UE reports NR1 and LTE1 and performs ENDCHO.
UE_B2 1) B1→NR1 + A5→LTE1 UE reports NR1 and LTE1 and performs ENDCHO.
UE_B3 1) B1→NR1 UE reports NR1 and sets up EN-DC on serving cell.
UE_B4 1) B1→NR1 UE reports NR1 and sets up EN-DC on serving cell.
UE_C1 1) B1→NR2 UE reports NR2 and sets up EN-DC on serving cell.
2) B1→NR1 + A5→LTE1 Second measurements are never configured.
UE_C2 1) B1→NR2 UE has no coverage from NR2 and the first measurement
2) B1→NR1 + A5→LTE1 times out.
UE reports NR1 and LTE1 and performs ENDCHO.
UE_C3 1) B1→NR2 + A5→LTE2 UE reports NR2 and LTE2 and performs ENDCHO
2) B1→NR1 Second measurement is never configured.
UE_C4 1) B1→NR2 + A5→LTE2 UE reports LTE2 but has no coverage from NR2 and the
2) B1→NR1 first B1 measurement times out.
UE reports NR1 and sets up EN-DC on the serving cell.
UE_D1 1) B1→NR2 UE reports NR2 and sets up EN-DC on serving cell.
2) B1→NR1 Second measurement is never configured
UE_D2 1) B1→NR2 UE has no coverage from NR2 and the first measurement
2) B1→NR1 times out.
UE reports NR1 and sets up EN-DC on serving cell.
UE_D3 1) B1→NR2 UE reports NR2 and sets up EN-DC on serving cell.
2) B1→NR1 Second measurement is never configured.
UE_D4 1) B1→NR2 UE has no coverage form NR2 and the first measurement
2) B1→NR1 times out.
UE reports NR1 and sets up EN-DC on serving cell.

The key takeaways for ENDCHO are:

• ENDCHO enables a UE to access EN-DC using an NR frequency which the UE cannot

use for EN-DC in combination with the serving cell.

• For a particular UE, a given NR frequency is considered as a candidate for either

ENDCHO or SN addition on the serving cell, never both.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 146 (179)
 5G Mobility and Traffic Management Guideline

• If a UE can use EN-DC on the serving LTE cell in combination with all configured NR
frequencies, then ENDCHO will never occur for that UE, regardless of coverage or
priority settings.

• The preference among the NR frequencies is determined by the order of the

measurements, which is controlled by
GUtranFreqRelation.endcB1MeasPriority. The timeouts involved with
measuring multiple frequencies can be reduced through the careful choice of priorities,
as described in 9.2.1.2.

• To maximize EN-DC availability, ensure that all NR cells which cover the serving LTE
cell have a GUtranFreqRelation defined, with endcB1MeasPriority not equal to
-1 and a GUtranCellRelation.

9.2.13.2 ENDCHO Parameters

The key parameters for this feature are:

Table 9-12 – Parameters for EN-DC Triggered Handover During Setup
Attribute Values (default) Description
(RAT, MO) [unit]
endcB1MeasPriority -1, 0 to 7 NR frequency priority for EN-DC
(LTE, GUtranFreqRelation) (4) measurements.
Highest priority is 7. Lowest priority is 0.
Value -1 means that the frequency is excluded.
Frequencies with the same priority are
selected randomly.
endcHoFreqPriority -1, 0 to 7 (7) LTE frequency priority for EN-DC Triggered
(LTE, EUtranFreqRelation) Handover During Setup. Highest priority is 7.
Lowest priority is 0.
Value -1 means that the frequency is excluded.
Frequencies with the same priority are
selected randomly.
endcMeasTime -1, 40 to 120000 Time in which UE performs measurements
(LTE, UeMeasControl) (2000) [ms] requested in each RRC reconfiguration
message for EN-DC.
Value -1 means infinity.
endcMeasRestartTime -1, 0 to 240000 Time to wait for next B1 array (up to three
(LTE, UeMeasControl) (-1) [ms] batches of B1 measurement configuration) for
EN-DC.

Value -1 means B1 array will not be restarted.

a5Threshold1Rsrp -140 to -44 (-140) Serving cell RSRP threshold for A5. Used only
(LTE, ReportConfigA5EndcHo) [dBm] if triggerQuantityA5 is set to RSRP.
a5Threshold2Rsrp -140 to -44 (-136) Target cell RSRP threshold for A5. Used only if
(LTE, ReportConfigA5EndcHo) [dBm] triggerQuantityA5 is set to RSRP.
a5Threshold1Rsrq -195 to -30 (-195) Serving cell RSRQ threshold for A5. Used only
(LTE, ReportConfigA5EndcHo) resolution 5 if triggerQuantityA5 is set to RSRQ.
[0.1 dBm]
a5Threshold2Rsrq -195 to -30, Target cell RSRQ threshold for A5. Used only
(LTE, ReportConfigA5EndcHo) resolution 5 if triggerQuantityA5 is set to RSRQ.
[0.1 dBm]
(-195)

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 147 (179)
 5G Mobility and Traffic Management Guideline

Attribute Values (default) Description

(RAT, MO) [unit]
reportAmountA5 0, 1, 2, 4, 8, 16, 32, Number of reports for periodical reporting for
(LTE, ReportConfigA5EndcHo) 64 event A5 measurement. 0 means that reports
(0) are sent as long as the event is fulfilled.
reportIntervalA5 Various values from Interval for event-triggered periodical reporting
(LTE, ReportConfigA5EndcHo) 120 ms to 60 min for event A5 measurement.
(480 ms)
triggerQuantityA5 RSRP, RSRQ Quantity that triggers event A5 for event A5
(LTE, ReportConfigA5EndcHo) (RSRP) measurement.
timeToTriggerA5 0,40,64,80,100128,16 Time-to-trigger value for event A5. Used for
(LTE, ReportConfigA5EndcHo) 0,256, 320,480,512 both RSRP and RSRQ.
640,1024,12802560,
5120 (100) [ms]
hysteresisA5 0 to 150, (10) The hysteresis value for event A5
(LTE, ReportConfigA5EndcHo) resolution 5 measurement.
[0.1 dB]

9.2.14 Basic EN-DC Triggered Handover During Setup (FAJ 121 5125)

Note: This licensed eNodeB feature is for DU Radio Nodes. The corresponding feature for
Baseband Radio Nodes is EN-DC Triggered Handover During Setup (Section 9.2.13).

This feature is similar to EN-DC Triggered Handover During Setup. The differences are as
follows:

• No B1 measurement is configured in the UE to check for NR coverage; only an A5

measurement, to check for LTE coverage, is configured.

• When determining which frequencies to measure for A5, the eNodeB considers the
EUTRA capability of the UE. It does not consider the EN-DC capability of the UE.

• The A5 measurements use the a5Threshold1Rsrp, a5Threshold2Rsrp,

hysteresisA5 values in ReportConfigEUtraInterFreqLb MO. Other
parameters are hard-coded: for example, time-to-trigger = 100ms, report interval =
480ms.

• If the frequencies to be measured for A5 do not fit within a single RRC reconfiguration
message, then the eNodeB divides them into up to three messages, in order of
EndcHoFreqPriority. These RRC reconfiguration messages are separated in time
by 2100 ms, assuming no valid A5 report is received first.

• In a baseband node, ENDCHO can be triggered from a cell which the UE can use for
EN-DC. This is not possible in a DU radio node, as the node does not support EN-DC.

9.2.15 Enhanced NR Restriction (FAJ 121 5212)

This licensed eNodeB feature allows access to EN-DC to be controlled per NR frequency
range. It modifies how the eNodeB handles the “NR Restriction in EPS as Secondary RAT”
information element in the Handover Restriction List (HRL), as follows:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 148 (179)
 5G Mobility and Traffic Management Guideline

• If this feature is not active, UEs which have the NR restriction in the HRL are
completely prevented from using EN-DC.

• If this feature is active, UEs which have the NR restriction may access EN-DC on FR1
(low-band and mid-band) NR frequencies, but are prevented from accessing EN-DC on
FR2 (high-band) NR frequencies. This allows an operator who has both FR1 and FR2
to reserve the FR2 spectrum for “prioritized” users only; namely users that do not have
the NR restriction. To achieve this outcome, the Enhanced NR Restriction feature
removes the FR2 bands from the capability enquiry message that it sends to the UE;
which makes the UE appear incapable of FR2.

This feature is provided because 3GPP does not currently support EN-DC restriction at the
frequency range level.

9.2.16 EN-DC Triggered Handover During Connected Mode Mobility (FAJ 121 5243)

This licensed eNodeB feature is similar to the feature EN-DC Triggered Handover During
Setup, but instead triggers EN-DC triggered handover (ENDCHO) at an incoming handover
(either IRAT or intra-LTE) and at RRC re-establishment in LTE. Apart from the different
trigger, the two features follow the same procedures; refer to Section 9.2.13 for details.

Figure 9-8 gives two examples of EN-DC triggered handover during connected mode
mobility. Note that the figure is designed purely to illustrate the functionality; it does not
illustrate a recommended configuration.

Figure 9-8 – EN-DC Triggered Handover During Connected Mode Mobility

Consider the two UEs shown in Figure 9-8, A and B. The colors show which band
combinations the UEs support for EN-DC; namely LTE1 + NR1 and LTE2 + NR2. It is the
limited band combination capability which causes the EN-DC triggered handovers.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 149 (179)
 5G Mobility and Traffic Management Guideline

UE A: This shows an example where coverage from the highest priority NR frequency
runs out, so ENDCHO sends the UE to an LTE cell where it can set up EN-DC with
a lower priority NR frequency. The UE starts on the left, where it has EN-DC using
LTE2A + NR2A. As the UE moves out of NR2A coverage, it loses EN-DC and
eventually the intra-frequency handover between the LTE2A and LTE2B occurs.
After the handover, the UE is configured with a B1 measurement for NR2 (the
higher priority NR frequency) for SN addition. However, there is no coverage from
NR2, so this measurement times out. The UE is reconfigured with a B1
measurement for NR1 (the lower priority NR frequency) and an A5 measurement
for LTE1. The UE finds NR1 and A5 LTE1 and reports both, and an ENDCHO
occurs to LTE1 B. The B1 measurement report for NR1 is forwarded to the target
LTE1 B, the SN addition is initiated after the LTE Handover.

UE B: This shows an example where ENDCHO sends the UE to an LTE cell where it can
set up EN-DC with a higher priority NR frequency. The UE starts on the right, where
it has EN-DC using LTE1B and NR1A (the lower priority NR frequency). As the UE
moves to the left it enters the coverage of NR2, which has a higher priority.
Eventually an intra-frequency handover from LTE1B to LTE1A occurs. After the
handover, the UE is configured with a B1 measurement for NR2 (the higher priority
NR frequency) and an A5 measurement for LTE2. The UE finds NR2 and LTE2 and
reports both, which triggers the EN-DC triggered handover from LTE1A to LTE2A.
The B1 measurement report for NR2 is forwarded to the target LTE2A, the SN
addition is initiated after the LTE Handover.

9.2.17 Automatic Neighbor Relations (FAJ 121 0497)

This licensed eNodeB feature enables the automatic creation and removal of the managed
objects associated with neighbor relations.

This section covers ANR for the relations from LTE to NR, which are used for EN-DC.
Specifically, it covers:

• Enabling ANR for EN-DC Relations

• Neighbor Addition for Low-Band and Mid-Band NR Cells

• Neighbor Addition for High-Band NR Cells

• Neighbor Removal

The remaining ANR functions are described in the LTE Mobility and Traffic Management
Guideline in CPI.

9.2.17.1 Enabling ANR for EN-DC Relations

To enable ANR, perform the following:

• In the eNodeB:

– Activate the feature license for Automated Neighbor Relations (FAJ 121 0497)

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 150 (179)
 5G Mobility and Traffic Management Guideline

– Set ANRFunctionNR.anrStateNR = 1 (ACTIVATED)

– Set GUtranFreqRelation.anrMeasOn = true

– Set ENodeBFunction.endcX2IpAddrViaS1Active = true

• In the gNodeB:

– Set NRCellDU.secondaryCellOnly = false, to enable SIB1 broadcast

– Set NRCellDU.configuredEpsTAC to a valid value. Note that this EPS TAC is

not broadcast and differs from the 5G System TAC.

• The MME must support X2 TNL Address Discovery via S1 based on TS 36.413
V15.5.0 or a later revision.

• The UE must support reportCGI-NR-NoEN-DC-r15 in UE-EUTRA-Capability

9.2.17.2 Neighbor Addition for Low-Band and Mid-Band NR Cells

With ANR enabled, the procedure for neighbor addition for Low-Band and Mid-Band NR
cells is as follows:

• The eNodeB receives, from the UE, a B1 report containing a PCI which does not have
a corresponding GUtranCellRelation.

• The eNodeB de-configures the B1 measurement and configures a measurement in the

UE to determine the NR Cell Global Identity (an NCGI measurement)

– However, if the UE has a voice call in progress (namely serviceType = VOIP, PTT
or MC_SIGNALING), the NCGI measurement cannot be configured, and the B1
report is discarded.

• The eNodeB receives, from the UE, the report containing the NCGI:

– If the gNodeB is unknown, then the eNodeB creates ExternalGNodeBFunction

under GUtraNetwork, and TermPointToGNB under
ExternalGNodeBFunction; which triggers X2 setup.

• To acquire the IP address of the gNodeB, the eNodeB uses the X2 TNL
Address Discovery Procedure on the S1 interface to the MME. This procedure
requires that at least one EN-DC X2 is already manually defined from another
eNodeB to the gNodeB, within the same MME.

– If the NR cell is unknown, then the eNodeB creates ExternalGUtranCell under

ExternalGNodeBFunction. Note that ExternalGUtranCell MOs can also be
created during X2 configuration, but this is unrelated to ANR.

– If the NR cell does not have a corresponding GUtranCellRelation under the

EUtranCellFDD/TDD.GUtranFreqRelation, then the eNodeB creates it.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 151 (179)
 5G Mobility and Traffic Management Guideline

– Creation (or removal) of a cell relation can trigger an automatic update of the upper
layer indication, as described in Section 9.2.1.4.

– The eNodeB reconfigures the B1 measurement in the UE to detect NR coverage,

as described in Section 9.2.1.2. A new B1 report must be received to trigger EN-DC
setup.

– Note: For the current software release, check the release notes for compatibility of
ANR with ESS NSA.

9.2.17.3 Neighbor Addition for High-Band Cells

The procedure for neighbor addition by ANR for High-Band is different, because some UE
vendors do not support the NCGI measurement on High-Band. The procedure is as
follows:

• The eNodeB receives, from the UE, a B1 report containing a PCI which does not have
a corresponding GUtranCellRelation.

• If no ExternalGUtranCell exists for the reported PCI, then the B1 report is

discarded.

• If an ExternalGUtranCell exists for the reported PCI, then the ENodeB creates a
corresponding GUtranCellRelation under the
EUtranCellFDD/TDD.GUtranFreqRelation

• A new B1 report must be received to trigger EN-DC setup.

• Creation (or removal) of a cell relation can trigger an automatic update of the upper
layer indication, as described in Section 9.2.1.4.

9.2.17.4 Neighbor Removal

The procedure for neighbor removal by ANR, for all of Low-Band, Mid-Band and High-Band
NR cells is as follows:

• GUtranCellRelation is removed if:

– GUtranCellRelation.isRemoveAllowed = true

– GUtranCellRelation.essEnabled = false

– The relation has not been used for EN-DC setup for
AnrFunction.removeNrelTime (default 7 days)

• ExternalGUtranCell is removed if:

– ExternalGUtranCell.isRemoveAllowed = true

– ExternalGUtranCell is unused for AnrFunction.removeNcellTime (default

30 days)

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 152 (179)
 5G Mobility and Traffic Management Guideline

– Note: ANR cannot create (or re-create) ExternalGUtranCell MOs for NR High-
Band cells. Therefore, to prevent their removal by ANR, set isRemoveAllowed =
False.

• TermPointToGNB is removed when the last ExternalGUtranCell is removed from

the parent ExternalGNodeBFunction

• ExternalGNodeBFunction is removed when no child ExternalGUtranCell exists

for AnrFunction.removeNgnbTime (default 7 days)

9.2.18 Multiple Frequency Band Indicators (FAJ 121 3054)

In LTE, frequencies are grouped together into bands, as defined by 3GPP. Some of these
bands overlap each other, so a given physical frequency can belong to more than one
frequency band. If it does, the frequency is represented by a different EARFCN for each
band that it belongs to. When a UE connects to the network, it tells the network which
bands and band combinations it supports. In the case of overlapping frequency bands, it is
possible that the UE supports only one of the overlapping bands, and not the other(s). If so,
the UE cannot use cells on the non-supported band. However, if the feature Multiple
Frequency Band Indicators (MFBI) is enabled, then the UE can use the cell on an
overlapping band.

Consider the overlapping frequency band example shown in Figure 9-9. The UE is unable
to use the cell on the configured EARFCN_X, because the UE does not support Band_X.
However, if MFBI is enabled, then the UE can use the cell on EARFCN_Y as a Band_Y
cell; it can use an overlapping band. MFBI also allows the use of overlapping bands when
configuring UE measurements on other frequencies, when directing a UE to a new target
cell and (of particular relevance to this guideline) when setting up EN-DC, as explained in
Section 9.2.1.

Figure 9-9 – Overlapping Frequency Bands

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 153 (179)
 5G Mobility and Traffic Management Guideline

9.2.19 Inter Vendor EN-DC Triggered Handover During Setup

This is a licensed Baseband Radio Node feature in the Inter-Vendor Load Management
value package (FAJ 801 0416).

The feature enables EN-DC Triggered Handover to a target cell that is inter vendor (non-
Ericsson) or to an Ericsson external cell (without an X2 connection).

The feature can trigger ENDCHO only when it is not possible for the UE to set up EN-DC in
the serving LTE cell; for example, because the UE does not support the configured EN-DC
band combinations.

The triggering points for the feature are during Initial Context Setup and incoming
Handover (LTE and IRAT).

During EN-DC Triggered Handover to non-Ericsson eNodeB the B1 measurement results

will be forwarded to the target LTE cell.

9.3 gNodeB Features

This section lists features implemented in the gNodeB that are important for 5G Mobility &
Traffic Management.

9.3.1 LTE-NR Dual Connectivity (FAJ 121 4908)

This is an unlicensed gNodeB feature in the NR RAN Base Package (FAJ 801 4002).

The LTE-NR Dual Connectivity feature introduces the basic support for EN-DC in the
gNodeB used in a non-standalone deployment. The counterpart feature on the eNodeB
side is the feature Basic Intelligent Connectivity (FAJ 121 4843).

The feature covers the fundamental interaction between LTE and NR in the EN-DC
context. For example, setting up and releasing SN Terminated bearers in EN-DC.

Other supported functions include:

• Packet forwarding at SN addition

• Support of VoLTE services

• Support of NR Restriction, which can prevent establishment of an SN Terminated

bearer for specific UEs

• Support of legacy LTE mobility, which causes release of the SN Terminated bearer

• Support of measurement-based SN addition

• Support of LTE RRC re-establishment with SN Terminated Split Bearer

• EN-DC secondary RAT data usage reporting to the core network. This enables
observability of the data volume transmitted using SCG resources. When configuring

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 154 (179)
 5G Mobility and Traffic Management Guideline

this reporting, set GNBCUUPFunction.endcDataUsageReportEnabled and

ENodeBFunction.endcDataUsageReportEnabled to the same value. A mismatch
can delay mobility due to nodes waiting for messages which are not sent.

• Support of A2-triggered Secondary Node Initiated Secondary Node Release

Refer to the CPI document LTE-NR Dual Connectivity for more information.

9.3.2 Uplink-Downlink Decoupling (FAJ 121 4909)

This is an unlicensed gNodeB feature in the NR RAN Base Package (FAJ 801 4002).

This feature introduces the basic support for configuring the downlink (DL) and uplink (UL)
on the MCG and SCG resources independently as well as dynamically switching between
them, as described in Section 5.3.2 and Section 5.3.3.

Note that the UL dynamic switching of the user plane between MCG and SCG resources
(LTE and NR) is controllable on the cell level via
NRCellDU.endcUlLegSwitchEnabled.

The UL SINR quality threshold, NRCellDU.endcUlNrLowQualThresh,has

recommended parameter settings depending on the operating NR band, for example low-
band, mid-band or high-band. Refer to the CPI document RAN Parameter
Recommendations.

The feature provides for example improved NR coverage by using the coverage benefits of
the LTE UL on a lower FDD band as described in Section 5.3.1.

Refer to the CPI document LTE-NR Dual Connectivity for more information.

9.3.3 NR Mobility (FAJ 121 5041) – SA and NSA

This is an unlicensed gNodeB feature in the NR RAN Base Package (FAJ 801 4002).

The purpose of the NR Mobility feature is to manage the UE in RRC_CONNECTED mode.

Note: In the current software release, the procedures for NR mobility may depend on the
frequency band. Refer to the CPI documents NR Mobility and NR RAN Feature Status for
more information.

The feature contains the following functionalities:

9.3.3.1 NSA Intra-Frequency PSCell change

This functionality allows EN-DC configured UEs with SCG resources to perform intra-
frequency Event A3 measurement in RRC_CONNECTED mode. When an Event A3
measurement report is received by the gNodeB, PSCell change is triggered, as described
in Section 6.3.1.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 155 (179)
 5G Mobility and Traffic Management Guideline

9.3.3.2 SA Idle Mode

This functionality enables broadcast of System Information in NR SA cells, which enables

cell selection and reselection in NR SA, as described in Section 7.1.

9.3.3.3 NR SA Intra-frequency Mobility

This functionality enables intra-frequency mobility using Event A3 (neighbor NR cell

becomes offset better than the NR serving cell) for UEs connected to an NR SA cell, as
described in Section 7.2.2.

9.3.3.4 NR to LTE Session Continuity

This functionality enables an SA user to perform a blind release-with-redirect from NR to

LTE when the UE enters bad NR coverage. The release-with-redirect is triggered when the
UE sends an Event A2 measurement report, as described in Section 7.2.3.

9.3.4 LTE-NR Downlink Aggregation (FAJ 121 4912)

This is a licensed gNodeB feature in the gNodeB in the value package Peak Rate Evolution
(FAJ 801 4005).

The feature enables transmission of downlink user plane data simultaneously on both the
MCG and SCG resources of an SN Terminated Split Bearer. Different packets are sent on
the two cell groups. The feature improves the end user throughput.

An overview of this feature, and its relation to downlink user plane switching, is provided in
Section 5.3.4.

Refer to the CPI document LTE-NR Downlink Aggregation for more information.

9.3.5 LTE-NR Uplink Aggregation (FAJ 121 5091)

This is a licensed gNodeB feature in the value package Peak Rate Evolution (FAJ 801
4005).

The feature enables transmission of uplink user plane data (PDCP layer) simultaneously
on both the MCG and SCG resources of an SN Terminated Split Bearer. The feature
improves the end user throughput.

An overview of this feature, and its relation to uplink user plane switching, is provided in
Section 5.3.5.

Refer to the CPI document LTE-NR Uplink Aggregation for more information.

9.3.6 EPS Fallback to IMS Voice (FAJ 121 5059)

This is an unlicensed gNodeB feature in the NR RAN Base Package (FAJ 801 4002).

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 156 (179)
 5G Mobility and Traffic Management Guideline

This feature enables fallback to LTE for an NR SA connected UE to an LTE connection

when a voice call is made.

It is redirected to LTE with the help of the release-with-redirect mechanism.

Refer to the CPI document Fallback to LTE for Voice for more information.

9.3.7 Service Request-Based Emergency Fallback (FAJ 121 5166)

This is an unlicensed gNodeB feature in the NR RAN Base Package (FAJ 801 4002).

The feature allows UEs to send a Service Request (NAS) to indicate an emergency call.
Upon receiving the request, the Access and Mobility Management Function (AMF) instructs
the gNodeB to perform an emergency fallback. The gNodeB then instructs the UE to
perform a release-with-redirect to a selected LTE frequency. For more detail see Section
7.2.5.

9.3.8 RAN Slicing Framework (FAJ 121 5095)

This is a licensed gNodeB feature in the package RAN Slicing (FAJ 801 4015).

The feature enables RAN slicing and adds new configurations to the Single-Network Slice
Selection Assistance Information (S-NSSAI) list.

The feature also enables the S-NSSAI in PDU sessions and slice-aware Core Network
instance selection. Additionally, the feature supports the following functionalities with the
RanSlicingFramework license:

• Slice-aware QoS mapping framework

• Slice-aware NG-based handover

Refer to the CPI documents RAN Slicing Framework and NR SA Network Slicing
Guidelines for more information.

9.4 MME Features

This section lists selected MME features implemented that are important for 5G Mobility &
Traffic Management.

9.4.1 UE Dual Connectivity Support (FAT 102 3381/2116)

This is a licensed MME feature and a pre-requisite for successful Dual Connectivity
operation.

The UE Dual Connectivity Support feature allows eNodeB to switch user plane tunnels
between LTE and NR for devices in connected state. This is enabled by the E-RAB
Modification Indication procedure between the eNodeB, MME and the SGW.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 157 (179)
 5G Mobility and Traffic Management Guideline

If the feature is not ACTIVATED, the SGSN-MME handles a received E-RAB Modification
Indication message as unknown/unsuccessful and responds with an Error Indication
message and Cause IE Message Not Compatible With Receiver State.

For further information on this feature refer to the SGSN-MME 5G EPC Feature
Description.

9.4.2 NR Access Control (FAT 102 3381/2119)

This is a licensed MME feature and a pre-requisite for successful Dual Connectivity
operation.

The NR Access Control feature enables NR Capable UEs connected to the EPC, to use
NR as a secondary RAT.

Based on the NR Access Control feature state, UE support for NR, HSS subscription data
and local SGSN-MME configuration, a decision is made on whether NR access is restricted
or not.

NR access is allowed only in the following scenarios:

• The NR Access Control license is enabled and the feature is activated

• The UE supports NR

• The HSS subscription data does not restrict NR

• The MME has no local configuration that restricts NR for the subscriber

The eNodeB receives the information in the “NR Restriction in EPS as Secondary RAT” IE
in the Handover Restriction List IE in the Initial Context Setup Request, Handover Request,
and Downlink NAS Transport messages. The “NR Restriction in EPS as Secondary RAT “
IE is included only if NR is restricted for the UE.

The NR base package feature LTE-NR Dual Connectivity (FAJ 121 4908) includes support
for NR Access Control (referred to as NR Restriction).

For further information on this feature refer to the SGSN-MME 5G EPC Feature
Description.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 158 (179)
 5G Mobility and Traffic Management Guideline

10 Appendix 2 – Mobility Trigger Levels

This section provides formulas for the effective trigger levels of various mobility cases. It
focusses on those mobility cases which are new with 5G. Legacy LTE mobility cases are
described in the CPI document LTE Mobility and Traffic Management Guideline.

The formulas use the following notation:

(node)MO_Class.Parameter

For example:

(eNB)ReportConfigB1GUtra.triggerQuantityB1

When using these formulas, note the following:

• The formulas refer to the Ericsson parameter values with their sign as set in the node.
For example, if offset = -30 (-3dB) then use the value -30 in the formula. The
formula includes the appropriate conversion, so that the results are in dBm (SS_RSRP,
RSRP) or dB (SS_RSRQ, RSRQ, SINR or RSRP delta). Any exceptions to this are
noted (e.g. sIntraSearch = 1000, which means not sent).

• For connected mode transitions, the event is triggered when the entry level is satisfied
for the relevant time-to-trigger. More detailed descriptions of the how the various
events are entered and triggered are provided in Section 4.7.5.

• In general, this section covers only the triggering levels themselves, not the criteria
which determine when a particular trigger applies. For more details on triggering criteria
refer to the relevant sections in this document or the feature descriptions in CPI.

• For LTE, the formulas shown here are for LTE FDD cells. The formulas for TDD can be
obtained by replacing EUtranCellFDD with EUtranCellTDD.

• This section assumes that the UE is capable of LTE, NR NSA and NR SA.

• The parameter qOffsetFreq impacts both idle connected mode triggering. However,
note that it is used with a different sign in idle and connected modes.

10.1 Idle Mode

The idle mode formulas presented in the following sections assume the following:

• Higher priority PLMN offsets do not apply (which is normally the case). More
specifically this means:

– The 3GPP parameter Qrxlevminoffset = 0, which occurs if either qRxLevMinOffset =

1000 (default value) or the cell is not being evaluated as a result of a search for a
higher priority PLMN, and

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 159 (179)
 5G Mobility and Traffic Management Guideline

– The 3GPP parameter Qqualminoffset = 0, which occurs if either qQualMinOffset = 0

(default value), or the cell is not being evaluated as a result of a search for a higher
priority PLMN.

• The UE is capable of the maximum transmit power allowed in the cell (which is
normally the case). More specifically this means:

– For the serving cell, the 3GPP parameter Pcompensation = 0, which occurs if either
pMaxServingCell = 1000 (default value), or if the UE is capable of the power
indicated by pMaxServingCell.

– For a neighbor cell, the 3GPP parameter Pcompensation = 0, which occurs if either
pMax = 1000 (default value), or if the UE is capable of the power indicated by
pMax.

• Speed dependent scaling does not apply.

• The UE is capable of both NR SA and LTE.

10.1.1 Cell Selection

Given the simplifying assumptions in Section 10.1, cell selection is performed as follows.

The UE can select an NR SA cell when:

SS_RSRPNR > (gNB)NRCellDU.qRxLevMin

and

SS_RSRQNR > (gNB)NRCellDU.qQualMin

The UE can select an LTE cell when:

RSRPLTE > (eNB)EUtranCellFDD.qRxLevMin

and, if the UE is capable of RSRQ based evaluation (mandatory in 3GPP Release 9),

RSRQLTE > (eNB)EUtranCellFDD.qQualMin

10.1.2 Criteria to Conduct Measurements for Intra-Frequency Cell Reselection

Given the simplifying assumptions for idle mode in Section 10.1, measurements for cell
reselection are performed as follows.

If camped on NR SA, the UE must perform intra-frequency measurements when:

SS_RSRPServingCell < (gNB)NRCellDU.qRxLevMin

+ (gNB)NRFreqRelation.sIntraSearchP

or

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 160 (179)
 5G Mobility and Traffic Management Guideline

SS_RSRQServingCell < (gNB)NRCellDU.qQualMin

+ (gNB)NRFreqRelation.sIntraSearchQ

If camped on LTE, the UE must perform intra-frequency measurements when:

RSRPServingCell < (eNB)EUtranCellFDD.qRxLevMin

+ (eNB)EUtranCellFDD.systemInformationBlock3.sIntraSearch

or alternately (if sIntraSearchv920Active = true, and the UE is Release 9

onwards) when:

RSRPServingCell < (eNB)EUtranCellFDD.qRxLevMin

+ (eNB)EUtranCellFDD.systemInformationBlock3.sIntraSearchP

or

RSRQServingCell < (eNB)EUtranCellFDD.qQualMin

+ (eNB)EUtranCellFDD.systemInformationBlock3.sIntraSearchQ

Note that if sIntraSearch = 1000, the UE applies the default value of infinity (always
measure).

If the above conditions are not met, then the UE may choose not to perform intra-frequency
measurements.

10.1.3 Intra-Frequency Cell Reselection

Given that idle-mode measurements are being performed (see Section 10.1.2), reselection
occurs as follows.

If camped on NR SA, reselection occurs when:

SS_RSRPtarget - SS_RSRPsource > (gNB)NRCellCU.qHyst

and

SS_RSRPtarget > (gNB)NRFreqRelation.qRxLevMin

and

SS_RSRPtarget > (gNB)NRFreqRelation.qQualMin

for a time of (gNB)NRFreqRelation.tReselectionNR, (default 2 s)

If camped on LTE, reselection occurs when:

RSRPtarget - RSRPsource >

(eNB)EUtranCellFDD.systemInformationBlock3.qHyst
+ (eNB)EUtranCellRelation.qOffsetCellEUtran

and

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 161 (179)
 5G Mobility and Traffic Management Guideline

RSRPtarget > (eNB)EUtranFreqRelation.qRxLevMin

and, if the UE is capable of RSRQ based evaluation (mandatory in 3GPP Release 9),

RSRQtarget > (eNB)EUtranFreqRelation.qQualMin

for a time of (eNB)EUtranFreqRelation.tReselectionEutra, (typically 2 s)

10.1.4 Criteria to Conduct Measurements for Inter-Frequency and Inter-RAT Cell

Reselection

In idle mode, the UE must always measure frequencies with higher

cellReselectionPriority than the serving frequency.

If camped on NR SA, the UE must measure frequencies with

cellReselectionPriority equal to or lower than the current frequency when:

SS_RSRPServingCell < (gNB)NRCellDU.qRxLevMin

+ (gNB)NRCellCU.sNonIntraSearchP

or

SS_RSRQServingCell < (gNB)NRCellDU.qQualMin

+ (gNB)NRCellCU.sNonIntraSearchQ

If sNonIntraSearchP or sNonIntraSearchQ is empty, then the UE applies the

default value of infinity (always measure).

If the above conditions are not met, then the UE can choose not to measure equal or
lower priority frequencies.

If camped on LTE, the UE must measure frequencies with cellReselectionPriority

equal to or lower than the current frequency when:

RSRPServingCell < (eNB)EUtranCellFDD.qRxLevMin

+ (eNB)EUtranCellFDD.systemInformationBlock3.sNonIntraSearch

Or alternately (if sNonIntraSearchv920Active = true and the UE is Release 9

onwards) when:

RSRPServingCell < (eNB)EUtranCellFDD.qRxLevMin

+ (eNB)EUtranCellFDD.systemInformationBlock3.sNonIntraSearchP

or

RSRQServingCell < (eNB)EUtranCellFDD.qQualMin

+ (eNB)EUtranCellFDD.systemInformationBlock3.sNonIntraSearchQ

If sNonIntraSearch = 1000, the UE applies the default value of infinity (always

measure).

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 162 (179)
 5G Mobility and Traffic Management Guideline

If the above conditions are not met, then the UE can choose not to measure equal or
lower priority frequencies.

Frequencies can be made unavailable for reselection as follows:

• If (eNB)EUtranFreqRelation.cellReselectionPriority = -1 the frequency is

excluded from SIB5 and IMMCI, making it unavailable for cell reselection.

• If (eNB)GUtranFreqRelation.cellReselectionPriority = -1 the frequency is

excluded from SIB24 and IMMCI, making it unavailable for cell reselection.

• If (gNB)EUtranFreqRelation.cellReselectionPriority is set to empty, the

frequency is excluded from SIB5, making it unavailable for cell reselection.

• However, for (gNB)NRFreqRelation.cellReselectionPriority it is not

possible to set the value to -1 or empty.

10.1.5 Inter-Frequency Equal Priority Reselection

Given that idle-mode measurements are being performed (see Section 10.1.4), reselection
occurs as follows.

If camped on NR SA, reselection to an equal priority NR frequency (equal

(gNB)NRFreqRelation.cellReselectionPriority) occurs when:

SS_RSRPtarget - SS_RSRPsource >

(gNB)NRCellCU.qHyst - (gNB)NRFreqRelation.qOffsetFreq
and

SS_RSRPtarget > (gNB)NRCellDU.qRxLevMin

and

SS_RSRQtarget > (gNB)NRCellDU.qQualMin

for a time of (gNB)NRFreqRelation.tReselectionNR, (default 2 s)

If camped on LTE, reselection to an equal priority LTE frequency (equal

(eNB)EUtranFreqRelation.cellReselectionPriority) occurs when:

RSRPtarget - RSRPsource >

(eNB)EUtranCellFDD.systemInformationBlock3.qHyst
- (eNB)EUtranFreqRelation.qOffsetFreq
+ (eNB)EUtranCellRelation.qOffsetCellEUtran

and

RSRPtarget > (eNB)EUtranFreqRelation.qRxLevMin

and, if the UE is capable of RSRQ based evaluation (mandatory in 3GPP Release 9),

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 163 (179)
 5G Mobility and Traffic Management Guideline

RSRQtarget > (eNB)EUtranFreqRelation.qQualMin

for a time of (eNB)EUtranFreqRelation.tReselectionEutra, (typically 2 s)

Note that the criteria for equal-priority, inter-frequency cell reselection include the
parameter qOffsetFreq, whereas the criteria for intra-frequency cell reselection do not.

10.1.6 Inter-Frequency, Low to High Priority Reselection

Measurements on higher priority frequencies are always performed (see Section 10.1.4).

If camped on NR SA, reselection to a higher priority NR SA frequency (higher

(gNB)NRFreqRelation.cellReselectionPriority) occurs when:

SS_RSRPtarget > (gNB)NRFreqRelation.qRxLevMin

+ (gNB)NRFreqRelation.threshXHighP

or alternately, if threshServingLowQ is included in system information and more

than one second has elapsed since the UE camped on the serving cell:

SS_RSRQtarget > (gNB)NRFreqRelation.qQualMin

+ (gNB)NRFreqRelation.threshXHighQ

for a time of (gNB)NRFreqRelation.tReselectionNR (default 2 s).

If camped on LTE, reselection to a higher priority LTE frequency (higher

(eNB)EUtranFreqRelation.cellReselectionPriority) occurs when:

RSRPtarget > (eNB)EUtranFreqRelation.qRxLevMin

+ (eNB)EUtranFreqRelation.threshXHigh

or alternately, if threshServingLowQ is included in system information and more

than one second has elapsed since the UE camped on the serving cell:

RSRQtarget > (eNB)EUtranFreqRelation.qQualMin

+ (eNB)EUtranFreqRelation.threshXHighQ

for a time of (eNB)EUtranFreqRelation.tReselectionEUtra (default 2 s).

10.1.7 Inter-Frequency, High to Low Priority Reselection

Given that measurements are being performed (see Section 10.1.4):

If camped on NR SA, reselection to a lower priority NR SA frequency (lower

(gNB)NRFreqRelation.cellReselectionPriority) occurs when:

SS_RSRPsource < (gNB)NRCellCU.qRxLevMin

+ (gNB)NRCellCU.threshServingLowP

and

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 164 (179)
 5G Mobility and Traffic Management Guideline

SS_RSRPtarget > (gNB)NRFreqRelation.qRxLevMin

+ (gNB)NRFreqRelation.threshXLowP

or alternately, if threshServingLowQ is included in system information and more than

one second has elapsed since the UE camped on the cell:

SS_RSRQsource < (gNB)NRCellCU.qQualMin

+ (gNB)NRCellCU.threshServingLowQ

and

SS_RSRQtarget > (gNB)NRFreqRelation.qQualMin

+ (gNB)NRFreqRelation.threshXLowQ

for a time of (gNB)NRFreqRelation.tReselectionNR (default 2 s).

If camped on LTE, reselection to a lower priority LTE frequency (lower

(eNB)EUtranFreqRelation.cellReselectionPriority) occurs when:

RSRPsource < (eNB)EUtranCellFDD.qRxLevMin

+ (eNB)EUtranCellFDD.threshServingLow

and

RSRPtarget > (eNB)EUtranFreqRelation.qRxLevMin

+ (eNB)EUtranFreqRelation.threshXLow

or alternately, if threshServingLowQ is included in system information and more than

one second has elapsed since the UE camped on the cell:

RSRQsource < (eNB)EUtranCellFDD.qQualMin

+ (eNB)EUtranCellFDD.threshServingLowQ

and

RSRQtarget > (eNB)EUtranFreqRelation.qQualMin

+ (eNB)EUtranFreqRelation.threshXLowQ

for a time of (eNB)EUtranFreqRelation.tReselectionEUtra (default 2 s).

10.1.8 Inter-RAT, Low to High Priority Reselection

Measurements on higher priority frequencies are always performed (see Section 10.1.4).

If camped on NR SA and the LTE frequency has a higher priority (that is

(gNB)EUtranFreqRelation.cellReselectionPriority >
(gNB)NRFreqRelation.cellReselectionPriority), then reselection from NR SA to
LTE occurs when:

RSRPLTE_target > (gNB)EUtranFreqRelation.qRxLevMin

+ (gNB)EUtranFreqRelation.threshXHighP

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 165 (179)
 5G Mobility and Traffic Management Guideline

or alternately, if threshServingLowQ is included in system information and more

than one second has elapsed since the UE camped on the cell:

RSRQLTE_target > (gNB)EUtranFreqRelation.qQualMin

+ (gNB)EUtranFreqRelation.threshXHighQ

for a time of (gNB)EUtranFreqRelation.tReselectionEUtra (default 2 s).

Note that this case is unlikely to occur, as NR SA will typically have a higher
cellReselectionPriority than LTE.

If camped on LTE and the NR SA frequency has a higher priority (that is

(eNB)GUtranFreqRelation.cellReselectionPriority >
(eNB)EUtranFreqRelation.cellReselectionPriority), then reselection from LTE
to NR SA occurs when:

SS_RSRPNR_target > (eNB)GUtranFreqRelation.qRxLevMin

+ (eNB)GUtranFreqRelation.threshXHigh

or alternately, if threshServingLowQ is included in system information and more

than one second has elapsed since the UE camped on the cell:

SS_RSRQNR_target > (eNB)GUtranFreqRelation.qQualMin

+ (eNB)GUtranFreqRelation.threshXHighQ

for a time of (eNB)EUtranCellFDD.systemInformationBlock24.

tReselectionNR (default 2 s).

10.1.9 Inter-RAT, High to Low Priority Reselection

Given that measurements are being performed (see Section 10.1.4).

If camped on NR SA and the LTE frequency has a lower priority (that is

(gNB)NRFreqRelation.cellReselectionPriority >
(gNB)EUtranFreqRelation.cellReselectionPriority), then reselection from NR
SA to LTE occurs when:

SS_RSRPNR_Serving < (gNB)NRCellCU.qRxLevMin

+ (gNB)NRCellCU.threshServingLowP

and

RSRPLTE_Target > (gNB)EUtranFreqRelation.qRxLevMin

+ (gNB)EUtranFreqRelation.threshXLowP

for a time of (gNB)EUtranFreqRelation.tReselectionEUtra (default 2 s).

or alternately, if threshServingLowQ is included in system information and more than

one second has elapsed since the UE camped on the cell:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 166 (179)
 5G Mobility and Traffic Management Guideline

SS_RSRQNR_Serving < (gNB)NRCellCU.qQualMin

+ (gNB)NRCellCU.threshServingLowQ

and

RSRQLTE_Target > (gNB)EUtranFreqRelation.qQualMin

+ (gNB)EUtranFreqRelation.threshXLowQ

for a time of (gNB)EUtranFreqRelation.tReselectionEUtra (default 2 s).

If camped on LTE and the NR SA frequency has a lower priority (that is

(eNB)EUtranFreqRelation.cellReselectionPriority >
(eNB)GUtranFreqRelation.cellReselectionPriority), then reselection from LTE
to NR SA occurs when:

RSRPLTE_Serving < (eNB)EUtranCellFDD.qRxLevMin

+ (eNB)EUtranCellFDD.threshServingLow

and

SS_RSRPNR_Target > (eNB)GUtranFreqRelation.qRxLevMin

+ (eNB)GUtranFreqRelation.threshXLow

for a time of (eNB)EUtranCellFDD.systemInformationBlock24.

tReselectionNR (default 2 s).

or alternately, if threshServingLowQ is included in system information and more than

one second has elapsed since the UE camped on the cell:

RSRQLTE_Serving < (eNB)EUtranCellFDD.qQualMin

+ (eNB)EUtranCellFDD.threshServingLowQ

and

SS_RSRQNR_Target > (eNB)GUtranFreqRelation.qQualMin

+ (eNB)GUtranFreqRelation.threshXLowQ

for a time of (eNB)EUtranCellFDD.systemInformationBlock24.

tReselectionNR (default 2 s).

Note that this case is unlikely to occur, as NR SA will typically have a higher
cellReselectionPriority than LTE.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 167 (179)
 5G Mobility and Traffic Management Guideline

10.2 Connected Mode

10.2.1 Criteria to Commence Connected Mode Measurements

UEs in connected mode are required to perform any configured measurements when the
RSRP drops below sMeasure. There are two sMeasure parameters, one configured in
the eNodeB and the other in the gNodeB:

• The sMeasure parameter in the eNodeB applies to all Layer 3 measurements

configured by the eNodeB, including the Event B1 measurement used for detecting NR
coverage. UEs are required to make these measurements when:

RSRPLTE < (eNB)UeMeasControl.sMeasure

The default value is 0 which means disabled (always measure).

• The sMeasure parameter in the gNodeB applies to the Layer 3 measurements

configured by the gNodeB, namely the Events A2 and A3. UEs are required to make
these measurements when:

SS_RSRPNR < (gNB)UeMeasControl.sMeasure

The default value is ‘empty field’ which means disabled (always measure).
However, if the UE receives an empty field, then it will use the last previously received
value, if it has one. To ensure consistent behavior, it is therefore best to set sMeasure
to a non-empty value. The value -29 is a special value which means SS_RSRP =
infinity; always measure.

The UE may also measure when the RSRP or SS_RSRP exceeds sMeasure, but this is
not required by the standard.

10.2.2 Measurement-Based Secondary Node Addition - NSA

Secondary Node Addition is either measurement-based or configuration-based.

Measurement-based Secondary Node addition uses Event B1 to check for acceptable
coverage. The parameters to control this measurement are configured in the eNodeB.

If (eNB)ReportConfigB1GUtra.triggerQuantityB1 = SS_RSRP then Event B1 is

triggered when:

SS_RSRPNR > (eNB)ReportConfigB1GUtra.b1ThresholdRsrp

+ (eNB)GUtranFreqRelation.b1ThrRsrpFreqOffset
+ (eNB)ReportConfigB1GUtra.hysteresisB1 / 2

is fulfilled for: (eNB)ReportConfigB1GUtra.timeToTriggerB1

Alternately, if (eNB)ReportConfigB1GUtra.triggerQuantityB1 = SS_RSRQ then

Event B1 is triggered when:

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 168 (179)
 5G Mobility and Traffic Management Guideline

SS_RSRQNR > (eNB)ReportConfigB1GUtra.b1ThresholdRsrq / 10

+ (eNB)GUtranFreqRelation.b1ThrRsrqFreqOffset / 10
+ (eNB)ReportConfigB1GUtra.hysteresisB1 / 2

is fulfilled for: (eNB)ReportConfigB1GUtra.timeToTriggerB1

Ericsson recommends SS_RSRP as the trigger quantity for Event B1.

10.2.3 Release-With-Redirect from LTE to NR SA

Release-with-redirect from LTE to NR SA is enabled by the eNodeB feature NR Coverage-

Triggered NR Session Continuity, which uses Event B1 to check for acceptable NR SA
coverage.

If (eNB) ReportConfigB1NR.triggerQuantityB1NR = SS_RSRP then Event B1 is

triggered when:

SS_RSRPNR > (eNB) ReportConfigB1NR.b1ThresholdRsrp

+ (eNB)GUtranFreqRelation.qOffsetFreq
+ (eNB) ReportConfigB1NR.hysteresisB1 / 2

is fulfilled for: (eNB) ReportConfigB1NR.timeToTriggerB1

Alternately, if (eNB) ReportConfigB1NR.triggerQuantityB1NR = SS_RSRQ then

Event B1 is triggered when:

SS_RSRQNR > (eNB) ReportConfigB1NR.b1ThresholdRsrq / 10

+ (eNB)GUtranFreqRelation.qOffsetFreq
+ (eNB) ReportConfigB1NR.hysteresisB1 / 2

is fulfilled for: (eNB) ReportConfigB1NR.timeToTriggerB1

Ericsson recommends SS_RSRP as the trigger quantity for Event B1.

10.2.4 NR Intra-Frequency Mobility – NSA and SA

In both NSA and SA, intra-frequency measurements are conducted to find better NR cells.

NR Intra-frequency mobility always uses Event A3. The parameters to control this event
are configured in the gNodeB.

If (gNB)ReportConfigA3.triggerQuantity = RSRP then Event A3 is triggered when:

SS_RSRPtarget – SS_RSRPsource >

(gNB)ReportConfigA3.offset / 10
+ (gNB)ReportConfigA3.hysteresis / 10
- (gNB)NRCellRelation.cellIndividualOffsetNR

is fulfilled for: (gNB)ReportConfigA3.timeToTrigger

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 169 (179)
 5G Mobility and Traffic Management Guideline

Alternately, if (gNB)ReportConfigA3.triggerQuantity = RSRQ then Event A3 is

triggered when:

SS_RSRQtarget – SS_RSRQsource >

(gNB)ReportConfigA3.offset / 10
+ (gNB)ReportConfigA3.hysteresis / 10
- (gNB)NRCellRelation.cellIndividualOffsetNR

is fulfilled for: (gNB)ReportConfigA3.timeToTrigger

Ericsson recommends RSRP as the trigger quantity for Event A3.

10.2.5 Release-With-Redirect from NR SA to LTE

Release-with-redirect from NR SA to LTE is enabled by the Coverage-Triggered NR to LTE

Session Continuity function within the NR Mobility feature. This function configures A2
measurements in the UE to detect poor NR SA coverage.

If (gNB)ReportConfigA2.triggerQuantity = RSRP then Event A2 is triggered when:

SS_RSRPNR < (gNB)ReportConfigA2.thresholdRsrp

+ (gNB)ReportConfigA2.hysteresis / 10

is fulfilled for: (gNB)ReportConfigA2.timeToTrigger

Alternately, if (gNB)ReportConfigA2.triggerQuantity = RSRQ then Event A2 is

triggered when:

SS_RSRQNR < (gNB)ReportConfigA2.thresholdRsrq / 10

+ (gNB)ReportConfigA2.hysteresis / 10

is fulfilled for: (gNB)ReportConfigA2.timeToTrigger

Ericsson recommends RSRP as the trigger quantity for Event A2.

10.2.6 EN-DC Triggered Handover – NSA

The purpose of EN-DC Triggered Handover (ENDCHO) is to move the UE to an LTE cell
which is better suited to provide it with EN-DC.

The measurements configured for ENDCHO depend on which feature triggered it:

• EN-DC Triggered Handover During Setup (Section 9.2.13) and

EN-DC Triggered Handover During Connected Mode Mobility (Section 9.2.16)

These two features are for Baseband Radio Nodes. They configure both B1
measurements (to detect NR coverage) and A5 measurements (to detect LTE
coverage). To trigger the handover, the UE must first report an Event B1 for the NR cell
and then, within 240 ms, an Event A5 for an LTE cell that, together with the NR cell,
gives a valid frequency combination for ENDCHO.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 170 (179)
 5G Mobility and Traffic Management Guideline

• Basic EN-DC Triggered Handover During Setup (Section 9.2.14)

This feature is for DU Radio Nodes. It configures only A5 measurements to detect LTE
coverage. It does not configure B1 measurements.

The Event B1 is triggered according to 10.2.2.

For EN-DC Triggered Handover During Setup and EN-DC Triggered Handover During
Connected Mode Mobility the Event A5, is triggered as follows:

If (eNB)ReportConfigA5EndcHo.triggerQuantityA5 = RSRP, the report is triggered

when:

RSRPsource < (eNB)ReportConfigA5EndcHo.a5Threshold1Rsrp

– (eNB)ReportConfigA5EndcHo.hysteresisA5 / 10

and

RSRPtarget > (eNB)ReportConfigA5EndcHo.a5Threshold2Rsrp

+ (eNB)ReportConfigA5EndcHo.hysteresisA5 / 10
– (eNB)EUtranFreqRelation.qOffsetFreq
- (eNB)EUtranCellRelation.cellIndividualOffsetEUtran

are fulfilled for (eNB)ReportConfigA5EndcHo.timeToTriggerA5.

If (eNB)ReportConfigA5EndcHo.reportQuantityA5 = BOTH, then the following

additional check must be satisfied for handover to occur:

RSRQtarget > (eNB)ReportConfigA5EndcHo.a5Threshold2Rsrq / 10

+ (eNB)ReportConfigA5EndcHo.hysteresisA5 / 10

If (eNB)ReportConfigA5EndcHo.triggerQuantityA5 = RSRQ, the report is triggered

when:

RSRQsource < (eNB)ReportConfigA5EndcHo.a5Threshold1Rsrq / 10

– (eNB)ReportConfigA5EndcHo.hysteresisA5 / 10

and

RSRQtarget > (eNB)ReportConfigA5EndcHo.a5Threshold2Rsrq / 10

+ (eNB)ReportConfigA5EndcHo.hysteresisA5 / 10
– (eNB)EUtranFreqRelation.qOffsetFreq
- (eNB)EUtranCellRelation.cellIndividualOffsetEUtran

are fulfilled for (eNB)ReportConfigA5EndcHo.timeToTriggerA5.

If (eNB)ReportConfigA5EndcHo.reportQuantityA5 = BOTH, then the following

additional check must be satisfied for handover to occur:

RSRPtarget > (eNB)ReportConfigA5EndcHo.a5Threshold2Rsrp

+ (eNB)ReportConfigA5EndcHo.hysteresisA5 / 10

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 171 (179)
 5G Mobility and Traffic Management Guideline

For Basic EN-DC Triggered Handover During Setup the Event A5, is triggered when:

RSRPsource < (eNB)ReportConfigEUtraInterFreqLb.a5Threshold1Rsrp

– (eNB)ReportConfigEUtraInterFreqLb.hysteresisA5 / 10

and

RSRPtarget > (eNB)ReportConfigEUtraInterFreqLb.a5Threshold2Rsrp

+ (eNB)ReportConfigEUtraInterFreqLb.hysteresisA5 / 10
– (eNB)EUtranFreqRelation.qOffsetFreq
- (eNB)EUtranCellRelation.cellIndividualOffsetEUtran)

are fulfilled for the time-to-trigger, which is hard-coded to 100 ms.

For handover to occur, the following additional check must be satisfied, regardless of
the setting of (eNB)bothA5RsrpRsrq:

RSRQtarget > (eNB)ReportConfigEUtraInterFreqLb.a5Threshold2Rsrq / 10

+ (eNB)ReportConfigEUtraInterFreqLb.hysteresisA5 / 10

10.2.7 NR Coverage-Triggered Secondary Node Release

NR Coverage-Triggered Secondary Node Release is contained within the feature LTE-NR

Dual Connectivity and is enabled by setting: NRCellCU.mcpcEnabled = true and
McpcPSCellProfile.rsrpCriticalEnabled = true.

The release is initiated when the SN receives an A2 critical report from the UE. The report
is triggered when:

SS_RSRPNR < (gNB)McpcPSCellProfile.rsrpCritical.threshold

- (gNB)McpcPSCellProfile.rsrpCritical.hysteresis / 10

is fulfilled for: (gNB)McpcPSCellProfile.rsrpCritical.timeToTrigger

10.2.8 NR DL Carrier Aggregation

The features NR DL Carrier Aggregation and NR DL Carrier Aggregation for Coverage

Extension introduces the use of event A1 for NR SCell activation, event A2 for NR SCell
deactivation and event A6 for NR SCell change for FDD and TDD operation in the FR1
frequency bands (and not FR2).

The SCell activation is initiated when the SN receives an A1 report from the UE.

If (gNB)IntraFreqMCCellProfile.sCellCoverageTriggerQuantity = RSRP then

Event A1 is triggered when:

SS_RSRPSCell >
(gNB)IntraFreqMCCellProfile.rsrpSCellCoverage.threshold
+ (gNB)IntraFreqMCCellProfile.rsrpSCellCoverage.hysteresis / 10

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 172 (179)
 5G Mobility and Traffic Management Guideline

is fulfilled for:
(gNB)IntraFreqMCCellProfile.rsrpSCellCoverage.timeToTrigger

Alternately, if (gNB)IntraFreqMCCellProfile.sCellCoverageTriggerQuantity
= RSRQ then Event A1 is triggered when:

SS_RSRQSCell >
(gNB)IntraFreqMCCellProfile.rsrqSCellCoverage.threshold / 10
+ (gNB)IntraFreqMCCellProfile.rsrqSCellCoverage.hysteresis / 10

is fulfilled for:
(gNB)IntraFreqMCCellProfile.rsrqSCellCoverage.timeToTrigger

The SCell deactivation is initiated when the SN receives an A2 report from the UE.

If (gNB)IntraFreqMCCellProfile.sCellCoverageTriggerQuantity = RSRP then

Event A2 is triggered when:

SS_RSRPSCell <
(gNB)IntraFreqMCCellProfile.rsrpSCellCoverage.threshold
- (gNB)IntraFreqMCCellProfile.rsrpSCellCoverage.hysteresis / 10

is fulfilled for:
(gNB)IntraFreqMCCellProfile.rsrpSCellCoverage.timeToTrigger

Alternately, if (gNB)IntraFreqMCCellProfile.sCellCoverageTriggerQuantity
= RSRQ then Event A2 is triggered when:

SS_RSRQSCell <
(gNB)IntraFreqMCCellProfile.rsrqSCellCoverage.threshold / 10
- (gNB)IntraFreqMCCellProfile.rsrqSCellCoverage.hysteresis / 10

is fulfilled for:
(gNB)IntraFreqMCCellProfile.rsrqSCellCoverage.timeToTrigger

In both NSA and SA NR DL Carrier Aggregation for FR1, intra-frequency SCell

measurements are conducted to find better SCells.

SCell Intra-frequency mobility always uses Event A6. The parameters to control this event
are configured in the gNodeB. The report always uses RSRP and is triggered when:

SS_RSRPtargetSCell – SS_RSRPsourceSCell >

(gNB)IntraFreqMCCellProfile.rsrpBetterSCell.offset / 10
+ (gNB)IntraFreqMCCellProfile.rsrpBetterSCell.hysteresis / 10

is fulfilled for:
(gNB)IntraFreqMCCellProfile.rsrpBetterSCell.timeToTrigger

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 173 (179)
 5G Mobility and Traffic Management Guideline

11 Appendix 3 – Mobility KPIs

Key Performance Indicators (KPIs) are important for understanding the performance of NR
NSA. This section provides a high-level overview of KPIs and PIs which are useful in the
context of mobility and traffic management.

Note that the feature Flexible Counters can be used to obtain KPIs which focus on EN-DC
users; see Section 9.2.8 for more details.

11.1 Key Performance Indicators – NSA

Table 11-1 highlights some of the relevant KPIs for NR NSA. Further details on formulas
and counters are provided in the CPI document Key Performance Indicators.
Table 11-1 – KPIs for NR NSA
QoS Category KPI Name
Accessibility Initial E-RAB Establishment Success Rate
Accessibility Random Access Success Rate
Accessibility EN-DC Setup Success Rate
Retainability E-RAB Retainability
Retainability SCG Radio Resource Retainability
Mobility Cell Mobility Success Rate in LTE
Mobility Cell Handover Success Rate in LTE
Mobility Cell Handover Execution Success Rate in LTE
Mobility EN-DC Intra-sgNodeB PSCell Change Success Rate
Mobility EN-DC Inter-sgNodeB PSCell Change Success Rate

11.2 Additional Performance Indicators – NSA

In addition to the KPIs listed in Section 11.1, the following Performance Indicators (PIs) are
useful for assessing NR NSA mobility.

11.2.1 B1 Report Rate

The following formula shows the proportion of Event B1 reports per Event B1 configuration.

B1 Report Rate = 100 * (EUtranCellFDD/TDD.pmB1MeasRepEndcConfig /

EUtranCellFDD/TDD.pmMeasConfigB1Endc)

11.2.2 EN-DC Setup Random Access Failure Rate

The following formula shows the failure rate of random access attempts in the NR cell.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 174 (179)
 5G Mobility and Traffic Management Guideline

EN-DC Setup Random Access Failure Rate =

100 * (EUtranCellFDD/TDD.pmEndcSetupFailNrRa /
EUtranCellFDD/TDD.pmEndcSetupUeAtt)

11.2.3 Capability-Aware Idle Mode Control Prioritized Release per LTE Frequency

The following counter shows to which EUtranFreqRelation the feature Capability-

Aware Idle Mode Control has assigned the highest cellReselectionPriority
(namely 7) at UE release for an EN-DC capable UE.

Number of prioritized releases per LTE frequency = EUtranFreqRelation.

pmEndcPrioritizedUe

The count will be impacted by:

• The proportion of UEs which support EN-DC on the frequency

• The hit rate, or EN-DC capable cell count, on the frequency (if more than one EN-DC
capable frequency exists)

11.2.4 EN-DC Triggered Handover Success Rate

The following formula shows the success rate of the EN-DC Triggered Handover.

EN-DC Triggered Handover Success Rate =

100 * ((EUtranCellFDD/TDD.pmCellHoPrepSuccLteInterFEndcHo /
EUtranCellFDD/TDD.pmCellHoPrepAttLteInterFEndcHo) *
(EUtranCellFDD/TDD.pmCellHoExeSuccLteInterFEndcHo /
EUtranCellFDD/TDD.pmCellHoExeAttLteInterFEndcHo))

11.2.5 Number of UE Initiated SCGFailureInformationNR

Some UE vendors require a mechanism to intentionally trigger an SN release, for example

to save power when the UE screen is turned off. To do this, the UE sends an
SCGFailureInformationNR (3GPP 36.331) message with the measResultFreqListNR-r15
information element set as follows, so that the eNodeB understands that this is an
intentional “failure”:

• The ARFCN-ValueNR-r15 attribute is set to 0

• The pci-r15 attribute is set to 0

• The measResultCell-r15 attribute is empty

The eNodeB counts such intentional “failures” with a special counter,

EUtranCellFDD/TDD.pmRrcScgFailureArfcnNil, to distinguish them from genuine
failures. This allows them to be subtracted from the overall failure count (for example in
pmEndcRelMnMcgRelocAtt) to produce KPIs which reflects the genuine failure rate.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 175 (179)
 5G Mobility and Traffic Management Guideline

11.2.6 B1 EN-DC Trigger Rate

This KPI measures the percentage of B1 measurement reports received that are able to
trigger an EN-DC setup.

B1 EN-DC Trigger Rate = 100 * EUtranCellFDD/TDD.pmEndcSetupUeAtt /

EUtranCellFDD/TDD.pmB1MeasRepEndcConfig

11.3 Key Performance Indicators – SA

Table 11-2 highlights some of the relevant KPIs for NR SA. Further details on formulas and
counters are provided in the CPI document Key Performance Indicators.
Table 11-2 – Main KPIs for NR SA
QoS Category KPI Name
Accessibility DRB Accessibility - Success Rate for mapped 5QI
Retainability DRB Retainability - Percentage Lost per mapped 5QI
Retainability DRB Retainability - Percentage Lost per mapped 5QI,
gNodeB triggered only
Mobility NR Handover success rate captured in source gNodeB

11.4 Additional Performance Indicators – SA

In addition to the KPIs listed in Section 11.1, the following Performance Indicators (PIs) are
useful for assessing NR SA mobility.

11.4.1 NR Coverage-Triggered NR Session Continuity

The following counter shows how many times the feature NR Coverage-Triggered NR
Session Continuity triggered release-with-redirect.

Number of NR Coverage-Triggered NR Session Continuity to SA per LTE cell =

EUtranCellFDD/TDD.pmUeCtxtRelSCNr

11.4.2 NR to LTE Session Continuity

The following counter shows how many times the feature NR to LTE Session Continuity
triggered release-with-redirect.

Number of LTE Session Continuity to LTE per SA cell =

NRCellCU.pmRwrEutranUeSuccNrCoverage

11.4.3 EPS Fallback to IMS Voice

The following counter shows how many times the feature EPS Fallback to IMS Voice
triggered release-with-redirect.

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 176 (179)
 5G Mobility and Traffic Management Guideline

Number of EPS Fallback to IMS Voice to LTE per SA cell =

NRCellCU.pmRwrEutranUeSuccEpsfb

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 177 (179)
 5G Mobility and Traffic Management Guideline

12 Appendix 4 – Configuration Profiles

Configuration profiles are used in the gNodeB to facilitate the configuration of certain
features. They enable a group of related parameters to be configured together in one or
more profiles.

One example of a configuration profile is the McpcPSCellProfile class. This profile is

used to configure those attributes of the Mobility Control at Poor Coverage (MCPC) feature
that apply to Primary SCell (PSCell) mobility. One or more instances of
McpcPSCellProfile are defined within the Mcpc container class and are referenced
from NRCellCU using mcpcPSCellProfileRef. This is shown in Figure 12-1.

Note that the option of creating an McpcPSCellProfile instance as a child of NRCellCU

is removed as of software release NR 2020 Q4.

Figure 12-1 – McpcPSCellProfile Configuration Example

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 178 (179)
 5G Mobility and Traffic Management Guideline

13 Appendix 5 – Release History

This section summarizes the major changes in this document release. Note that there are
also many smaller changes which are not listed here.
Table 13-1 – Changes per Release
Release Comments
2020 Q4 - ESS is now supported for NR SA
(this - The measurement events A1, A2 and A6 are introduced for NR carrier aggregation
release) - Added the feature Inter Vendor EN-DC Triggered Handover During Setup
- The feature EN-DC Triggered Handover During Connected Mode Mobility is enhanced
to trigger also on RRC re-establishment
- The EN-DC triggered handover features are enhanced to forward the B1 measurement
report to the target cell during handover, to speed up SN addition on the target cell.
- Introduced intra-frequency SCell change for NR NSA
- Introduced intra-frequency SCell change for NR SA
- Included guidance on preventing a non-ESS capable UE from using an SA ESS cell
- The feature Basic Intelligent Connectivity now supports periodic repetition of B1
measurements and the prioritization of NR frequencies within a priority group for B1
measurements
- Updated KPI information
- Updated configuration options for McpcPSCellProfile
2020 Q3 - The feature EN-DC Triggered Handover During Setup now also allows ENDCHO from a
(previous cell which the UE can use for EN-DC (this impacts the NSA procedures, the section on
release) anchor carrier management, the feature summaries for ENDCHO and BIC, and the
effective trigger levels for ENDCHO)
- EN-DC triggered handover can now also be triggered at incoming handover, by the new
feature EN-DC Triggered Handover During Connected Mode Mobility (this impacts the
NSA procedures, the section on anchor carrier management and the feature
summaries for ENDCHO)
- The feature Automated Neighbor Relations can now manage the relations associated
with EN-DC (this results in a new feature summary and impacts the feature summary
for BIC)
- The feature Multiple Frequency Band Indicators has new functionality to allow
overlapping LTE bands to be used for EN-DC (this results in a new feature summary
and impacts the feature summary for BIC)
- Added the feature RAN Slicing Framework (this results in a new feature summary and
impacts the NR SA procedures)
- Data Radio Bearers can now be added to an existing connection directly as SN
terminated bearers (this impacts the data bearer addition procedure)
- Upper layer indication can now be set automatically by BIC (this impacts the sections on
5G status icon and the BIC feature summary)
- The NSA Intra-Frequency Mobility Procedure is updated to include the requirements for
two cells to be considered intra-frequency

2/154 43-LZA 701 6017 Uen Rev J 2020-11-20 © Ericsson AB 2020 179 (179)