5G Mobility and Traffic Management Guideline

5G Mobility and Traffic Management
Guideline
Operating Guide
Document Number Revision

2/154 43-LZA 701 6017 Uen PA2
5G Mobility and Traffic Management Guideline
Contents
1 Purpose ............................................................................................ 3
2 Scope ............................................................................................... 3
3 Definitions ........................................................................................ 3
4 Mobility Overview ............................................................................ 6

4.1 5G Connectivity Options .................................................................... 6
4.2 Radio Bearer Types ........................................................................... 7
4.3 Radio Bearer Transitions ................................................................... 9
4.4 Split Bearer User Plane Functions ................................................... 10
4.5 Downlink Carrier Aggregation .......................................................... 16
4.6 Mobility States ................................................................................. 17
4.7 5G Status Icon on UE ...................................................................... 19
4.8 Measurement Quantities.................................................................. 21
4.9 Connected Mode Measurements ..................................................... 22
4.10 Frequency Ranges & Bands ............................................................ 27
5 Mobility and Connectivity Procedures ......................................... 28

5.1 Idle Mode Procedures...................................................................... 29
5.2 Data Bearer Setup and Release Procedures ................................... 30
5.3 NR Coverage-Triggered Mobility Procedures .................................. 38
5.4 VoLTE Procedures .......................................................................... 41
5.5 CS Fallback Procedures .................................................................. 46
5.6 LTE Coverage-Triggered Mobility Procedures ................................. 46
5.7 LTE Load-Triggered Mobility Procedures......................................... 50
6 LTE Anchor Carrier Management ................................................. 53

6.1 Choosing Suitable Anchor Carriers .................................................. 53
6.2 Steering 5G UEs to an Anchor Carrier ............................................. 56
6.3 Steering non-5G UEs away from an Anchor Carrier ........................ 74
6.4 Configuring SPID for Anchor Carrier Control ................................... 74
6.5 Configuring QCI for 5G Users .......................................................... 76
7 Appendix 1 – Mobility Features .................................................... 79

7.1 Software Value Packages and Features .......................................... 79
7.2 eNodeB Features ............................................................................ 80
7.3 gNodeB Features ............................................................................ 82
7.4 MME Features ................................................................................. 84
8 Appendix 2 – Mobility Trigger Levels ........................................... 85

8.1 Measurement-Based Secondary Node Addition .............................. 86
8.2 NR intra-frequency mobility ............................................................. 87
9 Appendix 3 – Mobility KPIs ........................................................... 88

9.1 Key Performance Indicators............................................................. 88
9.2 Performance Indicators.................................................................... 88
2/154 43-LZA 701 6017 Uen Rev PA2 2019-08-22  Ericsson AB 2019 2 (89)
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 for 5G network deployment is based on the 3GPP dual
RAT configuration EN-DC (also known as Option 3x). This option is non-standalone
(NSA), meaning that UEs that are connected to the network through 5G NR also have
a connection through 4G LTE. This document therefore covers aspects of mobility and
traffic management on both NR and LTE.
2 Scope
This document covers the 2019 Q3 release of LTE and NR software (referred to in this
document as “the current release”).
It focuses on Ericsson’s EN-DC solution (Option 3x) and does not cover other 5G
options (such as Option 2), which are not implemented in this release.
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 5G mobility; 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 Recommendation Lists. This guideline provides
recommended values only for cases which fall outside that document.
3 Definitions
The following terms and acronyms are used in this document.
Term Definition
5GC 5G Core
ASGH Advanced Subscriber Group Handling
BIC The feature Basic Intelligent Connectivity
CC Component Carrier
CPI Customer Product Information
CS Circuit Switched
CSI Channel State Information
DL Downlink
DRB Data Radio Bearer
Term Definition
EN-DC EUTRAN-NR Dual Connectivity. This is also known as
Option 3x.
eNodeB Node providing LTE user plane and control plane
protocol terminations towards the UE, and connected
via the S1 interface to the EPC
EPC Evolved Packet Core
EPS Evolved Packet System
ESM EPS Subscription Manager
gNodeB Node providing NR user plane and control plane
protocol terminations towards the UE, and 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 deployment which,
however, is not connected to a 5GC.
HARQ Hybrid Automatic Repeat Request
HRL Handover Restriction List
HSS Home Subscriber Server
IMS IP Multimedia Subsystem
KPI Key Performance Indicator
LTE Long Term Evolution (4G Air Interface Standard)
MAC Media Access Control
MBB Mobile Broadband
MCG Master Cell Group
MCPC The feature Mobility Control at Poor Coverage
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.
NAS Non-Access Stratum
Non-standalone NR A deployment configuration where NR and LTE
together provide the required connectivity over the air
interface.
NR NR Radio Access
Option 3x 5G Connectivity option, formally known as EN-DC
(EUTRAN-NR Dual Connectivity)
PDCP Packet Data Convergence Protocol
PDSCH Physical Downlink Shared Channel
PI Performance Indicator
PLMN Public Land Mobile Network
PSCell Primary Cell in SCG
Term Definition
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
SCG Secondary Cell Group
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
SS-RSRQ Synchronization Signal Reference Signal Received
Quality
STM The feature Subscriber Triggered Mobility
UE User Equipment
UL Uplink
VoLTE Voice over LTE
4 Mobility 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

There are two options: Evolved Packet Core (EPC) and 5G Core (5GC)
 The Master Radio Access Technology (RAT)

The Master RAT terminates the Control Plane from the core network.
 The Secondary RAT

This Secondary RAT supplies additional user plane resources. Not all options have
a Secondary RAT.
Table 4-1 – UE Connectivity Options
Connectivity Core Master Secondary 3GPP
Option Network RAT RAT Term
Option 1 EPC LTE - LTE
Option 3 EPC LTE NR EN-DC
Option 2 5GC NR - NR
Option 4 5GC NR eLTE NE-DC
Option 5 5GC eLTE - eLTE
Option 7 5GC eLTE NR NGEN-DC
In a given network deployment, a base station may support more than one option
simultaneously, with individual UEs connected by different options or even
combinations of options.
The current Ericsson release supports two of the six options:
 Option 1: This is legacy LTE.
 Option 3x: This 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). This is a non-standalone option, meaning that
LTE is required in addition to NR.
In addition, future Ericsson releases will support Option 2, NR standalone. These

three options are shown in Figure 4-1.
Figure 4-1 – 5G Connectivity Options
4.2 Radio Bearer Types

This section describes the radio bearers that connect the UE to the radio network in
Option 1 (Legacy LTE) and Option 3x (EN-DC). There are two radio bearer types:
 Signaling Radio Bearer (SRB)
 Data Radio Bearer (DRB)
The SRB transports Layer 3 signaling to and from the UE in connected mode. The
SRB is carried over the LTE RAT (the Master RAT) via the eNodeB in both Option 1
and Option 3x.
A DRB transports Layer 3 user plane data to and from the UE. In connected mode the
UE has one or more DRBs.
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 4.5), one or more secondary cells (SCells).
The SCG also has one primary cell (PSCell) and, if NR carrier aggregation is
configured (see Section 4.5), one or more secondary cells.
There are three types of DRB; one for Option 1 and two for Option 3x:
 Option 1 DRB:
- MN Terminated MCG DRB
 Option 3x DRBs:
- SN Terminated MCG DRB
- SN Terminated Split DRB
The SRB and the three DRB types are shown in Figure 4-2.
Figure 4-2 - Bearer Types in an EN-DC capable Network
Which DRBs a UE can use depends on its capability:
 UEs which are not EN-DC capable (legacy LTE UEs) can use one or more MN
Terminated MCG DRBs only.
 EN-DC capable UEs can use one or more MN terminated DRBs, or one or more
SN terminated DRBs, or combinations of the two. However, the network does not
configure the UE simultaneously with two different types of SN Terminated DRB
(that is an SN Terminated Split DRB and an SN Terminated MCG DRB).
4.3 Radio Bearer Transitions

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 are shown in Figure 4-3. In addition, the UE can be released to idle mode from
any bearer state.
Figure 4-3 - Bearer Type Transitions for EN-DC
Notes for Figure 4-3:
Initial context setup, incoming handover and RRC re-establishment result in the setup
of an MN Terminated MCG Bearer.
SN addition involves reconfiguring the MN terminated MCG DRB into an SN

terminated split DRB. The SN addition can be either configuration-based or
measurement-based. 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.9.5.2.
SCG release occurs when a bearer is set up that prevents other bearers being
configured as SN Terminated Split Bearers, for example at VoLTE call setup. SCG
resources are released but the PDCP context is kept.
SCG addition is triggered by reception of a B1 measurement. The B1 measurement is

started when the bearer – that prevents other bearers to be configured as SN
terminated Split DRBs – is released, for example at VoLTE call release.
There are two transitions labelled with 5. The transition from the SN Terminated Split
DRB state is triggered by NR radio link failure or by LTE or NR mobility events. The
transition from the SN Terminated MCG Bearer state is triggered only by LTE mobility
events (as there are no SCG resources in this case).
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 5.
4.4 Split Bearer User Plane Functions

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 4-4.
Figure 4-4 - 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.
 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.
 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 5.2.4.
In addition to the Downlink 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 4.5.
The above functions are described in more detail in the following sections.
4.4.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. Depending on the deployment
scenario, this provides a 10 to 12 dB NR coverage improvement over standalone NR
on the same frequency.
Figure 4-5 – Coverage Extension Due to EN-DC Uplink-Downlink Decoupling
Note that although uplink user plane data (PUSCH) can be moved to LTE uplink, the
uplink Layer 1 and Layer 2 signaling flow associated with the NR downlink (for
example HARQ and RLC Status Reports, which are more robust than user data) still
use the NR uplink.
4.4.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 4-6.
Figure 4-6 – Downlink User Plane Switching

1 Initially, when an SN Terminated Split Bearer is established (e.g. 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.
If the UE has more than one SN Terminated Split Bearer, all are switched at the same
time and use the same downlink resources.
A downlink user data flow at the PDCP layer requires an uplink signaling flow at Layer
1 and Layer 2, for example HARQ and RLC Status Reports. This uplink signaling is
carried on the same cell group as the downlink data flow:
 The Layer 1 and Layer 2 signaling associated with the SCG downlink user plane is
always carried on the SCG uplink.
 The Layer 1 and Layer 2 signaling associated with the MCG downlink user plane is
always carried on the MCG uplink.
4.4.3 Uplink User Plane Switching
Uplink User Plane Switching allows the uplink user plane to be switched dynamically
between MCG and SCG resources based on the NR uplink Layer 1 SINR, measured
by the gNodeB. It is enabled at cell level with the parameter
NRCellDU.endcUlLegSwitchEnabled.
The uplink user plane switch involves reconfiguration of the UE via RRC, unlike the
downlink user plane switch which does not require the UE to be reconfigured.
Uplink User Plane Switching is illustrated in Figure 4-7.
Figure 4-7 – Uplink User Plane Switching

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. If Uplink User Plane
Switching is disabled, the initial selection is kept statically throughout the lifetime of
the SN Terminated Split Bearer. In this example the parameter is set to SCG.
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 SINR which would
be measured if the UE were using on a single resource block. This normalization
must be considered when setting endcUlNrLowQualThresh. For example, if the
minimum requirement for acceptable NR performance is N resource blocks with a
SINR of X dB on each of those resource blocks, then endcUlNrLowQualThresh
should be set to X + 10 * log10(N). In other words, the threshold should be
increased by 3 dB for each doubling of the number of required resource blocks.
3 Even if the NR UL SINR becomes acceptable again (above
NRCellDU.endcUlNrLowQualThresh + NRCellDU.endcUlNrQualHyst), a
switch back to SCG (NR) resources cannot occur until the prohibit timer expires.
4 When the GNBCUUPFunction.endcUlNrRetProhibTimer expires, and the
quality remains acceptable, a switch back to SCG (NR) resources is triggered.
If the UE has more than one SN Terminated Split Bearer, all are switched at the same
time and use the same uplink resources.
An uplink user data flow at the PDCP layer requires a downlink signaling flow at Layer
1 and Layer 2, for example HARQ and RLC Status Reports. This downlink signaling is
carried on the same cell group as the uplink data flow:
 The Layer 1 and Layer 2 signaling associated with the SCG uplink user plane is
always carried on the SCG downlink.
 The Layer 1 and Layer 2 signaling associated with the MCG uplink user plane is
always carried on the MCG downlink.
4.4.4 Downlink User Plane Aggregation
The licensed feature LTE-NR Downlink Aggregation (FAJ 121 4912) enables
transmission of downlink user plane data simultaneously on both the MCG and SCG
resources of an SN Terminated Split Bearer. Different packets are sent on the two cell
groups. The feature improves the end user throughput.
Figure 4-8 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 4.4.2).
Figure 4-8 – Downlink Aggregation and User Plane Switching for a Split Bearer

1 Good NR DL SINR (derived from the CQI measured on the Primary SCell) triggers
a switch from MCG to SCG resources (see Section 4.4.2).
2 Poor NR DL SINR or a lack of CQI reports triggers a switch to MCG resources only
(see Section 4.4.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 4.4.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.
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.
4.4.5 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 buffers packets to
reduce the flow rate towards the relevant RLC entity. 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.
4.5 Downlink Carrier Aggregation

In addition to the Downlink User Plane Aggregation described in Section 4.4.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 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 mid-band NR:
- Up to 5 LTE CCs, and
- 1 NR CC
 For high-band NR:
- Up to 5 LTE CCs, and
- Up to 4 NR CCs
Figure 4-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 4-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.
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.
4.6 Mobility States

The mobility states for User Equipment (UE) in an EN-DC deployment are identical to
those in legacy LTE and are shown in Figure 4-10.
Figure 4-10 – UE Mobility States
An EMM-DEREGISTERED UE is not in contact with the network, that is, it is turned

off, out of coverage etc.
An EMM-REGISTERED (attached) UE is known to the network and can send or

receive traffic when required.
A UE in ECM-CONNECTED state (connected mode) is known to the LTE RBS at a

cell level and can send or receive data to the network, and so is consuming radio
resources.
A UE in ECM-IDLE state (idle mode) is not consuming radio resources (other than
paging channel) and must transition to ECM-CONNECTED state before sending or
receiving traffic.
Note that 3GPP Release 15 introduced an additional EMM-REGISTERED state called

RRC-INACTIVE. However, this state is not used in an EN-DC deployment as it
requires a 5GC.
4.6.1 ECM-IDLE, Idle Mode
In idle mode, all UE related information in the radio network is released. This reduces
load in the eNodeB during long periods of inactivity. The MME retains the UE context
and information about established bearers, but there is no explicit signaling between
the UE and EPC.
However, the UE is still in EMM-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 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 MME. Idle mode reselection parameters are
broadcast in each cell, and an LTE 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.
Further information on idle mode procedures is provided in Section 5.1.
4.6.2 ECM-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 5.
4.7 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. However, in non-standalone 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 in
LTE in connected mode. 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
indicator should be displayed.
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
SIB 2. This bit can be used 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 indicator. This bit is
the only 3GPP agreed mechanism for determining the availability of 5G when camped
on LTE in idle mode. The parameters for controlling the upperLayerIndication are
shown in Table 4-2.
Note: For certain UE implementations, NAS signaling (containing NR restriction info)

can prevent an EN-DC capable UE from displaying any 5G icon even if
upperLayerIndication-rel15 in SIB2 is correctly received in the UE.
Table 4-2 - Parameters for Controlling the upperLayerIndication
MO Parameter Description
EUtranCellFDD/ primaryUpperLayerInd Indicates whether
EUtranCellTDD upperLayerIndication is set for the
PLMN identified by
ENodeBFunction.eNodeBPlmnId
EUtranCellFDD/ additionalUpperLayerIndList Indicates whether
EUtranCellTDD upperLayerIndication is set for any
MO Parameter Description
additional PLMN identities that may be
broadcast in SIB1.
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 four configurations for determining

whether to display the 5G status icon. These configurations are shown in Table 4-3.
Configuration A is the most restrictive and Configuration D is the most relaxed. States
1 to 5 deal with NR NSA whereas State 6 deals with NR standalone. GSMA submitted
this recommendation to 3GPP in a liaison statement (R2-1713952, LS Reply to 3GPP
SA2 on Status Icon related to 5G).
Table 4-3 - GSMA Recommended Configurations for the 5G Icon
State Configuration
A B C D
1 (IDLE under or Connected to LTE cell not supporting
4G 4G 4G 4G
NSA)
2 (IDLE under or Connected to LTE cell supporting NSA
4G 4G 4G 5G
and no detection of NR coverage)
3 (Connected to LTE only under LTE cell supporting NSA
4G 4G 5G 5G
and detection of NR coverage)
4 (IDLE under LTE cell supporting NSA and detection of
4G 5G 5G 5G
NR coverage)
5 (Connected to LTE + NR under LTE cell supporting
5G 5G 5G 5G
NSA)
6 (IDLE under or connected to NG-RAN while attached
5G 5G 5G 5G
to 5GC)
It is up to the network operator, UE vendor and possibly regulators to determine

whether the GSMA recommendations are followed and, if so, which configuration is
used. Figure 4-11 shows where the 5G icon would be displayed in an example
network deployment, comparing configuration A with D.
Figure 4-11 - 5G Icon Configuration Examples
4.8 Measurement Quantities

In an EN-DC deployment, UEs make radio signal measurements on both LTE and NR
cells. 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 on 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 supported trigger quantities are SS-RSRP and SS-
RSRQ. These are explained below.
4.8.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 eNodeB 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.8.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.
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.9 Connected Mode Measurements

In an EN-DC deployment, UEs in connected mode make radio signal measurements
on both LTE and NR cells. Measurements on LTE cells are unchanged from legacy
LTE and are described in the LTE Mobility and Traffic Management Guideline.
Measurements on NR cells are described in this section.
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.
When an event is triggered, the UE sends a measurement report to the network which
can then trigger a mobility action.
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:
RSRP_PCell < (LTE)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 Event A3 measurements used for detecting
neighbor NR cells that are an offset better than the PSCell. UEs are required to
make these measurements when:
SS-RSRP_PSCell < (NR)UeMeasControl.sMeasure
The default value is ‘empty field’ which means disabled (always measure).
The UE may also measure when the RSRP or SS-RSRP exceeds sMeasure, but this
is not required by the standard.
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.
4.9.1 Triggering Quantity
In the current software release, the triggering quantity can be either SS-RSRP or SS-
RSRQ.
SS-RSRP is the default and is recommended for both Event B1 (to detect NR
coverage) and Event A3 (for NR intra-frequency mobility).
SS-RSRQ is not recommended as a triggering quantity. It is influenced strongly by

own cell load and by the distribution of load amongst the beams in use, as described
in Section 4.8.2. This makes it difficult to select an appropriate threshold value.
4.9.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 RSRP and RSRQ
 For NR Event 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.9.3 Threshold, Hysteresis and Time To Trigger
Figure 4-12 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 e.g. Event B1 (IRAT Neighbor
Becomes Better than Threshold) which could be either SS-RSRP or SS-RSRQ.
Figure 4-12 – Event Triggering Process
 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.
4.9.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 are mandated by the 3GPP standards for
FR1 (< 6 GHz), and for FR2 (24-86 GHz) if the UE requires it as indicated in the
capability information. However, some early UEs do not require measurement gaps.
4.9.5 Measurement Events
This section describes the event-based measurements used for evaluation of NR

coverage, namely Event A3 and Event B1.
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.9.5.1 Event A3: Neighbor NR Cell Becomes Offset Better than PSCell
Event A3, shown in Figure 4-13, is used to detect when a neighboring intra-frequency
NR cell becomes offset better than the primary secondary NR cell (PSCell). This
measurement event is configured using the ReportConfigA3 MO in the NR Node.
Figure 4-13 – Event A3 – Neighbor NR Cell Becomes Offset Better than PSCell
Upon satisfying Event A3, the UE sends a measurement report to the gNodeB via the
eNodeB. This triggers the intra-frequency mobility procedure described in Section
5.6.1.
The full formula (showing all parameters involved with this event) is provided in
Section 8.2.
Note: Future software releases will remove the A3 suffix from the hysteresisA3,
offsetA3 and timeToTriggerA3 parameters.
4.9.5.2 Event B1: IRAT Neighbor Becomes Better than Threshold
Event B1, shown in Figure 4-14, is used to detect acceptable NR coverage before an
EN-DC bearer is set up. This measurement event is configured using the
ReportConfigB1GUtra MO in the eNodeB.
Figure 4-14 – Event B1 – IRAT Neighbor Becomes Better than Threshold
Upon satisfying Event B1, the UE sends a measurement report to the eNodeB, which
triggers the SN addition procedure described in Section 5.2.3.
The full formula (showing all parameters involved with this event) is provided in
Section 8.1.
4.10 Frequency Ranges & Bands

Standardized ranges FR1, FR2
The air interface defined by 3GPP for 5G is known as New Radio (NR). The
specification defines two Frequency Ranges (FRs):
 FR1 (<6 GHz)
 FR2 (24-86 GHz)
Mid-band, High-band and Low-band
Additionally, the current and planned Ericsson radio products refer to the following
frequency ranges:
High-band (TDD) 24 GHz – 40 GHz

New spectrum Typically: 28, 39 GHz
Mid-band (FDD/TDD) 1 GHz – 6 GHz

Legacy & new spectrum Typically: 2.6, 3.5 GHz
Low-band (FDD) Sub 1 GHz

Legacy & new spectrum Typically: 600 MHz
5 Mobility and Connectivity Procedures

This section describes mobility and connectivity procedures that occur in an EN-DC
network. The procedures are triggered by one of the following changes:
 Service activity (e.g. establishing or releasing a data or voice bearer)
 Changes in NR coverage (e.g. leading to intra-frequency mobility or radio link

failure)
 Changes in LTE coverage (e.g. leading to intra-frequency, inter-frequency or inter-

RAT mobility, or radio link failure)
 Load management by the eNodeB (e.g. leading to inter-frequency handover)
In some cases, the procedure depends on which radio bearers are in place when the
procedure is triggered.
Figure 5-1 shows an example of a series of procedures for a UE moving through an

EN-DC 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 5-1 - Example of EN-DC 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.
5.1 Idle Mode Procedures

In an EN-DC deployment, 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 EN-DC are described in the
following sections.
5.1.1 Upper Layer Indicator
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 indicator”
in system information. This indicator is used by UEs when deciding whether to display
a 5G status icon.
The upper layer indicator is described in detail in Section 4.7 - 5G Status Icon on UE.
5.1.2 NR Non-Standalone Cells
In an EN-DC deployment the NR cells are non-standalone and do not provide idle
mode services. Idle mode UEs must therefore not camp on the NR cells.
UEs which are capable of EN-DC operation only (not 5G standalone operation) do not
reselect to the NR cells in idle mode as they are not capable of doing so.
UEs which are capable of 5G standalone operation and are camped on the LTE
network in idle mode do not reselect to the EN-DC NR cells because the LTE cell does
not instruct UEs to measure the NR frequencies for idle mode reselection.
UEs which are capable of 5G standalone operation and enter the NR coverage area
without camping on LTE first, are prevented from camping on the NSA only cells
because SIB1 is not broadcast from these cells. This is configured by setting
NRCellDU.secondaryCellOnly = true (which is the default value).
5.1.3 NR Standalone Cells
While Ericsson does not support NR Standalone (Option 2) in the current release,
operators may deploy NR Standalone solutions from other vendors. To allow UEs to
reselect to such standalone networks in idle mode, the eNodeB feature NR Coverage-
Triggered NR Session Continuity is used. This feature is described in Section 7.2.2.
5.2 Data Bearer Setup and Release Procedures

This section describes the procedures associated with establishing and releasing a
data bearer for transferring MBB data. VoLTE procedures are covered in Section 5.4.
5.2.1 Data Bearer Setup from Idle Mode
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 5-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 resources only. NR resources are added, if allowed, by a
subsequent SN addition procedure, as described in Section 5.2.3.
5.2.2 Data Bearer Addition
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 on the default bearer.
An additional bearer is always added as an MN Terminated MCG Bearer, regardless

of whether existing bearers are MN or SN Terminated (as shown in Figure 5-3). The
added bearer therefore has access to LTE resources only.
Figure 5-3 - Bearer Addition from Connected Mode with Pre-existing Split Bearer
NR resources are added, if allowed, by subsequent secondary node release and

addition procedures, as described in Section 5.2.4 and Section 5.2.3 respectively.
5.2.3 Secondary Node Addition
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 transitioning the MN Terminated MCG Bearer into an SN
Terminated Split Bearer, as shown in Figure 5-4.
Figure 5-4 – Secondary Node Addition
Secondary Node Addition is either configuration-based or measurement-based.

Configuration-based involves a blind setup to a pre-configured NR cell. Measurement-
based involves UE measurements to detect and report coverage from NR cells. Which
is used depends on whether the LTE cell is configured with a reference to an NR cell.
The NR cell reference is defined with the following attribute:
 EUtranCellFDD.extGUtranCellRef
 EUtranCellTDD.extGUtranCellRef
If extGUtranCellRef is not defined, then SN addition is always measurement-

based.
If extGUtranCellRef is defined, then SN addition is either configuration-based or

measurement-based, as follows:
 Configuration-based SN addition is used for the following cases:
- Initial context setup
- Incoming handover
 Measurement-based SN addition is used for the following cases:
- A bearer (that prevents other bearers being configured as SN terminated split

DRBs) is released, for example VoLTE call release
Measurement-based SN addition uses the B1 measurement to detect coverage from

NR cells. When configuring the B1 measurement in the UE, the eNodeB uses the
lowest NR frequency among the candidates. Candidate frequencies are defined using
the GUtranSyncSignalFrequency MO. The B1 measurement uses the
b1ThresholdRsrp, b1ThresholdRsrq, hysteresisB1, timeToTriggerB1
and triggerQuantityB1 that are configured in the ReportConfigB1GUtra.
5.2.3.1 Prerequisites for SN Addition
The following conditions are prerequisites for SN addition:

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 "NR Restriction in EPS as Secondary RAT" information element is not present
in the received Handover Restriction List. The UE Context stores
the NR Restriction information, and it is forwarded at eNodeB handover
procedures.
4 At least one PLMN ID matches. The PLMNs for which EN-DC is supported must
be configured in the endcAllowedPlmnList per LTE cell.
If no PLMN ID is listed, 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 serving
LTE cell primary PLMN ID is listed in the endcAllowedPlmnList.
5 An EN-DC band combination exists, meeting the following requirements:

5.1 The band combination is signaled by the UE in the UE MRDC Capabilities.
5.2 The band combination has the same LTE band as the current
serving LTE cell.
5.3 The band combination has the same NR band as one external NR cell
defined and hosted by a gNodeB with X2 connectivity.
5.4 The UE indicates support for simultaneousRxTxInterBandENDC for the band
combination.
6 Criteria related to VoLTE. At least one of the following conditions is met:
6.1 None of the bearers established for this UE has Service Type = VoIP.
6.2 The UE indicates support for Dynamic Power Sharing for the selected EN-
DC band combination.
6.3 The operator-defined attribute endcSplitAllowedNonDynPwrShUe is set
to true
7 No bearer prevents the use of EN-DC. EN-DC is allowed for the UE only if none of
the DRBs prevent other DRBs from being setup as split bearer.
8 Split is allowed for at least one bearer. The evaluation whether split bearer is
allowed to be used is contained by EN-DC Profile Configuration.
9 TTI Bundling is not activated for any of the established bearers.
5.2.3.2 Preventing SN Addition for Subscribers Without a 5G Subscription
Operators may wish to prevent subscribers without a 5G subscription from accessing

5G resources, even when the subscriber’s UE is 5G capable. This can be achieved
with the MME feature NR Access Control. This feature controls access to NR at the
subscriber level.
To determine whether a particular UE should be given access to NR, the feature uses
the “NR Restriction in EPS as Secondary RAT” Information Element (IE). If this IE is
received by the eNodeB for a UE, and is set to NRrestrictedinEPSasSecondaryRAT,
then the UE is not given access to NR.
The NR Restriction 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. By default, the IE is not included and access to NR is not restricted.
NR access is allowed when there is no NR restriction set for the subscriber in the HSS
and there is no manually configured NR restriction in the MME. The configuration in
the MME is per IMSI number series.
Figure 5-5 – Handover Restriction List and NR Restriction
5.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).
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; only one can be
configured in a given eNodeB:
 Disallow split bearer for problematic devices only (blacklist)
 Allow split bearer for certain devices only (whitelist)
Disallow Split Bearer for Problematic Devices Only
Use the following steps to disallow split bearer use on problematic devices only, and
allow it on all other capable devices:
 Configure ImeisvProfile.listOfTacSvSns with the details of the problematic

devices.
 Include the value 6 (FEATURE_NAME7, Basic Intelligent Connectivity) in the array

ImeisvTable.listOfFeaturesDefaultOn
 Include the value 6 (FEATURE_NAME7, Basic Intelligent Connectivity) in the array

ImeisvProfile.listOfFeaturesToTurnOff
Allow Split Bearer for Certain Devices Only
Use the following steps to allow split bearer only on certain devices, for example the
devices used in a trial:
 Configure ImeisvProfile.listOfTacSvSns with the details of the allowed

devices.
 Include the value 6 (FEATURE_NAME7, Feature Basic Intelligent Connectivity) in

the array ImeisvTable.listOfFeaturesDefaultOff
 Include the value 6 (FEATURE_NAME7, Feature Basic Intelligent Connectivity) in

the array ImeisvProfile.listOfFeaturesToTurnOn
5.2.3.4 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.Rcs.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. The PDCP is then moved from the SN back to the eNodeB,
which includes reconfiguring the SN Terminated Split Bearer to an MN Terminated
MCG Bearer.
The subsequent procedure depends on whether the eNodeB uses configuration-based

or measurement-based SN Addition:
 Measurement-based: The eNodeB configures a B1 measurement in the UE to

detect NR coverage. If a B1 report is received from the UE, then the eNodeB
triggers another attempt at SN Addition.
 Configuration-based: The eNodeB takes no further action until the next trigger for
SN Addition occurs (as listed in Section 5.2.3).
5.2.4 Secondary Node Release
Secondary Node Release 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
When the SN is released, any SN terminated bearers are transitioned to MN

Terminated MCG Bearers, as shown in Figure 5-6.
Figure 5-6 - SN Release - Split Bearer Example
5.2.5 Release to Idle Mode
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.
5.2.5.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.
The minimum settable value for tInactivityTimer is 10 seconds, and this setting
is typically used.
5.2.5.2 Inactivity Release – UE with an SN terminated bearer
If the UE has one or more SN terminated bearers, then both the MN (eNodeB) and the
SN (gNodeB) monitor UE activity. The monitoring is performed at the PDCP layer. The
MN monitors the activity of any MN terminated DRBs. The SN monitors the activity of
SN terminated DRBs and informs the eNodeB of the results over the X2-AP interface.
The eNodeB is responsible for releasing a UE due to inactivity. 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 a
further time of Rcs.tInactivityTimer - 5 seconds expires without receiving
an active notification. Given that the SN requires 5 seconds of inactivity before
notifying the eNodeB, the total inactivity time required for SN terminated bearers is
at least tInactivityTimer; same as for MN terminated bearers. Note that the
minimum configurable value for tInactivityTimer is 10 seconds, which is
longer than the 5 second timer in the SN.
Figure 5-7 summarizes the procedure for release due to inactivity for a UE with both
an MN terminated MCG DRB and an SN terminated split DRB.
Figure 5-7 - Release due to Inactivity - Split Bearer Example
5.3 NR Coverage-Triggered Mobility Procedures

This section covers mobility procedures that are triggered by changes in NR coverage.
5.3.1 NR Coverage-Triggered Intra-Frequency Mobility
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 5-8.
Figure 5-8 – NR Intra-Frequency Mobility
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
 Neighbor relation between the serving and reported cell must be configured
 Parameter NRCellRelation.isHoAllowed = true for the target NR cell
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 is not supported in the
current software release. Figure 5-9 shows the managed objects involved.
Figure 5-9 – Managed Objects for NR Neighbor Configuration
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.
5.3.2 NR Radio Link Failure
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.Rcs.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.Rcs.n310 consecutive “out-of-synch” indications starts

timer T310 (set by GNBDUFunction.Rcs.t310)
- GNBDUFunction.Rcs.n311 consecutive “in-synch” indication stops timer

T310
- RLF occurs when T310 expires
If the gNodeB detects NR RLF, via the following condition, then the gNodeB initiates
SN release:
 RLC DL delivery failure. The number of DL RLC retransmissions exceeds

GNBDUFunction.DataRadioBearer.dlMaxRetxThreshold
5.4 VoLTE Procedures

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 these two VoLTE bearers from being configured as EN-DC split
bearers. Other bearers, such as QCI9, may still be configured as split bearers, even
when VoLTE is present.
For a bearer to be configured as split, split bearer must be allowed for both the bearer
itself and the UE overall. To determine whether split bearers are allowed for the UE
overall, the eNodeB considers the QCI and Allocation and Retention Priority (ARP)
values of all the bearers. It also considers whether the UE is capable of dynamic
power sharing.
Split bearer is allowed if all of the following conditions are met:
 ARP Value of Bearer > meNodeBS1TermReqArpLev for at least one bearer
 ARP Value of Bearer > splitNotAllowedUeArpLev for all bearers
 TTI bundling is not activated
 And at least one of the following conditions is met:
- The UE is capable of dynamic power sharing
- The parameter endcSplitAllowedNonDynPwrShUe is true
- The UE has no bearers with service type VoIP
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 by
assigning EndcProfilePredefined = 3 to QCI’s used for VoIP services (e.g. QCI1
and QCI2). This predefined profile has meNbS1TermReqArpLev = 15 (disallowing
split for this bearer) and splitNotAllowedUeArpLev =15 (disallowing split for other
bearers).
Note that 3GPP specifies that the QCI1 bearer is not allowed to be configured as a
split bearer.
Mission Critical Push to Talk (MCPTT), which uses QCI65, QCI66 or QCI69, impacts
split bearer setup in the same way as VoLTE (QCI1).
5.4.1 VoLTE Setup from Idle Mode
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 (e.g.
QCI9) are set up as MN Terminated MCG Bearers, as shown in Figure 5-10.
Figure 5-10 - VoLTE Setup from Idle Mode
5.4.2 VoLTE Setup in Connected Mode
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:
 SN Terminated MCG Bearer
5.4.2.1 VoLTE Setup with Pre-Existing MN Terminated MCG Bearer
This procedure is unchanged from the legacy LTE procedure. The VoLTE bearer for
voice data (QCI1) is set up as an MN Terminated MCG Bearer, as shown in Figure
5-11.
Figure 5-11 - VoLTE Setup with MN Terminated MCG Bearer
5.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 5.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 5-12. 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 5-12 - 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 5-13.
Figure 5-13 - VoLTE Setup with Split Bearer Allowed
5.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
5.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
5-14.
Figure 5-14 - VoLTE Setup with SN Terminated MCG Bearer
5.4.3 VoLTE Release
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 5.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 5-15.
Figure 5-15 - 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 5.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
5-16.
Figure 5-16 - VoLTE Release with SN Terminated MCG Bearer
If a new bearer is set up while an SN Terminated Split Bearer is in place, then the new
bearer is set up as an MN Terminated Split 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 Figure 5-16. 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
5-17.
Figure 5-17 - VoLTE Release with SN Terminated Split Bearer
5.4.4 VoLTE Single Radio Voice Call Continuity (SRVCC)
The procedure for SRVCC depends whether a Secondary Node is configured or not. If
a Secondary Node is not configured, then the procedure is identical to that for legacy
LTE. If a Secondary Node is configured, then it is released at SRVCC.
5.5 CS Fallback Procedures

This section describes procedures that are initiated by a CS fallback event.
5.5.1 CS Fallback from Idle Mode
The procedure for CS fallback from idle mode is unchanged by the deployment of EN-
DC and is identical to that for legacy LTE.
5.5.2 CS Fallback from Connected Mode
The procedure for CS fallback from connected mode depends whether a Secondary
Node is configured or not.
If a Secondary Node is not configured, then the procedure is identical to that for legacy
LTE.
If a Secondary Node is configured, then it 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 measurement-based CS Fallback is activated, the NR B1 measurements are

stopped (if ongoing).
Otherwise the procedure is identical to that for legacy LTE.
5.6 LTE Coverage-Triggered Mobility Procedures

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.
5.6.1 Coverage-Triggered Intra-LTE Handover
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:
 SN Terminated MCG Bearer with VoLTE
The procedures cover both intra and inter-frequency handover within LTE.
5.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 5-18. This case can arise, for example, if the serving LTE cell is not capable
of EN-DC. The first part, the handover itself, is identical to that for legacy LTE. The
second part, the addition of the secondary node and secondary cell group, occurs only
if split bearer is allowed for the UE in the target cell.
Figure 5-18 – Intra-LTE Handover with MN Terminated MCG Bearer without VoLTE

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 EN-DC
setup. If the target cell uses configuration-based EN-DC setup, then after the handover
in Step 2 the target eNodeB attempts to set up EN-DC on the configured NR cell.
5.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 5-19.
Figure 5-19 – Intra-LTE Handover with SN Terminated Split Bearer

1 eNodeB receives Event A3 or Event A5 report from the UE
2 eNodeB initiates secondary node release, including secondary cell group release
3 eNodeB initiates intra-frequency or inter-frequency handover on LTE
4 eNodeB configures B1 measurement report in the UE, if the target LTE cell is also
EN-DC capable.
5 eNodeB receives Event B1 report from the UE
6 eNodeB initiates secondary node addition, including secondary cell group addition
The above procedure assumes that the target cell uses measurement-based EN-DC
setup. If the target cell uses configuration-based EN-DC setup, 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).
5.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 first, the resulting handover procedure is shown in
Figure 5-20.
Figure 5-20 – Intra-LTE Handover with SN Terminated MCG Bearer

1 eNodeB receives Event A3 report from the UE
2 eNodeB initiates SN release

3 eNodeB initiates intra-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.
5.6.2 LTE Coverage-Triggered IRAT Handover
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.
5.6.3 LTE Radio Link Failure
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.
5.6.4 LTE RRC Connection Reestablishment
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 in a cell that supports EN-DC, the

eNodeB sets up an Event B1 measurement in the UE to facilitate SN Addition, even if
the cell is configured for configuration-based SN Addition. However, the Event B1
measurement is not set up if TTI bundling is active for the connection.
5.7 LTE Load-Triggered Mobility Procedures

In an EN-DC network, 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.
5.7.1 LTE Load-Triggered Mobility – Non EN-DC Capable UEs
Load-triggered mobility for UEs that are not capable of EN-DC is unchanged from
legacy LTE behavior.
5.7.2 LTE Load-Triggered Mobility – UEs With Split Bearer Configured
Load-trigged mobility is disabled for UEs with an SN Terminated Split Bearer

configured.
5.7.3 LTE Load-Triggered Mobility – EN-DC Capable UEs Without Split Bearer
Load-triggered mobility can be disabled for UEs that are capable of EN-DC but do not
have an SN Terminated Split Bearer configured. This is done with the parameter
LoadBalancingFunction.lbAllowedForEndcUe.
If lbAllowedForEndcUe = false, then load-triggered mobility is not allowed:
 This setting is recommended by Ericsson.
 It prevents load management features from configuring measurements in EN-DC

capable UEs without a split bearer, which disables load-triggered handover.
If lbAllowedForEndcUe = true, then load-triggered mobility is allowed:
 Load-triggered inter-frequency handovers follow the same procedures as

coverage-triggered inter-frequency handovers, as detailed in Section 5.6.1.
 Load-triggered inter-RAT handovers follow the same procedures as coverage-

triggered inter-RAT handovers, as detailed in Section 5.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 feature Load-Based

Distribution at Release (LBDAR). However, if the feature Subscriber Triggered Mobility
(STM) is active, then any cell reselection priorities imposed by STM override those
imposed by LBDAR. STM can therefore be used to prevent LBDAR from impacting
EN-DC capable UEs. Section 6 provides more detail on using STM to control the LTE
mobility of EN-DC capable UEs.
6 LTE Anchor Carrier Management

The Ericsson implementation for EN-DC allows any LTE carrier to be configured 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 6.1.
If all LTE carriers are configured as anchors, then 5G capable UEs can use whatever
LTE carrier they are camped on as the anchor for EN-DC. In this case, EN-DC can be
deployed without requiring any changes to the existing LTE mobility and traffic
management strategy. This is the simplest approach, and the recommended one.
If only some of the LTE carriers are configured as anchors, then 5G service is
available to only those UEs that are camped on an anchor carrier. Any UEs that are
camped on a non-anchor carrier must be moved to an anchor carrier to obtain 5G
service. If the existing mobility and traffic management strategy does not accomplish
this, then the mobility strategy needs to be changed when 5G is deployed. Section 6.2
explains how it can be changed to steer 5G UEs towards an anchor carrier.
6.1 Choosing Suitable Anchor Carriers

The following sections present criteria for determining whether an LTE carrier is
suitable for use as an anchor for EN-DC.
6.1.1 Standardized EN-DC Band Combinations
The allowed band combinations for EN-DC operation are specified in 3GPP TS
38.101-3.
In a given network deployment, some combinations of LTE and NR may not be

allowed. If an LTE carrier has no allowed combinations with the deployed NR carriers
then it cannot be used as an anchor carrier.
6.1.2 UE support of EN-DC Band Combinations
The UE reports its supported list of EN-DC band combinations in the IE UE-MRDC-
Capability as specified in 3GPP TS 38.331.
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
EN-DC inter-band combinations that fall within one of these band groups are unlikely
to be supported by UEs and should therefore be avoided. For example, if NR is
deployed in a low-band (below 1 GHz), then the LTE anchor should be mid-band
(above 1 GHz).
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 combinations that are likely to be supported by UEs. If so, that carrier is unsuitable
for use as an anchor carrier.
6.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.
Note that 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 that if a UE supports a band combination then it typically also supports

simultaneous reception and transmission on that band combination.
6.1.4 Potential IM Interference and Single UL Allowed
UEs that transmit simultaneously on two different frequencies (e.g. 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.
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 indicate
that it supports 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 can indicate that they support single uplink on a
particular EN-DC combination using the IE MRDC-Parameters (singleUL-
Transmission), as specified in 3GPP TS 38.331.
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 6-1 shows a potentially
problematic case, where the IM products fall across the used LTE downlink. Figure 6-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 6-1 - Example of Frequencies with Potentially Problematic IM Interference
Figure 6-2 - Example of Frequencies with Non-Problematic IM
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. Note that use of single UL TX inevitably impacts
performance compared to dual UL TX, since LTE and NR UL transmissions are
divided in time.
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.
6.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
(e.g. 5212, 5216, 6318, 6620, 6630). Older baseband units (e.g. 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.
6.1.6 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 5G 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, it may be desirable to avoid using carriers that do not have
contiguous coverage as anchor carriers.
 UL capacity: To improve uplink performance, it may be desirable to use carriers

with a larger bandwidth (e.g. 20 MHz rather than 5 MHz)
6.2 Steering 5G UEs to an Anchor Carrier

The network operator may choose to use only a subset of the available LTE carriers
as anchors for EN-DC. In this case, any 5G capable UEs that happen to be camped
on a non-anchor carrier do not have access to 5G. To give these UEs access to 5G
they must be steered to an anchor carrier. This steering is best done selectively, so
that UEs that are not capable of 5G 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 6-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_Cov_Go Encourage 5G UEs to perform a handover from non-anchor to anchor

using aggressive coverage-triggered mobility settings
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 6-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:
SPID Subscriber Profile ID for RAT/Frequency Priority

The SPID is a number from 1 to 256 which is set per subscriber in
the HSS. It is sent from the HSS to the MME and from there to the
eNodeB where it can be used to impact mobility behavior. One or
more SPID values can be used to differentiate 5G subscribers from
non-5G subscribers.
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.
UE Capability The UE informs the eNodeB whether it is capable of EN-DC, and this
information can be used to impact mobility behavior.
In the strategies presented here, these mechanisms are used together with one or
more of the following eNodeB features to control mobility behavior:
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 mobility behavior to be adapted based on the QCI
value and frequency relation.
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.
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.
Table 6-1 describes how the differentiation mechanisms and features (green cells) can
be combined to build a solution for each strategy component. Each green cell
represents a possible solution for the strategy component; some strategy components
have more than one possible solution. Each possible solution is described in detail in a
subsequent section of this document.
Table 6-1 – Solutions for Steering 5G UEs
Strategy Mechanism for Differentiating 5G UEs
Component SPID QCI UE Capability
5G_Idle_Go STM - -
5G_Idle_Stay STM - -
5G_Cov_Stay STM & MCPC MLSTM -
5G_Cov_Go STM & MCPC MLSTM -
5G_IFLB_Stay STM SSLM BIC
The following solution descriptions assume that unique SPID and QCI values are
assigned in the core network for 5G subscribers. However, if this is not the case,
Sections 6.4 and 6.5 provide details on how to do so.
6.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 solution.
6.2.1.1 5G_Idle Solution Based on SPID and STM
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”.
To ensure complete control over prioritization, it is therefore recommended to

configure STM with cellReselectionPriority values for all existing layers:
EUtranFreqRelation, UtranFreqRelation and GeranFreqGroupRelation.
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 6.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 (e.g. 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:
Assign an even lower priority to the non-anchor frequency:
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 6-4.
Figure 6-4 – Example Solution for 5G_Idle_Go and 5G_Idle_Stay
Besides the definition of the frequency priorities, it is also important to review the
values of the thresholds that control the cell reselection towards frequencies with
higher and lower priorities:
 EUtranFreqRelation.threshXHigh – threshold for reselecting towards a

higher priority frequency
 EUtranCellFDD/TDD.sib3.sNonIntraSearch – threshold for starting

measurements on a lower priority frequency
 sib3.sNonIntraSearchv920Active – enables sending

sib3.sNonIntraSearchP and sib3.sNonIntraSearchQ to control
measurement activation thresholds per RSRP and RSRQ
 EUtranCellFDD/TDD.threshServingLow – serving cell threshold for

reselection towards a lower priority frequency.
 EUtranFreqRelation.threshXLow – target cell threshold for reselection to a

lower priority frequency.
Note that these thresholds cannot be modified on SPID basis.
6.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 6-2.
Table 6-2 – Solutions for 5G_Cov_Stay

Solution Mechanism Features Comments
Number for Used
Differentiating
5G
Subscribers
1 SPID STM This SPID-based solution completely prevents
handover from anchor carriers to non-anchor
carriers. It is a simple solution, but it is not
suitable if the non-anchor carriers provide unique
coverage.
2 SPID STM, This SPID-based solution uses the MCPC
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 two stage search helps UEs to
remain on an anchor carrier. This solution does
not completely prevent handover to non-anchor
carriers, so it can be used even when non-
anchor carriers provide unique coverage.
However, it is more complex than Solution 1.
3 QCI MLSTM This QCI-based solution uses the MLSTM
feature to introduce offsets to delay the handover
from anchor carriers to non-anchor carriers, so
that handover amongst anchor carriers is given
priority. This is a very simple solution, and it can
be used even when non-anchor carriers provide
unique coverage. 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.
6.2.2.1 5G_Cov_Stay Solutions Based on SPID and STM
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 6-2), and another which discourages it (Solution 2 in Table 6-2).
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 6-5, for the same example as used in
6.2.1.1.
Figure 6-5 – 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 6.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 if the non-anchor carrier provides exclusive

coverage in some areas; that is if the coverage-triggered handover from anchor to
non-anchor is required to maintain service. In this case Solution 2 is recommended.
Solution 2 – Discourage Handover
This solution is similar to Solution 1, except that coverage-triggered handover to non-

anchor carriers is discouraged rather than prevented. This solution is preferable if the
non-anchor carriers provide unique coverage.
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 6-6. 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.
Figure 6-6 – 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, 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:
 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 6-3 and Figure 6-7; building on
the example given for the idle mode solution in 6.2.1.1.
Table 6-3 – Settings for SPID-Based Solution for 5G_Cov_Stay (Discourage Handover)
MO Parameter Value Comment
ReportConfigSearch a1a2SearchThresholdRsrp -115 Assuming previous value
was -118 dBm, raise the value
by 3dB to allow the inner
search zone to begin 3 dB
earlier.
ReportConfigSearch a2OuterSearchThrRsrpOffset -3 Set outer search zone
boundary 3dB below inner
search zone boundary (at the
previous search zone level of -
118 dBm).
UeMeasControl lowPrioMeasThresh 5 Frequencies with a priority less
than this value are searched in
the outer search zone only.
EUtranFreqRelation connectedModeMobilityPrio 4 For non-5G UEs, all LTE
frequencies are searched in
EUtranFreqRelation voicePrio 4 For non-5G UEs, all LTE
UtranFreqRelation connectedModeMobilityPrio 3 For non-5G UEs, all UTRAN
UtranFreqRelation voicePrio 3 For non-5G UEs, all UTRAN
Figure 6-7 – 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 6-8; once again, these search zones are implemented in
anchor cells only.
Figure 6-8 – 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.
6.2.2.2 5G_Cov_Stay Solution Based on QCI and MLSTM
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 6.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 6-9.
Figure 6-9 – 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 (e.g. 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.
6.2.3 Anchor Control Strategy – 5G_Cov_Go
The section presents solutions for the 5G_Cov_Go strategy. The purpose of this
strategy is to encourage 5G UEs to move from a non-anchor carrier to an anchor
carrier in connected mode, using aggressive coverage-triggered handover settings.
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 6.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.
Two solutions are available, one based on SPID and one on QCI, as shown in Table
6-4.
Table 6-4 – Solutions for 5G_Cov_Go
Solution Mechanism for Features Comments
Number Differentiating 5G Used
Subscribers
1 QCI MLSTM This QCI-based solution uses the MLSTM
feature to introduce offsets to the measurement
and handover thresholds for 5G UEs. The offsets
cause UEs to hand over sooner. This is a simple
solution, but it requires the use of QCI as the
differentiation mechanism.
2 SPID STM, This SPID-based solution uses the MCPC
MCPC feature to create two search zones. The inner
search zone is used to push 5G UEs from non-
anchor to anchor carriers. The outer search zone
is used for normal coverage-triggered handovers
for non-5G UEs. This is a more complex
solution, but it does not require QCI.
6.2.3.1 5G_Cov_Go Solution Based on QCI and MLSTM
This section presents a solution for the 5G_Cov_Go strategy, based on QCI and the
feature Multi-Layer Service-Triggered Mobility (MLSTM).
Coverage-triggered inter-frequency handover is normally used to handle poor serving

cell coverage. However, in this solution it is used to proactively push 5G UEs from a
non-anchor frequency to an anchor frequency, even when serving cell coverage is
good. To do this, the feature Multi-Layer Service-Triggered Mobility (MLSTM) is used
to offset the A2 and A5 thresholds for the QCIs corresponding to 5G users. The offsets
cause the inter-frequency measurements and handovers to be triggered earlier. This
solution assumes that dedicated QCI values are assigned for 5G subscribers, as
described in Section 6.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 6-10. 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 6-10 – QCI-Based Solution for 5G_Cov_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 does not provide
continuous coverage.
6.2.3.2 5G_Cov_Go Solution Based on SPID, STM and MCPC
This section presents a solution for the 5G_Cov_Go strategy, based on the features
Subscriber Triggered Mobility (STM) and Mobility Control at Poor Coverage (MCPC). It
uses SPID to differentiate 5G from non-5G subscribers.
This solution is similar to the Solution 2, SPID-based solution for 5G_Cov_Stay

(presented in Section 6.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 6-11. 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 6-11 – SPID-Based Solution for 5G_Cov_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
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_Cov_Go is identical to that of

5G_Cov_Stay; refer to Table 6-3 and Figure 6-7 for details.
6.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 5.6).
Three solutions are available, using different differentiation mechanisms and features,
as shown in Table 6-5.
Table 6-5 – Solutions for 5G_LB_Stay
Solution Mechanism Features Comments
Number for Used
Differentiating
5G
Subscribers
1 UE Capability BIC This feature uses the parameter
lbAllowedForEndcUe in the feature Basic
Intelligent Connectivity to prevent all load
triggered handovers for EN-DC capable UEs.
2 SPID STM This SPID-based solution uses the feature
Subscriber Triggered Mobility to prevent load-
triggered handovers from anchor to non-anchor
carriers, or even between anchor carriers.
3 QCI SSLM This QCI-based solution uses the feature
Service Specific Load Management to prevent
load triggered handovers at the frequency
relation level. Alternatively, the handovers can
be discouraged, but not prevented, by adjusting
A5 thresholds.
6.2.4.1 5G_LB_Stay Solution Based on UE Capability and BIC
This section presents a solution for the 5G_LB_Stay strategy, based on a single
parameter, LoadBalancingFunction.lbAllowedForEndcUe. This parameter is
provided by the feature Basic Intelligent Connectivity (BIC).
By setting lbAllowedForEndcUe = false all load management actions, including

Inter Frequency Load Balancing and IRAT Offload, are prevented for EN-DC capable
UEs which do not have an SN Terminated Split Bearer set up. Those UEs which do
have an SN terminated bearer set up are excluded from all load management actions
anyway, regardless of how this parameter is set (see Section 5.7).
This solution is best when the number of 5G UEs is low compared with the number of
non-5G UEs, so that 5G UEs can be safely ignored for the purposes of load
management, without risking congestion.
6.2.4.2 5G_LB_Stay Solution Based on SPID and STM
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 6-12; building on the example
given for the idle mode solution in 6.2.1.1.
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.
Figure 6-12 – 5G_LB_Stay Solution Based on SPID and STM
6.2.4.3 5G_LB_Stay Solution Based on QCI and SSLM
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
6-13.
Figure 6-13 – 5G_LB_Stay Solution Based on QCI and SSLM
6.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 6.2.
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 is overridden with
the 5G strategy components in Section 6.2.
6.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.
6.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 6-14.
Figure 6-14 – Duplicating SPID Values for 5G Introduction
For further information on this feature refer to the HSS Feature Description EPS
Subscriber Data Handling in ESM.
6.4.2 Configuring SPID in the MME
The MME receives SPID information from the HSS and forwards it to the eNodeB
during connection setup. It also forwards SPID during S1 handover. The MME also
adds or removes SPID for incoming roamers.
6.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.
6.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
6-15.
Figure 6-15 – RATFreqPrio MO
6.5 Configuring QCI for 5G Users

Some of the solutions for anchor carrier control involve using the Quality of Service
Class Identifier (QCI) to differentiate between 5G and non-5G users. There are two
options for assigning QCI values for 5G users:
 Assign QCI in the HSS
 Remap QCI Using ASGH Framework
6.5.1 Assign QCI in the HSS
In this option, the QCI associated with 5G subscribers is specified in the HSS using an
additional ContextId of the current APN configuration.
6.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]
Figure 6-16 and Figure 6-17 present of QCI mapping using ASGH. In this example, 5G
subscribers are assigned SPID values 5 and 20 in the HSS. For these subscribers QCI
9 is remapped to QCI 20 by applying an offset of 11.
Figure 6-16 – 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 6-17 – Defining an Additional QCI Profile
7 Appendix 1 – Mobility Features
7.1 Software Value Packages and Features

A Software Value Package consist of a number of FAJ features that are bundled and
offered together. Table 7-1 provides an overview of the features referred to in this
guideline.
Note: The feature descriptions in CPI aim to describe features holistically, and
therefore sometimes describe functionality which is implemented in other node types.
Table 7-1 – RAN Features and Software Value Packages
Node Value Package Feature name Licensed
Type
eNodeB LTE Base Package Mobility Control at Poor Coverage Yes
(FAJ 801 0400) (FAJ 121 3013)
eNodeB LTE Base Package Subscriber Triggered Mobility Yes
(FAJ 801 0400) (FAJ 121 1788)
eNodeB LTE Base Package ASGH Framework No
(FAJ 801 0400) (FAJ 121 4795)
eNodeB LTE Base Package Flexible Counters No
(FAJ 801 0400) (FAJ 121 4669)
eNodeB Service Based Mobility Multi-Layer Service-Triggered Mobility Yes
(FAJ 801 0433) (FAJ 121 4124)
eNodeB Service Based Mobility Service-Specific Load Management Yes
(FAJ 801 0433) (FAJ 121 3047)
eNodeB Intelligent Connectivity Basic Intelligent Connectivity Yes
(FAJ 801 1013) (FAJ 121 4843)
eNodeB Intelligent Connectivity NR Coverage-Triggered NR Session Yes
(FAJ 801 1013) Continuity
(FAJ 121 4983)
gNodeB NR RAN Base Package LTE-NR Dual Connectivity No
(FAJ 801 4002) (FAJ 121 4908)
gNodeB NR RAN Base Package Uplink-Downlink Decoupling No
(FAJ 801 4002) (FAJ 121 4909)
gNodeB NR RAN Base Package NR Mobility No
(FAJ 801 4002) (FAJ 121 5041)
gNodeB Peak Rate Evolution Value LTE-NR Downlink Aggregation Yes
Package (FAJ 121 4912)
(FAJ 801 4005)
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 7.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.
7.2 eNodeB Features

This section lists features implemented in the eNodeB that are important for 5G
Mobility & Traffic Management.
7.2.1 Basic Intelligent Connectivity (FAJ 121 4843)
This is a licensed feature in the eNodeB in the Value Package Intelligent Connectivity
(FAJ 801 1013).
The Basic Intelligent Connectivity feature introduces the basic support for EN-DC in
the eNodeB used in a non-standalone deployment. The counterpart feature on the
gNodeB side is the feature LTE-NR Dual Connectivity (FAJ 121 4908).
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 and
providing the upper layer indicator for NR services.
Refer to the CPI document Basic Intelligent Connectivity for more information.
7.2.2 NR Coverage-Triggered NR Session Continuity (FAJ 121 4983)
Note: Ericsson does not support NR SA in the current release. This feature is therefore
useful only in conjunction with NR SA deployments from other vendors.
This licensed feature in the Value Package Intelligent Connectivity (FAJ 801 1013)
enables NR Standalone (NR SA) capable UEs in idle mode to reselect from LTE to NR
SA when NR coverage becomes acceptable. Information to enable this reselection is
broadcast to UEs in SIB24. The feature provides the following functionality:
 Introduces the GUtranFreqRelation MO, which contains parameters specific to

the mobility relation between an EUtranCellFDD/TDD and an NR frequency.
 Introduces cell reselection parameters for SIB24 in the EUtranCellFDD/TDD

MOs.
 Updates the MappingInfoSIBs and ChangeNotificationSIBs structures in

EUtranCellFDD/TDD with parameters for SIB24
In the current release this feature does not enable connected mode mobility to NR SA.
7.2.3 Subscriber Triggered Mobility (FAJ 121 1788)
This is a licensed feature in the LTE Base Package (FAJ 801 0400).
This feature provides a framework to control mobility related UE behavior differently for
different UEs. However, it is only used to enhance the functionalities of other features.
It allows reception and storage of Subscriber Profile ID (SPID) from the Core Network.
The following features use the SPID framework to modify their behavior for each UE
depending on the SPID value received for those UE units:
 LTE Cell Reselection Dedicated Priorities
 Release with Redirect to LTE
7.2.4 ASGH Framework (FAJ 121 4795)
This is an unlicensed feature in the LTE Base Package (FAJ 801 0400).
The ASGH framework relies on three separate features:
 An unlicensed feature that puts the framework in place, allowing the configuration
of the detection criteria, QCI remapping and observability
 The licensed ASGH Performance Package (FAJ 121 4796) that enables the
modification of all UE-level parameters, except for prescheduling parameters
 The licensed ASGH-Based Prescheduling (FAJ 121 4797) that enables the
modification of prescheduling parameters
The main utilization of ASGH in the traffic management solution is to map the existing
QCI of some group of subscribers into an operator defined QCI in order to activate
special mobility features like Multi-Layer Service-Triggered Mobility or Service Specific
Load Management.
7.2.5 Mobility Control at Poor Coverage (FAJ 121 3013)
Mobility Control at Poor Coverage (MCPC) is a licensed feature in the LTE Base
Package (FAJ 801 0400).
It builds on the legacy Session Continuity features to provide more control over
mobility when poor coverage is encountered. Refer to the LTE Mobility and Traffic
Management Guideline for information on using this feature in the mobility strategy.
7.2.6 Multi-Layer Service-Triggered Mobility (FAJ 121 4124)
Multi-Layer Service-Triggered Mobility (MLSTM) is a licensed 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 (e.g. Coverage-Triggered
Inter-Frequency Session Continuity). This feature supersedes the Service-Triggered
Mobility feature, and overrides it if both features are activated. Refer to the LTE
Mobility and Traffic Management Guideline for information on using this feature in the
mobility strategy.
7.2.7 Service Specific Load Management (FAJ 121 3047)
Service Specific Load Management is a licensed feature in the Service Based Mobility
Value Package (FAJ 801 0433).
This feature provides control over how certain services (e.g. VoIP) are treated by load
balancing and offload. Refer to the LTE Mobility and Traffic Management Guideline for
information on using this feature in the mobility strategy.
7.2.8 Flexible Counters (FAJ 121 4669)
Flexible Counters is an unlicensed feature in the LTE Base Package (FAJ 801 0400).
The feature Flexible Counters 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.
0 ENDC_NR_CAPABLE
UE ENDC capability is confirmed.
1 ENDC_NR_MATCHED
UE ENDC capability matches LTE cell configuration.
2 ENDC_NR_ACTIVE
UE ENDC has been created and active.
7.3 gNodeB Features

This section lists features implemented in the gNodeB that are important for 5G
7.3.1 LTE-NR Dual Connectivity (FAJ 121 4908)
This is an unlicensed 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 where SN Terminated bearer establishment can be

prevented for specific UEs
 Support of legacy LTE mobility where the SN Terminated bearer is released
 Support of measurement-based SN addition
 Support of LTE RRC re-establishment with SN Terminated Split Bearer
 EN-DC secondary RAT data usage reporting to the core network. This enables
observability of the data volume transmitted using SCG resources. When
configuring 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.
Refer to the CPI document LTE-NR Dual Connectivity for more information.
7.3.2 Uplink-Downlink Decoupling (FAJ 121 4909)
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 4.4.2 and Section 4.4.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, e.g. mid-band
or high-band. Refer to the CPI document RAN Parameter Recommendations.
The feature provides for example improved NR coverage by utilizing the coverage
benefits of the LTE UL on a lower FDD band as described in Section 4.4.1.
Refer to the CPI document LTE-NR Dual Connectivity for more information.
7.3.3 NR Mobility (FAJ 121 5041)
The purpose of the NR Mobility feature is to manage the UE in RRC_CONNECTED

mode.
The feature allows EN-DC configured UEs with SCG resources to perform intra-
frequency Event A3 measurement in RRC_CONNECTED mode. When an Event A3
measurement report is received by the gNodeB, PSCell change is triggered, as
described in Section 5.3.1.
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.
7.3.4 LTE-NR Downlink Aggregation (FAJ 121 4912)
This is a licensed feature in the gNodeB in the Peak Rate Evolution Value Package
(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 and Uplink User Plane
Switching, is provided in Section 4.4.4.
The feature LTE-NR Downlink Aggregation is enabled by setting the

attribute featureState to ACTIVATED in the FeatureState=CXC4012273 MO
instance.
Refer to the CPI document LTE-NR Downlink Aggregation for more information.
7.4 MME Features

This section lists selected MME features implemented that are important for 5G
7.4.1 UE Dual Connectivity Support (FAT 102 3381/2116)
This is a licensed 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.
7.4.2 NR Access Control (FAT 102 3381/2119)
This is a licensed 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 IE in the Handover

Restriction List IE in the Initial Context Setup Request, Handover Request, and
Downlink NAS Transport messages. The NR Restriction 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.
8 Appendix 2 – Mobility Trigger Levels

This section provides formulas for the effective trigger levels of various mobility cases.
It includes only those mobility cases which are new with EN-DC. Legacy LTE mobility
cases are described in the CPI document LTE Mobility and Traffic Management
Guideline.
The formulas use the following notation:
(RAT_Containing_MO_Class)MO_Class.Parameter
For example:
(LTE)ReportConfigB1Gutra.triggerQuantityB1
When using these formulas, note the following:
 The formulas refer to the Ericsson parameter values with their sign as set in the
node. For example, if offsetA3 = -30 (-3dB) then use the value -30 in the
formula. The formula includes the appropriate conversion, so that the results are in
dBm (RSRP) or dB (RSRQ, SINR or RSRP delta).
 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.9.5.
 In general, this section covers only the triggering levels themselves, not the criteria
which determine when a particular trigger applies or time to trigger requirements.
For more details refer to the relevant sections in this document or the feature
descriptions in CPI.
8.1 Measurement-Based Secondary Node Addition

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 (LTE)ReportConfigB1Gutra.triggerQuantityB1 = SS_RSRP then B1 is

entered when:
RSRP_target > (LTE)ReportConfigB1Gutra.b1ThresholdRsrp

+ (LTE)ReportConfigB1Gutra.hysteresisB1/2
Is fulfilled for: (LTE)ReportConfigB1Gutra.timeToTriggerB1
Alternately, if (LTE)ReportConfigB1Gutra.triggerQuantityB1 = SS_RSRQ then

B1 is entered when:
RSRQ_target > (LTE)ReportConfigB1Gutra.b1ThresholdRsrq/10

+ (LTE)ReportConfigB1Gutra.hysteresisB1/2
Is fulfilled for: (LTE)ReportConfigB1Gutra.timeToTriggerB1
Ericsson recommends SS_RSRP as the trigger quantity for Event B1.
Note that in connected mode, the UE is required to perform any configured Layer 3
measurements on LTE (including the above-mentioned B1) when:
RSRP_PCell < (LTE)UeMeasControl.sMeasure
Refer to the CPI document LTE Mobility and Traffic Management Guideline for more
detail.
8.2 NR intra-frequency mobility

When the SN Terminated Split Bearer is setup, intra-frequency measurements are
conducted to find better NR cells. The UE is required to perform measurements when:
SS-RSRP_PSCell < (NR)UeMeasControl.sMeasure
(NR)UeMeasControl.sMeasure applies to all UE-based connected mode Layer 3

measurements on NR. In NR, the default value for sMeasure is ‘empty field’
which means disabled (always measure). The UE may also measure when the SS-
RSRP exceeds sMeasure, but this is not required by the standard.
NR Intra-frequency mobility always uses Event A3. The parameters to control this
event are configured in the gNodeB.
If (NR)ReportConfigA3.triggerQuantityA3 = RSRP then Event A3 is entered

when:
SS-RSRP_target – SS-RSRP_source > (NR)ReportConfigA3.offsetA3/10

+ (NR)ReportConfigA3.hysteresisA3/10
- (NR)NRCellRelation.cellIndividualOffsetNR
Is fulfilled for: (NR)ReportConfigA3.timeToTriggerA3
Alternately, if (NR)ReportConfigA3.triggerQuantityA3 = RSRQ then Event A3

entering condition is satisfied when:
SS-RSRQ_target – SS-RSRQ_source > (NR)ReportConfigA3.offsetA3/10

+ (NR)ReportConfigA3.hysteresisA3/10
- (NR)NRCellRelation.cellIndividualOffsetNR
Is fulfilled for: (NR)ReportConfigA3.timeToTriggerA3
Ericsson recommends RSRP as the trigger quantity for Event A3.
Note: Future software releases will remove the A3 suffix from the hysteresisA3,
offsetA3 and timeToTriggerA3 parameters.
9 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 7.2.8 for more details.
9.1 Key Performance Indicators

Table 9-1 highlights some of the relevant KPIs for NR NSA Mobility. Further details on
formulas and counters are provided in the CPI document Key Performance Indicators.
Table 9-1 – RAN Features and Software Packages
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-frequency Handover Success Rate
9.2 Performance Indicators

In addition to the KPIs listed in Section 9.1, the following Performance Indicators (PIs)
are useful for assessing NR NSA mobility.
9.2.1 B1 Report Rate
The following formula shows the report rate for B1 measurements: the proportion of
Event B1 reports per Event B1 configuration.
B1 Report Rate =
100 * (EUtranCellFDD/TDD.pmB1MeasRepEndcConfig /
EUtranCellFDD/TDD.pmMeasConfigB1Endc)
9.2.2 EN-DC Setup Random Access Failure Rate
The following formula shows the failure rate of random access attempts in the NR cell.
EN-DC Setup Random Access Failure Rate =

100 * (EUtranCellFDD/TDD.pmEndcSetupFailNrRa /
EUtranCellFDD/TDD.pmEndcSetupUeAtt)

5G Mobility and Traffic Management Guideline

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

5G Mobility and Traffic Management Guideline

Uploaded by

Copyright:

Available Formats

5G Mobility and Traffic Management

Document Number Revision

4 Mobility Overview ............................................................................ 6

5 Mobility and Connectivity Procedures ......................................... 28

6 LTE Anchor Carrier Management ................................................. 53

7 Appendix 1 – Mobility Features .................................................... 79

8 Appendix 2 – Mobility Trigger Levels ........................................... 85

9 Appendix 3 – Mobility KPIs ........................................................... 88

The focus is on Radio Access Network functionality. However, core network

4.1 5G Connectivity Options

 The core network used

 The Master Radio Access Technology (RAT)

 The Secondary RAT

The current Ericsson release supports two of the six options:

 Option 1: This is legacy LTE.

In addition, future Ericsson releases will support Option 2, NR standalone. These

Figure 4-1 – 5G Connectivity Options

4.2 Radio Bearer Types

 Signaling Radio Bearer (SRB)

 Data Radio Bearer (DRB)

DRBs are described by two characteristics:

- Master Node (MN) or

- Secondary Node (SN)

- Master Cell Group (MCG) or

- Secondary Cell Group (SCG)

- Split (both MCG and SCG provide resources)

- MN Terminated MCG DRB

- SN Terminated MCG DRB

- SN Terminated Split DRB

Figure 4-2 - Bearer Types in an EN-DC capable Network

Which DRBs a UE can use depends on its capability:

4.3 Radio Bearer Transitions

Figure 4-3 - Bearer Type Transitions for EN-DC

Notes for Figure 4-3:

SN addition involves reconfiguring the MN terminated MCG DRB into an SN

SCG addition is triggered by reception of a B1 measurement. The B1 measurement is

4.4 Split Bearer User Plane Functions

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)

Figure 4-4 - SN Terminated Split Bearer Resources

 Uplink / Downlink Decoupling

 Downlink User Plane Switching

 Uplink User Plane Switching

 Downlink User Plane Aggregation

4.4.1 Uplink-Downlink Decoupling

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

4.4.2 Downlink User Plane Switching

Downlink User Plane Switching is illustrated in Figure 4-6.

Figure 4-6 – Downlink User Plane Switching

Notes for Figure 4-6:

4 When the GNBCUUPFunction.endcDlNrRetProhibTimer expires, and if the

4.4.3 Uplink User Plane Switching

Uplink User Plane Switching is illustrated in Figure 4-7.

Figure 4-7 – Uplink User Plane Switching

Notes for Figure 4-7:

4.4.4 Downlink User Plane Aggregation

Notes for Figure 4-8:

4 Downlink aggregation is stopped and returned to downlink using only SCG

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

4.4.5 Flow Control

4.5 Downlink Carrier Aggregation

 MN Terminated MCG Bearer

 SN Terminated Split Bearer