3GPP TS 38
3GPP TS 38.300 V17.3.0 (2022-12)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Radio Access Network;
NR; NR and NG-RAN Overall Description;
Stage 2
(Release 17)
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.
3GPP
Postal address
3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© 2022, 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
Contents
Foreword 11
1 Scope 12
2 References 12
3 Abbreviations and Definitions 14
3.1 Abbreviations 14
3.2 Definitions 17
4 Overall Architecture and Functional Split 20
4.1 Overall Architecture 20
4.2 Functional Split 21
4.3 Network Interfaces 23
4.3.1 NG Interface 23
4.3.1.1 NG User Plane 23
4.3.1.2 NG Control Plane 23
4.3.2 Xn Interface 24
4.3.2.1 Xn User Plane 24
4.3.2.2 Xn Control Plane 25
4.4 Radio Protocol Architecture 25
4.4.1 User Plane 25
4.4.2 Control Plane 26
4.5 Multi-Radio Dual Connectivity 26
4.6 Radio Access Network Sharing 26
4.7 Integrated Access and Backhaul 26
4.7.1 Architecture 26
4.7.2 Protocol Stacks 28
4.7.3 User-plane Aspects 29
4.7.3.1 Backhaul transport 29
4.7.3.2 Flow and Congestion Control 30
4.7.3.3 Uplink Scheduling Latency 30
4.7.4 Signalling procedures 30
4.7.4.1 IAB-node Integration 30
4.7.4.2 IAB-node Migration 31
4.7.4.3 Topological Redundancy 31
4.7.4.4 Backhaul RLF Recovery 31
4.7.4.5 OTA timing synchronization 31
4.7.4.6 Inter node discovery 32
4.8 Non-Public Networks 32
5 Physical Layer 32
5.1 Waveform, numerology and frame structure 32
5.2 Downlink 33
5.2.1 Downlink transmission scheme 33
5.2.2 Physical-layer processing for physical downlink shared channel 33
5.2.3 Physical downlink control channels 34
5.2.4 Synchronization signal and PBCH block 35
5.2.5 Physical layer procedures 36
5.2.5.1 Link adaptation 36
5.2.5.2 Power Control 36
5.2.5.3 Cell search 36
5.2.5.4 HARQ 36
5.2.5.5 Reception of SIB1 36
5.2.6 Downlink Reference Signals and Measurements for Positioning 36
5.3 Uplink 37
5.3.1 Uplink transmission scheme 37
5.3.2 Physical-layer processing for physical uplink shared channel 37
5.3.3 Physical uplink control channel 38
5.3.4 Random access 39
5.3.5 Physical layer procedures 39
5.3.5.1 Link adaptation 39
5.3.5.2 Uplink Power control 40
5.3.5.3 Uplink timing control 40
5.3.5.4 HARQ 40
5.3.5.5 Prioritization of overlapping transmissions 40
5.3.6 Uplink Reference Signals and Measurements for Positioning 40
5.4 Carrier aggregation 41
5.4.1 Carrier aggregation 41
5.4.2 Supplementary Uplink 41
5.4.3 Uplink Tx switching 41
5.5 Transport Channels 41
5.6 Access to Shared Spectrum 42
5.6.1 Overview 42
5.6.2 Channel Access Priority Classes 43
5.7 Sidelink 43
5.7.1 General 43
5.7.2 Sidelink resource allocation modes 44
5.7.3 Physical sidelink channels and signals 44
5.7.4 Physical layer procedures for sidelink 44
5.7.4.1 HARQ feedback 44
5.7.4.2 Power Control 44
5.7.4.3 CSI report 44
5.7.5 Physical layer measurement definition 44
6 Layer 2 45
6.1 Overview 45
6.2 MAC Sublayer 48
6.2.1 Services and Functions 48
6.2.2 Logical Channels 49
6.2.3 Mapping to Transport Channels 49
6.2.4 HARQ 49
6.3 RLC Sublayer 49
6.3.1 Transmission Modes 49
6.3.2 Services and Functions 50
6.3.3 ARQ 50
6.4 PDCP Sublayer 50
6.4.1 Services and Functions 50
6.5 SDAP Sublayer 51
6.6 L2 Data Flow 51
6.7 Carrier Aggregation 51
6.8 Dual Connectivity 53
6.9 Supplementary Uplink 53
6.10 Bandwidth Adaptation 53
6.11 Backhaul Adaptation Protocol Sublayer 54
6.11.1 Services and Functions 54
6.11.2 Traffic Mapping from Upper Layers to Layer-2 54
6.11.3 Routing, BAP Header Rewriting and BH-RLC-channel Mapping on BAP sublayer 55
6.12 Multiple Transmit/Receive Point Operation 57
7 RRC 57
7.1 Services and Functions 57
7.2 Protocol States 58
7.3 System Information Handling 59
7.3.1 Overview 59
7.3.2 Scheduling 61
7.3.3 SI Modification 61
7.4 Access Control 61
7.5 UE Capability Retrieval framework 62
7.6 Transport of NAS Messages 62
7.7 Carrier Aggregation 62
7.8 Bandwidth Adaptation 62
7.9 UE Assistance Information 63
7.10 Segmentation of RRC messages 63
8 NG Identities 63
8.1 UE Identities 63
8.2 Network Identities 64
8.3 User Data Transport on the CN-RAN Interface 65
8.4 NR sidelink communication and V2X sidelink communication related identities 65
9 Mobility and State Transitions 66
9.1 Overview 66
9.2 Intra-NR 67
9.2.1 Mobility in RRC_IDLE 67
9.2.1.1 Cell Selection 67
9.2.1.2 Cell Reselection 67
9.2.1.3 State Transitions 68
9.2.2 Mobility in RRC_INACTIVE 70
9.2.2.1 Overview 70
9.2.2.2 Cell Reselection 71
9.2.2.3 RAN-Based Notification Area 71
9.2.2.4 State Transitions 72
9.2.2.4.1 UE triggered transition from RRC_INACTIVE to RRC_CONNECTED 72
9.2.2.4.2 Network triggered transition from RRC_INACTIVE to RRC_CONNECTED 73
9.2.2.5 RNA update 74
9.2.2.6 Resume request responded with Release with Redirect, with UE context relocation 76
9.2.3 Mobility in RRC_CONNECTED 77
9.2.3.1 Overview 77
9.2.3.2 Handover 79
9.2.3.2.1 C-Plane Handling 79
9.2.3.2.2 U-Plane Handling 83
9.2.3.2.3 Data Forwarding 85
9.2.3.3 Re-establishment procedure 86
9.2.3.4 Conditional Handover 87
9.2.3.4.1 General 87
9.2.3.4.2 C-plane handling 88
9.2.3.4.3 U-plane handling 90
9.2.3.4.4 Data Forwarding 90
9.2.4 Measurements 90
9.2.5 Paging 93
9.2.6 Random Access Procedure 96
9.2.7 Radio Link Failure 98
9.2.8 Beam failure detection and recovery 100
9.2.9 Timing Advance 101
9.2.10 Extended DRX for RRC_IDLE and RRC_INACTIVE 101
9.3 Inter RAT 102
9.3.1 NR-E-UTRA mobility: Intra 5GC 102
9.3.1.1 Cell Reselection 102
9.3.1.2 Handover 102
9.3.1.3 Measurements 102
9.3.2 NR-E-UTRA mobility: From 5GC to EPC 102
9.3.2.1 Cell Reselection 102
9.3.2.2 Handover and redirection 103
9.3.2.3 Measurements 103
9.3.2.4 Data Forwarding for the Control Plane 103
9.3.2.5 Data Forwarding for the User Plane 104
9.3.3 NR-E-UTRA mobility: From EPC to 5GC 104
9.3.3.1 Data Forwarding for the Control Plane 104
9.3.3.2 Data Forwarding for the User Plane 105
9.3.4 NR-UTRA mobility 105
9.3.4.1 Handover with SRVCC operation 105
9.3.4.2 Measurements 106
9.4 Roaming and Access Restrictions 106
10 Scheduling 106
10.1 Basic Scheduler Operation 106
10.2 Downlink Scheduling 107
10.3 Uplink Scheduling 107
10.4 Measurements to Support Scheduler Operation 108
10.5 Rate Control 109
10.5.1 Downlink 109
10.5.2 Uplink 109
10.6 Activation/Deactivation Mechanism 110
10.7 E-UTRA-NR Cell Resource Coordination 110
10.8 Cross Carrier Scheduling 110
10.9 IAB Resource Configuration 111
11 UE Power Saving 112
12 QoS 113
12.1 Overview 113
12.2 Explicit Congestion Notification 116
13 Security 116
13.1 Overview and Principles 116
13.2 Security Termination Points 118
13.3 State Transitions and Mobility 118
14 UE Capabilities 118
15 Self-Configuration and Self-Optimisation 120
15.1 Definitions 120
15.2 Void 120
15.3 Self-configuration 120
15.3.1 Dynamic configuration of the NG-C interface 120
15.3.1.1 Prerequisites 120
15.3.1.2 SCTP initialization 120
15.3.1.3 Application layer initialization 120
15.3.2 Dynamic Configuration of the Xn interface 121
15.3.2.1 Prerequisites 121
15.3.2.2 SCTP initialization 121
15.3.2.3 Application layer initialization 121
15.3.3 Automatic Neighbour Cell Relation Function 121
15.3.3.1 General 121
15.3.3.2 Intra-system Automatic Neighbour Cell Relation Function 122
15.3.3.3 Void 123
15.3.3.4 Void 123
15.3.3.5 Inter-system Automatic Neighbour Cell Relation Function 123
15.3.4 Xn-C TNL address discovery 124
15.4 Support for Energy Saving 125
15.4.1 General 125
15.4.2 Solution description 125
15.4.2.1 Intra-system energy saving 125
15.4.2.2 Inter-system energy saving 125
15.4.3 O&M requirements 125
15.5 Self-optimisation 126
15.5.1 Support for Mobility Load Balancing 126
15.5.1.1 General 126
15.5.1.2 Load reporting for intra-RAT and intra-system inter-RAT load balancing 126
15.5.1.4 Adapting handover and/or reselection configuration 127
15.5.1.5 Load reporting for inter-system load balancing 127
15.5.2 Support for Mobility Robustness Optimization 127
15.5.2.1 General 127
15.5.2.2 Connection failure 128
15.5.2.2.1 General 128
15.5.2.2.2 Connection failure due to intra-system mobility 128
15.5.2.2.3 Connection failure due to inter-system mobility 129
15.5.2.3 Inter-system Unnecessary HO 130
15.5.2.4 Inter-system Ping-pong 131
15.5.2.5 O&M Requirements 131
15.5.2.6 PSCell change failure 131
15.5.2.7 Successful HO 131
15.5.3 Support for RACH Optimization 132
15.5.4 UE History Information from the UE 132
15.5.5 Support for Coverage and Capacity Optimisation 132
15.5.5.1 General 132
15.5.5.2 OAM requirements 133
15.5.5.3 Dynamic coverage configuration changes 133
15.5.6 Support for PCI Optimisation 133
15.5.6.1 Centralized PCI Assignment 133
15.5.6.2 Distributed PCI Assignment 133
16 Verticals Support 133
16.1 URLLC 133
16.1.1 Overview 133
16.1.2 LCP Restrictions 133
16.1.3 Packet Duplication 134
16.1.4 CQI and MCS 135
16.1.5 DCI formats 135
16.1.6 Higher layer multi-connectivity 135
16.1.6.1 Redundant user plane paths based on dual connectivity 135
16.1.6.2 Redundant data transmission via single UPF and single RAN node 135
16.1.7 URLLC in Unlicensed Controlled Environment 135
16.1.8 PUCCH cell switching for TDD cells 135
16.2 IMS Voice 136
16.2.0 Support for IMS voice 136
16.2.1 Support for MMTEL IMS voice and video enhancements 136
16.2.1.1 RAN-assisted codec adaptation 136
16.2.1.2 MMTEL voice quality/coverage enhancements 137
16.3 Network Slicing 137
16.3.1 General Principles and Requirements 137
16.3.2 AMF and NW Slice Selection 139
16.3.2.1 CN-RAN interaction and internal RAN aspects 139
16.3.2.2 Radio Interface Aspects 139
16.3.3 Resource Isolation and Management 139
16.3.3.1 General 139
16.3.3.2 Handling of Slice Resources 139
16.3.3a Slice-based cell reselection 140
16.3.4 Signalling Aspects 140
16.3.4.1 General 140
16.3.4.2 AMF and NW Slice Selection 140
16.3.4.3 UE Context Handling 141
16.3.4.4 PDU Session Setup Handling 141
16.3.4.5 Mobility 141
16.4 Public Warning System 142
16.5 Emergency Services 143
16.5.1 Overview 143
16.5.2 IMS Emergency call 143
16.5.3 eCall over IMS 143
16.5.4 Fallback 143
16.6 Stand-Alone NPN 144
16.6.1 General 144
16.6.2 Mobility 144
16.6.2.1 General 144
16.6.2.2 Inactive Mode 144
16.6.2.3 Connected Mode 144
16.7 Public Network Integrated NPN 145
16.7.1 General 145
16.7.2 Mobility 146
16.7.2.1 General 146
16.7.2.2 Inactive Mode 146
16.7.2.3 Connected Mode 146
16.7.3 Self-Configuration for PNI-NPN 146
16.7.4 Access Control 146
16.7.5 Paging 147
16.8 Support for Time Sensitive Communications 147
16.9 Sidelink 148
16.9.1 General 148
16.9.2 Radio Protocol Architecture for NR sidelink communication 149
16.9.2.1 Overview 149
16.9.2.2 MAC 151
16.9.2.3 RLC 152
16.9.2.4 PDCP 152
16.9.2.5 SDAP 152
16.9.2.6 RRC 152
16.9.3 Radio Resource Allocation 152
16.9.3.1 General 152
16.9.3.2 Scheduled Resource Allocation 153
16.9.3.3 UE Autonomous Resource Selection 153
16.9.4 Uu Control 153
16.9.4.1 General 153
16.9.4.2 Control of connected UEs 154
16.9.4.3 Control of idle/inactive UEs 154
16.9.5 Sidelink Discovery 154
16.9.6 SL DRX 155
16.9.6.1 General 155
16.9.6.2 Unicast 155
16.9.6.3 Groupcast/Broadcast 156
16.9.6.4 Alignment between Uu DRX and SL DRX 156
16.9.7 Power Savings Resource Allocation 156
16.9.8 Inter-UE Coordination (IUC) 157
16.10 Multicast and Broadcast Services 157
16.10.1 General 157
16.10.2 Network Architecture 157
16.10.3 Protocol Architecture 158
16.10.4 Group Scheduling 160
16.10.5 Multicast Handling 160
16.10.5.1 Session Management 160
16.10.5.2 Configuration 161
16.10.5.3 Service Continuity 162
16.10.5.3.1 General 162
16.10.5.3.2 Handover between Multicast supporting cells 162
16.10.5.3.3 Handover between Multicast-supporting cell and Multicast non-supporting cell 162
16.10.5.3.4 MRB reconfiguration 163
16.10.5.4 Reception of MBS Multicast data 163
16.10.5.5 Support of CA 163
16.10.5.6 DRX 163
16.10.5.7 Physical Layer 163
16.10.6 Broadcast Handling 164
16.10.6.1 Session Management 164
16.10.6.2 Configuration 164
16.10.6.3 Support of CA 164
16.10.6.4 DRX 164
16.10.6.5 Service Continuity 165
16.10.6.5.0 General 165
16.10.6.5.1 Service Continuity in RRC_IDLE or RRC_INACTIVE 165
16.10.6.5.2 Service Continuity in RRC_CONNECTED 165
16.10.6.5A Reception of MBS Broadcast data 165
16.10.6.6 Physical Layer 166
16.11 Minimization of Service Interruption 166
16.12 Sidelink Relay 166
16.12.1 General 166
16.12.2 Protocol Architecture 167
16.12.2.1 L2 UE-to-Network Relay 167
16.12.3 Relay Discovery 168
16.12.4 Relay Selection/Reselection 169
16.12.5 Control plane procedures for L2 U2N Relay 170
16.12.5.1 RRC Connection Management 170
16.12.5.2 Radio Link Failure 172
16.12.5.3 RRC Connection Re-establishment 172
16.12.5.4 RRC Connection Resume 172
16.12.5.5 System Information 172
16.12.5.6 Paging 173
16.12.5.7 Access Control 173
16.12.5.8 Mobility Registration Update and RAN Area Update 173
16.12.6 Service Continuity for L2 U2N relay 173
16.12.6.0 General 173
16.12.6.1 Switching from indirect to direct path 173
16.12.6.2 Switching from direct to indirect path 175
16.13 Support of Reduced Capability (RedCap) NR devices 176
16.13.1 Introduction 176
16.13.2 Capabilities 176
16.13.3 Identification, access and camping restrictions 176
16.13.4 RRM measurement relaxations 176
16.13.5 BWP operation 176
16.14 Non-Terrestrial Networks 177
16.14.1 Overview 177
16.14.2 Timing and Synchronization 178
16.14.2.1 Scheduling and Timing 178
16.14.2.2 Timing Advance and Frequency Pre-compensation 178
16.14.3 Mobility and State transition 179
16.14.3.1 Mobility in RRC_IDLE and RRC_INACTIVE 179
16.14.3.2 Mobility in RRC_CONNECTED 179
16.14.3.2.1 Handover 179
16.14.3.2.2 Conditional Handover 179
16.14.3.3 Measurements 180
16.14.4 Switchover 180
16.14.4.1 Definitions 180
16.14.4.2 Assumptions 180
16.14.4.3 Procedures 181
16.14.5 NG-RAN signalling 181
16.14.6 AMF (Re-)Selection 181
16.14.7 O&M Requirements 181
16.14.8 Coarse UE location reporting 182
17 Interference Management 182
17.1 Remote Interference Management 182
17.2 Cross-Link Interference Management 183
18 Small Data Transmission 183
18.0 General 183
18.1 Support of SDT procedure over RACH 184
18.2 SDT with UE context relocation 185
18.3 SDT without UE context relocation 186
19 Support for NR coverage enhancements 187
20 Support for Multi-USIM devices 187
20.1 General 187
20.2 Paging Collision Avoidance 187
20.3 UE notification on Network Switching 188
21 Application Layer Measurement Collection 188
21.1 Overview 188
21.2 QoE Measurement Configuration 188
21.2.1 QoE Measurement Collection Activation and Reporting 188
21.2.2 QoE Measurement Collection Deactivation 189
21.2.3 Handling of QMC during RAN Overload 189
21.2.4 QoE Measurement Handling in RRC_IDLE and RRC_INACTIVE States 189
21.2.5 Per-slice QoE Measurement 189
21.3 QoE Measurement Continuity for Mobility 190
21.4 RAN Visible QoE Measurements 190
21.5 Alignment of MDT and QoE Measurements 191
Annex A (informative): QoS Handling in RAN 192
A.1 PDU Session Establishment 192
A.2 New QoS Flow with RQoS 192
A.3 New QoS Flow with Explicit RRC Signalling 193
A.4 New QoS Flow with Explicit NAS Signalling 194
A.5 Release of QoS Flow with Explicit Signalling 195
A.6 UE Initiated UL QoS Flow 195
Annex B (informative): Deployment Scenarios 197
B.1 Supplementary Uplink 197
B.2 Multiple SSBs in a carrier 197
B.3 NR Operation with Shared Spectrum 198
B.4 Example implementation of Non-Terrestrial Networks 198
Annex C (informative): I-RNTI Reference Profiles 201
Annex D (informative): SPID ranges and mapping of SPID values to cell reselection and inter-RAT/inter frequency handover priorities 202
Annex E (informative): NG-RAN Architecture for Radio Access Network Sharing with multiple cell ID broadcast 203
Annex F (normative): Use and structure of the I-RNTI 203
Annex G (informative): Change history 204
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:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
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.
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 specific reference, subsequent revisions do not apply.
- 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.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[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".
[4] 3GPP TS 38.401: "NG-RAN; Architecture description".
[5] 3GPP TS 33.501: "Security Architecture and Procedures for 5G System".
[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".
[15] 3GPP TS 22.268: "Public Warning System (PWS) Requirements".
[16] 3GPP TS 38.410: "NG-RAN; NG general aspects and principles".
[17] 3GPP TS 38.420: "NG-RAN; Xn general aspects and principles".
[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"
[21] 3GPP TS 37.340: "NR; Multi-connectivity; Overall description; Stage-2".
[22] 3GPP TS 23.502: "Procedures for the 5G System; Stage 2".
[23] IETF RFC 4960 (2007-09): "Stream Control Transmission Protocol".
[24] 3GPP TS 26.114: "Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction".
[25] Void.
[26] 3GPP TS 38.413: "NG-RAN; NG Application Protocol (NGAP)".
[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".
[30] 3GPP TS 38.415: "NG-RAN; PDU Session User Plane Protocol".
[31] 3GPP TS 38.340: "NR; Backhaul Adaptation Protocol (BAP) specification".
[32] 3GPP TS 38.470: "NG-RAN; F1 application protocol (F1AP) ".
[33] 3GPP TS 38.425: "NG-RAN; NR user plane protocol".
[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".
[38] 3GPP TS 38.213: "NR; Physical layer procedures for control".
[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".
[43] 3GPP TS 37.355: "LTE Positioning Protocol (LPP)".
[44] 3GPP TS 29.002: "Mobile Application Part (MAP) specification".
[45] 3GPP TS 23.247: "Architectural enhancements for 5G multicast-broadcast services; Stage 2".
[46] 3GPP TS 26.346 "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs".
[47] 3GPP TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode".
[48] 3GPP TS 23.304: "Proximity based Services (ProSe) in the 5G System (5GS)".
[49] 3GPP TS 28.541: "5G Network Resource Model (NRM)".
[50] 3GPP TS 38.423: "NG-RAN; Xn Application Protocol (XnAP)".
[51] NIMA TR 8350.2, Third Edition, Amendment 1, 3 January 2000: "DEPARTMENT OF DEFENSE WORLD GEODETIC SYSTEM 1984".
[52] 3GPP TS 38.211: "NR; Physical channels and modulation".
[53] 3GPP TS 24.587: "Vehicle-to-Everything (V2X) services in 5G System (5GS)".
[54] 3GPP TS 23.041: "Technical realization of Cell Broadcast Service (CBS)".
3 Abbreviations and Definitions
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].
5GC 5G Core Network
5GS 5G System
5QI 5G QoS Identifier
A-CSI Aperiodic CSI
AGC Automatic Gain Control
AKA Authentication and Key Agreement
AMBR Aggregate Maximum Bit Rate
AMC Adaptive Modulation and Coding
AMF Access and Mobility Management Function
ARP Allocation and Retention Priority
BA Bandwidth Adaptation
BCCH Broadcast Control Channel
BCH Broadcast Channel
BFD Beam Failure Detection
BH Backhaul
BL Bandwidth reduced Low complexity
BPSK Binary Phase Shift Keying
C-RNTI Cell RNTI
CAG Closed Access Group
CAPC Channel Access Priority Class
CBRA Contention Based Random Access
CCE Control Channel Element
CD-SSB Cell Defining SSB
CFR Common Frequency Resource
CFRA Contention Free Random Access
CG Configured Grant
CHO Conditional Handover
CIoT Cellular Internet of Things
CLI Cross Link interference
CMAS Commercial Mobile Alert Service
CORESET Control Resource Set
CP Cyclic Prefix
CPA Conditional PSCell Addition
CPC Conditional PSCell Change
DAG Directed Acyclic Graph
DAPS Dual Active Protocol Stack
DFT Discrete Fourier Transform
DCI Downlink Control Information
DCP DCI with CRC scrambled by PS-RNTI
DL-AoD Downlink Angle-of-Departure
DL-SCH Downlink Shared Channel
DL-TDOA Downlink Time Difference Of Arrival
DMRS Demodulation Reference Signal
DRX Discontinuous Reception
E-CID Enhanced Cell-ID (positioning method)
EHC Ethernet Header Compression
ePWS enhancements of Public Warning System
ETWS Earthquake and Tsunami Warning System
FS Feature Set
FSA ID Frequency Selection Area Identity
G-CS-RNTI Group Configured Scheduling RNTI
G-RNTI Group RNTI
GFBR Guaranteed Flow Bit Rate
GIN Group ID for Network selection
GNSS Global Navigation Satellite System
GSO Geosynchronous Orbit
H-SFN Hyper System Frame Number
HAPS High Altitude Platform Station
HRNN Human-Readable Network Name
IAB Integrated Access and Backhaul
IFRI Intra Frequency Reselection Indication
I-RNTI Inactive RNTI
INT-RNTI Interruption RNTI
KPAS Korean Public Alarm System
L2 Layer-2
L3 Layer-3
LDPC Low Density Parity Check
LEO Low Earth Orbit
MBS Multicast/Broadcast Services
MCE Measurement Collection Entity
MCCH MBS Control Channel
MDBV Maximum Data Burst Volume
MEO Medium Earth Orbit
MIB Master Information Block
MICO Mobile Initiated Connection Only
MFBR Maximum Flow Bit Rate
MMTEL Multimedia telephony
MNO Mobile Network Operator
MPE Maximum Permissible Exposure
MRB MBS Radio Bearer
MT Mobile Termination
MTCH MBS Traffic Channel
MTSI Multimedia Telephony Service for IMS
MU-MIMO Multi User MIMO
Multi-RTT Multi-Round Trip Time
MUSIM Multi-Universal Subscriber Identity Module
NB-IoT Narrow Band Internet of Things
NCD-SSB Non Cell Defining SSB
NCGI NR Cell Global Identifier
NCL Neighbour Cell List
NCR Neighbour Cell Relation
NCRT Neighbour Cell Relation Table
NGAP NG Application Protocol
NGSO Non-Geosynchronous Orbit
NID Network Identifier
NPN Non-Public Network
NR NR Radio Access
NSAG Network Slice AS Group
NTN Non-Terrestrial Network
P-MPR Power Management Maximum Power Reduction
P-RNTI Paging RNTI
PCH Paging Channel
PCI Physical Cell Identifier
PDC Propagation Delay Compensation
PDCCH Physical Downlink Control Channel
PDSCH Physical Downlink Shared Channel
PEI Paging Early Indication
PH Paging Hyperframe
PLMN Public Land Mobile Network
PNI-NPN Public Network Integrated NPN
PO Paging Occasion
PRACH Physical Random Access Channel
PRB Physical Resource Block
PRG Precoding Resource block Group
PRS Positioning Reference Signal
PS-RNTI Power Saving RNTI
PSS Primary Synchronisation Signal
PTM Point to Multipoint
PTP Point to Point
PTW Paging Time Window
PUCCH Physical Uplink Control Channel
PUSCH Physical Uplink Shared Channel
PWS Public Warning System
QAM Quadrature Amplitude Modulation
QFI QoS Flow ID
QMC QoE Measurement Collection
QoE Quality of Experience
QPSK Quadrature Phase Shift Keying
RA Random Access
RA-RNTI Random Access RNTI
RACH Random Access Channel
RANAC RAN-based Notification Area Code
REG Resource Element Group
RIM Remote Interference Management
RLM Radio Link Monitoring
RMSI Remaining Minimum SI
RNA RAN-based Notification Area
RNAU RAN-based Notification Area Update
RNTI Radio Network Temporary Identifier
RQA Reflective QoS Attribute
RQoS Reflective Quality of Service
RS Reference Signal
RSRP Reference Signal Received Power
RSRQ Reference Signal Received Quality
RSSI Received Signal Strength Indicator
RSTD Reference Signal Time Difference
RTT Round Trip Time
SCS SubCarrier Spacing
SD Slice Differentiator
SDAP Service Data Adaptation Protocol
SDT Small Data Transmission
SFI-RNTI Slot Format Indication RNTI
SHR Successful Handover Report
SIB System Information Block
SI-RNTI System Information RNTI
SLA Service Level Agreement
SMC Security Mode Command
SMF Session Management Function
SMTC SS/PBCH block Measurement Timing Configuration
S-NSSAI Single Network Slice Selection Assistance Information
SNPN Stand-alone Non-Public Network
SNPN ID Stand-alone Non-Public Network Identity
SPS Semi-Persistent Scheduling
SR Scheduling Request
SRAP Sidelink Relay Adaptation Protocol
SRS Sounding Reference Signal
SRVCC Single Radio Voice Call Continuity
SS Synchronization Signal
SSB SS/PBCH block
SSS Secondary Synchronisation Signal
SSSG Search Space Set Group
SST Slice/Service Type
SU-MIMO Single User MIMO
SUL Supplementary Uplink
TA Timing Advance
TB Transport Block
TCE Trace Collection Entity
TNL Transport Network Layer
TPC Transmit Power Control
TRP Transmit/Receive Point
TRS Tracking Reference Signal
U2N UE-to-Network
UCI Uplink Control Information
UDC Uplink Data Compression
UE-Slice-MBR UE Slice Maximum Bit Rate
UL-AoA Uplink Angles of Arrival
UL-RTOA Uplink Relative Time of Arrival
UL-SCH Uplink Shared Channel
UPF User Plane Function
URLLC Ultra-Reliable and Low Latency Communications
VR Virtual Reality
V2X Vehicle-to-Everything
Xn-C Xn-Control plane
Xn-U Xn-User plane
XnAP Xn Application Protocol
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].
BH RLC channel: an RLC channel between two nodes, which is used to transport backhaul packets.
Boundary IAB-node: as defined in TS 38.401 [4].
Broadcast MRB: A radio bearer configured for MBS broadcast delivery.
CAG Cell: a PLMN cell broadcasting at least one Closed Access Group identity.
CAG Member Cell: for a UE, a CAG 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 CAG cell that is only available for normal service for CAG UEs.
Cell-Defining SSB: an SSB with an RMSI associated.
Child node: IAB-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 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.
Direct Path: a type of UE-to-Network transmission path, where data is transmitted between a UE and the network without sidelink relaying.
Downstream: direction toward child node or UE in IAB-topology.
Early Data Forwarding: data forwarding that is initiated before the UE executes the handover.
Earth-centered, earth-fixed: a global geodetic reference system for the Earth intended for practical applications of mapping, charting, geopositioning and navigation, as specified in NIMA TR 8350.2 [51].
Feeder link: wireless link between the NTN Gateway and the NTN payload.
Geosynchronous Orbit: earth-centered orbit at approximately 35786 kilometres above Earth's surface and synchronised with Earth's rotation. A geostationary orbit is a non-inclined geosynchronous orbit, i.e. in the Earth's equator plane.
Group ID for Network Selection: an identifier used during SNPN selection to enhance the likelihood of selecting a preferred SNPN that supports a Default Credentials Server or a Credentials Holder, as specified in TS 23.501 [3].
gNB: node providing NR user plane and control plane protocol terminations towards the UE, and connected via the NG interface to the 5GC.
High Altitude Platform Station: airborne vehicle embarking the NTN payload placed at an altitude between 8 and 50 km.
IAB-donor: gNB that provides network access to UEs via a network of backhaul and access links.
IAB-donor-CU: as defined in TS 38.401 [4].
IAB-donor-DU: as defined in TS 38.401 [4].
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.
IAB topology: the unison of all IAB-nodes and IAB-donor-DUs whose F1 and/or RRC connections are terminated at the same IAB-donor-CU.
Indirect Path: a type of UE-to-Network transmission path, where data is forwarded via a U2N Relay UE between a U2N Remote UE and the network.
Inter-donor partial migration: migration of an IAB-MT to a parent node underneath a different IAB-donor-CU while the collocated IAB-DU and its descendant IAB-node(s), if any, are terminated at the initial IAB-donor-CU. The procedure renders the said IAB-node as a boundary IAB-node.
Intra-system Handover: handover that does not involve a CN change (EPC or 5GC).
Inter-system Handover: handover that involves 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.
Mapped Cell ID: in NTN, it corresponds to a fixed geographical area.
MBS Radio Bearer: A radio bearer configured for MBS delivery.
MSG1: preamble transmission of the random access procedure for 4-step random access (RA) type.
MSG3: first scheduled transmission of the random access procedure.
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.
Multicast/Broadcast Service: A point-to-multipoint service as defined in TS 23.247 [45].
Multicast MRB: A radio bearer configured for MBS multicast delivery.
Multi-hop backhauling: using a chain of NR backhaul links between an IAB-node and an IAB-donor.
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.
NG-C: control plane interface between NG-RAN and 5GC.
NG-U: user plane interface between NG-RAN and 5GC.
NG-RAN node: either a gNB or an ng-eNB.
Non-CAG Cell: a PLMN cell which does not broadcast any Closed Access Group identity.
Non-Geosynchronous orbit: earth-centered orbit with an orbital period that does not match Earth's rotation on its axis. This includes Low and Medium Earth Orbit (LEO and MEO). LEO operates at altitudes between 300 km and 1500 km and MEO at altitudes between 7000 km and 25000 km, approximately.
Non-terrestrial network: an NG-RAN consisting of gNBs, which provide non-terrestrial NR access to UEs by means of an NTN payload embarked on an airborne or space-borne NTN vehicle and an NTN Gateway.
NR backhaul link: NR link used for backhauling between an IAB-node and an IAB-donor, 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] and the ProSe communication (including ProSe non-Relay and UE-to-Network Relay communication) as defined in TS 23.304 [48], between two or more nearby UEs, using NR technology but not traversing any network node.
NR sidelink discovery: AS functionality enabling ProSe non-Relay Discovery and ProSe UE-to-Network Relay discovery for Proximity based Services as defined in TS 23.304 [48] between two or more nearby UEs, using NR technology but not traversing any network node.
NTN Gateway: an earth station located at the surface of the earth, providing connectivity to the NTN payload using the feeder link. An NTN Gateway is a TNL node.
NTN payload: a network node, embarked on board a satellite or high altitude platform station, providing connectivity functions, between the service link and the feeder link. In the current version of this specification, the NTN payload is a TNL 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-MT's next hop neighbour node; the parent node can be IAB-node or IAB-donor-DU
PC5 Relay RLC channel: an RLC channel between L2 U2N Remote UE and L2 U2N Relay UE, which is used to transport packets over PC5 for L2 UE-to-Network Relay.
PLMN Cell: a cell of the PLMN.
RedCap UE: a UE with reduced capabilities as specified in clause 4.2.21.1 in TS 38.306 [11].
Relay discovery: AS functionality enabling 5G ProSe UE-to-Network Relay Discovery as defined in TS 23.304 [48], using NR technology but not traversing any network node.
Satellite: a space-borne vehicle orbiting the Earth embarking the NTN payload.
Service link: wireless link between the NTN payload and UE.
SNPN Access Mode: mode of operation whereby a UE only accesses SNPNs.
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).
Transmit/Receive Point: part of the gNB transmitting and receiving radio signals to/from UE according to physical layer properties and parameters inherent to that element.
U2N Relay UE: a UE that provides functionality to support connectivity to the network for U2N Remote UE(s).
U2N Remote UE: a UE that communicates with the network via a U2N Relay UE.
Upstream: direction toward parent node in IAB-topology.
Uu Relay RLC channel: an RLC channel between L2 U2N Relay UE and gNB, which is used to transport packets over Uu for L2 UE-to-Network Relay.
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.
Xn: network interface between NG-RAN nodes.
4 Overall Architecture and Functional Split
4.1 Overall Architecture
An NG-RAN node is either:
- 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].
The NG-RAN architecture is illustrated in Figure 4.1-1 below.
Figure 4.1-1: Overall Architecture
4.2 Functional Split
The gNB and ng-eNB host the following functions:
- 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);
- IP and Ethernet header compression, uplink data decompression, encryption and integrity protection of data;
- Selection of an AMF at UE attachment when no routing to an AMF can be determined from the information provided by the UE;
- Routing of User Plane data towards UPF(s);
- Routing of Control Plane information towards AMF;
- Connection setup and release;
- Scheduling and transmission of paging messages;
- Scheduling and transmission of system broadcast information (originated from the AMF or OAM);
- Measurement and measurement reporting configuration for mobility and scheduling;
- Transport level packet marking in the uplink;
- Session Management;
- Support of Network Slicing;
- QoS Flow management and mapping to data radio bearers;
- Support of UEs in RRC_INACTIVE state;
- Distribution function for NAS messages;
- Radio access network sharing;
- Dual Connectivity;
- Tight interworking between NR and E-UTRA;
- Maintain security and radio configuration for User Plane CIoT 5GS Optimisation, as defined in TS 23.501 [3] (ng-eNB only).
NOTE 1: BL UE or UE in enhanced coverage is only supported by ng-eNB, see TS 36.300 [2].
NOTE 2: NB-IoT UE is only supported by ng-eNB, see TS 36.300 [2].
The AMF hosts the following main functions (see TS 23.501 [3]):
- NAS signalling termination;
- NAS signalling security;
- AS Security control;
- Inter CN node signalling for mobility between 3GPP access networks;
- Idle mode UE Reachability (including control and execution of paging retransmission);
- Registration Area management;
- Support of intra-system and inter-system mobility;
- Access Authentication;
- Access Authorization including check of roaming rights;
- Mobility management control (subscription and policies);
- Support of Network Slicing;
- SMF selection.
- Selection of CIoT 5GS optimisations;
The UPF hosts the following main functions (see TS 23.501 [3]):
- Anchor point for Intra-/Inter-RAT mobility (when applicable);
- External PDU session point of interconnect to Data Network;
- Packet routing & forwarding;
- Packet inspection and User plane part of Policy rule enforcement;
- Traffic usage reporting;
- Uplink classifier to support routing traffic flows to a data network;
- Branching point to support multi-homed PDU session;
- QoS handling for user plane, e.g. packet filtering, gating, UL/DL rate enforcement;
- Uplink Traffic verification (SDF to QoS flow mapping);
- Downlink packet buffering and downlink data notification triggering.
The Session Management function (SMF) hosts the following main functions (see TS 23.501 [3]):
- Session Management;
- UE IP address allocation and management;
- Selection and control of UP function;
- Configures traffic steering at UPF to route traffic to proper destination;
- Control part of policy enforcement and QoS;
- Downlink Data Notification.
This is summarized on the figure below where yellow boxes depict the logical nodes and white boxes depict the main functions.
Figure 4.2-1: Functional Split between NG-RAN and 5GC
4.3 Network Interfaces
4.3.1 NG Interface
4.3.1.1 NG User Plane
The NG user plane interface (NG-U) is defined between the NG-RAN node and the UPF. The user plane protocol stack of the NG interface is shown on Figure 4.3.1.1-1. The transport network layer is built on IP transport and GTP-U is used on top of UDP/IP to carry the user plane PDUs between the NG-RAN node and the UPF.
Figure 4.3.1.1-1: NG-U Protocol Stack
NG-U provides non-guaranteed delivery of user plane PDUs between the NG-RAN node and the UPF.
Further details of NG-U can be found in TS 38.410 [16].
4.3.1.2 NG Control Plane
The NG control plane interface (NG-C) is defined between the NG-RAN node and the AMF. The control plane protocol stack of the NG interface is shown on Figure 4.3.1.2-1. The transport network layer is built on IP transport. For the reliable transport of signalling messages, SCTP is added on top of IP. The application layer signalling protocol is referred to as NGAP (NG Application Protocol). The SCTP layer provides guaranteed delivery of application layer messages. In the transport, IP layer point-to-point transmission is used to deliver the signalling PDUs.
Figure 4.3.1.2-1: NG-C Protocol Stack
NG-C provides the following functions:
- NG interface management;
- UE context management;
- UE mobility management;
- Transport of NAS messages;
- Paging;
- PDU Session Management;
- Configuration Transfer;
- Warning Message Transmission.
Further details of NG-C can be found in TS 38.410 [16].
4.3.2 Xn Interface
4.3.2.1 Xn User Plane
The Xn User plane (Xn-U) interface is defined between two NG-RAN nodes. The user plane protocol stack on the Xn interface is shown in Figure 4.3.2.1-1. The transport network layer is built on IP transport and GTP-U is used on top of UDP/IP to carry the user plane PDUs.
Figure 4.3.2.1-1: Xn-U Protocol Stack
Xn-U provides non-guaranteed delivery of user plane PDUs and supports the following functions:
- Data forwarding;
- Flow control.
Further details of Xn-U can be found in TS 38.420 [17].
4.3.2.2 Xn Control Plane
The Xn control plane interface (Xn-C) is defined between two NG-RAN nodes. The control plane protocol stack of the Xn interface is shown on Figure 4.3.2.2-1. The transport network layer is built on SCTP on top of IP. The application layer signalling protocol is referred to as XnAP (Xn Application Protocol). The SCTP layer provides the guaranteed delivery of application layer messages. In the transport IP layer point-to-point transmission is used to deliver the signalling PDUs.
Figure 4.3.2.2-1: Xn-C Protocol Stack
The Xn-C interface supports the following functions:
- Xn interface management;
- UE mobility management, including context transfer and RAN paging;
- Dual connectivity.
Further details of Xn-C can be found in TS 38.420 [17].
4.4 Radio Protocol Architecture
4.4.1 User Plane
The figure below shows the protocol stack for the user plane, where SDAP, PDCP, RLC and MAC sublayers (terminated in gNB on the network side) perform the functions listed in clause 6.
Figure 4.4.1-1: User Plane Protocol Stack
4.4.2 Control Plane
The figure below shows the protocol stack for the control plane, where:
- 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…
Figure 4.4.2-1: Control Plane Protocol Stack
4.5 Multi-Radio Dual Connectivity
NG-RAN supports Multi-Radio Dual Connectivity (MR-DC) operation whereby a UE in RRC_CONNECTED is configured to utilise radio resources provided by two distinct schedulers, located in two different NG-RAN nodes connected via a non-ideal backhaul, one providing NR access and the other one providing either E-UTRA or NR access. Further details of MR-DC operation, including Conditional PSCell Addition (CPA) and Conditional PSCell Change (CPC), can be found in TS 37.340 [21].
4.6 Radio Access Network Sharing
NG-RAN supports radio access network sharing as defined in TS 23.501 [3].
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. 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.
4.7 Integrated Access and Backhaul
4.7.1 Architecture
Integrated access and backhaul (IAB) enables wireless relaying in NG-RAN. The relaying node, referred to as IAB-node, supports access and backhauling via NR. The terminating node of NR backhauling on network side is referred to as the IAB-donor, which represents a gNB with additional functionality to support IAB. Backhauling can occur via a single or via multiple hops. The IAB architecture is shown in Figure 4.7.1-1.
The IAB-node supports the 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 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 connects via E-UTRA to a MeNB, and the IAB-donor terminates X2-C as SgNB (TS 37.340 [21]).
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 backhaul hops and controlled by this IAB-donor via F1AP and/or RRC form an IAB topology with the IAB-donor as its root (Fig. 4.7.1-2). In this IAB topology, the neighbour node of the IAB-DU or the IAB-donor-DU is referred to as the child node and the neighbour node of the IAB-MT is referred to as the parent node. The direction toward the child node is referred to as downstream while the direction toward the parent node is referred to as upstream. The IAB-donor performs centralized resource, topology and route management for its IAB topology.
Figure 4.7.1-2: Parent- and child-node relationship for IAB-node
4.7.2 Protocol Stacks
Fig. 4.7.2-1 shows the protocol stack for F1-U and Fig. 4.7.2-2 shows the protocol stack for F1-C between IAB-DU and IAB-donor-CU. In these figures, F1-U and F1-C are carried over two backhaul hops.
F1-U and F1-C use an IP transport layer between IAB-DU and IAB-donor-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 also be used for non-F1 traffic, such as OAM traffic as defined in TS 38.401 [4].
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 entities 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].
Fig. 4.7.2-1: Protocol stack for the support of F1-U protocol
Fig. 4.7.2-2: Protocol stack for the support of F1-C protocol
The IAB-MT further establishes SRBs (carrying RRC and NAS) with the IAB-donor-CU. For IAB-nodes operating in EN-DC, the IAB-MT establishes one or more DRBs with the eNB and one or more DRBs 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.
Figure 4.7.2-3: Protocol stack for the support of IAB-MT's RRC and NAS connections
4.7.3 User-plane Aspects
4.7.3.1 Backhaul transport
The IAB-DU's IP traffic is routed over the wireless backhaul via the BAP sublayer. The BAP sublayer is specified in TS 38.340 [31]. In downstream direction, upper layer packets are encapsulated by the BAP sublayer at the IAB-donor-DU and de-encapsulated at the destination IAB-node. In upstream direction, upper layer packets are encapsulated at the IAB-node and de-encapsulated at the IAB-donor-DU. IAB-specific transport between IAB-donor-CU and IAB-donor-DU is specified in TS 38.401 [4].
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 the BAP header is stripped off when the packet 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 BAP 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 BAP header and a routing configuration it received from the IAB-donor-CU.
For each packet, the IAB-node further determines the egress BH RLC channel on the designated egress link. For packets arriving from upper layers, the designated egress 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 QoS information 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 traffic 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 egress 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.
4.7.3.2 Flow and Congestion Control
Flow and congestion control can be supported in both upstream and downstream directions in order to avoid congestion-related packet drops on IAB-nodes and IAB-donor-DU:
- 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 buffer size for an ingress BH RLC channel or BAP routing ID 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.
4.7.3.3 Uplink Scheduling Latency
The IAB-node can reduce UL scheduling latency through signalling of a Pre-emptive BSR to its parent node. The IAB-node can send the Pre-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-1). The Pre-emptive BSR conveys the data expected rather than the data buffered.
Figure 4.7.3.3-1: Scheduling of BSR in IAB:
a) regular BSR based on buffered data,
b) Pre-emptive BSR based on UL grant,
c) Pre-emptive BSR based on reception of regular BSR
4.7.4 Signalling procedures
4.7.4.1 IAB-node Integration
The IAB-node integration procedure is captured in TS 38.401 [4].
4.7.4.2 IAB-node Migration
The IAB-node can migrate to a different parent node underneath the same IAB-donor-CU. The IAB-node continues providing access and backhaul service when migrating to a different parent node.
The IAB-MT can also migrate to a different parent node underneath another IAB-donor-CU. In this case, the collocated IAB-DU and the IAB-DU(s) of its descendant node(s) retain F1 connectivity with the initial IAB-donor-CU. The IAB-MT of each descendant node and all the served UEs retain the RRC connectivity with the initial IAB-donor-CU. This migration is referred to as inter-donor partial migration. The IAB-node, whose IAB-MT migrates to the new IAB-donor-CU, is referred to as a boundary IAB-node. After inter-donor partial migration, the F1 traffic of the IAB-DU and its descendant nodes is routed via the BAP layer of the IAB topology to which the IAB-MT has migrated.
Inter-donor partial migration is only supported for SA-mode.
The intra-donor IAB-node migration procedure and inter-donor partial migration procedures are captured in TS 38.401 [4].
4.7.4.3 Topological Redundancy
The IAB-node may have redundant routes to the IAB-donor-CU(s).
For IAB-nodes operating in SA-mode, NR DC can be used to enable route redundancy in the BH by allowing the IAB-MT to have concurrent BH links with two parent nodes. The parent nodes may be connected to the same or to different IAB-donor-CUs, which control the establishment and release of redundant routes via these two parent nodes. Either parent node's gNB-DU functionality together with the respective IAB-donor-CU assumes the role of the IAB-MT's master node or 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]).
The procedure for establishment of topological redundancy for IAB-nodes operating in SA-mode is captured in TS 38.401 [4].
An IAB-node operating in NR-DC may also use one of its links for BH connectivity with an IAB-donor and the other link for access-only connectivity with a separate gNB that does not assume IAB-donor role. The IAB-donor can assume the MN or the SN role. The IAB-node may exchange F1-C traffic with the IAB-donor via the backhaul link and/or via the access link with the gNB. In the latter case, the F1-C messages are carried over NR RRC between the IAB-node and the gNB, and via XnAP between the gNB and the IAB-donor.
IAB-nodes operating in EN-DC can exchange F1-C traffic with the IAB-donor via the MeNB. The F1-C message is carried over LTE RRC using SRB2 between IAB-node and MeNB and via X2AP between the MeNB and the IAB-donor.
The procedures for establishment of redundant transport of F1-C for IAB-nodes using NR-DC and EN-DC are captured in TS 37.340 [21] and TS 38.401 [4].
4.7.4.4 Backhaul RLF Recovery
When the IAB-node using SA-mode declares RLF on the backhaul link, it can perform RLF recovery at another parent node underneath the same or underneath a different IAB-donor-CU. In the latter case, the collocated IAB-DU and the IAB-DU(s) of its descendant node(s) may retain the F1 connectivity with the initial IAB-donor-CU, while the IAB-MT(s) of the descendant node(s) and all the served UEs retain the RRC connectivity with the initial IAB-donor-CU, in the same manner as for inter-donor partial migration.
The BH RLF recovery procedure for the IAB-node is captured in TS 38.401 [4]. BH RLF declaration for IAB-node and the aspects of RLF recovery by the IAB-MT are handled in clause 9.2.7 of the present document.
4.7.4.5 OTA timing synchronization
An IAB-DU is subject to the same downlink timing alignment of a gNB. The IAB-DU may use the received downlink signal from a parent as a reference to control its downlink timing using TA in conjunction with an additional Tdelta parameter received by the collocated IAB-MT from the parent via MAC-CE.
4.7.4.6 Inter node discovery
Inter node discovery is supported via SSB-based and/or CSI-RS-based measurements. An IAB-node can be configured to transmit and receive off synchronization raster SSB signals to discover neighbouring IAB-nodes. The configuration is not expected to create a conflict between IAB-DU SSB transmission and IAB-MT SSB measurement windows.
4.8 Non-Public Networks
A Non-Public Network (NPN) is a network for non-public use (see TS 22.261 [19]), which can be deployed as (see TS 23.501 [3]):
- 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.
NOTE: As described in clause 5.30.3.1 of TS 23.501 [3], there are several approaches in which PNI-NPNs can be made available via PLMNs. The only approach visible to AS, and hence the only approach that is addressed in AS specifications is the approach of using CAGs.
5 Physical Layer
5.1 Waveform, numerology and frame structure
The downlink transmission waveform is conventional OFDM using a Cyclic Prefix. The uplink transmission waveform is conventional OFDM using a CP with a transform precoding function performing DFT spreading that can be disabled or enabled. For operation with shared spectrum channel access in FR1, the uplink transmission waveform subcarrier mapping can map to subcarriers in one or more PRB interlaces.
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,5,6} for PSS, SSS and PBCH and µ={0,1,2,3,5,6} 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.
Table 5.1-1: Supported transmission numerologies.
|
| CP | 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 |
5 | 480 | Normal | Yes | Yes |
6 | 960 | Normal | Yes | 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.
Figure 5.1-2: Uplink-downlink timing relation
Operation on both paired and unpaired spectrum is supported.
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).
Transmission durations from 2 to 14 symbols in a slot is supported.
Aggregation of multiple slots with Transport Block (TB) repetition is supported.
5.2.2 Physical-layer processing for physical downlink shared channel
The downlink physical-layer processing of transport channels consists of the following steps:
- Transport block CRC attachment;
- Code block segmentation and code block CRC attachment;
- Channel coding: LDPC coding;
- Physical-layer hybrid-ARQ processing;
- Rate matching;
- Scrambling;
- Modulation: QPSK, 16QAM, 64QAM, 256QAM, and 1024QAM;
- Layer mapping;
- Mapping to assigned resources and antenna ports.
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.
The DL-SCH physical layer model is described in TS 38.202 [20].
5.2.3 Physical downlink control channels
The Physical Downlink Control Channel (PDCCH) can be used to schedule DL transmissions on PDSCH and UL transmissions on PUSCH, where the Downlink Control Information (DCI) on PDCCH includes:
- 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.
In addition to scheduling, PDCCH can be used to for:
- Activation and deactivation of configured PUSCH transmission with configured grant;
- Activation and deactivation of PDSCH semi-persistent transmission;
- Notifying one or more UEs of the slot format;
- 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 TPC commands for PUCCH and PUSCH;
- Transmission of one or more TPC commands for SRS transmissions by one or more UEs;
- Switching a UE's active bandwidth part;
- Initiating a random access procedure;
- Indicating the UE(s) to monitor the PDCCH during the next occurrence of the DRX on-duration;
- In IAB context, indicating the availability for soft symbols of an IAB-DU;
- Triggering one shot HARQ-ACK codebook feedback;
- For operation with shared spectrum channel access:
- Triggering search space set group switching;
- Indicating one or more UEs about the available RB sets and channel occupancy time duration;
- Indicating downlink feedback information for configured grant PUSCH (CG-DFI).
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.
The PDCCH repetition is operated by using two search spaces which are explicitly linked by configuration provided by the RRC layer, and are associated with corresponding CORESETs. For PDCCH repetition, two linked search spaces are configured with the same number of candidates, and two PDCCH candidates in two search spaces are linked with the same candidate index. When PDCCH repetition is scheduled to a UE, an intra-slot repetition is allowed and each repetition has the same number of CCEs and coded bits, and corresponds to the same DCI payload.
Polar coding is used for PDCCH.
Each resource element group carrying PDCCH carries its own DMRS.
QPSK modulation is used for PDCCH.
5.2.4 Synchronization signal and PBCH block
The Synchronization Signal and PBCH block (SSB) consists of primary and secondary synchronization signals (PSS, SSS), each occupying 1 symbol and 127 subcarriers, and PBCH spanning across 3 OFDM symbols and 240 subcarriers, but on one symbol leaving an unused part in the middle for SSS as show in Figure 5.2.4-1. The possible time locations of SSBs within a half-frame are determined by sub-carrier spacing and the periodicity of the half-frames where SSBs are transmitted is configured by the network. During a half-frame, different SSBs may be transmitted in different spatial directions (i.e. using different beams, spanning the coverage area of a cell).
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 is referred to as a Cell-Defining SSB (CD-SSB). A PCell is always associated to a CD-SSB located on the synchronization raster.
Figure 5.2.4-1: Time-frequency structure of SSB
Polar coding is used for PBCH.
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.
PBCH symbols carry its own frequency-multiplexed DMRS.
QPSK modulation is used for PBCH.
The PBCH physical layer model is described in TS 38.202 [20].
5.2.5 Physical layer procedures
5.2.5.1 Link adaptation
Link adaptation (AMC: adaptive modulation and coding) with various modulation schemes and channel coding rates is applied to the PDSCH. The same coding and modulation is applied to all groups of resource blocks belonging to the same L2 PDU scheduled to one user within one transmission duration and within a MIMO codeword.
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.2 Power Control
Downlink power control can be used.
5.2.5.3 Cell search
Cell search is the procedure by which a UE acquires time and frequency synchronization with a cell and detects the Cell ID of that cell. NR cell search is based on the primary and secondary synchronization signals, and PBCH DMRS, located on the synchronization raster.
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 by using enhanced dynamic codebook and/or one-shot triggering of HARQ-ACK transmission for (i) all configured CCs and HARQ processes in the PUCCH group, (ii) a configured subset of CCs and/or HARQ processes in the PUCCH group, or (iii) a dynamically indicated HARQ-ACK feedback instance. For HARQ-ACK of SPS PDSCH without associated PDCCH, in case of HARQ-ACK dropping due to TDD specific collisions, the HARQ-ACK feedback can be deferred to a next available PUCCH transmission occasion.
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.
5.2.5.5 Reception of SIB1
The Master Information Block (MIB) on PBCH provides the UE with parameters (e.g. CORESET#0 configuration) for monitoring of PDCCH for scheduling PDSCH that carries the System Information Block 1 (SIB1). PBCH may also indicate that there is no associated SIB1, in which case the UE may be pointed to another frequency from where to search for an SSB that is associated with a SIB1 as well as a frequency range where the UE may assume no SSB associated with SIB1 is present. The indicated frequency range is confined within a contiguous spectrum allocation of the same operator in which SSB is detected.
5.2.6 Downlink Reference Signals and Measurements for Positioning
The DL Positioning Reference Signals (DL PRS) are defined to facilitate support of different positioning methods such as DL-TDOA, DL-AoD, multi-RTT through the following set of UE measurements DL RSTD, DL PRS-RSRP, and UE Rx-Tx time difference respectively as described in TS 38.305 [42].
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.
Transmission durations from 1 to 14 symbols in a slot is supported.
Aggregation of multiple slots with TB repetition is supported.
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.
5.3.2 Physical-layer processing for physical uplink shared channel
The uplink physical-layer processing of transport channels consists of the following steps:
- Transport Block CRC attachment;
- Code block segmentation and Code Block CRC attachment;
- Channel coding: LDPC coding;
- Physical-layer hybrid-ARQ processing;
- Rate matching;
- Scrambling;
- Modulation: π/2 BPSK (with transform precoding only), QPSK, 16QAM, 64QAM and 256QAM;
- Layer mapping, transform precoding (enabled/disabled by configuration), and pre-coding;
- Mapping to assigned resources and antenna ports.
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.
The UL-SCH physical layer model is described in TS 38.202 [20].
For configured grants operation with shared spectrum channel access, described in clause 10.3, a CG-UCI (Configured Grant Uplink Control Information) can be transmitted in PUSCH scheduled by configured uplink grant.
5.3.3 Physical uplink control channel
Physical uplink control channel (PUCCH) carries the Uplink Control Information (UCI) from the UE to the gNB. Five formats of PUCCH exist, depending on the duration of PUCCH and the UCI payload size:
- 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;
- 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. Short and long PUCCH formats can be repeated over multiple slots or sub-slots, where the repetition factor is either indicated dynamically in the DCI or semi-statically in an RRC configuration.
For operation with shared spectrum channel access in FR1, 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.
For operation in FR2-2, PUCCH Format #0, #1, #4 are extended to use resource in configurable number of continuous PRBs, up to 16 PRBs.
Up to two PUCCH configurations can be configured for a UE per PUCCH group (see TS 38.331 [12]), where the first PUCCH configuration is associated with a PUCCH of priority index 0 (low) and the second PUCCH configuration is associated with a PUCCH of priority index 1 (high).
UCI multiplexing in PUCCH is supported when PUCCH transmissions of UCIs coincide in time, and are associated with the same priority (high/low). In addition, multiplexing of HARQ-ACK of priority index 0 (low) and UCI of priority index 1 (high) in PUCCH of priority index 1 (high) is supported when PUCCH transmissions of HARQ-ACK of priority index 0 and UCI of priority index 1 (high) coincide in time.
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, and are associated with the same priority (high/low). In addition, HARQ-ACK multiplexing of a certain priority in PUSCH of a different priority is supported when HARQ-ACK 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:
- UCI carrying HARQ-ACK feedback with 1 or 2 bits is multiplexed by puncturing PUSCH;
- In all other cases UCI is multiplexed by rate matching PUSCH.
UCI consists of the following information:
- CSI;
- ACK/NAK;
- Scheduling request.
Simultaneous transmission of PUCCH and PUSCH associated with different priorities on cells of different bands in a PUCCH group is supported, where UCI multiplexing in the PUCCH associated with a priority in combination of UCI multiplexing in a PUSCH associated with a different priority is supported if the UCI multiplexed on PUSCH is of same priority as the PUSCH.
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.
Transform precoding is applied to PUCCH Format #3 and Format #4.
Channel coding used for uplink control information is described in table 5.3.3-1.
Table 5.3.3-1: Channel coding for uplink control information
Uplink Control Information size including CRC, if present | Channel code |
1 | Repetition code |
2 | Simplex code |
3-11 | Reed Muller code |
>11 | Polar code |
5.3.4 Random access
Random access preamble sequences, of four different lengths are supported. Sequence length 839 is applied with subcarrier spacings of 1.25 and 5 kHz, sequence length 139 is applied with subcarrier spacings of 15, 30, 60, 120, 480, and 960 kHz, sequence length of 571 is applied with subcarrier spacings of 30, 120, and 480 kHz, and sequence length 1151 is applied with subcarrier spacings of 15 and 120 kHz. Sequence length 839 supports unrestricted sets and restricted sets of Type A and Type B, while sequence lengths 139, 571, and 1151 support unrestricted sets only. Sequence length 839 is only used for operation with licensed channel access while sequence length 139 can be used for operation with either licensed or shared spectrum channel access. For FR1, sequence lengths of 571 and 1151 can be used only for operation with shared spectrum channel access. For FR2-2, sequence lengths of 571 and 1151 can be used for operation with either licensed or shared spectrum channel access.
Editor's Note: Restriction of sequence length 1151 to operation with shared spectrum channel access for FR2-2 is FFS.
Multiple PRACH preamble formats are defined with one or more PRACH OFDM symbols, and different CP and guard time. The PRACH preamble configuration to use is provided to the UE in the system information.
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.
5.3.5 Physical layer procedures
5.3.5.1 Link adaptation
Four types of link adaptation are supported as follows:
- Adaptive transmission bandwidth;
- Adaptive transmission duration;
- Transmission power control;
- Adaptive modulation and channel coding rate.
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.2 Uplink Power control
The gNB determines the desired uplink transmit power and provides uplink transmit power control commands to the UE. The UE uses the provided uplink transmit power control commands to adjust its transmit power.
5.3.5.3 Uplink timing control
The gNB (including IAB-DU and IAB-donor-DU) determines the desired Timing Advance setting and provides that to the UE (or IAB-MT). The UE/IAB-MT uses the provided TA to determine its uplink transmit timing relative to the UE's/IAB-MTs observed downlink receive timing.
An IAB-node may support additional modes for uplink timing:
- The IAB-MT uses the provided TA plus a provided additional offset to determine its uplink transmission timing, to facilitate parent node's IAB-MT Rx / IAB-DU Rx multiplexing;
- The IAB-MT aligns its uplink transmission timing to that of the collocated IAB-DU downlink transmission timing, to facilitate IAB-MT Tx / IAB-DU Tx multiplexing of this IAB-node.
The IAB-node uplink timing mode is indicated by the parent node via MAC-CE.
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 if configured.
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.
5.3.5.5 Prioritization of overlapping transmissions
PUSCH and PUCCH can be associated with a priority (high/low) by RRC or L1 signalling. If a PUCCH transmission overlaps in time with a transmission of a PUSCH or another PUCCH, only the PUCCH or PUSCH associated with a high priority can be transmitted.
5.3.6 Uplink Reference Signals and Measurements for Positioning
The periodic, semipersistent and aperiodic transmission of Rel-15 SRS is defined for gNB UL RTOA, UL SRS-RSRP, UL-AoA measurements to facilitate support of UL TDOA and UL AoA positioning methods as described in TS 38.305 [42].
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].
5.4 Carrier aggregation
5.4.1 Carrier aggregation
In Carrier Aggregation (CA), two or more Component Carriers (CCs) are aggregated. A UE may simultaneously receive or transmit on one or multiple CCs depending on its capabilities:
- 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.
5.4.2 Supplementary Uplink
In conjunction with a UL/DL carrier pair (FDD band) or a bidirectional carrier (TDD band), a UE may be configured with additional, Supplementary Uplink (SUL). SUL differs from the aggregated uplink in that the UE may be scheduled to transmit either on the supplementary uplink or on the uplink of the carrier being supplemented, but not on both at the same time.
5.4.3 Uplink Tx switching
In uplink CA or SUL, a UE configured with uplink Tx switching can have Tx dynamically switched from one uplink carrier to another uplink carrier for enabling 2Tx UL transmission on that carrier.
5.5 Transport Channels
The physical layer offers information transfer services to MAC and higher layers. The physical layer transport services are described by how and with what characteristics data are transferred over the radio interface. An adequate term for this is "Transport Channel". This should be clearly separated from the classification of what is transported, which relates to the concept of logical channels at MAC sublayer.
Downlink transport channel types are:
1. Broadcast Channel (BCH) characterised by:
- fixed, pre-defined transport format;
- requirement to be broadcast in the entire coverage area of the cell, either as a single message or by beamforming different BCH instances.
2. Downlink Shared Channel (DL-SCH) characterised by:
- support for HARQ;
- support for dynamic link adaptation by varying the modulation, coding and transmit power;
- possibility to be broadcast in the entire cell;
- possibility to use beamforming;
- support for both dynamic and semi-static resource allocation;
- support for UE discontinuous reception (DRX) to enable UE power saving.
3. Paging Channel (PCH) characterised by:
- 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.
Uplink transport channel types are:
1. Uplink Shared Channel (UL-SCH) characterised by:
- possibility to use beamforming;
- support for dynamic link adaptation by varying the transmit power and potentially modulation and coding;
- support for HARQ;
- support for both dynamic and semi-static resource allocation.
2. Random Access Channel(s) (RACH) characterised by:
- limited control information;
- collision risk.
Sidelink transport channel types are:
1. Sidelink broadcast channel (SL-BCH) characterised by:
- pre-defined transport format.
2. Sidelink shared channel (SL-SCH) characterised by:
- support for unicast transmission, groupcast transmission and broadcast transmission;
- 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 HARQ;
- support for dynamic link adaptation by varying the transmit power, modulation and coding;
- support for SL discontinuous reception (SL DRX) to enable UE power saving.
Association of transport channels to physical channels is described in TS 38.202 [20].
5.6 Access to Shared Spectrum
5.6.1 Overview
NR Radio Access operating with shared spectrum channel access can operate in different modes where either PCell, PSCell, or SCells can be in shared spectrum and an SCell may or may not be configured with uplink. The applicable deployment scenarios are described in Annex B.3.
The gNB performs channel access mode procedures as described in TS 37.213 [37]. The gNB and the 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.
5.6.2 Channel Access Priority Classes
The Channel Access Priority Classes (CAPC) of radio bearers and MAC CEs are either fixed or configurable for operation in FR1:
- Fixed to the lowest priority for the padding BSR and recommended bit rate MAC CEs;
- Fixed to the highest priority for SRB0, SRB1, SRB3 and other MAC CEs;
- Configured by the gNB for SRB2 and DRB.
When choosing the CAPC of a DRB, the gNB takes into account the 5QIs of all the QoS flows multiplexed in that DRB while considering fairness between different traffic types and transmissions. Table 5.6.2-1 below shows which CAPC should be used for which standardized 5QIs i.e. which CAPC to use for a given QoS flow.
NOTE: A QoS flow corresponding to a non-standardized 5QI (i.e. operator specific 5QI) should use the CAPC of the standardized 5QI which best matches the QoS characteristics of the non-standardized 5QI.
Table 5.6.2-1: Mapping between Channel Access Priority Classes and 5QI
CAPC | 5QI |
1 | 1, 3, 5, 65, 66, 67, 69, 70, 79, 80, 82, 83, 84, 85 |
2 | 2, 7, 71 |
3 | 4, 6, 8, 9, 72, 73, 74, 76 |
4 | - |
NOTE: lower CAPC value means higher priority - | |
When performing Type 1 LBT for the transmission of an uplink TB (see TS 37.213 [37], clause 4.2.1.1) and when the CAPC is not indicated in the DCI, the UE shall select the CAPC as follows:
- If only MAC CE(s) are included in the TB, the highest priority CAPC of those MAC CE(s) is used; or
- If CCCH SDU(s) are included in the TB, the highest priority CAPC is used; or
- If DCCH SDU(s) are included in the TB, the highest priority CAPC of the DCCH(s) is used; or
- The lowest priority CAPC of the logical channel(s) with MAC SDU multiplexed in the TB is used otherwise.
5.7 Sidelink
5.7.1 General
Sidelink supports UE-to-UE direct communication using the sidelink resource allocation modes, physical-layer signals/channels, and physical layer procedures below.
5.7.2 Sidelink resource allocation modes
Two sidelink resource allocation modes are supported: mode 1 and mode 2. In mode 1, the sidelink resource allocation is provided by the network. In mode 2, UE decides the SL transmission resources in the resource pool(s).
5.7.3 Physical sidelink channels and signals
Physical Sidelink Control Channel (PSCCH) indicates resource and other transmission parameters used by a UE for PSSCH. PSCCH transmission is associated with a DM-RS.
Physical Sidelink Shared Channel (PSSCH) transmits the TBs of data themselves, and control information for HARQ procedures and CSI feedback triggers, etc. At least 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 Sidelink Feedback Channel (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 synchronization signal 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 9 and 5 symbols for normal and extended CP cases respectively, including the associated DM-RS.
5.7.4 Physical layer procedures for sidelink
5.7.4.1 HARQ feedback
Sidelink HARQ feedback uses PSFCH and can be operated in one of two options. In one option, which can be configured for unicast and groupcast, PSFCH transmits either ACK or NACK using a resource dedicated to a single PSFCH transmitting UE. In another option, which can be configured for groupcast, PSFCH transmits NACK, or no PSFCH signal is transmitted, on a resource that can be shared by multiple PSFCH transmitting UEs.
In sidelink resource allocation mode 1, a UE which received PSFCH can report sidelink HARQ feedback to gNB via PUCCH or PUSCH.
5.7.4.2 Power Control
For in-coverage operation, the power spectral density of the sidelink transmissions can be adjusted based on the pathloss from the gNB.
For unicast, the power spectral density of some sidelink transmissions can be adjusted based on the pathloss between the two communicating UEs.
5.7.4.3 CSI report
For unicast, channel state information reference signal (CSI-RS) is supported for CSI measurement and reporting in sidelink. A CSI report is carried in a sidelink MAC CE.
5.7.5 Physical layer measurement definition
For measurement on the sidelink, the following UE measurement quantities are supported:
- PSBCH reference signal received power (PSBCH RSRP);
- PSSCH reference signal received power (PSSCH-RSRP);
- PSСCH reference signal received power (PSCCH-RSRP);
- Sidelink received signal strength indicator (SL RSSI);
- Sidelink channel occupancy ratio (SL CR);
- Sidelink channel busy ratio (SL CBR).
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:
- The physical layer offers to the MAC sublayer transport channels;
- The MAC sublayer offers to the RLC sublayer logical channels;
- The RLC sublayer offers to the PDCP sublayer RLC channels;
- The PDCP sublayer offers to the SDAP sublayer radio bearers;
- The SDAP sublayer offers to 5GC QoS flows;
- Comp. refers to header compression or uplink data compression;
- Segm. refers to segmentation;
- Control channels (BCCH, PCCH are not depicted for clarity).
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.
Figure 6.1-1: Downlink Layer 2 Structure
Figure 6.1-2: Uplink Layer 2 Structure
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 Layer 2 of NR includes: MAC, RLC, Backhaul Adaptation Protocol (BAP), PDCP and optionally SDAP. 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 BH RLC channels.
Figure 6.1-3: DL L2-structure for user plane at IAB-donor
Figure 6.1-4: DL L2-structure at IAB-node
Figure 6.1-5: UL L2-structure at IAB-node
6.2 MAC Sublayer
6.2.1 Services and Functions
The main services and functions of the MAC sublayer include:
- Mapping between logical channels and 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;
- Scheduling information reporting;
- Error correction through HARQ (one HARQ entity per cell in case of CA);
- Priority handling between UEs by means of dynamic scheduling;
- Priority handling between logical channels of one UE by means of logical channel prioritisation;
- Priority handling between overlapping resources of one UE;
- 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).
6.2.2 Logical Channels
Different kinds of data transfer services as offered by MAC. Each logical channel type is defined by what type of information is transferred. Logical channels are classified into two groups: Control Channels and Traffic Channels. Control channels are used for the transfer of control plane information only:
- 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.
6.2.3 Mapping to Transport Channels
In Downlink, the following connections between logical channels and transport channels exist:
- BCCH can be mapped to BCH;
- BCCH can be mapped to DL-SCH;
- PCCH can be mapped to PCH;
- CCCH can be mapped to DL-SCH;
- DCCH can be mapped to DL-SCH;
- DTCH can be mapped to DL-SCH.
In Uplink, the following connections between logical channels and transport channels exist:
- CCCH can be mapped to UL-SCH;
- DCCH can be mapped to UL- SCH;
- DTCH can be mapped to UL-SCH.
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.
6.3 RLC Sublayer
6.3.1 Transmission Modes
The RLC sublayer supports three transmission modes:
- Transparent Mode (TM);
- Unacknowledged Mode (UM);
- Acknowledged Mode (AM).
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.
6.3.2 Services and Functions
The main services and functions of the RLC sublayer depend on the transmission mode and include:
- Transfer of upper layer PDUs;
- Sequence numbering independent of the one in PDCP (UM and AM);
- Error Correction through ARQ (AM only);
- Segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs;
- Reassembly of SDU (AM and UM);
- Duplicate Detection (AM only);
- RLC SDU discard (AM and UM);
- RLC re-establishment;
- Protocol error detection (AM only).
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;
- Polling for RLC status report is used when needed by RLC;
- RLC receiver can also trigger RLC status report after detecting a missing RLC SDU or RLC SDU segment.
6.4 PDCP Sublayer
6.4.1 Services and Functions
The main services and functions of the PDCP sublayer include:
- Transfer of data (user plane or control plane);
- Maintenance of PDCP SNs;
- Header compression and decompression using the ROHC protocol;
- Header compression and decompression using EHC protocol;
- Compression and decompression of uplink PDCP SDUs: DEFLATE based UDC only;
- Ciphering and deciphering;
- Integrity protection and integrity verification;
- Timer based SDU discard;
- For split bearers, routing;
- Duplication;
- Reordering and in-order delivery;
- 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).
6.5 SDAP Sublayer
The main services and functions of SDAP include:
- Mapping between a QoS flow and a data radio bearer;
- Marking QoS flow ID (QFI) in both DL and UL packets.
A single protocol entity of SDAP is configured for each individual PDU session.
6.6 L2 Data Flow
An example of the Layer 2 Data Flow is depicted on Figure 6.6-1, where a transport block is generated by MAC by concatenating two RLC PDUs from RBx and one RLC PDU from RBy. The two RLC PDUs from RBx each corresponds to one IP packet (n and n+1) while the RLC PDU from RBy is a segment of an IP packet (m).
NOTE: H depicts the headers and subheaders.
Figure 6.6-1: Data Flow Example
6.7 Carrier Aggregation
In case of CA, the multi-carrier nature of the physical layer is only exposed to the MAC layer for which one HARQ entity is required per serving cell as depicted on Figures 6.7-1 and 6.7-2 below:
- 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.
Figure 6.7-1: Layer 2 Structure for DL with CA configured
Figure 6.7-2: Layer 2 Structure for UL with CA configured
6.8 Dual Connectivity
When the UE is configured with SCG, the UE is configured with two MAC entities: one MAC entity for the MCG and one MAC entity for the SCG. Further details of DC operation can be found in TS 37.340 [21].
6.9 Supplementary Uplink
In case of Supplementary Uplink (SUL, see TS 38.101-1 [18]), the UE is configured with 2 ULs for one DL of the same cell, and uplink transmissions on those two ULs are controlled by the network to avoid overlapping PUSCH/PUCCH transmissions in time. Overlapping transmissions on PUSCH are avoided through scheduling while overlapping transmissions on PUCCH are avoided through configuration (PUCCH can only be configured for only one of the 2 ULs of the cell). In addition, initial access is supported in each of the uplink (see clause 9.2.6). An example of SUL is given in Annex B.
6.10 Bandwidth Adaptation
With Bandwidth Adaptation (BA), the receive and transmit bandwidth of a UE need not be as large as the bandwidth of the cell and can be adjusted: the width can be ordered to change (e.g. to shrink during period of low activity to save power); the location can move in the frequency domain (e.g. to increase scheduling flexibility); and the subcarrier spacing can be ordered to change (e.g. to allow different services). A subset of the total cell bandwidth of a cell is referred to as a Bandwidth Part (BWP) and BA is achieved by configuring the UE with BWP(s) and telling the UE which of the configured BWPs is currently the active one.
Figure 6.10-1 below describes a scenario where 3 different BWPs are configured:
- BWP1 with a width of 40 MHz and subcarrier spacing of 15 kHz;
- BWP2 with a width of 10 MHz and subcarrier spacing of 15 kHz;
- BWP3 with a width of 20 MHz and subcarrier spacing of 60 kHz.
Figure 6.10-1: BA Example
6.11 Backhaul Adaptation Protocol Sublayer
6.11.1 Services and Functions
The main service and functions of the BAP sublayer include:
- Transfer of data;
- Routing of packets to next hop;
- Determination of BAP destination and BAP path for packets from upper layers;
- Determination of egress BH RLC channels for packets routed to next hop;
- Differentiating traffic to be delivered to upper layers from traffic to be delivered to egress link;
- Flow control feedback and polling signalling;
- BH RLF detection indication, BH RLF recovery indication, and BH RLF indication;
- BAP header rewriting.
6.11.2 Traffic Mapping from Upper Layers to Layer-2
In upstream direction, the IAB-donor-CU configures the IAB-node with mappings between upstream F1 and non-F1 traffic originated at the IAB-node, and the appropriate BAP routing ID, next-hop BAP address and BH RLC channel. A specific mapping is configured:
- for each F1-U GTP-U tunnel;
- for non-UE associated F1AP messages;
- for UE-associated F1AP messages;
- for non-F1 traffic.
Multiple mappings can contain the same BH 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 nodes.
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 via F1AP. For a boundary IAB-node, the traffic mapping configuration includes information that allows the boundary IAB-node to determine the IAB topology the mapping applies to.
During IAB-node integration, a default BH RLC channel and a default BAP routing ID may be configured via RRC, which can be used for non-F1-U traffic. These default configurations may be updated during topology adaptation scenarios as discussed in TS 38.401 [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].
6.11.3 Routing, BAP Header Rewriting and BH-RLC-channel Mapping on BAP sublayer
Figure 6.11.3-1: Routing and BH RLC channel selection on BAP sublayer
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. For a dual-connected boundary IAB-node that is configured with two BAP addresses, the BAP address in the packet's BAP header is matched with the BAP address configured by the CU of the IAB topology, where the packet has been received.
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 sublayer 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 or a default configuration provided by the IAB-donor-CU via RRC signalling. This F1AP configuration contains the mapping between the BAP routing ID carried in the packet's BAP header and the next-hop node's BAP address.
Table 6.11.3-1: Routing configuration
BAP routing ID | Next-hop BAP address |
Derived from BAP packet's BAP header | Egress BH link to forward packet |
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/IAB-donor-DU with its child-node's BAP address via F1AP, and it provides the IAB-node with its parent-node's BAP address via RRC. For a boundary IAB-node, the routing configuration also indicates the IAB topology it applies to. The BH link to the next-hop node and the next-hop BAP address belong to the IAB topology of the CU that provided the RRC configuration of the BH link to that next-hop node.
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 resolved from the routing entry is considered unavailable for this packet, the IAB-node may perform local rerouting as defined in TS38.340 [31], i.e., select another BH link by considering only the packet's BAP address or, in some cases, by header rewriting. In this manner, the packet can be delivered via an alternative path as defined in TS 38.340 [31].
A BH link may be considered unavailable in case the BH link has RLF. A parent link may be considered unavailable after a BH RLF detection indication has been received on this parent link and before a subsequent BH RLF recovery indication has been received on the same parent link. For DL traffic, a BH link may be considered unavailable for BAP PDUs carrying a certain BAP routing ID due to congestion derived from flow-control feedback information related to this BAP routing ID, as defined in TS 38.340 [31].
For a boundary IAB-node, the routing configuration may carry information on the IAB topology the configuration applies to.
The IAB-node may rewrite the BAP routing ID in the packet's BAP header under the following circumstances:
- A packet is routed between two IAB topologies via a boundary IAB-node as defined in TS 38.401[31]. In this case, the BAP routing ID carried by the received BAP PDU is allocated by the IAB-donor-CU of the ingress IAB topology, while the BAP routing ID carried by the BAP PDU after header rewriting is allocated by the IAB-donor-CU of the egress IAB topology.
- An upstream packet is locally re-routed to a different IAB-donor-DU than indicated by the BAP address in the BAP header of the received packet. The rewritten BAP header carries the BAP address of the alternative IAB-donor-DU and the BAP path ID for a path to this alternative IAB-donor-DU. BAP header rewriting for upstream inter-IAB-donor-DU local rerouting is only applied if neither routing nor local re-routing without header rewriting resolve to an available egress BH link.
For packets that are routed between two IAB topologies via a boundary node, the BAP header rewriting configuration is provided via F1AP, and it includes the ingress BAP routing ID, the egress BAP routing ID, and it indicates the egress IAB topology:
Table 6.11.3-2a: BAP header rewriting configuration
Ingress BAP routing ID | Egress BAP routing ID | Egress topology indicator |
BAP routing ID carried in the BAP header of the received BAP PDU | BAP routing ID carried in the BAP header of the transmitted BAP PDU | Indicates the egress IAB topology. |
For upstream packets that are locally re-routed to a different IAB-donor-DU, the BAP header is rewritten with a BAP routing ID contained in the routing entry that was selected for re-routing.
Details of BAP header rewriting are defined in TS 38.340 [31].
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:
Table 6.11.3-2: BH RLC channel mapping configuration
Next-hop BAP address | Prior-hop BAP address | Ingress RLC channel ID | Egress RLC channel ID |
Derived from routing configuration | Derived from packet's ingress BH link | Derived from packet's ingress BH RLC channel | BH RLC channel on egress BH link to forward packet |
For a boundary IAB-node, the BH RLC channel mapping configuration may also include indicators for the IAB topology of the ingress and of the egress BH link.
The IAB-node resolves the BH RLC channel IDs from logical channel IDs based on the configuration by the IAB-donor-CU. The IAB-MT obtains the BH RLC channel ID in the RRC configuration of the corresponding logical channel. The IAB-DU obtains the BH RLC channel ID in the F1AP configuration of the BH RLC channel.
6.12 Multiple Transmit/Receive Point Operation
In Multiple Transmit/Receive Point (multi-TRP) operation, a serving cell can schedule the UE from two TRPs, providing better coverage, reliability and/or data rates for PDSCH, PDCCH, PUSCH, and PUCCH.
There are two different operation modes to schedule multi-TRP PDSCH transmissions: single-DCI and multi-DCI. For both modes, control of uplink and downlink operation can be done by physical layer and MAC layer, within the configuration provided by the RRC layer. In single-DCI mode, the UE is scheduled by the same DCI for both TRPs and in multi-DCI mode, the UE is scheduled by independent DCIs from each TRP.
There are two different operation modes for multi-TRP PDCCH: PDCCH repetition as in Clause 5.2.3 and SFN based PDCCH transmission. In both modes, the UE can receive two PDCCH transmissions, one from each TRP, carrying the same DCI. In PDCCH repetition mode, the UE can receive the two PDCCH transmissions carrying the same DCI from two linked search spaces each associated with a different CORESET. In SFN based PDCCH transmission mode, the UE can receive the two PDCCH transmissions carrying the same DCI from a single search space/CORESET using different TCI states.
For multi-TRP PUSCH repetition, according to indications in a single DCI or in a semi-static configured grant provided over RRC, the UE performs PUSCH transmission of the same contents toward two TRPs with corresponding beam directions associated with different spatial relations. For multi-TRP PUCCH repetition, the UE performs PUCCH transmission of the same contents toward two TRPs with corresponding beam directions associated with different spatial relations.
For inter-cell multi-TRP operation, for multi-DCI PDSCH transmission, one or more TCI states can be associated with SSB with a PCI different from the serving cell PCI. The activated TCI states can be associated with at most one PCI different from the serving cell PCI at a time.
7 RRC
7.1 Services and Functions
The main services and functions of the RRC sublayer over the Uu interface include:
- Broadcast of System Information related to AS and NAS;
- Paging initiated by 5GC or NG-RAN;
- Establishment, maintenance and release of an RRC connection between the UE and NG-RAN including:
- Addition, modification and release of carrier aggregation;
- Addition, modification and release of Dual Connectivity in NR or between E-UTRA and NR.
- Security functions including key management;
- Establishment, configuration, maintenance and release of Signalling Radio Bearers (SRBs) and Data Radio Bearers (DRBs);
- Mobility functions including:
- Handover and context transfer;
- UE cell selection and reselection and control of cell selection and reselection;
- Inter-RAT mobility.
- QoS management functions;
- UE measurement reporting and control of the reporting;
- Detection of and recovery from radio link failure;
- NAS message transfer to/from NAS from/to UE.
The sidelink specific services and functions of the RRC sublayer over the Uu interface include:
- Configuration of sidelink resource allocation via system information or dedicated signalling;
- Reporting of UE sidelink information;
- Measurement configuration and reporting related to sidelink;
- Reporting of UE assistance information for SL traffic pattern(s).
7.2 Protocol States
RRC supports the following states which can be characterised as follows:
- RRC_IDLE:
- PLMN selection;
- Broadcast of system information;
- Cell re-selection mobility;
- Paging for mobile terminated data is initiated by 5GC;
- Transfer of MBS broadcast data to the UE over MRB(s);
- DRX for CN paging configured by NAS.
- RRC_INACTIVE:
- PLMN selection;
- Broadcast of system information;
- Cell re-selection mobility;
- Paging is initiated by NG-RAN (RAN paging);
- RAN-based notification area (RNA) is managed by NG- RAN;
- DRX for RAN paging configured by NG-RAN;
- 5GC - NG-RAN connection (both C/U-planes) is established for UE;
- The UE Inactive AS context is stored in NG-RAN and the UE;
- NG-RAN knows the RNA which the UE belongs to;
- Transfer of MBS broadcast data to the UE over MRB(s);
- Transfer of unicast data and/or signalling to/from the UE over radio bearers configured for SDT.
- RRC_CONNECTED:
- 5GC - NG-RAN connection (both C/U-planes) is established for UE;
- The UE AS context is stored in NG-RAN and the UE;
- NG-RAN knows the cell which the UE belongs to;
- Transfer of unicast data to/from the UE;
- Transfer of MBS multicast/broadcast data to the UE over MRB(s);
- Network controlled mobility including measurements.
7.3 System Information Handling
7.3.1 Overview
System Information (SI) consists of a MIB and a number of SIBs, which are divided into Minimum SI and Other SI:
- 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, 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 or when the UE configured with inter cell beam management is receiving DL-SCH from a TRP with PCI different from serving cell's PCI). 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), which can also be used for NR idle/inactive measurements;
- 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);
- SIB6 contains an ETWS primary notification;
- SIB7 contains an ETWS secondary notification;
- SIB8 contains a CMAS warning notification;
- 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;
- SIB11 contains information related to idle/inactive measurements;
- SIB15 contains information related to disaster roaming;
- SIB16 contains slice-based cell reselection information;
- SIB17 contains information related to TRS configuration for UEs in RRC_IDLE/RRC_INACTIVE;
- SIBpos contains positioning assistance data as defined in TS 37.355 [43] and TS 38.331 [12];
- SIB18 contains information related to the Group IDs for Network selection (GINs) associated with SNPNs listed in SIB1.
For sidelink, Other SI also includes:
- SIB12 contains information related to NR sidelink communication;
- SIB13 contains information related to SystemInformationBlockType21 for V2X sidelink communication as specified in TS 36.331 clause 5.2.2.28 [29];
- SIB14 contains information related to SystemInformationBlockType26 for V2X sidelink communication as specified in TS 36.331 clause 5.2.2.33 [29].
For non-terrestrial network, Other SI also includes:
- SIB19 contains NTN-specific parameters for serving cell and optionally NTN-specific parameters for neighbour cells as defined in TS 38.331 [12].
For MBS broadcast, Other SI also includes:
- SIB20 contains MCCH configuration;
- SIB21 contains information related to service continuity for MBS broadcast reception.
Figure 7.3.1-1 below summarises System Information provisioning.
Figure 7.3.1-1: System Information Provisioning
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.
In case of BA, the UE only acquires SI on the active BWP.
If the UE is configured with inter cell beam management:
- the UE is not required to acquire the SI from the serving cell while it is receiving DL-SCH from a TRP with PCI different from serving cell's PCI.
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 while SDT procedure is not ongoing (see clause 18), 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 next modification period. The UE applies the previously acquired system information until the UE acquires the new system information.
7.4 Access Control
NG-RAN supports overload and access control functionality such as RACH back off, RRC Connection Reject, RRC Connection Release and UE based access barring mechanisms.
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.
Unified access control does not apply to IAB-MTs.
7.5 UE Capability Retrieval framework
The UE reports its UE radio access capabilities which are static at least when the network requests. The gNB can request what capabilities for the UE to report based on band information. The UE capability can be represented by a capability ID, which may be exchanged in NAS signalling over the air and in network signalling instead of the UE capability structure.
In IAB, it is optional for an IAB-MT to support UE capability Retrieval framework and the related signalling. In case IAB-MT does not support UE capability Retrieval framework, IAB-MT capabilities are assumed to be known to the network by other means, e.g. OAM.
7.6 Transport of NAS Messages
NR provides reliable in-sequence delivery of NAS messages over SRBs in RRC, except at handover where losses or duplication can occur when PDCP is re-established. In RRC, NAS messages are sent in transparent containers. Piggybacking of NAS messages can occur in the following scenarios:
- At bearer establishment/modification/release in the DL;
- 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.
NG-RAN node may trigger the NAS Non Delivery Indication procedure to report the non-delivery of the non PDU Session related NAS PDU received from the AMF as specified in TS 38.413 [26].
7.7 Carrier Aggregation
When CA is configured, the UE only has one RRC connection with the network. At RRC connection establishment/re-establishment/handover, one serving cell provides the NAS mobility information, and at RRC connection re-establishment/handover, one serving cell provides the security input. This cell is referred to as the Primary Cell (PCell). Depending on UE capabilities, Secondary Cells (SCells) can be configured to form together with the PCell a set of serving cells. The configured set of serving cells for a UE therefore always consists of one PCell and one or more SCells.
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 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.
7.8 Bandwidth Adaptation
To enable BA on the PCell, the gNB configures the UE with UL and DL BWP(s). To enable BA on SCells in case of CA, the gNB configures the UE with DL BWP(s) at least (i.e. there may be none in the UL). For the PCell, the BWP used for initial access is configured via system information. For the SCell(s), the BWP used after initial activation is configured via dedicated RRC signalling.
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.
7.9 UE Assistance Information
When configured to do so, the UE can signal the network through UEAssistanceInformation:
- If it prefers an adjustment in the connected mode DRX cycle length, for the purpose of delay budget reporting;
- If it is experiencing internal overheating;
- 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;
- If it prefers (not) to be provisioned with reference time information;
- If it prefers to transition out of RRC_CONNECTED state for MUSIM operation and its preferred RRC state after transition;
- If it wants to include assistance information for setup or release of gaps for MUSIM operation;
- The list of frequencies affected by IDC problems (see clause 23.4 of TS 36.300 [2]);
- Its RRM measurement relaxation status indicating whether RRM measurement relaxation criteria are met or not;
- Its RLM measurement relaxation status indicating whether the UE is applying RLM measurements relaxation;
- Its BFD measurement relaxation status indicating whether the UE is applying BFD measurements relaxation.
NOTE: Only the Frequency Division Multiplexing (FDM) solution as defined for E-UTRA in clause 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.
7.10 Segmentation of RRC messages
An RRC message may be segmented in case the size of the encoded RRC message PDU exceeds the maximum PDCP SDU size. Segmentation is performed in the RRC layer using a separate RRC PDU to carry each segment. The receiver reassembles the segments to form the complete RRC message. All segments of an RRC message are transmitted before sending another RRC message. Segmentation is supported in both uplink and downlink as specified in TS 38.331 [12].
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;
- CI-RNTI: identification of cancellation in the uplink;
- CS-RNTI: unique UE identification used for Semi-Persistent Scheduling in the downlink or configured grant in the uplink;
- INT-RNTI: identification of pre-emption in the downlink;
- 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;
- SI-RNTI: identification of Broadcast and System Information in the downlink;
- SP-CSI-RNTI: unique UE identification used for semi-persistent CSI reporting on PUSCH.
For power and slot format control, the following identities are used:
- SFI-RNTI: identification of slot format;
- TPC-PUCCH-RNTI: unique UE identification to control the power of PUCCH;
- TPC-PUSCH-RNTI: unique UE identification to control the power of PUSCH;
- TPC-SRS-RNTI: unique UE identification to control the power of SRS.
During the random access procedure, the following identities are also used:
- RA-RNTI: identification of the Random Access Response in the downlink;
- 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 identity is used at NG-RAN level:
- I-RNTI: used to identify the UE context in RRC_INACTIVE.
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.
For IAB the following identity is used:
- AI-RNTI: identification of the DCI carrying availability indication for soft symbols of an IAB-DU.
For MBS, the following identities are used:
- G-RNTI: Identifies dynamically scheduled PTM transmissions of MTCH(s);
- G-CS-RNTI: Identifies configured scheduled PTM transmissions of MTCH(s) scheduled with configured grant;
- MCCH-RNTI: Identifies transmissions of MCCH and MCCH change notification.
8.2 Network Identities
The following identities are used in NG-RAN for identifying a specific network entity:
- AMF Name: used to identify an AMF.
- 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 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.
- Network Slice AS Group (NSAG): identifies an association to a slice or a set of slices. An NSAG is defined within a TA, used for slice-based cell reselection and/or slice-based RACH configuration. Values of NSAG IDs associated with different slice or set of slices shall be unique within a TA, also when slice-based cell reselection and slice-based RACH configuration are both supported in the TA.
- Network Identifier (NID): identifies an SNPN in combination with a PLMN ID.
- Closed Access Group Identifier: identifies a CAG within a PLMN.
- Local NG-RAN Node Identifier: used as reference to the NG-RAN node in the I-RNTI.
8.3 User Data Transport on the CN-RAN Interface
The core network may provide two transport layer addresses of different versions to enable that a NG-RAN node can select either IPv4 or IPv6.
8.4 NR sidelink communication and V2X sidelink communication related identities
The following identities are used for NR sidelink communication:
- 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 to upper layers the PC5 unicast link in which sidelink RLF was declared and corresponding PC5-RRC connection was released.
V2X sidelink communication related identities are specified in clause 8.3 of TS 36.300 [2].
9 Mobility and State Transitions
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;
- Inter-RAT measurements for E-UTRA;
- Inter-RAT measurements for UTRA.
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:
- Associate several reporting configurations to one measurement object and;
- Associate one reporting configuration to several measurement objects.
The measurements identity is used as well when reporting results of the measurements.
Measurement quantities are considered separately for each RAT.
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.
9.2 Intra-NR
9.2.1 Mobility in RRC_IDLE
9.2.1.1 Cell Selection
The principles of PLMN selection in NR are based on the 3GPP PLMN selection principles. Cell selection is required on transition from RM-DEREGISTERED to RM-REGISTERED, from CM-IDLE to CM-CONNECTED and from CM-CONNECTED to CM-IDLE and is based on the following principles:
- The UE NAS layer identifies a selected PLMN and equivalent PLMNs;
- 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:
On transition from RRC_CONNECTED or RRC_INACTIVE to RRC_IDLE, a UE should camp on a cell as result of cell selection according to the frequency be assigned by RRC in the state transition message if any.
Recovery from out of coverage:
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).
9.2.1.2 Cell Reselection
A UE in RRC_IDLE performs cell reselection. The principles of the procedure are the following:
- 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.
- 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:
- Intra-frequency reselection is based on ranking of cells;
- Inter-frequency reselection is based on absolute priorities where a UE tries to camp on the highest priority frequency available;
- A Neighbour Cell List (NCL) can be provided by the serving cell to handle specific cases for intra- and inter-frequency neighbouring cells;
- Exclude-lists can be provided to prevent the UE from reselecting to specific intra- and inter-frequency neighbouring cells;
- Allow-lists can be provided to request the UE to reselect to only specific intra- and inter-frequency neighbouring cells;
- Cell reselection can be speed dependent;
- Service specific prioritisation;
- Slice-based cell reselection information can be provided to facilitate the UE to reselect a cell that supports specific slices.
In multi-beam operations, the cell quality is derived amongst the beams corresponding to the same cell (see clause 9.2.4).
9.2.1.3 State Transitions
The following figure describes the UE triggered transition from RRC_IDLE to RRC_CONNECTED (for the NAS part, see TS 23.502 [22]):
Figure 9.2.1.3-1: UE triggered transition from RRC_IDLE to RRC_CONNECTED
1. The UE requests to setup a new connection from RRC_IDLE.
2/2a. The gNB completes the RRC setup procedure.
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.
7/7a. The gNB activates the AS security with the UE.
8/8a. The gNB performs the reconfiguration to setup SRB2 and DRBs for UE, or SRB2 and optionally DRBs for IAB-MT.
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:
Figure 9.2.1.3-2: Rejection of UE triggered transition from RRC_IDLE
1. UE attempts to setup a new connection from RRC_IDLE.
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 Mobility in RRC_INACTIVE
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, and to assist UE configuration and paging in 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, the Expected UE Behaviour, the UE Radio Capability for Paging, the PEI with Paging Subgrouping assistance information and the NR Paging eDRX Information and Paging Cause Indication for Voice Service. 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. The NG-RAN node may use the UE Radio Capability for Paging during RAN Paging. The NG-RAN node takes into account the PEI with Paging Subgrouping assistance information for subgroup paging in RRC_INACTIVE. When sending the XnAP RAN Paging to neighbour NG-RAN node(s), the PEI with Paging Subgrouping assistance information may be included. The NG-RAN node takes into account the NR Paging eDRX Information to configure the RAN Paging when the NR UE is in RRC_INACTIVE. When sending XnAP RAN Paging to neighbour NG-RAN node(s), the NR Paging eDRX Information for RRC_IDLE and for RRC_INACTIVE may be included. The NG-RAN node takes into consideration the Paging Cause Indication for Voice Service to include the Paging Cause in RAN Paging for a UE in RRC_INACTIVE state. When sending XnAP RAN Paging to neighbour NG-RAN node(s), the Paging Cause may be included.
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.
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 non PDU Session related NAS PDU received from the AMF as specified in TS 38.413 [26].
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.
9.2.2.2 Cell Reselection
A UE in RRC_INACTIVE performs cell reselection. The principles of the procedure are as for the RRC_IDLE state (see clause 9.2.1.2).
9.2.2.3 RAN-Based Notification Area
A UE in the RRC_INACTIVE state can be configured by the last serving NG-RAN node with an RNA, where:
- 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.
- List of RAN areas:
- 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, in case of network sharing with multiple cell ID broadcast, 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.
9.2.2.4 State Transitions
9.2.2.4.1 UE triggered transition from RRC_INACTIVE to RRC_CONNECTED
The following figure describes the UE triggered transition from RRC_INACTIVE to RRC_CONNECTED in case of UE context retrieval success:
Figure 9.2.2.4.1-1: UE triggered transition from RRC_INACTIVE to RRC_CONNECTED
(UE context retrieval success)
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 provides 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.
7/8. The gNB performs path switch.
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:
Figure 9.2.2.4.1-2: UE triggered transition from RRC_INACTIVE to RRC_CONNECTED
(UE context retrieval failure)
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.
4. The last serving gNB indicates the failure to the gNB.
5. The gNB performs a fallback to establish a new RRC connection by sending RRCSetup.
6. A new connection is setup as described in clause 9.2.1.3.
The following figure describes the rejection form the network when the UE attempts to resume a connection from RRC_INACTIVE:
Figure 9.2.2.4.1-3: Reject from the network, UE attempts to resume a connection
1. UE attempts to resume the connection from RRC_INACTIVE.
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.
9.2.2.4.2 Network triggered transition from RRC_INACTIVE to RRC_CONNECTED
The following figure describes the network triggered transition from RRC_INACTIVE to RRC_CONNECTED:
Figure 9.2.2.4.2-1: Network triggered transition from RRC_INACTIVE to RRC_CONNECTED
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).
3. The UE is paged with the I-RNTI.
4. If the UE has been successfully reached, it attempts to resume from RRC_INACTIVE, as described in clause 9.2.2.4.1.
9.2.2.5 RNA update
The following figure describes the UE triggered RNA update procedure involving context retrieval over Xn. The procedure may be triggered when the UE moves out of the configured RNA, or periodically.
Figure 9.2.2.5-1: RNA update procedure with UE context relocation
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 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.
6./7. The gNB performs path switch.
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:
Figure 9.2.2.5-2: Periodic RNA update procedure without UE context relocation
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.
4. The gNB forwards the RRCRelease message to the UE.
The following figure describes the RNA update procedure for the case when the last serving gNB decides to move the UE to RRC_IDLE:
Figure 9.2.2.5-3: RNA update procedure with transition to RRC_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.
4. The last serving gNB deletes the UE context.
5. The gNB sends the RRCRelease which triggers the UE to move to RRC_IDLE.
9.2.2.6 Resume request responded with Release with Redirect, with UE context relocation
The following figure describes a UE triggered NAS procedure responded by the network with a release with redirect, with UE context relocation.
Figure 9.2.2.6-1: Resume request responded with Release with Redirect, with UE Context relocation
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 provides the UE context.
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, including a release with redirect indication (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.
6./7. The gNB performs path switch.
8. The gNB keeps the UE in RRC_INACTIVE state by sending RRCRelease with suspend indication, including redirection information (frequency layer the UE performs cell selection upon entering RRC_INACTIVE).
9. The gNB triggers the release of the UE resources at the last serving gNB.
NOTE1: Upon receiving the release with redirect, the higher layers trigger a pending procedure so the UE tries to resume again after cell selection.
9.2.3 Mobility in RRC_CONNECTED
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. Beam level mobility includes intra-cell beam level mobility and inter-cell 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:
Figure 9.2.3.1-1: Inter-gNB handover procedures
1. The source gNB initiates handover and issues a HANDOVER REQUEST over the Xn interface.
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.
Only source and target PCell are used during DAPS handover. CA, DC, SUL, multi-TRP, EHC, CHO, UDC, NR sidelink configurations and V2X sidelink configurations are released by the source gNB before the handover command is sent to the UE and are not configured by the target gNB until the DAPS handover has completed (i.e. at earliest in the same message that releases the source PCell).
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:
- Creates a MAC entity for target;
- Establishes the RLC entity and an associated DTCH logical channel for target for each DRB configured with DAPS;
- For each 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: Void.
NOTE 3: Void.
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, PDCP can either be re-established together with a security key change or remain as it is without a key change. For SRBs, PDCP can either remain as it is, discard its stored PDCP PDUs/SDUs without a key change or be re-established together with a security 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 handover scenarios:
- When DAPS handover fails, the UE falls back to the source cell configuration, resumes the connection with the source cell, and reports DAPS handover 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 handover/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].
Beam Level Mobility does not require explicit RRC signalling to be triggered. Beam level mobility can be within a cell, or between cells, the latter is referred to as inter-cell beam management (ICBM). For ICBM, a UE can receive or transmit UE dedicated channels/signals via a TRP associated with a PCI different from the PCI of a serving cell, while non-UE-dedicated channels/signals can only be received via a TRP associated with a PCI of the serving cell. 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. In case of ICBM, a measurement configuration includes SSB resources associated with PCIs different from the PCI of a serving cell. 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
9.2.3.2.1 C-Plane Handling
The intra-NR RAN handover performs the preparation and execution phase of the handover procedure performed without involvement of the 5GC, i.e. preparation messages are directly exchanged between the gNBs. The release of the resources at the source gNB during the handover completion phase is triggered by the target gNB. The figure below depicts the basic handover scenario where neither the AMF nor the UPF changes:
Figure 9.2.3.2.1-1: Intra-AMF/UPF Handover
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 one or more DRBs.
NOTE 1: 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 2: 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 3: 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 4: 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.
NOTE 4a: CHO cannot be configured simultaneously with DAPS handover.
7a. For DRBs configured with DAPS, 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 5: 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 6: 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 handover, the UE does not detach from the source cell upon receiving the RRCReconfiguration message. The UE releases the source resources and configurations and stops DL/UL reception/transmission with the source upon receiving an explicit release from the target node.
NOTE 6a: From RAN point of view, the DAPS handover is considered to only be completed after the UE has released the source cell as explicitly requested from the target node. RRC suspend, a subsequent handover or inter-RAT handover cannot be initiated until the source cell has been released.
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 7: 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.
NOTE 8: For DRBs configured with DAPS, 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 9: Void.
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:
i) Common RACH configuration;
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.
Upon receiving a handover command requesting DAPS handover, 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 resumes source cell SRBs for control plane signalling transmission.
9.2.3.2.2 U-Plane Handling
The U-plane handling during the Intra-NR-Access mobility activity for UEs in RRC_CONNECTED takes the following principles into account to avoid data loss during HO:
- 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;
- 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 RLC-AM bearers:
- 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 1: 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 5GC on the new DRB. In the UL, the target gNB should not deliver data of the QoS flow from the new DRB to 5GC 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.
- In case of handovers involving Full Configuration, the following description below for RLC-UM bearers applies for RLC-AM bearers instead. Data loss may happen.
For RLC-UM bearers:
- The PDCP SN and HFN are reset in the target gNB, unless the bearer is configured with DAPS handover;
- No PDCP SDUs are retransmitted in the target gNB;
- The target gNB prioritises all downlink SDAP SDUs forwarded by the source gNB over the data from the core network;
NOTE 2: 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 5GC on the new DRB. In the UL, the target gNB should not deliver data of the QoS flow from the new DRB to 5GC 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:
- During HO preparation, a forwarding tunnel is always established.
- 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.
- 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 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 PDCP entity configured with DAPS maintains separate security and ROHC header decompression functions associated with each gNB, while maintaining common functions for reordering, duplicate detection and discard, 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 towards the target gNB, 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-)transmissions 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.
- The establishment of a forwarding tunnel is optional.
- HFN and PDCP SN are maintained in the target gNB. The SN STATUS TRANSFER message indicates the COUNT of the first missing PDCP SDU that the target should start delivering to the 5GC, even for RLC-UM.
9.2.3.2.3 Data Forwarding
The following description depicts the data forwarding principles for intra-system handover.
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.
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.
For handovers involving Full Configuration, the source NG-RAN node behaviour is unchanged from the description above. In case a DRB DL forwarding tunnel was established, the target NG-RAN node may identify the PDCP SDUs for which delivery was attempted by the source NG-RAN node, by the presence of the PDCP SN in the forwarded GTP-U packet and may discard them.
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.
For DRBs configured with DAPS handover, data forwarding after the source gNB receives the HANDOVER SUCCESS message from the target gNB follows the same behaviors as described above.
For DRBs configured with DAPS handover, before the source gNB receives the HANDOVER SUCCESS message:
- 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.
Handling of end marker packets:
- 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.
9.2.3.3 Re-establishment procedure
A UE in RRC_CONNECTED may initiate the re-establishment procedure to continue the RRC connection when a failure condition occurs (e.g. radio link failure, reconfiguration failure, integrity check failure…).
The following figure describes the re-establishment procedure started by the UE:
Figure 9.2.3.3-1: Re-establishment procedure
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.
2. If the UE Context is not locally available, the gNB, requests the last serving gNB to provide UE Context data.
3. The last serving gNB provides 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.
8/9. The gNB performs path switch.
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 Conditional Handover
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.
The following principles apply to CHO:
- 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 also supported for the IAB-MT in context of intra- and inter-donor IAB-node migration and BH RLF recovery.
CHO is not supported for NG-C based handover in this release of the specification.
9.2.3.4.2 C-plane handling
As in intra-NR RAN handover, in intra-NR RAN CHO, the preparation and execution phase of the conditional handover procedure is performed without involvement of the 5GC; i.e. preparation messages are directly exchanged between gNBs. The release of the resources at the source gNB during the conditional handover completion phase is triggered by the target gNB. The figure below depicts the basic conditional handover scenario where neither the AMF nor the UPF changes:
Figure 9.2.3.4.2-1: Intra-AMF/UPF Conditional Handover
0/1. Same as step 0, 1 in Figure 9.2.3.2.1-1 of clause 9.2.3.2.1.
2. The source gNB decides to use CHO.
3. The source gNB requests CHO for one or more candidate cells belonging to one or more candidate gNBs. A CHO request message is sent for each candidate cell.
4. Same as step 4 in Figure 9.2.3.2.1-1 of clause 9.2.3.2.1.
5. The candidate gNB(s) sends CHO response (HO REQUEST ACKNOWLEDGE) including configuration of CHO candidate cell(s) to the source gNB. The CHO response message is 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.
NOTE 1a: A configuration of a CHO candidate cell cannot contain a DAPS handover configuration.
7. The UE sends an RRCReconfigurationComplete message to 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 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 following the principles described in step 7 of Intra-AMF/UPF Handover in clause 9.2.3.2.1.
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 candidate target gNBs, if any, to cancel CHO for the UE.
9.2.3.4.3 U-plane handling
The U-plane handling for Conditional Handover follows the same principles for DAPS handover in 9.2.3.2.2, if early data forwarding is applied, except that, in case of Full Configuration, HFN and PDCP SN are reset in the target gNB after the SN assignment is handed over to the target gNB. If late data forwarding is applied, the U-plane handling follows the RLC-AM or RLC-UM bearer principles defined in 9.2.3.2.2.
9.2.3.4.4 Data Forwarding
If late data forwarding is applied, the source NG-RAN node initiates data forwarding once it knows which target NG-RAN node the UE has successfully accessed. In that case the behavior of the Conditional Handover data forwarding follows the same behavior as defined in 9.2.3.2.3 for the intra-system handover data forwarding, except the behavior for DRBs configured with DAPS handover.
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 handover 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.
The corresponding high-level measurement model is described below:
Figure 9.2.4-1: Measurement Model
NOTE 1: K beams correspond to the measurements on SSB or CSI-RS resources configured for L3 mobility by gNB and detected by UE at L1.
- A: measurements (beam specific samples) internal to the physical layer.
- 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) is 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).
- D: measurement report information (message) sent on the radio interface.
- 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.
- 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 are characterized by the following:
- 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 an exclude-list configured by the network are not used in event evaluation and reporting, and conversely when an allow-list is configured by the network, only the cells belonging to the allow-list 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:
- SSB based intra-frequency measurement: a measurement is defined as an SSB based intra-frequency measurement provided the center frequency of the SSB of the serving cell and the center frequency of the SSB of the neighbour cell are the same, and the subcarrier spacing of the two SSBs is also the same.
- SSB based inter-frequency measurement: a measurement is defined as an SSB based inter-frequency measurement provided the center frequency of the SSB of the serving cell and the center frequency of the SSB of the neighbour cell are different, or the subcarrier spacing of the two SSBs is different.
NOTE 2: For SSB based measurements, one measurement object corresponds to one SSB and the UE considers different SSBs as different cells.
NOTE 2a: If a RedCap UE is configured to perform serving cell measurements based on an NCD-SSB configured in its active BWP, this NCD-SSB is considered as the SSB of the serving cell in the definition of intra-frequency and inter-frequency measurements as above.
- CSI-RS based intra-frequency measurement: a measurement is defined as a CSI-RS based intra-frequency measurement provided that:
- The subcarrier spacing of CSI-RS resources on the neighbour cell configured for measurement is the same as the SCS of CSI-RS resources on the serving cell indicated for measurement; and
- For 60kHz subcarrier spacing, the CP type of CSI-RS resources on the neighbour cell configured for measurement is the same as the CP type of CSI-RS resources on the serving cell indicated for measurement; and
- The centre frequency of CSI-RS resources on the neighbour cell configured for measurement is the same as the centre frequency of CSI-RS resource on the serving cell indicated for measurement.
- CSI-RS based inter-frequency measurement: a measurement is defined as a CSI-RS based inter-frequency measurement if it is not a CSI-RS based intra-frequency measurement.
NOTE 3: Extended CP for CSI-RS based measurement is not supported in this release.
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· 25岁的心里话
· 闲置电脑爆改个人服务器（超详细） #公网映射 #Vmware虚拟网络编辑器
· 基于 Docker 搭建 FRP 内网穿透开源项目（很简单哒）
· 零经验选手，Compose 一天开发一款小游戏！
· 通过 API 将Deepseek响应流式内容输出到前端