5G Mobility and Traffic Management
Guideline
Document Number
Revision
2/154 43-LZA 701 6017 Uen
G
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
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Mobility and Connectivity Overview ............................................. 10
5G Connectivity Options .................................................................. 10
Frequency Ranges & Bands ............................................................ 11
Ericsson Spectrum Sharing (ESS) ................................................... 12
Mobility States ................................................................................. 13
5G Status Icon on UE ...................................................................... 16
Measurement Quantities.................................................................. 18
Connected Mode Measurements ..................................................... 19
5
5.1
5.2
5.3
5.4
5.5
Connectivity and Bearers – NSA .................................................. 25
Radio Bearer Types – NSA.............................................................. 25
Radio Bearer Transitions – NSA ...................................................... 26
Split Bearer User Plane Functions – NSA ........................................ 28
Downlink Carrier Aggregation – NSA ............................................... 35
Uplink Carrier Aggregation – NSA ................................................... 37
6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Mobility and Connectivity Procedures – NSA.............................. 39
Idle Mode Procedures – NSA .......................................................... 40
Data Bearer Setup and Release Procedures – NSA ........................ 41
NR Coverage-Triggered Mobility Procedures – NSA ....................... 55
VoLTE Procedures – NSA ............................................................... 59
CS Fallback Procedures – NSA ....................................................... 64
LTE Coverage-Triggered Mobility Procedures – NSA ...................... 65
LTE Load-Triggered Mobility Procedures – NSA ............................. 69
7
7.1
7.2
7.3
Mobility and Connectivity Procedures – SA ................................ 71
Idle Mode Procedures – SA ............................................................. 71
Connected Mode Procedures – SA.................................................. 75
Interworking Between LTE and NR SA ............................................ 80
8
8.1
8.2
8.3
8.4
8.5
LTE Anchor Carrier Management – NSA...................................... 84
Choosing Suitable Anchor Carriers – NSA....................................... 84
Steering 5G UEs to an Anchor Carrier – NSA.................................. 88
Steering non-5G UEs away from an Anchor Carrier ...................... 113
Configuring SPID for Anchor Carrier Control ................................. 114
Configuring QCI for 5G Users ........................................................ 116
9
9.1
9.2
9.3
9.4
Appendix 1 – Mobility Features .................................................. 119
Software Value Packages and Features ........................................ 119
eNodeB Features .......................................................................... 121
gNodeB Features .......................................................................... 150
MME Features ............................................................................... 153
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
3 (175)
5G Mobility and Traffic Management Guideline
10
10.1
10.2
Appendix 2 – Mobility Trigger Levels ......................................... 155
Idle Mode....................................................................................... 155
Connected Mode ........................................................................... 164
11
11.1
11.2
11.3
11.4
Appendix 3 – Mobility KPIs ......................................................... 169
Key Performance Indicators – NSA ............................................... 169
Additional Performance Indicators – NSA ...................................... 169
Key Performance Indicators – SA .................................................. 170
Additional Performance Indicators – SA ........................................ 171
12
Appendix 4 – Configuration Profiles .......................................... 172
13
Appendix 5 – Release History..................................................... 173
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
4 (175)
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 Q3 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 G
2020-08-24
© Ericsson AB 2020
5 (175)
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
5G_Idle_Stay
5G_HO_Go
5G_Cov_Stay
5G_LB_Stay
These acronyms refer to the five anchor management
strategies which are defined in this document. The
strategies are used to maximize EN-DC availability, by
steering EN-DC capable UEs towards LTE cells which
are capable of acting as anchors for EN-DC.
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 G
2020-08-24
© Ericsson AB 2020
6 (175)
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 G
2020-08-24
© Ericsson AB 2020
7 (175)
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
Option 2
Option 3x
Terms used to describe UE to network connectivity
options. Option 1 is LTE, Option 2 is NR, Option 3x is
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.
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
SS-RSRP
Synchronization Signal Reference Signal Received
Power
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
8 (175)
5G Mobility and Traffic Management Guideline
Term
Definition
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 G
2020-08-24
© Ericsson AB 2020
9 (175)
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
Option
Network RAT
Option 1
EPC
LTE
Option 3
EPC
LTE
Option 2
5GC
NR
Option 4
5GC
NR
Option 5
5GC
eLTE
Option 7
5GC
eLTE
Secondary
RAT
NR
eLTE
NR
3GPP
Term
LTE
EN-DC
NR
NE-DC
eLTE
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 G
2020-08-24
© Ericsson AB 2020
10 (175)
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 G
2020-08-24
© Ericsson AB 2020
11 (175)
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)
Legacy & new spectrum
< 6 GHz
For example: 1.8 GHz or 2.1 GHz
Mid-band (TDD)
Legacy & new spectrum
< 6 GHz
For example: 3.5 GHz
High-band (TDD)
New spectrum
> 24 GHz (mm wave)
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.
In the current software revision, ESS dynamically shares the spectrum between an LTE
and NR NSA carrier, of bandwidth 10, 15 or 20 MHz. The split of PRBs between LTE and
NR NSA 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
Future software revisions will provide additional functionality, such as: carrier aggregation
with other NR carriers and NR SA on the ESS carrier.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
12 (175)
5G Mobility and Traffic Management Guideline
ESS requires that the LTE and NR carriers have the same bandwidth and center
frequency. 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 also 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.
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 G
2020-08-24
© Ericsson AB 2020
13 (175)
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 G
2020-08-24
© Ericsson AB 2020
14 (175)
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 Reestablishment 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 G
2020-08-24
© Ericsson AB 2020
15 (175)
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
1. Idle under or connected to LTE cell not supporting NSA
UE Indication
4G
2. Idle under or connected to LTE cell supporting NSA and
no detection of NR coverage
5G
3. Connected to LTE only under LTE cell supporting NSA
and detection of NR coverage
5G
4. Idle under LTE cell supporting NSA and detection of NR
coverage
5G
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 G
2020-08-24
© Ericsson AB 2020
16 (175)
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 upperLayerIndicationrel15 in SIB2 is correctly received in the UE.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
17 (175)
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 G
2020-08-24
© Ericsson AB 2020
18 (175)
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 intrafrequency 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 G
2020-08-24
© Ericsson AB 2020
19 (175)
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 G
2020-08-24
© Ericsson AB 2020
20 (175)
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 G
2020-08-24
© Ericsson AB 2020
21 (175)
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 A2: Serving Becomes Worse than Threshold
Event A2, as shown in Figure 4-7, is used to detect poor NR cell coverage for both SA and
NSA.
Figure 4-7 – Event A2 – Serving Becomes Worse than Threshold
For SA, the A2 event 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 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
22 (175)
5G Mobility and Traffic Management Guideline
4.7.5.2
Event A3: Neighbor NR Cell Becomes Offset Better than Serving Cell
Event A3, shown in Figure 4-8, 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.
Figure 4-8 – Event A3 – Neighbor NR Cell 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 mobility 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 mobility procedure described in Section 6.3.1.
The full formula (showing all parameters involved with this event) is provided in Section
10.2.4.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
23 (175)
5G Mobility and Traffic Management Guideline
4.7.5.3
Event B1: IRAT Neighbor Becomes Better than Threshold
Event B1, shown in Figure 4-9, is used to detect acceptable NR coverage.
Figure 4-9 – 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 G
2020-08-24
© Ericsson AB 2020
24 (175)
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 G
2020-08-24
© Ericsson AB 2020
25 (175)
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:
5.2
•
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).
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 G
2020-08-24
© Ericsson AB 2020
26 (175)
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.3.
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 G
2020-08-24
© Ericsson AB 2020
27 (175)
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 G
2020-08-24
© Ericsson AB 2020
28 (175)
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 G
2020-08-24
© Ericsson AB 2020
29 (175)
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 G
2020-08-24
© Ericsson AB 2020
30 (175)
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:
5.3.3
•
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.
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 G
2020-08-24
© Ericsson AB 2020
31 (175)
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:
5.3.4
•
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.
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 G
2020-08-24
© Ericsson AB 2020
32 (175)
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 G
2020-08-24
© Ericsson AB 2020
33 (175)
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 G
2020-08-24
© Ericsson AB 2020
34 (175)
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 G
2020-08-24
© Ericsson AB 2020
35 (175)
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
36 (175)
5G Mobility and Traffic Management Guideline
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.
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 G
2020-08-24
© Ericsson AB 2020
37 (175)
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 G
2020-08-24
© Ericsson AB 2020
38 (175)
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. 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.
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 G
2020-08-24
© Ericsson AB 2020
39 (175)
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 G
2020-08-24
© Ericsson AB 2020
40 (175)
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.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 G
2020-08-24
© Ericsson AB 2020
41 (175)
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 G
2020-08-24
© Ericsson AB 2020
42 (175)
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. Measurementbased 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 G
2020-08-24
© Ericsson AB 2020
43 (175)
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.4 for details.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
44 (175)
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.4 for details.
10 TTI Bundling is not activated for any of the established bearers.
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)
•
6.2.3.2
When this inhibition stops, the other prerequisites for SN addition (listed above) are
applied.
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 G
2020-08-24
© Ericsson AB 2020
45 (175)
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 midband) 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 G
2020-08-24
© Ericsson AB 2020
46 (175)
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 G
2020-08-24
© Ericsson AB 2020
47 (175)
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 G
2020-08-24
© Ericsson AB 2020
48 (175)
5G Mobility and Traffic Management Guideline
ENDCHO functionality is provided by three different features. The main differences
between these features are shown in Table 6-1. See the indicated sections for more detail.
Table 6-1 – EN-DC Triggered Handover Features
Node
Type
Trigger
Measurements
Configured
Baseband
Connection setup
B1 and A5
Basic EN-DC Triggered Handover During
Connection Setup (Section 9.2.14)
DU
Connection setup
A5 only
EN-DC Triggered Handover During
Connected Mode Mobility (Section 9.2.16)
Baseband
Incoming handover
B1 and A5
Feature Name
EN-DC Triggered Handover During
Connection Setup (Section 9.2.13)
The procedures involved with all three features are shown in Figure 6-6.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
49 (175)
5G Mobility and Traffic Management Guideline
Figure 6-6 – EN-DC Triggered Handover Procedures
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
50 (175)
5G Mobility and Traffic Management Guideline
– 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 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 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 trigger for ENDCHO is incoming handover
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:
•
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
51 (175)
5G Mobility and Traffic Management Guideline
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
•
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
52 (175)
5G Mobility and Traffic Management Guideline
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.
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 3 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
53 (175)
5G Mobility and Traffic Management Guideline
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 3 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.
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
54 (175)
5G Mobility and Traffic Management Guideline
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 Mobility – 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 G
2020-08-24
© Ericsson AB 2020
55 (175)
5G Mobility and Traffic Management Guideline
Figure 6-10 – Intra-Frequency and Inter-Frequency Examples
NR intra-frequency mobility is triggered by the gNodeB when an NR A3 report is received
from the UE (forwarded by the eNodeB). This triggers a PSCell change to the reported NR
Cell. The procedure is shown in Figure 6-11.
Figure 6-11 – NR Intra-Frequency Mobility
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 G
2020-08-24
© Ericsson AB 2020
56 (175)
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.
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
57 (175)
5G Mobility and Traffic Management Guideline
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:
•
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:
•
6.3.3
RLC DL delivery failure. The number of DL RLC retransmissions exceeds
GNBDUFunction.DataRadioBearer.dlMaxRetxThreshold
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 PCell 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
58 (175)
5G Mobility and Traffic Management Guideline
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)
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-13.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
59 (175)
5G Mobility and Traffic Management Guideline
Figure 6-13 - 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.
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:
6.4.2.1
•
MN Terminated MCG Bearer
•
SN Terminated Split Bearer
•
SN Terminated MCG Bearer
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-14.
Figure 6-14 - 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
60 (175)
5G Mobility and Traffic Management Guideline
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.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-15. 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
•
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-15 - 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-16.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
61 (175)
5G Mobility and Traffic Management Guideline
Figure 6-16 - 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-17.
Figure 6-17 - 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.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-18.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
62 (175)
5G Mobility and Traffic Management Guideline
Figure 6-18 - 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.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-19.
Figure 6-19 - 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-19.
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-20.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
63 (175)
5G Mobility and Traffic Management Guideline
Figure 6-20 - 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.
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
64 (175)
5G Mobility and Traffic Management Guideline
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
reestablishment 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-21. 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 G
2020-08-24
© Ericsson AB 2020
65 (175)
5G Mobility and Traffic Management Guideline
Figure 6-21 – Intra-LTE Handover with MN Terminated MCG Bearer without VoLTE
Notes for Figure 6-21:
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 G
2020-08-24
© Ericsson AB 2020
66 (175)
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-22. 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-22 – Intra-LTE Handover with SN Terminated Split Bearer
Notes for Figure 6-22:
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 ENDC 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 G
2020-08-24
© Ericsson AB 2020
67 (175)
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-23.
Figure 6-23 – Intra-LTE Handover with SN Terminated MCG Bearer
Notes for Figure 6-23:
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 G
2020-08-24
© Ericsson AB 2020
68 (175)
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 Reestablishment – NSA
If an LTE connection reestablishment 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 reestablishment, 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 G
2020-08-24
© Ericsson AB 2020
69 (175)
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 coveragetriggered 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 G
2020-08-24
© Ericsson AB 2020
70 (175)
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 G
2020-08-24
© Ericsson AB 2020
71 (175)
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 intrafrequency 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 G
2020-08-24
© Ericsson AB 2020
72 (175)
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 G
2020-08-24
© Ericsson AB 2020
73 (175)
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 G
2020-08-24
© Ericsson AB 2020
74 (175)
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 G
2020-08-24
© Ericsson AB 2020
75 (175)
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-EUTRACapability 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 G
2020-08-24
© Ericsson AB 2020
76 (175)
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-3.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
77 (175)
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 Mobility – SA
This procedure is enabled by the gNodeB feature NR Mobility (FAJ 121 5041), Section
9.3.3.3.
NR intra-frequency mobility is triggered by the gNodeB when an NR A3 report is received
from the UE. This triggers a handover to the reported NR Cell.
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 G
2020-08-24
© Ericsson AB 2020
78 (175)
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 G
2020-08-24
© Ericsson AB 2020
79 (175)
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.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-5.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
80 (175)
5G Mobility and Traffic Management Guideline
Figure 7-5 – 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-6 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 G
2020-08-24
© Ericsson AB 2020
81 (175)
5G Mobility and Traffic Management Guideline
Figure 7-6 – IRAT Mobility Thresholds for LTE and NR SA
Notes for Figure 7-6:
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 G
2020-08-24
© Ericsson AB 2020
82 (175)
5G Mobility and Traffic Management Guideline
The boundaries between these regions in Figure 7-6 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 G
2020-08-24
© Ericsson AB 2020
83 (175)
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-MRDCCapability 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 G
2020-08-24
© Ericsson AB 2020
84 (175)
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 MRDCParameters (singleUL-Transmission), as specified in 3GPP TS 38.331.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
85 (175)
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 G
2020-08-24
© Ericsson AB 2020
86 (175)
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 same carrier is used for both LTE and NR NSA. 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 both legacy LTE and EN-DC 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 G
2020-08-24
© Ericsson AB 2020
87 (175)
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
2/154 43-LZA 701 6017 Uen Rev G
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.
2020-08-24
© Ericsson AB 2020
88 (175)
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
Component
5G_Idle_Go
5G_Idle_Stay
5G_Cov_Stay
5G_HO_Go
5G_IFLB_Stay
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
Mechanism for Differentiating 5G UEs
UE Capability
SPID
QCI
CAIMC
STM
CAIMC
STM
STM & MCPC
MLSTM
ENDCHO
STM & MCPC
MLSTM
BIC
STM
SSLM
© Ericsson AB 2020
89 (175)
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
Number
Features
Used
Comments
1
Mechanism for
Differentiating
5G Subscribers
UE Capability
CAIMC
2
SPID
STM
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 preexisting 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.
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 G
2020-08-24
© Ericsson AB 2020
90 (175)
5G Mobility and Traffic Management Guideline
8.2.1.1
•
EUtranFreqRelation.threshXLow – target cell threshold for reselection to a lower
priority frequency.
•
EUtranFreqRelation.threshXHigh – neighbor cell threshold for reselecting
towards a higher priority frequency
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 G
2020-08-24
© Ericsson AB 2020
91 (175)
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 ENDC. 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 G
2020-08-24
© Ericsson AB 2020
92 (175)
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 G
2020-08-24
© Ericsson AB 2020
93 (175)
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 G
2020-08-24
© Ericsson AB 2020
94 (175)
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 G
2020-08-24
© Ericsson AB 2020
95 (175)
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.
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
FreqPrioListEUTRA[0].cellReselectionPriority = 7
Assign a lower priority to the secondary anchor frequency:
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
96 (175)
5G Mobility and Traffic Management Guideline
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.
Table 8-3 – Solutions for 5G_Cov_Stay
Solution
Number
1
Mechanism for
Differentiating
5G Subscribers
SPID
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
Features
Used
Comments
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.
© Ericsson AB 2020
97 (175)
5G Mobility and Traffic Management Guideline
Solution
Number
Features
Used
Comments
2
Mechanism for
Differentiating
5G Subscribers
SPID
STM,
MCPC
3
QCI
MLSTM
This SPID-based solution uses the MCPC feature to
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 twostage 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.
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.
These settings are summarized in Figure 8-8, for the same example as used in 8.2.1.1.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
98 (175)
5G Mobility and Traffic Management Guideline
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 nonanchor 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 G
2020-08-24
© Ericsson AB 2020
99 (175)
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 G
2020-08-24
© Ericsson AB 2020
100 (175)
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
ReportConfigSearch
Parameter
a1a2SearchThresholdRsrp
Value
-115
ReportConfigSearch
a2OuterSearchThrRsrpOffset
-3
UeMeasControl
lowPrioMeasThresh
5
EUtranFreqRelation
connectedModeMobilityPrio
4
EUtranFreqRelation
voicePrio
4
UtranFreqRelation
connectedModeMobilityPrio
3
UtranFreqRelation
voicePrio
3
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
Comment
Assuming previous value
was -118 dBm, raise the value
by 3dB to allow the inner
search zone to begin 3 dB
earlier.
Set outer search zone
boundary 3dB below inner
search zone boundary (at the
previous search zone level of 118 dBm).
Frequencies with a priority less
than this value are searched in
the outer search zone only.
For non-5G UEs, all LTE
frequencies are searched in
the outer search zone only.
For non-5G UEs, all LTE
frequencies are searched in
the outer search zone only.
For non-5G UEs, all UTRAN
frequencies are searched in
the outer search zone only.
For non-5G UEs, all UTRAN
frequencies are searched in
the outer search zone only.
101 (175)
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 G
2020-08-24
© Ericsson AB 2020
102 (175)
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 G
2020-08-24
© Ericsson AB 2020
103 (175)
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
Number
Features
Used
Comments
1
Mechanism for
Differentiating 5G
Subscribers
UE Capability
ENDCHO
2
QCI
MLSTM
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.
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 G
2020-08-24
© Ericsson AB 2020
104 (175)
5G Mobility and Traffic Management Guideline
Solution
Number
3
8.2.3.1
Mechanism for
Differentiating 5G
Subscribers
SPID
Features
Used
Comments
STM,
MCPC
This SPID-based solution uses the MCPC
feature to create two search zones. The inner
search zone is used to push 5G UEs from nonanchor 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.
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.
8.2.3.2
•
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.
•
To set up the A5 measurement, ENDCHO uses the parameters described in Section
10.2.6.
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).
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
105 (175)
5G Mobility and Traffic Management Guideline
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 nonanchor 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 interfrequency 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.
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
106 (175)
5G Mobility and Traffic Management Guideline
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:
Inner-Outer Search Zone Boundary
= a1a2SearchThresholdRsrp + a2OuterSearchThrRsrpOffset
= -44 dBm + (-74) dBm = -118 dBm
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
107 (175)
5G Mobility and Traffic Management Guideline
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
Number
8.2.4.1
Features
Used
Comments
1
Mechanism
for
Differentiating
5G
Subscribers
UE Capability
BIC
2
SPID
STM
3
QCI
SSLM
This feature uses the parameter
lbAllowedForEndcUe in the feature Basic
Intelligent Connectivity to prevent all loadtriggered handovers for EN-DC capable UEs.
This SPID-based solution uses the feature
Subscriber Triggered Mobility to prevent loadtriggered handovers from anchor to non-anchor
carriers, or even between anchor carriers.
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.
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).
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
108 (175)
5G Mobility and Traffic Management Guideline
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 non5G 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 G
2020-08-24
© Ericsson AB 2020
109 (175)
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 G
2020-08-24
© Ericsson AB 2020
110 (175)
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 G
2020-08-24
© Ericsson AB 2020
111 (175)
5G Mobility and Traffic Management Guideline
Figure 8-17 – Interaction between UE Capability-Aware Features
Notes for Figure 8-17:
8.2.5.1
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 procedure starts again at 1) on the target
cell. It is possible for ENDCHO to be triggered again on the target cell. However, this is
not likely if the ENDCHO configuration and GUtranFreqRelation definitions are the
same in the source and target cells.
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 coveragetriggered 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 (5GIdle-Stay and 5G-Idle-Go).
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 G
2020-08-24
© Ericsson AB 2020
112 (175)
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 G
2020-08-24
© Ericsson AB 2020
113 (175)
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 G
2020-08-24
© Ericsson AB 2020
114 (175)
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 G
2020-08-24
© Ericsson AB 2020
115 (175)
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:
8.5.1
•
Assign QCI in the HSS
•
Remap QCI Using ASGH Framework
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 G
2020-08-24
© Ericsson AB 2020
116 (175)
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 three 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.
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]
•
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
117 (175)
5G Mobility and Traffic Management Guideline
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 G
2020-08-24
© Ericsson AB 2020
118 (175)
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
Type
eNodeB LTE Base Package
Mobility Control at Poor Coverage
(FAJ 801 0400)
(FAJ 121 3013)
Licensed
Yes
eNodeB
LTE Base Package
(FAJ 801 0400)
Subscriber Triggered Mobility
(FAJ 121 1788)
Yes
eNodeB
LTE Base Package
(FAJ 801 0400)
LTE Base Package
(FAJ 801 0400)
LTE Base Package
(FAJ 801 0400)
ASGH Framework
(FAJ 121 4795)
Flexible Counters
(FAJ 121 4669)
Multiple Frequency Band Indicators
(FAJ 121 3054)
No
eNodeB
Service Based Mobility
(FAJ 801 0433)
Multi-Layer Service-Triggered Mobility Yes
(FAJ 121 4124)
eNodeB
Service Based Mobility
(FAJ 801 0433)
Service-Specific Load Management
(FAJ 121 3047)
Yes
eNodeB
Intelligent Connectivity
(FAJ 801 1013)
Basic Intelligent Connectivity
(FAJ 121 4843)
Yes
eNodeB
Intelligent Connectivity
(FAJ 801 1013)
Yes
eNodeB
Intelligent Connectivity
(FAJ 801 1013)
NR Coverage-Triggered NR Session
Continuity
(FAJ 121 4983)
Capability-Aware Idle Mode Control
(FAJ 121 5073)
eNodeB
Intelligent Connectivity
(FAJ 801 1013)
Yes
eNodeB
Intelligent Connectivity
(FAJ 801 1013)
eNodeB
Intelligent Connectivity
(FAJ 801 1013)
EN-DC Triggered Handover During
Setup
(FAJ 121 5097)
EN-DC Triggered Handover During
Connected Mode Mobility
(FAJ 121 5243)
Enhanced NR Restriction
(FAJ 121 5212)
eNodeB
Basic NR Mobility Support
(FAJ 801 1018)
Basic Capability-Aware Idle Mode
Control
(FAJ 121 5123)
Yes
eNodeB
eNodeB
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
No
Yes
Yes
Yes
Yes
119 (175)
5G Mobility and Traffic Management Guideline
Node
Type
eNodeB
Value Package
Feature name
Licensed
Basic NR Mobility Support
(FAJ 801 1018)
Yes
eNodeB
Inter-Vendor Load
Management
(FAJ 801 0416)
Multi-carrier Load
Management
(FAJ 801 0427)
Self-Organizing Networks
(FAJ 801 0435)
Basic EN-DC Triggered Handover
during Setup
(FAJ 121 5125)
Inter-Vendor Capability-Aware Idle
Mode Control
(FAJ 121 5160)
TM9 Capability-Aware Idle Mode
Control
(FAJ 121 5153)
Automated Neighbor Relations
(FAJ 121 0497)
eNodeB
eNodeB
Yes
Yes
Yes
Table 9-2 – RAN Features and Software Value Packages for gNodeB
Node
Value Package
Feature name
Type
Licensed
gNodeB
NR RAN Base Package
(FAJ 801 4002)
LTE-NR Dual Connectivity
(FAJ 121 4908)
No
gNodeB
NR RAN Base Package
(FAJ 801 4002)
NR RAN Base Package
(FAJ 801 4002)
NR RAN Base Package
(FAJ 801 4002)
NR RAN Base Package
(FAJ 801 4002)
Peak Rate Evolution Value
Package
(FAJ 801 4005)
Peak Rate Evolution Value
Package
(FAJ 801 4005)
RAN Slicing
(FAJ 801 4015)
Uplink-Downlink Decoupling
(FAJ 121 4909)
NR Mobility
(FAJ 121 5041)
EPS Fallback to IMS Voice
(FAJ 121 5059)
Service Request-Based Emergency
Fallback (FAJ 121 5059)
LTE-NR Downlink Aggregation
(FAJ 121 4912)
No
LTE-NR Uplink Aggregation
(FAJ 121 5091)
Yes
RAN Slicing Framework
(FAJ 121 5095)
Yes
gNodeB
gNodeB
gNodeB
gNodeB
gNodeB
gNodeB
No
No
No
Yes
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)
•
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
120 (175)
5G Mobility and Traffic Management Guideline
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.
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
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
121 (175)
5G Mobility and Traffic Management Guideline
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 configurationbased 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
– 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:
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
122 (175)
5G Mobility and Traffic Management Guideline
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 G
2020-08-24
© Ericsson AB 2020
123 (175)
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
Notes for Figure 9-2:
•
If endcMeasTime = -1, then only the first RRC Reconfiguration is sent, and the
measurement continues indefinitely.
•
If the last measurement is removed and EN-DC is not setup, then further B1
measurements for EN-DC are not configured until the UE either enters idle mode and
re-enters connected mode or performs an LTE handover or an LTE RRC connection
reestablishment.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
124 (175)
5G Mobility and Traffic Management Guideline
•
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 frequencies below 6 GHz (FR1) but for
frequencies above 6 GHz measurement gaps are used only if the UE requires it.
If B1 measurements are ongoing and an event occurs which violates the preconditions for
SN addition (Section 6.2.3.1), for example a VoLTE bearer is set up, then the B1
measurements are removed.
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.
The parameters for controlling the B1 measurement sequence are shown in 10.2.2:
Table 9-5 – Parameters for Controlling B1 Measurements
Attribute
Values
Description
(RAT, MO)
(default)
[units]
maxMeasB1Endc
1 to 8 (3)
The maximum number of concurrent B1
(LTE, UeMeasControl)
measurement configurations on NR frequency
for ENDC
endcB1MeasPriority
-1, 0 to 7 (4) NR frequency priority for EN-DC measurements.
(LTE, GUtranFreqRelation)
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
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]
endcAwareMfbiIntraCellHo
(LTE, ENodeBFunction)
true, false
(false)
If true, all overlapping bands of serving LTE PCell
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.
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).
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
125 (175)
5G Mobility and Traffic Management Guideline
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
•
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, the upper layer indication tells the UE that 5G NSA service is
potentially available in the area. This indication can be set either manually or automatically
(by BIC) per 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
126 (175)
5G Mobility and Traffic Management Guideline
•
If automatic update is disabled:
– The upper layer indication is set manually, using the attributes
EUtranCellFDD/TDD.primaryUpperLayerInd and
EUtranCellFDD/TDD.additionalUpperLayerIndList.
•
9.2.2
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.
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 redirected 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).
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
127 (175)
5G Mobility and Traffic Management Guideline
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
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 MultiLayer 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 InterFrequency 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
128 (175)
5G Mobility and Traffic Management Guideline
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.
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.
9.2.9
•
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.
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 6.2.3.2) 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
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
129 (175)
5G Mobility and Traffic Management Guideline
– 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
– 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
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
130 (175)
5G Mobility and Traffic Management Guideline
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:
•
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 G
2020-08-24
© Ericsson AB 2020
131 (175)
5G Mobility and Traffic Management Guideline
Table 9-6 – CAIMC Frequency Ranking – Example 1
Frequency
ENDC
SIB
Aggregated
Capable
Priority
Hit Rate
LTE 1
No
7
LTE 2
Yes
6
20%
LTE 3
Yes
5
50%
LTE 4
Yes
4
80%
LTE 5
No
3
(Serving Cell)
LTE 6
No
Not included
(priority = -1)
CAIMC
Priority
4
5
6
7
3
Not included
(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
ENDC
SIB
Aggregated
Capable Priority
Hit Rate
LTE 1
Yes
7
30%
LTE 2
Yes
6
(Serving Cell)
LTE 3
Yes
5
50%
LTE 4
Yes
5
60%
LTE 5
Yes
4
60%
LTE 6
Yes
4
70%
LTE 7
Yes
3
80%
LTE 8
No
3
UTRAN 1
No
2
GERAN
No
1
UTRAN 2
No
0
-
CAIMC
Priority
2
7
3
4
4
5
6
2
1
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 G
2020-08-24
© Ericsson AB 2020
132 (175)
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 G
2020-08-24
© Ericsson AB 2020
133 (175)
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
available over X2?
No
(inter-vendor case)
Created by
Handling of endcAllowedPlmnList
Operator
ANR or X2
Yes (both eNodeBs
must be Ericsson)
Operator
ANR or X2
Must be configured manually
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.
Set automatically through X2 information
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 G
2020-08-24
© Ericsson AB 2020
134 (175)
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 three 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.
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, interfrequency and inter-RAT handover, 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.
The rest of this section describes functionality that is relevant primarily to features 1 and 2
above, which apply to baseband radio nodes. 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-3.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
135 (175)
5G Mobility and Traffic Management Guideline
Figure 9-3 – 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 6.2.3.1
– The band combination is supported by the UE
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
136 (175)
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
Secondary RAT” present in HRL?
Not present
Present
Present
•
Enhanced NR
Restriction
feature state
Not active
Active
ENDCHO Allowed?
Yes
No
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 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 G
2020-08-24
© Ericsson AB 2020
137 (175)
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 eNodeB configures up to three consecutive sets of measurements, with the
highest priority NR frequency(s) and matching LTE frequencies in the first set and the
lowest in the last. The sequencing of these measurement sets is shown in Figure 9-2.
The measurements are separated in time by endcMeasTime + timeToTriggerB1. If
endcMeasTime = -1, then the first set of measurements continues indefinitely.
•
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-4 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
138 (175)
5G Mobility and Traffic Management Guideline
Figure 9-4 – EN-DC Triggered Handover During Setup – How eNodeB Chooses
Frequencies
Notes for Figure 9-4:
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
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
139 (175)
5G Mobility and Traffic Management Guideline
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
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
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
140 (175)
5G Mobility and Traffic Management Guideline
– 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.
•
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.
In the current software revision, after the ENDCHO is performed the target eNodeB
reconfigures B1 measurements in the UE for SN addition, using the procedure described in
6.2.3. It is possible for ENDCHO to be triggered again on the target cell. However, this is
unlikely if the ENDCHO configuration and GUtranFreqRelation definitions are the same
in the source and target cells.
9.2.13.1
ENDCHO – Interaction of UE Capability, Priority and Coverage
Figure 9-5 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
141 (175)
5G Mobility and Traffic Management Guideline
Figure 9-5 – ENDCHO – Interaction of UE Capability, Priority and Coverage
Notes for Figure 9-5:
•
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
UE_A1
UE_A2
Measurement Order
1) B1→NR2
1) B1→NR2
UE_A3
UE_A4
1) B1→NR2 + A5→LTE2
1) B1→NR2 + A5→LTE2
UE_B1
UE_B2
UE_B3
UE_B4
UE_C1
1) B1→NR1 + A5→LTE1
1) B1→NR1 + A5→LTE1
1) B1→NR1
1) B1→NR1
1) B1→NR2
2) B1→NR1 + A5→LTE1
1) B1→NR2
2) B1→NR1 + A5→LTE1
UE_C2
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
Behavior
UE reports NR2 and sets up EN-DC on serving cell.
UE has no coverage from NR2, the measurement times out
and EN-DC cannot be set up.
UE reports NR2 and LTE2 and performs ENDCHO
UE reports LTE2 but has no coverage from NR2, the B1
measurement times out and EN-DC cannot be set up.
UE reports NR1 and LTE1 and performs ENDCHO.
UE reports NR1 and LTE1 and performs ENDCHO.
UE reports NR1 and sets up EN-DC on serving cell.
UE reports NR1 and sets up EN-DC on serving cell.
UE reports NR2 and sets up EN-DC on serving cell.
Second measurements are never configured.
UE has no coverage from NR2 and the first measurement
times out.
UE reports NR1 and LTE1 and performs ENDCHO.
© Ericsson AB 2020
142 (175)
5G Mobility and Traffic Management Guideline
UE
UE_C3
UE_C4
UE_D1
UE_D2
UE_D3
UE_D4
Measurement Order
1) B1→NR2 + A5→LTE2
2) B1→NR1
1) B1→NR2 + A5→LTE2
2) B1→NR1
1) B1→NR2
2) B1→NR1
1) B1→NR2
2) B1→NR1
1) B1→NR2
2) B1→NR1
1) B1→NR2
2) B1→NR1
Behavior
UE reports NR2 and LTE2 and performs ENDCHO
Second measurement is never configured.
UE reports LTE2 but has no coverage from NR2 and the
first B1 measurement times out.
UE reports NR1 and sets up EN-DC on the serving cell.
UE reports NR2 and sets up EN-DC on serving cell.
Second measurement is never configured
UE has no coverage from NR2 and the first measurement
times out.
UE reports NR1 and sets up EN-DC on serving cell.
UE reports NR2 and sets up EN-DC on serving cell.
Second measurement is never configured.
UE has no coverage form NR2 and the first measurement
times out.
UE reports NR1 and sets up EN-DC on serving cell.
The key takeaways for ENDCHO are:
9.2.13.2
•
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.
•
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.
•
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.
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
(4)
measurements.
(LTE, GUtranFreqRelation)
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 G
2020-08-24
© Ericsson AB 2020
143 (175)
5G Mobility and Traffic Management Guideline
Attribute
(RAT, MO)
endcHoFreqPriority
(LTE, EUtranFreqRelation)
Values (default)
[unit]
-1, 0 to 7 (7)
endcMeasTime
(LTE, UeMeasControl)
-1, 40 to 120000
(2000) [ms]
a5Threshold1Rsrp
(LTE, ReportConfigA5EndcHo)
a5Threshold2Rsrp
(LTE, ReportConfigA5EndcHo)
a5Threshold1Rsrq
(LTE, ReportConfigA5EndcHo)
-140 to -44 (-140)
[dBm]
-140 to -44 (-136)
[dBm]
-195 to -30 (-195)
resolution 5
[0.1 dBm]
-195 to -30,
resolution 5
[0.1 dBm]
(-195)
0, 1, 2, 4, 8, 16, 32, 64
(0)
a5Threshold2Rsrq
(LTE, ReportConfigA5EndcHo)
reportAmountA5
(LTE, ReportConfigA5EndcHo)
reportIntervalA5
(LTE, ReportConfigA5EndcHo)
triggerQuantityA5
(LTE, ReportConfigA5EndcHo)
timeToTriggerA5
(LTE, ReportConfigA5EndcHo)
hysteresisA5
(LTE, ReportConfigA5EndcHo)
9.2.14
Various values from
120 ms to 60 min
(480 ms)
RSRP, RSRQ
(RSRP)
0,40,64,80,100128,16
0,256, 320,480,512
640,1024,12802560,
5120 (100) [ms]
0 to 150, (10)
resolution 5
[0.1 dB]
Description
LTE frequency priority for EN-DC
Triggered 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.
Time in which UE performs
measurements requested in each RRC
reconfiguration message for EN-DC.
Value -1 means infinity.
Serving cell RSRP threshold for A5. Used only
if triggerQuantityA5 is set to RSRP.
Target cell RSRP threshold for A5. Used only
if triggerQuantityA5 is set to RSRP.
Serving cell RSRQ threshold for A5. Used
only if triggerQuantityA5 is set to RSRQ.
Target cell RSRQ threshold for A5. Used only
if triggerQuantityA5 is set to RSRQ.
Number of reports for periodical reporting for
event A5 measurement. 0 means that reports
are sent as long as the event is fulfilled.
Interval for event-triggered periodical reporting
for event A5 measurement.
Quantity that triggers event A5 for event A5
measurement.
Time-to-trigger value for event A5. Used for
both RSRP and RSRQ.
The hysteresis value for event A5
measurement.
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.11).
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
144 (175)
5G Mobility and Traffic Management Guideline
9.2.15
•
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.
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:
•
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). Apart from the different trigger, the two features follow the same
procedures; refer to Section 9.2.13 for details.
Figure 9-6 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
145 (175)
5G Mobility and Traffic Management Guideline
Figure 9-6 – EN-DC Triggered Handover During Connected Mode Mobility
Consider the two UEs shown in Figure 9-6, 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.
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 and reports both, and an ENDCHO occurs to LTE1 B. There
the UE is again configured with a B1 measurement for NR1, for SN addition. The
timing of the measurements is explained in more detail in Section 9.2.1.2.
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 and reports both,
which triggers the EN-DC triggered handover from LTE1A to LTE2A. There the UE is
again configured with a B1 measurement for NR2, for SN addition.
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
146 (175)
5G Mobility and Traffic Management Guideline
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)
– 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.
9.2.17.2
•
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
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)
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
147 (175)
5G Mobility and Traffic Management Guideline
– 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.
– 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
148 (175)
5G Mobility and Traffic Management Guideline
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)
– Note: ANR cannot create (or re-create) ExternalGUtranCell MOs for NR HighBand cells. Therefore, to prevent their removal by ANR, set isRemoveAllowed =
False.
9.2.18
•
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)
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-7. 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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
149 (175)
5G Mobility and Traffic Management Guideline
Figure 9-7 – Overlapping Frequency Bands
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
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
150 (175)
5G Mobility and Traffic Management Guideline
•
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
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 lowband, 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:
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
151 (175)
5G Mobility and Traffic Management Guideline
9.3.3.1
NSA Intra-Frequency PSCell change
This functionality allows EN-DC configured UEs with SCG resources to perform intrafrequency 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.
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
152 (175)
5G Mobility and Traffic Management Guideline
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).
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.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
153 (175)
5G Mobility and Traffic Management Guideline
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.
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 G
2020-08-24
© Ericsson AB 2020
154 (175)
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:
10.1
•
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.
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 G
2020-08-24
© Ericsson AB 2020
155 (175)
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.
10.1.1
•
Speed dependent scaling does not apply.
•
The UE is capable of both NR SA and LTE.
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_RSRPNR < (gNB)NRCellDU.qRxLevMin
+ (gNB)NRFreqRelation.sIntraSearchP
or
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
156 (175)
5G Mobility and Traffic Management Guideline
SS_RSRQNR < (gNB)NRCellDU.qQualMin
+ (gNB)NRFreqRelation.sIntraSearchQ
If camped on LTE, the UE must perform intra-frequency measurements when:
RSRPLTE < (eNB)EUtranCellFDD.qRxLevMin
+ (eNB)EUtranCellFDD.systemInformationBlock3.sIntraSearch
or alternately (if sIntraSearchv920Active = true, and the UE is Release 9
onwards) when:
RSRPLTE < (eNB)EUtranCellFDD.qRxLevMin
+ (eNB)EUtranCellFDD.systemInformationBlock3.sIntraSearchP
or
RSRQLTE < (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 G
2020-08-24
© Ericsson AB 2020
157 (175)
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_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.
If camped on LTE, the UE must measure frequencies with cellReselectionPriority
equal to or lower than the current frequency when:
RSRPLTE < (eNB)EUtranCellFDD.qRxLevMin
+ (eNB)EUtranCellFDD.systemInformationBlock3.sNonIntraSearch
Or alternately (if sNonIntraSearchv920Active = true and the UE is Release 9
onwards) when:
RSRPLTE < (eNB)EUtranCellFDD.qRxLevMin
+ (eNB)EUtranCellFDD.systemInformationBlock3.sNonIntraSearchP
or
RSRQLTE < (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 G
2020-08-24
© Ericsson AB 2020
158 (175)
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:
10.1.5
•
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.
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 G
2020-08-24
© Ericsson AB 2020
159 (175)
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 G
2020-08-24
© Ericsson AB 2020
160 (175)
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 > (gNB)EUtranFreqRelation.qRxLevMin
+ (gNB)EUtranFreqRelation.threshXHighP
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
161 (175)
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 > (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 > (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 > (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 < (gNB)NRCellCU.qRxLevMin
+ (gNB)NRCellCU.threshServingLowP
and
RSRPLTE > (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 G
2020-08-24
© Ericsson AB 2020
162 (175)
5G Mobility and Traffic Management Guideline
SS_RSRQNR < (gNB)NRCellCU.qQualMin
+ (gNB)NRCellCU.threshServingLowQ
and
RSRQLTE > (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 < (eNB)EUtranCellFDD.qRxLevMin
+ (eNB)EUtranCellFDD.threshServingLow
and
SS_RSRPNR > (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 < (eNB)EUtranCellFDD.qQualMin
+ (eNB)EUtranCellFDD.threshServingLowQ
and
SS_RSRQNR > (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 G
2020-08-24
© Ericsson AB 2020
163 (175)
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 G
2020-08-24
© Ericsson AB 2020
164 (175)
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 CoverageTriggered 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 G
2020-08-24
© Ericsson AB 2020
165 (175)
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 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 G
2020-08-24
© Ericsson AB 2020
166 (175)
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 G
2020-08-24
© Ericsson AB 2020
167 (175)
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
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
168 (175)
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
11.2
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
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 G
2020-08-24
© Ericsson AB 2020
169 (175)
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 CapabilityAware 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:
11.2.4
•
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)
EN-DC Triggered Handover during Setup Success Rate
The following formula shows the success rate of the EN-DC Triggered Handover During
Setup in the serving LTE cell.
EN-DC Triggered Handover during Setup Success Rate =
100 * ((EUtranCellFDD/TDD.pmCellHoPrepSuccLteInterFEndcHo /
EUtranCellFDD/TDD.pmCellHoPrepAttLteInterFEndcHo) *
(EUtranCellFDD/TDD.pmCellHoExeSuccLteInterFEndcHo /
EUtranCellFDD/TDD.pmCellHoExeAttLteInterFEndcHo))
11.3
Key Performance Indicators – SA
Table 11-1 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
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
170 (175)
5G Mobility and Traffic Management Guideline
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.
Number of EPS Fallback to IMS Voice to LTE per SA cell =
NRCellCU.pmRwrEutranUeSuccEpsfb
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
171 (175)
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. These profiles are either common or dedicated to particular MO:
•
Dedicated profiles can be used only by one MO instance and are created as a child of
that MO instance.
•
Common profiles are created under a “container class” and can be referred to by
multiple MO instances.
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. Each cell can either use its own
McpcPSCellProfile instance, defined as a child MO, or it can refer to a common
McpcPSCellProfile instance defined within the Mcpc container class. This is shown in
Figure 12-1 and the following notes.
Figure 12-1 – McpcPSCellProfile Configuration Example
Notes for Figure 12-1:
1
Each of these two cells each has its own child instance of McpcPSCellProfile,
which contains the settings for that cell, only. The mcpcPSCellProfileRef attribute
is therefore not relevant and is empty.
2
These cells do not have their own child instances of McpcPSCellProfile. Instead,
they use the mcpcPSCellProfileRef attribute to refer to one of the common
McpcPSCellProfile instances defined under the Mcpc container class. In this
example Mcpc contains two instances of McpcPSCellProfile, but it can contain 0 to
10 instances.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
172 (175)
5G Mobility and Traffic Management Guideline
As shown in Figure 12-1, each cell can either define its own child instance of
McpcPSCellProfile, or it can refer to a common profile defined under Mcpc. The
gNodeB will not allow both of these options to be configured simultaneously for an
individual cell. If neither option is configured, then the cell will use the default values for
each individual attribute. For rsrpCritical, these default values are defined within its
structure type, which is ReportConfigA1A2Rsrp. As the default values are not
necessarily the recommended values, always configure every cell with a valid
McpcPSCellProfile instance; either as a child or as a reference. Note that the system
does not automatically create any instances of McpcPSCellProfile; all instances must
be manually created.
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 Q3
(this
release)
- The feature EN-DC Triggered Handover During Setup now also
allows ENDCHO from a cell which the UE can use for EN-DC (this
impacts the NSA procedures, the section on 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 G
2020-08-24
© Ericsson AB 2020
173 (175)
5G Mobility and Traffic Management Guideline
Release
Comments
2020 Q2 - SA is now supported on both low and mid-band spectrum
(previous - ESS now allocates resources at individual PRB level
release) - Introduced NR Coverage-Triggered Secondary Node Release (A2
critical release)
- Updated the supported Carrier Aggregation CC configurations
- Added uplink carrier aggregation for NSA SCG
- Updated UE EN-DC Capability Enquiry – NSA, including additional
information on how overlapping bands are handled.
- Added the feature Enhanced NR Restriction (including impacts on SN
addition and EN-DC Triggered Handover During Setup)
- Added section on preventing SN addition on ESS carriers for noncompliant UEs
- Updated range for tInactivityTimer, which impacts Inactivity Release
section
- Added diagram with key MOs for release with redirect from LTE to NR
- Added voice fallback from NR SA to LTE (feature EPS Fallback to
IMS Voice)
- Added emergency voice fallback from NR SA to LTE (feature Service
Request-Based Emergency Fallback)
- Added new section on Configuring the eNodeB for SN addition, within
the Basic Intelligent Connectivity feature summary
- Added option to set (gNB)EUtranFreqRelation.cellReselectionPriority
to empty to exclude frequencies from SIB5.
- Added additional performance indicators for NR SA
- Added a new section on Configuration Profiles. These are used for
NR Coverage-Triggered Secondary Node Release, and will be used
increasingly for mobility in future releases.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
174 (175)
5G Mobility and Traffic Management Guideline
Release
Comments
2020 Q1
- Added Standalone 5G (NR SA) including a new section on SA
procedures (both idle and connected mode), interworking between LTE
and NR SA, and updated mobility states.
- Added Ericsson Spectrum Sharing (ESS), including a section of the
impacts of ESS on anchor carrier selection.
- Updated the 5G Icon recommendations in line with the latest from
GSMA
- Added Uplink User Plane Aggregation.
- Included the new mechanism for inhibiting SN addition during MO
voice call setup.
- Updated the Anchor Carrier Management section to include EN-DC
triggered handover and a high-level solution which uses the three UE
capability aware features (BIC, ENDCHO and CAIMC).
- Updated the feature summaries for: BIC, NR Coverage-Triggered NR
Session Continuity, CAIMC, STM and NR Mobility.
- Added feature summaries for Inter-Vendor CAIMC, TM9 CAIMC, ENDC Triggered Handover During Setup, Basic EN-DC Triggered
Handover During Setup, LTE-NR Uplink Aggregation.
- Added new cases to the Mobility Trigger Levels section including:
criteria to begin measurements, idle mode cell selection and
reselection, release with redirect from LTE to NR and from NR to LTE,
and EN-DC triggered handover during setup.
- Added KPIs for NR SA.
2/154 43-LZA 701 6017 Uen Rev G
2020-08-24
© Ericsson AB 2020
175 (175)