3GPP TS 38.300
3GPP TS 38.300
3GPP TS 38.300
0 (2020-073)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Radio Access Network;
NR; NR and NG-RAN Overall Description;
Stage 2
(Release 16)
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this
Specification.
Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 16 2 3GPP TS 38.300 V16.21.0 (2020-073)
3GPP
Postal address
Internet
http://www.3gpp.org
Copyright Notification
© 2020, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.
UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association
3GPP
Release 16 3 3GPP TS 38.300 V16.21.0 (2020-073)
Contents
Foreword..........................................................................................................................................................9
1 Scope....................................................................................................................................................10
2 References............................................................................................................................................10
3 Abbreviations and Definitions..............................................................................................................11
3.1 Abbreviations.....................................................................................................................................................11
3.2 Definitions.........................................................................................................................................................14
4 Overall Architecture and Functional Split............................................................................................15
4.1 Overall Architecture..........................................................................................................................................15
4.2 Functional Split..................................................................................................................................................16
4.3 Network Interfaces............................................................................................................................................18
4.3.1 NG Interface.................................................................................................................................................18
4.3.1.1 NG User Plane........................................................................................................................................18
4.3.1.2 NG Control Plane...................................................................................................................................19
4.3.2 Xn Interface..................................................................................................................................................19
4.3.2.1 Xn User Plane.........................................................................................................................................19
4.3.2.2 Xn Control Plane....................................................................................................................................20
4.4 Radio Protocol Architecture..............................................................................................................................21
4.4.1 User Plane....................................................................................................................................................21
4.4.2 Control Plane................................................................................................................................................21
4.5 Multi-Radio Dual Connectivity.........................................................................................................................21
4.6 Radio Access Network Sharing.........................................................................................................................22
4.7 Integrated Access and Backhaul........................................................................................................................22
4.7.1 Architecture..................................................................................................................................................22
4.7.2 Protocol Stacks.............................................................................................................................................23
4.7.3 User-plane Aspects......................................................................................................................................25
4.7.3.1 Backhaul transport..................................................................................................................................25
4.7.3.2 Flow and Congestion Control................................................................................................................25
4.7.3.3 Uplink Scheduling Latency....................................................................................................................25
4.7.4 Signalling procedures...................................................................................................................................26
4.7.4.1 IAB-node Integration.............................................................................................................................26
4.7.4.2 IAB-node Migration...............................................................................................................................26
4.7.4.3 Topological Redundancy........................................................................................................................26
4.7.4.4 Backhaul RLF Recovery........................................................................................................................26
4.8 Non-Public Networks........................................................................................................................................27
5 Physical Layer......................................................................................................................................27
5.1 Waveform, numerology and frame structure.....................................................................................................27
5.2 Downlink...........................................................................................................................................................28
5.2.1 Downlink transmission scheme...................................................................................................................28
5.2.2 Physical-layer processing for physical downlink shared channel................................................................28
5.2.3 Physical downlink control channels.............................................................................................................29
5.2.4 Synchronization signal and PBCH block.....................................................................................................29
5.2.5 Physical layer procedures.............................................................................................................................30
5.2.5.1 Link adaptation.......................................................................................................................................30
5.2.5.2 Power Control........................................................................................................................................30
5.2.5.3 Cell search..............................................................................................................................................30
5.2.5.4 HARQ.....................................................................................................................................................31
5.2.5.5 Reception of SIB1..................................................................................................................................31
5.2.6 Downlink Reference Signals and Measurements for Positioning................................................................31
5.3 Uplink................................................................................................................................................................31
5.3.1 Uplink transmission scheme........................................................................................................................31
5.3.2 Physical-layer processing for physical uplink shared channel.....................................................................32
5.3.3 Physical uplink control channel...................................................................................................................32
5.3.4 Random access.............................................................................................................................................33
5.3.5 Physical layer procedures.............................................................................................................................33
3GPP
Release 16 4 3GPP TS 38.300 V16.21.0 (2020-073)
3GPP
Release 16 5 3GPP TS 38.300 V16.21.0 (2020-073)
8 NG Identities........................................................................................................................................55
8.1 UE Identities......................................................................................................................................................55
8.2 Network Identities.............................................................................................................................................56
8.3 User Data Transport on the CN-RAN Interface................................................................................................56
8.4 NR sidelink communication and V2X sidelink communication related identities............................................56
9 Mobility and State Transitions..............................................................................................................57
9.1 Overview...........................................................................................................................................................57
9.2 Intra-NR.............................................................................................................................................................58
9.2.1 Mobility in RRC_IDLE...............................................................................................................................58
9.2.1.1 Cell Selection.........................................................................................................................................58
9.2.1.2 Cell Reselection......................................................................................................................................58
9.2.1.3 State Transitions.....................................................................................................................................59
9.2.2 Mobility in RRC_INACTIVE......................................................................................................................60
9.2.2.1 Overview................................................................................................................................................60
9.2.2.2 Cell Reselection......................................................................................................................................61
9.2.2.3 RAN-Based Notification Area...............................................................................................................61
9.2.2.4 State Transitions.....................................................................................................................................62
9.2.2.4.1 UE triggered transition from RRC_INACTIVE to RRC_CONNECTED.......................................62
9.2.2.4.2 Network triggered transition from RRC_INACTIVE to RRC_CONNECTED...............................64
9.2.2.5 RNA update............................................................................................................................................64
9.2.3 Mobility in RRC_CONNECTED................................................................................................................67
9.2.3.1 Overview................................................................................................................................................67
9.2.3.2 Handover................................................................................................................................................68
9.2.3.2.1 C-Plane Handling.............................................................................................................................68
9.2.3.2.2 U-Plane Handling.............................................................................................................................70
9.2.3.2.3 Data Forwarding...............................................................................................................................72
9.2.3.3 Re-establishment procedure...................................................................................................................73
9.2.3.4 Conditional Handover............................................................................................................................74
9.2.3.4.1 General..............................................................................................................................................74
9.2.3.4.2 C-plane handling...............................................................................................................................74
9.2.4 Measurements..............................................................................................................................................76
9.2.5 Paging..........................................................................................................................................................78
9.2.6 Random Access Procedure...........................................................................................................................79
9.2.7 Radio Link Failure.......................................................................................................................................80
9.2.8 Beam failure detection and recovery...........................................................................................................81
9.2.9 Timing Advance...........................................................................................................................................82
9.3 Inter RAT...........................................................................................................................................................82
9.3.1 NR-E-UTRA mobility: Intra 5GC...............................................................................................................82
9.3.1.1 Cell Reselection......................................................................................................................................82
9.3.1.2 Handover................................................................................................................................................82
9.3.1.3 Measurements.........................................................................................................................................83
9.3.2 NR-E-UTRA mobility: From 5GC to EPC..................................................................................................83
9.3.2.1 Cell Reselection......................................................................................................................................83
9.3.2.2 Handover and redirection.......................................................................................................................83
9.3.2.3 Measurements.........................................................................................................................................83
9.3.2.4 Data Forwarding for the Control Plane..................................................................................................84
9.3.2.5 Data Forwarding for the User Plane.......................................................................................................84
9.3.3 NR-E-UTRA mobility: From EPC to 5GC..................................................................................................84
9.3.3.1 Data Forwarding for the Control Plane..................................................................................................84
9.3.3.2 Data Forwarding for the User Plane.......................................................................................................85
9.3.4 NR-UTRA mobility.....................................................................................................................................86
9.3.4.1 Handover with SRVCC operation..........................................................................................................86
9.3.4.2 Measurements.........................................................................................................................................86
9.4 Roaming and Access Restrictions.....................................................................................................................86
10 Scheduling............................................................................................................................................87
10.1 Basic Scheduler Operation................................................................................................................................87
10.2 Downlink Scheduling........................................................................................................................................87
10.3 Uplink Scheduling.............................................................................................................................................88
10.4 Measurements to Support Scheduler Operation................................................................................................89
10.5 Rate Control.......................................................................................................................................................89
3GPP
Release 16 6 3GPP TS 38.300 V16.21.0 (2020-073)
10.5.1 Downlink......................................................................................................................................................89
10.5.2 Uplink..........................................................................................................................................................89
10.6 Activation/Deactivation Mechanism.................................................................................................................90
10.7 E-UTRA-NR Cell Resource Coordination........................................................................................................90
10.8 Cross Carrier Scheduling...................................................................................................................................90
11 UE Power Saving.................................................................................................................................91
12 QoS.......................................................................................................................................................92
12.1 Overview...........................................................................................................................................................92
12.2 Explicit Congestion Notification.......................................................................................................................94
13 Security................................................................................................................................................94
13.1 Overview and Principles....................................................................................................................................94
13.2 Security Termination Points..............................................................................................................................96
13.3 State Transitions and Mobility...........................................................................................................................97
14 UE Capabilities.....................................................................................................................................97
15 Self-Configuration and Self-Optimisation............................................................................................97
15.1 Definitions.........................................................................................................................................................97
15.2 Void...................................................................................................................................................................98
15.3 Self-configuration..............................................................................................................................................98
15.3.1 Dynamic configuration of the NG-C interface............................................................................................98
15.3.1.1 Prerequisites...........................................................................................................................................98
15.3.1.2 SCTP initialization.................................................................................................................................98
15.3.1.3 Application layer initialization...............................................................................................................98
15.3.2 Dynamic Configuration of the Xn interface................................................................................................98
15.3.2.1 Prerequisites...........................................................................................................................................98
15.3.2.2 SCTP initialization.................................................................................................................................98
15.3.2.3 Application layer initialization...............................................................................................................98
15.3.3 Automatic Neighbour Cell Relation Function.............................................................................................99
15.3.3.1 General...................................................................................................................................................99
15.3.3.2 Intra-system Automatic Neighbour Cell Relation Function.................................................................100
15.3.3.3 Void......................................................................................................................................................100
15.3.3.4 Void......................................................................................................................................................100
15.3.3.5 Inter-system Automatic Neighbour Cell Relation Function.................................................................100
15.3.4 Xn-C TNL address discovery....................................................................................................................101
15.4 Support for Energy Saving..............................................................................................................................102
15.4.1 General.......................................................................................................................................................102
15.4.2 Solution description...................................................................................................................................102
15.4.3 O&M requirements....................................................................................................................................102
16 Verticals Support................................................................................................................................103
16.1 URLLC............................................................................................................................................................103
16.1.1 Overview....................................................................................................................................................103
16.1.2 LCP Restrictions........................................................................................................................................103
16.1.3 Packet Duplication.....................................................................................................................................103
16.1.4 CQI and MCS............................................................................................................................................104
16.1.5 DCI formats...............................................................................................................................................104
16.2 IMS Voice........................................................................................................................................................104
16.2.0 Support for IMS voice...............................................................................................................................104
16.2.1 Support for MMTEL IMS voice and video enhancements........................................................................105
16.2.1.1 RAN-assisted codec adaptation............................................................................................................105
16.2.1.2 MMTEL voice quality/coverage enhancements...................................................................................105
16.3 Network Slicing...............................................................................................................................................105
16.3.1 General Principles and Requirements........................................................................................................105
16.3.2 AMF and NW Slice Selection....................................................................................................................107
16.3.2.1 CN-RAN interaction and internal RAN aspects..................................................................................107
16.3.2.2 Radio Interface Aspects.......................................................................................................................107
16.3.3 Resource Isolation and Management.........................................................................................................107
16.3.4 Signalling Aspects......................................................................................................................................108
16.3.4.1 General.................................................................................................................................................108
16.3.4.2 AMF and NW Slice Selection..............................................................................................................108
3GPP
Release 16 7 3GPP TS 38.300 V16.21.0 (2020-073)
3GPP
Release 16 8 3GPP TS 38.300 V16.21.0 (2020-073)
Annex D (informative): SPID ranges and mapping of SPID values to cell reselection and inter-
RAT/inter frequency handover priorities.................................................128
Annex E: NG-RAN Architecture for Radio Access Network Sharing with multiple cell ID broadcast
(informative)...............................................................................................129
3GPP
Release 16 9 3GPP TS 38.300 V16.21.0 (2020-073)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
3GPP
Release 16 10 3GPP TS 38.300 V16.21.0 (2020-073)
1 Scope
The present document provides an overview and overall description of the NG-RAN and focuses on the radio interface
protocol architecture of NR connected to 5GC (E-UTRA connected to 5GC is covered in the 36 series). Details of the
radio interface protocols are specified in companion specifications of the 38 series.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[2] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".
[3] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[6] 3GPP TS 38.321: "NR; Medium Access Control (MAC) protocol specification".
[7] 3GPP TS 38.322: "NR; Radio Link Control (RLC) protocol specification".
[8] 3GPP TS 38.323: "NR; Packet Data Convergence Protocol (PDCP) specification".
[9] 3GPP TS 37.324: " E-UTRA and NR; Service Data Protocol (SDAP) specification".
[10] 3GPP TS 38.304: "NR; User Equipment (UE) procedures in Idle mode and RRC Inactive state".
[11] 3GPP TS 38.306: "NR; User Equipment (UE) radio access capabilities".
[12] 3GPP TS 38.331: "NR; Radio Resource Control (RRC); Protocol specification".
[13] 3GPP TS 38.133: "NR; Requirements for support of radio resource management".
[14] 3GPP TS 22.168: "Earthquake and Tsunami Warning System (ETWS) requirements; Stage 1".
[18] 3GPP TS 38.101-1: "NR; User Equipment (UE) radio transmission and reception; Part 1: Range 1
Standalone".
[19] 3GPP TS 22.261: "Service requirements for next generation new services and markets".
[20] 3GPP TS 38.202: "NR; Physical layer services provided by the physical layer"
3GPP
Release 16 11 3GPP TS 38.300 V16.21.0 (2020-073)
[24] 3GPP TS 26.114: "Technical Specification Group Services and System Aspects; IP Multimedia
Subsystem (IMS); Multimedia Telephony; Media handling and interaction".
[25] Void.
[27] IETF RFC 3168 (09/2001): "The Addition of Explicit Congestion Notification (ECN) to IP".
[28] 3GPP TS 24.501: "NR; Non-Access-Stratum (NAS) protocol for 5G System (5GS)".
[29] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC); Protocol specification".
[34] 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2".
[35] 3GPP TS 38.101-2: "User Equipment (UE) radio transmission and reception; Part 2: Range 2
Standalone".
[36] 3GPP TS 38.101-3: "User Equipment (UE) radio transmission and reception; Part 3: Range 1 and
Range 2 Interworking operation with other radios".
[37] 3GPP TS 37.213: "Physical layer procedures for shared spectrum channel access".
[39] 3GPP TS 22.104 "Service requirements for cyber-physical control applications in vertical
domains".
[40] 3GPP TS 23.287: "Architecture enhancements for 5G System (5GS) to support Vehicle-to-
Everything (V2X) services".
[41] 3GPP TS 23.285: "Technical Specification Group Services and System Aspects; Architecture
enhancements for V2X services".
[42] 3GPP TS 38.305: "NG Radio Access Network (NG-RAN); Stage 2 functional specification of
User Equipment (UE) positioning in NG-RAN".
3.1 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1], in TS 36.300 [2] and the following
apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if
any, in TR 21.905 [1] and TS 36.300 [2].
3GPP
Release 16 12 3GPP TS 38.300 V16.21.0 (2020-073)
3GPP
Release 16 13 3GPP TS 38.300 V16.21.0 (2020-073)
3GPP
Release 16 14 3GPP TS 38.300 V16.21.0 (2020-073)
3.2 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1], in TS 36.300 [2] and the
following apply. A term defined in the present document takes precedence over the definition of the same term, if any,
in TR 21.905 [1] and TS 36.300 [2].
CAG Cell: a cell broadcasting at least one Closed Access Group identity.
CAG Member Cell: for a UE, a cell broadcasting the identity of the selected PLMN, registered PLMN or equivalent
PLMN, and for that PLMN, a CAG identifier belonging to the Allowed CAG list of the UE for that PLMN.
CAG-only cell: a cell that is only available for normal service for CAG UEs.
Child node: IAB-node-DU’s and IAB-donor-DU’s next hop neighbour node; the child node is also an IAB-node.
Conditional Handover (CHO): a handover procedure that is executed only when the configured execution condition(s)
are met.
CORESET#0: the control resource set for at least SIB1 scheduling, can be configured either via MIB or via dedicated
RRC signalling.
DAPS Handover: a handover procedure that maintains the source gNB connection after reception of RRC message for
handover and until releasing the source cell after successful random access to the target gNB.
Early Data Forwarding: data forwarding that is initiated before the UE executes the handover.
gNB: node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG
interface to the 5GC.
IAB-donor: gNB that provides network access to UEs via a network of backhaul and access links.
IAB-DU: gNB-DU functionality supported by the IAB-node to terminate the NR access interface to UEs and next-hop
IAB-nodes, and to terminate the F1 protocol to the gNB-CU functionality, as defined in TS 38.401 [4], on the IAB-
donor.
IAB-MT: IAB-node function that terminates the Uu interface to the parent node using the procedures and behaviours
specified for UEs unless stated otherwise. IAB-MT function used in 38-series of 3GPP Specifications corresponds to
IAB-UE function defined in TS 23.501 [3].
IAB-node: RAN node that supports NR access links to UEs and NR backhaul links to parent nodes and child nodes.
The IAB-node does not support backhauling via LTE.
Intra-system Handover: Handover that does not involve a CN change (EPC or 5GC).
Late Data Forwarding: data forwarding that is initiated after the source NG-RAN node knows that the UE has
successfully accessed a target NG-RAN node.
3GPP
Release 16 15 3GPP TS 38.300 V16.21.0 (2020-073)
MSG1: preamble transmission of the random access procedure for 4-step random access (RA) type.
MSGA: preamble and payload transmissions of the random access procedure for 2-step RA type.
MSGB: response to MSGA in the 2-step random access procedure. MSGB may consist of response(s) for contention
resolution, fallback indication(s), and backoff indication.
Multi-hop backhauling: Using a chain of NR backhaul links between an IAB-node and an IAB-donor-gNB.
ng-eNB: node providing E-UTRA user plane and control plane protocol terminations towards the UE, and connected
via the NG interface to the 5GC.
NR backhaul link: NR link used for backhauling between an IAB-node and an IAB-donor-gNB, and between IAB-
nodes in case of a multi-hop backhauling.
NR sidelink communication: AS functionality enabling at least V2X communication as defined in TS 23.287 [40],
between two or more nearby UEs, using NR technology but not traversing any network node.
Numerology: corresponds to one subcarrier spacing in the frequency domain. By scaling a reference subcarrier spacing
by an integer N, different numerologies can be defined.
Parent node: IAB-node-MT’s next hop neighbour node; the parent node can be IAB-node or IAB-donor-DU
SNPN-only cell: a cell that is only available for normal service for SNPN subscribers.
SNPN Identity: the identity of Stand-alone NPN defined by the pair (PLMN ID, NID).
V2X sidelink communication: AS functionality enabling V2X communication as defined in TS 23.285 [41], between
nearby UEs, using E-UTRA technology but not traversing any network node.
- a gNB, providing NR user plane and control plane protocol terminations towards the UE; or
- an ng-eNB, providing E-UTRA user plane and control plane protocol terminations towards the UE.
The gNBs and ng-eNBs are interconnected with each other by means of the Xn interface. The gNBs and ng-eNBs are
also connected by means of the NG interfaces to the 5GC, more specifically to the AMF (Access and Mobility
Management Function) by means of the NG-C interface and to the UPF (User Plane Function) by means of the NG-U
interface (see TS 23.501 [3]).
NOTE: The architecture and the F1 interface for a functional split are defined in TS 38.401 [4].
3GPP
Release 16 16 3GPP TS 38.300 V16.21.0 (2020-073)
AMF/UPF AMF/UPF
5GC
NG
NG
NG
NG
NG
NG
NG
NG
Xn NG-RAN
gNB gNB
Xn
Xn
Xn
ng-eNB ng-eNB
- Functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection
Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling);
- Selection of an AMF at UE attachment when no routing to an AMF can be determined from the information
provided by the UE;
- Scheduling and transmission of system broadcast information (originated from the AMF or OAM);
- Session Management;
- Dual Connectivity;
3GPP
Release 16 17 3GPP TS 38.300 V16.21.0 (2020-073)
- Maintain security and radio configuration for User Plane CIoT 5GS Optimisation, as defined in TS 23.501 [3]
(ng-eNB only).
The AMF hosts the following main functions (see TS 23.501 [3]):
- AS Security control;
- Access Authentication;
- SMF selection.
The UPF hosts the following main functions (see TS 23.501 [3]):
- QoS handling for user plane, e.g. packet filtering, gating, UL/DL rate enforcement;
The Session Management function (SMF) hosts the following main functions (see TS 23.501 [3]):
- Session Management;
3GPP
Release 16 18 3GPP TS 38.300 V16.21.0 (2020-073)
This is summarized on the figure below where yellow boxes depict the logical nodes and white boxes depict the main
functions.
Dynamic Resource
Allocation (Scheduler) PDU Handling
internet
NG-RAN 5GC
GTP-U
UDP
IP
Physical Layer
NG-U provides non-guaranteed delivery of user plane PDUs between the NG-RAN node and the UPF.
3GPP
Release 16 19 3GPP TS 38.300 V16.21.0 (2020-073)
NG-AP
SCTP
IP
Physical Layer
- NG interface management;
- UE context management;
- UE mobility management;
- Paging;
- Configuration Transfer;
4.3.2 Xn Interface
3GPP
Release 16 20 3GPP TS 38.300 V16.21.0 (2020-073)
GTP-U
UDP
IP
Physical Layer
Xn-U provides non-guaranteed delivery of user plane PDUs and supports the following functions:
- Data forwarding;
- Flow control.
Xn-AP
SCTP
IP
Physical Layer
- Xn interface management;
- Dual connectivity.
3GPP
Release 16 21 3GPP TS 38.300 V16.21.0 (2020-073)
UE gNB
SDAP SDAP
PDCP PDCP
RLC RLC
MAC MAC
PHY PHY
- PDCP, RLC and MAC sublayers (terminated in gNB on the network side) perform the functions listed in clause
6;
- RRC (terminated in gNB on the network side) performs the functions listed in clause 7;
- NAS control protocol (terminated in AMF on the network side) performs the functions listed in TS 23.501 [3]),
for instance: authentication, mobility management, security control…
UE gNB AMF
NAS NAS
RRC RRC
PDCP PDCP
RLC RLC
MAC MAC
PHY PHY
3GPP
Release 16 22 3GPP TS 38.300 V16.21.0 (2020-073)
If NR access is shared, system information broadcast in a shared cell indicates a TAC and a Cell Identity for each subset
of PLMNs, PNI-NPNs and SNPNs (up to 12). NR access provides only one TAC and one Cell Identity per cell per
PLMN. SNPN or PNI-NPN. In this version of the specification, a Cell Identity can only belong to one network type
among PLMN, PNI-NPN or SNPN as defined in TS 23.501 [3].
Each Cell Identity associated with a subset of PLMNs, SNPNs or PNI-NPNs identifies its serving NG-RAN node.
The IAB-node supports gNB-DU functionality, as defined in TS 38.401 [4], to terminate the NR access interface to UEs
and next-hop IAB-nodes, and to terminate the F1 protocol to the gNB-CU functionality, as defined in TS 38.401 [4], on
the IAB-donor. The gNB-DU functionality on the IAB-node DU is also referred to as IAB-DU.
In addition to the gNB-DU functionality, the IAB-node also supports a subset of the UE functionality referred to as
IAB-MT, which includes, e.g., physical layer, layer-2, RRC and NAS functionality to connect to the gNB-DU of another
IAB-node or the IAB-donor, to connect to the gNB-CU on the IAB-donor, and to the core network.
The IAB-node can access the network using either SA-mode or EN-DC. In EN-DC, the IAB-node also connects via E-
UTRA to a MeNB, and the IAB-donor terminates X2-C as SgNB (TS 37.340 [21]).
S1
S1
Xn X2 X2-C
gNB IAB-donor eNB MeNB IAB-donor
(gNB) (SgNB)
NR Uu
NR Uu
F1
F1
F1
F1
IAB-node IAB-node
NR Uu
NR Uu
a) b)
IAB-node IAB-node
Figure 4.7.1-1: IAB architecture; a) IAB-node using SA mode with NGC; b) IAB-node using EN-DC
All IAB-nodes that are connected to an IAB-donor via one or multiple hops form a directed acyclic graph (DAG)
topology with the IAB-donor at its root (Fig. 4.7.1-2). In this DAG topology, the neighbour node on the IAB-DU’s
interface is referred to as child node and the neighbour node on the IAB-MT’s interface is referred to as parent node.
The direction toward the child node is further referred to as downstream while the direction toward the parent node is
3GPP
Release 16 23 3GPP TS 38.300 V16.21.0 (2020-073)
referred to as upstream. The IAB-donor performs centralized resource-, topology- and route management for the IAB
topology.
Parent
IAB-DU IAB-DU nodes
NR Uu
upstream
IAB-MT
IAB-node
IAB-DU
downstream
NR Uu
F1-U and F1-C use an IP transport layer between IAB-DU and IAB-donor gNB-CU as defined in TS 38.470 [32]. F1-U
and F1-C need to be security-protected as described in TS 33.501 [5] (the security layer is not shown in the Figures
4.7.2-1/2).
On the wireless backhaul, the IP layer is carried over the backhaul adaptation protocol (BAP) sublayer, which enables
routing over multiple hops. The IP layer can is also be used for some non-F1 traffic, such as OAM traffic [4]signalling
traffic for the establishment and management of SCTP associations and the F1-supporting security layer.
On each backhaul link, the BAP PDUs are carried by BH RLC channels. Multiple BH RLC channels can be configured
on each BH link to allow traffic prioritization and QoS enforcement. The BH-RLC-channel mapping for BAP PDUs is
performed by the BAP entitiesy on each IAB-node and the IAB-donor-DU.
Protocol stacks for an IAB-donor with split gNB architecture are specified in TS 38.401 [4].
3GPP
Release 16 24 3GPP TS 38.300 V16.21.0 (2020-073)
The IAB-MT further establishes SRBs (carrying RRC and NAS) with the IAB-donor-CU. For IAB-nodes operating in
ENDC, the IAB-MT also establishes one or more and potentially also DRBs (e.g. carrying OAM traffic) with the IAB-
donor-CU, which can be used, e.g., to carry OAM traffic. For SA mode, the establishment of DRBs is optional. These
SRBs and DRBs are transported between the IAB-MT and its parent node over Uu access channel(s). The protocol
stacks for the SRB is shown in Fig. 4.7.2-3.
3GPP
Release 16 25 3GPP TS 38.300 V16.21.0 (2020-073)
IAB-MT IAB-DU CU
NAS NAS
RRC RRC
PDCP PDCP
RLC RLC
MAC MAC
PHY PHY
NR Uu
Figure 4.7.2-3: Protocol stack for the support of IAB-MT’s RRC and NAS connections
On the BAP sublayer, packets are routed based on the BAP routing ID, which is carried in the BAP header. The BAP
header is added to the packet when it arrives from upper layers, and it is stripped off when it has reached its destination
node. The selection of the packet’s BAP routing ID is configured by the IAB-donor-CU. The BAP routing ID consists
of BAP address and BAP path ID, where the BAP address indicates the destination node of the packet on the BAP
sublayer, and the BAP path ID indicates the routing path the packet should follow to this destination. For the purpose of
routing, each IAB-node and IAB-donor-DU is further configured with a designated BAP address.
On each hop of the packet’s path, the IAB-node inspects the packet's BAP address in the BAP routing ID carried in the
packet routing header to determine if the packet has reached its destination, i.e., matches the IAB-node’s BAP address.
In case the packet has not reached the destination, the IAB-node determines the next hop backhaul link, referred to as
egress link, based on the BAP routing ID carried in the packet header and a routing configuration it received from the
IAB-donor-CU.
For each packet, tThe IAB-node also further determines selects the BH RLC channel on the designated egress link. For
packets arriving from upper layers the designatedselection of the BH RLC channel is configured by the IAB-donor-CU,
and it is based on upper layer traffic specifiers. Since each BH RLC channel is configured with a QoS information code
point or priority level, BH-RLC-channel selection facilitates traffic-specific prioritization and QoS enforcement on the
BH. For F1-U traffic, it is possible to map each GTP-U tunnel to a dedicated BH RLC channel or to aggregate multiple
GTP-U tunnels into one common BH RLC channel. For other than F1-U traffic, it is possible to map UE-associated
F1AP messages, non-UE-associated F1AP messages and non-F1 traffic onto the same or separate BH RLC channels.
When packets are routed from one BH link to another, the BH RLC channel on the egress BH link is determined based
on the mapping configuration between ingress BH RLC channels and egress BH RLC channels provided by the IAB-
donor-CU.
- In upstream direction, UL scheduling on MAC layer can support flow control on each hop;
- In downstream direction, the NR user plane protocol (TS 38.425 [33]) supports flow and congestion control
between the IAB-node and the IAB-donor-CU for UE bearers that terminate at this IAB-node. Further, flow
control is supported on BAP sublayer, where the IAB-node can send feedback information on the available
3GPP
Release 16 26 3GPP TS 38.300 V16.21.0 (2020-073)
buffer size for an ingress BH RLC channel or BAP- routing IDsublayer destination to its parent node. The
feedback can be sent proactively, e.g., when the buffer load exceeds a certain threshold, or based on polling by
the parent node.
The IAB-node can reduce UL scheduling latency through pre-emptive signalling of BSR to its parent node. The IAB-
node can send the Ppre-emptive BSR based on UL grants it has provided to child nodes and/or UEs, or based on BSRs
it has received from child nodes or UEs (Figure 4.7.3-3). The Ppre-emptive BSR conveys the data expected rather than
the data buffered.
Child Parent
IAB-node
Node Node
Regular BSR
a) UL Grant
Data
Regular BSR
Regular BSR
UL Grant
b) Pre-emptive BSR
Data
Regular BSR
Pre-emptive BSR
UL Grant
c) Data
For IAB-nodes operating in SA-mode, NR DC is used to enable route redundancy in the BH by allowing the IAB-MT
to have concurrent BH RLC links with two parent nodes. The parent nodes have to be connected to the same IAB-
donor- CU-CP, which controls the establishment and release of redundant routes via these two parent nodes. The parent
nodes' gNB-DU functionality together with the IAB-donor- CU obtains the roles of the IAB-MT’s master node or and
secondary node. The NR DC framework (e.g. MCG/SCG-related procedures) is used to configure the dual radio links
with the parent nodes (TS 37.340 [21]).
3GPP
Release 16 27 3GPP TS 38.300 V16.21.0 (2020-073)
The procedure for establishment of topological redundancy for IAB-nodes operating in SA-mode is captured in TS
38.401 [4].
IAB-nodes operating in EN-DC can exchange F1-C traffic with the IAB-donor via the MeNB. The F1-C message is are
carried over LTE RRC using SRB2 between IAB-node and MeNB and via X2AP between MeNB and IAB-donor.
The procedure for establishment of redundant transport of F1-C for IAB-nodes using EN-DC is captured in TS 38.401
[4].
- a Stand-alone Non-Public Network (SNPN) when not relying on network functions provided by a PLMN; or
- a Public Network Integrated (PNI) NPN when relying on the support of a PLMN.
5 Physical Layer
Transform Sub-carrier
IFFT CP Insertion
Precoding* Mapping
Figure 5.1-1: Transmitter block diagram for CP-OFDM with optional DFT-spreading
The numerology is based on exponentially scalable sub-carrier spacing f = 2µ × 15 kHz with µ={0,1,3,4} for PSS, SSS
and PBCH and µ={0,1,2,3} for other channels. Normal CP is supported for all sub-carrier spacings, Extended CP is
supported for µ=2. 12 consecutive sub-carriers form a Physical Resource Block (PRB). Up to 275 PRBs are supported
on a carrier.
3GPP
Release 16 28 3GPP TS 38.300 V16.21.0 (2020-073)
f 2 15 [kHz] Cyclic prefix Supported for data Supported for synch
0 15 Normal Yes Yes
1 30 Normal Yes Yes
2 60 Normal, Extended Yes No
3 120 Normal Yes Yes
4 240 Normal No Yes
The UE may be configured with one or more bandwidth parts on a given component carrier, of which only one can be
active at a time, as described in clauses 7.8 and 6.10 respectively. The active bandwidth part defines the UE's operating
bandwidth within the cell's operating bandwidth. For initial access, and until the UE's configuration in a cell is received,
initial bandwidth part detected from system information is used.
Downlink and uplink transmissions are organized into frames with 10 ms duration, consisting of ten 1 ms subframes.
Each frame is divided into two equally-sized half-frames of five subframes each. The slot duration is 14 symbols with
Normal CP and 12 symbols with Extended CP, and scales in time as a function of the used sub-carrier spacing so that
there is always an integer number of slots in a subframe.
Timing Advance TA is used to adjust the uplink frame timing relative to the downlink frame timing.
Downlink frame i
Uplink frame i
5.2 Downlink
5.2.1 Downlink transmission scheme
A closed loop Demodulation Reference Signal (DMRS) based spatial multiplexing is supported for Physical Downlink
Shared Channel (PDSCH). Up to 8 and 12 orthogonal DL DMRS ports are supported for type 1 and type 2 DMRS
respectively. Up to 8 orthogonal DL DMRS ports per UE are supported for SU-MIMO and up to 4 orthogonal DL
DMRS ports per UE are supported for MU-MIMO. The number of SU-MIMO code words is one for 1-4 layer
transmissions and two for 5-8 layer transmissions.
The DMRS and corresponding PDSCH are transmitted using the same precoding matrix and the UE does not need to
know the precoding matrix to demodulate the transmission. The transmitter may use different precoder matrix for
different parts of the transmission bandwidth, resulting in frequency selective precoding. The UE may also assume that
the same precoding matrix is used across a set of Physical Resource Blocks (PRBs) denoted Precoding Resource Block
Group (PRG).
3GPP
Release 16 29 3GPP TS 38.300 V16.21.0 (2020-073)
- Rate matching;
- Scrambling;
- Layer mapping;
The UE may assume that at least one symbol with demodulation reference signal is present on each layer in which
PDSCH is transmitted to a UE, and up to 3 additional DMRS can be configured by higher layers.
Phase Tracking RS may be transmitted on additional symbols to aid receiver phase tracking.
- Downlink assignments containing at least modulation and coding format, resource allocation, and hybrid-ARQ
information related to DL-SCH;
- Uplink scheduling grants containing at least modulation and coding format, resource allocation, and hybrid-ARQ
information related to UL-SCH.
- Notifying one or more UEs of the PRB(s) and OFDM symbol(s) where the UE may assume no transmission is
intended for the UE;
- Transmission of one or more TPC commands for SRS transmissions by one or more UEs;
- Indicating the UE(s) to monitor the PDCCH during the next occurrence of the DRX on-duration;.
A UE monitors a set of PDCCH candidates in the configured monitoring occasions in one or more configured COntrol
REsource SETs (CORESETs) according to the corresponding search space configurations.
A CORESET consists of a set of PRBs with a time duration of 1 to 3 OFDM symbols. The resource units Resource
Element Groups (REGs) and Control Channel Elements (CCEs) are defined within a CORESET with each CCE
consisting a set of REGs. Control channels are formed by aggregation of CCE. Different code rates for the control
channels are realized by aggregating different number of CCE. Interleaved and non-interleaved CCE-to-REG mapping
are supported in a CORESET.
3GPP
Release 16 30 3GPP TS 38.300 V16.21.0 (2020-073)
Each resource element group carrying PDCCH carries its own DMRS.
Within the frequency span of a carrier, multiple SSBs can be transmitted. The PCIs of SSBs transmitted in different
frequency locations do not have to be unique, i.e. different SSBs in the frequency domain can have different PCIs.
However, when an SSB is associated with an RMSI, the SSB corresponds to an individual cell, which has a unique
NCGI (see clause 8.2). Such an SSB is referred to as a Cell-Defining SSB (CD-SSB). A PCell is always associated to a
CD-SSB located on the synchronization raster.
239 P
B
C
192 H
182
P P
P S
Subcarrier B B
S S
Number C C
S S
H H
56
47 P
B
C
H
0
0 1 2 3
The UE may assume a band-specific sub-carrier spacing for the SSB unless a network has configured the UE to assume
a different sub-carrier spacing.
3GPP
Release 16 31 3GPP TS 38.300 V16.21.0 (2020-073)
For channel state estimation purposes, the UE may be configured to measure CSI-RS and estimate the downlink
channel state based on the CSI-RS measurements. The UE feeds the estimated channel state back to the gNB to be used
in link adaptation.
5.2.5.4 HARQ
Asynchronous Incremental Redundancy Hybrid ARQ is supported. The gNB provides the UE with the HARQ-ACK
feedback timing either dynamically in the DCI or semi-statically in an RRC configuration. Retransmission of HARQ-
ACK feedback is supported for operation with shared spectrum channel access by using enhanced dynamic codebook
and/or one-shot triggering of HARQ-ACK transmission for all configured CCs and HARQ processes in the PUCCH
group.
The UE may be configured to receive code block group based transmissions where retransmissions may be scheduled to
carry a sub-set of all the code blocks of a TB.
Besides DL PRS signals, UE can use SSB and CSI-RS for RRM (RSRP and RSRQ) measurements for E-CID type of
positioning.
5.3 Uplink
5.3.1 Uplink transmission scheme
Two transmission schemes are supported for PUSCH: codebook based transmission and non-codebook based
transmission.
For codebook based transmission, the gNB provides the UE with a transmit precoding matrix indication in the DCI. The
UE uses the indication to select the PUSCH transmit precoder from the codebook. For non-codebook based
transmission, the UE determines its PUSCH precoder based on wideband SRI field from the DCI.
A closed loop DMRS based spatial multiplexing is supported for PUSCH. For a given UE, up to 4 layer transmissions
are supported. The number of code words is one. When transform precoding is used, only a single MIMO layer
transmission is supported.
3GPP
Release 16 32 3GPP TS 38.300 V16.21.0 (2020-073)
Two types of frequency hopping are supported, intra-slot frequency hopping, and in case of slot aggregation, inter-slot
frequency hopping. Intra-slot and inter-slot frequency hopping are not supported when PRB interlace uplink
transmission waveform is used.
PUSCH may be scheduled with DCI on PDCCH, or a semi-static configured grant may be provided over RRC, where
two types of operation are supported:
- The first PUSCH is triggered with a DCI, with subsequent PUSCH transmissions following the RRC
configuration and scheduling received on the DCI, or
- The PUSCH is triggered by data arrival to the UE's transmit buffer and the PUSCH transmissions follow the
RRC configuration.
- Rate matching;
- Scrambling;
- Modulation: π/2 BPSK (with transform precoding only), QPSK, 16QAM, 64QAM and 256QAM;
The UE transmits at least one symbol with demodulation reference signal on each layer on each frequency hop in which
the PUSCH is transmitted, and up to 3 additional DMRS can be configured by higher layers.
Phase Tracking RS may be transmitted on additional symbols to aid receiver phase tracking.
For configured grants operation with shared spectrum channel access, described in section 10.3, a CG-UCI (Configured
Grant Uplink Control Information) is transmitted in PUSCH scheduled by configured uplink grant.
- Format #0: Short PUCCH of 1 or 2 symbols with small UCI payloads of up to two bits with UE multiplexing
capacity of up to 6 UEs with 1-bit payload in the same PRB;
- Format #1: Long PUCCH of 4-14 symbols with small UCI payloads of up to two bits with UE multiplexing
capacity of up to 84 UEs without frequency hopping and 36 UEs with frequency hopping in the same PRB;
- Format #2: Short PUCCH of 1 or 2 symbols with large UCI payloads of more than two bits with no UE
multiplexing capability in the same PRBs;
- Format #3: Long PUCCH of 4-14 symbols with large UCI payloads with no UE multiplexing capability in the
same PRBs;
3GPP
Release 16 33 3GPP TS 38.300 V16.21.0 (2020-073)
- Format #4: Long PUCCH of 4-14 symbols with moderate UCI payloads with multiplexing capacity of up to 4
UEs in the same PRBs.
The short PUCCH format of up to two UCI bits is based on sequence selection, while the short PUCCH format of more
than two UCI bits frequency multiplexes UCI and DMRS. The long PUCCH formats time-multiplex the UCI and
DMRS. Frequency hopping is supported for long PUCCH formats and for short PUCCH formats of duration of 2
symbols. Long PUCCH formats can be repeated over multiple slots.
For operation with shared spectrum channel access, PUCCH Format #0, #1, #2, #3 are extended to use resource in one
PRB interlace (up to two interlaces for Format #2 and Format #3) in one RB Set. PUCCH Format #2 and #3 are
enhanced to support multiplexing capacity of up to 4 UEs in the same PRB interlace when one interlace is used.
UCI multiplexing in PUSCH is supported when UCI and PUSCH transmissions coincide in time, either due to
transmission of a UL-SCH transport block or due to triggering of A-CSI transmission without UL-SCH transport block:
- CSI;
- ACK/NAK;
- Scheduling request.
For operation with shared spectrum channel access, multiplexing of CG-UCI and PUCCH carrying HARQ-ACK
feedback can be configured by the gNB. If not configured, when PUCCH overlaps with PUSCH scheduled by a
configured grant within a PUCCH group and PUCCH carries HARQ ACK feedback, PUSCH scheduled by configured
grant is skipped.
QPSK and π/2 BPSK modulation can be used for long PUCCH with more than 2 bits of information, QPSK is used for
short PUCCH with more than 2 bits of information and BPSK and QPSK modulation can be used for long PUCCH with
up to 2 information bits.
Channel coding used for uplink control information is described in table 5.3.3-1.
Multiple PRACH preamble formats are defined with one or more PRACH OFDM symbols, and different cyclic prefix
and guard time. The PRACH preamble configuration to use is provided to the UE in the system information.
3GPP
Release 16 34 3GPP TS 38.300 V16.21.0 (2020-073)
For IAB additional random access configurations are defined. These configurations are obtained by extending the
random access configurations defined for UEs via scaling the periodicity and/or offsetting the time domain position of
the RACH occasions.
IAB-MTs can be provided with random access configurations (as defined for UEs or after applying the aforementioned
scaling/offsetting) different from random access configurations provided to UEs.
The UE calculates the PRACH transmit power for the retransmission of the preamble based on the most recent estimate
pathloss and power ramping counter.
The system information provides information for the UE to determine the association between the SSB and the RACH
resources. The RSRP threshold for SSB selection for RACH resource association is configurable by network.
For channel state estimation purposes, the UE may be configured to transmit SRS that the gNB may use to estimate the
uplink channel state and use the estimate in link adaptation.
5.3.5.4 HARQ
Asynchronous Incremental Redundancy Hybrid ARQ is supported. The gNB schedules each uplink transmission and
retransmission using the uplink grant on DCI. For operation with shared spectrum channel access, UE can also
retransmit on configured grants.
The UE may be configured to transmit code block group based transmissions where retransmissions may be scheduled
to carry a sub-set of all the code blocks of a transport block.
Up to two HARQ-ACK codebooks corresponding to a priority (high/low) can be constructed simultaneously. For each
HARQ-ACK codebook, more than one PUCCH for HARQ-ACK transmission within a slot is supported. Each PUCCH
is limited within one sub-slot, and the sub-slot pattern is configured per HARQ-ACK codebook.
3GPP
Release 16 35 3GPP TS 38.300 V16.21.0 (2020-073)
The periodic, semipersistent and aperiodic transmission of SRS for positioning is defined for gNB UL RTOA, UL SRS-
RSRP, UL-AoA, gNB Rx-Tx time difference measurements to facilitate support of UL TDOA, UL AoA and multi-RTT
positioning methods as described in TS 38.305 [42].
- A UE with single timing advance capability for CA can simultaneously receive and/or transmit on multiple CCs
corresponding to multiple serving cells sharing the same timing advance (multiple serving cells grouped in one
TAG);
- A UE with multiple timing advance capability for CA can simultaneously receive and/or transmit on multiple
CCs corresponding to multiple serving cells with different timing advances (multiple serving cells grouped in
multiple TAGs). NG-RAN ensures that each TAG contains at least one serving cell;
- A non-CA capable UE can receive on a single CC and transmit on a single CC corresponding to one serving cell
only (one serving cell in one TAG).
CA is supported for both contiguous and non-contiguous CCs. When CA is deployed frame timing and SFN are aligned
across cells that can be aggregated, or an offset in multiples of slots between the PCell/PSCell and an SCell is
configured to the UE. The maximum number of configured CCs for a UE is 16 for DL and 16 for UL.
- requirement to be broadcast in the entire coverage area of the cell, either as a single message or by
beamforming different BCH instances.
- support for dynamic link adaptation by varying the modulation, coding and transmit power;
3GPP
Release 16 36 3GPP TS 38.300 V16.21.0 (2020-073)
- support for UE discontinuous reception (DRX) to enable UE power saving (DRX cycle is indicated by the
network to the UE);
- requirement to be broadcast in the entire coverage area of the cell, either as a single message or by
beamforming different BCH instances;
- mapped to physical resources which can be used dynamically also for traffic/other control channels.
- support for dynamic link adaptation by varying the transmit power and potentially modulation and coding;
- collision risk.
- support for both UE autonomous resource selection and scheduled resource allocation by NG-RAN;
- support for both dynamic and semi-static resource allocation when UE is allocated resources by the NG-
RAN;
- support for dynamic link adaptation by varying the transmit power, modulation and coding.
3GPP
Release 16 37 3GPP TS 38.300 V16.21.0 (2020-073)
The gNB operates in either dynamic or semi-static channel access mode as described in TS 37.213 [37]. In both channel
access modes, the gNB and UE may apply Listen-Before-Talk (LBT) before performing a transmission on a cell
configured with shared spectrum channel access. When LBT is applied, the transmitter listens to/senses the channel to
determine whether the channel is free or busy and performs transmission only if the channel is sensed free.
When the UE detects consistent uplink LBT failures, it takes actions as specified in TS 38.321 [6]. The detection is per
Bandwidth Part (BWP) and based on all uplink transmissions within this BWP. When consistent uplink LBT failures
are detected on SCell(s), the UE reports this to the corresponding gNB (MN for MCG, SN for SCG) via MAC CE on a
different serving cell than the SCell(s) where the failures were detected. If no resources are available to transmit the
MAC CE, a Scheduling Request (SR) can be transmitted by the UE. When consistent uplink LBT failures are detected
on SpCell, the UE switches to another UL BWP with configured RACH resources on that cell, initiates RACH, and
reports the failure via MAC CE. When multiple UL BWPs are available for switching, it is up to the UE
implementation which one to select. For PSCell, if consistent uplink LBT failures are detected on all the UL BWPs with
configured RACH resources, the UE declares SCG RLF and reports the failure to the MN via SCGFailureInformation.
For PCell, if the uplink LBT failures are detected on all the UL BWP(s) with configured RACH resources, the UE
declares RLF.
Editor’s Note: It is FFS whether and where to capture NR-U deployment scenarios (e.g. in this section or Annex).
For DRBs, the gNB selects the CAPC by taking into account the 5QIs of all the QoS flows multiplexed in this DRB
while considering fairness between different traffic types and transmissions. For SRB0, SRB1, and SRB3, the CAPC is
always the highest priority (i.e. the lowest number in Table 5.6.2-1). The padding BSR and recommended bit rate MAC
CEs use the lowest priority CAPC (i.e. highest number in Table 5.6.2-1) while other MAC CEs use the highest priority
CAPC. For uplink transmissions on configured grants, MSG3 and MSGsgA PUSCH transmissions, and other uplinkUL
transmissions where the UE performs Type 1 LBT (see TS 37.213 [37], clause 4.2.1.1) and CAPC is not indicated in the
DCI, the gNB configures the UE for the CAPC to be used for SRB2 and DRBs and the UE shall select the CAPC as
follows:
- highest priority CAPC of MAC CE(s) if only MAC CE(s) are included;
- lowest priority CAPC of the logical channel(s) with MAC SDU multiplexed in this MAC PDU otherwise.
Table 5.6.2-1: Mapping between Channel Access Priority Classes and 5QI
5.7 Sidelink
5.7.1 General
Sidelink supports UE-to-UE direct communication using the sidelink resource allocation transmission modes, physical-
layer signals/channels, and physical layer procedures below.
3GPP
Release 16 38 3GPP TS 38.300 V16.21.0 (2020-073)
Physical Sidelink Shared Channel (PSSCH) transmits the TBs of data themselves, and control information for HARQ
procedures and CSI feedback triggers, etc. At least 5 6 OFDM symbols within a slot are used for PSSCH transmission.
PSSCH transmission is associated with a DM-RS and may be associated with a PT-RS.
Physical Ssidelink Ffeedback Cchannel (PSFCH) carries HARQ feedback over the sidelink from a UE which is an
intended recipient of a PSSCH transmission to the UE which performed the transmission. PSFCH sequence is
transmitted in one PRB repeated over two OFDM symbols near the end of the sidelink resource in a slot.
The Sidelink sSynchronization sSignal consists of sidelink primary and sidelink secondary synchronization signals (S-
PSS, S-SSS), each occupying 2 symbols and 127 subcarriers. Physical Sidelink Broadcast Channel (PSBCH) occupies 7
9 and 5 symbols for normal and extended cyclic prefix cases respectively, including the associated DM-RS.
In sidelink resource allocation mode 1, a UE which received PSFCH can report sidelink HARQ feedback to gNB via
PUCCH or PUSCH.
For unicast, the power spectral density of some sidelink transmissions can be adjusted based on the pathloss between
the two communicating UEs.
3GPP
Release 16 39 3GPP TS 38.300 V16.21.0 (2020-073)
6 Layer 2
6.1 Overview
The layer 2 of NR is split into the following sublayers: Medium Access Control (MAC), Radio Link Control (RLC),
Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP). The two figures below
depict the Layer 2 architecture for downlink and uplink, where:
NOTE: The gNB may not be able to guarantee that a L2 buffer overflow will never occur. If such overflow
occurs, the UE may discard packets in the L2 buffer.
QoS Flows
Radio Bearers
RLC Channels
Logical Channels
HARQ HARQ
Transport Channels
3GPP
Release 16 40 3GPP TS 38.300 V16.21.0 (2020-073)
QoS Flows
QoS flow
SDAP handling
Radio Bearers
ROHC ROHC
PDCP
Security Security
RLC Channels
Segm. Segm.
RLC ARQ
...
ARQ
Logical Channels
Scheduling
MAC Multiplexing
HARQ
Transport Channels
Radio bearers are categorized into two groups: data radio bearers (DRB) for user plane data and signalling radio bearers
(SRB) for control plane data.
For IAB, the Llayer 2 of NR also includes: Backhaul Adaptation Protocol (BAP).
- The BAP sublayer supports routing across the IAB topology and traffic mapping to BH RLC channels for
enforcement of traffic prioritization and QoS.
Figures 6.1-3 below depicts the Layer- 2 architecture for downlink on the IAB-donor. Figure 6.1-4 and 6.1-5 depict the
Layer- 2 architecture for downlink and uplink on the IAB-node, where the BAP sublayer offers routing functionality
and mapping to backhaul RLC channels.
3GPP
Release 16 41 3GPP TS 38.300 V16.21.0 (2020-073)
QoS Flows
UE Radio Bearers
Access RLC
Channels
Upper layer Upper layer Upper layer Upper layer Upper layer Upper layer
processing processing processing processing processing processing
BH RLC
Channels
Transport Channels
Transport Channels
RX HARQ
MAC RX
De-multiplexing Backhaul Link
BH Logical Channels
Reassemble Reassemble
RLC RX ARQ ARQ
BH RLC Channels
Transport Channels
3GPP
Release 16 42 3GPP TS 38.300 V16.21.0 (2020-073)
Transport Channels
MAC RX
De-multiplexing De-multiplexing De-multiplexing
Backhaul Link Backhaul Link Access Link UE
... ... ...
BH Logical Access Logical
Channels Channels
BH RLC Channels
BH Logical Channels
...
MAC TX
Multiplexing Backhaul Link
TX HARQ
Transport Channels
- Multiplexing/demultiplexing of MAC SDUs belonging to one or different logical channels into/from transport
blocks (TB) delivered to/from the physical layer on transport channels;
- Error correction through HARQ (one HARQ entity per cell in case of CA);
- Priority handling between logical channels of one UE by means of logical channel prioritisation;
- Padding.
A single MAC entity can support multiple numerologies, transmission timings and cells. Mapping restrictions in logical
channel prioritisation control which numerology(ies), cell(s), and transmission timing(s) a logical channel can use (see
clause 16.1.2).
3GPP
Release 16 43 3GPP TS 38.300 V16.21.0 (2020-073)
- Broadcast Control Channel (BCCH): a downlink channel for broadcasting system control information.
- Paging Control Channel (PCCH): a downlink channel that carries paging messages.
- Common Control Channel (CCCH): channel for transmitting control information between UEs and network.
This channel is used for UEs having no RRC connection with the network.
- Dedicated Control Channel (DCCH): a point-to-point bi-directional channel that transmits dedicated control
information between a UE and the network. Used by UEs having an RRC connection.
Traffic channels are used for the transfer of user plane information only:
- Dedicated Traffic Channel (DTCH): point-to-point channel, dedicated to one UE, for the transfer of user
information. A DTCH can exist in both uplink and downlink.
In Uplink, the following connections between logical channels and transport channels exist:
6.2.4 HARQ
The HARQ functionality ensures delivery between peer entities at Layer 1. A single HARQ process supports one TB
when the physical layer is not configured for downlink/uplink spatial multiplexing, and when the physical layer is
configured for downlink/uplink spatial multiplexing, a single HARQ process supports one or multiple TBs.
3GPP
Release 16 44 3GPP TS 38.300 V16.21.0 (2020-073)
The RLC configuration is per logical channel with no dependency on numerologies and/or transmission durations, and
ARQ can operate on any of the numerologies and/or transmission durations the logical channel is configured with.
For SRB0, paging and broadcast system information, TM mode is used. For other SRBs AM mode used. For DRBs,
either UM or AM mode are used.
- Segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs;
- RLC re-establishment;
6.3.3 ARQ
The ARQ within the RLC sublayer has the following characteristics:
- ARQ retransmits RLC SDUs or RLC SDU segments based on RLC status reports;
- RLC receiver can also trigger RLC status report after detecting a missing RLC SDU or RLC SDU segment.
- Duplication;
3GPP
Release 16 45 3GPP TS 38.300 V16.21.0 (2020-073)
- Out-of-order delivery;
- Duplicate discarding.
Since PDCP does not allow COUNT to wrap around in DL and UL, it is up to the network to prevent it from happening
(e.g. by using a release and add of the corresponding radio bearer or a full configuration).
A single protocol entity of SDAP is configured for each individual PDU session.
n n+1 m
RBx RBy
SDAP H SDAP SDU H SDAP SDU H SDAP SDU ...
RLC H RLC SDU H RLC SDU H SDU Segment H SDU Segment ...
MAC H MAC SDU H MAC SDU H MAC SDU H MAC SDU ...
- In both uplink and downlink, there is one independent hybrid-ARQ entity per serving cell and one transport
block is generated per assignment/grant per serving cell in the absence of spatial multiplexing. Each transport
block and its potential HARQ retransmissions are mapped to a single serving cell.
3GPP
Release 16 46 3GPP TS 38.300 V16.21.0 (2020-073)
QoS Flows
Radio Bearers
RLC Channels
Logical Channels
Transport Channels
3GPP
Release 16 47 3GPP TS 38.300 V16.21.0 (2020-073)
QoS Flows
QoS flow
SDAP handling
Radio Bearers
ROHC ROHC
PDCP
Security Security
RLC Channels
Segm. Segm.
RLC ... ...
ARQ ARQ
Logical Channels
Scheduling
MAC Multiplexing
HARQ HARQ
Transport Channels
Figure 6.10-1 below describes a scenario where 3 different BWPs are configured:
3GPP
Release 16 48 3GPP TS 38.300 V16.21.0 (2020-073)
frequency
BWP3
20MHz/ 60kHz
BWP1 BWP1
40MHz BWP2 BWP2 40MHz
...
15kHz 15kHz
10MHz/ 15kHz 10MHz/ 15kHz
time
- Transfer of data;
- Determination of BAP destination and BAP path for packets from upper layers;
- Differentiating traffic to be delivered to upper layers from traffic to be delivered to egress link;
- BH RLF indicationnotification.
3GPP
Release 16 49 3GPP TS 38.300 V16.21.0 (2020-073)
Multiple mappings can contain the same BH Backhaul RLC channel and/or next-hop BAP address and/or BAP routing
ID. In case the IAB-MT is NR-dual-connected (SA-mode only), the mapping may include two separate BH RLC
channels, where the two BH RLC channels are established toward different parent IAB-DUs.
In case the IAB-node is configured with multiple IP addresses for F1-C on the NR leg, multiple mappings can be
configured for non-UE-associated F1AP messages or UE-associated F1AP messages. The appropriate mapping is
selected based on the IAB node’s implementation.
These traffic mapping configurations are performed received via F1AP. During IAB-node integration, before F1AP is
established, a default BH RLC channel and a default BAP routing ID may be are configured via RRC, which can beare
used for all upper layer traffic. These default configurations may be updated during topology adaptation scenarios as
discussed in [4].
In downstream direction, traffic mapping occurs internal to the IAB-donor. Transport for IAB-donors that use split-gNB
architecture is handled in TS 38.401 [4].
In case the IAB-MT is NR-dual-connected (SA-mode only), the mapping may include two separate BH RLC channels,
where the two BH RLC channels are established towards different parent IAB-DUs.
In case the IAB-node is configured with multiple IP addresses for F1-C on the NR leg, multiple mappings can be
configured for non-UE-associated F1AP messages or UE-associated F1AP messages. The appropriate mapping is
selected based on the IAB node’s implementation.
Prior-hop
Ingress BH link
Ingress BH RLC channels
Routing
Selection of BH RLC channel
Egress BH link
Egress BH RLC channels
Next-hop Next-hop
Routing on BAP sublayer uses the BAP routing ID, which is configured by the IAB-donor-CU. The BAP routing ID
consists of BAP address and BAP path ID. The BAP address is used for the following purposes:
1. Determination if a packet has reached the destination node, i.e. IAB-node or IAB-donor- DU, on BAP sublayer.
This is the case if the BAP address in the packet’s BAP header matches the BAP address configured via RRC on
the IAB-node, or via F1AP on the IAB-donor- DU.
2. Determination of the next-hop node for packets that have not reached their destination. This applies to packets
arriving from a prior hop on BAP sub-layer or that have been received from IP layer.
For packets arriving from a prior hop or from upper layers, the determination of the next-hop node is based on a routing
configuration provided by the IAB-donor- CU via F1AP signalling. This configuration contains the mapping between
the BAP routing ID carried in the packet’s BAP header and the next-hop node’s BAP address.
3GPP
Release 16 50 3GPP TS 38.300 V16.21.0 (2020-073)
The IAB-node resolves the next-hop BAP address to a physical backhaul link. For this purpose, the IAB-donor- CU
provides the IAB-node with its child-node’s BAP address viain a UE-associated F1AP message and its parent-node’s
BAP address via in RRC signalling.
The IAB-node can receive multiple routing configurations with the same destination BAP address but different BAP
path IDs. These routing configurations may resolve to the same or different egress BH links. In case the BH link has
RLF, the IAB-node may select another BH link based on routing entries with the same destination BAP address, i.e., by
disregarding the BAP path ID. In this manner, a packet can be delivered via an alternative path in case the indicated
path is not available.
When routing a packet from an ingress to an egress BH link, the IAB-node derives the egress BH RLC -channel on the
egress BH link through an F1AP-configured mapping from the BH RLC channel used on the ingress BH link. The BH
RLC channel IDs used for ingress and egress BH RLC channels are generated by the IAB-donor- CU. Since the BH
RLC channel ID only has link-local scope, the mapping configurations also include the BAP addresses of prior and next
hop:
Next-hop BAP address Prior-hop BAP address Ingress RLC channel ID Egress RLC channel ID
Derived from routing Derived from packet’s Derived from packet’s BH RLC channelTo be
configuration ingress link ingress BH RLC used on egress link to
channellink forward packet
The IAB-node resolves the BH RLC channel IDs from logical channel IDs based on the configuration by the IAB-
donor-CU. For BH RLC channels in downstream direction, the BH RLC channel ID is included in the F1AP
configuration of the BH RLC channel. For BH RLC channels in upstream direction, the BH RLC channel ID is included
in the RRC configuration of the corresponding logical channel.
7 RRC
- Establishment, maintenance and release of an RRC connection between the UE and NG-RAN including:
- Addition, modification and release of Dual Connectivity in NR or between E-UTRA and NR.
- Establishment, configuration, maintenance and release of Signalling Radio Bearers (SRBs) and Data Radio
Bearers (DRBs);
- UE cell selection and reselection and control of cell selection and reselection;
- Inter-RAT mobility.
3GPP
Release 16 51 3GPP TS 38.300 V16.21.0 (2020-073)
The sidelink specific services and functions of the RRC sublayer over the Uu interface include:
- RRC_IDLE:
- PLMN selection;
- RRC_INACTIVE:
- PLMN selection;
- RRC_CONNECTED:
3GPP
Release 16 52 3GPP TS 38.300 V16.21.0 (2020-073)
- Minimum SI comprises basic information required for initial access and information for acquiring any other SI.
Minimum SI consists of:
- MIB contains cell barred status information and essential physical layer information of the cell required to
receive further system information, e.g. CORESET#0 configuration. MIB is periodically broadcast on BCH.
- SIB1 defines the scheduling of other system information blocks and contains information required for initial
access. SIB1 is also referred to as Remaining Minimum SI (RMSI) and is periodically broadcast on DL-SCH
or sent in a dedicated manner on DL-SCH to UEs in RRC_CONNECTED.
- Other SI encompasses all SIBs not broadcast in the Minimum SI. Those SIBs can either be periodically
broadcast on DL-SCH, broadcast on-demand on DL-SCH (i.e. upon request from UEs in RRC_IDLE, or
RRC_INACTIVE), or RRC_CONNECTED), or sent in a dedicated manner on DL-SCH to UEs in
RRC_CONNECTED (i.e., upon request, if configured by the network, from UEs in RRC_CONNECTED or
when the UE has an active BWP with no common search space configured). Other SI consists of:
- SIB2 contains cell re-selection information, mainly related to the serving cell;
- SIB3 contains information about the serving frequency and intra-frequency neighbouring cells relevant for
cell re-selection (including cell re-selection parameters common for a frequency as well as cell specific re-
selection parameters);
- SIB4 contains information about other NR frequencies and inter-frequency neighbouring cells relevant for
cell re-selection (including cell re-selection parameters common for a frequency as well as cell specific re-
selection parameters);
- SIB5 contains information about E-UTRA frequencies and E-UTRA neighbouring cells relevant for cell re-
selection (including cell re-selection parameters common for a frequency as well as cell specific re-selection
parameters);
- SIB9 contains information related to GPS time and Coordinated Universal Time (UTC);.
- SIB10 contains the Human-Readable Network Names (HRNN) of the NPNs listed in SIB1;.
- SIBpos contains positioning assistance data as defined in TS 37.355 [49] and TS 38.331 [12].
3GPP
Release 16 53 3GPP TS 38.300 V16.21.0 (2020-073)
UE gNB
Minimum SI (MIB)
periodically broadcast on BCH
Minimum SI (SIB1)
periodically broadcast on DL-SCH
Minimum SI (SIB1)
unicast on DL-SCH
Other SI (SIBn)
periodically broadcast on DL-SCH
Other SI (SIBn)
broadcast on-demand on DL-SCH
Other SI (SIBn)
unicast on DL-SCH
Other SI (SIBn)
unicast on-demand on DL-SCH
For a cell/frequency that is considered for camping by the UE, the UE is not required to acquire the contents of the
minimum SI of that cell/frequency from another cell/frequency layer. This does not preclude the case that the UE
applies stored SI from previously visited cell(s).
If the UE cannot determine the full contents of the minimum SI of a cell by receiving from that cell, the UE shall
consider that cell as barred.
7.3.2 Scheduling
The MIB is mapped on the BCCH and carried on BCH while all other SI messages are mapped on the BCCH, where
they are dynamically carried on DL-SCH. The scheduling of SI messages part of Other SI is indicated by SIB1.
For UEs in RRC_IDLE and RRC_INACTIVE, a request for Other SI triggers a random access procedure (see clause
9.2.6) where MSG3 includes the SI request message unless the requested SI is associated to a subset of the PRACH
resources, in which case MSG1 is used for indication of the requested Other SI. When MSG1 is used, the minimum
granularity of the request is one SI message (i.e. a set of SIBs), one RACH preamble and/or PRACH resource can be
used to request multiple SI messages and the gNB acknowledges the request in MSG2. When MSG 3 is used, the gNB
acknowledges the request in MSG4.
For UEs in RRC_CONNECTED, a request for Other SI may be sent to the network, if configured by the network, in a
dedicated manner (i.e., via UL-DCCH) and the granularity of the request is one SIB. The gNB may respond with an
RRCReconfiguration including the requested SIB(s). It is a network choice to decide which requested SIBs are
delivered in a dedicated or broadcasted manner.
The Other SI may be broadcast at a configurable periodicity and for a certain duration. The Other SI may also be
broadcast when it is requested by UE in RRC_IDLE/RRC_INACTIVE/RRC_CONNECTED.
For a UE to be allowed to camp on a cell it must have acquired the contents of the Minimum SI from that cell. There
may be cells in the system that do not broadcast the Minimum SI and where the UE therefore cannot camp.
7.3.3 SI Modification
Change of system information (other than for ETWS/CMAS, see clause 16.4) only occurs at specific radio frames, i.e.
the concept of a modification period is used. System information may be transmitted a number of times with the same
content within a modification period, as defined by its scheduling. The modification period is configured by system
information.
When the network changes (some of the) system information, it first notifies the UEs about this change, i.e. this may be
done throughout a modification period. In the next modification period, the network transmits the updated system
information. Upon receiving a change notification, the UE acquires the new system information from the start of the
3GPP
Release 16 54 3GPP TS 38.300 V16.21.0 (2020-073)
next modification period. The UE applies the previously acquired system information until the UE acquires the new
system information.
One unified access control framework as specified in TS 22.261 [19] applies to all UE states (RRC_IDLE,
RRC_INACTIVE and RRC_CONNECTED) for NR. NG-RAN broadcasts barring control information associated with
Access Categories and Access Identities (in case of network sharing, the barring control information can be set
individually for each PLMN). The UE determines whether an access attempt is authorized based on the barring
information broadcast for the selected PLMN, and the selected Access Category and Access Identity(ies) for the access
attempt:
- For NAS triggered requests, NAS determines the Access Category and Access Identity(ies);
- For AS triggered requests, RRC determines the Access Category while NAS determines the Access Identity(ies).
The gNB handles access attempts with establishment causes "emergency", "mps-PriorityAccess" and "mcs-
PriorityAccess" (i.e. Emergency calls, MPS, MCS subscribers) with high priority and responds with RRC Reject to
these access attempts only in extreme network load conditions that may threaten the gNB stability.
- For transferring the initial NAS message during connection setup and connection resume in the UL.
NOTE: In addition to the integrity protection and ciphering performed by NAS, NAS messages can also be
integrity protected and ciphered by PDCP.
Multiple NAS messages can be sent in a single downlink RRC message during PDU Session Resource establishment or
modification. In this case, the order of the NAS messages contained in the RRC message shall be in the same order as
that in the corresponding NG-AP message in order to ensure the in-sequence delivery of NAS messages.
The reconfiguration, addition and removal of SCells can be performed by RRC. At intra-NR handover and during
connection resume from RRC_INACTIVE, the network can also add, remove, keep, or reconfigure SCells for usage
3GPP
Release 16 55 3GPP TS 38.300 V16.21.0 (2020-073)
with the target PCell. When adding a new SCell, dedicated RRC signalling is used for sending all required system
information of the SCell i.e. while in connected mode, UEs need not acquire broadcast system information directly from
the SCells.
In paired spectrum, DL and UL can switch BWP independently. In unpaired spectrum, DL and UL switch BWP
simultaneously. Switching between configured BWPs happens by means of RRC signalling, DCI, inactivity timer or
upon initiation of random access. When an inactivity timer is configured for a serving cell, the expiry of the inactivity
timer associated to that cell switches the active BWP to a default BWP configured by the network. There can be at most
one active BWP per cell, except when the serving cell is configured with SUL, in which case there can be at most one
on each UL carrier.
- If it prefers an adjustment in the connected mode DRX cycle length, for the purpose of delay budget reporting;
- If it prefers certain DRX parameter values, and/or a reduced maximum number of secondary component carriers,
and/or a reduced maximum aggregated bandwidth and/or a reduced maximum number of MIMO layers and/or
minimum scheduling offsets K0 and K2 for power saving purpose;
- If it expects not to send or receive any more data in the near future, and in this case, it can provide its preference
to transition out of RRC_CONNECTED where this indication may express its preferred RRC state, or
alternately, it may cancel an earlier indicated preference to transition out of RRC_CONNECTED;
- The list of frequencies affected by IDC problems (see subclause 23.4 of TS 36.300 [2]).
NOTE: Only the Frequency Division Multiplexing (FDM) solution as defined for E-UTRA in subclause 23.4 of
TS 36.300 [2] is used in NR. The requirements on RRM/RLM/CSI measurements in different phases of
IDC interference defined in TS 36.300 [2] are applicable except that for NR serving cell, the requirements
in TS 38.133 [13] and TS 38.101-1 [18], TS 38.101-2 [35], TS 38.101-3 [36] apply.
In the second case, the UE can express a preference for temporarily reducing the number of maximum secondary
component carriers, the maximum aggregated bandwidth and the number of maximum MIMO layers. In all cases, it is
up to the gNB whether to accommodate the request.
For sidelink, the UE can report SL traffic pattern(s) to NG-RAN, for periodic traffic.
In this version of the specification, segmentation applies only to the UECapabilityInformation, RRCReconfiguration,
and RRCResume messages.
3GPP
Release 16 56 3GPP TS 38.300 V16.21.0 (2020-073)
8 NG Identities
8.1 UE Identities
In this clause, the identities used by NR connected to 5GC are listed. For scheduling at cell level, the following
identities are used:
- C-RNTI: unique UE identification used as an identifier of the RRC Connection and for scheduling;
- CS-RNTI: unique UE identification used for Semi-Persistent Scheduling in the downlink or configured grant in
the uplink;
- MCS-C-RNTI: unique UE identification used for indicating an alternative MCS table for PDSCH and PUSCH;
- P-RNTI: identification of Paging and System Information change notification in the downlink;
For power and slot format control, the following identities are used:
During the random access procedure, the following identities are also used:
- Temporary C-RNTI: UE identification temporarily used for scheduling during the random access procedure;
- Random value for contention resolution: UE identification temporarily used for contention resolution purposes
during the random access procedure.
For NR connected to 5GC, the following UE identities are used at NG-RAN level:
For UE power saving purpose during DRX, the following identity is used:
- PS-RNTI: used to determine if the UE needs to monitor PDCCH on the next occurrence of the connected mode
DRX on-duration.
- AI-RNTI: identification of the DCI carrying availability indication for soft symbols of an IAB-DU.
- NR Cell Global Identifier (NCGI): used to identify NR cells globally. The NCGI is constructed from the PLMN
identity the cell belongs to and the NR Cell Identity (NCI) of the cell. The PLMN ID included in the NCGI
3GPP
Release 16 57 3GPP TS 38.300 V16.21.0 (2020-073)
should be the first PLMN ID within the set of PLMN IDs associated to the NR Cell Identity in SIB1, following
the order of broadcast.
NOTE 1: How to manage the scenario where a different PLMN ID has been allocated by the operator for an NCGI
is left to OAM and/or implementation.
- gNB Identifier (gNB ID): used to identify gNBs within a PLMN. The gNB ID is contained within the NCI of its
cells.
- Global gNB ID: used to identify gNBs globally. The Global gNB ID is constructed from the PLMN identity the
gNB belongs to and the gNB ID. The MCC and MNC are the same as included in the NCGI.
NOTE 2: It is not precluded that a cell served by a gNB does not broadcast the PLMN ID included in the Global
gNB ID.
- Tracking Area identity (TAI): used to identify tracking areas. The TAI is constructed from the PLMN identity
the tracking area belongs to and the TAC (Tracking Area Code) of the Tracking Area.
- Single Network Slice Selection Assistance information (S-NSSAI): identifies a network slice.
- Source Layer-2 ID: Identifies the sender of the data in NR sidelink communication. The Source Layer-2 ID is 24
bits long and is split in the MAC layer into two bit strings:
- One bit string is the LSB part (8 bits) of Source Layer-2 ID and forwarded to physical layer of the sender.
This identifies the source of the intended data in sidelink control information and is used for filtering of
packets at the physical layer of the receiver;
- Second bit string is the MSB part (16 bits) of the Source Layer-2 ID and is carried within the MAC header.
This is used for filtering of packets at the MAC layer of the receiver.
- Destination Layer-2 ID: Identifies the target of the data in NR sidelink communication. For NR sidelink
communication, the Destination Layer-2 ID is 24 bits long and is split in the MAC layer into two bit strings:
- One bit string is the LSB part (16 bits) of Destination Layer-2 ID and forwarded to physical layer of the
sender. This identifies the target of the intended data in sidelink control information and is used for filtering
of packets at the physical layer of the receiver;
- Second bit string is the MSB part (8 bits) of the Destination Layer-2 ID and is carried within the MAC
header. This is used for filtering of packets at the MAC layer of the receiver.
- PC5 Link Identifier: Uniquely identifies the PC5 unicast link in a UE for the lifetime of the PC5 unicast link as
specified in TS 23.287 [40]. The PC5 Link Identifier is used to indicate the PC5 unicast link whose sidelink RLF
declaration was made and PC5-RRC connection was released.
V2X sidelink communication related identities are specified in clause 8.3 of TS 36.300 [2].
3GPP
Release 16 58 3GPP TS 38.300 V16.21.0 (2020-073)
9.1 Overview
Load balancing is achieved in NR with handover, redirection mechanisms upon RRC release and through the usage of
inter-frequency and inter-RAT absolute priorities and inter-frequency Qoffset parameters.
Measurements to be performed by a UE for connected mode mobility are classified in at least four measurement types:
- Intra-frequency NR measurements;
- Inter-frequency NR measurements;
For each measurement type one or several measurement objects can be defined (a measurement object defines e.g. the
carrier frequency to be monitored).
For each measurement object one or several reporting configurations can be defined (a reporting configuration defines
the reporting criteria). Three reporting criteria are used: event triggered reporting, periodic reporting and event triggered
periodic reporting.
The association between a measurement object and a reporting configuration is created by a measurement identity (a
measurement identity links together one measurement object and one reporting configuration of the same RAT). By
using several measurement identities (one for each measurement object, reporting configuration pair) it is then possible
to:
The measurements identity is used as well when reporting results of the measurements.
Measurement commands are used by NG-RAN to order the UE to start, modify or stop measurements.
Handover can be performed within the same RAT and/or CN, or it can involve a change of the RAT and/or CN.
Inter system fallback towards E-UTRAN is performed when 5GC does not support emergency services, voice services,
for load balancing etc. Depending on factors such as CN interface availability, network configuration and radio
conditions, the fallback procedure results in either RRC_CONNECTED state mobility (handover procedure) or
RRC_IDLE state mobility (redirection), see TS 23.501 [3] and TS 38.331 [12].
SRVCC from 5G to UTRAN, if supported by both the UE and the network, may be performed to handover a UE with
an ongoing voice call from NR to UTRAN. The overall procedure is described in TS 23.216 [34]. See also TS 38.331
[12] and TS 38.413 [26].
In the NG-C signalling procedure, the AMF based on support for emergency services, voice service, any other services
or for load balancing etc, may indicate the target CN type as EPC or 5GC to the gNB node. When the target CN type is
received by gNB, the target CN type is also conveyed to the UE in RRCRelease Message.
Inter-gNB CSI-RS based mobility, i.e. handover, is supported between two neighbour gNBs by enabling that neighbour
gNBs can exchange and forward their own CSI-RS configurations and on/off status.
3GPP
Release 16 59 3GPP TS 38.300 V16.21.0 (2020-073)
9.2 Intra-NR
9.2.1 Mobility in RRC_IDLE
- Cell selection is always based on CD-SSBs located on the synchronization raster (see clause 5.2.4):
- The UE searches the NR frequency bands and for each carrier frequency identifies the strongest cell as per
the CD-SSB. It then reads cell system information broadcast to identify its PLMN(s):
- The UE may search each carrier in turn ("initial cell selection") or make use of stored information to
shorten the search ("stored information cell selection").
- The UE seeks to identify a suitable cell; if it is not able to identify a suitable cell it seeks to identify an
acceptable cell. When a suitable cell is found or if only an acceptable cell is found it camps on that cell and
commence the cell reselection procedure:
- A suitable cell is one for which the measured cell attributes satisfy the cell selection criteria; the cell PLMN
is the selected PLMN, registered or an equivalent PLMN; the cell is not barred or reserved and the cell is not
part of a tracking area which is in the list of "forbidden tracking areas for roaming";
- An acceptable cell is one for which the measured cell attributes satisfy the cell selection criteria and the cell
is not barred.
- The IAB-MT applies the cell selection procedure as described for the UE with the following differences:
- The IAB-MT ignores cell-barring or cell-reservation indications contained in cell system information
broadcast;
- The IAB-MT only considers a cell as a candidate for cell selection if the cell system information broadcast
indicates IAB support for the selected PLMN or the selected SNPN.
Transition to RRC_IDLE:
The UE should attempt to find a suitable cell in the manner described for stored information or initial cell
selection above. If no suitable cell is found on any frequency or RAT, the UE should attempt to find an
acceptable cell.
In multi-beam operations, the cell quality is derived amongst the beams corresponding to the same cell (see clause
9.2.4).
- Cell reselection is always based on CD-SSBs located on the synchronization raster (see clause 5.2.4).
- The UE makes measurements of attributes of the serving and neighbour cells to enable the reselection process:
- For the search and measurement of inter-frequency neighbouring cells, only the carrier frequencies need to be
indicated.
3GPP
Release 16 60 3GPP TS 38.300 V16.21.0 (2020-073)
- Cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria which
involves measurements of the serving and neighbour cells:
- Inter-frequency reselection is based on absolute priorities where a UE tries to camp on the highest priority
frequency available;
- An NCL can be provided by the serving cell to handle specific cases for intra- and inter-frequency
neighbouring cells;
- Black lists can be provided to prevent the UE from reselecting to specific intra- and inter-frequency
neighbouring cells;
- White lists can be provided to request the UE to reselect to only specific intra- and inter-frequency
neighbouring cells;
In multi-beam operations, the cell quality is derived amongst the beams corresponding to the same cell (see clause
9.2.4).
3GPP
Release 16 61 3GPP TS 38.300 V16.21.0 (2020-073)
UE gNB AMF
UE in RRC_IDLE
CM-IDLE
1. RRCSetupRequest
2. RRCSetup
UE in RRC_CONNECTED
CM-IDLE
2a. RRCSetupComplete
3. INITIAL UE MESSAGE
UE in RRC_CONNECTED
CM-CONNECTED
4a. DLInformationTransfer
5. ULInformationTransfer
7. SecurityModeCommand
7a. SecurityModeComplete
8. RRCReconfiguration
8a. RRCReconfigurationComplete
NOTE: The scenario where the gNB rejects the request is described below.
3. The first NAS message from the UE, piggybacked in RRCSetupComplete, is sent to AMF.
4/4a/5/5a. Additional NAS messages may be exchanged between UE and AMF, see TS 23.502 [22].
6. The AMF prepares the UE context data (including PDU session context, the Security Key, UE Radio Capability
and UE Security Capabilities, etc.) and sends it to the gNB.
8/8a. The gNB performs the reconfiguration to setup SRB2 and DRBs.
9. The gNB informs the AMF that the setup procedure is completed.
NOTE 1: RRC messages in step 1 and 2 use SRB0, all the subsequent messages use SRB1. Messages in steps 7/7a
are integrity protected. From step 8 on, all the messages are integrity protected and ciphered.
NOTE 2: For signalling only connection, step 8 is skipped since SRB2 and DRBs are not setup.
The following figure describes the rejection from the network when the UE attempts to setup a connection from
RRC_IDLE:
3GPP
Release 16 62 3GPP TS 38.300 V16.21.0 (2020-073)
UE gNB
UE in RRC_IDLE
CM-IDLE
1. RRCSetupRequest
2. The gNB is not able to handle the procedure, for instance due to congestion.
3. The gNB sends RRCReject (with a wait time) to keep the UE in RRC_IDLE.
9.2.2.1 Overview
RRC_INACTIVE is a state where a UE remains in CM-CONNECTED and can move within an area configured by NG-
RAN (the RNA) without notifying NG-RAN. In RRC_INACTIVE, the last serving gNB node keeps the UE context and
the UE-associated NG connection with the serving AMF and UPF.
If the last serving gNB receives DL data from the UPF or DL UE-associated signalling from the AMF (except the UE
Context Release Command message) while the UE is in RRC_INACTIVE, it pages in the cells corresponding to the
RNA and may send XnAP RAN Paging to neighbour gNB(s) if the RNA includes cells of neighbour gNB(s).
Upon receiving the UE Context Release Command message while the UE is in RRC_INACTIVE, the last serving gNB
may page in the cells corresponding to the RNA and may send XnAP RAN Paging to neighbour gNB(s) if the RNA
includes cells of neighbour gNB(s), in order to release UE explicitly.
Upon receiving the NG RESET message while the UE is in RRC_INACTIVE, the last serving gNB may page involved
UEs in the cells corresponding to the RNA and may send XnAP RAN Paging to neighbour gNB(s) if the RNA includes
cells of neighbour gNB(s) in order to explicitly release involved UEs.
Upon RAN paging failure, the gNB behaves according to TS 23.501 [3].
The AMF provides to the NG-RAN node the Core Network Assistance Information to assist the NG-RAN node's
decision whether the UE can be sent to RRC_INACTIVE. The Core Network Assistance Information includes the
registration area configured for the UE, the Periodic Registration Update timer, and the UE Identity Index value, and
may include the UE specific DRX, an indication if the UE is configured with Mobile Initiated Connection Only (MICO)
mode by the AMF, and the Expected UE Behaviour. The UE registration area is taken into account by the NG-RAN
node when configuring the RNA. The UE specific DRX and UE Identity Index value are used by the NG-RAN node for
RAN paging. The Periodic Registration Update timer is taken into account by the NG-RAN node to configure Periodic
RNA Update timer. The NG-RAN node takes into account the Expected UE Behaviour to assist the UE RRC state
transition decision.
At transition to RRC_INACTIVE the NG-RAN node may configure the UE with a periodic RNA Update timer value.
At periodic RNA Update timer expiry without notification from the UE, the gNB behaves as specified in TS 23.501 [3].
If the UE accesses a gNB other than the last serving gNB, the receiving gNB triggers the XnAP Retrieve UE Context
procedure to get the UE context from the last serving gNB and may also trigger an Xn-U Address Indication procedure
including tunnel information for potential recovery of data from the last serving gNB. Upon successful UE context
retrieval, the receiving gNB shall perform the slice-aware admission control in case of receiving slice information and
becomes the serving gNB and it further triggers the NGAP Path Switch Request and applicable RRC procedures. After
the path switch procedure, the serving gNB triggers release of the UE context at the last serving gNB by means of the
XnAP UE Context Release procedure.
3GPP
Release 16 63 3GPP TS 38.300 V16.21.0 (2020-073)
In case the UE is not reachable at the last serving gNB, the gNB shall fail any AMF initiated UE-associated class 1
procedure which allows the signalling of unsuccessful operation in the respective response message. It may trigger the
NAS Non Delivery Indication procedure to report the non-delivery of any NAS PDU received from the AMF.
- Fail any AMF initiated UE-associated class 1 procedure which allows the signalling of unsuccessful operation in
the respective response message; and
- Trigger the NAS Non Delivery Indication procedure to report the non-delivery of any NAS PDU received from
the AMF for the UE.
If the UE accesses a gNB other than the last serving gNB and the receiving gNB does not find a valid UE Context, the
receiving gNB can perform establishment of a new RRC connection instead of resumption of the previous RRC
connection. UE context retrieval will also fail and hence a new RRC connection needs to be established if the serving
AMF changes.
A UE in the RRC_INACTIVE state is required to initiate RNA update procedure when it moves out of the configured
RNA. When receiving RNA update request from the UE, the receiving gNB triggers the XnAP Retrieve UE Context
procedure to get the UE context from the last serving gNB and may decide to send the UE back to RRC_INACTIVE
state, move the UE into RRC_CONNECTED state, or send the UE to RRC_IDLE. In case of periodic RNA update, if
the last serving gNB decides not to relocate the UE context, it fails the Retrieve UE Context procedure and sends the
UE back to RRC_INACTIVE, or to RRC_IDLE directly by an encapsulated RRCRelease message.
- the RNA can cover a single or multiple cells, and shall be contained within the CN registration area; in this
release Xn connectivity should be available within the RNA;
- a RAN-based notification area update (RNAU) is periodically sent by the UE and is also sent when the cell
reselection procedure of the UE selects a cell that does not belong to the configured RNA.
There are several different alternatives on how the RNA can be configured:
- List of cells:
- A UE is provided an explicit list of cells (one or more) that constitute the RNA.
- A UE is provided (at least one) RAN area ID, where a RAN area is a subset of a CN Tracking Area or equal
to a CN Tracking Area. A RAN area is specified by one RAN area ID, which consists of a TAC and
optionally a RAN area Code;
- A cell broadcasts one or more RAN area IDs in the system information.
NG-RAN may provide different RNA definitions to different UEs but not mix different definitions to the same UE at
the same time. UE shall support all RNA configuration options listed above.
3GPP
Release 16 64 3GPP TS 38.300 V16.21.0 (2020-073)
UE in RRC_INACTIVE
CM-CONNECTED
1. RRCResumeRequest
4. RRCResume
UE in RRC_CONNECTED
CM-CONNECTED
5. RRCResumeComplete
9. UE CONTEXT RELEASE
1. The UE resumes from RRC_INACTIVE, providing the I-RNTI, allocated by the last serving gNB.
2. The gNB, if able to resolve the gNB identity contained in the I-RNTI, requests the last serving gNB to provide
UE Context data.
4/5. The gNB and UE completes the resumption of the RRC connection.
NOTE: User Data can also be sent in step 5 if the grant allows.
6. If loss of DL user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding
addresses.
9. The gNB triggers the release of the UE resources at the last serving gNB.
After step 1 above, when the gNB decides to use a single RRC message to reject the Resume Request right away and
keep the UE in RRC_INACTIVE without any reconfiguration (e.g. as described in the two examples below), or when
the gNB decides to setup a new RRC connection, SRB0 (without security) is used. Conversely, when the gNB decides
to reconfigure the UE (e.g. with a new DRX cycle or RNA) or when the gNB decides to push the UE to RRC_IDLE,
SRB1 (with integrity protection and ciphering as previously configured for that SRB) shall be used.
NOTE: SRB1 can only be used once the UE Context is retrieved i.e. after step 3.
The following figure describes the UE triggered transition from RRC_INACTIVE to RRC_CONNECTED in case of
UE context retrieval failure:
3GPP
Release 16 65 3GPP TS 38.300 V16.21.0 (2020-073)
UE in RRC_INACTIVE
CM-CONNECTED
1. RRCResumeRequest
5. RRCSetup
1. The UE resumes from RRC_INACTIVE, providing the I-RNTI, allocated by the last serving gNB.
2. The gNB, if able to resolve the gNB identity contained in the I-RNTI, requests the last serving gNB to provide
UE Context data.
3. The last serving gNB cannot retrieve or verify the UE context data.
5. The gNB performs a fallback to establish a new RRC connection by sending RRCSetup.
The following figure describes the rejection form the network when the UE attempts to resume a connection from
RRC_INACTIVE:
UE gNB
UE in RRC_INACTIVE
CM-CONNECTED
1. RRCResumeRequest
2. The gNB is not able to handle the procedure, for instance due to congestion.
3. The gNB sends RRCReject (with a wait time) to keep the UE in RRC_INACTIVE.
3GPP
Release 16 66 3GPP TS 38.300 V16.21.0 (2020-073)
UE in RRC_INACTIVE
CM-CONNECTED
2. RAN Paging
3. Paging UE
1. A RAN paging trigger event occurs (incoming DL user plane, DL signalling from 5GC, etc.).
2. RAN paging is triggered; either only in the cells controlled by the last serving gNB or also by means of Xn RAN
Paging in cells controlled by other gNBs, configured to the UE in the RAN-based Notification Area (RNA).
4. If the UE has been successfully reached, it attempts to resume from RRC_INACTIVE, as described in clause
9.2.2.4.1.
UE in RRC_INACTIVE
CM-CONNECTED
1. RRCResumeRequest
RNA Update
2. RETRIEVE UE CONTEXT REQUEST
4. Send UE to INACTIVE
8. RRCRelease
Suspend Indication
9. UE CONTEXT RELEASE
1. The UE resumes from RRC_INACTIVE, providing the I-RNTI allocated by the last serving gNB and
appropriate cause value, e.g., RAN notification area update.
2. The gNB, if able to resolve the gNB identity contained in the I-RNTI, requests the last serving gNB to provide
UE Context, providing the cause value received in step 1.
3GPP
Release 16 67 3GPP TS 38.300 V16.21.0 (2020-073)
3. The last serving gNB may provide the UE context (as assumed in the following). Alternatively, the last serving
gNB may decide to move the UE to RRC_IDLE (and the procedure follows steps 3 and later of figure 9.2.2.5-3)
or, if the UE is still within the previously configured RNA, to keep the UE context in the last serving gNB and to
keep the UE in RRC_INACTIVE (and the procedure follows steps 3 and later of figure 9.2.2.5-2).
4. The gNB may move the UE to RRC_CONNECTED (and the procedure follows step 4 of Figure 9.2.2.4.1-1), or
send the UE back to RRC_IDLE (in which case an RRCRelease message is sent by the gNB), or send the UE
back to RRC_INACTIVE as assumed in the following.
5. If loss of DL user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding
addresses.
8. The gNB keeps the UE in RRC_INACTIVE state by sending RRCRelease with suspend indication.
9. The gNB triggers the release of the UE resources at the last serving gNB.
The following figure describes the RNA update procedure for the case when the UE is still within the configured RNA
and the last serving gNB decides not to relocate the UE context and to keep the UE in RRC_INACTIVE:
UE in RRC_INACTIVE
CM-CONNECTED
1. RRCResumeRequest
RNA Update
2. RETRIEVE UE CONTEXT REQUEST
RNA Update
3. RETRIEVE UE CONTEXT FAILURE
4. RRCRelease
Suspend Indication
http://msc-generator.sourceforge.net v6.3.5
1. The UE resumes from RRC_INACTIVE, providing the I-RNTI allocated by the last serving gNB and
appropriate cause value, e.g., RAN notification area update.
2. The gNB, if able to resolve the gNB identity contained in the I-RNTI, requests the last serving gNB to provide
UE Context, providing the cause value received in step 1.
3. The last serving gNB stores received information to be used in the next resume attempt (e.g. C-RNTI and PCI
related to the resumption cell), and responds to the gNB with the RETRIEVE UE CONTEXT FAILURE
message including an encapsulated RRCRelease message. The RRCRelease message includes Suspend
Indication.
The following figure describes the RNA update procedure for the case when the last serving gNB decides to move the
UE to RRC_IDLE:
3GPP
Release 16 68 3GPP TS 38.300 V16.21.0 (2020-073)
UE in RRC_INACTIVE
CM-CONNECTED
1. RRCResumeRequest
RNA update
2. RETRIEVE UE CONTEXT REQUEST
4. Release UE context
5. RRCRelease
UE in RRC_IDLE
CM-IDLE
1. The UE resumes from RRC_INACTIVE, providing the I-RNTI allocated by the last serving gNB and
appropriate cause value, e.g., RAN notification area update.
2. The gNB, if able to resolve the gNB identity contained in the I-RNTI, requests the last serving gNB to provide
UE Context, providing the cause value received in step 1.
3. Instead of providing the UE context, the last serving gNB provides an RRCRelease message to move the UE to
RRC_IDLE.
5. The gNB sends the RRCRelease which triggers the UE to move to RRC_IDLE.
9.2.3.1 Overview
Network controlled mobility applies to UEs in RRC_CONNECTED and is categorized into two types of mobility: cell
level mobility and beam level mobility.
Cell Level Mobility requires explicit RRC signalling to be triggered, i.e. handover. For inter-gNB handover, the
signalling procedures consist of at least the following elemental components illustrated in Figure 9.2.3.1-1:
1. HANDOVER REQUEST
Admission Control
3. RRCReconfiguration
4. RRCReconfigurationComplete
1. The source gNB initiates handover and issues a HANDOVER REQUEST over the Xn interface.
3GPP
Release 16 69 3GPP TS 38.300 V16.21.0 (2020-073)
2. The target gNB performs admission control and provides the new RRC configuration as part of the
HANDOVER REQUEST ACKNOWLEDGE.
3. The source gNB provides the RRC configuration to the UE by forwarding the RRCReconfiguration message
received in the HANDOVER REQUEST ACKNOWLEDGE. The RRCReconfiguration message includes at
least cell ID and all information required to access the target cell so that the UE can access the target cell without
reading system information. For some cases, the information required for contention-based and contention-free
random access can be included in the RRCReconfiguration message. The access information to the target cell
may include beam specific information, if any.
4. The UE moves the RRC connection to the target gNB and replies with the RRCReconfigurationComplete.
NOTE 1: User Data can also be sent in step 4 if the grant allows.
In case of DAPS handover, the UE continues the downlink user data reception from the source gNB until releasing the
source cell and continues the uplink user data transmission to the source gNB until successful random access procedure
to the target gNB.
The handover mechanism triggered by RRC requires the UE at least to reset the MAC entity and re-establish RLC,
except for DAPS handover, where upon reception of the handover command, the UE:
The handover mechanism triggered by RRC requires the UE at least to reset the MAC entity and re-establish RLC,
except for DAPS handover, where upon reception of the handover command, the UE:
- Establishes the an RLC entity and an associated DTCH logical channel for target for each DRB configured with
DAPS;
- For the DRB configured with DAPS, reconfigures the PDCP entity with separate security and ROHC functions
for source and target and associates them with the RLC entities configured by source and target respectively;
- Retains the rest of the source configurations until release of the source.
NOTE 2: The handling on RLC and PDCP for DRBs without DAPS is same as in normal handover.
NOTE 3: Only PCell is kept during DAPS handover. All other serving cells and all SCells are released by the
network.
RRC managed handovers with and without PDCP entity re-establishment are both supported. For DRBs using RLC AM
mode, PDCP can either be re-established together with a security key change or initiate a data recovery procedure
without a key change. For DRBs using RLC UM mode and for SRBs, PDCP can either be re-established together with a
security key change or remain as it is without a key change.
Data forwarding, in-sequence delivery and duplication avoidance at handover can be guaranteed when the target gNB
uses the same DRB configuration as the source gNB.
Timer based handover failure procedure is supported in NR. RRC connection re-establishment procedure is used for
recovering from handover failure except in certain CHO or DAPS scenarios:
- When DAPS HO fails, the UE falls back to source cell configuration, resumes the connection with source cell,
and reports DAPS HO failure via the source without triggering RRC connection re-establishment if the source
link has not been released.
- When initial CHO execution attempt fails or HO fails, the UE performs cell selection, and if the selected cell is a
CHO candidate and if network configured the UE to try CHO after HO/CHO failure, then the UE attempts CHO
execution once, otherwise re-establishment is performed.
DAPS handover for FR2 to FR2 case is not supported in this release of the specification.
The handover of the IAB-MT in SA mode follows the same procedure as described for the UE. After the backhaul has
been established, the handover of the IAB-MT is part of the intra-CU topology adaptation procedure defined in TS
38.401 [4]. Modifications to the configuration of BAP sublayer and higher protocol layers above the BAP sublayer are
described in TS 38.401 [4].
3GPP
Release 16 70 3GPP TS 38.300 V16.21.0 (2020-073)
Beam Level Mobility does not require explicit RRC signalling to be triggered. The gNB provides via RRC signalling
the UE with measurement configuration containing configurations of SSB/CSI resources and resource sets, reports and
trigger states for triggering channel and interference measurements and reports. Beam Level Mobility is then dealt with
at lower layers by means of physical layer and MAC layer control signalling, and RRC is not required to know which
beam is being used at a given point in time.
SSB-based Beam Level Mobility is based on the SSB associated to the initial DL BWP and can only be configured
for the initial DL BWPs and for DL BWPs containing the SSB associated to the initial DL BWP. For other DL BWPs,
Beam Level Mobility can only be performed based on CSI-RS.
9.2.3.2 Handover
3GPP
Release 16 71 3GPP TS 38.300 V16.21.0 (2020-073)
2. Handover Decision
3. HANDOVER REQUEST
4. Admission Control
5. HANDOVER REQUEST
ACKNOWLEDGE
User Data
User Data
End Marker
User Data
http://msc-generator.sourceforge.net v6.3.7
3GPP
Release 16 72 3GPP TS 38.300 V16.21.0 (2020-073)
2. Handover Decision
3. HANDOVER REQUEST
4. Admission Control
5. HANDOVER REQUEST
ACKNOWLEDGE
7. SN STATUS TRANSFER
Detach from old cell
Synchronise to new cell
User Data
End Marker
User Data
0. The UE context within the source gNB contains information regarding roaming and access restrictions which
were provided either at connection establishment or at the last TA update.
1. The source gNB configures the UE measurement procedures and the UE reports according to the measurement
configuration.
2. The source gNB decides to handover the UE, based on MeasurementReport and RRM information.
3. The source gNB issues a Handover Request message to the target gNB passing a transparent RRC container with
necessary information to prepare the handover at the target side. The information includes at least the target cell
ID, KgNB*, the C-RNTI of the UE in the source gNB, RRM-configuration including UE inactive time, basic
AS-configuration including antenna Info and DL Carrier Frequency, the current QoS flow to DRB mapping
rules applied to the UE, the SIB1 from source gNB, the UE capabilities for different RATs, PDU session related
information, and can include the UE reported measurement information including beam-related information if
available. The PDU session related information includes the slice information and QoS flow level QoS profile(s).
The source gNB may also request a DAPS Handover for some DRBs.
3GPP
Release 16 73 3GPP TS 38.300 V16.21.0 (2020-073)
NOTE: After issuing a Handover Request, the source gNB should not reconfigure the UE, including performing
Reflective QoS flow to DRB mapping.
4. Admission Control may be performed by the target gNB. Slice-aware admission control shall be performed if the
slice information is sent to the target gNB. If the PDU sessions are associated with non-supported slices the
target gNB shall reject such PDU Sessions.
5. The target gNB prepares the handover with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE
to the source gNB, which includes a transparent container to be sent to the UE as an RRC message to perform
the handover. The target gNB also indicates if a DAPS Handover is accepted.
NOTE 1: As soon as the source gNB receives the HANDOVER REQUEST ACKNOWLEDGE, or as soon as the
transmission of the handover command is initiated in the downlink, data forwarding may be initiated.
NOTE 2: For DRBs configured with DAPS, downlink PDCP SDUs are forwarded with SN assigned by the source
gNB, until SN assignment is handed over to the target gNB in step 8b, for which the normal data
forwarding follows as defined in 9.2.3.2.3.
6. The source gNB triggers the Uu handover by sending an RRCReconfiguration message to the UE, containing the
information required to access the target cell: at least the target cell ID, the new C-RNTI, the target gNB security
algorithm identifiers for the selected security algorithms. It can also include a set of dedicated RACH resources,
the association between RACH resources and SSB(s), the association between RACH resources and UE-specific
CSI-RS configuration(s), common RACH resources, and system information of the target cell, etc.
NOTE 3: For DRBs configured with DAPS, the source gNB does not stop transmitting downlink packets until it
receives the HANDOVER SUCCESS message from the target gNB in step 8a.
7a. For DRBs configured with DAPS, the The source gNB sends the EARLY STATUS TRANSFER message. The
DL COUNT value conveyed in the EARLY STATUS TRANSFER message indicates PDCP SN and HFN of the
first PDCP SDU that the source gNB forwards to the target gNB. The source gNB does not stop assigning SNs to
downlink PDCP SDUs until it sends the SN STATUS TRANSFER message to the target gNB in step 8b.
7. For DRBs not configured with DAPS, the source gNB sends the SN STATUS TRANSFER message to the target
gNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of DRBs for
which PDCP status preservation applies (i.e. for RLC AM). The uplink PDCP SN receiver status includes at
least the PDCP SN of the first missing UL PDCP SDU and may include a bit map of the receive status of the out
of sequence UL PDCP SDUs that the UE needs to retransmit in the target cell, if any. The downlink PDCP SN
transmitter status indicates the next PDCP SN that the target gNB shall assign to new PDCP SDUs, not having a
PDCP SN yet.
NOTE 4: In case of DAPS Handover, the uplink PDCP SN receiver status and the downlink PDCP SN transmitter
status for a DRB with RLC-AM and not configured with DAPS may be transferred by the SN STATUS
TRANSFER message in step 8b instead of step 7.
NOTE 5: For DRBs configured with DAPS, the source gNB may additionally send the EARLY STATUS
TRANSFER message(s) between step 7 and step 8b, to inform discarding of already forwarded PDCP
SDUs. The target gNB does not transmit forwarded downlink PDCP SDUs to the UE, whose COUNT is
less than the conveyed DL COUNT value and discards them if transmission has not been attempted
already.
8. The UE synchronises to the target cell and completes the RRC handover procedure by sending
RRCReconfigurationComplete message to target gNB. In case of DAPS HO, the UE does not detach from the
source cell upon receiving the RRCReconfiguration message. The UE releases the source SRB resources,
security configuration of the source cell and stops DL/UL reception/transmission with the source upon receiving
an explicit release from the target node.
8a/b In case of DAPS Handover, the target gNB sends the HANDOVER SUCCESS message to the source gNB to
inform that the UE has successfully accessed the target cell. In return, the source gNB sends the SN STATUS
TRANSFER message for DRBs configured with DAPS for which the description in step 7 applies, and the
normal data forwarding follows as defined in 9.2.3.2.3.
NOTE 6: The uplink PDCP SN receiver status and the downlink PDCP SN transmitter status are also conveyed for
DRBs with RLC-UM in the SN STATUS TRANSFER message in step 8b, if configured with DAPS.
3GPP
Release 16 74 3GPP TS 38.300 V16.21.0 (2020-073)
NOTE 7: For DRBs configured with DAPS for which duplication avoidance is required (i.e. RLC-AM), the source
gNB does not stop delivering uplink QoS flows to the UPF until it sends the SN STATUS TRANSFER
message in step 8b. The target gNB does not forward QoS flows of the uplink PDCP SDUs successfully
received in-sequence to the UPF until it receives the SN STATUS TRANSFER message, in which UL
HFN and the first missing SN in the uplink PDCP SN receiver status indicates the start of uplink PDCP
SDUs to be delivered to the UPF. The target gNB does not deliver any uplink PDCP SDUs which has an
UL COUNT lower than the provided.
NOTE 8: The source gNB may omit sending the SN STATUS TRANSFER message if none of DRBs is configured
with DAPS or shall be treated with PDCP status preservation.
9. The target gNB sends a PATH SWITCH REQUEST message to AMF to trigger 5GC to switch the DL data path
towards the target gNB and to establish an NG-C interface instance towards the target gNB.
10. 5GC switches the DL data path towards the target gNB. The UPF sends one or more "end marker" packets on the
old path to the source gNB per PDU session/tunnel and then can release any U-plane/TNL resources towards the
source gNB.
11. The AMF confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST
ACKNOWLEDGE message.
12. Upon reception of the PATH SWITCH REQUEST ACKNOWLEDGE message from the AMF, the target gNB
sends the UE CONTEXT RELEASE to inform the source gNB about the success of the handover. The source
gNB can then release radio and C-plane related resources associated to the UE context. Any ongoing data
forwarding may continue.
The RRM configuration can include both beam measurement information (for layer 3 mobility) associated to SSB(s)
and CSI-RS(s) for the reported cell(s) if both types of measurements are available. Also, if CA is configured, the RRM
configuration can include the list of best cells on each frequency for which measurement information is available. And
the RRM measurement information can also include the beam measurement for the listed cells that belong to the target
gNB.
The common RACH configuration for beams in the target cell is only associated to the SSB(s). The network can have
dedicated RACH configurations associated to the SSB(s) and/or have dedicated RACH configurations associated to
CSI-RS(s) within a cell. The target gNB can only include one of the following RACH configurations in the Handover
Command to enable the UE to access the target cell:
ii) Common RACH configuration + Dedicated RACH configuration associated with SSB;
iii) Common RACH configuration + Dedicated RACH configuration associated with CSI-RS.
The dedicated RACH configuration allocates RACH resource(s) together with a quality threshold to use them. When
dedicated RACH resources are provided, they are prioritized by the UE and the UE shall not switch to contention-based
RACH resources as long as the quality threshold of those dedicated resources is met. The order to access the dedicated
RACH resources is up to UE implementation.
- During HO preparation, U-plane tunnels can be established between the source gNB and the target gNB;
- During HO execution, user data can be forwarded from the source gNB to the target gNB;
- Forwarding should take place in order as long as packets are received at the source gNB from the UPF or the
source gNB buffer has not been emptied.
- During HO completion:
- The target gNB sends a path switch request message to the AMF to inform that the UE has gained access and
the AMF then triggers path switch related 5GC internal signalling and actual path switch of the source gNB
to the target gNB in UPF;
3GPP
Release 16 75 3GPP TS 38.300 V16.21.0 (2020-073)
- The source gNB should continue forwarding data as long as packets are received at the source gNB from the
UPF or the source gNB buffer has not been emptied.
- For in-sequence delivery and duplication avoidance, PDCP SN is maintained on a per DRB basis and the source
gNB informs the target gNB about the next DL PDCP SN to allocate to a packet which does not have a PDCP
sequence number yet (either from source gNB or from the UPF).
- For security synchronisation, HFN is also maintained and the source gNB provides to the target one reference
HFN for the UL and one for the DL i.e. HFN and corresponding SN.
- In both the UE and the target gNB, a window-based mechanism is used for duplication detection and reordering.
- The occurrence of duplicates over the air interface in the target gNB is minimised by means of PDCP SN based
reporting at the target gNB by the UE. In uplink, the reporting is optionally configured on a per DRB basis by
the gNB and the UE should first start by transmitting those reports when granted resources are in the target gNB.
In downlink, the gNB is free to decide when and for which bearers a report is sent and the UE does not wait for
the report to resume uplink transmission.
- The target gNB re-transmits and prioritizes all downlink data forwarded by the source gNB (i.e. the target gNB
should first send all forwarded PDCP SDUs with PDCP SNs, then all forwarded downlink PDCP SDUs without
SNs before sending new data from 5GC), excluding PDCP SDUs for which the reception was acknowledged
through PDCP SN based reporting by the UE.
NOTE: Lossless delivery when a QoS flow is mapped to a different DRB at handover, requires the old DRB to be
configured in the target cell. For in-order delivery in the DL, the target gNB should first transmit the
forwarded PDCP SDUs on the old DRB before transmitting new data from 5GCN on the new DRB. In
the UL, the target gNB should not deliver data of the QoS flow from the new DRB to 5GCN before
receiving the end marker on the old DRB from the UE.
- The UE re-transmits in the target gNB all uplink PDCP SDUs starting from the oldest PDCP SDU that has not
been acknowledged at RLC in the source, excluding PDCP SDUs for which the reception was acknowledged
through PDCP SN based reporting by the target.
- The PDCP SN and HFN are reset in the target gNB, unless the bearer is configured with DAPS Handover;
- The target gNB prioritises all downlink SDAP SDUs forwarded by the source gNB over the data from the core
network;
NOTE: To minimise losses when a QoS flow is mapped to a different DRB at handover, the old DRB needs to be
configured in the target cell. For in-order delivery in the DL, the target gNB should first transmit the
forwarded PDCP SDUs on the old DRB before transmitting new data from 5GCN on the new DRB. In
the UL, the target gNB should not deliver data of the QoS flow from the new DRB to 5GCN before
receiving the end marker on the old DRB from the UE.
- The UE does not retransmit any PDCP SDU in the target cell for which transmission had been completed in the
source cell.
A DAPS Handover can be used for an RLC-AM or RLC-UM bearer. For a DRB configured with DAPS, the following
principles are additionally applied.
Downlink:
- The source gNB is responsible for allocating downlink PDCP SNs until the SN assignment is handed over to the
target gNB and data forwarding in 9.2.3.2.3 takes place. That is, the source gNB does not stop assigning PDCP
SNs to downlink packets until it receives the HANDOVER SUCCESS message and sends the SN STATUS
TRANSFER message to the target gNB.
3GPP
Release 16 76 3GPP TS 38.300 V16.21.0 (2020-073)
- Upon allocation of downlink PDCP SNs by the source gNB, it starts scheduling downlink data on the source
radio link and also starts forwarding downlink PDCP SDUs along with assigned PDCP SNs to the target gNB.
- For security synchronisation, HFN is maintained for the forwarded downlink SDUs with PDCP SNs assigned by
the source gNB. The source gNB sends the EARLY STATUS TRANSFER message to convey the DL COUNT
value, indicating PDCP SN and HFN of the first PDCP SDU that the source gNB forwards to the target gNB.
- HFN and also PDCP SN are maintained after the SN assignment is handed over to the target gNB. The SN
STATUS TRANSFER message indicates the next DL PDCP SN to allocate to a packet which does not have a
PDCP sequence number yet, even for RLC-UM.
- During handover execution period, the source and target gNBs separately perform ROHC header compression,
ciphering, and adding PDCP header.
- During handover execution period, the UE continues to receive downlink data from both source and target gNBs
until the source gNB connection is released by an explicit release command from the target gNB.
- During handover execution period, the UE DAPS PDCP maintains separate security and ROHC header
decompression associated with each gNB, while maintaining common reordering function, duplicate detection,
discard function, and PDCP SDUs in-sequence delivery to upper layers. PDCP SN continuity is supported for
both RLC AM and UM DRBs configured with DAPS.
Uplink:
- The UE transmits UL data to the source gNB until the random access procedure toward the target gNB has been
successfully completed. Afterwards the UE switches its UL data transmission to the target gNB.
- Even after switching its UL data transmissions, the UE continues to send UL layer 1 CSI feedback, HARQ
feedback, layer 2 RLC feedback, ROHC feedback, HARQ data re-transmissions, and RLC data re-transmission
to the source gNB.
- During handover execution period, the UE maintains separate security context and ROHC header compressor
context for uplink transmissions towards the source and target gNBs. The UE maintains common UL PDCP SN
allocation. PDCP SN continuity is supported for both RLC AM and UM DRBs configured with DAPS.
- During handover execution period, the source and target gNBs maintain their own security and ROHC header
decompressor contexts to process UL data received from the UE.
- HFN and PDCP SN are maintained in the target gNB. The SN STATUS TRANSFER message indicates the first
missing UL COUNT that the target should start delivering to the 5GC, even for RLC-UM.
Upon receiving DAPS handover command message, the UE suspends source cell SRBs, stops sending and receiving
any RRC control plane signalling toward the source cell, and establishes SRBs for the target cell. The UE releases the
source cell SRBs configuration upon receiving source cell release indication from the target cell after successful DAPS
handover execution. When DAPS handover to the target cell fails and if the source cell link is available, then the UE
reverts back to the source cell configuration and activate source cell SRBs for control plane signalling.
The source NG-RAN node may suggest downlink data forwarding per QoS flow established for a PDU session and may
provide information how it maps QoS flows to DRBs. The target NG-RAN node decides data forwarding per QoS flow
established for a PDU Session.
If "lossless handover" is required and the QoS flows to DRB mapping applied at the target NG-RAN node allows
applying for data forwarding the same QoS flows to DRB mapping as applied at the source NG-RAN node for a DRB
and if all QoS flows mapped to that DRB are accepted for data forwarding, the target NG-RAN node establishes a
downlink forwarding tunnel for that DRB.
For a DRB for which preservation of SN status applies, the target NG-RAN node may decide to establish an UL data
forwarding tunnel.
3GPP
Release 16 77 3GPP TS 38.300 V16.21.0 (2020-073)
The target NG-RAN node may also decide to establish a downlink forwarding tunnel for each PDU session. In this case
the target NG-RAN node provides information for which QoS flows data forwarding has been accepted and
corresponding UP TNL information for data forwarding tunnels to be established between the source NG-RAN node
and the target NG-RAN node.
If QoS flows have been re-mapped at the source NG-RAN node and user packets along the old source mapping are still
being processed at handover preparation, and if the source NG-RAN node has not yet received the SDAP end marker
for certain QoS flows when providing the SN status to the target NG-RAN node, the source NG-RAN node provides the
old side QoS mapping information for UL QoS flows to the target NG-RAN node for which no SDAP end marker was
yet received. The target NG-RAN will receive for those QoS flows the end marker when the UE finalises to send UL
user data according to the old source side mapping.
The source NG-RAN node may also propose to establish uplink forwarding tunnels for some PDU sessions in order to
transfer SDAP SDUs corresponding to QoS flows for which flow re-mapping happened before the handover and the
SDAP end marker has not yet been received, and for which user data was received at the source NG-RAN node via the
DRB to which the QoS flow was remapped. If accepted the target NG-RAN node shall provide the corresponding UP
TNL information for data forwarding tunnels to be established between the source NG-RAN node and the target NG-
RAN node.
As long as data forwarding of DL user data packets takes place, the source NG-RAN node shall forward user data in the
same forwarding tunnel, i.e.
- for any QoS flow accepted for data forwarding by the target NG-RAN node and for which a DRB DL
forwarding tunnel was established for a DRB to which this QoS flow was mapped at the source NG-RAN node,
any fresh packets of this QoS flow shall be forwarded as PDCP SDUs via the mapped DRB DL forwarding
tunnel.
- for DRBs for which preservation of SN status applies, the source NG-RAN node may forward in order to the
target NG-RAN node via the DRB DL forwarding tunnel all downlink PDCP SDUs with their SN corresponding
to PDCP PDUs which have not been acknowledged by the UE.
NOTE: The SN of forwarded PDCP SDUs is carried in the "PDCP PDU number" field of the GTP-U extension
header.
- for any QoS flow accepted for data forwarding by the target NG-RAN node for which a DL PDU session
forwarding tunnel was established, the source NG-RAN node forwards SDAP SDUs as received on NG-U from
the UPF.
As long as data forwarding of UL user data packets takes place for DRBs for which preservation of SN status applies
the source NG-RAN node either:
- discards the uplink PDCP PDUs received out of sequence if the source NG-RAN node has not accepted the
request from the target NG-RAN node for uplink forwarding or if the target NG-RAN node has not requested
uplink forwarding for the bearer during the Handover Preparation procedure; or
- forwards to the target NG-RAN node via the corresponding DRB UL forwarding tunnel, the uplink PDCP SDUs
with their SN corresponding to PDCP PDUs received out of sequence if the source NG-RAN node has accepted
the request from the target NG-RAN node for uplink forwarding for the bearer during the Handover Preparation
procedure, including PDCP SDUs corresponding to user data of those QoS flows, for which re-mapping
happened for a QoS flow before the handover and the SDAP end marker has not yet been received at the source
NG-RAN node.
As long as data forwarding of UL user data packets takes place for a PDU session, the source NG-RAN node forwards
via the corresponding PDU session UL forwarding tunnel, the uplink SDAP SDUs corresponding to QoS flows for
which flow re-mapping happened before the handover and the SDAP end marker has not yet been received at the source
NG-RAN node, and which were received at the source NG-RAN node via the DRB to which the QoS flow was
remapped.
Data forwarding after the source gNB receives the HANDOVER SUCCESS message from the target gNB follows the
same behaviors as described above.
3GPP
Release 16 78 3GPP TS 38.300 V16.21.0 (2020-073)
- The source gNB may forward to the target gNB downlink PDCP SDUs with SNs assigned by the source gNB.
No downlink PDCP SDU without a SN assigned or SDAP SDU is forwarded. No uplink PDCP SDU or SDAP
SDU is forwarded.
- The source gNB sends the EARLY STATUS TRANSFER message to maintain HFN continuity by indicating
PDCP SN and HFN of the first PDCP SDU that the source gNB forwards to the target gNB. The subsequent
messages may be sent for discarding of already forwarded downlink PDCP SDUs in the target gNB.
- The source gNB does not stop transmitting downlink packets to the UE. The source gNB keeps forwarding to the
5GC the uplink SDAP SDUs successfully received in-sequence from the UE.
- The source NG-RAN node receives one or several GTP-U end marker packets per PDU session from the UPF
and replicates the end marker packets into each data forwarding tunnel when no more user data packets are to be
forwarded over that tunnel.
- End marker packets sent via a data forwarding tunnel are applicable to all QoS flows forwarded via that tunnel.
After end marker packets have been received over a forwarding tunnel, the target NG-RAN node can start taking
into account the packets of QoS flows associated with that forwarding tunnel received at the target NG-RAN
node from the NG-U PDU session tunnel.
The following figure describes the re-establishment procedure started by the UE:
UE in RRC_CONNECTED
CM-CONNECTED
1. RRCReestablishmentRequest
4. RRCReestablishment
5. RRCReconfiguration
4a. RRCReestablishmentComplete
5a. RRCReconfigurationComplete
7. SN STATUS TRANSFER
1. The UE re-establishes the connection, providing the UE Identity (PCI+C-RNTI) to the gNB where the trigger for
the re-establishment occurred.
3GPP
Release 16 79 3GPP TS 38.300 V16.21.0 (2020-073)
2. If the UE Context is not locally available, the gNB, requests the last serving gNB to provide UE Context data.
4/4a. The gNB continues the re-establishment of the RRC connection. The message is sent on SRB1.
5/5a. The gNB may perform the reconfiguration to re-establish SRB2 and DRBs when the re-establishment
procedure is ongoing.
6/7. If loss of user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding
addresses, and the last serving gNB provides the SN status to the gNB.
10. The gNB triggers the release of the UE resources at the last serving gNB.
The IAB-MT in SA mode follows the same re-establishment procedure as described for the UE. After the backhaul has
been established, the re-establishment procedure of the IAB-MT is part of the intra-CU backhaul RLF recovery
procedure for IAB-nodes defined in TS 38.401 [4]. Modifications to the configuration of BAP sublayer and higher
protocol layers above the BAP sublayer are described in TS 38.401 [4].
9.2.3.4.1 General
A Conditional Handover (CHO) is defined as a handover that is executed by the UE when one or more handover
execution conditions are met. The UE starts evaluating the execution condition(s) upon receiving the CHO
configuration, and stops evaluating the execution condition(s) once a handover is executed (legacy handover or
conditional handover execution)the execution condition(s) is met.
- The CHO configuration contains the configuration of CHO candidate cell(s) generated by the candidate gNB(s)
and execution condition(s) generated by the source gNB.
- An execution condition may consist of one or two trigger condition(s) (CHO events A3/A5, as defined in [12]).
Only single RS type is supported and at most two different trigger quantities (e.g. RSRP and RSRQ, RSRP and
SINR, etc.) can be configured simultaneously for the evalution of CHO execution condition of a single candidate
cell.
- Before any CHO execution condition is satisfied, upon reception of HO command (without CHO configuration),
the UE executes the HO procedure as described in clause 9.2.3.2, regardless of any previously received CHO
configuration.
- While executing CHO, i.e. from the time when the UE starts synchronization with target cell, UE does not
monitor source cell.
CHO is not supported for NG-C based handover in this release of the specification.
3GPP
Release 16 80 3GPP TS 38.300 V16.21.0 (2020-073)
2. CHO Decision
3. HANDOVER REQUEST
3. HANDOVER REQUEST
4. Admission Control
4. Admission Control
5. HANDOVER REQUEST
ACKNOWLEDGE
6. RRCReconfiguration
7. RRCReconfigurationComplete
User Data
http://msc-generator.sourceforge.net v6.3.7
3GPP
Release 16 81 3GPP TS 38.300 V16.21.0 (2020-073)
2. CHO Decision
3. HANDOVER REQUEST
3. HANDOVER REQUEST
4. Admission Control
4. Admission Control
5. HANDOVER REQUEST
ACKNOWLEDGE
5. HANDOVER REQUEST
ACKNOWLEDGE
6. RRCReconfiguration
7. RRCReconfigurationComplete
3. The source gNB requests CHOissues a Handover Request message to one or more candidate gNBs. A CHO
request message is sent for each candidate cell.
5. The candidate gNB(s) sends CHO responseHANDOVER REQUEST ACKNOWLEDGE message including
configuration of CHO candidate cell(s) to the source gNB. The response message is also sent for each candidate
cell.
6. The source gNB sends an RRCReconfiguration message to the UE, containing the configuration of CHO
candidate cell(s) and CHO execution condition(s).
NOTE 1: CHO configuration of candidate cells can be followed by other reconfiguration from the source gNB.
7a If early data forwarding is applied, the source gNB sends the EARLY STATUS TRANSFER message.
8. The UE maintains connection with the source gNB after receiving CHO configuration, and starts evaluating the
CHO execution conditions for the candidate cell(s). If at least one CHO candidate cell satisfies the corresponding
3GPP
Release 16 82 3GPP TS 38.300 V16.21.0 (2020-073)
CHO execution condition, the UE detaches from the source gNB, applies the stored corresponding configuration
for that selected candidate cell, synchronises to that candidate cell and completes the RRC handover procedure
by sending RRCReconfigurationComplete message to the target gNB. The UE releases stored CHO
configurations after successful completion of RRC handover procedure.
8a/b The target gNB sends the HANDOVER SUCCESS message to the source gNB to inform that the UE has
successfully accessed the target cell. In return, the source gNB sends the SN STATUS TRANSFER message.
NOTE 2: Late data forwarding may be initiated as soon as the source gNB receives the HANDOVER SUCCESS
message.
8c. The source gNB sends the HANDOVER CANCEL message toward the other signalling connections or other
potential target gNBs, if any, to cancel CHO for the UE.
If early data forwarding is applied instead, the source NG-RAN node initiates data forwarding before the UE executes
the handover, to a candidate target node of interest. The behavior of early data forwarding for the Conditional Handover
follows the same principles for DRBs configured with DAPS Handver in the intra-system handover as defined in
9.2.3.2.3.
9.2.4 Measurements
In RRC_CONNECTED, the UE measures multiple beams (at least one) of a cell and the measurements results (power
values) are averaged to derive the cell quality. In doing so, the UE is configured to consider a subset of the detected
beams. Filtering takes place at two different levels: at the physical layer to derive beam quality and then at RRC level to
derive cell quality from multiple beams. Cell quality from beam measurements is derived in the same way for the
serving cell(s) and for the non-serving cell(s). Measurement reports may contain the measurement results of the X best
beams if the UE is configured to do so by the gNB.
3GPP
Release 16 83 3GPP TS 38.300 V16.21.0 (2020-073)
RRC configures
RRC configures RRC configures
parameters
parameters parameters
UE
UE Implementation
Implementation
specific
specific
A A1
gNB beam 1 Layer1 filtering C
Beam B Layer 3 Evaluation of
gNB beam 2 Layer1 filtering D
Consolidation/ filtering for cell reporting
Cell quality 1
Selection quality C criteria
gNB beam K Layer1 filtering
K beams
K beams L3 Beam filtering
L3 Beam filtering Beam Selection X beams
for reporting
L3 Beam filtering
E F
NOTE: K beams correspond to the measurements on SSB or CSI-RS resources configured for L3 mobility by
gNB and detected by UE at L1.
- Layer 1 filtering: internal layer 1 filtering of the inputs measured at point A. Exact filtering is implementation
dependent. How the measurements are actually executed in the physical layer by an implementation (inputs A
and Layer 1 filtering) in not constrained by the standard.
- A1: measurements (i.e. beam specific measurements) reported by layer 1 to layer 3 after layer 1 filtering.
- Beam Consolidation/Selection: beam specific measurements are consolidated to derive cell quality. The
behaviour of the Beam consolidation/selection is standardised and the configuration of this module is provided
by RRC signalling. Reporting period at B equals one measurement period at A1.
- B: a measurement (i.e. cell quality) derived from beam-specific measurements reported to layer 3 after beam
consolidation/selection.
- Layer 3 filtering for cell quality: filtering performed on the measurements provided at point B. The behaviour
of the Layer 3 filters is standardised and the configuration of the layer 3 filters is provided by RRC signalling.
Filtering reporting period at C equals one measurement period at B.
- C: a measurement after processing in the layer 3 filter. The reporting rate is identical to the reporting rate at point
B. This measurement is used as input for one or more evaluation of reporting criteria.
- Evaluation of reporting criteria: checks whether actual measurement reporting is necessary at point D. The
evaluation can be based on more than one flow of measurements at reference point C e.g. to compare between
different measurements. This is illustrated by input C and C1. The UE shall evaluate the reporting criteria at least
every time a new measurement result is reported at point C, C1. The reporting criteria are standardised and the
configuration is provided by RRC signalling (UE measurements).
- L3 Beam filtering: filtering performed on the measurements (i.e. beam specific measurements) provided at
point A1. The behaviour of the beam filters is standardised and the configuration of the beam filters is provided
by RRC signalling. Filtering reporting period at E equals one measurement period at A1.
- E: a measurement (i.e. beam-specific measurement) after processing in the beam filter. The reporting rate is
identical to the reporting rate at point A1. This measurement is used as input for selecting the X measurements to
be reported.
3GPP
Release 16 84 3GPP TS 38.300 V16.21.0 (2020-073)
- Beam Selection for beam reporting: selects the X measurements from the measurements provided at point E.
The behaviour of the beam selection is standardised and the configuration of this module is provided by RRC
signalling.
- F: beam measurement information included in measurement report (sent) on the radio interface.
Layer 1 filtering introduces a certain level of measurement averaging. How and when the UE exactly performs the
required measurements is implementation specific to the point that the output at B fulfils the performance requirements
set in TS 38.133 [13]. Layer 3 filtering for cell quality and related parameters used are specified in TS 38.331 [12] and
do not introduce any delay in the sample availability between B and C. Measurement at point C, C1 is the input used in
the event evaluation. L3 Beam filtering and related parameters used are specified in TS 38.331 [12] and do not
introduce any delay in the sample availability between E and F.
- Measurement reports include the measurement identity of the associated measurement configuration that
triggered the reporting;
- Cell and beam measurement quantities to be included in measurement reports are configured by the network;
- The number of non-serving cells to be reported can be limited through configuration by the network;
- Cells belonging to a blacklist configured by the network are not used in event evaluation and reporting, and
conversely when a whitelist is configured by the network, only the cells belonging to the whitelist are used in
event evaluation and reporting;
- Beam measurements to be included in measurement reports are configured by the network (beam identifier only,
measurement result and beam identifier, or no beam reporting).
Intra-frequency neighbour (cell) measurements and inter-frequency neighbour (cell) measurements are defined as
follows:
NOTE: For SSB based measurements, one measurement object corresponds to one SSB and the UE considers
different SSBs as different cells.
Whether a measurement is non-gap-assisted or gap-assisted depends on the capability of the UE, the active BWP of the
UE and the current operating frequency:
- For SSB based inter-frequency measurement, if the measurement gap requirement information is reported by the
UE, a measurement gap configuration may be provided according to the information. Otherwise, a measurement
gap configuration is always provided in the following cases:
- If the UE supports per-FR measurement gaps and any of the serving cells are in the same frequency range of
the measurement object.
3GPP
Release 16 85 3GPP TS 38.300 V16.21.0 (2020-073)
- For SSB based intra-frequency measurement, if the measurement gap requirement information is reported by the
UE, a measurement gap configuration may be provided according to the information. Otherwise, a measurement
gap configuration is always provided in the following case:
- Other than the initial BWP, if any of the UE configured BWPs do not contain the frequency domain
resources of the SSB associated to the initial DL BWP.
In non-gap-assisted scenarios, the UE shall be able to carry out such measurements without measurement gaps. In gap-
assisted scenarios, the UE cannot be assumed to be able to carry out such measurements without measurement gaps.
Network may request the UE to measure NR and/or E-UTRA carriers in RRC_IDLE or RRC_INACTIVE via system
information or via dedicated measurement configuration in RRCRelease. If the UE was configured to perform
measurements of NR and/or E-UTRA carriers while in RRC_IDLE, it may provide an indication of the availability of
corresponding measurement results to the gNB in the RRCSetupComplete message. The network may request the UE to
report those measurements after security activation. The request for the measurements can be sent by the network
immediately after transmitting the Security Mode Command (i.e. before the reception of the Security Mode Complete
from the UE).
If the UE was configured to perform measurements of NR and/or E-UTRA carriers while in RRC_INACTIVE, the gNB
can request the UE to provide corresponding measurement results in the RRCResume message and then the UE can
include the available measurement results in the RRCResumeComplete message. Alternatively, the UE may provide an
indication of the availability of the measurement results to the gNB in the RRCResumeComplete message and the gNB
can then request the UE to provide these measurement results.
9.2.5 Paging
Paging allows the network to reach UEs in RRC_IDLE and in RRC_INACTIVE state through Paging messages, and to
notify UEs in RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED state of system information change (see clause
7.3.3) and ETWS/CMAS indications (see clause 16.4) through Short Messages. Both Paging messages and Short
Messages are addressed with P-RNTI on PDCCH, but while the former is sent on PCCH, the latter is sent over PDCCH
directly (see clause 6.5 of TS 38.331 [12]).
While in RRC_IDLE the UE monitors the paging channels for CN-initiated paging; in RRC_INACTIVE the UE also
monitors paging channels for RAN-initiated paging. A UE need not monitor paging channels continuously though;
Paging DRX is defined where the UE in RRC_IDLE or RRC_INACTIVE is only required to monitor paging channels
during one Paging Occasion (PO) per DRX cycle (see TS 38.304 [10]). The Paging DRX cycles are configured by the
network:
2) For CN-initiated paging, a UE specific cycle can be configured via NAS signalling;
- The UE uses the shortest of the DRX cycles applicable i.e. a UE in RRC_IDLE uses the shortest of the first two
cycles above, while a UE in RRC_INACTIVE uses the shortest of the three.
The POs of a UE for CN-initiated and RAN-initiated paging are based on the same UE ID, resulting in overlapping POs
for both. The number of different POs in a DRX cycle is configurable via system information and a network may
distribute UEs to those POs based on their IDs.
When in RRC_CONNECTED, the UE monitors the paging channels in any PO signalled in system information for SI
change indication and PWS notification. In case of BA, a UE in RRC_CONNECTED only monitors paging channels on
the active BWP with common search space configured.
For operation with shared spectrum channel access, a UE can be configured for an additional number of PDCCH
monitoring occasions in its PO to monitor for paging. However, when the UE detects a PDCCH transmission within the
UE’s PO addressed with P-RNTI, the UE is not required to monitor the subsequent PDCCH monitoring occasions
within this PO.
Paging optimization for UEs in CM_IDLE: at UE context release, the NG-RAN node may provide the AMF with a
list of recommended cells and NG-RAN nodes as assistance info for subsequent paging. The AMF may also provide
Paging Attempt Information consisting of a Paging Attempt Count and the Intended Number of Paging Attempts and
may include the Next Paging Area Scope. If Paging Attempt Information is included in the Paging message, each paged
3GPP
Release 16 86 3GPP TS 38.300 V16.21.0 (2020-073)
NG-RAN node receives the same information during a paging attempt. The Paging Attempt Count shall be increased by
one at each new paging attempt. The Next Paging Area Scope, when present, indicates whether the AMF plans to
modify the paging area currently selected at next paging attempt. If the UE has changed its state to CM CONNECTED
the Paging Attempt Count is reset.
Paging optimization for UEs in RRC_INACTIVE: at RAN Paging, the serving NG-RAN node provides RAN Paging
area information. The serving NG-RAN node may also provide RAN Paging attempt information. Each paged NG-
RAN node receives the same RAN Paging attempt information during a paging attempt with the following content:
Paging Attempt Count, the intended number of paging attempts and the Next Paging Area Scope. The Paging Attempt
Count shall be increased by one at each new paging attempt. The Next Paging Area Scope, when present, indicates
whether the serving NG_RAN node plans to modify the RAN Paging Area currently selected at next paging attempt. If
the UE leaves RRC_INACTIVE state the Paging Attempt Count is reset.
- UL data arrival during RRC_CONNECTED when there are no PUCCH resources for SR available;
- SR failure;
Two types of random access procedure are supported: 4-step RA type with MSG1 and 2-step RA type with MSGA.
Both types of RA procedure support contention-based random access (CBRA) and contention-free random access
(CFRA) as shown on Figure 9.2.6-1 below.
The UE selects the type of random access at initiation of the random access procedure based on network configuration:
- when CFRA resources are not configured, an RSRP threshold is used by the UE to select between 2-step RA
type and 4-step RA type;
- when CFRA resources for 4-step RA type are configured, UE performs random access with 4-step RA type;
- when CFRA resources for 2-step RA type are configured, UE performs random access with 2-step RA type.
The network does not configure CFRA resources for 4-step and 2-step RA types at the same time for a Bandwidth Part
(BWP). CFRA with 2-step RA type is only supported for handover.
The MSG1 of the 4-step RA type consists of a preamble on PRACH. After MSG1 transmission, the UE monitors for a
response from the network within a configured window. For CFRA, dedicated preamble for MSG1 transmission is
assigned by the network and upon receiving random access response from the network, the UE ends the random access
procedure as shown in Figure 9.2.6-1(c). For CBRA, upon reception of the random access response, the UE sends
MSG3 using the UL grant scheduled in the response and monitors contention resolution as shown in Figure 9.2.6-1(a).
If contention resolution is not successful after MSG3 (re)transmission(s), the UE goes back to MSG1 transmission.
The MSGA of the 2-step RA type includes a preamble on PRACH and a payload on PUSCH. After MSGA
transmission, the UE monitors for a response from the network within a configured window. For CFRA, dedicated
preamble and PUSCH resource are configured for MSGA transmission and upon receiving the network response, the
UE ends the random access procedure as shown in Figure 9.2.6-1(d). For CBRA, if contention resolution is successful
3GPP
Release 16 87 3GPP TS 38.300 V16.21.0 (2020-073)
upon receiving the network response, the UE ends the random access procedure as shown in Figure 9.2.6-1(b); while if
fallback indication is received in MSGB, the UE performs MSG3 transmission using the UL grant scheduled in the
fallback indication and monitors contention resolution as shown in Figure 9.2.6-2. If contention resolution is not
successful after MSG3 (re)transmission(s), the UE goes back to MSGA transmission.
If the random access procedure with 2-step RA type is not completed after a number of MSGA transmissions, the UE
can be configured to switch to CBRA with 4-step RA type.
UE gNB
UE gNB
Random Access Response 2
Random Access Preamble
A
PUSCH payload
3 Scheduled Transmission
Contention Resolution B
Contention Resolution 4
(a) CBRA with 4-step RA type (b) CBRA with 2-step RA type
UE gNB UE gNB
(c) CFRA with 4-step RA type (d) CFRA with 2-step RA type
For random access in a cell configured with SUL, the network can explicitly signal which carrier to use (UL or SUL).
Otherwise, the UE selects the SUL carrier if and only if the measured quality of the DL is lower than a broadcast
threshold. UE performs carrier selection before selecting between 2-step and 4-step RA type. The RSRP threshold for
selecting between 2-step and 4-step RA type can be configured separately for UL and SUL. Once started, all uplink
transmissions of the random access procedure remain on the selected carrier.
When CA is configured, random access procedure with 2-step RA type is only performed on PCell while contention
resolution can be cross-scheduled by the PCell.
When CA is configured, for random access procedure with 4-step RA type, the first three steps of CBRA always occur
on the PCell while contention resolution (step 4) can be cross-scheduled by the PCell. The three steps of a CFRA started
on the PCell remain on the PCell. CFRA on SCell can only be initiated by the gNB to establish timing advance for a
secondary TAG: the procedure is initiated by the gNB with a PDCCH order (step 0) that is sent on a scheduling cell of
an activated SCell of the secondary TAG, preamble transmission (step 1) takes place on the indicated SCell, and
Random Access Response (step 2) takes place on PCell.
3GPP
Release 16 88 3GPP TS 38.300 V16.21.0 (2020-073)
SSB associated to the initial DL BWP. For other DL BWPs, RLM can only be performed based on CSI-RS. In case of
DAPS handover, the UE continues the RLM at the source cell until the successful completion of the random access
procedure to the target cell.
The UE declares Radio Link Failure (RLF) when one of the following criteria are met:
- Expiry of a radio problem timer started after indication of radio problems from the physical layer (if radio
problems are recovered before the timer is expired, the UE stops the timer); or
- Expiry of a timer started upon triggering a measurement report for a measurement identity for which the timer
has been configured while another radio problem timer is running; or
- RLC failure; or
- Detection of consistent uplink LBT failures for operation with shared spectrum channel access as described in
5.6.1; or.
- For IAB-MT, the reception of BH RLF indication received from its parent node.
- stays in RRC_CONNECTED;
- stops any data transmission or reception via the source link and releases the source link, but maintains the
source RRC configuration;
- enters RRC_IDLE if a suitable cell was not found within a certain time after handover failure was
declared.
- selects a suitable cell and if the selected cell is a CHO candidate and if network configured the UE to try
CHO after RLF then the UE attempts CHO execution once, otherwise re-establishment is performed;
- enters RRC_IDLE if a suitable cell was not found within a certain time after RLF was declared.
- enters RRC_IDLE if a suitable cell was not found within a certain time after RLF was declared.
- stays in RRC_CONNECTED;
- stops any data transmission or reception via the source link and releases the source link, but maintains the source
RRC configuration;
In case of DAPS handover, when handover failure is declared at the target cell after source cell RLF was declared, the
UE:
- stays in RRC_CONNECTED;
- enters RRC_IDLE if a suitable cell was not found within a certain time after handover failure was declared.
3GPP
Release 16 89 3GPP TS 38.300 V16.21.0 (2020-073)
- stays in RRC_CONNECTED;
- selects a suitable cell and if the selected cell is a CHO candidate and if network configured the UE to try CHO
after RLF then the UE attempts CHO execution once, otherwise re-establishment is performed;
- enters RRC_IDLE if a suitable cell was not found within a certain time after RLF was declared.
When RLF occurs at the IAB BH link, the same mechanisms and procedures are applied as for the access link. This
includes BH RLF detection and RLF recovery using RRC reestablishment procedure.
In case the RRC reestablishment procedure fails, the IAB-node may transmit an BH RLF indication to its child nodes.
The BH RLF indication is transmitted as BAP Control PDU.
For IAB-nodes operating in SA-mode, the IAB-node may transmit an RLF notification message to its child nodes in
case the RRC reestablishment procedure to recover the BH link fails. The child node considers the BH link, on which it
has received the RLF notification as failed (i.e. as if it has detected RLF on that BH link). The RLF notification
message is transmitted on BAP layer.
SSB-based Beam Failure Detection is based on the SSB associated to the initial DL BWP and can only be configured
for the initial DL BWPs and for DL BWPs containing the SSB associated to the initial DL BWP. For other DL BWPs,
Beam Failure Detection can only be performed based on CSI-RS.
- triggers beam failure recovery by initiating a Random Access procedure on the PCell;
- selects a suitable beam to perform beam failure recovery (if the gNB has provided dedicated Random Access
resources for certain beams, those will be prioritized by the UE).
Upon completion of the Random Access procedure, beam failure recovery is considered complete.
For the primary TAG the UE uses the PCell as timing reference, except with shared spectrum channel access where an
SCell can also be used in certain cases (see clause 7.1, TS 38.133 [13]). In a secondary TAG, the UE may use any of the
activated SCells of this TAG as a timing reference cell, but should not change it unless necessary.
Timing advance updates are signalled by the gNB to the UE via MAC CE commands. Such commands restart a TAG-
specific timer which indicates whether the L1 can be synchronised or not: when the timer is running, the L1 is
considered synchronised, otherwise, the L1 is considered non-synchronised (in which case uplink transmission can only
take place on PRACH).
3GPP
Release 16 90 3GPP TS 38.300 V16.21.0 (2020-073)
9.3.1.2 Handover
Inter RAT mobility is characterised by the following:
- The source RAT decides on the preparation initiation and provides the necessary information to the target RAT
in the format required by the target RAT:
- For handover preparation from E-UTRA to NR, the source RAT issues a handover preparation request
message to the target RAT passing a transparent RRC container with necessary information to prepare the
handover at the target side. The information for the target RAT is the same type as specified in section
9.2.3.2.1 including the current QoS flow to DRB mapping applied to the UE and RRM configuration.
- The details of RRM configuration are the same type as specified for NR in section 9.2.3.2.1 including beam
measurement information for the listed cells if the measurements are available.
- Radio resources are prepared in the target RAT before the handover.
- The RRC reconfiguration message from the target RAT is delivered to the source RAT via a transparent
container, and is passed to the UE by the source RAT in the handover command:
- The inter-RAT handover command message carries the same type of information required to access the target
cell as specified for NR baseline handover in section 9.2.3.2.1.
- The in-sequence and lossless handover is supported for the handover between gNB and ng-eNB.
- Both Xn and NG based inter-RAT handover between NG-RAN nodes is supported. Whether the handover is
over Xn or CN is transparent to the UE.
- In order to keep the SDAP and PDCP configurations for in-sequence and lossless inter-RAT handover, delta-
configuration for the radio bearer configuration is used.
9.3.1.3 Measurements
Inter RAT measurements in NR for this use case are limited to E-UTRA.
For a UE configured with E-UTRA Inter RAT measurements, a measurement gap configuration is always provided
when:
- The UE supports per-FR measurement gaps and at least one of the NR serving cells is in FR1.
3GPP
Release 16 91 3GPP TS 38.300 V16.21.0 (2020-073)
NOTE: Information about the availability of the N26 interface may be configured by OAM at the NG-RAN.
- The source RAT decides on the preparation initiation and provides the necessary information to the target RAT
in the format required by the target RAT.
- Radio resources are prepared in the target RAT before the handover.
- The RRC reconfiguration message from the target RAT is delivered to the source RAT via a transparent
container, and is passed to the UE by the source RAT in the handover command.
- Security procedures for handover to E-UTRA/EPC should follow legacy inter-RAT handover procedures.
9.3.2.3 Measurements
Inter RAT measurements in NR for this use case are limited to E-UTRA.
For a UE configured with E-UTRA Inter RAT measurements, a measurement gap configuration is always provided
when:
- The UE supports per-FR measurement gaps and at least one of the NR serving cells is in FR1.
- PDU session information at the serving NG-RAN node contains mapping information per QoS Flow to a
corresponding E-RAB.
- At handover preparation, the source NG-RAN node shall decide which mapped E-RABs are proposed to be
subject to data forwarding and provide this information in the source-to-target container to the target eNB. Based
on availability of direct data forwarding path the source NG-RAN node may request to apply direct data
forwarding by indicating direct data forwarding path availability to the 5GC.
- The target eNB assigns forwarding TEID/TNL address(es) for the E-RAB(s) for which it accepts data
forwarding.
- In case of indirect data forwarding, a single data forwarding tunnel is established between the source NG-RAN
node and UPF per PDU session for which at least data for a single QoS Flow is subject to data forwarding.
- In case of direct data forwarding, the source NG-RAN node receives a TEID/TNL address for each E-RAB
accepted for data forwarding as assigned by the target eNB.
- For the QoS flows accepted for data forwarding, the NG-RAN node initiates data forwarding to the UPF by the
corresponding PDU session data forwarding tunnel(s).
- The UPF maps forwarded data received from the per PDU session data forwarding tunnel(s) to the mapped EPS
bearer(s) removing the QFI.
3GPP
Release 16 92 3GPP TS 38.300 V16.21.0 (2020-073)
- The source NG-RAN node receives one or several end marker packets per PDU session from the UPF. When
there are no more data packets to be forwarded for QoS flows mapped to an E-RAB, the source NG-RAN
node sends one or several end markers including one QFI (by means of the PDU Session User Plane protocol
TS 38.415 [30]) of those QoS flows mapped to that E-RAB and sends the end marker packets to the UPF
over the PDU session tunnel. From the included QFI in the end markers and its mapping to an EPS bearer ID,
the UPF knows which EPS bearer tunnel it needs to forward the end-markers to the SGW. The QFI is
removed in the end marker packets sent to the SGW.
In case of direct data forwarding, user plane handling for inter-System data forwarding from 5GS to EPS follows the
following key principles:
- For the QoS flows accepted for data forwarding, the source NG-RAN node maps data received from the NG-U
PDU session tunnel to the respective E-RAB data forwarding tunnel and forwards each user packet as PDCP
SDU without PDCP SN and QFI information.
- The source NG-RAN node receives one or several GTP-U end marker packets per PDU session from the UPF
and replicates the end marker packets into each E-RAB data forwarding tunnel when no more user data packets
are to be forwarded over that tunnel.
- The target NG-RAN node receives in the Handover Request message the mapping between E-RAB ID(s) and
QoS Flow ID(s). It decides whether to accept the data forwarding for E-RAB IDs proposed for forwarding
within the Source NG-RAN Node to Target NG-RAN Node Transparent Container. Based on availability of
direct data forwarding path the source eNB may request to apply direct data forwarding by indicating direct data
forwarding availability to the CN.
- The target NG-RAN node assigns a TEID/TNL address for each PDU session for which at least one QoS
flow is involved in the accepted data forwarding.
- The target NG-RAN node sends the Handover Request Acknowledge message in which it indicates the list of
PDU sessions and QoS flows for which it has accepted the data forwarding.
- A single data forwarding tunnel is established between the UPF and the target NG-RAN node per PDU
session for which at least data for a single QoS Flow is subject to data forwarding.
- The source eNB receives in the Handover Command message the list of E-RAB IDs for which the target NG-
RAN node has accepted data forwarding of corresponding PDU sessions and QoS flows.
- The source eNB indicates direct path availability to the CN. The source eNB’s decision is indicated by the
CN to the target NG-RAN node.
- The target NG-RAN node assigns a TEID/TNL address for each E-RAB it accepted for data forwarding.
- The source eNB receives in the Handover Command message the list of E-RAB IDs for which the target NG-
RAN node has accepted data forwarding.
3GPP
Release 16 93 3GPP TS 38.300 V16.21.0 (2020-073)
- For each E-RAB accepted for data forwarding, the source eNB forwards data to the SGW in the corresponding
E-RAB tunnel and the SGW forwards the received data to the UPF in the E-RAB tunnel.
- The UPF maps the forwarded data received from an E-RAB tunnel to the corresponding mapped PDU session
tunnel, adding a QFI value (by means of the PDU Session User Plane protocol TS 38.415 [30]).
- The target NG-RAN node maps a forwarded packet to the corresponding DRB based on the received QFI value.
It prioritizes the forwarded packets over the fresh packets for those QoS flows.
- The UPF/PGW-U sends one or several end marker packets to the SGW per EPS bearer. The SGW forwards
the received end markers per EPS bearer to the source eNB. When there are no more data packets to be
forwarded for an E-RAB, the source eNB forwards the received end markers in the EPS bearer tunnel to the
SGW and the SGW forwards them to the UPF. The UPF adds one QFI (by means of the PDU Session User
Plane protocol TS 38.415 [30]) among the QoS flows mapped to that E-RAB to the end markers and sends
those end markers to the target NG-RAN node in the per PDU session tunnel. When the target NG-RAN
node receives an end marker with a QFI added, the target NG-RAN node starts to transmit the data packets of
all QoS flows mapped to the corresponding E-RAB received from the core network towards the UE.
In case of direct data forwarding, user plane handling for inter-System data forwarding from EPS to 5GS follows the
following key principles:
- For each E-RAB accepted for data forwarding, the source eNB forwards data to the target NG-RAN node in the
corresponding E-RAB data forwarding tunnel.
- Until a GTP-U end marker packet is received, the target NG-RAN node prioritizes the forwarded packets over
the fresh packets for those QoS flows which are involved in the accepted data forwarding.
- The source NR node determines based on the radio conditions and the indication that SRVCC operation is
possible that handover to UTRAN should be initiated;
- The source NR node initiates the handover preparation only for the ongoing IMS voice and provides the
indication to AMF that the handover is towards UTRAN together with the target UTRAN Node ID. The source
NR node also provides an indication to the target UTRAN that the incoming handover originates from 5G. The
SRVCC proceeds as specified in TS 23.216 [34];
- Radio resources are prepared in the target RAT before the handover;
- The RRC reconfiguration message from the target RAT is delivered to the source NR node via a transparent
container and is passed to the UE by the source NR node in the handover command;
- Security procedures for handover to UTRA follows the procedures as specified in TS 33.501 [5];
9.3.4.2 Measurements
Inter RAT measurements are performed for UTRA.
3GPP
Release 16 94 3GPP TS 38.300 V16.21.0 (2020-073)
It includes the forbidden RAT, the forbidden area and the service area restrictions as specified in TS 23.501 [3]. It also
includes serving PLMN/SNPN and may include a list of equivalent PLMNs. It may also include PNI-NPN mobility
restrictions (i.e. list of CAGs allowed for the UE and whether the UE can also access PLMN cells).
Upon receiving the roaming and access restriction information for a UE, if applicable, the gNB should use it to
determine whether to apply restriction handling for subsequent mobility action, e.g., handover, redirection.
If the roaming and access restriction information is not available for a UE at the gNB, the gNB shall consider that there
is no restriction for subsequent mobility actions.
Only if received over NG or Xn signalling, the roaming and access restriction information shall be propagated over Xn
by the source gNB during Xn handover. If the Xn handover results in a change of serving PLMN (to an equivalent
PLMN), the source gNB shall replace the serving PLMN with the identity of the target PLMN and move the serving
PLMN to the equivalent PLMN list, before propagating the roaming and access restriction information.
If NG-RAN nodes with different versions of the XnAP or NGAP protocol are deployed, information provided by the
5GC within the NGAP Mobility Restriction List may be lost in the course of Xn mobility. In order to avoid such loss of
information at Xn handover or UE context retrieval due to a source NG-RAN node or an old NG-RAN node not able to
recognise the entire content, the source NG-RAN node or the old NG-RAN node may provide an 5GC Mobility
Restriction List Container to the target NG-RAN node or the new NG-RAN node, containing the Mobility Restriction
List as received from the 5GC. The target NG-RAN node or the new NG-RAN node shall use the information contained
in the 5GC Mobility Restriction List Container as the Mobility Restriction List, except for the Serving PLMN and the
Equivalent PLMNs, which the NG-RAN node shall use from the XnAP Mobility Restriction List. The 5GC Mobility
Restriction List Container may be propagated at future Xn handover and UE context retrieval.
10 Scheduling
Scheduler Operation:
- Taking into account the UE buffer status and the QoS requirements of each UE and associated radio bearers,
schedulers assign resources between UEs;
- Schedulers may assign resources taking account the radio conditions at the UE identified through measurements
made at the gNB and/or reported by the UE;
- Uplink buffer status reports (measuring the data that is buffered in the logical channel queues in the UE) are used
to provide support for QoS-aware packet scheduling;
- Power headroom reports (measuring the difference between the nominal UE maximum transmit power and the
estimated power for uplink transmission) are used to provide support for power aware packet scheduling.
3GPP
Release 16 95 3GPP TS 38.300 V16.21.0 (2020-073)
The gNB may pre-empt an ongoing PDSCH transmission to one UE with a latency-critical transmission to another UE.
The gNB can configure UEs to monitor interrupted transmission indications using INT-RNTI on a PDCCH. If a UE
receives the interrupted transmission indication, the UE may assume that no useful information to that UE was carried
by the resource elements included in the indication, even if some of those resource elements were already scheduled to
this UE.
In addition, with Semi-Persistent Scheduling (SPS), the gNB can allocate downlink resources for the initial HARQ
transmissions to UEs: RRC defines the periodicity of the configured downlink assignments while PDCCH addressed to
CS-RNTI can either signal and activate the configured downlink assignment, or deactivate it; i.e. a PDCCH addressed
to CS-RNTI indicates that the downlink assignment can be implicitly reused according to the periodicity defined by
RRC, until deactivated.
The dynamically allocated downlink reception overrides the configured downlink assignment in the same serving cell,
if they overlap in time. Otherwise a downlink reception according to the configured downlink assignment is assumed, if
activated.
The UE may be configured with up to 8 active configured downlink assignments for a given BWP of a serving cell.
When more than one is configured:
- The network decides which of these configured downlink assignments are active at a time (including all of
them); and
- Each configured downlink assignment is activated separately using a DCI command and deactivation of
configured downlink assignments is done using a DCI command, which can either deactivate a single configured
downlink assignment or multiple configured downlink assignments jointly.
Editor’s note: FFS whether there are other restrictions of how many SPS configurations are supported, e.g. per cell /
per UE.
The gNB may cancel a PUSCH transmission, or a repetition of a PUSCH transmission, or an SRS transmission of a UE
for another UE with a latency-critical transmission. The gNB can configure UEs to monitor cancelled transmission
indications using CI-RNTI on a PDCCH. If a UE receives the cancelled transmission indication, the UE shall cancel the
PUSCH transmission from the earliest symbol overlapped with the resource or the SRS transmission overlapped with
the resource indicated by cancellation (see clause 11.2A of TS 38.213 [38]).
In addition, with Configured Grants, the gNB can allocate uplink resources for the initial HARQ transmissions and
HARQ retransmissions to UEs. Two types of configured uplink grants are defined:
- With Type 1, RRC directly provides the configured uplink grant (including the periodicity).
- With Type 2, RRC defines the periodicity of the configured uplink grant while PDCCH addressed to CS-RNTI
can either signal and activate the configured uplink grant, or deactivate it; i.e. a PDCCH addressed to CS-RNTI
indicates that the uplink grant can be implicitly reused according to the periodicity defined by RRC, until
deactivated.
If the UE is not configured with enhanced intra-UE overlapping resources prioritization, the dynamically allocated
uplink transmission overrides the configured uplink grant in the same serving cell, if they overlap in time. Otherwise an
uplink transmission according to the configured uplink grant is assumed, if activated.
3GPP
Release 16 96 3GPP TS 38.300 V16.21.0 (2020-073)
If the UE is configured with enhanced intra-UE overlapping resources prioritization, in case a configured uplink grant
transmission overlaps in time with dynamically allocated uplink transmission or with another configured uplink grant
transmission in the same serving cell, the UE prioritizes the transmission based on the comparison between the highest
priority of the logical channels that have data to be transmitted and which are multiplexed or can be multiplexed in
MAC PDUs associated with the overlapping resources. Similarly, in case a configured uplink grant transmissions or a
dynamically allocated uplink transmission overlaps in time with a scheduling request transmission, the UE prioritizes
the transmission based on the comparison between the priority of the logical channel which triggered the scheduling
request and the highest priority of the logical channels that have data to be transmitted and which are multiplexed or can
be multiplexed in MAC PDU associated with the overlapping resource. In case the MAC PDU associated with a
deprioritized transmission has already been generated, the UE keeps it stored to allow the gNB to schedule a
retransmission. The UE may also be configured by the gNB to transmit the stored MAC PDU as a new transmission
using a subsequent resource of the same configured uplink grant configuration when an explicit retransmission grant is
not provided by the gNB.
Retransmissions other than repetitions are explicitly allocated via PDCCH(s) or via configuration of a retransmission
timer.
The UE may be configured with up to 12 active configured uplink grants for a given BWP of a serving cell. When more
than one is configured, the network decides which of these configured uplink grants are active at a time (including all of
them). Each configured uplink grant can either be of Type 1 or Type 2. For Type 2, activation and deactivation of
configured uplink grants are independent among the serving cells. When more than one Type 2 configured grant is
configured, each configured grant is activated separately using a DCI command and deactivation of Type 2 configured
grants is done using a DCI command, which can either deactivate a single configured grant configuration or multiple
configured grant configurations jointly.
When SUL is configured, the network should ensure that an active configured uplink grant on SUL does not overlap in
time with another active configured uplink grant on the other UL configuration.
For both dynamic grant and configured grant, for a transport block, two or more repetitions can be in one slot, or across
slot boundary in consecutive available slots with each repetition in one slot. For both dynamic grant and configured
grant Type 2, the number of repetitions can be also dynamically indicated in the L1 signalling. The dynamically
indicated number of repetitions shall override the RRC configured number of repetitions, if both are present.
Editor’s note: The limitation of maximum of 32 CGs per MAC entity needs to be captured.
Uplink buffer status reports (BSR) are needed to provide support for QoS-aware packet scheduling. In NR, uplink
buffer status reports refer to the data that is buffered in for a group of logical channels (LCG) in the UE. Eight LCGs
and two formats are used for reporting in uplink:
- A flexible long format to report several BSRs (up to all eight LCGs).
Uplink buffer status reports are transmitted using MAC signalling. When a BSR is triggered (e.g. when new data arrives
in the transmission buffers of the UE), a Scheduling Request (SR) can be transmitted by the UE (e.g. when no resources
are available to transmit the BSR).
For IAB, the Pre-emptive BSR can be configured on the backhaul links. The Pre-emptive BSR is sent based on
expected data rather than buffered data, as described in Section 4.7.3.3.
Power headroom reports (PHR) are needed to provide support for power-aware packet scheduling. In NR, three types of
reporting are supported: a first one for PUSCH transmission, a second one for PUSCH and PUCCH transmission in an
LTE Cell Group in EN-DC (see TS 37.340 [21]) and a third one for SRS transmission on SCells configured with SRS
only. In case of CA, when no transmission takes place on an activated SCell, a reference power is used to provide a
virtual report. Power headroom reports are transmitted using MAC signalling.
3GPP
Release 16 97 3GPP TS 38.300 V16.21.0 (2020-073)
10.5.2 Uplink
The UE has an uplink rate control function which manages the sharing of uplink resources between logical channels.
RRC controls the uplink rate control function by giving each logical channel a priority, a prioritised bit rate (PBR), and
a buffer size duration (BSD). The values signalled need not be related to the ones signalled via NG to the gNB. In
addition, mapping restrictions can be configured (see clause 16.1.2).
The uplink rate control function ensures that the UE serves the logical channel(s) in the following sequence:
2. All relevant logical channels in decreasing priority order for the remaining resources assigned by the grant.
NOTE 1: In case the PBRs are all set to zero, the first step is skipped and the logical channels are served in strict
priority order: the UE maximises the transmission of higher priority data.
NOTE 2: The mapping restrictions tell the UE which logical channels are relevant for the grant received. If no
mapping restrictions are configured, all logical channels are considered.
NOTE 3: Through radio protocol configuration and scheduling, the gNB can guarantee the GFBR(s) and ensure
that neither the MFBR(s) nor the UE-AMBR are exceeded in uplink (see clause 12).
NOTE 4: The mapping restrictions allows the gNB to fulfil the MDBV requirements through scheduling at least for
the case where logical channels are mapped to separate serving cells.
If more than one logical channel have the same priority, the UE shall serve them equally.
- SCells which remain in the set (either unchanged or reconfigured) do not change their activation status
(activated or deactivated).
To enable reasonable UE battery consumption when BA is configured, only one UL BWP for each uplink carrier and
one DL BWP or only one DL/UL BWP pair can be active at a time in an active serving cell, all other BWPs that the UE
is configured with being deactivated. On deactivated BWPs, the UE does not monitor the PDCCH, does not transmit on
PUCCH, PRACH and UL-SCH.
3GPP
Release 16 98 3GPP TS 38.300 V16.21.0 (2020-073)
To enable fast SCell activation when CA is configured, one dormant BWP can be configured for an SCell. If the active
BWP of the activated SCell is a dormant BWP, the UE stops monitoring PDCCH on the SCell but continues performing
CSI measurements, AGC and beam management, if configured. A DCI is used to control entering/leaving the dormant
BWP for one or more SCell(s) or one or more SCell group(s).
The dormant BWP is one of the UE’s dedicated BWPs configured by network via dedicated RRC signalling. The
SpCell and PUCCH SCell cannot be configured with a dormant BWP.
- Cross-carrier scheduling does not apply to PCell i.e. PCell is always scheduled via its PDCCH;
- When an SCell is configured with a PDCCH, that cell’s PDSCH and PUSCH are always scheduled by the
PDCCH on this SCell;
- When an SCell is not configured with a PDCCH, that SCell’s PDSCH and PUSCH are always scheduled by a
PDCCH on another serving cell;
- The scheduling PDCCH and the scheduled PDSCH/PUSCH can use the same or different numerologies.
The scheduler on an IAB-DU or IAB-donor-DU complies with the gNB-DU resource configuration received via F1AP,
which defines the usage of scheduling resources to account for the aforementioned duplexing constraint.
The resource configuration assigns an attribute of hard, soft or unavailable to each symbol of each DU cell.
Transmission/reception can occur for symbols configured as hard, whereas scheduling cannot occur, except for some
special cases, for symbols configures as unavailable. For symbols configured as soft, scheduling can occur conditionally
on an explicit indication of availability by the parent node via DCI format 2_5, or on an implicit determination of
availability by the IAB-node. The implicit determination of availability is determined by the IAB-node depending on
whether or not the operation of the IAB-DU would have an impact on the collocated IAB-MT.
11 UE Power Saving
The PDCCH monitoring activity of the UE in RRC connected mode is governed by DRX, BA, and DCP.
When DRX is configured, the UE does not have to continuously monitor PDCCH. DRX is characterized by the
following:
- on-duration: duration that the UE waits for, after waking up, to receive PDCCHs. If the UE successfully
decodes a PDCCH, the UE stays awake and starts the inactivity timer;
3GPP
Release 16 99 3GPP TS 38.300 V16.21.0 (2020-073)
- inactivity-timer: duration that the UE waits to successfully decode a PDCCH, from the last successful decoding
of a PDCCH, failing which it can go back to sleep. The UE shall restart the inactivity timer following a single
successful decoding of a PDCCH for a first transmission only (i.e. not for retransmissions);
- cycle: specifies the periodic repetition of the on-duration followed by a possible period of inactivity (see figure
11-1 below);
- active-time: total duration that the UE monitors PDCCH. This includes the "on-duration" of the DRX cycle, the
time UE is performing continuous reception while the inactivity timer has not expired, and the time when the UE
is performing continuous reception while waiting for a retransmission opportunity.
DRX Cycle
When BA is configured, the UE only has to monitor PDCCH on the one active BWP i.e. it does not have to monitor
PDCCH on the entire DL frequency of the cell. A BWP inactivity timer (independent from the DRX inactivity-timer
described above) is used to switch the active BWP to the default one: the timer is restarted upon successful PDCCH
decoding and the switch to the default BWP takes place when it expires.
In addition, the UE may be indicated, when configured accordingly, whether it is required to monitor or not the PDCCH
during the next occurrence of the on-duration by a DCP monitored on the active BWP. If the UE does not detect a DCP
on the active BWP, it does not monitor the PDCCH during the next occurrence of the on-duration, unless it is explicitly
configured to do so in that case.
A UE can only be configured to monitor DCP when connected mode DRX is configured, and at occasion(s) at a
configured offset before the on-duration. More than one monitoring occasion can be configured before the on-duration.
The UE does not monitor DCP on occasions occurring during active-time, measurement gaps, or BWP switching, in
which case it monitors the PDCCH during the next on-duration. If no DCP is configured in the active BWP, UE follows
normal DRX operation.
One DCP can be configured to control PDCCH monitoring during on-duration for one or more UEs independently.
Power saving in RRC_IDLE and RRC_INACTIVE can also be achieved by UE relaxing neighbour cells RRM
measurements when it meets the criteria determining it is in low mobility and/or not at cell edge.
UE power saving may be enabled by adapting the DL maximum number of MIMO layers by BWP switching.
Power saving is also enabled during active-time via cross-slot scheduling, which facilitates UE to achieve power saving
with the assumption that it won’t be scheduled to receive PDSCH, triggered to receive A-CSI or transmit a PUSCH
scheduled by the PDCCH until the minimum scheduling offsets K0 and K2. Dynamic adaptation of the minimum
scheduling offsets K0 and K2 is controlled by PDCCH.
3GPP
Release 16 100 3GPP TS 38.300 V16.21.0 (2020-073)
12 QoS
12.1 Overview
The 5G QoS model is based on QoS Flows (see TS 23.501 [3]) and supports both QoS Flows that require guaranteed
flow bit rate (GBR QoS Flows) and QoS Flows that do not require guaranteed flow bit rate (non-GBR QoS Flows). At
NAS level (see TS 23.501 [3]), the QoS flow is thus the finest granularity of QoS differentiation in a PDU session. A
QoS flow is identified within a PDU session by a QoS Flow ID (QFI) carried in an encapsulation header over NG-U.
The QoS architecture in NG-RAN, both for NR connected to 5GC and for E-UTRA connected to 5GC, is depicted in
the Figure 12-1 and described in the following:
- Except for NB-IoT, for each UE, the NG-RAN establishes at least one Data Radio Bearers (DRB) together with
the PDU Session and additional DRB(s) for QoS flow(s) of that PDU session can be subsequently configured (it
is up to NG-RAN when to do so);
- If NB-IoT UE supports NG-U data transfer, the NG-RAN may establish Data Radio Bearers (DRB) together
with the PDU Session and one PDU session maps to only one DRB;
- The NG-RAN maps packets belonging to different PDU sessions to different DRBs;
- NAS level packet filters in the UE and in the 5GC associate UL and DL packets with QoS Flows;
- AS-level mapping rules in the UE and in the NG-RAN associate UL and DL QoS Flows with DRBs.
NG-RAN 5GC
UE NB UPF
PDU Session
Radio Bearer NG-U Tunnel
QoS Flow
QoS Flow
Radio Bearer
QoS Flow
Radio NG-U
NG-RAN and 5GC ensure quality of service (e.g. reliability and target delay) by mapping packets to appropriate QoS
Flows and DRBs. Hence there is a 2-step mapping of IP-flows to QoS flows (NAS) and from QoS flows to DRBs
(Access Stratum).
At NAS level, a QoS flow is characterised by a QoS profile provided by 5GC to NG-RAN and QoS rule(s) provided by
5GC to the UE. The QoS profile is used by NG-RAN to determine the treatment on the radio interface while the QoS
rules dictates the mapping between uplink User Plane traffic and QoS flows to the UE. A QoS flow may either be GBR
or Non-GBR depending on its profile. The QoS profile of a QoS flow contains QoS parameters, for instance (see TS
23.501 [3]):
3GPP
Release 16 101 3GPP TS 38.300 V16.21.0 (2020-073)
- Guaranteed Flow Bit Rate (GFBR) for both uplink and downlink;
- Maximum Flow Bit Rate (MFBR) for both uplink and downlink;
- Notification Control.
NOTE: The Maximum Packet Loss Rate (UL, DL) is only provided for a GBR QoS flow belonging to voice
media.
- Reflective QoS Attribute (RQA): the RQA, when included, indicates that some (not necessarily all) traffic
carried on this QoS flow is subject to reflective quality of service (RQoS) at NAS;
The QoS parameter Notification Control indicates whether notifications are requested from the RAN when the GFBR
can no longer (or again) be fulfilled for a QoS Flow. If, for a given GBR QoS Flow, notification control is enabled and
the RAN determines that the GFBR cannot be guaranteed, RAN shall send a notification towards SMF and keep the
QoS Flow (i.e. while the NG-RAN is not delivering the requested GFBR for this QoS Flow), unless specific conditions
at the NG-RAN require the release of the NG-RAN resources for this GBR QoS Flow, e.g. due to Radio link failure or
RAN internal congestion. When applicable, NG-RAN sends a new notification, informing SMF that the GFBR can be
guaranteed again.
If Alternative QoS parameters Sets are received with the Notification Control parameter, the NG-RAN may also include
in the notification a reference corresponding to the QoS Parameter Set which it can currently fulfil as specified in TS
23.501 [3].
In addition, an Aggregate Maximum Bit Rate is associated to each PDU session (Session-AMBR) and to each UE (UE-
AMBR). The Session-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR QoS
Flows for a specific PDU Session and is ensured by the UPF. The UE-AMBR limits the aggregate bit rate that can be
expected to be provided across all Non-GBR QoS Flows of a UE and is ensured by the RAN (see clause 10.5.1).
The 5QI is associated to QoS characteristics giving guidelines for setting node specific parameters for each QoS Flow.
Standardized or pre-configured 5G QoS characteristics are derived from the 5QI value and are not explicitly signalled.
Signalled QoS characteristics are included as part of the QoS profile. The QoS characteristics consist for instance of
(see TS 23.501 [3]):
- Priority level;
- Averaging window;
At Access Stratum level, the data radio bearer (DRB) defines the packet treatment on the radio interface (Uu). A DRB
serves packets with the same packet forwarding treatment. The QoS flow to DRB mapping by NG-RAN is based on
QFI and the associated QoS profiles (i.e. QoS parameters and QoS characteristics). Separate DRBs may be established
for QoS flows requiring different packet forwarding treatment, or several QoS Flows belonging to the same PDU
session can be multiplexed in the same DRB.
In the uplink, the mapping of QoS Flows to DRBs is controlled by mapping rules which are signalled in two different
ways:
3GPP
Release 16 102 3GPP TS 38.300 V16.21.0 (2020-073)
- Reflective mapping: for each DRB, the UE monitors the QFI(s) of the downlink packets and applies the same
mapping in the uplink; that is, for a DRB, the UE maps the uplink packets belonging to the QoS flows(s)
corresponding to the QFI(s) and PDU Session observed in the downlink packets for that DRB. To enable this
reflective mapping, the NG-RAN marks downlink packets over Uu with QFI.
- Explicit Configuration: QoS flow to DRB mapping rules can be explicitly signalled by RRC.
The UE always applies the latest update of the mapping rules regardless of whether it is performed via reflecting
mapping or explicit configuration.
When a QoS flow to DRB mapping rule is updated, the UE sends an end marker on the old bearer.
In the downlink, the QFI is signalled by NG-RAN over Uu for the purpose of RQoS and if neither NG-RAN, nor the
NAS (as indicated by the RQA) intend to use reflective mapping for the QoS flow(s) carried in a DRB, no QFI is
signalled for that DRB over Uu. In the uplink, NG-RAN can configure the UE to signal QFI over Uu.
For each PDU session, a default DRB may be configured: if an incoming UL packet matches neither an RRC
configured nor a reflective mapping rule, the UE then maps that packet to the default DRB of the PDU session. For non-
GBR QoS flows, the 5GC may send to the NG-RAN the Additional QoS Flow Information parameter associated with
certain QoS flows to indicate that traffic is likely to appear more often on them compared to other non-GBR QoS flows
established on the same PDU session.
Within each PDU session, it is up to NG-RAN how to map multiple QoS flows to a DRB. The NG-RAN may map a
GBR flow and a non-GBR flow, or more than one GBR flow to the same DRB, but mechanisms to optimise these cases
are not within the scope of standardization.
13 Security
- For user data (DRBs), ciphering provides user data confidentiality and integrity protection provides user data
integrity;
- For RRC signalling (SRBs), ciphering provides signalling data confidentiality and integrity protection signalling
data integrity;
NOTE: Ciphering and integrity protections are optionally configured except for RRC signalling for which
integrity protection is always configured. Ciphering and integrity protection can be configured per DRB
but all DRBs belonging to a PDU session for which the User Plane Security Enforcement information
indicates that UP integrity protection is required (see TS 23.502 [22]), are configured with integrity
protection.
- For key management and data handling, any entity processing cleartext shall be protected from physical attacks
and located in a secure environment;
- The gNB (AS) keys are cryptographically separated from the 5GC (NAS) keys;
- Separate AS and NAS level Security Mode Command (SMC) procedures are used;
- A sequence number (COUNT) is used as input to the ciphering and integrity protection and a given sequence
number must only be used once for a given key (except for identical re-transmission) on the same radio bearer in
the same direction.
3GPP
Release 16 103 3GPP TS 38.300 V16.21.0 (2020-073)
- KNASint is a key derived by ME and AMF from KAMF, which shall only be used for the protection of NAS
signalling with a particular integrity algorithm;
- KNASenc is a key derived by ME and AMF from KAMF, which shall only be used for the protection of NAS
signalling with a particular encryption algorithm.
- KgNB is a key derived by ME and AMF from KAMF. KgNB is further derived by ME and source gNB when
performing horizontal or vertical key derivation.
- KUPenc is a key derived by ME and gNB from KgNB, which shall only be used for the protection of UP traffic
between ME and gNB with a particular encryption algorithm;
- KUPint is a key derived by ME and gNB from KgNB, which shall only be used for the protection of UP traffic
between ME and gNB with a particular integrity algorithm.
- KRRCint is a key derived by ME and gNB from KgNB, which shall only be used for the protection of RRC
signalling with a particular integrity algorithm;
- KRRCenc is a key derived by ME and gNB from KgNB, which shall only be used for the protection of RRC
signalling with a particular encryption algorithm.
Intermediate keys:
- KgNB* is a key derived by ME and gNB when performing a horizontal or vertical key derivation.
The primary authentication enables mutual authentication between the UE and the network and provide an anchor key
called KSEAF. From KSEAF, KAMF is created during e.g. primary authentication or NAS key re-keying and key refresh
events. Based on KAMF, KNASint and KNASenc are then derived when running a successful NAS SMC procedure.
Whenever an initial AS security context needs to be established between UE and gNB, AMF and the UE derive a K gNB
and a Next Hop parameter (NH). The KgNB and the NH are derived from the KAMF. A NH Chaining Counter (NCC) is
associated with each KgNB and NH parameter. Every KgNB is associated with the NCC corresponding to the NH value
from which it was derived. At initial setup, the KgNB is derived directly from KAMF, and is then considered to be
associated with a virtual NH parameter with NCC value equal to zero. At initial setup, the derived NH value is
associated with the NCC value one. On handovers, the basis for the KgNB that will be used between the UE and the target
gNB, called KgNB*, is derived from either the currently active KgNB or from the NH parameter. If KgNB* is derived from
the currently active KgNB, this is referred to as a horizontal key derivation and is indicated to UE with an NCC that does
not increase. If the KgNB* is derived from the NH parameter, the derivation is referred to as a vertical key derivation and
is indicated to UE with an NCC increase. Finally, KRRCint, KRRCenc, KUPint and KUPenc are derived based on KgNB after a new
KgNB is derived. This is depicted on Figure 13.1-1 below:
3GPP
Release 16 104 3GPP TS 38.300 V16.21.0 (2020-073)
KSEAF
ME / SEAF
KAMF
ME / AMF
NCC
With such key derivation, a gNB with knowledge of a KgNB, shared with a UE, is unable to compute any previous KgNB
that has been used between the same UE and a previous gNB, therefore providing backward security. Similarly, a gNB
with knowledge of a KgNB, shared with a UE, is unable to predict any future KgNB that will be used between the same UE
and another gNB after n or more handovers (since NH parameters are only computable by the UE and the AMF).
The AS SMC procedure is for RRC and UP security algorithms negotiation and RRC security activation. When AS
security context is to be established in the gNB, the AMF sends the UE 5G security capabilities to the gNB. The gNB
chooses the ciphering algorithm which has the highest priority from its configured list and is also present in the UE 5G
security capabilities. The gNB also chooses the integrity algorithm which has the highest priority from its configured
list and is also present in the UE 5G security capabilities. The chosen algorithms are indicated to the UE in the AS SMC
and this message is integrity protected. RRC downlink ciphering (encryption) at the gNB starts after sending the AS
SMC message. RRC uplink deciphering (decryption) at the gNB starts after receiving and successful verification of the
integrity protected AS security mode complete message from the UE. The UE verifies the validity of the AS SMC
message from the gNB by verifying the integrity of the received message. RRC uplink ciphering (encryption) at the UE
starts after sending the AS security mode complete message. RRC downlink deciphering (decryption) at the UE shall
start after receiving and successful verification of the AS SMC message. The RRC Connection Reconfiguration
procedure used to add DRBs shall be performed only after RRC security has been activated as part of the AS SMC
procedure.
The maximum supported data rate for integrity protected DRBs is a UE capability indicated at NAS layer, with a
minimum value of 64 kbps and a maximum value of the highest data rate supported by the UE. In case of failed
integrity check (i.e. faulty or missing MAC-I), the concerned PDU shall be discarded by the receiving PDCP entity.
Key refresh is possible for KgNB, KRRC-enc, KRRC-int, KUP-enc, and KUP-int and can be initiated by the gNB when a PDCP
COUNTs are about to be re-used with the same Radio Bearer identity and with the same KgNB. Key re-keying is also
possible for the KgNB, KRRC-enc, KRRC-int, KUP-enc, and KUP-int and can be initiated by the AMF when a 5G AS security context
different from the currently active one shall be activated.
3GPP
Release 16 105 3GPP TS 38.300 V16.21.0 (2020-073)
On RRC_CONNECTED to RRC_IDLE transitions, the gNBs deletes the keys it stores for that UE such that state
information for idle mode UEs only has to be maintained in AMF. It is also assumed that gNB does no longer store state
information about the corresponding UE and deletes the current keys from its memory. In particular, on connected to
idle transitions:
- The gNB and UE delete NH, KgNB, KRRCint, KRRCenc, KUPint and KUPenc and related NCC;
On mobility with vertical key derivation the NH is further bound to the target PCI and its frequency ARFCN-DL before
it is taken into use as the KgNB in the target gNB. On mobility with horizontal key derivation the currently active KgNB is
further bound to the target PCI and its frequency ARFCN-DL before it is taken into use as the KgNB in the target gNB
(see clause 13.1). In both cases, ARFCN-DL is the absolute frequency of SSB of the target PCell.
It is not required to change the AS security algorithms during intra-gNB-CU handover. If the UE does not receive an
indication of new AS security algorithms during an intra-gNB-CU handover, the UE shall continue to use the same
algorithms as before the handover (see TS 38.331 [12]).
14 UE Capabilities
The UE capabilities in NR do not rely on UE categories: UE categories associated to fixed peak data rates are only
defined for marketing purposes and not signalled to the network. Instead, the network determines the UL and DL data
rate supported by a UE from the supported band combinations and from the baseband capabilities (modulation scheme,
MIMO layers, …).
To limit signalling overhead, the gNB can request the UE to provide NR capabilities for a restricted set of bands. When
responding, the UE can skip a subset of the requested band combinations when the corresponding UE capabilities are
the same.
If supported by the UE and the network, the UE may provide an ID in NAS signalling that represents its radio
capabilities for one or more RATs in order to reduce signalling overhead. The ID may be assigned either by the
manufacturer or by the serving PLMN. The manufacturer-assigned ID corresponds to a pre-provisioned set of
capabilities. In the case of the PLMN-assigned ID, assignment takes place in NAS signalling.
15.1 Definitions
Void.
3GPP
Release 16 106 3GPP TS 38.300 V16.21.0 (2020-073)
15.2 Void
15.3 Self-configuration
15.3.1 Dynamic configuration of the NG-C interface
15.3.1.1 Prerequisites
The following prerequisites are assumed:
- An initial remote IP end point to be used for SCTP initialisation is provided to the NG-RAN node for each AMF
the NG-RAN node is supposed to connect to.
NOTE: The NG-RAN node may use different source and/or destination IP end point(s) if the SCTP establishment
towards one IP end point fails. How the NG-RAN node gets the remote IP end point(s) and its own IP
address are outside the scope of this specification.
- The NG-RAN node provides the relevant configuration information to the AMF, which includes list of supported
TA(s), etc;
- The AMF provides the relevant configuration information to the NG-RAN node, which includes PLMN ID, etc.;
- When the application layer initialization is successfully concluded, the dynamic configuration procedure is
completed and the NG-C interface is operational.
After the application layer initialization is successfully completed, the AMF may add or update or remove SCTP
endpoints to be used for NG-C signalling between the AMF and the NG-RAN node pair as specified in TS 23.501 [3].
15.3.2.1 Prerequisites
The following prerequisites are necessary:
- An initial remote IP end point to be used for SCTP initialisation is provided to the NG-RAN node.
NOTE: The NG-RAN node may use different source and/or destination IP end point(s) if the SCTP establishment
towards one IP end point fails.
3GPP
Release 16 107 3GPP TS 38.300 V16.21.0 (2020-073)
- The NG-RAN node provides the relevant configuration information to the candidate NG-RAN node, which
includes served cell information.
- The candidate NG-RAN node provides the relevant configuration information to the initiating NG-RAN node,
which includes served cell information.
- When the application layer initialization is successfully concluded, the dynamic configuration procedure is
completed and the Xn interface is operational.
- The NG-RAN node shall keep neighbouring NG-RAN nodes updated with the complete list of served cells, or, if
requested by the peer NG-RAN node, by a limited list of served cells, while the Xn interface is operational.
15.3.3.1 General
The purpose of ANR function is to relieve the operator from the burden of manually managing NCRs. Figure 15.3.3.1-1
shows ANR and its environment:
OAM
Add/Update NCR
NCR report
Internal
Neighbour Cell Relation Table Iinformation
Neighbour Cell Relation O&M controlled Attributes
Neighbour
NCRremove
NCR TCI No
No HO No Xn Removal
Remove
NCRupdate NCRT Function
1 TCl#1
Managemnt
Function
2 TCI#1 X X
eNB NCRadd Neighbour
3 TCI#1
X Detection Function
Mrmnt Mrmnt
ANR function requests reports
gNB RRC
The ANR function resides in the gNB and manages the Neighbour Cell Relation Table (NCRT). Located within ANR,
the Neighbour Detection Function finds new neighbours and adds them to the NCRT. ANR also contains the Neighbour
Removal Function which removes outdated NCRs. The Neighbour Detection Function and the Neighbour Removal
Function are implementation specific.
An existing NCR from a source cell to a target cell means that gNB controlling the source cell:
a) Knows the global and physical IDs (e.g. NR CGI/NR PCI, ECGI/PCI) of the target cell.
b) Has an entry in the NCRT for the source cell identifying the target cell.
c) Has the attributes in this NCRT entry defined, either by OAM or set to default values.
NCRs are cell-to-cell relations, while an Xn link is set up between two gNBs. Neighbour Cell Relations are
unidirectional, while an Xn link is bidirectional.
3GPP
Release 16 108 3GPP TS 38.300 V16.21.0 (2020-073)
NOTE: The neighbour information exchange, which occurs during the Xn Setup procedure or in the gNB
Configuration Update procedure, may be used for ANR purpose.
The ANR function also allows OAM to manage the NCRT. OAM can add and delete NCRs. It can also change the
attributes of the NCRT. The OAM system is informed about changes in the NCRT.
Cell A UE Cell B
Phy-CID=3 Phy-CID=5
Global-CID=17 Global-CID=19
1. Report
(Phy-CID=5, strong signal)
2. Report Global-CID Request
(Target Phy-CID=5)
2b. BCCH (...)
3. Report Global-CID=19
Figure 15.3.3.2-1 depicts an example where the NG-RAN node serving cell A has an ANR function. In
RRC_CONNECTED, the NG-RAN node instructs each UE to perform measurements on neighbour cells. The NG-
RAN node may use different policies for instructing the UE to do measurements, and when to report them to the NG-
RAN node. This measurement procedure is as specified in TS 38.331[12] and TS 36.331 [29].
1. The UE sends a measurement report regarding cell B. This report contains Cell B's PCI, but not its NCGI/ECGI.
When the NG-RAN node receives a UE measurement report containing the PCI, the following sequence may be used.
2. The NG-RAN node instructs the UE, using the newly discovered PCI as parameter, to read all the broadcast
NCGI(s) /ECGI(s), TAC(s), RANAC(s), PLMN ID(s) and, for neighbour NR cells, NR frequency band(s). To do
so, the NG-RAN node may need to schedule appropriate idle periods to allow the UE to read the NCGI/ECGI
from the broadcast channel of the detected neighbour cell. How the UE reads the NCGI/ECGI is specified in TS
38.331 [12] and TS 36.331 [29].
3. When the UE has found out the new cell's NCGI(s) /ECGI(s), the UE reports all the broadcast NCGI(s)/ECGI(s)
to the serving cell NG-RAN node. In addition, the UE reports all the tracking area code(s), RANAC(s), PLMN
IDs and, for neighbour NR cells, NR frequency band(s), that have been read by the UE. In case the detected NR
cell does not broadcast SIB1, the UE may report noSIB1 indication as specified in TS 38.331 [12].
4. The NG-RAN node decides to add this neighbour relation, and can use PCI and NCGI(s)/ECGI(s) to:
15.3.3.3 Void
15.3.3.4 Void
3GPP
Release 16 109 3GPP TS 38.300 V16.21.0 (2020-073)
Cell A UE Cell B
Type=NR Type=LTE
Phy-CID=3 Phy-CID=PSC=5
Global-CID=17 Global-CID=19
4. Report Global-CID=19
Figure 15.3.3.5-1: Automatic Neighbour Relation Function in case of E-UTRAN detected cell
Figure 15.3.3.5-1 depicts an example where the NG-RAN node serving cell A has an ANR function. In
RRC_CONNECTED, the NG-RAN node instructs a UE to perform measurements and detect E-UTRA cells connected
to EPC. The NG-RAN node may use different policies for instructing the UE to do measurements, and when to report
them to the NG-RAN node.
1 The NG-RAN node instructs a UE to look for neighbour cells in the target system. To do so the NG-RAN node
may need to schedule appropriate idle periods to allow the UE to scan all cells in the target system.
2 The UE reports the PCI and carrier frequency of the detected cells in the target system.
When the NG-RAN node receives UE reports containing PCIs of cell(s) the following sequence may be used.
3 The NG-RAN node instructs the UE, using the newly discovered PCI as parameter, to read the ECGI, the TAC
and all available PLMN ID(s) of the newly detected cell in case of E-UTRA detected cells. The UE ignores
transmissions from the serving cell while finding the requested information transmitted in the broadcast channel
of the detected inter-system/inter-frequency neighbour cell. To do so, the NG-RAN node may need to schedule
appropriate idle periods to allow the UE to read the requested information from the broadcast channel of the
detected inter-system neighbour cell.
4 After the UE has read the requested information in the new cell, it reports the detected ECGI, TAC, and
available PLMN ID(s) to the serving cell NG-RAN node.
- The NG-RAN node sends the UPLINK RAN CONFIGURATION TRANSFER message to the AMF to request
the TNL address of the candidate NG-RAN node, and includes relevant information such as the source and target
RAN node ID.
- The AMF relays the request by sending the DOWNLINK RAN CONFIGURATION TRANSFER message to
the candidate NG-RAN node identified by the target RAN node ID.
- The candidate NG-RAN node responds by sending the UPLINK RAN CONFIGURATION TRANSFER
message containing one or more TNL addresses to be used for SCTP connectivity with the initiating NG-RAN
node, and includes other relevant information such as the source and target RAN node ID.
- The AMF relays the response by sending the DOWNLINK CONFIGURATION TRANSFER message to the
initiating NG-RAN node identified by the target RAN node ID.
NOTE: In this version of the specification, it is assumed that the NG-RAN node is able to determine the gNB ID
length of the candidate gNB (e.g. based on OAM configuration).
3GPP
Release 16 110 3GPP TS 38.300 V16.21.0 (2020-073)
The function allows, for example in a deployment where capacity boosters can be distinguished from cells providing
basic coverage, to optimize energy consumption enabling the possibility for an E-UTRA or NR cell providing
additional capacity via single or dual connectivity, to be switched off when its capacity is no longer needed and to be re-
activated on a need basis.
The NG-RAN node may initiate handover actions in order to off-load the cell being switched off and may indicate the
reason for handover with an appropriate cause value to support the target node in taking subsequent actions, e.g. when
selecting the target cell for subsequent handovers.
All neighbour NG-RAN nodes are informed by the NG-RAN node owning the concerned cell about the switch-off
actions over the Xn interface, by means of the NG-RAN node Configuration Update procedure.
All informed nodes maintain the cell configuration data, e.g., neighbour relationship configuration, also when a certain
cell is inactive. If basic coverage is ensured by NG-RAN node cells, NG-RAN node owning non-capacity boosting cells
may request a re-activation over the Xn interface if capacity needs in such cells demand to do so. This is achieved via
the Cell Activation procedure. During switch off time period of the boost cell, the NG-RAN node may prevent idle
mode UEs from camping on this cell and may prevent incoming handovers to the same cell.
The NG-RAN node receiving a request should act accordingly. The switch-on decision may also be taken by O&M. All
peer NG-RAN nodes are informed by the NG-RAN node owning the concerned cell about the re-activation by an
indication on the Xn interface.
- The ability of an NG-RAN node to request the re-activation of a configured list of inactive cells owned by a peer
NG-RAN node.
- policies used by peer NG-RAN nodes for requesting the re-activation of an inactive cell.
15.5 Self-optimisation
15.5.1 Support for Mobility Load Balancing
15.5.1.1 General
The objective of mobility load balancing is to distribute load evenly among cells and among areas of cells, or to transfer
part of the traffic from congested cell or from congested areas of cells, or to offload users from one cell, cell area,
carrier or RAT to achieve network energy saving. This can be done by means of optimization of cell
3GPP
Release 16 111 3GPP TS 38.300 V16.21.0 (2020-073)
reselection/handover parameters and handover actions. The automation of such optimisation can provide high quality
user experience, while simultaneously improving the system capacity and also to minimize human intervention in the
network management and optimization tasks.
In general, support for mobility load balancing consists of one or more of following functions:
- Load reporting;
The following load related information should be supported which consists of,
- Radio resource usage (per-cell and per SSB area PRB usage: DL/UL GBR PRB usage, DL/UL non-GBR PRB
usage, DL/UL total PRB usage, and DL/UL scheduling PDCCH CCE usage);
- TNL capacity indicator (UL/DL TNL offered capacity and available capacity);
- Capacity value (per cell, per SSB area and per slice: UL/DL available capacity);
- HW capacity indicator (offered throughput and available throughput over E1, percentage utilisation over F1);
- RRC connections (number of RRC connections, and available RRC Connection Capacity);
To achieve load reporting function, Resource Status Reporting Initiation & Resource Status Reporting procedures are
used.
The source cell informs the target cell about the new mobility setting and provides cause for the change (e.g. load
balancing related request). The proposed change is expressed by the means of the difference (delta) between the current
and the new values of the handover trigger. The handover trigger is the cell specific offset that corresponds to the
threshold at which a cell initialises the handover preparation procedure. Cell reselection configuration may be amended
to reflect changes in the HO setting. The target cell responds to the information from the source cell. The allowed delta
range for HO trigger parameter may be carried in the failure response message. The source cell should consider the
responses before executing the planned change of its mobility setting.
All automatic changes on the HO and/or reselection parameters must be within the range allowed by OAM.
3GPP
Release 16 112 3GPP TS 38.300 V16.21.0 (2020-073)
15.5.2.1 General
Mobility Robustness Optimisation aims at detecting and enabling correction of following problems:
-Inter-system Unnecessary HO (too early inter-system HO from NR to E-UTRAN with no radio link failure);
-Inter-system HO ping-pong.
MRO provides means to distinguish the above problems from NR coverage related problems and other problems, not
related to mobility.
15.5.2.2.1 General
For analysis of connection failures, the UE makes the RLF Report available to the network.
The UE stores the latest RLF Report, including both LTE and NR RLF report until the RLF report is fetched by the
network or for 48 hours after the connection failure is detected.
The UE only indicates RLF report availability and only provides the RLF report to the network if the current RPLMN is
a PLMN that was present in the UE's EPLMN List or was the RPLMN at the time the connection failure was detected.
In case RLF happens in an E-UTRA cell, the UE makes the LTE RLF Report available to NG-RAN nodes and eNB(s),
and in case RLF happens in an NR cell the UE makes the NR RLF Report available to gNB(s).
If the LTE RLF Report is reported to a NG-RAN node, and the last serving node is an E-UTRAN node, the NG-RAN
node may transfer it to the E-UTRAN node by triggering the Uplink RAN configuration transfer procedure over NG
and the E-UTRAN node can take this into account as defined in TS 36.300 [2].
- [Intra-system Too Late Handover] An RLF occurs after the UE has stayed for a long period of time in the cell;
the UE attempts to re-establish the radio link connection in a different cell.
- [Intra-system Too Early Handover] An RLF occurs shortly after a successful handover from a source cell to a
target cell or a handover failure occurs during the handover procedure; the UE attempts to re-establish the radio
link connection in the source cell.
- [Intra-system Handover to Wrong Cell] An RLF occurs shortly after a successful handover from a source cell to
a target cell or a handover failure occurs during the handover procedure; the UE attempts to re-establish the radio
link connection in a cell other than the source cell and the target cell.
In the definition above, the "successful handover" refers to the UE state, namely the successful completion of the RA
procedure.
Detection mechanism:
A failure indication may be initiated after a UE attempts to re-establish the radio link connection at NG-RAN node B
after a failure at NG-RAN node A. NG-RAN node B may initiate the Failure Indication procedure towards multiple
NG-RAN nodes if they control cells which use the PCI signalled by the UE during the re-establishment procedure. The
NG-RAN node receiving this selects the UE context that matches the received Failure Cell ID and C-RNTI, and, if
available, uses the shortMAC-I to confirm this identification, by calculating the shortMAC-I and comparing it to the
received IE.
A failure indication may also be sent to the node last serving the UE when the NG-RAN node fetches the RLF
REPORT from UE by triggering:
3GPP
Release 16 113 3GPP TS 38.300 V16.21.0 (2020-073)
- the Uplink RAN configuration transfer procedure and Downlink RAN configuration transfer procedure over NG.
The detailed detection mechanisms for too late handover, too early handover and handover to wrong cell are carried out
through the following in the NG-RAN node that served the UE before the reported connection failure:
There is no recent handover for the UE prior to the connection failure e.g. the UE reported timer is absent or larger
than the configured threshold (e.g. Tstore_UE_cntxt)
There is a recent handover for the UE prior to the connection failure e.g. the UE reported timer is smaller than the
configured threshold (e.g. Tstore_UE_cntxt), and the first re-establishment attempt cell/the cell UE attempts to re-
connect is the cell that served the UE at the last handover initialisation.
There is a recent handover for the UE prior to the connection failure e.g. the UE reported timer is smaller than the
configured threshold (e.g. Tstore_UE_cntxt), and the first re-establishment attempt cell/the cell UE attempts to re-
connect is neither the cell that served the UE at the last handover initialisation nor the cell that served the UE where
the RLF happened or the cell that the handover was initialized toward.
The "UE reported timer" above indicates the time elapsed since the last handover initialisation until connection failure.
In case of Too Early Handover or Handover to Wrong Cell, the NG-RAN node receiving the failure indication may
inform the NG-RAN node controlling the cell where the mobility configuration caused the failure by means of the
Handover Report procedure over Xn or the Uplink RAN Configuration Transfer procedure over NG. This may include
the RLF report.
In order to retrieve relevant information collected at the network side as part of the UE context, the UE provides C-
RNTI used in the last serving cell. If the cause for the failure is identified as a "Too Early HO" or a "HO to Wrong
Cell", the NG-RAN node controlling the last serving cell shall, include in the HANDOVER REPORT message the C-
RNTI used in the source cell of the last completed handover before the failure. If the NG RAN node controlling that
source cell provided the Mobility Information, it is also included in the HANDOVER REPORT message. If used, the
Mobility Information is prepared at the source NG RAN node of a handover and may refer to or identify any handover-
related data at this NG RAN node.
In case the RRC re-establishment fails and the RRC connection setup succeeds, MRO evaluation of intra-RAT mobility
connection failures may be triggered twice for the same failure event. In this case, only one failure event should be
counted.
- [Inter-system/ Too Late Handover] An RLF occurs after the UE has stayed in a cell belonging to an NG-RAN
node for a long period of time; the UE attempts to re-connect to a cell belonging to an E-UTRAN node.
- [Inter-system/ Too Early Handover] An RLF occurs shortly after a successful handover from a cell belonging to
an E-UTRAN node to a target cell belonging to an NG-RAN node; the UE attempts to re-connect to the source
cell or to another cell belonging to an E-UTRAN node.
Detection mechanism:
A failure indication may be sent to the node last serving the UE when the NG-RAN node fetches the RLF REPORT
from UE by triggering:
3GPP
Release 16 114 3GPP TS 38.300 V16.21.0 (2020-073)
- the Uplink RAN configuration transfer procedure and Downlink RAN configuration transfer procedure over NG.
In case the last serving node is an E-UTRAN node, the detection mechanism proceed as deined in TS 36.300 [2].
In case the last serving node is an NG-RAN node, the detection mechanisms for Too Late Inter-system Handover and
Too Early Inter-system Handover are carried out through the following:
The connection failure occurs while being connected to a NG-RAN node, and there is no recent handover for the UE
prior to the connection failure i.e., the UE reported timer is absent or larger than the configured threshold, e.g.,
Tstore_UE_cntxt, and the first node where the UE attempts to re-connect is a E-UTRAN node.
The connection failure occurs while being connected to a NG-RAN node, and there is a recent inter-system handover
for the UE prior to the connection failure i.e., the UE reported timer is smaller than the configured threshold, e.g.,
Tstore_UE_cntxt, and the first cell where the UE attempts to re-connect and the node that served the UE at the last
handover initialisation are both E-UTRAN node.
The "UE reported timer" above indicates the time elapsed since the last handover initialisation until connection failure.
The UE may make the RLF Report available to an NG-RAN node. The NG-RAN node may forward the information
using the FAILURE INDICATION message over Xn or by means of the Uplink RAN configuration transfer procedure
and Downlink RAN configuration transfer over NG to the node that served the UE before the reported connection
failure.
In case the failure is a Too Early Inter-system Handover, the NG-RAN node receiving the failure indication may inform
the E-UTRAN node by means of the Uplink RAN Configuration Transfer procedure over NG. This may include the
RLF report.
- UE is handed over from NR to E-UTRAN even though quality of the NR coverage was sufficient for the service
used by the UE. The handover may therefore be considered as unnecessary HO to another system (i.e. EPS) (too
early inter-system HO without connection failure).
In inter-system HO, if the serving cell threshold (NR cell) is set too high, and cell in another system (i.e. EPS) with
good signal strength is available, a handover to another system may be triggered unnecessarily, resulting in an
inefficient use of the networks. With a lower threshold the UE could have continued in the source system (5GS).
To be able to detect the Unnecessary HO to another system, a gNB node may choose to put additional coverage and
quality condition information into the HANDOVER REQUIRED message in the Handover Preparation procedure when
an inter-system HO from gNB to another system occurs. The RAN node in the other system, upon receiving this
additional coverage and quality information, may instruct the UE to continue measuring the cell(s) in source system
during a period of time, while being connected to another system, and send periodic or single measurement reports to
the node in other system. When the period of time indicated by the node in source system expires, the RAN node in the
other system, may evaluate the received measurement reports with the coverage/quality condition received during the
inter-system HO procedure and decide if an inter-system unnecessary HO report should be sent to the gNB in the source
system.
The inter-system unnecessary HO report shall only be sent in cases where, in all UE measurement reports collected
during the measurement period, any cells in the source system exceed the radio coverage and/or quality threshold (the
radio threshold RSRP, RSRQ or/and SINR and the measurement period are indicated in the additional coverage and
quality information in the Handover Preparation procedure). If an inter-system handover towards 5GS is executed from
EPS within the indicated measurement period, the measurement period expires. In this case, the eNB in EPS may also
send the HO Report. No HO Report shall be sent in case no NR cell could be included, or if the indicated period of time
is interrupted by an inter-system handover to a system different than 5GS.
3GPP
Release 16 115 3GPP TS 38.300 V16.21.0 (2020-073)
The RAN node in the source system (5GS) upon receiving of the report, can decide if/how its parameters (e.g.,
threshold to trigger Inter-system HO) should be adjusted.
- A UE is handed over from a cell in a source system (e.g. 5GS) to a cell in a target system different from the
source system (e.g. EPS), then within a predefined limited time the UE is handed over back to a cell in the
source system, while the coverage of the source system was sufficient for the service used by the UE. The event
may occur more than once.
The solution for the problem may consist of the following steps:
1) Statistics regarding inter-system ping-pong occurrences are collected by the responsible node.
2) Coverage verification is performed to check if the mobility to other system was inevitable.
The statistics regarding ping-pong occurrence may be based on evaluation of the UE History Information IE in the
HANDOVER REQUIRED message. If the evaluation indicates a potential ping-pong case and the source NG_RAN
node of the 1st inter-system handover is different than the target NG-RAN node of the 2nd inter-system handover, the
target NG-RAN node may use the HANDOVER REPORT message or the UPLINK RAN CONFIGURATION
TRANSFER message to indicate the occurrence of potential ping-pong cases to the source NG-RAN node.
If NG-RAN coverage during the potential ping-pong event needs to be verified for the purpose of determining
corrective measures, the Unnecessary HO to another system procedure may be used
The following control parameters shall be provided by OAM to control MRO behaviour:
Furthermore, in order to support the solutions for detection of mobility optimisation, the parameter Tstore_UE_cntxt
shall be configurable by the OAM system.
- I ndexes of the SSBs and number of RACH preambles sent on each tried SSB listed in chronological order of
attempts.
- Indication whether the selected SSB is above or below the rsrp-ThresholdSSB threshold per RACH attempt.
3GPP
Release 16 116 3GPP TS 38.300 V16.21.0 (2020-073)
The UE may report the UE history information when connecting to a cell of the NG-RAN node.
When information needs to be discarded because the list is full, such information will be discarded in order of its
position in the list, starting with the oldest cell record. If the list is full, and the UE history information from the UE is
available, the UE history information from the UE should also be discarded.
The resulting information is then used in subsequent handover preparations by means of the Handover Preparation
procedures over the NG and XN interfaces, which provide the target NG-RAN node with a list of previously visited
cells and associated (per-cell) information elements. The Handover Preparation procedures also trigger the target NG-
RAN node to start collection and storage of UE history Information and thus to propagate the collected information.
16 Verticals Support
16.1 URLLC
16.1.1 Overview
The support of Ultra-Reliable and Low Latency Communications (URLLC) services is facilitated by the introduction of
the mechanisms described in the following clauses. Please note however that those mechanisms need not be limited to
the provision of URLLC services. Furthermore, RRC can associate logical channels with different SR configurations,
for instance, to provide more frequent SR opportunities to URLLC services.
PDCP
RLC RLC
primary secondary
Primary Secondary
LCH LCH
3GPP
Release 16 117 3GPP TS 38.300 V16.21.0 (2020-073)
NOTE: PDCP control PDUs are not duplicated and always submitted to the primary RLC entity.
When configuring duplication for a DRB, RRC also sets the initial state of PDCP duplication (either activated or
deactivated) at the time of (re-)configuration. After the configuration, the PDCP duplication state can then be
dynamically controlled by means of a MAC control element and in DC, the UE applies the MAC CE commands
regardless of their origin (MCG or SCG). When duplication is configured for an SRB the state is always active and
cannot be dynamically controlled. When configuring duplication for a DRB with more than one secondary RLC entity,
RRC also sets the initial state of each of them (i.e. either activated or deactivated). Subsequently, a MAC CE can be
used to dynamically control whether each of the configured secondary RLC entities for a DRB should be activated or
deactivated, i.e. which of the RLC entities shall be used for duplicate transmission. Primary RLC entity cannot be
deactivated. When duplication is deactivated for a DRB, all secondary RLC entities associated to this DRB are
deactivated. When a secondary RLC entity is deactivated, it is not re-established, the HARQ buffers are not flushed,
and the transmitting PDCP entity should indicate to the secondary RLC entity to discard all duplicated PDCP PDUs.
Editor’s note: For NR-DC, it is FFS how the nodes can coordinate RLC entities activation/deactivation between
each other (pending RAN3 discussions)
When activating duplication for a DRB, NG-RAN should ensure that at least one serving cell is activated for each
logical channel of the DRB; and when the deactivation of SCells leaves no serving cells activated for a logical channel
of the DRB, NG-RAN should ensure that duplication is also deactivated.
When duplication is activated, the original PDCP PDU and the corresponding duplicate(s) shall not be transmitted on
the same carrier. The primary and secondary logical channels can either belong to the same MAC entity (referred to as
CA duplication) or to different ones (referred to as DC or DC+CA duplication). CA duplication can be configured
together with DC duplication when duplication over more than two legs is configured in the UE. In CA duplication,
logical channel mapping restrictions are used in MAC to ensure that the primary and secondary logical channels are not
sent on the same carrier. When CA duplication is configured for an SRB, one of the logical channels associated to the
SRB is mapped to SpCell.
When CA duplication is deactivated for a DRB, the logical channel mapping restrictions of the primary and secondary
logical channels are lifted for as long as duplication remains deactivated.
When an RLC entity acknowledges the transmission of a PDCP PDU, the PDCP entity shall indicate to the other RLC
entity(ies) to discard it. In addition, in case of CA duplication, when an RLC entity restricted to only SCell(s) reaches
the maximum number of retransmissions for a PDCP PDU, the UE informs the gNB but does not trigger RLF.
For scheduling data packets with higher reliability, 64QAM MCS tables containing entries with lower spectral
efficiency are introduced for both downlink and uplink. The tables are different for CP-OFDM and DFT-s-OFDM. The
MCS tables can be configured semi-statically or dynamically. The dynamic signalling of MCS table is supported by
configuring UE with MCS-C-RNTI, where the scrambling of DCI CRC by MCS-C-RNTI indicates the 64QAM MCS
tables with entries of lower spectral efficiency.
3GPP
Release 16 118 3GPP TS 38.300 V16.21.0 (2020-073)
disjoint user plane paths according to the redundancy information received from the 5GC. The RAN shall ensure that
the resources of the data radio bearers for the two redundant PDU sessions are isolated. If the RAN cannot satisfy the
disjoint user plane requirement, the redundant PDU sessions may be kept or not kept according to the RAN local
configuration. The redundancy information is transferred to the target NG-RAN node in case of handover.
16.1.6.2 Redundant data transmission via single UPF and single RAN node
Two NG-U tunnels are setup between single UPF and single NG-RAN node for redundant transmission of the QoS
flows when PDU session setup or modification is initiated. The two NG-U tunnels are transferred via disjointed
transport layer paths. The 5GC provides the indicator per QoS flow to the NG-RAN for the redundant transmission. For
downlink, the NG-RAN node eliminates the duplicated packets per QoS flow. For uplink, the NG-RAN node replicates
the packets and transmits them via the two NG-U tunnels. The indicator per QoS flow for redundant transmission is
transferred to the target NG-RAN node in case of handover.
- Network ability to support IMS voice sessions, i.e. ability to support QoS flows with 5QI for voice and IMS
signalling (see clause 12 and TS 23.501 [3]), or through EPC System fallback;
The capabilities indications check is handled at NAS layer. To maintain the voice service in NG-RAN, the UE provides
additional capabilities over RRC (see TS 38.331 [12]), that are used to determine accurate NR voice support options.
Further MMTEL IMS voice and video enhancements are facilitated by the mechanisms described in the following
clauses.
For uplink or downlink bit rate adaptation, gNB may send a recommended bit rate to the UE to inform the UE on the
currently recommended transport bit rate on the local uplink or downlink, which the UE may use in combination with
other information to adapt the bit rate, e.g. the UE may send a bit rate request to the peer UE via application layer
messages as specified in TS 26.114 [24], which the peer UE may use in combination with other information to adapt the
codec bit rate. The recommended bit rate is in kbps at the physical layer at the time when the decision is made.
The recommended bit rate for UL and DL is conveyed as a MAC Control Element (CE) from the gNB to the UE as
outlined in Figure 16.2.1.1-1.
UE gNB
3GPP
Release 16 119 3GPP TS 38.300 V16.21.0 (2020-073)
Based on the recommended bit rate from the gNB, a UE may initiate an end-to-end bit rate adaptation with its peer (UE
or MGW). The UE may also send a query message to its local gNB to check if a bit rate recommended by its peer can
be provided by the gNB. The UE is not expected to go beyond the recommended bit rate from the gNB.
The recommended bit rate query message is conveyed as a MAC CE from the UE to the gNB as outlined in Figure
16.2.1.1-2.
UE gNB
A prohibit timer can be configured per logical channel by the network to limit UEs sending frequent query MAC CEs.
Independent prohibit timers are used for each direction (uplink and downlink) to prohibit the UE from retransmitting
exactly the same query MAC CE to the gNB during the configured time.
A network slice always consists of a RAN part and a CN part. The support of network slicing relies on the principle that
traffic for different slices is handled by different PDU sessions. Network can realise the different network slices by
scheduling and also by providing different L1/L2 configurations.
Each network slice is uniquely identified by a S-NSSAI, as defined in TS 23.501 [3]. NSSAI (Network Slice Selection
Assistance Information) includes one or a list of S-NSSAIs (Single NSSAI) where a S-NSSAI is a combination of:
- mandatory SST (Slice/Service Type) field, which identifies the slice type and consists of 8 bits (with range is 0-
255);
- optional SD (Slice Differentiator) field, which differentiates among Slices with same SST field and consist of 24
bits.
The UE provides NSSAI (Network Slice Selection Assistance Information) for network slice selection in
RRCSetupComplete, if it has been provided by NAS (see clause 9.2.1.3). While the network can support large number
of slices (hundreds), the UE need not support more than 8 slices simultaneously. A BL UE or a NB-IoT UE supports a
maximum of 8 slices simultaneously.
Network Slicing is a concept to allow differentiated treatment depending on each customer requirements. With slicing,
it is possible for Mobile Network Operators (MNO) to consider customers as belonging to different tenant types with
each having different service requirements that govern in terms of what slice types each tenant is eligible to use based
on Service Level Agreement (SLA) and subscriptions.
The following key principles apply for support of Network Slicing in NG-RAN:
3GPP
Release 16 120 3GPP TS 38.300 V16.21.0 (2020-073)
- NG-RAN supports a differentiated handling of traffic for different network slices which have been pre-
configured. How NG-RAN supports the slice enabling in terms of NG-RAN functions (i.e. the set of network
functions that comprise each slice) is implementation dependent.
- NG-RAN supports the selection of the RAN part of the network slice, by NSSAI provided by the UE or the 5GC
which unambiguously identifies one or more of the pre-configured network slices in the PLMN.
- NG-RAN supports policy enforcement between slices as per service level agreements. It should be possible for a
single NG-RAN node to support multiple slices. The NG-RAN should be free to apply the best RRM policy for
the SLA in place to each supported slice.
Support of QoS
- For initial attach, the UE may provide NSSAI to support the selection of an AMF. If available, NG-RAN uses
this information for routing the initial NAS to an AMF. If the NG-RAN is unable to select an AMF using this
information or the UE does not provide any such information the NG-RAN sends the NAS signalling to one of
the default AMFs.
- For subsequent accesses, the UE provides a Temp ID, which is assigned to the UE by the 5GC, to enable the
NG-RAN to route the NAS message to the appropriate AMF as long as the Temp ID is valid (NG-RAN is aware
of and can reach the AMF which is associated with the Temp ID). Otherwise, the methods for initial attach
applies.
- The NG-RAN supports resource isolation between slices. NG-RAN resource isolation may be achieved by
means of RRM policies and protection mechanisms that should avoid that shortage of shared resources in one
slice breaks the service level agreement for another slice. It should be possible to fully dedicate NG-RAN
resources to a certain slice. How NG-RAN supports resource isolation is implementation dependent.
Access control
- By means of the unified access control (see clause 7.4), operator-defined access categories can be used to enable
differentiated handling for different slices. NG-RAN may broadcast barring control information (i.e. a list of
barring parameters associated with operator-defined access categories) to minimize the impact of congested
slices.
Slice Availability
- Some slices may be available only in part of the network. The NG-RAN supported S-NSSAI(s) is configured by
OAM. Awareness in the NG-RAN of the slices supported in the cells of its neighbours may be beneficial for
inter-frequency mobility in connected mode. It is assumed that the slice availability does not change within the
UE's registration area.
- The NG-RAN and the 5GC are responsible to handle a service request for a slice that may or may not be
available in a given area. Admission or rejection of access to a slice may depend by factors such as support for
the slice, availability of resources, support of the requested service by NG-RAN.
- In case a UE is associated with multiple slices simultaneously, only one signalling connection is maintained and
for intra-frequency cell reselection, the UE always tries to camp on the best cell. For inter-frequency cell
reselection, dedicated priorities can be used to control the frequency on which the UE camps.
- Slice awareness in NG-RAN is introduced at PDU session level, by indicating the S-NSSAI corresponding to the
PDU Session, in all signalling containing PDU session resource information.
3GPP
Release 16 121 3GPP TS 38.300 V16.21.0 (2020-073)
- It is the responsibility of the 5GC to validate that the UE has the rights to access a network slice. Prior to
receiving the Initial Context Setup Request message, the NG-RAN may be allowed to apply some
provisional/local policies, based on awareness of which slice the UE is requesting access to. During the initial
context setup, the NG-RAN is informed of the slice for which resources are being requested.
Hardware/software resource isolation is up to implementation. Each slice may be assigned with either shared or
dedicated radio resource up to RRM implementation and SLA.
To enable differentiated handling of traffic for network slices with different SLA:
- NG-RAN is configured with a set of different configurations for different network slices by OAM;
- To select the appropriate configuration for the traffic for each network slice, NG-RAN receives relevant
information indicating which of the configurations applies for this specific network slice.
16.3.4.1 General
In this clause, signalling flows related to the realization of network slicing in the NG-RAN are given.
3GPP
Release 16 122 3GPP TS 38.300 V16.21.0 (2020-073)
NG SETUP REQUEST
(List of S-NSSAI(s) supported per TA)
NG SETUP RESPONSE
(List of S-NSSAI(s) supported per PLMN)
NG SETUP REQUEST
(List of S-NSSAI(s) supported per TA)
NG SETUP RESPONSE
(List of S-NSSAI(s) supported per PLMN)
RRC(Connection)Setup Complete
(Temp ID optional, NSSAI optional)
INITIAL UE MESSAGE
validate UE rights
and slice(s)availability
In case a Temp ID is not available, the NG-RAN uses the NSSAI provided by the UE at RRC connection establishment
to select the appropriate AMF (the information is provided after MSG3 of the random access procedure). If such
information is also not available, the NG-RAN routes the UE to one of the configured default AMF(s).
The NG-RAN uses the list of supported S-NSSAI(s) previously received in the NG Setup Response message when
selecting the AMF with the NSSAI. This list may be updated via the AMF Configuration Update message.
Preconditions: RRC Connection Establishment, AMF Instance Selection, Provisional policies may be applied
3GPP
Release 16 123 3GPP TS 38.300 V16.21.0 (2020-073)
NG-RAN confirms the establishment of the resources for a PDU session associated to a certain network slice by
responding with the PDU Session Resource Setup Response message over the NG-C interface.
16.3.4.5 Mobility
To make mobility slice-aware in case of Network Slicing, S-NSSAI is introduced as part of the PDU session
information that is transferred during mobility signalling. This enables slice-aware admission and congestion control.
Both NG and Xn handovers are allowed regardless of the slice support of the target NG-RAN node i.e. even if the target
NG-RAN node does not support the same slices as the source NG-RAN node. An example for the case of connected
mode mobility across different Registration Areas is shown in Figure 16.3.4.5-1 for the case of NG based handover and
in Figure 16.3.4.5-2 for the case of Xn based handover.
UE in RRC_CONNECTED with
n slices configured at NAS level
and with m PDU sessions active
Handover preparation
to gNB2 triggered
HANDOVER REQUIRED
HANDOVER REQUEST
(Allowed NSSAI, one S-NSSAI per PDU Session)
HANDOVER REQUEST ACKNOWLEDGE
(List of accepted and failed PDU Sessions)
HANDOVER COMMAND
Handover Execution
Registration Area Update (alignment of slices supported in the new RA between UE and Network)
3GPP
Release 16 124 3GPP TS 38.300 V16.21.0 (2020-073)
UE in RRC_CONNECTED with
n slices configured at NAS level
and with m PDU sessions active
at AS level
HANDOVER REQUEST
(one S-NSSAI per PDU Session)
Slice Aware
Admission Control
Handover Execution
Registration Area Update (alignment of slices supported in the new RA between UE and Network)
- Earthquake and Tsunami Warning System: ETWS is a public warning system developed to meet the regulatory
requirements for warning notifications related to earthquake and/or tsunami events (see TS 22.168 [14]). ETWS
warning notifications can either be a primary notification (short notification) or secondary notification (providing
detailed information).
- Commercial Mobile Alert System: CMAS is a public warning system developed for the delivery of multiple,
concurrent warning notifications (see TS 22.268 [15]).
Different SIBs are defined for ETWS primary notification, ETWS secondary notification and CMAS notification.
Paging is used to inform UEs about ETWS indication and CMAS indication (see clause 9.2.5). UE monitors
ETWS/CMAS indication in its own paging occasion for RRC_IDLE and RRC_INACTIVE. UE monitors
ETWS/CMAS indication in any paging occasion for RRC Connected. Paging indicating ETWS/CMAS notification
triggers acquisition of system information (without delaying until the next modification period).
3GPP
Release 16 125 3GPP TS 38.300 V16.21.0 (2020-073)
broadcast indication (ims-EmergencySupport). The broadcast indicator is set to "support" if any AMF in a non-shared
environment or at least one of the PLMN's in a shared environment supports IMS emergency bearer services.
16.5.4 Fallback
RAT fallback towards E-UTRA connected to 5GC is performed when NR does not support Emergency Services and
System fallback towards E-UTRA connected to EPS is performed when 5GC does not support Emergency Services.
Depending on factors such as CN interface availability, network configuration and radio conditions, the fallback
procedure results in either CONNECTED state mobility (handover procedure) or IDLE state mobility (redirection) - see
TS 23.501 [3] and TS 38.331 [12].
An SNPN-capable UE supports the SNPN access mode. When the UE is set to operate in SNPN access mode, the UE
only selects and registers with SNPNs. When the UE is not set to operate in SNPN access mode, the UE performs
normal PLMN selection procedures.
16.6.2 Mobility
16.6.2.1 General
The same principles as described in 9.2 apply to SNPN except for what is described below.
UEs operating in SNPN access mode only (re)select cells within the selected/registered SNPN and a cell can only be
considered as suitable if the PLMN and NID broadcast by the cell matches the selected/registered SNPN.
An SNPN-only cell can only be suitable for its subscribers and is barred otherwise.
In addition, manual selection of SNPN(s) is supported, for which HRNN(s) can be optionally provided.
The roaming and access restrictions applicable to SNPN are described in subclause 9.4.
At the time of handover, cells that do not support the serving SNPN ID are not considered as candidate target cells by
the source NG-RAN node.
3GPP
Release 16 126 3GPP TS 38.300 V16.21.0 (2020-073)
The target NG-RAN node performs access control. In case it cannot accept the handover for the serving SNPN the
target NG-RAN node fails the handover including an appropriate cause value.
If the check is successful, the AMF sets up the UE-associated logical NG-connection and provides the NG-RAN node
with the mobility restrictions applicable for the SNPN.
If the check is not successful, the AMF shall reject setting up the UE-associated NG connection and inform the NG-
RAN node with an appropriate cause value as specified in TS 23.501 [3].
A CAG-capable UE can be configured with the following per PLMN (see clause 5.30.3.3 of TS 23.501 [3]):
- an Allowed CAG list containing the CAG identifiers which the UE is allowed to access; and
- a CAG-only indication if the UE is only allowed to access 5GS via CAG cells.
NR-NR Dual Connectivity is supported within PNI-NPN and across PLMN and PNI-NPN.
16.7.2 Mobility
16.7.2.1 General
The same principles as described in 9.2 apply to CAG cells except for what is described below.
Cell selection/reselection to CAG cells may be based on a UE autonomous search function, which determines itself
when/where to search, but cannot contradict the dedicated cell reselection priority information if any is stored.
A range of PCI values reserved by the network for use by CAG cells may be broadcast.
A CAG Member Cell for a UE is a cell broadcasting the identity of the selected PLMN, registered PLMN or equivalent
PLMN, and for that PLMN, a CAG identifier belonging to the Allowed CAG list of the UE for that PLMN. The UE
checks the suitability of CAG cells based on the Allowed CAG list provided by upper layers and a CAG-only cell can
only be suitable for its subscribers but can be acceptable for the rest.
NOTE: A non-CAG-capable UE (e.g. Rel-15 UE) considers a CAG-only cell as acceptable cell if the cell is not
barred to Rel-15 UEs, and if a PLMN ID without CAG list is broadcast and that PLMN is forbidden (e.g.
by use of a PLMN ID for which all registration attempts are rejected such that the PLMN ID becomes
forbidden).
When the UE is configured with a CAG-only indication, only CAG Member Cells can be suitable. A non-suitable cell
can be acceptable though if the UE is configured with a CAG-only indication for one of the PLMN broadcast by the
cell.
3GPP
Release 16 127 3GPP TS 38.300 V16.21.0 (2020-073)
In addition, manual selection of CAG cell(s) is supported, for which an HRNN(s) can be optionally provided.
The roaming and access restrictions applicable to PNI-NPN are described in subclause 9.4.
At the time of handover, the source NG-RAN node determines a target cell among the candidates which is compatible
with the received PNI-NPN restrictions.
At incoming handover, the target NG-RAN node receives the PNI-NPN mobility restrictions and checks that the
selected target cell is compatible with the received mobility restrictions.
In addition, each NG-RAN node informs the connected neighbour NG-RAN nodes of the list of supported CAG ID(s)
per cell in the appropriate Xn interface management procedures.
If the check is successful, the AMF sets up the UE-associated logical NG-connection and provides the NG-RAN node
with the list of CAGs allowed for the UE and, whether the UE is allowed to access non-CAG cells. This information is
used by the NG-RAN for access control of subsequent mobility.
If the check is not successful, the AMF shall reject setting up the UE-associated NG connection and inform the NG-
RAN node with an appropriate cause value as specified in TS 23.501 [3].
16.7.5 Paging
The NG-RAN node may receive a paging message including the list of CAGs allowed for the UE, and whether the UE
is allowed to access PLMN cells. The NG-RAN node may use this information to avoid paging in cells on which the
UE is not allowed to camp.
For UEs in RRC_INACTIVE state, the NG-RAN node may page a neighbour NG-RAN node including the list of
CAGs allowed for the UE, and whether the UE is allowed to access PLMN cells. The neighbour NG-RAN node may
use this information to avoid paging in cells on which the UE is not allowed to camp.
To support strict synchronization accuracy requirements of TSC applications, the gNB may signal 5G system time
reference information to the UE using unicast or broadcast RRC signalling with a granularity of 10 ns. Uncertainty
parameter may be included in reference time information to indicate its accuracy. The UE may indicate to the gNB a
preference to be provisioned with reference time information using UE Assistance Information procedure.
3GPP
Release 16 128 3GPP TS 38.300 V16.21.0 (2020-073)
Editor’s note: FFS how the need for reference time information can be determined for any given connected UE.
The gNB may also receive TSC Assistance Information (TSCAI), see TS 23.501 [3], from the Core Network, e.g.
during QoS flow establishment, or from another gNB during handover. TSCAI contains additional information about
the traffic flow such as burst arrival time and burst periodicity. TSCAI knowledge may be leveraged in the gNB’s
scheduler to more efficiently schedule periodic, deterministic traffic flows either via Configured Grants, Semi-Persistent
Scheduling or with dynamic grants.
16.9 Sidelink
16.9.1 General
In this subclause, an overview of NR sidelink communication and how NG-RAN supports NR sidelink communication
and V2X sidelink communication is given. V2X sidelink communication is are specified in TS 36.300 [2].
The NG-RAN architecture supports the PC5 interface as illustrated in Figure 16.9.1-1. Sidelink transmission and
reception over the PC5 interface are supported when the UE is inside NG-RAN coverage, irrespective of which RRC
state the UE is in, and when the UE is outside NG-RAN coverage.
NG-RAN
Xn
gNB ng-eNB
Uu
Uu
Inside
NG-RAN
UE UE Coverage
PC5
PC 5
5 PC Outside
NG-RAN
UE Coverage
Support of V2X services via the PC5 interface can be provided by NR sidelink communication and/or V2X sidelink
communication. NR sidelink communication may be used to support other services than V2X services.
NR sidelink communication can support one of three types of transmission modes for a pair of a Source Layer-2 ID and
a Destination Layer-2 ID in the AS:
- Support of one PC5-RRC connection between peer UEs for the pair;
- Transmission and reception of control information and user traffic between peer UEs in sidelink;
3GPP
Release 16 129 3GPP TS 38.300 V16.21.0 (2020-073)
- Transmission and reception of user traffic among UEs belonging to a group in sidelink;
16.9.2.1 Overview
The AS protocol stack for the control plane for SCCH for RRC in the PC5 interface consists of RRC, PDCP, RLC and
MAC sublayers, and the physical layer. The protocol stack of control plane PC5-C for SCCH for RRC is shown in
Figure 16.9.2.1-1.
UE A UE B
RRC RRC
PDCP PDCP
RLC RLC
MAC MAC
PHY PHY
Figure 16.9.2.1-1: PC5 cControl plane (PC5-C) protocol stack for SCCH for RRC.
For support of PC5-S protocol specified in TS 23.287 [40], PC5-S is located on top of PDCP, RLC and MAC sublayers,
and the physical layer in for the control plane protocol stack for SCCH for PC5-S,in the PC5 interface as shown in
Figure 16.9.2.1-2.
UE A UE B
PC5-S PC5-S
PDCP PDCP
RLC RLC
MAC MAC
PHY PHY
Figure 16.9.2.1-2: PC5 cControl plane (PC5-C) protocol stack for SCCH for PC5-S.
The AS protocol stack for SBCCH in the PC5 interface consists of RRC, RLC, MAC sublayers, and the physical layer
as shown below in Figure 16.9.2.1-3.
3GPP
Release 16 130 3GPP TS 38.300 V16.21.0 (2020-073)
UE A UE B
RRC RRC
RLC RLC
MAC MAC
PHY PHY
Figure 16.9.2.1-3: PC5 cControl plane (PC5-C) protocol stack for SBCCH.
The AS protocol stack for user plane in the PC5 interface consists of SDAP, PDCP, RLC and MAC sublayers, and the
physical layer. The protocol stack of user planePC5-U is shown in Figure 16.9.2.1-4.
UE A UE B
SDAP SDAP
PDCP PDCP
RLC RLC
MAC MAC
PHY PHY
Figure 16.9.2.1-4: PC5 uUser plane (PC5-U) protocol stack for STCH.
Sidelink Radio bearers (SLRB) are categorized into two groups: sidelink data radio bearers (SL DRB) for user plane
data and sidelink signalling radio bearers (SL SRB) for control plane data. Separate SL SRBs using different SCCHs are
configured for PC5-RRC and PC5-S signalling respectively.
16.9.2.2 MAC
The MAC sublayer provides the following services and functions over the PC5 interface in addition to the services and
functions specified in subclause 6.2.1:
- Packet filtering;
- Priority handling between uplink and sidelink transmissions for a given UE;
With LCP restrictions in MAC, only sidelink logical channels belonging to the same destination can be multiplexed into
a MAC PDU for every unicast, groupcast and broadcast transmission which is associated to the destination. NG-RAN
can also control whether a sidelink logical channel can utilise the resources allocated to a configured sidelink grant
Type 1 (see subclause 16.9.3.2).
For packet filtering, a SL-SCH MAC header including portions of both Source Layer-2 ID and a Destination Layer-2 ID
is added to each MAC PDU as specified in subclause 8.4. LCID included within a MAC subheader uniquely identifies a
logical channel within the scope of the Source Layer-2 ID and Destination Layer-2 ID combination.
- Sidelink Control Channel (SCCH): a sidelink channel for transmitting control information (i.e. PC5-RRC and
PC5-S messages) from one UE to other UE(s);
- Sidelink Traffic Channel (STCH): a sidelink channel for transmitting user information from one UE to other
UE(s);
3GPP
Release 16 131 3GPP TS 38.300 V16.21.0 (2020-073)
- Sidelink Broadcast Control Channel (SBCCH): a sidelink channel for broadcasting sidelink system information
from one UE to other UE(s).
The following connections between logical channels and transport channels exist:
16.9.2.3 RLC
The services and functions of the RLC sublayer as specified in subclause 6.3.2 are supported for sidelink. TM is used
for SBCCH. Both Either UM and or AM are is used in unicast transmission while only UM is used in groupcast or
broadcast transmission. For UM, only unidirectional transmission is supported for groupcast and broadcast.
16.9.2.4 PDCP
The services and functions of the PDCP sublayer as specified in subclause 6.4.1 are supported for sidelink with some
restrictions:
16.9.2.5 SDAP
The SDAP sublayer provides the following service and function over the PC5 interface:
There is one SDAP entity per destination for one of unicast, groupcast and broadcast which is associated to the
destination. Reflective QoS is not supported over the PC5 interface.
16.9.2.6 RRC
The RRC sublayer provides the following services and functions over the PC5 interface:
- Detection of sidelink radio link failure for a PC5-RRC connection based on indication from MAC or RLC.
A PC5-RRC connection is a logical connection between two UEs for a pair of Source and Destination Layer-2 IDs
which is considered to be established after a corresponding PC5 unicast link is established as specified in TS 23.287
[40]. There is one-to-one correspondence between the PC5-RRC connection and the PC5 unicast link. A UE may have
multiple PC5-RRC connections with one or more UEs for different pairs of Source and Destination Layer-2 IDs.
Separate PC5-RRC procedures and messages are used for a UE to transfer UE capability and sidelink configuration
including SL-DRB configuration to the peer UE. Both peer UEs can exchange their own UE capability and sidelink
configuration using separate bi-directional procedures in both sidelink directions.
If it is not interested in sidelink transmission, if sidelink RLF on the PC5-RRC connection is declared, or if the Layer-2
link release procedure is completed as specified in TS 23.287 [40] or if the T400 is expired as specified in TS 38.331
[12], UE releases the PC5-RRC connection.
3GPP
Release 16 132 3GPP TS 38.300 V16.21.0 (2020-073)
16.9.3.1 General
The UE can operate in two modes for resource allocation in sidelink:
- The UE can transmit data when inside NG-RAN coverage, irrespective of which RRC state the UE is in, and
when outside NG-RAN coverage;
- The UE autonomously selects transmission resources from resource pool(s)a pool of resources.
- For NR sidelink communication, the UE performs sidelink transmissions only on a single carrier.
In addition, NG-RAN can allocate sidelink resources to a UE with two types of configured sidelink grants:
- With type 1, RRC directly provides the configured sidelink grant only for NR sidelink communication;
- With type 2, RRC defines the periodicity of the configured sidelink grant while PDCCH can either signal and
activate the configured sidelink grant, or deactivate it. The PDCCH is addressed to SL-CS-RNTI for NR sidelink
communication and SL Semi-Persistent Scheduling V-RNTI for V2X sidelink communication.
Besides, NG-RAN can also semi-persistently allocate sidelink resources to the UE via the V-RNTI on PDCCH(s) for
V2X sidelink communication.
For the UE performing NR sidelink communication, there can be more than one configured sidelink grant activated at a
time on the carrier configured for sidelink transmission.
When beam failure or physical layer problem occurs on MCGNR Uu, the UE can continue using the configured sidelink
grant Type 1 until initiation of the RRC connection re-establishment procedure as specified in TS 38.331 [12]. During
handover, the UE can be provided with configured sidelink grants via handover command, regardless of the type. If
provided, the UE activates the configured sidelink grant Type 1 upon reception of the handover command or execution
of CHO.
The UE can send sidelink buffer status report to support scheduler operation in NG-RAN. The sidelink buffer status
reports refer to the data that is buffered in for a group of logical channels (LCG) per destination in the UE. Eight LCGs
are used for reporting of the sidelink buffer status reports. Two formats, which are SL BSR and truncated SL BSR, are
used.
For NR sidelink communication, the resource pool(s)pools of resources can be provided for a given validity area where
the UE does not need to acquire a new pool of resources while moving within the validity area, at least when this pool is
provided by SIB (e.g. reuse valid area of NR SIB). The NR SIB area scope mechanism as specified in TS 38.331 [12] is
reusedNR SIB validity mechanism is reused to enable validity area for SL resource pool configured via broadcasted
system information.
3GPP
Release 16 133 3GPP TS 38.300 V16.21.0 (2020-073)
The UE is allowed to temporarily use UE autonomous resource selection with random selection for sidelink
transmission based on configuration of the exceptional transmission resource pool as specified in TS 38.331 [12].
16.9.4 Uu Control
16.9.4.1 General
When a UE is inside NG-RAN coverage, NR sidelink communication and/or V2X sidelink communication can be
configured and controlled by NG-RAN via dedicated signalling or system information:
- The UE should support and be authorized to perform NR sidelink communication and/or V2X sidelink
communication in NG-RAN;
- If configured, the UE performs V2X sidelink communication as specified in TS 36.300 [2] unless otherwise
specified, with the restriction that the dynamic scheduling for V2X sidelink communication (i.e. based on SL-V-
RNTI) is not supported;
- NG-RAN can provide the UE with intra-carrier sidelink configuration, inter-carrier sidelink configuration and
anchor carrier which provides sidelink configuration via a Uu carrier for NR sidelink communication and/or
V2X Ssidelink communication;
- When the UE cannot simultaneously perform both NR sidelink transmission and NR uplink transmission in time
domain, prioritization between both transmissions is done based on their priorities and thresholds configured by
the NG-RAN. When the UE cannot simultaneously perform both V2X sidelink transmission and NR uplink
transmission in time domain, prioritization between both transmissions is done based on the priorities (i.e. PPPP)
of V2X sidelink communication and a threshold configured by the NG-RAN.
When a UE is outside NG-RAN coverage, SL DRB configuration(s) are preconfigured to the UE for NR sidelink
communication. If UE changes the RRC state but has not received the SL DRB configuration(s) for the new RRC state,
UE continues using the configuration obtained in the previous RRC state to perform sidelink data transmissions and
receptions until the configuration for the new RRC state is received.
NG-RAN provides RRCReconfiguration to the UE in order to provide the UE with dedicated sidelink configuration.
The RRCReconfiguration may include SL DRB configuration(s) for NR sidelink communication as well as mode 1
resource configuration and/or mode 2 resource configurationeither sidelink scheduling configuration or resource pool
configuration. If UE has received SL DRB configuration via system information, UE should continue using the
configuration to perform sidelink data transmissions and receptions until a new configuration is received via the
RRCReconfiguration.
NG-RAN may also configure measurement and reporting of CBR and reporting of location information to the UE via
RRCReconfiguration.
During handover, the UE performs sidelink transmission and reception based on configuration of the exceptional
transmission resource pool or configured sidelink grant Type 1 and reception resource pool of the target cell as provided
in the handover command.
3GPP
Release 16 134 3GPP TS 38.300 V16.21.0 (2020-073)
When the UE performs cell reselection, the UE interested in V2X service(s) considers at least whether NR sidelink
communication and/or V2X sidelink communication are supported by the cell. The UE may consider the following
carrier frequency as the highest priority frequency, except for the carrier only providing the anchor carrier:
- the frequency providing both NR sidelink communication configuration and V2X sidelink communication
configuration, if configured to perform both NR sidelink communication and V2X sidelink communication;
- the frequency providing NR sidelink communication configuration, if configured to perform only NR sidelink
communication.
- the frequency providing V2X sidelink communication configuration, if configured to perform only V2X sidelink
communication.
17 Interference Management
A remote interference scenario may involve a number of victim and aggressor cells, where the gNBs execute Remote
Interference Management (RIM) coordination on behalf of their respective cells. Aggressor and victim gNBs can be
grouped into semi-static sets, where each cell is assigned a set ID, and is configured with a RIM Reference Signal
(RIM-RS) and the radio resources associated with the set ID. Each aggressor gNB can be configured with multiple set
IDs and each victim gNB can be configured with multiple set IDs, whereas each cell can have at most one victim set ID
and one aggressor set ID. Consequently, each gNB can be an aggressor and a victim at the same time.
To mitigate remote interference, the network enables RIM frameworks for coordination between victim and aggressor
gNBs. The coordination communication in RIM frameworks can be wireless- or backhaul-based. The backhaul-based
RIM framework uses a combination of wireless and backhaul communication, while in the wireless framework, the
communication is purely wireless.
In both frameworks, all gNBs in a victim set simultaneously transmit an identical RIM reference signal carrying the
victim set ID over the air.
In the wireless framework, upon reception of the RIM reference signal from the victim set, aggressor gNBs undertake
RIM measures, and send back a RIM reference signal carrying the aggressor set ID. The RIM reference signal sent by
the aggressor is able to provide information whether the atmospheric ducting phenomenon exists. The victim gNBs
realize the atmospheric ducting phenomenon have ceased upon not receiving any reference signal sent from aggressors.
In the RIM backhaul framework, upon reception of the RIM reference signal from the victim set, aggressor gNBs
undertake RIM measures, and establish backhaul coordination towards the victim gNB set. The backhaul messages are
sent from individual aggressor gNBs to individual victim gNB, where the signalling is transparent to the core network.
The RIM backhaul messages from aggressor to victim gNBs carry the indication about the detection or disappearance of
RIM reference signal. Based on the indication from the backhaul message, the victim gNBs realize whether the
atmospheric ducting and the consequent remote interference have ceased.
In both frameworks, upon realizing that the atmospheric ducting has disappeared, the victim gNBs stop transmitting the
RIM reference signal.
3GPP
Release 16 135 3GPP TS 38.300 V16.21.0 (2020-073)
To mitigate the CLI, the network signalling enables the involved gNBs can to exchange and coordinate their intended
TDD DL-UL configurations over Xn and F1 interfaces; and. Based on the information exchanged, a receiving gNB can
adjust its transmission pattern to avoid (causing) the CLI. Moreover, to support flexible resource adaptation for TDD
cells, the victim UEs can be configured to perform CLI measurements. There are tTwo types of CLI measurements are
supported for CLI managementx:
- SRS-RSRP measurement in which the UE measures SRS-RSRP over configured SRS resources of transmissions
of one or multiple aggressor UE(s);
- CLI-RSSI measurement in which the UE measures the total received power observed over configured RSSI
resources.
Both event triggered and periodic reporting are supported for both SRS-RSRP and CLI-RSSI measurements. Layer 3
filtering appliesis applied to CLI measurement results and both event triggered and periodic reporting are supported..
3GPP
Release 16 136 3GPP TS 38.300 V16.21.0 (2020-073)
Annex A (informative):
QoS Handling in RAN
3. RRCReconfiguration
4. DRB(s) established
5. RRCReconfigurationComplete
2. AMF sends a PDU SESSION RESOURCE SETUP REQUEST message to gNB, which includes the NAS
message to be sent to the UE with NAS QoS related information.
3. gNB sends an RRCReconfiguration message to UE including the configuration of at least one DRB and the NAS
message received at Step 2.
4. UE establishes the DRB(s) for the new PDU session and creates the QFI to DRB mapping rules.
7. User Plane Data can then be exchanged between UE and gNB over DRB(s) according to the mapping rules and
between UPF and gNB over the tunnel for the PDU session. QFI marking over Uu is optional (see clause 12)
while QFI marking over NG-U is always present.
3GPP
Release 16 137 3GPP TS 38.300 V16.21.0 (2020-073)
1. DL Packet (QFI)
Figure A.2-1: DL data with new QFI sent over existing DRB
2. gNB decides to send the new QoS flow over an existing DRB.
NOTE: If gNB decides to send it over a new DRB, it needs to establish the DRB first.
3. gNB sends the DL packet over the selected DRB with the new QFI and RDI set in the SDAP header.
4. UE identifies the QFI and RDI in the received DL packet and the DRB on which the packet was received. The
AS mapping rules are then updated accordingly.
5. User Plane Data for the new QoS flow can then be exchanged between UE and gNB over the DRB according to
the updated mapping rules and between UPF and gNB over the tunnel for the PDU session.
1. DL Packet (QFI)
3. RRCReconfiguration
5. RRCReconfigurationComplete
Figure A.3-1: DL data with new QFI sent over existing DRB
3GPP
Release 16 138 3GPP TS 38.300 V16.21.0 (2020-073)
2. gNB decides to send the new QoS flow over an existing DRB using explicit RRC signalling for updating the AS
mapping rules.
3. gNB sends an RRCReconfiguration message to UE with the new QFI to DRB mapping rule. gNB may also
decide to update the DRB configuration if required to meet the QoS requirements for the new QoS Flow.
4. UE updates the QFI to DRB mapping rules and configuration (if received).
6. User Plane Data for the new QoS flow can then be exchanged between UE and gNB over the DRB according to
the updated mapping rules and between UPF and gNB over the tunnel for the PDU session.
3. RRCReconfiguration
5. RRCReconfigurationComplete
Figure A.4-1: DL data with new QoS Flow ID sent over new DRB with explicit signalling
1. gNB receives a PDU SESSION RESOURCE MODIFY REQUEST message from AMF for a new QoS flow.
2. If gNB cannot find an existing DRB to map this new QoS flow, it decides to establish a new DRB.
3. gNB sends an RRCReconfiguration message to UE including the DRB configuration with the new QFI to DRB
mapping rule and the NAS message received at step 1.
4. UE establishes the DRB for the new QoS flow associated with this PDU session and updates the mapping rules.
7. User Plane Data can then be exchanged between UE and gNB over DRB(s) according to the mapping rules and
between UPF and gNB over the tunnel for the PDU session.
3GPP
Release 16 139 3GPP TS 38.300 V16.21.0 (2020-073)
3. RRCReconfiguration
5. RRCReconfigurationComplete
1. gNB receives a PDU SESSION RESOURCE MODIFY REQUEST message from AMF to release a QoS flow.
2. The gNB decides to release corresponding the QFI to DRB mapping rule. Since the DRB also carries other QoS
flows, the DRB is not released.
3. gNB sends an RRCReconfiguration message to UE to release the QFI to DRB mapping rule.
4. UE updates the AS QFI to DRB mapping rules to release this QFI to DRB mapping rule.
3GPP
Release 16 140 3GPP TS 38.300 V16.21.0 (2020-073)
1. UL packet (QFI)
2. Default DRB
if no mapping rules
5. RRCReconfiguration
Figure A.6-1: UL packet with a new QoS flow for which a mapping does not exist in UE
0. PDU session and DRBs (including a default DRB) have been already established.
2. UE uses the QFI of the packet to map it to a DRB. If there is no mapping of the QFI to a DRB in the AS
mapping rules for this PDU session, then the packet is assigned to the default DRB.
3. UE sends the UL packet on the default DRB. The UE includes the QFI in the SDAP header.
5. If gNB wants to use a new DRB for this QoS flow, it sets up one. It can also choose to move the QoS flow to an
existing DRB using RQoS or RRC signalling (see clauses A.2 and A.3).
6. User Plane Data for the new QoS flow can then be exchanged between UE and gNB over the DRB according to
the updated mapping rules and between UPF and gNB over the tunnel for the PDU session.
3GPP
Release 16 141 3GPP TS 38.300 V16.21.0 (2020-073)
Annex B (informative):
Deployment Scenarios
DL+UL coverage
DL only coverage
SUL coverage
UL DL + UL
frequency
SUL High NR frequency
3GPP
Release 16 142 3GPP TS 38.300 V16.21.0 (2020-073)
Carrier
RMSI RMSI
NCGI = 5 NCGI = 6
UE 1 Initial BWP
connected
to NCGI 5 Dedicated BWP1
Dedicated BWP2
UE 2 Initial BWP
connected
to NCGI 5 Dedicated BWP1
UE 3 Initial BWP
connected
to NCGI 6 Dedicated BWP1
Dedicated BWP2
Frequency
- Scenario A: Carrier aggregation between NR in licensed spectrum (PCell) and NR in shared spectrum (SCell);
- Scenario B: Dual connectivity between LTE in licensed spectrum and NR in shared spectrum (PSCell);
3GPP
Release 16 143 3GPP TS 38.300 V16.21.0 (2020-073)
Annex C (informative):
I-RNTI Reference Profiles
The I-RNTI provides the new NG-RAN node a reference to the UE context in the old NG-RAN node. How the new
NG-RAN node is able to resolve the old NG-RAN ID from the I-RNTI is a matter of proper configuration in the old and
new NG-RAN node.
Table C-1 below provides some typical partitioning of a 40bit I-RNTI, assuming the following content:
- NG-RAN node address index: information to identify the NG-RAN node that has allocated the UE specific
part;
NOTE: RAT-specific information may be introduced in a later release, containing information to identify the
RAT of the cell within which the UE was sent to RRC_INACTIVE. This version of the specification only
supports intra-RAT mobility of UEs in RRC_INACTIVE.
- PLMN-specific information: information supporting network sharing deployments, providing an index to the
PLMN ID part of the Global NG-RAN node identifier.
3GPP
Release 16 144 3GPP TS 38.300 V16.21.0 (2020-073)
Annex D (informative):
SPID ranges and mapping of SPID values to cell reselection
and inter-RAT/inter frequency handover priorities
The SPID values are defined in Annex I of TS 36.300 [2].
From the SPID reference values, only the SPID=253 also applies for 5GC.
3GPP
Release 16 145 3GPP TS 38.300 V16.21.0 (2020-073)
Annex E:
NG-RAN Architecture for Radio Access Network Sharing
with multiple cell ID broadcast (informative)
Each NG-RAN node serving a cell identified by a Cell Identity associated with either a subset of PLMNs, or a subset of
SNPNs, or a subset of PNI-NPNs is connected to another NG-RAN node via a single Xn-C interface instance.
Xn-C interface instances terminating at NG-RAN nodes which share the same physical radio resources may share the
same signalling transport resources. If this option is applied:
- Non-UE associated signalling is associated to an Xn-C interface instance by including an Interface Instance
Indication in the XnAP message;
- Node related, non-UE associated Xn-C interface signalling may provide information destined for multiple
logical nodes in a single XnAP procedure instance once the Xn-C interface instance is setup;
NOTE 1: If the Interface Instance Indication corresponds to more than one interface instance, the respective XnAP
message carries information destined for multiple logical nodes.
- A UE associated signalling connection is associated to an Xn-C interface instance by allocating values for the
corresponding NG-RAN node UE XnAP IDs so that they can be mapped to that Xn-C interface instance.
NOTE 2: One possible implementation is to partition the value ranges of the NG-RAN node UE XnAP IDs and
associate each value range with an Xn-C interface instance.
Annex F (informative):
Change history
Change history
Date Meeting TDoc CR Rev Cat Subject/Comment New
Version
2017.03 RAN2 R2-1702627 - - - First version. 0.1.0
97bis
2017.04 RAN2 R2-1703825 - - - Editorial Updates: 0.1.1
97bis - Stage 2 Details of ARQ operation marked as FFS
- Placeholder for CU/DU Split overview added
- Outdated editor notes removed
- Protocol Architecture updated
- NG-RAN terminology aligned
- Header placement in the L2 overview put as FFS
2017.04 RAN2 R2-1703952 - - - Editorial Updates: 0.1.2
97bis - description of measurements for mobility clarified
- some cell reselection details put FFS
- outdated references removed
2017.04 RAN2 R2-1704296 - - - Editorial updates: 0.1.3
98 - NG interfaces naming aligned to RAN3
- 5GC used consistently
- Statement on lossless delivery removed from 9.3.2
- Overview of PDCP function for CP detailed
2017.05 RAN2 R2-1704298 - - - Agreements of RAN2#97bis captured: 0.2.0
98 - overview of duplication operation
- RLC modes for DRBs and SRBs
- Condition for lossless mobility
- L2 handling at handover
- RLF triggers
- Measurement details (filtering, beams, quality…)
- QoS flow handling in DC
- RACH procedure message usage for on-demand SI
- Random Access Procedure triggers
- DRX baseline
2017.05 RAN2 R2-1704452 - - - RAN3 agreements captured (R3-171329) 0.2.1
3GPP
Release 16 146 3GPP TS 38.300 V16.21.0 (2020-073)
3GPP
Release 16 147 3GPP TS 38.300 V16.21.0 (2020-073)
3GPP
Release 16 148 3GPP TS 38.300 V16.21.0 (2020-073)
RP-81 RP-181942 0080 1 F QoS Flow to DRB Remapping during Handover 15.3.0
RP-81 RP-181941 0081 1 F NR Corrections (38.300 Baseline CR covering RAN3-101 agreements) 15.3.0
2018/10 - - - - - Changes of CR0035 rev 3 were undone since this CR was actually not 15.3.1
approved by RAN #81 as it was not submitted to RAN #81
2018/12 RP-82 RP-182656 0028 5 F Slice Aware Access Control 15.4.0
RP-82 RP-182649 0035 4 B ECN support in NR 15.4.0
RP-82 RP-182653 0074 2 F Corrections to System Information 15.4.0
RP-82 RP-182655 0075 2 F Stage2 Corrections on UE capability 15.4.0
RP-82 RP-182657 0083 3 F Clarifications on dynamic scheduling 15.4.0
RP-82 RP-182658 0084 2 F Clarification of AMF Switch in RRC_INACTIVE 15.4.0
RP-82 RP-182657 0086 2 F Correction to the system information in Handover Request message 15.4.0
RP-82 RP-182654 0087 2 F Capture signalling flows where the last serving gNB moves the UE to 15.4.0
RRC_IDLE
RP-82 RP-182649 0088 2 F Scheduling Request Overview 15.4.0
RP-82 RP-182649 0089 1 F System Information Provisioning 15.4.0
RP-82 RP-182657 0090 3 F Transport of NAS Messages 15.4.0
RP-82 RP-182649 0091 2 F SON Overview 15.4.0
RP-82 RP-182649 0093 2 F RDI handling for data forwarding at handover 15.4.0
RP-82 RP-182656 0095 2 F Clarification on basic voice support 15.4.0
RP-82 RP-182659 0096 2 F Relation between SSB and SS-Burst 15.4.0
RP-82 RP-182659 0097 3 F Defining inter-system and intra-system handover 15.4.0
RP-82 RP-182659 0099 3 F Correction regarding key deletion at state transition to RRC_IDLE 15.4.0
RP-82 RP-182656 0102 2 F Clarification on SSB-based BM, RLM and BFD 15.4.0
RP-82 RP-182653 0103 1 F Correction to beam failure detection in Stage-2 15.4.0
RP-82 RP-182655 0106 2 F Random Access Triggers 15.4.0
RP-82 RP-182649 0107 - F Correction of BWP adaptation 15.4.0
RP-82 RP-182657 0108 1 F Notification Control 15.4.0
RP-82 RP-182665 0109 1 F PDU Session AMBR 15.4.0
RP-82 RP-182649 0110 - F Logical channel restrictions clarifications and correction 15.4.0
RP-82 RP-182666 0111 2 F CORESET#0 15.4.0
RP-82 RP-182659 0115 2 F Corrections to activation of SCells 15.4.0
RP-82 RP-182657 0116 1 F Description of RLM aspects 15.4.0
RP-82 RP-182651 0120 - F Minor corrections to paging 15.4.0
RP-82 RP-182659 0125 1 F Clarification on power ramping counter 15.4.0
RP-82 RP-182658 0127 1 F Corrections on the descriptions of active BWP 15.4.0
RP-82 RP-182653 0131 - F Stage 2 Correction on Mobility in RRC_IDLE 15.4.0
RP-82 RP-182660 0133 1 F Stage 2 CR on Measurement gap configuration scenarios 15.4.0
RP-82 RP-182659 0134 1 F CR on the carrier selection for random access 15.4.0
RP-82 RP-182659 0137 1 F Corrections on Multi-Radio dual connectivity 15.4.0
RP-82 RP-182670 0138 2 F Inter-system HO 15.4.0
RP-82 RP-182787 0139 - F Baseline CR for TS 38.300 15.4.0
RP-82 RP-182799 0140 - B Addition of Annex X for SPID ranges 15.4.0
2019/03 RP-83 RP-190542 0142 2 F RRC Reject Handling for MPS and MCS 15.5.0
RP-83 RP-190540 0143 - F Misalignments with other Specifications 15.5.0
RP-83 RP-190543 0146 2 F RLF triggering when RLC reaches maximum number of retransmission 15.5.0
RP-83 RP-190543 0147 1 F Correction on RLC modes for duplication 15.5.0
RP-83 RP-190545 0148 1 F Correction of Data Forwarding over Xn 15.5.0
RP-83 RP-190544 0149 - F Correction to RNAU without context relocation 15.5.0
RP-83 RP-190544 0150 - F Correction of handling of PDCP SN during Data Forwarding 15.5.0
RP-83 RP-190545 0151 1 F Correction of stage 2 for slicing 15.5.0
RP-83 RP-190544 0152 - F Energy Saving Support in R15 15.5.0
2019/06 RP-84 RP-191373 0154 - F CQI and MCS for URLLC 15.6.0
RP-84 RP-191373 0155 1 F Miscellaneous Corrections 15.6.0
RP-84 RP-191373 0156 1 F CA Clarifications - RACH and Timing Advance 15.6.0
RP-84 RP-191373 0157 - F Cross Carrier Scheduling 15.6.0
RP-84 RP-191379 0159 1 F CR on 38.300 for SRB cell mapping for CA duplication 15.6.0
RP-84 RP-191380 0160 1 F Support of ongoing re-mapping on source side during SDAP mobility 15.6.0
RP-84 RP-191379 0161 - F Correction of data forwarding 15.6.0
RP-84 RP-191379 0162 - F Slicing information during handover 15.6.0
RP-84 RP-191380 0163 - F Corrections for support of data forwarding for reestablishment UE 15.6.0
RP-84 RP-191380 0164 - F Correction of QoS flow re-mapping before handover 15.6.0
RP-84 RP-191380 0165 - F Correction of NAS PDU 15.6.0
RP-84 RP-191380 0168 - F Support for network sharing 15.6.0
2019/09 RP-85 RP-192191 0171 1 F Correction on 5GC to EPC inter-RAT inter-system handover 15.7.0
2019/12 RP-86 RP-192934 0173 2 F Clarification on measurement gap configuration in NR SA 15.8.0
RP-86 RP-192934 0174 1 F KgNB derivation upon mobility 15.8.0
RP-86 RP-192934 0178 - F Correction on PUCCH transform precoding 15.8.0
RP-86 RP-192935 0181 - F Correction on mini-slot scheduling 15.8.0
RP-86 RP-192937 0182 - F Independent migration to IPv6 on NG-U 15.8.0
RP-86 RP-192938 0183 - F Correction of QoS flow re-mapping before handover 15.8.0
RP-86 RP-192944 0184 - B CR TS 38.300 Remote Interference Management 16.0.0
3GPP
Release 16 149 3GPP TS 38.300 V16.21.0 (2020-073)
RP-86 RP-192942 0185 - B Introduction of direct data forwarding for inter-system HO between 16.0.0
EPS and 5GS
2020/03 RP-87 RP-200349 0153 8 B CR to 38.300 on Integrated Access and Backhaul for NR 16.1.0
RP-87 RP-200347 0172 3 B Introduction of NR mobility enhancement 16.1.0
RP-87 RP-200360 0175 3 B Introduction of additional enhancements for eMTC 16.1.0
RP-87 RP-200361 0176 3 B Introduction of additional enhancements for NB-IoT 16.1.0
RP-87 RP-200350 0186 2 B Introduction of SRVCC from 5G to 3G 16.1.0
RP-87 RP-200351 0187 1 B Introduction of RACS and DL RRC segmentation 16.1.0
RP-87 RP-200335 0189 2 A Security and RRC Resume Request 16.1.0
RP-87 RP-200357 0190 - B Introduction of NR IDC solution 16.1.0
RP-87 RP-200344 0193 2 B Introduction of UE Power Saving in NR 16.1.0
RP-87 RP-200341 0194 2 B Introduction of on-demand SI procedure in RRC_CONNECTED 16.1.0
RP-87 RP-200353 0195 2 B Non-Public Networks 16.1.0
RP-87 RP-200342 0197 1 B Introduction of 2-step RACH 16.1.0
RP-87 RP-200348 0198 2 B CR for 38.300 for CA/DC enhancements 16.1.0
RP-87 RP-200341 0199 2 B Introduction of NR operation with Shared Spectrum Access to Stage 2 16.1.0
RP-87 RP-200343 0200 1 B Introduction of NR eURLLC 16.1.0
RP-87 RP-200340 0201 2 B Introduction of cross link interference management 16.1.0
RP-87 RP-200352 0203 - B Introduction of NR Industrial IoT features 16.1.0
RP-87 RP-200346 0204 - B Introduction of 5G V2X with NR Sidelink 16.1.0
RP-87 RP-200334 0207 - A Propagation of Roaming and Access Restriction information in NG- 16.1.0
RAN in non-homogenous NG-RAN node deployments
RP-87 RP-200345 0209 - B RAN1 stage 2 agreements related to positioning 16.1.0
2020/07 RP-88 RP-201165 0191 3 B Introduction of NeedForGap capability for NR measurement 16.2.0
RP-88 RP-201177 0211 2 F Corrections to Mobility Enhancements 16.2.0
RP-88 RP-201173 0214 1 F 4-step RA type figure description 16.2.0
RP-88 RP-201181 0215 1 F Stage-2 updates for IIOT 16.2.0
RP-88 RP-201171 0217 4 F CLI Corrections 16.2.0
RP-88 RP-201179 0220 1 C CR to 38.300 on Integrated Access and Backhaul for NR 16.2.0
RP-88 RP-201161 0222 1 A Clarification on pdcp-Duplication at RRC Reconfiguration 16.2.0
RP-88 RP-201164 0224 1 A Correction on bandwidth adaptation 16.2.0
RP-88 RP-201182 0225 2 F Miscellaneous corrections to NPN 16.2.0
RP-88 RP-201175 0227 1 F Missing SIB for positioning 16.2.0
RP-88 RP-201172 0229 1 F Miscellaneous corrections for NR operation with shared spectrum 16.2.0
RP-88 RP-201177 0230 2 F Corrections on NR mobility enhancements 16.2.0
RP-88 RP-201178 0236 2 F Clarification of DAPS configuration in MR-DC 16.2.0
RP-88 RP-201176 0237 1 F Introduction of on-demand SIB(s) procedure in RRC_CONNECTED 16.2.0
RP-88 RP-201190 0239 - C Introduction of eCall over IMS for NR 16.2.0
RP-88 RP-201176 0245 1 F Correction for NR sidelink communication 16.2.0
RP-88 RP-201165 0246 - A Global Cell Identities and Global NG-RAN Node Identities when NR 16.2.0
access is shared
RP-88 RP-201176 0248 1 B Support for Alternative QoS profiles 16.2.0
RP-88 RP-201211 0249 1 C Introduction of Inter-gNB CSI-RS Based Mobility 16.2.0
RP-88 RP-201165 0251 - A Correction of NAS NON Delivery 16.2.0
RP-88 RP-201177 0252 1 B Baseline CR for introducing Rel-16 NR mobility enhancement 16.2.0
RP-88 RP-201181 0253 - B NRIIOT Higher Layer Multi-Connectivity 16.2.0
RP-88 RP-201182 0254 1 B Introduction of Non Public Networks 16.2.0
RP-88 RP-201179 0255 - B Mapping of Uplink Traffic to Backhaul RLC Channels 16.2.0
RP-88 RP-201354 0256 - B Addition of SON features 16.2.0
3GPP