3GPP TS 36.300: Technical Specification

3GPP TS 36.300 V17.2.
0 (2022-09)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Radio Access Network;
Evolved Universal Terrestrial Radio Access (E-UTRA)
and Evolved Universal Terrestrial Radio Access Network
(E-UTRAN);
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.
Release 17 3 3GPP TS 36.300 V17.2.0 (2022-09)
Keywords
LTE, E-UTRAN, stage 2, radio, architecture
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
Bluetooth® is a Trade Mark of the Bluetooth SIG registered for the benefit of its members
3GPP
Release 17 4 3GPP TS 36.300 V17.2.0 (2022-09)
Contents
Foreword........................................................................................................................................................
1 Scope....................................................................................................................................................
2 References............................................................................................................................................
3 Definitions, symbols and abbreviations................................................................................................
3.1 Definitions.........................................................................................................................................................
3.2 Abbreviations.....................................................................................................................................................
4 Overall architecture..............................................................................................................................
4.0 General...............................................................................................................................................................
4.1 Functional Split..................................................................................................................................................
4.2 Void...................................................................................................................................................................
4.2.1 Void..............................................................................................................................................................36
4.2.2 Void..............................................................................................................................................................36
4.3 Radio Protocol architecture...............................................................................................................................
4.3.0 General.........................................................................................................................................................36
4.3.1 User plane....................................................................................................................................................36
4.3.2 Control plane................................................................................................................................................36
4.4 Synchronization.................................................................................................................................................
4.5 IP fragmentation................................................................................................................................................
4.6 Support of HeNBs.............................................................................................................................................
4.6.1 Architecture..................................................................................................................................................37
4.6.2 Functional Split............................................................................................................................................39
4.6.3 Interfaces......................................................................................................................................................41
4.6.3.1 Protocol Stack for S1 User Plane...........................................................................................................41
4.6.3.2 Protocol Stacks for S1 Control Plane.....................................................................................................42
4.6.3.3 Protocol Stack for S5 interface...............................................................................................................43
4.6.3.4 Protocol Stack for SGi interface.............................................................................................................43
4.6.3.5 Protocol Stack for X2 User Plane and X2 Control Plane.......................................................................43
4.6.4 Void..............................................................................................................................................................43
4.6.5 Support of LIPA with HeNB.......................................................................................................................43
4.6.6 Support of X2 GW.......................................................................................................................................45
4.6.6.1 Enhanced TNL Address Discovery........................................................................................................46
4.6.6.2 Routing of X2AP messages....................................................................................................................46
4.6.6.3 (H)eNB unavailability............................................................................................................................46
4.6.6.4 (H)eNB registration................................................................................................................................46
4.7 Support for relaying...........................................................................................................................................
4.7.1 General.........................................................................................................................................................46
4.7.2 Architecture..................................................................................................................................................46
4.7.3 S1 and X2 user plane aspects.......................................................................................................................47
4.7.4 S1 and X2 control plane aspects..................................................................................................................48
4.7.5 Radio protocol aspects.................................................................................................................................49
4.7.6 Signalling procedures...................................................................................................................................50
4.7.6.1 RN attach procedure...............................................................................................................................50
4.7.6.2 E-RAB activation/modification..............................................................................................................51
4.7.6.3 RN startup procedure.............................................................................................................................51
4.7.6.4 RN detach procedure..............................................................................................................................52
4.7.6.5 Neighbouring Information Transfer.......................................................................................................53
4.7.6.6 Mobility to or from RN..........................................................................................................................53
4.7.7 Relay Node OAM Aspects...........................................................................................................................53
4.7.7.1 Architecture............................................................................................................................................53
4.7.7.2 OAM Traffic QoS Requirements...........................................................................................................54
4.7.7.3 Security Aspects.....................................................................................................................................54
4.7.7.4 Void........................................................................................................................................................54
4.7.7.5 OAM Requirements for Configuration Parameters...............................................................................54
4.7.7.5.1 Parameters Associated with Relay Bearer Mapping........................................................................54
4.8 Support of SIPTO at the Local Network...........................................................................................................
3GPP
Release 17 5 3GPP TS 36.300 V17.2.0 (2022-09)
4.8.1 General.........................................................................................................................................................54
4.8.2 SIPTO at the Local Network with collocated L-GW...................................................................................54
4.8.3 Support for SIPTO@LN with Stand-Alone Gateway..................................................................................56
4.9 Support for Dual Connectivity..........................................................................................................................
4.9.1 General.........................................................................................................................................................56
4.9.2 Radio Protocol Architecture.........................................................................................................................56
4.9.3 Network Interfaces.......................................................................................................................................57
4.9.3.1 E-UTRAN Control Plane for Dual Connectivity...................................................................................57
4.9.3.2 E-UTRAN User Plane for Dual Connectivity........................................................................................57
4.9.3.3 Support of HeNBs for Dual Connectivity..............................................................................................58
4.9.3.4 Support of SIPTO@LN and LIPA for Dual Connectivity.....................................................................58
4.10 NB-IoT...............................................................................................................................................................
4.11 Support for UE assistance information for local cache.....................................................................................
4.12 Support of Non-Terrestrial Networks................................................................................................................
5 Physical Layer for E-UTRA.................................................................................................................
5.0 Frame structures and channels...........................................................................................................................
5.1 Downlink Transmission Scheme.......................................................................................................................
5.1.1 Basic transmission scheme based on OFDM...............................................................................................65
5.1.1a Basic transmission scheme based on OFDM for NB-IoT............................................................................65
5.1.2 Physical-layer processing.............................................................................................................................66
5.1.3 Physical downlink control channels.............................................................................................................66
5.1.4 Downlink Reference signal and synchronization signals............................................................................67
5.1.4a Downlink Reference signal and synchronization signals for NB-IoT.........................................................68
5.1.5 Downlink multi-antenna transmission.........................................................................................................68
5.1.5a Downlink multi-antenna transmission for NB-IoT......................................................................................68
5.1.6 MBSFN transmission...................................................................................................................................68
5.1.7 Physical layer procedure..............................................................................................................................69
5.1.7.1 Link adaptation.......................................................................................................................................69
5.1.7.2 Power Control........................................................................................................................................69
5.1.7.3 Cell search..............................................................................................................................................69
5.1.7.3a Cell search for NB-IoT...........................................................................................................................69
5.1.8 Physical layer measurements definition.......................................................................................................69
5.1.9 Coordinated Multi-Point transmission.........................................................................................................70
5.1.10 Wake-up signal for NB-IoT.........................................................................................................................70
5.1.11 Wake-up signal for BL UE or UE in enhanced coverage............................................................................70
5.2 Uplink Transmission Scheme............................................................................................................................
5.2.1 Basic transmission scheme...........................................................................................................................70
5.2.1a Basic transmission scheme for NB-IoT.......................................................................................................70
5.2.3 Physical uplink control channel...................................................................................................................71
5.2.3a Uplink control information for NB-IoT.......................................................................................................72
5.2.4 Uplink Reference signal...............................................................................................................................72
5.2.4a Uplink Reference signal for NB-IoT...........................................................................................................72
5.2.5 Random access preamble.............................................................................................................................73
5.2.5a Random access preamble for NB-IoT..........................................................................................................73
5.2.6 Uplink multi-antenna transmission..............................................................................................................73
5.2.7 Physical channel procedure..........................................................................................................................73
5.2.7.1 Link adaptation.......................................................................................................................................73
5.2.7.2 Uplink Power control.............................................................................................................................73
5.2.7.3 Uplink timing control.............................................................................................................................74
5.2.8 Coordinated Multi-Point reception..............................................................................................................74
5.3 Transport Channels............................................................................................................................................
5.3.0 Transport channel types...............................................................................................................................74
5.3.1 Mapping between transport channels and physical channels.......................................................................75
5.3.1a Mapping between transport channels and narrowband physical channels..................................................76
5.4 E-UTRA physical layer model...........................................................................................................................
5.4.1 Void..............................................................................................................................................................77
5.4.2 Void..............................................................................................................................................................77
5.5 Carrier Aggregation...........................................................................................................................................
5.5.0 General.........................................................................................................................................................77
5.5.1 SRS switching between component carriers................................................................................................78
3GPP
Release 17 6 3GPP TS 36.300 V17.2.0 (2022-09)
5.5a Multi-carrier operation for NB-IoT...................................................................................................................

5.6 Sidelink..............................................................................................................................................................
5.6.0 General.........................................................................................................................................................79
5.6.1 Basic transmission scheme...........................................................................................................................79
5.6.3 Physical Sidelink control channel................................................................................................................79
5.6.4 Sidelink reference signals............................................................................................................................79
5.6.5 Physical channel procedure..........................................................................................................................79
5.6.5.1 Sidelink power control...........................................................................................................................79
5.6.6 Physical layer measurements definition.......................................................................................................79
5.7 Licensed-Assisted Access..................................................................................................................................
5.7.0 General.........................................................................................................................................................80
5.7.1 Channel Access Priority Classes..................................................................................................................80
5.7.2 Multiplexing of data.....................................................................................................................................81
5.8 Short Processing Time.......................................................................................................................................
5.9 Short Transmission Time Interval.....................................................................................................................
6 Layer 2.................................................................................................................................................
6.0 Overview...........................................................................................................................................................
6.1 MAC Sublayer...................................................................................................................................................
6.1.0 General.........................................................................................................................................................83
6.1.1 Services and Functions.................................................................................................................................83
6.1.2 Logical Channels..........................................................................................................................................84
6.1.2.0 General...................................................................................................................................................84
6.1.2.1 Control Channels....................................................................................................................................84
6.1.2.2 Traffic Channels.....................................................................................................................................85
6.1.3 Mapping between logical channels and transport channels.........................................................................85
6.1.3.1 Mapping in Uplink.................................................................................................................................85
6.1.3.2 Mapping in Downlink............................................................................................................................85
6.1.3.3 Mapping in Sidelink...............................................................................................................................86
6.2 RLC Sublayer....................................................................................................................................................
6.2.0 General.........................................................................................................................................................87
6.2.2 PDU Structure..............................................................................................................................................87
6.3 PDCP Sublayer..................................................................................................................................................
6.3.0 General.........................................................................................................................................................88
6.3.2 PDU Structure..............................................................................................................................................89
6.4 Carrier Aggregation...........................................................................................................................................
6.5 Dual Connectivity..............................................................................................................................................
7 RRC......................................................................................................................................................
7.0 General...............................................................................................................................................................
7.1 Services and Functions......................................................................................................................................
7.2 RRC protocol states & state transitions.............................................................................................................
7.3 Transport of NAS messages..............................................................................................................................
7.3a CIoT signalling reduction optimisations...........................................................................................................
7.3a.1 General.........................................................................................................................................................94
7.3a.2 Control Plane CIoT EPS/5GS optimisation.................................................................................................94
7.3a.3 User Plane CIoT EPS/5GS optimisations....................................................................................................95
7.3b MO-EDT..........................................................................................................................................................
7.3b.1 General.......................................................................................................................................................100
7.3b.2 MO-EDT for Control Plane CIoT EPS/5GS optimisations.......................................................................100
7.3b.3 MO-EDT for User Plane CIoT EPS/5GS optimisations............................................................................102
7.3c MT-EDT..........................................................................................................................................................
7.3c.1 General.......................................................................................................................................................107
7.3c.2 MT-EDT for Control Plane CIoT EPS Optimisation.................................................................................107
7.3c.3 MT-EDT for User Plane CIoT EPS Optimisation.....................................................................................108
7.3d Transmission using PUR.................................................................................................................................
7.3d.1 General.......................................................................................................................................................108
7.3d.2 PUR Configuration Request and PUR configuration................................................................................109
7.3d.3 Transmission using PUR for Control Plane CIoT EPS/5GS Optimisations..............................................109
3GPP
Release 17 7 3GPP TS 36.300 V17.2.0 (2022-09)
7.3d.4 Transmission using PUR for User Plane CIoT EPS/5GS Optimisations...................................................110
7.4 System Information.........................................................................................................................................
7.5 Carrier Aggregation.........................................................................................................................................
7.6 Dual Connectivity............................................................................................................................................
7.7 Segmentation of RRC messages......................................................................................................................
8 E-UTRAN identities...........................................................................................................................
8.1 E-UTRA related UE identities.........................................................................................................................
8.2 Network entity related Identities.....................................................................................................................
8.3 Sidelink communication and V2X Sidelink Communication related identities..............................................
8.4 MBMS related identities..................................................................................................................................
9 ARQ and HARQ.................................................................................................................................
9.0 General.............................................................................................................................................................
9.1 HARQ principles.............................................................................................................................................
9.2 ARQ principles................................................................................................................................................
9.3 Void.................................................................................................................................................................
10 Mobility..............................................................................................................................................
10.0 General.............................................................................................................................................................
10.1 Intra E-UTRAN...............................................................................................................................................
10.1.0 General.......................................................................................................................................................121
10.1.1 Mobility Management in ECM-IDLE........................................................................................................122
10.1.1.1 Cell selection........................................................................................................................................122
10.1.1.2 Cell reselection.....................................................................................................................................122
10.1.1.3 Void......................................................................................................................................................123
10.1.1.4 Void......................................................................................................................................................123
10.1.1.5 Void......................................................................................................................................................123
10.1.2 Mobility Management in ECM-CONNECTED/CM-CONNECTED........................................................123
10.1.2.0 General.................................................................................................................................................123
10.1.2.1 Handover..............................................................................................................................................124
10.1.2.1.0 General............................................................................................................................................124
10.1.2.1.1 C-plane handling.............................................................................................................................125
10.1.2.1.2 U-plane handling............................................................................................................................129
10.1.2.1a Conditional Handover..........................................................................................................................131
10.1.2.1a.1 General............................................................................................................................................131
10.1.2.1a.2 C-plane handling.............................................................................................................................132
10.1.2.1a.3 U-plane handling............................................................................................................................133
10.1.2.1a.4 Data Forwarding.............................................................................................................................133
10.1.2.2 Path Switch...........................................................................................................................................133
10.1.2.2.1 Path Switch upon handover............................................................................................................133
10.1.2.2.2 Path Update upon Dual Connectivity specific activities................................................................134
10.1.2.2.3 Path Switch upon UE context resume............................................................................................134
10.1.2.3 Data forwarding....................................................................................................................................134
10.1.2.3.1 For RLC-AM DRBs.......................................................................................................................134
10.1.2.3.2 For RLC-UM DRBs.......................................................................................................................135
10.1.2.3.3 SRB handling..................................................................................................................................135
10.1.2.3.4 User data forwarding for Dual Connectivity..................................................................................135
10.1.2.3.5 For DRBs configured with DAPS Handover.................................................................................135
10.1.2.4 Void......................................................................................................................................................136
10.1.2.5 Void......................................................................................................................................................136
10.1.2.6 Void......................................................................................................................................................136
10.1.2.7 Timing Advance...................................................................................................................................136
10.1.2.8 Dual Connectivity operation................................................................................................................137
10.1.2.8.1 SeNB Addition...............................................................................................................................137
10.1.2.8.2 SeNB Modification.........................................................................................................................138
10.1.2.8.2.1 Intra-MeNB handover involving SCG change.........................................................................140
10.1.2.8.3 SeNB Release.................................................................................................................................141
10.1.2.8.4 Change of SeNB.............................................................................................................................143
10.1.2.8.5 MeNB to eNB Change....................................................................................................................144
10.1.2.8.6 SCG change....................................................................................................................................145
10.1.2.8.7 eNB to MeNB change.....................................................................................................................145
10.1.2.8.8 Inter-MeNB handover without SeNB change................................................................................146
3GPP
Release 17 8 3GPP TS 36.300 V17.2.0 (2022-09)
10.1.2.8.9 Addition of a hybrid HeNB as the SeNB.......................................................................................149

10.1.2.9 LWA mobility......................................................................................................................................150
10.1.2.9.1 Inter-eNB handover without WT change.......................................................................................150
10.1.2.10 EN-DC Operation.................................................................................................................................151
10.1.3 Measurements............................................................................................................................................152
10.1.3.0 General.................................................................................................................................................152
10.1.3.1 Intra-frequency neighbour (cell) measurements...................................................................................154
10.1.3.2 Inter-frequency neighbour (cell) measurements...................................................................................154
10.1.4 Paging and C-plane establishment.............................................................................................................155
10.1.5 Random Access Procedure.........................................................................................................................157
10.1.5.0 General.................................................................................................................................................157
10.1.5.1 Contention based random access procedure.........................................................................................158
10.1.5.2 Non-contention based random access procedure.................................................................................160
10.1.5.3 Interaction model between L1 and L2/3 for Random Access Procedure.............................................161
10.1.6 Radio Link Failure.....................................................................................................................................161
10.1.7 Radio Access Network Sharing.................................................................................................................163
10.1.8 Handling of Roaming and Area Restrictions for UEs in ECM-CONNECTED........................................164
10.1.8a Handling of Roaming and Access Restrictions for UEs in ECM-CONNECTED.....................................164
10.1.9 Mobility in RRC_INACTIVE....................................................................................................................164
10.1.9.1 Overview..............................................................................................................................................164
10.1.9.2 Cell Reselection....................................................................................................................................164
10.1.9.3 RAN-Based Notification Area.............................................................................................................164
10.1.9.4 State Transitions...................................................................................................................................164
10.1.9.4.1 UE triggered transition from RRC_INACTIVE to RRC_CONNECTED.....................................164
10.1.9.4.2 Network triggered transition from RRC_INACTIVE to RRC_CONNECTED.............................164
10.1.9.5 RNA update..........................................................................................................................................164
10.2 Inter RAT.........................................................................................................................................................
10.2.0 General.......................................................................................................................................................165
10.2.1 Cell reselection...........................................................................................................................................165
10.2.2 Handover....................................................................................................................................................166
10.2.2a Inter-RAT cell change order to GERAN with NACC...............................................................................166
10.2.2b Inter-RAT handovers from E-UTRAN......................................................................................................166
10.2.2b.1 Data forwarding....................................................................................................................................166
10.2.2b.1.1 For RLC-AM bearers......................................................................................................................166
10.2.2b.1.2 For RLC-UM bearers......................................................................................................................167
10.2.2c Intra-EUTRA inter-system Handover........................................................................................................167
10.2.3 Measurements............................................................................................................................................167
10.2.3.1 Inter-RAT handovers from E-UTRAN................................................................................................167
10.2.3.2 Inter-RAT handovers to E-UTRAN.....................................................................................................167
10.2.3.3 Inter-RAT cell reselection from E-UTRAN.........................................................................................168
10.2.3.4 Limiting measurement load at UE........................................................................................................168
10.2.3.5 Inter-RAT measurements in RRC_IDLE or RRC_INACTIVE...........................................................168
10.2.4 Network Aspects........................................................................................................................................168
10.2.5 CS fallback.................................................................................................................................................168
10.2.6 Idle mode Inter-RAT Cell Selection to/from NB-IoT...............................................................................169
10.3 Mobility between E-UTRAN and Non-3GPP radio technologies...................................................................
10.3.1 UE Capability Configuration.....................................................................................................................169
10.3.2 Mobility between E-UTRAN and cdma2000 network..............................................................................169
10.3.2.1 Tunnelling of cdma2000 Messages over E-UTRAN between UE and cdma2000 Access Nodes......170
10.3.2.2 Mobility between E-UTRAN and HRPD.............................................................................................170
10.3.2.2.1 Mobility from E-UTRAN to HRPD...............................................................................................170
10.3.2.2.1.1 HRPD System Information Transmission in E-UTRAN..........................................................170
10.3.2.2.1.2 Measuring HRPD from E-UTRAN..........................................................................................171
10.3.2.2.1.2.1 Idle Mode Measurement Control........................................................................................171
10.3.2.2.1.2.2 Active Mode Measurement Control....................................................................................171
10.3.2.2.1.2.3 Active Mode Measurement.................................................................................................171
10.3.2.2.1.3 Pre-registration to HRPD Procedure.........................................................................................171
10.3.2.2.1.4 E-UTRAN to HRPD Cell Re-selection.....................................................................................171
10.3.2.2.1.5 E-UTRAN to HRPD Handover................................................................................................172
10.3.2.2.2 Mobility from HRPD to E-UTRAN...............................................................................................172
10.3.2.3 Mobility between E-UTRAN and cdma2000 1xRTT..........................................................................172
3GPP
Release 17 9 3GPP TS 36.300 V17.2.0 (2022-09)
10.3.2.3.1 Mobility from E-UTRAN to cdma2000 1xRTT.............................................................................172

10.3.2.3.1.1 cdma2000 1xRTT System Information Transmission in E-UTRAN.......................................172
10.3.2.3.1.2 Measuring cdma2000 1xRTT from E-UTRAN........................................................................172
10.3.2.3.1.2.1 Idle Mode Measurement Control..............................................................................................172
10.3.2.3.1.2.2 Active Mode Measurement Control..........................................................................................172
10.3.2.3.1.2.3 Active Mode Measurement.......................................................................................................173
10.3.2.3.1.3 E-UTRAN to cdma2000 1xRTT Cell Re-selection..................................................................173
10.3.2.3.1.4 E-UTRAN to cdma2000 1xRTT Handover..............................................................................173
10.3.2.3.2 Mobility from cdma2000 1xRTT to E-UTRAN.............................................................................173
10.3.2.3.3 1xRTT CS Fallback........................................................................................................................173
10.3.3 CDMA2000 interworking in LTE shared networks..................................................................................175
10.4 Area Restrictions.............................................................................................................................................
10.4a Roaming and Access Restrictions....................................................................................................................
10.5 Mobility to and from CSG and Hybrid cells...................................................................................................
10.5.0 Principles for idle-mode mobility with CSG cells.....................................................................................176
10.5.0.1 Intra-frequency mobility......................................................................................................................176
10.5.0.2 Inter-frequency mobility......................................................................................................................176
10.5.0.3 Inter-RAT Mobility..............................................................................................................................176
10.5.1 Inbound mobility to CSG cells...................................................................................................................177
10.5.1.1 RRC_IDLE...........................................................................................................................................177
10.5.1.2 RRC_CONNECTED............................................................................................................................177
10.5.2 Outbound mobility from CSG cells...........................................................................................................179
10.5.2.1 RRC_IDLE...........................................................................................................................................179
10.5.2.2 RRC_CONNECTED............................................................................................................................180
10.6 Measurement Model........................................................................................................................................
10.7 Hybrid Cells.....................................................................................................................................................
10.7.0 General.......................................................................................................................................................180
10.7.1 RRC_IDLE................................................................................................................................................180
10.7.2 RRC_CONNECTED.................................................................................................................................181
10.7.2.1 Inbound Mobility..................................................................................................................................181
10.7.2.2 Outbound Mobility...............................................................................................................................181
11 Scheduling and Rate Control..............................................................................................................
11.0 General.............................................................................................................................................................
11.1 Basic Scheduler Operation..............................................................................................................................
11.1.1 Downlink Scheduling.................................................................................................................................182
11.1.2 Uplink Scheduling......................................................................................................................................183
11.2 Activation/Deactivation Mechanism...............................................................................................................
11.3 Measurements to Support Scheduler Operation..............................................................................................
11.4 Rate Control of GBR, MBR and UE-AMBR..................................................................................................
11.4.1 Downlink....................................................................................................................................................185
11.4.2 Uplink........................................................................................................................................................185
11.4.3 UE-AMBR for Dual Connectivity.............................................................................................................185
11.5 CQI reporting for Scheduling..........................................................................................................................
11.6 Explicit Congestion Notification.....................................................................................................................
11.7 DL channel quality reporting...........................................................................................................................
12 DRX in RRC_CONNECTED.............................................................................................................
13 QoS.....................................................................................................................................................
13.0 General.............................................................................................................................................................
13.1 Bearer service architecture..............................................................................................................................
13.2 QoS parameters................................................................................................................................................
13.3 QoS support in Hybrid Cells...........................................................................................................................
14 Security...............................................................................................................................................
14.1 Overview and Principles..................................................................................................................................
14.2 Security termination points..............................................................................................................................
14.3 State Transitions and Mobility.........................................................................................................................
14.3.1 RRC_IDLE to RRC_CONNECTED.........................................................................................................194
14.3.2 RRC_CONNECTED to RRC_IDLE.........................................................................................................194
14.3.3 Intra E-UTRAN Mobility...........................................................................................................................194
14.3.4 SeNB Removal...........................................................................................................................................194
3GPP
Release 17 10 3GPP TS 36.300 V17.2.0 (2022-09)
14.4 AS Key Change in RRC_CONNECTED........................................................................................................

14.5 Security Interworking......................................................................................................................................
14.6 RN integrity protection for DRB(s).................................................................................................................
15 MBMS................................................................................................................................................
15.0 MBMS-Specific Definitions............................................................................................................................
15.1 General.............................................................................................................................................................
15.1.0 Overview....................................................................................................................................................196
15.1.1 E-MBMS Logical Architecture..................................................................................................................197
15.1.2 E-MBMS User Plane Protocol Architecture..............................................................................................199
15.1.3 E-MBMS Control Plane Protocol Architecture.........................................................................................199
15.2 MBMS Cells....................................................................................................................................................
15.2.1 MBMS-dedicated cell................................................................................................................................200
15.2.2 MBMS/Unicast-mixed cell........................................................................................................................200
15.2.2.1 FeMBMS/Unicast-mixed cell....................................................................................................................200
15.3 MBMS Transmission.......................................................................................................................................
15.3.1 General.......................................................................................................................................................200
15.3.2 Single-cell transmission.............................................................................................................................200
15.3.3 Multi-cell transmission..............................................................................................................................201
15.3.4 MBMS Reception States............................................................................................................................203
15.3.5 MCCH Structure........................................................................................................................................203
15.3.5a SC-MCCH structure...................................................................................................................................203
15.3.6 MBMS signalling on BCCH......................................................................................................................204
15.3.7 MBMS User Data flow synchronisation....................................................................................................204
15.3.8 Synchronisation of MCCH Update Signalling via M2..............................................................................205
15.3.9 IP Multicast Distribution............................................................................................................................206
15.4 Service Continuity...........................................................................................................................................
15.5 Network sharing..............................................................................................................................................
15.6 Network Functions for Support of Multiplexing.............................................................................................
15.7 Procedures.......................................................................................................................................................
15.7.1 Procedures for Broadcast mode.................................................................................................................209
15.7.1.1 Session Start procedure........................................................................................................................209
15.7.1.2 Session Stop procedure........................................................................................................................210
15.7a M1 Interface....................................................................................................................................................
15.7a.1 M1 User Plane............................................................................................................................................211
15.8 M2 Interface....................................................................................................................................................
15.8.1 M2 Control Plane.......................................................................................................................................211
15.8.2 M2 Interface Functions..............................................................................................................................212
15.8.2.1 General.................................................................................................................................................212
15.8.2.2 MBMS Session Handling Function......................................................................................................212
15.8.2.3 MBMS Scheduling Information Provision Function...........................................................................212
15.8.2.4 M2 Interface Management Function....................................................................................................212
15.8.2.5 M2 Configuration Function..................................................................................................................213
15.8.2.6 MBMS Service Counting Function......................................................................................................213
15.8.2.7 MBMS Service Suspension and Resumption Function.......................................................................213
15.8.2.8 MBMS Overload Notification Function..............................................................................................213
15.8.3 M2 Interface Signalling Procedures...........................................................................................................213
15.8.3.1 General.................................................................................................................................................213
15.8.3.2 MBMS Session signalling procedure...................................................................................................213
15.8.3.3 MBMS Scheduling Information procedure..........................................................................................213
15.8.3.4 M2 Interface Management procedures.................................................................................................213
15.8.3.4.1 Reset procedure..............................................................................................................................213
15.8.3.4.2 Error Indication procedure..............................................................................................................214
15.8.3.5 M2 Configuration procedures..............................................................................................................214
15.8.3.5.1 M2 Setup procedure........................................................................................................................214
15.8.3.5.2 eNB Configuration Update procedure............................................................................................214
15.8.3.5.3 MCE Configuration Update procedure...........................................................................................214
15.8.3.6 MBMS Service Counting procedures..................................................................................................214
15.8.3.6.1 MBMS Service Counting procedure..............................................................................................214
15.8.3.6.2 MBMS Service Counting Results Report procedure......................................................................214
15.8.3.7 MBMS Overload Notification procedure.............................................................................................214
15.9 M3 Interface....................................................................................................................................................
3GPP
Release 17 11 3GPP TS 36.300 V17.2.0 (2022-09)
15.9.1 M3 Control Plane.......................................................................................................................................214

15.9.2 M3 Interface Functions..............................................................................................................................215
15.9.2.1 General.................................................................................................................................................215
15.9.2.2 MBMS Session Handling Function......................................................................................................215
15.9.2.3 M3 Interface Management Function....................................................................................................215
15.9.2.4 M3 Configuration Function..................................................................................................................216
15.9.3 M3 Interface Signalling Procedures...........................................................................................................216
15.9.3.1 General.................................................................................................................................................216
15.9.3.2 MBMS Session signalling procedure...................................................................................................216
15.9.3.3 M3 Interface Management procedures.................................................................................................216
15.9.3.3.1 Reset procedure..............................................................................................................................216
15.9.3.3.2 Error Indication procedure..............................................................................................................216
15.9.3.4 M3 Configuration procedures..............................................................................................................216
15.9.3.4.1 M3 Setup procedure........................................................................................................................216
15.9.3.4.2 MCE Configuration Update procedure...........................................................................................216
15.10 MBMS Counting.............................................................................................................................................
15.10.1 General.......................................................................................................................................................216
15.10.2 Counting Procedure....................................................................................................................................217
15.11 MBMS service reception using Receive Only Mode......................................................................................
16 Radio Resource Management aspects.................................................................................................
16.0 General.............................................................................................................................................................
16.1 RRM functions................................................................................................................................................
16.1.1 Radio Bearer Control (RBC)......................................................................................................................217
16.1.2 Radio Admission Control (RAC)...............................................................................................................218
16.1.3 Connection Mobility Control (CMC)........................................................................................................218
16.1.4 Dynamic Resource Allocation (DRA) - Packet Scheduling (PS)..............................................................218
16.1.5 Inter-cell Interference Coordination (ICIC)...............................................................................................218
16.1.5.0 General.................................................................................................................................................218
16.1.5.1 UE configurations for time domain ICIC.............................................................................................219
16.1.5.2 OAM requirements for time domain ICIC...........................................................................................219
16.1.5.2.1 Configuration for CSG cell.............................................................................................................219
16.1.5.2.2 Configuration for interfering non-CSG cell...................................................................................219
16.1.6 Load Balancing (LB).................................................................................................................................220
16.1.7 Inter-RAT Radio Resource Management..................................................................................................220
16.1.8 Subscriber Profile ID for RAT/Frequency Priority....................................................................................220
16.1.9 Inter-eNB CoMP........................................................................................................................................220
16.1.10 Cell on/off and cell discovery....................................................................................................................220
16.1.11 Resource reservation..................................................................................................................................221
16.2 RRM architecture............................................................................................................................................
16.2.1 Centralised Handling of certain RRM Functions.......................................................................................221
16.2.2 De-Centralised RRM..................................................................................................................................221
16.2.2.1 UE History Information.......................................................................................................................221
16.2.3 Void............................................................................................................................................................221
16.3 UE assistance information for RRM, and UE power optimisations and UE overheating...............................
17 Void....................................................................................................................................................
17.1 Void.................................................................................................................................................................
18 UE capabilities....................................................................................................................................
19 S1 Interface.........................................................................................................................................
19.1 S1 User plane...................................................................................................................................................
19.2 S1 Control Plane..............................................................................................................................................
19.2.0 General.......................................................................................................................................................225
19.2.1 S1 Interface Functions...............................................................................................................................226
19.2.1.0 General.................................................................................................................................................226
19.2.1.1 S1 Paging function...............................................................................................................................227
19.2.1.2 S1 UE Context Management function.................................................................................................227
19.2.1.3 Initial Context Setup Function.............................................................................................................227
19.2.1.3a UE Context Modification Function......................................................................................................227
19.2.1.3b UE Context Resume Function..............................................................................................................227
19.2.1.4 Mobility Functions for UEs in ECM-CONNECTED..........................................................................227
3GPP
Release 17 12 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.1.4.1 Intra-LTE Handover.......................................................................................................................227

19.2.1.4.2 Inter-3GPP-RAT Handover............................................................................................................227
19.2.1.5 E-RAB Service Management function.................................................................................................227
19.2.1.6 NAS Signalling Transport function......................................................................................................227
19.2.1.7 NAS Node Selection Function (NNSF)...............................................................................................228
19.2.1.8 S1-interface management functions.....................................................................................................228
19.2.1.9 MME Load balancing Function...........................................................................................................228
19.2.1.10 Location Reporting Function...............................................................................................................228
19.2.1.11 Warning Message Transmission function.............................................................................................228
19.2.1.12 Overload Function................................................................................................................................228
19.2.1.13 RAN Information Management Function............................................................................................229
19.2.1.14 S1 CDMA2000 Tunnelling function....................................................................................................229
19.2.1.15 Configuration Transfer Function..........................................................................................................229
19.2.1.16 LPPa Signalling Transport function.....................................................................................................229
19.2.1.17 Trace Function......................................................................................................................................229
19.2.1.18 UE Radio Capability Match.................................................................................................................229
19.2.1.19 Retrieve UE Information Function.......................................................................................................229
19.2.1.20 UE Information Transfer Function.......................................................................................................229
19.2.1.21 Report of Secondary RAT data volumes Function..............................................................................229
19.2.1.22 UE Radio Capability ID Mapping Function........................................................................................229
19.2.2 S1 Interface Signalling Procedures............................................................................................................229
19.2.2.0 General.................................................................................................................................................230
19.2.2.1 Paging procedure..................................................................................................................................230
19.2.2.2 S1 UE Context Release procedure.......................................................................................................230
19.2.2.2.0 General............................................................................................................................................230
19.2.2.2.1 S1 UE Context Release (EPC triggered)........................................................................................230
19.2.2.2.2 S1 UE Context Release Request (eNB triggered)..........................................................................230
19.2.2.3 Initial Context Setup procedure............................................................................................................231
19.2.2.3a UE Context Modification procedure....................................................................................................232
19.2.2.4 E-RAB signalling procedures...............................................................................................................233
19.2.2.4.1 E-RAB Setup procedure.................................................................................................................233
19.2.2.4.2 E-RAB Modification procedure.....................................................................................................234
19.2.2.4.3 E-RAB Release procedure..............................................................................................................235
19.2.2.4.4 E-RAB Release Indication procedure.............................................................................................235
19.2.2.4.5 E-RAB Modification Indication procedure....................................................................................236
19.2.2.5 Handover signalling procedures...........................................................................................................236
19.2.2.5.0 General............................................................................................................................................236
19.2.2.5.1 Handover Preparation procedure....................................................................................................236
19.2.2.5.2 Handover Resource Allocation procedure......................................................................................237
19.2.2.5.3 Handover Notification procedure...................................................................................................238
19.2.2.5.4 Handover Cancellation...................................................................................................................238
19.2.2.5.5 Path Switch procedure....................................................................................................................238
19.2.2.5.6 Message sequence diagrams...........................................................................................................239
19.2.2.5.7 eNB Status Transfer procedure.......................................................................................................247
19.2.2.5.8 MME Status Transfer procedure....................................................................................................248
19.2.2.6 NAS transport procedures....................................................................................................................248
19.2.2.7 S1 interface Management procedures..................................................................................................251
19.2.2.7.1 Reset procedure..............................................................................................................................251
19.2.2.7.1a eNB initiated Reset procedure........................................................................................................251
19.2.2.7.1b MME initiated Reset procedure......................................................................................................252
19.2.2.7.2 Error Indication functions and procedures.....................................................................................252
19.2.2.7.2a eNB initiated error indication.........................................................................................................252
19.2.2.7.2b MME initiated error indication.......................................................................................................252
19.2.2.8 S1 Setup procedure...............................................................................................................................252
19.2.2.9 eNB Configuration Update procedure..................................................................................................253
19.2.2.9a eNB Configuration Transfer procedure................................................................................................254
19.2.2.10 MME Configuration Update procedure...............................................................................................254
19.2.2.10a MME Configuration Transfer procedure.............................................................................................255
19.2.2.11 Location Reporting procedures............................................................................................................255
19.2.2.11.0 General............................................................................................................................................255
19.2.2.11.1 Location Reporting Control procedure...........................................................................................256
3GPP
Release 17 13 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.11.2 Location Report procedure.............................................................................................................256

19.2.2.11.3 Location Report Failure Indication procedure................................................................................256
19.2.2.12 Overload procedure..............................................................................................................................257
19.2.2.12.1 Overload Start procedure................................................................................................................257
19.2.2.12.2 Overload Stop procedure................................................................................................................257
19.2.2.13 Write-Replace Warning procedure.......................................................................................................258
19.2.2.14 eNB Direct Information Transfer procedure........................................................................................258
19.2.2.15 MME Direct Information Transfer procedure......................................................................................259
19.2.2.16 S1 CDMA2000 Tunnelling procedures................................................................................................259
19.2.2.16.1 Downlink S1 CDMA2000 Tunnelling procedure..........................................................................259
19.2.2.16.2 Uplink S1 CDMA2000 Tunnelling procedure...............................................................................259
19.2.2.17 Kill procedure.......................................................................................................................................260
19.2.2.18 LPPa Transport procedures..................................................................................................................260
19.2.2.18.0 General............................................................................................................................................260
19.2.2.18.1 Downlink UE Associated LPPa Transport procedure....................................................................261
19.2.2.18.2 Uplink UE Associated LPPa Transport procedure.........................................................................261
19.2.2.18.3 Downlink Non UE Associated LPPa Transport procedure............................................................261
19.2.2.18.4 Uplink Non UE Associated LPPa Transport procedure.................................................................262
19.2.2.19 Trace procedures..................................................................................................................................262
19.2.2.19.0 General............................................................................................................................................262
19.2.2.19.1 Trace Start procedure......................................................................................................................262
19.2.2.19.2 Trace Failure Indication procedure.................................................................................................263
19.2.2.19.3 Deactivate Trace procedure............................................................................................................263
19.2.2.19.4 Cell Traffic Trace procedure..........................................................................................................263
19.2.2.20 UE Capability Info Indication procedure.............................................................................................263
19.2.2.21 UE Radio Capability Match procedure................................................................................................264
19.2.2.22 PWS Restart Indication procedure.......................................................................................................264
19.2.2.23 PWS Failure Indication procedure.......................................................................................................265
19.2.2.24 UE Context Modification Indication procedure...................................................................................265
19.2.2.25 Connection Establishment Indication procedure..................................................................................265
19.2.2.26 UE Context Suspend procedure...........................................................................................................266
19.2.2.27 UE Context Resume procedure............................................................................................................267
19.2.2.28 Retrieve UE Information procedure.....................................................................................................267
19.2.2.29 UE Information Transfer procedure.....................................................................................................267
19.2.2.30 eNB CP Relocation Indication.............................................................................................................268
19.2.2.31 MME CP Relocation Indication...........................................................................................................268
19.2.2.32 Secondary RAT Report........................................................................................................................269
19.2.2.33 UE Radio Capability ID Mapping procedure.......................................................................................269
20 X2 Interface........................................................................................................................................
20.1 User Plane........................................................................................................................................................
20.1.1 Flow Control Functions.............................................................................................................................270
20.2 Control Plane...................................................................................................................................................
20.2.0 X2-CP Overview........................................................................................................................................270
20.2.1 X2-CP Functions........................................................................................................................................271
20.2.2 X2-CP Procedures......................................................................................................................................272
20.2.2.0 Overview of X2-CP procedures...........................................................................................................272
20.2.2.1 Handover Preparation procedure..........................................................................................................272
20.2.2.2 Handover Cancel procedure.................................................................................................................272
20.2.2.2a SeNB Addition Preparation procedure.................................................................................................273
20.2.2.2b SeNB Reconfiguration Completion procedure....................................................................................273
20.2.2.2c MeNB initiated SeNB Modification Preparation procedure................................................................273
20.2.2.2d SeNB initiated SeNB Modification procedure.....................................................................................274
20.2.2.2e MeNB initiated SeNB Release procedure............................................................................................274
20.2.2.2f SeNB initiated SeNB Release procedure.............................................................................................275
20.2.2.2g SeNB Counter Check procedure..........................................................................................................275
20.2.2.3 UE Context Release procedure............................................................................................................275
20.2.2.4 SN Status Transfer procedure..............................................................................................................276
20.2.2.5 Error Indication procedure...................................................................................................................277
20.2.2.6 Load Indication procedure...................................................................................................................278
20.2.2.7 X2 Setup procedure..............................................................................................................................279
20.2.2.8 eNB Configuration Update procedure..................................................................................................279
3GPP
Release 17 14 3GPP TS 36.300 V17.2.0 (2022-09)
20.2.2.9 Reset procedure....................................................................................................................................280

20.2.2.10 Resource Status Reporting Initiation procedure...................................................................................280
20.2.2.11 Resource Status Reporting procedure..................................................................................................281
20.2.2.12 Radio Link Failure Indication procedure.............................................................................................281
20.2.2.13 Handover Report procedure.................................................................................................................282
20.2.2.14 Mobility Settings Change procedure....................................................................................................282
20.2.2.15 Cell Activation procedure....................................................................................................................282
20.2.2.16 X2 Release procedure...........................................................................................................................283
20.2.2.17 X2AP Message Transfer procedure.....................................................................................................283
20.2.2.18 X2 Removal procedure.........................................................................................................................283
20.2.2.19 Retrieve UE Context............................................................................................................................284
20.2.2.20 SgNB Addition Preparation procedure................................................................................................286
20.2.2.21 SgNB Reconfiguration Completion procedure....................................................................................286
20.2.2.22 MeNB initiated SgNB Modification Preparation procedure................................................................286
20.2.2.23 SgNB initiated SgNB Modification Preparation procedure.................................................................287
20.2.2.24 MeNB initiated SgNB Release procedure............................................................................................287
20.2.2.25 SgNB initiated SgNB Release procedure.............................................................................................288
20.2.2.26 SgNB initiated SgNB Change procedure.............................................................................................288
20.2.2.27 SgNB Counter Check procedure..........................................................................................................288
20.2.2.28 EN-DC X2 Setup procedure.................................................................................................................289
20.2.2.29 EN-DC Configuration Update procedure.............................................................................................289
20.2.2.31 E-UTRA - NR Cell Resource Coordination procedure........................................................................290
20.2.2.32 Partial Reset procedure for EN-DC......................................................................................................291
20.2.3 Void............................................................................................................................................................292
21 Void....................................................................................................................................................
21.1 Void.................................................................................................................................................................
21.2 Void.................................................................................................................................................................
21.3 Void.................................................................................................................................................................
22 Support for self-configuration and self-optimisation..........................................................................
22.1 Definitions.......................................................................................................................................................
22.2 UE Support for self-configuration and self-optimisation................................................................................
22.3 Self-configuration............................................................................................................................................
22.3.1 Dynamic configuration of the S1-MME interface.....................................................................................293
22.3.1.1 Prerequisites.........................................................................................................................................293
22.3.1.2 SCTP initialization...............................................................................................................................294
22.3.1.3 Application layer initialization.............................................................................................................294
22.3.2 Dynamic Configuration of the X2 interface..............................................................................................294
22.3.2.1 Prerequisites.........................................................................................................................................294
22.3.2a Automatic Neighbour Relation Function...................................................................................................295
22.3.3 Intra-LTE/frequency Automatic Neighbour Relation Function.................................................................296
22.3.4 Inter-RAT/Inter-frequency Automatic Neighbour Relation Function........................................................297
22.3.4a Automatic Neighbour Relation Function towards NR...............................................................................298
22.3.4b Automatic Neighbour Relation Function in NB-IoT.................................................................................298
22.3.5 Framework for PCI Selection....................................................................................................................300
22.3.6 TNL address discovery..............................................................................................................................300
22.3.6.1 TNL address discovery of candidate eNB via S1 interface..................................................................300
22.3.6.2 TNL address discovery of a candidate en-gNB via the S1 interface....................................................300
22.3.6.3 TNL address discovery of a candidate en-gNB via inter-system signalling........................................301
22.3.7 Dynamic configuration of the Xw-C interface..........................................................................................301
22.3.7.1 Prerequisites.........................................................................................................................................301
22.4 Self-optimisation.............................................................................................................................................
22.4.1 Support for Mobility Load Balancing........................................................................................................301
22.4.1.1 General.................................................................................................................................................301
22.4.1.2 Load reporting......................................................................................................................................302
22.4.1.2.1 Load reporting for intra-LTE scenario...........................................................................................302
22.4.1.2.2 Load reporting for inter-RAT scenario...........................................................................................303
3GPP
Release 17 15 3GPP TS 36.300 V17.2.0 (2022-09)
22.4.1.2.3 Load reporting for EN-DC scenario...............................................................................................303

22.4.1.2.4 Load reporting for inter-system load balancing..............................................................................303
22.4.1.3 Load balancing action based on handovers..........................................................................................304
22.4.1.4 Adapting handover and/or reselection configuration...........................................................................304
22.4.2 Support for Mobility Robustness Optimisation.........................................................................................304
22.4.2.1 General.................................................................................................................................................304
22.4.2.2 Connection failure due to intra-LTE mobility......................................................................................304
22.4.2.2a Connection failure due to inter-RAT mobility.....................................................................................307
22.4.2.3 Unnecessary HO to another RAT.........................................................................................................308
22.4.2.4 O&M Requirements.............................................................................................................................309
22.4.2.5 Inter-RAT ping-pong............................................................................................................................309
22.4.2.6 Dynamic coverage configuration changes...........................................................................................310
22.4.2.7 Connection failure due to Radio Link Failure in NB-IoT....................................................................310
22.4.2.8 Inter-system Ping-Pong........................................................................................................................310
22.4.3 Support for RACH Optimisation...............................................................................................................311
22.4.3.1 General.................................................................................................................................................311
22.4.3.2 Solution description..............................................................................................................................311
22.4.3.2.1 E-UTRA cell case...........................................................................................................................311
22.4.3.2.2 NR cell in EN-DC case...................................................................................................................311
22.4.4 Support for Energy Saving.........................................................................................................................312
22.4.4.1 General.................................................................................................................................................312
22.4.4.2 Solution description..............................................................................................................................312
22.4.4.2.1 E-UTRA cell case...........................................................................................................................312
22.4.4.2.2 EN-DC cell case.............................................................................................................................312
22.4.4.3 O&M requirements..............................................................................................................................313
22.4.5 Radio Link Failure report...........................................................................................................................313
22.5 Void.................................................................................................................................................................
22.6 Void.................................................................................................................................................................
22A LTE-WLAN Aggregation and RAN Controlled LTE-WLAN Interworking......................................
22A.1 LTE-WLAN Aggregation................................................................................................................................
22A.1.1 General.......................................................................................................................................................313
22A.1.2 Radio Protocol Architecture.......................................................................................................................314
22A.1.3 Network Interfaces.....................................................................................................................................315
22A.1.3.1 General.................................................................................................................................................315
22A.1.3.2 User Plane............................................................................................................................................315
22A.1.3.3 Control Plane........................................................................................................................................316
22A.1.4 Mobility......................................................................................................................................................317
22A.1.5 WLAN Measurements...............................................................................................................................317
22A.1.6 Procedure for WLAN Connection Status Reporting..................................................................................317
22A.1.7 LTE-WLAN Aggregation Operation.........................................................................................................318
22A.1.7.1 WT Addition........................................................................................................................................318
22A.1.7.2 WT Modification..................................................................................................................................319
22A.1.7.3 WT Release..........................................................................................................................................320
22A.1.7.4 Change of WT......................................................................................................................................322
22A.1.8 WLAN Authentication...............................................................................................................................322
22A.2 RAN Controlled LTE WLAN Interworking...................................................................................................
22A.2.1 General.......................................................................................................................................................322
22A.2.2.1 General.................................................................................................................................................323
22A.2.2.2 User Plane Plane...................................................................................................................................323
22A.2.2.3 Control Plane........................................................................................................................................323
22A.2.3 Mobility......................................................................................................................................................323
22A.2.4 WLAN Measurements...............................................................................................................................323
22A.2.5 Procedure for WLAN Connection Status Reporting..................................................................................323
22A.2.6 Traffic Steering Operation.........................................................................................................................323
22A.2.6.1 Traffic Steering from E-UTRAN to WLAN........................................................................................323
22A.2.6.2 Traffic Steering from WLAN to E-UTRAN........................................................................................324
22A.3 LTE/WLAN Radio Level Integration with IPsec Tunnel................................................................................
22A.3.0 General.......................................................................................................................................................324
22A.3.1 LWIP Operation.........................................................................................................................................327
22A.3.1.1 LWIP Tunnel Setup and Data Bearer Configuration...........................................................................327
3GPP
Release 17 16 3GPP TS 36.300 V17.2.0 (2022-09)
22A.3.1.2 Reconfiguration to Remove WLAN Resources from Data Bearer......................................................328

22A.3.1.3 LWIP Tunnel Release..........................................................................................................................328
22A.3.2.1 General.................................................................................................................................................329
22A.3.2.2 User Plane............................................................................................................................................329
22A.3.2.3 Control Plane........................................................................................................................................329
22B Xw Interface.......................................................................................................................................
22B.1 User Plane........................................................................................................................................................
22B.2 Control Plane...................................................................................................................................................
22B.2.0 General.......................................................................................................................................................330
22B.2.1 Xw-CP Functions.......................................................................................................................................331
22B.2.2 Xw-CP Procedures.....................................................................................................................................331
22B.2.2.1 WT Addition Preparation procedure....................................................................................................331
22B.2.2.2 WT Association Confirmation procedure............................................................................................331
22B.2.2.3 eNB initiated WT Modification Preparation procedure.......................................................................332
22B.2.2.4 WT initiated WT Modification procedure............................................................................................332
22B.2.2.5 eNB initiated WT Release procedure...................................................................................................333
22B.2.2.6 WT initiated WT Release procedure....................................................................................................333
22B.2.2.7 WT Status Reporting Initiation............................................................................................................333
22B.2.2.8 WT Status Reporting............................................................................................................................334
22B.2.2.9 Xw Setup procedure.............................................................................................................................334
22B.2.2.10 WT Configuration Update procedure...................................................................................................335
22B.2.2.11 Error Indication procedure...................................................................................................................335
22B.2.2.11.0 General............................................................................................................................................335
22B.2.2.11.1 WT initiated error indication..........................................................................................................336
22B.2.2.11.2 eNB initiated error indication.........................................................................................................336
22B.2.2.12 Reset procedure....................................................................................................................................336
22B.2.2.12.0 General............................................................................................................................................336
22B.2.2.12.1 WT initiated reset...........................................................................................................................336
22B.2.2.12.2 eNB initiated reset..........................................................................................................................337
22B.2.2.13 LWIP Addition Preparation procedure................................................................................................337
22B.2.2.14 eNB initiated LWIP Modification Preparation procedure...................................................................337
22B.2.2.15 eNB initiated LWIP Release procedure...............................................................................................338
23 Others.................................................................................................................................................
23.1 Support for real time IMS services..................................................................................................................
23.1.1 IMS Emergency Call..................................................................................................................................339
23.2 Subscriber and equipment trace.......................................................................................................................
23.2.0 General.......................................................................................................................................................339
23.2.1 Signalling activation..................................................................................................................................339
23.2.2 Management activation..............................................................................................................................340
23.3 E-UTRAN Support for Warning Systems.......................................................................................................
23.3.0 General.......................................................................................................................................................340
23.3.1 Earthquake and Tsunami Warning System................................................................................................340
23.3.2 Commercial Mobile Alert System.............................................................................................................340
23.3.3 Korean Public Alert System.......................................................................................................................340
23.3.4 EU-Alert.....................................................................................................................................................340
23.4 Interference avoidance for in-device coexistence............................................................................................
23.4.1 Problems....................................................................................................................................................340
23.4.2 Solutions....................................................................................................................................................341
23.5 TDD Enhanced Interference Management and Traffic Adaptation (eIMTA).................................................
23.6 RAN assisted WLAN interworking.................................................................................................................
23.6.0 General.......................................................................................................................................................343
23.6.1 General principles......................................................................................................................................343
23.6.2 Access network selection and traffic steering rules...................................................................................344
23.7 Support of Low Complexity UEs....................................................................................................................
23.7a Support of Bandwidth Reduced Low Complexity UEs...................................................................................
23.7b Support of UEs in Enhanced Coverage...........................................................................................................
23.8 Support for Radio Interface based Synchronization........................................................................................
23.9 Network-assisted interference cancellation/suppression.................................................................................
23.10 Support for sidelink communication...............................................................................................................
3GPP
Release 17 17 3GPP TS 36.300 V17.2.0 (2022-09)
23.10.1 General.......................................................................................................................................................346
23.10.2 Radio Protocol Architecture.......................................................................................................................347
23.10.2.0 General.................................................................................................................................................347
23.10.2.1 User plane.............................................................................................................................................347
23.10.2.2 Control plane........................................................................................................................................347
23.10.3 Radio resource allocation...........................................................................................................................348
23.10.3.0 General.................................................................................................................................................348
23.10.3.1 Resource Pool for sidelink control information...................................................................................350
23.10.3.2 Resource Pool for sidelink data............................................................................................................350
23.10.4 Sidelink Communication via ProSe UE-to-Network Relay.......................................................................350
23.11 Support for sidelink discovery.........................................................................................................................
23.11.1 General.......................................................................................................................................................352
23.11.2 Radio Protocol Architecture.......................................................................................................................352
23.11.3 Radio resource allocation...........................................................................................................................353
23.12 Resource usage reporting for shared networks................................................................................................
23.13 Optimising signalling load and resource usage for paging..............................................................................
23.13.1 General paging optimisation......................................................................................................................355
23.13.2 Paging optimisation for UEs in enhanced coverage..................................................................................356
23.14 Support for V2X services................................................................................................................................
23.14.1 General.......................................................................................................................................................356
23.14.1.0 Overview..............................................................................................................................................356
23.14.1.1 Support for V2X sidelink communication...........................................................................................356
23.14.1.2 Support for V2X communication via Uu.............................................................................................360
23.14.1.3 Void......................................................................................................................................................360
23.15 Support for MMTEL voice and video enhancements......................................................................................
23.15.1 RAN-assisted codec adaptation.................................................................................................................360
23.15.2 MMTEL signalling optimisation...............................................................................................................361
23.15.3 MMTEL voice quality/coverage enhancements........................................................................................361
23.16 Application Layer Measurement Collection....................................................................................................
23.17 Support for Aerial UE communication............................................................................................................
23.17.1 General.......................................................................................................................................................362
23.17.2 Subscription based identification of Aerial UE function...........................................................................362
23.17.3 Height based reporting for Aerial UE communication..............................................................................363
23.17.4 Interference detection and mitigation for Aerial UE communication........................................................363
23.17.5 Flight path information reporting...............................................................................................................363
23.17.6 Location reporting for Aerial UE communication.....................................................................................363
23.18 PDCP packet duplication.................................................................................................................................
23.19 E-UTRAN control for NR sidelink communication........................................................................................
23.20 Support for Multi-USIM devices.....................................................................................................................
23.20.1 General.......................................................................................................................................................364
23.20.2 Paging Collision Avoidance.......................................................................................................................364
23.21 Support for BL UEs, UEs in enhanced coverage and NB-IoT UEs over Non-Terrestrial Networks..............
23.21.1 General.......................................................................................................................................................364
23.21.2 Timing and synchronization.......................................................................................................................364
23.21.2.1 Scheduling timing................................................................................................................................364
23.21.2.2 Pre-compensation by the UE................................................................................................................365
23.21.3 Support of discontinuous coverage............................................................................................................366
23.21.4 Mobility Management................................................................................................................................366
23.21.4.1 Mobility Management in ECM-IDLE..................................................................................................366
23.21.4.2 Mobility Management in ECM-CONNECTED...................................................................................366
23.21.5 Switchover.................................................................................................................................................366
23.21.5.1 Definitions............................................................................................................................................366
23.21.5.2 Assumptions.........................................................................................................................................366
23.21.5.3 Procedures............................................................................................................................................366
23.21.6 Signalling...................................................................................................................................................367
23.21.7 MME(Re-)Selection by eNB.....................................................................................................................367
23.21.8 O&M Requirements...................................................................................................................................367
23.21.9 Coarse UE location reporting.....................................................................................................................367
24 Support for 5GC.................................................................................................................................
24.1 General.............................................................................................................................................................
24.2 Radio Protocol Architecture............................................................................................................................
3GPP
Release 17 18 3GPP TS 36.300 V17.2.0 (2022-09)
24.2.1 User Plane..................................................................................................................................................368

24.2.2 Control Plane..............................................................................................................................................369
24.3 Layer 2.............................................................................................................................................................
24.4 CN Selection....................................................................................................................................................
24.5 Mobility...........................................................................................................................................................
24.6 Slicing..............................................................................................................................................................
24.7 Access Control.................................................................................................................................................
24.8 Radio access network sharing..........................................................................................................................
24.9 Sidelink............................................................................................................................................................
24.10 Minimization of Service Interruption..............................................................................................................
Annex A (informative): NAS Overview....................................................................................................372

A.1 Services and Functions.......................................................................................................................
A.2 NAS protocol states & state transitions..............................................................................................
Annex B (informative): MAC and RRC Control.....................................................................................373
B.1 Difference between MAC and RRC control.......................................................................................
B.2 Void....................................................................................................................................................
Annex C (informative): Void.....................................................................................................................374
Annex D (informative): Void.....................................................................................................................374
Annex E (informative): Void......................................................................................................................374
Annex F (informative): Void374
Annex G (informative): Guideline for E-UTRAN UE capabilities..........................................................375
Annex H (informative): Void.....................................................................................................................376
Annex I (informative): SPID ranges and mapping of SPID values to cell reselection and
inter-RAT/inter frequency handover priorities........................................376
I.1 SPID ranges........................................................................................................................................
I.2 Reference SPID values.......................................................................................................................
Annex J (informative): Carrier Aggregation............................................................................................379
J.1 Deployment Scenarios........................................................................................................................
J.2 Void.................................................................................................................................................................
J.3 Void.................................................................................................................................................................
J.4 Void.................................................................................................................................................................
J.5 Void.................................................................................................................................................................
J.6 Void.................................................................................................................................................................
Annex K (informative): Time domain ICIC.............................................................................................380

K.1 Deployment scenarios.........................................................................................................................
K.1.1 CSG scenario...................................................................................................................................................
K.1.2 Pico scenario....................................................................................................................................................
3GPP
Release 17 19 3GPP TS 36.300 V17.2.0 (2022-09)
Annex L (informative): Void......................................................................................................................382

Annex M (informative): Dual Connectivity..............................................................................................383
M.1 Dual Connectivity operation...............................................................................................................
M.2 Operation Overview...........................................................................................................................
Annex N (informative): Sidelink communication.....................................................................................385
N.1 Deployment Scenarios........................................................................................................................
Annex O (informative): E-UTRAN Architecture for Radio Access Network Sharing with multiple cell
ID broadcast................................................................................................385
Annex P (informative): Example implementation of Non-Terrestrial Networks...................................386
Annex Q (informative): Change history....................................................................................................388
3GPP
Release 17 20 3GPP TS 36.300 V17.2.0 (2022-09)
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.
3GPP
Release 17 21 3GPP TS 36.300 V17.2.0 (2022-09)
1 Scope
The present document provides an overview and overall description of the E-UTRAN radio interface protocol
architecture. Details of the radio interface protocols are specified in companion specifications of the 36 series. For
Multi-Connectivity involving E-URAN, the differences relative to E-UTRA and E-UTRAN are specified in 3GPP TS
37.340 [76].
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 TR 25.913: "Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN (E-
UTRAN)".
[3] 3GPP TS 36.201: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer;
General description".
[4] 3GPP TS 36.211:"Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and
Modulation".
[5] 3GPP TS 36.212: "Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and
channel coding".
[6] 3GPP TS 36.213: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer
procedures".
[7] 3GPP TS 36.214: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer;
Measurements".
[8] IETF RFC 4960 (09/2007): "Stream Control Transmission Protocol".
[9] 3GPP TS 36.302: "Evolved Universal Terrestrial Radio Access (E-UTRA); Services provided by
the physical layer".
[10] Void
[11] 3GPP TS 36.304: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE)
procedures in idle mode".
radio access capabilities".
[13] 3GPP TS 36.321: "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access
Control (MAC) protocol specification".
[14] 3GPP TS 36.322: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control
(RLC) protocol specification".
[15] 3GPP TS 36.323: "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data
Convergence Protocol (PDCP) specification".
3GPP
Release 17 22 3GPP TS 36.300 V17.2.0 (2022-09)
[16] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC) protocol specification".
[17] 3GPP TS 23.401: "Technical Specification Group Services and System Aspects; GPRS
enhancements for E-UTRAN access".
[18] 3GPP TR 24.801: "3GPP System Architecture Evolution (SAE); CT WG1 aspects".
[19] 3GPP TS 23.402: "3GPP System Architecture Evolution: Architecture Enhancements for non-
3GPP accesses".
[20] 3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage
3".
[21] 3GPP TS 36.133: "Evolved Universal Terrestrial Radio Access (E-UTRA); "Requirements for
support of radio resource management".
[22] 3GPP TS 33.401: "3GPP System Architecture Evolution: Security Architecture".
[23] 3GPP TS 23.272: "Circuit Switched Fallback in Evolved Packet System; Stage 2".
[24] Void.
[25] 3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1
Application Protocol (S1AP)".
[26] 3GPP TS 23.003: "Numbering, addressing and identification".
[27] 3GPP TR 25.922: "Radio Resource Management Strategies".
[28] 3GPP TS 23.216: "Single Radio voice Call continuity (SRVCC); Stage 2".
[29] 3GPP TS 32.421: "Subscriber and equipment trace: Trace concepts and requirements".
[30] 3GPP TS 32.422: "Subscriber and equipment trace; Trace control and configuration management".
[31] 3GPP TS 32.423: "Subscriber and equipment trace: Trace data definition and management".
[32] Void.
[33] 3GPP TS 22.220: "Service Requirements for Home NodeBs and Home eNodeBs".
[34] 3GPP TS 22.268: "Public Warning System (PWS) Requirements".
[35] IETF RFC 3168 (09/2001): "The Addition of Explicit Congestion Notification (ECN) to IP".
[36] 3GPP TS 25.446: "MBMS synchronisation protocol (SYNC)".
[37] 3GPP TS 22.168: "Earthquake and Tsunami Warning System (ETWS) requirements; Stage 1".
[38] Void.
[39] Void.
[40] 3GPP TS 29.274: "Tunnelling Protocol for Control Plane (GTPv2-C); Stage 3".
[41] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting
packet based services and Packet Data Networks (PDN)".
[42] 3GPP TS 36.423: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2
Application Protocol (X2AP)".
[43] 3GPP TS 37.320: "Universal Terrestrial Radio Access (UTRA) and Evolved Universal Terrestrial
Radio Access (E-UTRA); Radio measurement collection for Minimization of Drive Tests (MDT);
Overall description; Stage 2".
[44] 3GPP TS 36.443: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); M2
Application Protocol (M2AP)".
3GPP
Release 17 23 3GPP TS 36.300 V17.2.0 (2022-09)
[45] 3GPP TS 36.444: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); M3
Application Protocol (M3AP)".
[46] 3GPP TS 36.420: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 general
aspects and principles".
[47] 3GPP TS 29.281: "General Packet Radio System (GPRS) Tunnelling Protocol User Plane
(GTPv1-U)"
[48] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional
description"
[49] 3GPP TS 26.346: "Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs"
[50] 3GPP TR 36.816: "Evolved Universal Terrestrial Radio Access (E-UTRA); Study on signalling
and procedure for interference avoidance for in-device coexistence".
[51] 3GPP TS 36.305: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Stage 2
functional specifications of User Equipment (UE) positioning in E-UTRAN".
radio transmission and reception".
[53] 3GPP TS 33.320: "Security of Home Node B (HNB) / Home evolved Node B (HeNB)".
[54] 3GPP TS 23.251: "Technical Specification Group Services and System Aspects; Network Sharing;
Architecture and functional description".
[55] 3GPP TS 23.139: "3GPP system – fixed broadband access network interworking".
[56] 3GPP TS 23.007: "Technical Specification Group Core Network and Terminals; Restoration
procedures".
[57] 3GPP TS 23.682: "Architecture enhancements to facilitate communications with packet data
networks and applications".
[58] 3GPP TS 24.312: "Access Network Discovery and Selection Function (ANDSF) Management
Object (MO)".
[59] 3GPP TR 36.842: "Study on Small Cell enhancements for E-UTRA and E-UTRAN; Higher layer
aspects"
[60] 3GPP TR 36.932: "Scenarios and Requirements for Small Cell Enhancements for E-UTRA and E-
UTRAN".
[61] 3GPP TS 36.425: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2
interface user plane protocol".
[62] 3GPP TS 23.303: "Technical Specification Group Services and System Aspects; Proximity-based
services (ProSe)"
[63] 3GPP TS 36.314: "Evolved Universal Terrestrial Radio Access (E-UTRA); Layer 2 -
Measurements".
[64] 3GPP TR 36.889: "Study on Licensed-Assisted Access to Unlicensed Spectrum".
[65] IEEE 802.11, Part 11: "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
specifications, IEEE Std.".
[66] 3GPP TS 36.360: "LTE-WLAN Aggregation Adaptation Protocol (LWAAP) specification".
[67] 3GPP TS 24.302: "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access
networks".
[68] 3GPP TS 36.361: "LTE/WLAN Radio Level Integration Using IPsec Tunnel (LWIP)
encapsulation; Protocol specification".
3GPP
Release 17 24 3GPP TS 36.300 V17.2.0 (2022-09)
[69] 3GPP TS 36.463: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and
Wireless LAN (WLAN); Xw application protocol (XwAP)".
[70] 3GPP TS 33.402: "3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP
accesses".
[71] 3GPP TS 22.185: "Service requirements for V2X services; Stage 1".
[72] 3GPP TS 23.285: "Technical Specification Group Services and System Aspects; Architecture
enhancements for V2X services".
[73] IETF RFC 7567 "IETF Recommendations Regarding Active Queue Management".
[74] 3GPP TS 26.114: "Technical Specification Group Services and System Aspects; IP Multimedia
Subsystem (IMS); Multimedia Telephony; Media handling and interaction".
[75] 3GPP TS 24.386: "User Equipment (UE) to V2X control function; protocol aspects; Stage 3".
[76] 3GPP TS 37.340: "Evolved Universal Terrestrial Radio Access (E-UTRA) and NR; Multi-
connectivity".
[77] 3GPP TS 23.280: "Common functional architecture to support mission critical services; Stage 2".
[78] 3GPP TS 36.355: " Evolved Universal Terrestrial Radio Access (E-UTRA);LTE Positioning
Protocol (LPP)".
[79] 3GPP TS 38.300: "NR; NR and NG-RAN Overall Description, Stage 2".
[80] 3GPP TS 37.324: "NR; Service Data Protocol (SDAP) specification".
[81] 3GPP TS 38.323: "NR; Packet Data Convergence Protocol (PDCP) specification".
[82] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[83] 3GPP TS 23.502: "Procedures for the 5G System; Stage 2".
[84] 3GPP TS 29.002: "Mobile Application Part (MAP) specification".
[85] 3GPP TS 25.412: "UTRAN Iu interface signalling transport".
[86] 3GPP TS 38.423: "NG-RAN; Xn Application Protocol (XnAP)".
[87] Void
[88] 3GPP TS 38.101-1: "NR; User Equipment (UE) radio transmission and reception; Part 1: Range 1
Standalone".
[89] 3GPP TS 38.306: "NR; User Equipment (UE) radio access capabilities".
[90] 3GPP TS 37.213: "Physical layer procedures for shared spectrum channel access".
[91] 3GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3".
[92] 3GPP TS 38.331: "NR; Radio Resource Control (RRC); Protocol specification".
[93] 3GPP TS 23.287: "Architecture enhancements for 5G System (5GS) to support Vehicle-to-
Everything (V2X) services ".
[94] 3GPP TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle
mode".
[95] 3GPP TS 36.410: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 general
aspects and principles".
3GPP
Release 17 25 3GPP TS 36.300 V17.2.0 (2022-09)
3 Definitions, symbols and abbreviations

3.1 Definitions
For the purposes of the present document, the following terms and definitions apply.
Access Control: the process that checks whether a UE is allowed to access and to be granted services in a closed cell.
Aerial UE communication: functionality enabling Aerial UE function as defined in 23.17.
Anchor carrier: in NB-IoT, a carrier where the UE assumes that NPSS/NSSS/NPBCH/SIB-NB for FDD or
NPSS/NSSS/NPBCH for TDD are transmitted.
Carrier frequency: center frequency of the cell.
Cell: combination of downlink and optionally uplink resources. The linking between the carrier frequency of the
downlink resources and the carrier frequency of the uplink resources is indicated in the system information transmitted
on the downlink resources.
Cell Group: in dual connectivity, a group of serving cells associated with either the MeNB or the SeNB.
CHO candidate cell: a candidate cell for CHO, for which UE has been configured with a CHO configuration.
Conditional Handover (CHO): a handover procedure that is executed only when execution condition(s) are met.
Control plane CIoT 5GS Optimisation: Enables support of efficient transport of user data (IP, Ethernet and
Unstructured) or SMS messages over control plane via the AMF without triggering user-plane resource establishment,
as defined in TS 24.501 [91]. In the context of this specification, a NB-IoT UE that only supports Control plane CIoT
5GS Optimisation is a UE that does not support User plane CIoT 5GS Optimisation and NG-U data transfer but may
support other CIoT 5GS Optimisations.
Control plane CIoT EPS optimisation: Enables support of efficient transport of user data (IP, non-IP or SMS) over
control plane via the MME without triggering data radio bearer establishment, as defined in TS 24.301 [20]. In the
context of this specification, a NB-IoT UE that only supports Control plane CIoT EPS optimisation is a UE that does
not support User plane CIoT EPS optimisation and S1-U data transfer but may support other CIoT EPS optimisations.
CSG Cell: a cell broadcasting a CSG indicator set to true and a specific CSG identity.
CSG ID Validation: the process that checks whether the CSG ID received via handover messages is the same as the
one broadcast by the target E-UTRAN.
CSG member cell: a cell broadcasting the identity of the selected PLMN, registered PLMN or equivalent PLMN and
for which the Permitted CSG list of the UE includes an entry comprising cell's CSG ID and the respective PLMN
identity.
DAPS Handover: a handover procedure that maintains the source eNB connection after reception of RRC message for
handover and until releasing the source cell after successful random access to the target eNB.
DCN-ID: DCN identity identifies a specific dedicated core network (DCN).
Dual Connectivity: mode of operation of a UE in RRC_CONNECTED, configured with a Master Cell Group and a
Secondary Cell Group.
Early Data Forwarding: data forwarding that is initiated before the UE executes the handover.
en-gNB: as defined in TS 37.340 [76].
Ephemeris: a set of parameters that describe the movement of an NTN node over time.
E-RAB: an E-RAB uniquely identifies the concatenation of an S1 Bearer and the corresponding Data Radio Bearer.
When an E-RAB exists, there is a one-to-one mapping between this E-RAB and an EPS bearer of the Non Access
Stratum as defined in [17].
Feeder link: wireless link between the NTN Gateway and the NTN payload.
3GPP
Release 17 26 3GPP TS 36.300 V17.2.0 (2022-09)
Frequency layer: set of cells with the same carrier frequency.
FeMBMS: further enhanced multimedia broadcast multicast service.
FeMBMS/Unicast-mixed cell: cell supporting MBMS transmission and unicast transmission as SCell.
Geosynchronous Orbit: Earth-centred orbit at approximately 35,786 kilometres in altitude 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.
Handover: procedure that changes the serving cell of a UE in RRC_CONNECTED.
Hybrid cell: a cell broadcasting a CSG indicator set to false and a specific CSG identity. This cell is accessible as a
CSG cell by UEs which are members of the CSG and as a normal cell by all other UEs.
Late Data Forwarding: data forwarding that is initiated after the source eNB knows that the UE has successfully
accessed a target eNB.
Local Home Network: as defined in TS 23.401 [17].
LTE bearer: in LTE-WLAN Aggregation, a bearer whose radio protocols are located in the eNB only to use eNB radio
resources only.
LWA bearer: in LTE-WLAN Aggregation, a bearer whose radio protocols are located in both the eNB and the WLAN
to use both eNB and WLAN resources.
LWAAP PDU: in LTE-WLAN Aggregation, a PDU with DRB ID generated by LWAAP entity for transmission over
WLAN.
Make-Before-Break HO/SeNB change: maintaining source eNB/SeNB connection after reception of RRC message
for handover or change of SeNB before the initial uplink transmission to the target eNB during handover or change of
SeNB.
Mapped Cell ID: in NTN, it corresponds to a fixed geographical area.
Master Cell Group: in dual connectivity, a group of serving cells associated with the MeNB, comprising of the PCell
and optionally one or more SCells.
Master eNB: in dual connectivity, the eNB which terminates at least S1-MME.
MBMS-dedicated cell: cell dedicated to MBMS transmission.
MBMS/Unicast-mixed cell: cell supporting both unicast and MBMS transmissions.
MCG bearer: in dual connectivity, a bearer whose radio protocols are only located in the MeNB to use MeNB
resources only.
Membership Verification: the process that checks whether a UE is a member or non-member of a hybrid cell.
Multi-Connectivity: Mode of operation whereby a multiple Rx/Tx UE in the connected mode is configured to utilise
radio resources amongst E-UTRA and/or NR provided by multiple distinct schedulers connected via non-ideal
backhaul.
NB-IoT: NB-IoT allows access to network services via E-UTRA with a channel bandwidth limited to 200 kHz.
NB-IoT UE: a UE that uses NB-IoT.
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.
Non-anchor carrier: in NB-IoT, a carrier where the UE does not assume that NPSS/NSSS/NPBCH/SIB-NB for FDD
or NPSS/NSSS/NPBCH for TDD are transmitted.
Non-geosynchronous orbit: Earth-centred orbit with an orbital period that does not match Earth's rotation on its axis.
This includes Low Earth Orbit (LEO) and Medium Earth Orbit (MEO).
3GPP
Release 17 27 3GPP TS 36.300 V17.2.0 (2022-09)
Non-terrestrial networks: an E-UTRAN consisting of eNBs, which provide non-terrestrial LTE access to UEs by
means of an NTN payload embarked on a space-borne NTN vehicle and an NTN Gateway.
NR: NR radio access
NR sidelink communication: AS functionality enabling at least V2X Communication as defined in TS 23.287 [93],
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, 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.
PLMN ID Check: the process that checks whether a PLMN ID is the RPLMN identity or an EPLMN identity of the
UE.
Power saving mode: mode configured and controlled by NAS that allows the UE to reduce its power consumption, as
defined in TS 24.301 [20], TS 23.401 [17], TS 23.682 [57].
Primary PUCCH group: a group of serving cells including PCell whose PUCCH signalling is associated with the
PUCCH on PCell.
Primary Timing Advance Group: Timing Advance Group containing the PCell. In this specification, Primary Timing
Advance Group refers also to Timing Advance Group containing the PSCell unless explicitly stated otherwise.
ProSe-enabled Public Safety UE: a UE that the HPLMN has configured to be authorized for Public Safety use, and
which is ProSe-enabled and supports ProSe procedures and capabilities specific to Public Safety. The UE may, but need
not, have a USIM with one of the special access classes {12, 13, 14}.
ProSe Per-Packet Priority: a scalar value associated with a protocol data unit that defines the priority handling to be
applied for transmission of that protocol data unit.
ProSe UE-to-Network Relay: a UE that provides functionality to support connectivity to the network for Remote
UE(s).
ProSe UE-to-Network Relay Selection: Process of identifying a potential ProSe UE-to Network Relay, which can be
used for connectivity services (e.g. to communicate with a PDN).
ProSe UE-to-Network Relay Reselection: process of changing previously selected ProSe UE-to-Network Relay and
identifying potential a new ProSe UE-to-Network Relay, which can be be used for connectivity services (e.g. to
communicate with PDN).
Public Safety ProSe Carrier: carrier frequency for public safety sidelink communication and public safety sidelink
discovery.
PUCCH group: either primary PUCCH group or a secondary PUCCH group.
PUCCH SCell: a Secondary Cell configured with PUCCH.
RACH-less HO/SeNB change: skipping random access procedure during handover or change of SeNB.
Receive Only Mode: See TS 23.246 [48].
Remote UE: a ProSe-enabled Public Safety UE, that communicates with a PDN via a ProSe UE-to-Network Relay.
Satellite: a space-borne vehicle orbiting the Earth that carries the NTN payload.
SCG bearer: in dual connectivity, a bearer whose radio protocols are only located in the SeNB to use SeNB resources.
Secondary Cell Group: in dual connectivity, a group of serving cells associated with the SeNB, comprising of PSCell
and optionally one or more SCells.
Secondary eNB: in dual connectivity, the eNB that is providing additional radio resources for the UE but is not the
Master eNB.
3GPP
Release 17 28 3GPP TS 36.300 V17.2.0 (2022-09)
Secondary PUCCH group: a group of SCells whose PUCCH signalling is associated with the PUCCH on the PUCCH
SCell.
Secondary Timing Advance Group: Timing Advance Group containing neither the PCell nor PSCell.
Service link: wireless link between the NTN payload and the UE.
Short Processing Time: For 1 ms TTI length, the operation with short processing time in UL data transmission and DL
data reception.
Short TTI: TTI length based on a slot or a subslot.
Sidelink: UE to UE interface for sidelink communication, V2X sidelink communication and sidelink discovery. The
Sidelink corresponds to the PC5 interface as defined in TS 23.303 [62].
Sidelink Control period: period over which resources are allocated in a cell for sidelink control information and
sidelink data transmissions. The Sidelink Control period corresponds to the PSCCH period as defined in TS 36.213 [6].
Sidelink communication: AS functionality enabling ProSe Direct Communication as defined in TS 23.303 [62],
between two or more nearby UEs, using E-UTRA technology but not traversing any network node. In this version, the
terminology "sidelink communication" without "V2X" prefix only concerns PS unless specifically stated otherwise.
Sidelink discovery: AS functionality enabling ProSe Direct Discovery as defined in TS 23.303 [62], using E-UTRA
technology but not traversing any network node.
Split bearer: in dual connectivity, a bearer whose radio protocols are located in both the MeNB and the SeNB to use
both MeNB and SeNB resources.
Split LWA bearer: in LTE-WLAN Aggregation, a bearer whose radio protocols are located in both the eNB and the
WLAN to use both eNB and WLAN radio resources.
Switched LWA bearer: in LTE-WLAN Aggregation, a bearer whose radio protocols are located in both the eNB and
the WLAN but uses WLAN radio resources only.
Timing Advance Group: a group of serving cells that is configured by RRC and that, for the cells with an UL
configured, use the same timing reference cell and the same Timing Advance value.
User plane CIoT 5GS Optimisation: Enables support for change from 5GMM-IDLE mode to 5GMM-CONNECTED
mode without the need for using the Service Request procedure, as defined in TS 24.501 [91].
User plane CIoT EPS optimisation: Enables support for change from EMM-IDLE mode to EMM-CONNECTED
mode without the need for using the Service Request procedure, as defined in TS 24.301 [20].
V2X sidelink communication: AS functionality enabling V2X Communication as defined in TS 23.285 [72], between
nearby UEs, using E-UTRA technology but not traversing any network node.
WLAN Termination: the logical node that terminates the Xw interface on the WLAN side.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] 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].
1xCSFB Circuit Switched Fallback to 1xRTT

5GC 5G Core Network
ABS Almost Blank Subframe
AC Access Category
ACK Acknowledgement
ACLR Adjacent Channel Leakage Ratio
AM Acknowledged Mode
AMBR Aggregate Maximum Bit Rate
ANDSF Access Network Discovery and Selection Function
ANR Automatic Neighbour Relation
ARP Allocation and Retention Priority
3GPP
Release 17 29 3GPP TS 36.300 V17.2.0 (2022-09)
ARQ Automatic Repeat Request

AS Access Stratum
AUL Autonomous Uplink
BCCH Broadcast Control Channel
BCH Broadcast Channel
BL Bandwidth reduced Low complexity
BR-BCCH Bandwidth Reduced Broadcast Control Channel
BSR Buffer Status Report
C/I Carrier-to-Interference Power Ratio
CA Carrier Aggregation
CAZAC Constant Amplitude Zero Auto-Correlation
CBC Cell Broadcast Center
CC Component Carrier
CG Cell Group
CHO Conditional Handover
CIF Carrier Indicator Field
CIoT Cellular Internet of Things
CMAS Commercial Mobile Alert Service
CMC Connection Mobility Control
C-plane Control Plane
C-RNTI Cell RNTI
CoMP Coordinated Multi Point
CP Cyclic Prefix
CQI Channel Quality Indicator
CRC Cyclic Redundancy Check
CRE Cell Range Extension
CRS Cell-specific Reference Signal
CSA Common Subframe Allocation
CSG Closed Subscriber Group
CSI Channel State Information
CSI-IM CSI interference measurement
CSI-RS CSI reference signal
DAPS Dual Active Protocol Stack
DC Dual Connectivity
DCCH Dedicated Control Channel
DCN Dedicated Core Network
DeNB Donor eNB
DFTS DFT Spread OFDM
DL Downlink
DMTC Discovery Signal Measurement Timing Configuration
DRB Data Radio Bearer
DRS Discovery Reference Signal
DRX Discontinuous Reception
DTCH Dedicated Traffic Channel
DTX Discontinuous Transmission
DwPTS Downlink Pilot Time Slot
E-CID Enhanced Cell-ID (positioning method)
E-RAB E-UTRAN Radio Access Bearer
E-UTRA Evolved UTRA
E-UTRAN Evolved UTRAN
EAB Extended Access Barring
ECGI E-UTRAN Cell Global Identifier
ECM EPS Connection Management
EDT Early Data Transmission
EHC Ethernet Header Compression
eHRPD enhanced High Rate Packet Data
eIMTA Enhanced Interference Management and Traffic Adaptation
EMM EPS Mobility Management
eNB E-UTRAN NodeB
EPC Evolved Packet Core
EPDCCH Enhanced Physical Downlink Control Channel
3GPP
Release 17 30 3GPP TS 36.300 V17.2.0 (2022-09)
EPS Evolved Packet System

ETWS Earthquake and Tsunami Warning System
FDD Frequency Division Duplex
FDM Frequency Division Multiplexing
G-RNTI Group RNTI
GBR Guaranteed Bit Rate
GERAN GSM EDGE Radio Access Network
GNSS Global Navigation Satellite System
GP Guard Period
GRE Generic Routing Encapsulation
GSM Global System for Mobile communication
GSO Geosynchronous Orbit
GUMMEI Globally Unique MME Identifier
GUTI Globally Unique Temporary Identifier
GWCN GateWay Core Network
GWUS Group Wake Up Signal
H-SFN Hyper System Frame Number
HARQ Hybrid ARQ
(H)eNB eNB or HeNB
HO Handover
HPLMN Home Public Land Mobile Network
HRPD High Rate Packet Data
HSDPA High Speed Downlink Packet Access
ICIC Inter-Cell Interference Coordination
IDC In-Device Coexistence
IP Internet Protocol
ISM Industrial, Scientific and Medical
KPAS Korean Public Alert System
L-GW Local Gateway
LAA Licensed-Assisted Access
LB Load Balancing
LBT Listen Before Talk
LCG Logical Channel Group
LCR Low Chip Rate
LCS LoCation Service
LEO Low Earth Orbit
LHN Local Home Network
LHN ID Local Home Network ID
LIPA Local IP Access
LMU Location Measurement Unit
LPPa LTE Positioning Protocol Annex
LTE Long Term Evolution
LWA LTE-WLAN Aggregation
LWAAP LTE-WLAN Aggregation Adaptation Protocol
LWIP LTE WLAN Radio Level Integration with IPsec Tunnel
LWIP-SeGW LWIP Security Gateway
MAC Medium Access Control
MBMS Multimedia Broadcast Multicast Service
MBR Maximum Bit Rate
MBSFN Multimedia Broadcast multicast service Single Frequency Network
MCCH Multicast Control Channel
MCE Multi-cell/multicast Coordination Entity
MCG Master Cell Group
MCH Multicast Channel
MCS Modulation and Coding Scheme
MDT Minimization of Drive Tests
MeNB Master eNB
MEO Medium Earth Orbit
MGW Media Gateway
MIB Master Information Block
MIMO Multiple Input Multiple Output
3GPP
Release 17 31 3GPP TS 36.300 V17.2.0 (2022-09)
MME Mobility Management Entity

MMTEL Multimedia telephony
MO-EDT Mobile Originated Early Data Transmission
MPDCCH MTC Physical Downlink Control Channel
MSA MCH Subframe Allocation
MSI MCH Scheduling Information
MSP MCH Scheduling Period
MT-EDT Mobile Terminated Early Data Transmission
MTC Machine-Type Communications
MTCH Multicast Traffic Channel
MTSI Multimedia Telephony Service for IMS
MUSIM Multi-Universal Subscriber Identity Module
N2 Reference point between the NG-RAN and the AMF
NACK Negative Acknowledgement
NAS Non-Access Stratum
NB-IoT Narrow Band Internet of Things
NCC Next Hop Chaining Counter
NCGI NR Cell Global Identifier
NCR Neighbour Cell Relation
NG-RAN NG Radio Access Network
NGSO Non-Geosynchronous Orbit
NH Next Hop key
NNSF NAS Node Selection Function
NPBCH Narrowband Physical Broadcast channel
NPDCCH Narrowband Physical Downlink Control channel
NPDSCH Narrowband Physical Downlink Shared channel
NPRACH Narrowband Physical Random Access channel
NPUSCH Narrowband Physical Uplink Shared channel
NPRS Narrowband Positioning Reference Signal
NPSS Narrowband Primary Synchronization Signal
NR NR Radio Access
NRT Neighbour Relation Table
NSSS Narrowband Secondary Synchronization Signal
NTN Non-Terrestrial Network
OFDM Orthogonal Frequency Division Multiplexing
OFDMA Orthogonal Frequency Division Multiple Access
OPI Offload Preference Indicator
OTDOA Observed Time Difference Of Arrival (positioning method)
P-GW PDN Gateway
P-RNTI Paging RNTI
PA Power Amplifier
PAPR Peak-to-Average Power Ratio
PBCH Physical Broadcast CHannel
PBR Prioritised Bit Rate
PCC Primary Component Carrier
PCCH Paging Control Channel
PCell Primary Cell
PCFICH Physical Control Format Indicator CHannel
PCH Paging Channel
PCI Physical Cell Identifier
PDCCH Physical Downlink Control CHannel
PDCP Packet Data Convergence Protocol
PDN Packet Data Network
PDSCH Physical Downlink Shared CHannel
PDU Protocol Data Unit
PHICH Physical Hybrid ARQ Indicator CHannel
PHY Physical layer
PLMN Public Land Mobile Network
PMCH Physical Multicast CHannel
PMK Pairwise Master Key
PPPP ProSe Per-Packet Priority
3GPP
Release 17 32 3GPP TS 36.300 V17.2.0 (2022-09)
PPPR ProSe Per-Packet Reliability

PRACH Physical Random Access CHannel
PRB Physical Resource Block
ProSe Proximity based Services
PSBCH Physical Sidelink Broadcast CHannel
PSC Packet Scheduling
PSCCH Physical Sidelink Control CHannel
PSCell Primary SCell
PSDCH Physical Sidelink Discovery CHannel
PSK Pre-Shared Key
PSM Power Saving Mode
PSSCH Physical Sidelink Shared CHannel
pTAG Primary Timing Advance Group
PTW Paging Time Window
PUCCH Physical Uplink Control CHannel
PUR Preconfigured Uplink Resource
PUR-RNTI Preconfigured Uplink Resource RNTI
PUSCH Physical Uplink Shared CHannel
PWS Public Warning System
QAM Quadrature Amplitude Modulation
QCI QoS Class Identifier
QoE Quality of Experience
QoS Quality of Service
R-PDCCH Relay Physical Downlink Control CHannel
RA-RNTI Random Access RNTI
RAC Radio Admission Control
RACH Random Access Channel
RANAC RAN-based Notification Area code
RAT Radio Access Technology
RB Radio Bearer
RBC Radio Bearer Control
RCLWI RAN Controlled LTE-WLAN Interworking
RF Radio Frequency
RIBS Radio-interface based synchronization
RIM RAN Information Management
RLC Radio Link Control
RMTC RSSI Measurement Timing Configuration
RN Relay Node
RNA RAN-based Notification Area
RNAU RAN-based Notification Area Update
RNC Radio Network Controller
RNL Radio Network Layer
RNTI Radio Network Temporary Identifier
ROHC Robust Header Compression
ROM Receive Only Mode
RRC Radio Resource Control
RRM Radio Resource Management
RTT Round Trip Time
RU Resource Unit
S-GW Serving Gateway
S-RSRP Sidelink Reference Signal Received Power
S1-MME S1 for the control plane
SAE System Architecture Evolution
SAP Service Access Point
SBCCH Sidelink Broadcast Control Channel
SC-FDMA Single Carrier – Frequency Division Multiple Access
SC-MCCH Single Cell Multicast Control Channel
SC-MTCH Single Cell Multicast Transport Channel
SC-N-RNTI Single Cell Notification RNTI
SC-PTM Single Cell Point To Multiploint
SC-RNTI Single Cell RNTI
3GPP
Release 17 33 3GPP TS 36.300 V17.2.0 (2022-09)
SCC Secondary Component Carrier

SCell Secondary Cell
SCG Secondary Cell Group
SCH Synchronization Channel
SCTP Stream Control Transmission Protocol
SD-RSRP Sidelink Discovery Reference Signal Received Power
SDAP Service Data Adaptation Protocol
SDF Service Data Flow
SDMA Spatial Division Multiple Access
SDU Service Data Unit
SeGW Security Gateway
SeNB Secondary eNB
SFN System Frame Number
SI System Information
SI-RNTI System Information RNTI
S1-U S1 for the user plane
SIB System Information Block
SIPTO Selected IP Traffic Offload
SIPTO@LN Selected IP Traffic Offload at the Local Network
SL-BCH Sidelink Broadcast Channel
SL-DCH Sidelink Discovery Channel
SL-RNTI Sidelink RNTI
SL-SCH Sidelink Shared Channel
SPDCCH Short PDCCH
SPID Subscriber Profile ID for RAT/Frequency Priority
SPT Short Processing Time
SPUCCH Short PUCCH
SR Scheduling Request
SRB Signalling Radio Bearer
sTAG Secondary Timing Advance Group
STCH Sidelink Traffic Channel
SU Scheduling Unit
TA Tracking Area
TAC Tracking Area Code
TAG Timing Advance Group
TB Transport Block
TCP Transmission Control Protocol
TDD Time Division Duplex
TDM Time Division Multiplexing
TEID Tunnel Endpoint Identifier
TFT Traffic Flow Template
TM Transparent Mode
TMGI Temporary Mobile Group Identity
TNL Transport Network Layer
TTI Transmission Time Interval
U-plane User plane
UAC Unified Access Control
UDC Uplink Data Compression
UE User Equipment
UL Uplink
UM Unacknowledged Mode
UMTS Universal Mobile Telecommunication System
UpPTS Uplink Pilot Time Slot
UTRA Universal Terrestrial Radio Access
UTRAN Universal Terrestrial Radio Access Network
V2I Vehicle-to-Infrastructure
V2N Vehicle-to-Network
V2P Vehicle-to-Pedestrian
V2V Vehicle-to-Vehicle
V2X Vehicle-to-Everything
VRB Virtual Resource Block
3GPP
Release 17 34 3GPP TS 36.300 V17.2.0 (2022-09)
WLAN Wireless Local Area Network

WT WLAN Termination
WUS Wake Up Signal
X2-C X2-Control plane
X2 GW X2 GateWay
X2-U X2-User plane
Xw-C Xw-Control plane
Xw-U Xw-User plane
4 Overall architecture
4.0 General
The E-UTRAN consists of eNBs, providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC)
protocol terminations towards the UE. The eNBs are interconnected with each other by means of the X2 interface. The
eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME
(Mobility Management Entity) by means of the S1-MME interface and to the Serving Gateway (S-GW) by means of the
S1-U interface. The S1 interface supports a many-to-many relation between MMEs / Serving Gateways and eNBs.
The E-UTRAN architecture is illustrated in Figure 4 below.
Figure 4-1: Overall Architecture
If the eNB supports SIPTO@LN with collocated L-GW, it shall support an S5 interface towards the S-GW and an SGi
interface towards the IP network. See clause 4.8.2 for the details of the architecture and functions in case SIPTO@LN
with collocated L-GW is supported.
The E-UTRAN may also comprise LMUs (Location Measurement Unit) (see TS 36.305 [51]) used for Uplink
positioning.
For NB-IoT the positioning is supported based on the existing LCS architecture.
4.1 Functional Split

The eNB hosts the following functions:
- Functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection
Mobility Control, Dynamic allocation of resources to UEs in uplink, downlink and sidelink (scheduling);
- IP and Ethernet header compression, uplink data decompression and encryption of user data stream;
3GPP
Release 17 35 3GPP TS 36.300 V17.2.0 (2022-09)
- Selection of an MME at UE attachment when no routing to an MME can be determined from the information
provided by the UE;
- Routing of User Plane data towards Serving Gateway;
- Scheduling and transmission of paging messages (originated from the MME);
- Scheduling and transmission of broadcast information (originated from the MME or O&M);
- Measurement and measurement reporting configuration for mobility and scheduling;
- Scheduling and transmission of PWS (which includes ETWS and CMAS) messages (originated from the MME);
- CSG handling;
- Transport level packet marking in the uplink;
- S-GW relocation without UE mobility, as defined in TS 23.401 [17];
- SIPTO@LN handling;
- Maintaining security and radio configuration for User Plane CIoT EPS optimisations, as defined in TS 24.301
[20];
- Optionally registering with the X2 GW (if used).
The DeNB hosts the following functions in addition to the eNB functions:
- S1/X2 proxy functionality for supporting RNs;
- S11 termination and S-GW/P-GW functionality for supporting RNs.
The MME hosts the following functions (see TS 23.401 [17]):
- NAS signalling;
- NAS signalling security;
- AS Security control;
- Selection of CIoT EPS optimisations (e.g., Control Plane CIoT EPS optimisation, as defined in TS 24.301 [20]);
- Inter CN node signalling for mobility between 3GPP access networks;
- Idle mode UE Reachability (including control and execution of paging retransmission);
- Tracking Area list management (for UE in idle and active mode);
- PDN GW and Serving GW selection;
- MME selection for handovers with MME change;
- SGSN selection for handovers to 2G or 3G 3GPP access networks;
- Roaming;
- Authentication;
- Bearer management functions including dedicated bearer establishment. The MME may include two transport
layer addresses of different versions in the Transport Layer Address IE to enable that an en-gNB can select either
IPv4 or IPv6 for a bearer;
- Support for PWS (which includes ETWS and CMAS) message transmission;
- Optionally performing paging optimisation;
- S-GW relocation without UE mobility, as defined in TS 23.401 [17].
3GPP
Release 17 36 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE 1: The MME should not filter the PAGING message based on the CSG IDs towards macro eNBs.
The Serving Gateway (S-GW) hosts the following functions (see TS 23.401 [17]):
- The local Mobility Anchor point for inter-eNB handover;
- Mobility anchoring for inter-3GPP mobility;
- E-UTRAN idle mode downlink packet buffering and initiation of network triggered service request procedure;
- Lawful Interception;
- Packet routeing and forwarding;
- Transport level packet marking in the uplink and the downlink;
- Accounting on user and QCI granularity for inter-operator charging;
- UL and DL charging per UE, PDN, and QCI.
The PDN Gateway (P-GW) hosts the following functions (see TS 23.401 [17]):
- Per-user based packet filtering (by e.g. deep packet inspection);
- Lawful Interception;
- UE IP address allocation;
- Transport level packet marking in the uplink and the downlink;
- UL and DL service level charging, gating and rate enforcement;
- DL rate enforcement based on APN-AMBR;
This is summarized on the figure below where yellow boxes depict the logical nodes, white boxes depict the functional
entities of the control plane and blue boxes depict the radio protocol layers.
NOTE 2: There is no logical E-UTRAN node other than the eNB needed for RRM purposes.
NOTE 3: MBMS related functions in E-UTRAN are described separately in clause 15.
3GPP
Release 17 37 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 4.1-1: Functional Split between E-UTRAN and EPC
4.2 Void
4.2.1 Void
4.2.2 Void
4.3 Radio Protocol architecture
4.3.0 General
In this clause, the radio protocol architecture of E-UTRAN is given for the user plane and the control plane.
4.3.1 User plane

The figure below shows the protocol stack for the user-plane, where PDCP, RLC and MAC sublayers (terminated in
eNB on the network side) perform the functions listed for the user plane in clause 6, e.g. header compression, ciphering,
scheduling, ARQ and HARQ.
Figure 4.3.1-1: User-plane protocol stack
3GPP
Release 17 38 3GPP TS 36.300 V17.2.0 (2022-09)
For NB-IoT, the user plane is not used when transfering data over NAS.
4.3.2 Control plane

The figure below shows the protocol stack for the control-plane, where:
- PDCP sublayer (terminated in eNB on the network side) performs the functions listed for the control plane in
clause 6, e.g. ciphering and integrity protection;
- RLC and MAC sublayers (terminated in eNB on the network side) perform the same functions as for the user
plane;
- RRC (terminated in eNB on the network side) performs the functions listed in clause 7, e.g.:
- Broadcast;
- Paging;
- RRC connection management;
- RB control;
- Mobility functions;
- UE measurement reporting and control, except for NB-IoT.
- NAS control protocol (terminated in MME on the network side) performs among other things:
- EPS bearer management;
- Authentication;
- ECM-IDLE mobility handling;
- Paging origination in ECM-IDLE;
- Security control.
NOTE 1: The NAS control protocol is not covered by the scope of this TS and is only mentioned for information.
Figure 4.3.2-1: Control-plane protocol stack
NOTE 2: For a NB-IoT UE that only supports Control Plane CIoT EPS optimisation, as defined in TS 24.301 [20],
PDCP is bypassed. For a NB-IoT UE that supports Control Plane CIoT EPS optimisation and S1-U data
transfer or User Plane CIoT EPS optimisation, as defined in TS 24.301 [20], PDCP is also bypassed (i.e.
not used) until AS security is activated.
3GPP
Release 17 39 3GPP TS 36.300 V17.2.0 (2022-09)
4.4 Synchronization
Diverse methods and techniques are preferred depending on synchronization requirements. As no single method can
cover all E-UTRAN applications a logical port at eNB may be used for reception of timing and/or frequency and/or
phase inputs pending to the synchronization method chosen.
4.5 IP fragmentation
Fragmentation function in IP layer on S1 and X2 shall be supported.
Configuration of S1-U (X2-U) link MTU in the eNB according to the MTU of the network domain the node belongs to
shall be considered as a choice at network deployment. The network may employ various methods to handle IP
fragmentation, but the specific methods to use are implementation dependant.
4.6 Support of HeNBs

4.6.1 Architecture
Figure 4.6.1-1 shows a logical architecture for the HeNB that has a set of S1 interfaces to connect the HeNB to the EPC.
The configuration and authentication entities as shown here should be common to HeNBs and HNBs.
Figure 4.6.1-1: E-UTRAN HeNB Logical Architecture
The E-UTRAN architecture may deploy a Home eNB Gateway (HeNB GW) to allow the S1 interface between the
HeNB and the EPC to support a large number of HeNBs in a scalable manner. The HeNB GW serves as a concentrator
for the C-Plane, specifically the S1-MME interface. The S1-U interface from the HeNB may be terminated at the HeNB
GW, or a direct logical U-Plane connection between HeNB and S-GW may be used (as shown in Figure 4.6.1-1).
The S1 interface is defined as the interface:
- Between the HeNB GW and the Core Network;
- Between the HeNB and the HeNB GW;
- Between the HeNB and the Core Network;
- Between the eNB and the Core Network.
The HeNB GW appears to the MME as an eNB. The HeNB GW appears to the HeNB as an MME. The S1 interface
between the HeNB and the EPC is the same, regardless whether the HeNB is connected to the EPC via a HeNB GW or
not.
3GPP
Release 17 40 3GPP TS 36.300 V17.2.0 (2022-09)
The HeNB GW shall connect to the EPC in a way that inbound and outbound mobility to cells served by the HeNB GW
shall not necessarily require inter MME handovers. One HeNB serves only one cell.
The functions supported by the HeNB shall be the same as those supported by an eNB (with possible exceptions e.g.
NNSF) and the procedures run between a HeNB and the EPC shall be the same as those between an eNB and the EPC
(with possible exceptions e.g. S5 procedures in case of LIPA support).
X2-based HO involving HeNBs is allowed as shown in Table 4.6.1-1.
Table 4.6.1-1: X2-based HO support
Source Target Notes

eNB or any HeNB open access HeNB
eNB, or any HeNB hybrid access HeNB
hybrid access HeNB or closed access HeNB Only applies for same
closed access HeNB CSG ID and PLMN,
and if the UE is a
member of the CSG
cell.
Any HeNB eNB
This version of the specification supports X2-connectivity between HeNBs, independent of whether any of the involved
HeNBs is connected to a HeNB GW.
The overall E-UTRAN architecture with deployed HeNB GW and X2 GW is shown below.
Figure 4.6.1-2: Overall E-UTRAN Architecture with deployed HeNB GW and X2 GW.
NOTE: In the figure above, a HeNB operating in LIPA mode has been represented with its S5 interface. X2-based
HO involving HeNBs is supported according to Table 4.6.1-1.
If the HeNB supports the LIPA function, it shall support an S5 interface towards the S-GW and an SGi interface
towards the residential/IP network. See clause 4.6.5 for the details of the architecture and functions in case of LIPA
support.
If the HeNB supports SIPTO@LN with collocated L-GW, it shall support an S5 interface towards the S-GW and an SGi
interface towards the IP network. The S5 interface does not go via the HeNB GW, even when present. All other
functions are described in clause 4.8.2.
3GPP
Release 17 41 3GPP TS 36.300 V17.2.0 (2022-09)
4.6.2 Functional Split

A HeNB hosts the same functions as an eNB as described in clause 4.1, with the following additional specifics in case
of connection to the HeNB GW:
- Discovery of a suitable Serving HeNB GW;
- A HeNB shall only connect to a single HeNB GW at one time, namely no S1 Flex function shall be used at the
HeNB:
- The HeNB will not simultaneously connect to another HeNB GW, or another MME.
- The TAC and PLMN ID used by the HeNB shall also be supported by the HeNB GW;
- Selection of an MME at UE attachment is hosted by the HeNB GW instead of the HeNB. Upon reception of the
GUMMEI from a UE, the HeNB shall include it in the INITIAL UE MESSAGE message; upon reception of the
GUMMEI Type from the UE, the HeNB shall also include it in the message if supported and supported by the
HeNB GW.
- HeNBs may be deployed without network planning. A HeNB may be moved from one geographical area to
another and therefore it may need to connect to different HeNB GWs depending on its location;
- Signalling the GUMMEI of the Source MME to the HeNB GW in the S1 PATH SWITCH REQUEST message.
Regardless of HeNB GW connection:
- The HeNB may support the LIPA function. See clause 4.6.5 for details.
- The HeNB may support Fixed Broadband Access network interworking function to signal Tunnel Information to
the MME via INITIAL UE MESSAGE message, PATH SWITCH REQUEST message and HANDOVER
NOTIFY message as specified in TS 23.139 [55]. The HeNB may also signal Tunnel Information to the MeNB
via SENB ADDITION REQUEST ACKNOWLEDGE message when the HeNB provide SeNB function and the
MeNB signal to MME via E-RAB MODIFICATION INDICATION message The Tunnel Information includes
the HeNB IP address, the UDP port if NAT/NAPT is detected.
- In case an X2 GW is used, the HeNB registers with the X2 GW at power on or after any change of TNL
address(es).
The HeNB GW hosts the following functions:
- Relaying UE-associated S1 application part messages between the MME serving the UE and the HeNB serving
the UE, except the UE CONTEXT RELEASE REQUEST message received from the HeNB with an explicit
GW Context Release Indication. In that case, the HeNB GW terminates the S1 UE Context Release Request
procedure and releases the UE context if it determines that the UE identified by the received UE S1AP IDs is no
longer served by an HeNB attached to it. Otherwise it ignores the message.
- In case of S1 INITIAL CONTEXT SETUP REQUEST message and S1 HANDOVER REQUEST message,
informing the HeNB about any GUMMEI corresponding to the serving MME, the MME UE S1AP ID
assigned by the MME and the MME UE S1AP ID assigned by the HeNB GW for the UE. In case of S1
PATH SWITCH REQUEST ACKNOWLEDGE message, informing the HeNB about the MME UE S1AP ID
assigned by the MME and the MME UE S1AP ID assigned by the HeNB GW for the UE.
- In case of S1 INITIAL UE MESSAGE message, S1 PATH SWITCH REQUEST and S1 HANDOVER

REQUEST ACKNOWLEDGE message, verifying, as defined in TS 33.320 [53], for a closed HeNB, that the
indicated cell access mode and CSG ID are valid for that HeNB.
- Terminating non-UE associated S1 application part procedures towards the HeNB and towards the MME. In
case of S1 SETUP REQUEST message, verifying, as defined in TS 33.320 [53], that the identity used by the
HeNB is valid and determining whether the access mode of the HeNB is closed or not. In case of S1 PWS
RESTART INDICATION message and PWS FAILURE INDICATION message, verifying, as defined in TS
33.320 [53], that the indicated cell identity is valid and replacing the HeNB ID by the HeNB GW ID before
sending the PWS RESTART INDICATION message (respectively the PWS FAILURE INDICATION message)
to the MME.
3GPP
Release 17 42 3GPP TS 36.300 V17.2.0 (2022-09)
- Upon receiving an OVERLOAD START/STOP message, the HeNB GW should send the OVERLOAD
START/STOP message towards the HeNB(s) including in the message the identities of the affected MME
node. The HeNB uses this information received from the OVERLOAD START message to identify to which
traffic the above defined rejections shall be applied. The HeNB shall apply the defined rejections until
reception of an OVERLOAD STOP message applicable to this traffic, or until the HeNB receives a further
OVERLOAD START message applicable to the same traffic, in which case it shall replace the ongoing
overload action with the newly requested one.
NOTE: If a HeNB GW is deployed, non-UE associated procedures shall be run between HeNBs and the HeNB
GW and between the HeNB GW and the MME.
- Optionally terminating S1-U interface with the HeNB and with the S-GW.
- Supporting TAC and PLMN ID used by the HeNB.
- X2 interfaces shall not be established between the HeNB GW and other nodes.
- Routing the S1 PATH SWITCH REQUEST message towards the MME based on the GUMMEI of the source
MME received from the HeNB.
- Selection of an IP version to be used for S1-U, if a requested ERAB configuration contains two transport layer
addresses of different versions.
A list of CSG IDs may be included in the PAGING message. If included, the HeNB GW may use the list of CSG IDs
for paging optimisation.
The X2 GW hosts the following functions:
- routing the X2AP X2 MESSAGE TRANSFER message to target eNB or HeNB based on the routing
information received in the X2AP X2 MESSAGE TRANSFER message.
- informing the relevant (H)eNBs upon detecting that the signalling (i.e. SCTP) connection to a (H)eNB is
unavailable. The relevant (H)eNBs are the ones which had an "X2AP association" with this (H)eNB via the X2
GW when the signalling connection became unavailable.
- Mapping the TNL address(es) of a (H)eNB to its corresponding Global (H)eNB ID and maintaining the
association.
In addition to functions specified in clause 4.1, the MME hosts the following functions:
- Access control for UEs that are members of Closed Subscriber Groups (CSG):
- In case of handovers to CSG cells, access control is based on the target CSG ID of the selected target PLMN
provided to the MME by the serving E-UTRAN (see TS 23.401 [17]).
- Membership Verification for UEs handing over to hybrid cells:
- In case of handovers to hybrid cells the MME performs Membership Verification based on UE's selected
target PLMN, cell access mode related information and the CSG ID of the target cell provided by the source
E-UTRAN in S1 handover, or provided by the target E-UTRAN in X2 handover (see TS 23.401 [17]).
- Membership Verification for UEs for which the hybrid cell is served by an SeNB is described in clause 4.9.3.3.
- CSG membership status signalling to the E-UTRAN in case of attachment/handover to hybrid cells and in case
of the change of membership status when a UE is served by a CSG cell or a hybrid cell.
- Supervising the E-UTRAN action after the change in the membership status of a UE.
- In case of a HeNB directly connected:
- verifying as defined in TS 33.320 [53], that the identity used by the HeNB is valid when receiving the S1
SETUP REQUEST message and determining whether the access mode of the HeNB is closed or not;
- verifying as defined in TS 33.320 [53], for a closed HeNB, that the indicated cell access mode and CSG ID
are valid when receiving the S1 INITIAL UE MESSAGE message, the S1 PATH SWITCH REQUEST and
the S1 HANDOVER REQUEST ACKNOWLEDGE message;
3GPP
Release 17 43 3GPP TS 36.300 V17.2.0 (2022-09)
- and verifying, as defined in TS 33.320 [53], that the indicated HeNB identity is valid when receiving the S1
PWS RESTART INDICATION message and the S1 PWS FAILURE INDICATION message.
- Routing of handover messages, MME configuration transfer messages and MME Direct Information Transfer
messages towards HeNB GWs based on the TAI contained in these messages.
NOTE: If routing ambiguities are to be avoided, a TAI used in a HeNB GW should not be reused in another
HeNB GW.
NOTE: The MME or HeNB GW should not include the list of CSG IDs for paging when sending the paging
message directly to an un-trusted HeNB or eNB.
- The MME may support the LIPA function with HeNB. See details of this support in clause 4.6.5.
- The MME may support fixed Broadband Access network interworking with HeNB as specified in TS 23.139
[55].
- The MME may send two transport layer addresses of different versions only in case of HeNB GW which does
not terminate user plane.
4.6.3 Interfaces
4.6.3.1 Protocol Stack for S1 User Plane
The S1-U data plane is defined between the HeNB, HeNB GW and the S-GW. The figures below show the S1-U
protocol stack with and without the HeNB GW.
Figure 4.6.3.1-1: User plane for S1-U interface for HeNB without HeNB GW
Figure 4.6.3.1-2: User plane for S1-U interface for HeNB with HeNB GW
3GPP
Release 17 44 3GPP TS 36.300 V17.2.0 (2022-09)
The HeNB GW may optionally terminate the user plane towards the HeNB and towards the S-GW, and relay User
Plane data between the HeNB and the S-GW.
4.6.3.2 Protocol Stacks for S1 Control Plane

The two figures below show the S1-MME protocol stacks with and without the HeNB GW.
When the HeNB GW is not present (Fig. 4.6.3.2-1), all the S1-AP procedures are terminated at the HeNB and the
MME.
When present (Fig. 4.6.3.2-2), the HeNB GW shall terminate the non-UE-dedicated procedures – both with the HeNB,
and with the MME. The HeNB GW relays Control Plane data between the HeNB and the MME. The scope of any
protocol function associated to a non-UE-dedicated procedure shall be between HeNB and HeNB GW and/or between
HeNB GW and MME.
Any protocol function associated to an UE-dedicated-procedure shall reside within the HeNB and the MME only.
Figure 4.6.3.2-1: Control plane for S1-MME Interface for HeNB to MME without the HeNB GW
Figure 4.6.3.2-2: Control plane for S1-MME Interface for HeNB to MME with the HeNB GW
4.6.3.3 Protocol Stack for S5 interface

The protocol stack for the S5 interface can be found in TS 29.281 [47] for the user plane and in TS 29.274 [40] for the
control plane.
4.6.3.4 Protocol Stack for SGi interface

The protocol stack for the SGi interface can be found in TS 29.061 [41].
3GPP
Release 17 45 3GPP TS 36.300 V17.2.0 (2022-09)
4.6.3.5 Protocol Stack for X2 User Plane and X2 Control Plane

The protocol stack for X2 User Plane and X2 Control Plane is reported in clause 6.4 of TS 36.420 [46].
4.6.4 Void
4.6.5 Support of LIPA with HeNB
Figure 4.6.5-1 shows the logical architecture for the HeNB when it supports the LIPA function.
Figure 4.6.5-1: E-UTRAN - HeNB operating in LIPA mode - Logical Architecture
For a LIPA PDN connection, the HeNB sets up and maintains an S5 connection to the EPC.
The S5 interface does not go via the HeNB GW, even when present.
Requirements on the secure backhaul link for the S5 interface are specified in TS 33.320 [53].
The mobility of the LIPA PDN connection is not supported in this release of the specification. The LIPA connection is
always released at outgoing handover as described in TS 23.401 [17]. The L-GW function in the HeNB triggers this
release over the S5 interface.
In case of LIPA support, the HeNB supports the following additional functions, regardless of the presence of a HeNB
GW:
- transfer of the collocated L-GW IP address of the HeNB over S1-MME to the EPC at every idle-active
transition;
- transfer of the collocated L-GW IP address of the HeNB over S1-MME to the EPC within every Uplink NAS
Transport procedure;
- support of basic P-GW functions in the collocated L-GW function such as support of the SGi interface
corresponding to LIPA;
- additional support of first packet sending, buffering of subsequent packets, internal direct L-GW - HeNB user
path management and in sequence packet delivery to the UE;
- support of the necessary restricted set of S5 procedures corresponding to the strict support of LIPA function as
specified in TS 23.401 [17];
3GPP
Release 17 46 3GPP TS 36.300 V17.2.0 (2022-09)
- notification to the EPC of the collocated L-GW uplink TEID(s) or GRE key(s) for the LIPA bearer(s) over S5
interface within the restricted set of procedures to be forwarded over S1-MME and further used by the HeNB as
"correlation id" for correlation purposes between the collocated L-GW function and the HeNB;
- in case of outgoing handover triggering the L-GW function to release the LIPA PDN connection and only
handing over the non-LIPA E-RABs.
In case of LIPA support, the MME may support the following additional functions:
- verification of UE authorization to request LIPA activation for the requested APN at this CSG and transfer of the
received collocated L-GW IP address;
- transfer of the "correlation id" i.e. collocated L-GW uplink TEID or GRE key to the HeNB within the UE
context setup procedure and E-RAB setup procedure;
- verification of whether the LIPA PDN connection has been released during the handover procedure, as specified
in TS 23.401 [17];
- deactivation of the LIPA PDN connection of an idle-mode UE if it detects that the UE has moved out of the
coverage area of the HeNB collocated with L-GW function, as specified in TS 23.401 [17].
4.6.6 Support of X2 GW
Figure 4.6.6-1 shows the logical architecture when X2-connectivity via the X2 GW is supported.
Figure 4.6.6-1: E-UTRAN operating with X2 GW - Logical Architecture
Support for the X2 GW relies on following principles:
- A HeNB connects to a single X2 GW only. Each HeNB is preconfigured with information about which X2 GW
it connects to, e.g. an IP address of the X2 GW.
- There is no limitation on the number of X2 GWs an eNB may connect to.
- The X2 GW does not terminate X2AP procedures except for the X2AP Message Transfer procedure, but it
initiates the X2 Release procedure and the X2 Error Indication procedure.
3GPP
Release 17 47 3GPP TS 36.300 V17.2.0 (2022-09)
- This version of the specification does not support an interface between two X2 GWs. The routing of X2AP
messages via more than one X2 GW (i.e. more than two SCTP hops) is not allowed.
- X2AP contexts only exist in the two peer (H)eNBs (same as without X2 GW). The peer X2AP contexts define
an "X2AP association" between peer (H)eNBs which spans over two SCTP associations (one per each hop).
- The X2 GW puts no constraints on the X2 user plane interface (X2-U).
- For each (H)eNB connected to the X2 GW, the X2 GW maintains the association information, i.e. the mapping
of the Global eNB ID to the TNL address(es). The registration procedure, described in Sec. 4.6.6.4, is used to
update the association information in the X2 GW.
4.6.6.1 Enhanced TNL Address Discovery

In case of Enhanced TNL Address Discovery is used with the X2 GW, in addition to the procedures specified in clause
22.3.6.1, the following also applies.
- During HeNB initiated Enhanced TNL address discovery procedure, the HeNB may include the IP address of the
X2 GW to which the HeNB connected in the eNB CONFIGURATION TRANSFER message thus indicating its
X2 GW support capability. Upon the reception of the IP address of the X2 GW, the candidate eNB may include
in its reply the received IP address of the X2 GW thus indicating the support of indirect X2 via the indicated X2
GW.
- During the eNB or HeNB initiated Enhanced TNL address discovery procedure towards an HeNB, the candidate
HeNB may include in its reply the IP address of the X2 GW to which the candidate HeNB connected thus
indicating the support of indirect X2 via the indicated X2 GW.
4.6.6.2 Routing of X2AP messages

When a (H)eNB sends an X2AP message (except the X2AP X2 MESSAGE TRANSFER message) to a peer node via
the X2 GW, the (H)eNB encapsulates the X2AP message in an X2AP X2 MESSAGE TRANSFER message, adds the
routing information, then sends the X2AP X2 MESSAGE TRANSFER message to the X2 GW. The routing
information includes both Target (H)eNB ID and source (H)eNB ID. The X2 GW routes the message based on the
target (H)eNB ID. The source (H)eNB ID is used by the destination (H)eNB node to reply.
4.6.6.3 (H)eNB unavailability

Upon the detection that the signalling (i.e. SCTP) connection to a (H)eNB is unavailable, the X2 GW initiates the X2
Release procedure to inform the relevant (H)eNBs. The relevant (H)eNBs are the ones which had an "X2AP
association" with this (H)eNB via the X2 GW when the signalling connection became unavailable.
4.6.6.4 (H)eNB registration

Registration of a (H)eNB is performed by initiating the X2AP Message Transfer procedure towards the X2 GW
signalling a Source (H)eNB ID, no Target (H)eNB ID, and no X2AP Message in the X2AP MESSAGE TRANSFER
message. Upon receipt of this message, the X2 GW saves the association information, i.e. the mapping of the received
Global eNB ID to the TNL address(es) of the originating (H)eNB.
4.7 Support for relaying

4.7.1 General
E-UTRAN supports relaying by having a Relay Node (RN) wirelessly connect to an eNB serving the RN, called Donor
eNB (DeNB), via a modified version of the E-UTRA radio interface, the modified version being called the Un interface.
The RN supports the eNB functionality meaning it terminates the radio protocols of the E-UTRA radio interface, and
the S1 and X2 interfaces. From a specification point of view, functionality defined for eNBs, e.g. RNL and TNL, also
applies to RNs unless explicitly specified. RNs do not support NNSF.
In addition to the eNB functionality, the RN also supports a subset of the UE functionality, e.g. physical layer, layer-2,
RRC, and NAS functionality, in order to wirelessly connect to the DeNB.
NOTE: Inter-cell handover of the RN is not supported.
3GPP
Release 17 48 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE: It is up to implementation when the RN starts or stops serving UEs.
NOTE: An RN may not use another RN as its DeNB.
4.7.2 Architecture
The architecture for supporting RNs is shown in Figure 4.7.2-1. The RN terminates the S1, X2 and Un interfaces. The
DeNB provides S1 and X2 proxy functionality between the RN and other network nodes (other eNBs, MMEs and
S-GWs). The S1 and X2 proxy functionality includes passing UE-dedicated S1 and X2 signalling messages as well as
GTP data packets between the S1 and X2 interfaces associated with the RN and the S1 and X2 interfaces associated
with other network nodes. Due to the proxy functionality, the DeNB appears as an MME (for S1-MME), an eNB (for
X2) and an S-GW (for S1-U) to the RN.
In phase II of RN operation (see clause 4.7.6.3), the DeNB also embeds and provides the S-GW/P-GW-like functions
needed for the RN operation. This includes creating a session for the RN and managing EPS bearers for the RN, as well
as terminating the S11 interface towards the MME serving the RN.
The RN and DeNB also perform mapping of signalling and data packets onto EPS bearers that are setup for the RN.
The mapping is based on existing QoS mechanisms defined for the UE and the P-GW.
In phase II of RN operation (see clause 4.7.6.3), the P-GW functions in the DeNB allocate an IP address for the RN for
the O&M which may be different than the S1 IP address of the DeNB.
If the RN address is not routable to the RN O&M domain, it shall be reachable from the RN O&M domain (e.g. via
NAT).
Figure 4.7.2-1: Overall E-UTRAN Architecture supporting RNs
4.7.3 S1 and X2 user plane aspects

The S1 user plane protocol stack for supporting RNs is shown in Figure 4.7.3-1. There is a GTP tunnel associated with
each UE EPS bearer, spanning from the S-GW associated with the UE to the DeNB, which is switched to another GTP
tunnel in the DeNB, going from the DeNB to the RN (one-to-one mapping).
The X2 user plane protocol stack for supporting RNs is shown in Figure 4.7.3-2. There is a GTP forwarding tunnel
associated with each UE EPS bearer subject to forwarding, spanning from the other eNB to the DeNB, which is
switched to another GTP tunnel in the DeNB, going from the DeNB to the RN (one-to-one mapping).
The S1 and X2 user plane packets are mapped to radio bearers over the Un interface. The mapping can be based on the
QCI associated with the UE EPS bearers. UE EPS bearer with similar QoS can be mapped to the same Un radio bearer.
3GPP
Release 17 49 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 4.7.3-1: S1 user plane protocol stack for supporting RNs
Figure 4.7.3-2: X2 user plane protocol stack for supporting RNs
4.7.4 S1 and X2 control plane aspects

The S1 control plane protocol stack for supporting RNs is shown in Figure 4.7.4-1. There is a single S1 interface
relation between each RN and its DeNB, and there is one S1 interface relation between the DeNB and each MME in the
MME pool. The DeNB processes and forwards all S1 messages between the RN and the MMEs for all UE-dedicated
procedures. The processing of S1-AP messages includes modifying S1-AP UE IDs, Transport Layer address and GTP
TEIDs but leaves other parts of the message unchanged.
All non-UE-dedicated S1-AP procedures are terminated at the DeNB, and handled locally between the RN and the
DeNB, and between the DeNB and the MME(s). Upon reception of an S1 non-UE-dedicated message from an MME,
the DeNB may trigger corresponding S1 non-UE-dedicated procedure(s) to the RN(s). If more than one RN is involved,
the DeNB may wait and aggregate the response messages from all involved RNs before responding to the MME. Upon
reception of an S1 non-UE-dedicated message from an RN, the DeNB may trigger associated S1 non-UE-dedicated
procedure(s) to the MME(s). In case of the RESET procedure, the DeNB does not need to wait for the response
message(s) from the MME(s) or RN(s) before responding with the RESET ACKNOWLEDGE message to the
originating node. Upon reception of a PAGING message, the DeNB sends the PAGING message toward the RN(s)
which support any tracking area(s) indicated in the List of TAIs. Upon reception of an S1 MME overload
START/STOP message, the DeNB sends the MME overload START/STOP message towards the RN(s), including in
the message the identities of the affected CN node. The RN uses this information received from the OVERLOAD
START message to identify to which traffic the above defined rejections shall be applied. The RN shall apply the
defined rejections until reception of an OVERLOAD STOP message applicable to this traffic, or until the RN receives a
further OVERLOAD START message applicable to the same traffic, in which case it shall replace the ongoing overload
action with the newly requested one. Upon reception of the GUMMEI from a UE, the RN shall include it in the
INITIAL UE MESSAGE message; upon reception of the GUMMEI Type from the UE, the RN shall also include it in
the message.
The X2 control plane protocol stack for supporting RNs is shown in Figure 4.7.4-2. There is a single X2 interface
relation between each RN and its DeNB. In addition, the DeNB may have X2 interface relations to neighbouring eNBs.
The DeNB processes and forwards all X2 messages between the RN and other eNBs for all UE-dedicated procedures.
The processing of X2-AP messages includes modifying S1/X2-AP UE IDs, Transport Layer address and GTP TEIDs
but leaves other parts of the message unchanged.
3GPP
Release 17 50 3GPP TS 36.300 V17.2.0 (2022-09)
All non-UE-dedicated X2-AP procedures are terminated at the DeNB, and handled locally between the RN and the
DeNB, and between the DeNB and other eNBs. Upon reception of an X2 non cell related non-UE-associated message
from RN or neighbour eNB, the DeNB may trigger associated non-UE-dedicated X2-AP procedure(s) to the neighbour
eNB or RN(s). Upon reception of an X2 cell related non-UE-dedicated message from RN or neighbour eNB, the DeNB
may pass associated information to the neighbour eNB or RN(s) based on the included cell information. If one or more
RN(s) are involved, the DeNB may wait and aggregate the response messages from all involved nodes to respond to the
originating node. Further, parallel Cell Activation procedures are not allowed on each X2 interface instance. The
processing of Resource Status Reporting Initiation/ Resource Status Reporting messages includes modification of
measurement ID.
The S1 and X2 interface signalling packets are mapped to radio bearers over the Un interface.
Figure 4.7.4-1: S1 control plane protocol stack for supporting RNs
Figure 4.7.4-2: X2 control plane protocol stack for supporting RNs
4.7.5 Radio protocol aspects

The RN connects to the DeNB via the Un interface using the same radio protocols and procedures as a UE connecting
to an eNB. The control plane protocol stack is shown in Figure 4.7.5-1 and the user plane protocol stack is shown in
Figure 4.7.5-2.
The following relay-specific functionalities are supported:
- the RRC layer of the Un interface has functionality to configure and reconfigure an RN subframe configuration
through the RN reconfiguration procedure (e.g. DL subframe configuration and an RN-specific control channel)
for transmissions between an RN and a DeNB. The RN may request such a configuration from the DeNB during
the RRC connection establishment, and the DeNB may initiate the RRC signalling for such configuration. The
RN applies the configuration immediately upon reception;
NOTE: The RN subframe configuration on the Un interface can be temporarily misaligned with the MBSFN
subframes configured in the RN cell due to the RN subframe configuration; i.e. a new subframe
configuration can be applied earlier by the RN on Un than in the RN cell.
- the RRC layer of the Un interface has functionality to send updated system information in a dedicated message
to an RN with an RN subframe configuration. The RN applies the received system information immediately;
3GPP
Release 17 51 3GPP TS 36.300 V17.2.0 (2022-09)
- the PDCP layer of the Un interface has functionality to provide integrity protection for the user plane. The
integrity protection is configured per DRB.
To support PWS towards UEs, the RN receives the relevant information over S1. The RN should hence ignore DeNB
system information relating to PWS.
Figure 4.7.5-1: Radio control plane protocol stack for supporting RNs
Figure 4.7.5-2: Radio user plane protocol stack for supporting RNs
4.7.6 Signalling procedures

4.7.6.1 RN attach procedure
Figure 4.7.6.1-1 shows a simplified version of the attach procedure for the RN. The procedure is the same as the normal
UE attach procedure TS 23.401 [17] with the exception that:
- The DeNB has been made aware of which MMEs support RN functionality via the S1 Setup Response message
earlier received from the MMEs;
- The RN sends an RN indication to the DeNB during RRC connection establishment;
- After receiving the RN indication from the RN, the DeNB sends the RN indicator and the IP address of the
S-GW/P-GW function embedded in the DeNB, within the Initial UE Message, to an MME supporting RN
functionality;
- MME selects S-GW/P-GW for the RN based on the IP address included in the Initial UE Message;
- During the attach procedure, the EPC checks if the RN is authorised for relay operation; only if the RN is
authorised, the EPC accepts the attach and sets up a context with the DeNB; otherwise the EPC rejects the attach.
The RN is preconfigured with information about which cells (DeNBs) it is allowed to access.
3GPP
Release 17 52 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 4.7.6.1-1: RN attach procedure
4.7.6.2 E-RAB activation/modification

Figure 4.7.6.2-1 shows a simplified version of the DeNB-initiated bearer activation/modification procedure. This
procedure can be used by the DeNB to change the EPS bearer allocation for the RN. The procedure is the same as the
normal network-initiated bearer activation/modification procedure TS 23.401 [17] with the exception that the S-
GW/P-GW functionality (steps 1 and 6) is performed by the DeNB.
Figure 4.7.6.2-1: DeNB-initiated bearer activation/modification procedure
4.7.6.3 RN startup procedure

Figure 4.7.6.3-1 shows a simplified version of the startup procedure for the RN. The procedure is based on the normal
UE attach procedure TS 23.401 [17] and it consists of the following two phases:
I. Phase I: Attach for RN preconfiguration.

The RN attaches to the E-UTRAN/EPC as a UE at power-up and retrieves initial configuration parameters,
including the list of DeNB cells, from RN OAM. After this operation is complete, the RN detaches from the
network as a UE and triggers Phase II. The MME performs the S-GW and P-GW selection for the RN as a
normal UE.
II. Phase II: Attach for RN operation.

The RN connects to a DeNB selected from the list acquired during Phase I to start relay operations. For this
purpose, the normal RN attach procedure described in clause 4.7.6.1 is applied. After the DeNB initiates setup of
3GPP
Release 17 53 3GPP TS 36.300 V17.2.0 (2022-09)
bearer for S1/X2, the RN initiates the setup of S1 and X2 associations with the DeNB (see clause 4.7.4). In
addition, the DeNB may initiate an RN reconfiguration procedure via RRC signalling for RN-specific
parameters.
After the S1 setup, the DeNB performs the S1 eNB Configuration Update procedure(s), if the configuration data
for the DeNB is updated due to the RN attach. After the X2 setup, the DeNB performs the X2 eNB
Configuration Update procedure(s) to update the cell information.
In this phase the RN cells' ECGIs are configured by RN OAM.
Figure 4.7.6.3-1: RN startup procedure
4.7.6.4 RN detach procedure

Figure 4.7.6.4-1 shows a simplified version of the detach procedure for the RN operation in case no UE is connected to
the RN cells.
1. The detach procedure is the same as the normal UE detach procedure TS 23.401 [17].
2. The DeNB performs the X2 eNB Configuration Update procedure(s) to update the cell information.
3 The DeNB performs the S1 eNB Configuration Update procedure(s), if the configuration data for the DeNB is
updated due to the RN detach.
3GPP
Release 17 54 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 4.7.6.4-1: RN detach procedure
4.7.6.5 Neighbouring Information Transfer

The X2 eNB Configuration Update procedure (see clause 20.2.2.8) is used by the DeNB to also transfer application
level configuration data of a single neighbouring eNB to the RN. Upon reception of an ENB CONFIGURATION
UPDATE message, if the served cells contained in the message belong to the neighbour eNB rather than the DeNB, the
RN shall regard the X2 interface between DeNB and the neighbour eNB as available. The RN will update the X2
availability, the corresponding GU Group ID and other information of the neighbour eNB according to the message.
4.7.6.6 Mobility to or from RN

In case of Handover between RN and neighbour eNB, in addition to the procedures specified in clause 10.1.2.1.1, the
following also applies.
- The DeNB may inform the RN of any GUMMEI of the UE's serving MME in the INITIAL CONTEXT SETUP
REQUEST and S1 HANDOVER REQUEST messages. Considering this information as well as the GU Group
ID of the neighbour eNB and the X2 interface availability between DeNB and neighbour eNB, the RN initiates
either S1 or X2 handover for the UE. In case the GUMMEI information is not available to the RN, the RN
attempts X2 handover for the UE (see clause 19.2.2.5); upon X2 handover failure, S1 handover may be initiated.
- The S1/X2 HANDOVER REQUEST is received by the DeNB, which reads the target cell ID from the message,
finds the target node corresponding to the target cell ID, and forwards the message toward the target node if
appropriate.
4.7.7 Relay Node OAM Aspects

4.7.7.1 Architecture
Each RN sends alarms and traffic counter information to its OAM system, from which it receives commands,
configuration data and software downloads (e.g. for equipment software upgrades). This transport connection between
each RN and its OAM, using IP, is provided by the DeNB; the reference architecture is shown in Figure 4.7.7.1-1. RN
OAM traffic is transported over the Un interface, and it shares resources with the rest of the traffic, including UEs
attached to the DeNB. The secure connection between the RN and its OAM may be direct or hop-by-hop, i.e. involving
intermediate hops trusted by the operator for this purpose.
3GPP
Release 17 55 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 4.7.7.1-1: Relay OAM architecture.
It has to be noted that Figure 4.7.7.1-1 refers to normal operating conditions for the RN, i.e. after the initial start-up
phase has been completed. The case where the secure connection between the RN and the OAM does not go through the
DeNB, e.g. during the initial start-up phase, is not precluded.
4.7.7.2 OAM Traffic QoS Requirements

Alarms in the RN generate bursts of high-priority traffic, to be transported in real time. Traffic counters generate bursts
of traffic, but their transport need not be real-time. Configuration messages from OAM to the RN will also generate
small bursts of traffic, possibly with lower priority than alarms but still delay-sensitive: when a configuration is
committed on the OAM, the time interval between the commitment and the effect on the equipment shall be small.
Alarm messages and commands should be transported on a high-priority bearer, while counters may be transported on a
lower priority bearer. There is no need to specify a new QCI value other than those already standardized.
Alarm messages and commands may be mapped over a dedicated bearer or over the same bearer that carries S1 and/or
X2 messages between the RN and the DeNB.
OAM software download to the RN may generate larger amounts of data, but both the required data rate and the priority
of this kind of traffic are much lower than in the case of alarms, commands and counters. OAM software downloads
may be mapped to a dedicated, non-GBR bearer, or transported together with the user plane traffic. If a dedicated bearer
is used, it is FFS whether it shall be present at all times, or its setup should be event-triggered (software upgrades are
triggered by the operator).
4.7.7.3 Security Aspects

Refer to clause D.2.5 of TS 33.401 [22] for details on secure management procedures for RN.
4.7.7.4 Void
4.7.7.5 OAM Requirements for Configuration Parameters
4.7.7.5.1 Parameters Associated with Relay Bearer Mapping
OAM provides the appropriate support to configure a QCI-to-DSCP mapping function at the relay node which is used
to control the mapping in uplink of Uu bearer(s) of different QCI(s) to Un bearer(s).
4.8 Support of SIPTO at the Local Network

4.8.1 General
E-UTRAN supports SIPTO at the Local Network with a collocated L-GW in the eNB or a standalone GW (with S-GW
and L-GW collocated), as specified in TS 23.401 [17].
4.8.2 SIPTO at the Local Network with collocated L-GW

Figure 4.8.2-1 shows the logical architecture for the eNB when it supports SIPTO@LN with a collocated L-GW.
3GPP
Release 17 56 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 4.8.2-1: E-UTRAN - SIPTO@LN with collocated L-GW - Logical Architecture
For a SIPTO@LN PDN connection, the eNB sets up and maintains an S5 connection to the EPC.
The mobility of the SIPTO@LN PDN connection is not supported in this release of the specification. The SIPTO@LN
PDN connection is released after a handover is performed, and the collocated L-GW in the source eNB triggers the
release over the S5 interface, as described in TS 23.401 [17].
In case of SIPTO@LN with collocated L-GW support, the eNB supports the following additional functions:
- transfer of the collocated L-GW IP address of the eNB over S1-MME to the EPC at every idle-active transition;
- transfer of the collocated L-GW IP address of the eNB over S1-MME to the EPC within every Uplink NAS
Transport procedure;
- support of basic P-GW functions in the collocated L-GW such as support of the SGi interface corresponding to
SIPTO@LN;
- additional support of first packet sending, buffering of subsequent packets, internal direct L-GW-eNB user path
management and in sequence packet delivery to the UE;
- support of the necessary restricted set of S5 procedures corresponding to the support of SIPTO@LN function as
specified in TS 23.401 [17];
- notification to the EPC of the collocated L-GW uplink TEID(s) or GRE key(s) for the SIPTO@LN bearer(s)
over S5 interface within the restricted set of procedures to be forwarded over S1-MME and further used by the
eNB as "SIPTO correlation id" for correlation purposes between the collocated L-GW and the eNB;
- triggering SIPTO@LN PDN connection release by the collocated L-GW after a handover is performed, as
specified in TS 23.401 [17].
In case of SIPTO@LN with collocated L-GW support, the MME supports the following additional functions:
- SIPTO@LN activation for the requested APN based on SIPTO permissions in the subscription data and received
collocated L-GW IP address;
- transfer of the "SIPTO correlation id" to the eNB via the initial context setup procedure and E-RAB setup
procedure;
- release of the SIPTO@LN PDN connection of an idle-mode UE when the UE moves away from the coverage
area of the eNB, as specified in TS 23.401 [17].
3GPP
Release 17 57 3GPP TS 36.300 V17.2.0 (2022-09)
4.8.3 Support for SIPTO@LN with Stand-Alone Gateway

SIPTO@LN is supported using a stand-alone gateway (with co-located S-GW and L-GW) deployed in the local
network. The MME may decide to trigger S-GW relocation without UE mobility, as specified in TS 23.401 [17].
Mobility for the SIPTO@LN PDN connection is not supported in this release: the SIPTO@LN PDN connection shall be
released after handover, unless the source and target eNBs are in the same LHN (i.e. they have the same LHN ID), as
In case of SIPTO@LN support with stand-alone gateway, the eNB supports the following additional functions:
- signalling of its LHN ID to the MME in the INITIAL UE MESSAGE, UPLINK NAS TRANSPORT,
HANDOVER NOTIFY and PATH SWITCH REQUEST messages;
- support for MME-triggered S-GW relocation without UE mobility through the E-RAB MODIFY REQUEST
message.
In case of SIPTO@LN support with stand-alone gateway, the MME supports the following additional functions:
- SIPTO@LN PDN activation for the requested APN based on subscription data and received LHN ID;
- S-GW relocation without UE mobility.
4.9 Support for Dual Connectivity

4.9.1 General
E-UTRAN supports Dual Connectivity (DC) operation whereby a multiple Rx/Tx UE in RRC_CONNECTED is
configured to utilise radio resources provided by two distinct schedulers, located in two eNBs connected via a non-ideal
backhaul over the X2 interface (see TR 36.842 [59] and TR 36.932 [60]). The overall E-UTRAN architecture as
specified in clause 4 and depicted in Figure 4-1 is applicable for DC as well. eNBs involved in DC for a certain UE may
assume two different roles: an eNB may either act as an MeNB or as an SeNB. In DC a UE is connected to one MeNB
and one SeNB.
NOTE: This clause only concerns intra-E-UTRAN DC. Dual connectivity between E-UTRAN and NR is
4.9.2 Radio Protocol Architecture

In DC, the radio protocol architecture that a particular bearer uses depends on how the bearer is setup. Three bearer
types exist: MCG bearer, SCG bearer and split bearer. Those three bearer types are depicted on Figure 4.9.2-1 below.
RRC is located in MeNB and SRBs are always configured as MCG bearer type and therefore only use the radio
resources of the MeNB.
NOTE: DC can also be described as having at least one bearer configured to use radio resources provided by the
SeNB.
Figure 4.9.2-1: Radio Protocol Architecture for Dual Connectivity
3GPP
Release 17 58 3GPP TS 36.300 V17.2.0 (2022-09)
4.9.3 Network Interfaces

4.9.3.1 E-UTRAN Control Plane for Dual Connectivity
Inter-eNB control plane signalling for DC is performed by means of X2 interface signalling. Control plane signalling
towards the MME is performed by means of S1 interface signalling.
There is only one S1-MME connection per DC UE between the MeNB and the MME. Each eNB should be able to
handle UEs independently, i.e. provide the PCell to some UEs while providing SCell(s) for SCG to others. Each eNB
involved in DC for a certain UE controls its radio resources and is primarily responsible for allocating radio resources
of its cells. Respective coordination between MeNB and SeNB is performed by means of X2 interface signalling.
Figure 4.9.3.1-1 shows C-plane connectivity of eNBs involved in DC for a certain UE: the S1-MME is terminated in
MeNB and the MeNB and the SeNB are interconnected via X2-C.
Figure 4.9.3.1-1: C-Plane connectivity of eNBs involved in Dual Connectivity
4.9.3.2 E-UTRAN User Plane for Dual Connectivity

For dual connectivity two different user plane architectures are allowed: one in which the S1-U only terminates in the
MeNB and the user plane data is transferred from MeNB to SeNB using the X2-U, and a second architecture where the
S1-U can terminate in the SeNB. Figure 4.9.3.2-1 shows different U-plane connectivity options of eNBs involved in DC
for a certain UE.
Different bearer options can be configured with different user plane architectures. U-plane connectivity depends on the
bearer option configured:
- For MCG bearers, the S1-U connection for the corresponding bearer(s) to the S-GW is terminated in the MeNB.
The SeNB is not involved in the transport of user plane data for this type of bearer(s) over the Uu.
- For split bearers, the S1-U connection to the S-GW is terminated in the MeNB. PDCP data is transferred
between the MeNB and the SeNB via X2-U. The SeNB and MeNB are involved in transmitting data of this
bearer type over the Uu.
- For SCG bearers, the SeNB is directly connected with the S-GW via S1-U. The MeNB is not involved in the
transport of user plane data for this type of bearer(s) over the Uu.
3GPP
Release 17 59 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 4.9.3.2-1: U-Plane connectivity of eNBs involved in Dual Connectivity
NOTE: if only MCG and split bearers are configured, there is no S1-U termination in the SeNB.
4.9.3.3 Support of HeNBs for Dual Connectivity

The following scenarios for Dual Connectivity involving HeNBs are supported as listed in Table 4.9.3.3-1.
Table 4.9.3.3-1: Support of HeNBs for Dual Connectivity
MeNB SeNB
eNB open access HeNB
eNB hybrid access HeNB
Membership Verification for the hybrid access HeNB is performed between the MeNB and the MME and is based on
membership status information reported by the UE and the CSG ID.
If the cell served by the SeNB is a shared hybrid cell, the UE reports the subset of the broadcasted PLMN identities
passing PLMN ID check and the Permitted CSG list of the UE includes an entry comprising of the concerned PLMN
identity and the CSG ID broadcast by the cell served by the SeNB. The MeNB performs PLMN ID check for the
PLMNs reported by the UE and selects one if multiple pass the PLMN ID check. If the cell served by the SeNB belongs
to a different PLMN than the PLMN serving for the UE in the MeNB, the information provided to the MME for
membership verification needs to contain the PLMN-ID of the hybrid cell served by the SeNB as well. Finally the
MME verifies the CSG membership according to the received CSG ID, the selected PLMN ID and stored subscription
CSG information of the UE.
In case the UE has been admitted with SCG resources configured with the split bearer option from a hybrid HeNB and a
SeNB Change is performed within the coverage area of the MeNB towards another hybrid HeNB which has the same
CSG ID as the first one, the MeNB may re-use the result of the membership verification performed for the first HeNB.
4.9.3.4 Support of SIPTO@LN and LIPA for Dual Connectivity

This version of the specification supports SIPTO@LN and LIPA for Dual Connectivity according to the following
logical architecture:
- SIPTO@LN with co-located L-GW in the MeNB. The MeNB and the MME support the functions described in
clause. 4.8.2 with the following change:
- For SCG bearer option, the MeNB sets GTP TEID and Transport Layer Address in S1 UL GTP Tunnel Endpoint
IE in the SENB ADDITION REQUEST message and SENB MODIFICATION REQUEST messages as the
correlation ID received from the MME and the IP address of the collocated L-GW respectively.
3GPP
Release 17 60 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 4.9.3.4-1: SIPTO@LN with co-located L-GW in MeNB – split and SCG bearer options.
- SIPTO@LN with co-located L-GW in the SeNB. For this scenario, only the SCG bearer option is supported for
the SIPTO bearer. The SeNB signals its L-GW IP address using the SeNB Addition Preparation procedure, or
the MeNB obtains such address via OAM. The MeNB signals the "SIPTO correlation id" to the SeNB using the
SeNB Addition Preparation and SeNB Modification Preparation procedures. The functions described in clause
4.8.2 are supported with the following changes:
- The MeNB supports the transfer of the L-GW IP address of SeNB over S1-MME to the EPC within every
Uplink NAS Transport procedure;
- The SeNB supports basic P-GW functions in the collocated L-GW such as support of the SGi interface
corresponding to SIPTO@LN;
- Additional support by the SeNB of first packet sending, buffering of subsequent packets, internal direct L-
GW-eNB user path management and in sequence packet delivery to the UE;
- The SeNB supports the necessary restricted set of S5 procedures corresponding to the support of SIPTO@LN
function as specified in TS 23.401 [17];
- The MeNB supports the notification to the EPC of the L-GW uplink TEID(s) or GRE key(s) for the
SIPTO@LN bearer(s) over S5 interface within the restricted set of procedures to be forwarded over S1-MME
and further used as "SIPTO correlation id" for correlation purposes between the L-GW and the SeNB;
- The SeNB supports triggering SIPTO@LN PDN connection release by the collocated L-GW after an SeNB
change or MeNB to eNB handover is performed.
Figure 4.9.3.4-2: SIPTO@LN with co-located L-GW in SeNB
- SIPTO@LN with stand-alone gateway: the MeNB and the SeNB belong to the same LHN (i.e. they have the
same LHN ID). The MeNB and the SeNB exchange their LHN ID using the X2 Setup procedure or via OAM.
The MeNB initiates the SeNB Modification Preparation procedure in order to support the MME-triggered S-GW
relocation without UE mobility. The MeNB and the MME support the functions described in Sec. 4.8.3.
3GPP
Release 17 61 3GPP TS 36.300 V17.2.0 (2022-09)
- LIPA: the logical architectures for LIPA correspond to the logical architectures for SIPTO@LN with co-located
L-GW in the SeNB.
- Before handover, the MeNB shall initiate the SeNB Modification Preparation procedure or the UE Context
Release procedure to release radio and control plane related resources associated to the LIPA bearer.
4.10 NB-IoT
NB-IoT provides access to network services using physical layer optimized for very low power consumption (e.g. full
carrier bandwidth is 180 kHz, subcarrier spacing can be 3.75 kHz or 15 kHz).
As indicated in the relevant clauses in this specification, a number of E-UTRA protocol functions supported by all Rel-8
UEs are not used for NB-IoT and need not be supported by eNBs and UEs only using NB-IoT.
In this version of the specification, a number of functions including inter-RAT mobility, handover, measurement
reports, public warning functions, GBR, CSG, support of HeNBs, relaying, carrier aggregation, dual connectivity,
NAICS, real-time services, interference avoidance for in-device coexistence, RAN assisted WLAN interworking,
sidelink communication/discovery, V2X sidelink communication, MDT, emergency call, CS fallback, ACB, EAB,
ACDC, SSAC, aerial UE Communication, EN-DC and RRC_INACTIVE are not supported for NB-IoT. This is not
further stated in the corresponding procedures.
4.11 Support for UE assistance information for local cache

UE assisted local cache is a solution to address long backhaul latency issue. The UE is allowed to transmit assistance
information bit to eNB to enable the eNB to identify whether an uplink data needs to be transferred to the local cache
entity, which may be co-sited with eNB or has direct connection with eNB, by operator implementation.
UE can report to the network its capability of supporting assistance information bit for local cache. If supported, the UE
assisted local cache function can be activated by the eNB. After that, the UE may indicate the assistance information bit
in the uplink PDCP PDU. Whether the UE indicates this assistance information bit is based on for instance the service
from the application layer the UE requests that support local cache handling.
4.12 Support of Non-Terrestrial Networks

E-UTRAN supports radio access over non-terrestrial networks for BL UEs, UEs in enhanced coverage and NB-IoT
UEs. Support for non-terrestrial networks encompasses platforms that provide radio access through Geosynchronous
orbits (GSO), Non-Geosynchronous Orbit (NGSO), which includes Low-Earth Orbit (LEO) and Medium Earth Orbit
(MEO) or High Altitude Platform Systems (HAPS).
The Figure 4.12-1 below illustrates an example of a Non-Terrestrial Network (NTN) providing non-terrestrial access by
means of an NTN payload and an NTN Gateway, depicting a service link between the NTN payload and a UE, and a
feeder link between the NTN Gateway and the NTN payload.
3GPP
Release 17 62 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 4.12-1: Overall illustration of an NTN
NOTE: Figure 4.12-1 illustrates an NTN; RAN4 aspects are out of scope.
The NTN payload transparently forwards the radio protocol received from the UE (via the service link) to the NTN
Gateway (via the feeder link) and vice-versa. The following connectivity is supported by the NTN payload:
- An eNB may serve multiple NTN payloads;
- An NTN payload may be served by multiple eNBs.
NOTE: In this release, the NTN-payload may change the carrier frequency, before re-transmitting it on the
service link, and vice versa (respectively on the feeder link).
For NTN, the following applies in addition to Network entity related Identities as described in clause 8.2:
- A Tracking Area corresponds to a fixed geographical area. Any respective mapping is configured in the RAN;
- A Mapped Cell ID as specified in clause 23.21.5.
Three types of service links are supported:
- Earth-fixed: provisioned by beam(s) continuously covering the same geographical areas all the time (e.g., the
case of GSO satellites);
- Quasi-Earth-fixed: provisioned by beam(s) covering one geographic area for a limited period of time and a
different geographic area during another period of time (e.g., the case of NGSO satellites generating steerable
beams);
- Earth-moving: provisioned by beam(s) whose coverage area slides over the Earth surface (e.g., the case of
NGSO satellites generating fixed or non-steerable beams).
With NGSO satellites, the eNB can provide either quasi-Earth-fixed cell coverage or Earth-moving cell coverage, while
eNB operating with GSO satellites can provide Earth fixed cell coverage or quasi-Earth-fixed cell coverage.
3GPP
Release 17 63 3GPP TS 36.300 V17.2.0 (2022-09)
5 Physical Layer for E-UTRA

5.0 Frame structures and channels
Downlink and uplink transmissions are organized into radio frames with 10 ms duration. Three radio frame structures
are supported:
- Type 1, applicable to FDD;
- Type 2, applicable to TDD;
- Type 3, applicable to LAA secondary cell operation only.
Frame structure Type 1 is illustrated in Figure 5.1-1. Each 10 ms radio frame is divided into ten equally sized sub-
frames. Each sub-frame consists of two equally sized slots. Each slot can further be divided into three subslots that may
have different sizes. For FDD, 10 subframes, 20 slots, or up to 60 subslots are available for downlink and uplink
transmission in each 10 ms interval. Uplink and downlink transmissions are separated in the frequency domain.
Figure 5.1-1: Frame structure type 1
Frame structure Type 2 is illustrated in Figure 5.1-2. Each 10 ms radio frame consists of two half-frames of 5 ms each.
Each half-frame consists of eight slots of length 0.5 ms and three special fields: DwPTS, GP and UpPTS. The length of
DwPTS and UpPTS is configurable subject to the total length of DwPTS, GP and UpPTS being equal to 1ms. Both 5ms
and 10ms switch-point periodicity are supported. Subframe 1 in all configurations and subframe 6 in configuration with
5ms switch-point periodicity consist of DwPTS, GP and UpPTS. Subframe 6 in configuration with 10ms switch-point
periodicity consists of DwPTS only. All other subframes consist of two equally sized slots.
For TDD, GP is reserved for downlink to uplink transition, and UpPTS is reserved in NB-IoT. Other Subframes/Fields
are assigned for either downlink or uplink transmission. Uplink and downlink transmissions are separated in the time
domain.
Figure 5.1-2: Frame structure type 2 (for 5ms switch-point periodicity)
3GPP
Release 17 64 3GPP TS 36.300 V17.2.0 (2022-09)
Table 5.1-1: Uplink-downlink allocations.
Configuratio Switch-point periodicity Subframe number

n 0 1 2 3 4 5 6 7 8 9
0 5 ms D S U U U D S U U U
1 5 ms D S U U D D S U U D
2 5 ms D S U D D D S U D D
3 10 ms D S U U U D D D D D
4 10 ms D S U U D D D D D D
5 10 ms D S U D D D D D D D
6 5 ms D S U U U D S U U D
Frame structure Type 3 is applicable to LAA secondary cell operation with normal cyclic prefix only. Each 10 ms radio
frame is divided into ten equally sized sub-frames. Each sub-frame consists of two equally sized slots. The 10
subframes within a radio frame are available for downlink or uplink transmissions.
Sidelink transmissions are defined for sidelink discovery, sidelink communication and V2X sidelink communication
between UEs. The sidelink transmissions use the same frame structure as the frame structure that is defined for uplink
and downlink when UEs are in network coverage; however, the sidelink transmission are restricted to a sub-set of the
uplink resources in time and frequency domain.
For NB-IoT, the frame structure is described in clauses 5.1.1a and 5.2.1a.
The physical channels of E-UTRA are:
Physical broadcast channel (PBCH)
- The coded BCH transport block is mapped to four subframes within a 40 ms interval;
- 40 ms timing is blindly detected, i.e. there is no explicit signalling indicating 40 ms timing;
- Each subframe is assumed to be self-decodable, i.e. the BCH can be decoded from a single reception,
assuming sufficiently good channel conditions.
Physical control format indicator channel (PCFICH)
- Informs the UE and the RN about the number of OFDM symbols used for the PDCCHs;
- Transmitted in every downlink or special subframe.
Physical downlink control channel (PDCCH)
- Informs the UE and the RN about the resource allocation of PCH and DL-SCH, and Hybrid ARQ
information related to DL-SCH;
- Carries the uplink scheduling grant;
- Carries the sidelink scheduling grant.
Enhanced physical downlink control channel (EPDCCH)
- Informs the UE about the resource allocation of DL-SCH, and Hybrid ARQ information related to DL-SCH;
- Carries the sidelink scheduling grant.
MTC physical downlink control channel (MPDCCH)
- Carries Hybrid ARQ ACK in response to uplink transmissions.
- Carries the direct indication information.
3GPP
Release 17 65 3GPP TS 36.300 V17.2.0 (2022-09)
Short physical downlink control channel (SPDCCH)
- Carries the uplink scheduling grant.
Physical Hybrid ARQ Indicator Channel (PHICH)
- Carries Hybrid ARQ ACK/NAKs in response to uplink transmissions.
Physical downlink shared channel (PDSCH)
- Carries the DL-SCH and PCH.
Physical multicast channel (PMCH)
- Carries the MCH.
Physical uplink control channel (PUCCH)
- Carries Hybrid ARQ ACK/NAKs in response to downlink transmission;
- Carries Scheduling Request (SR);
- Carries CSI reports.
Short physical uplink control channel (SPUCCH)
- Carries Hybrid ARQ ACK/NAKs in response to downlink transmission;
- Carries Scheduling Request (SR).
Physical uplink shared channel (PUSCH)
- Carries the UL-SCH.
Physical random access channel (PRACH)
- Carries the random access preamble.
Relay physical downlink control channel (R-PDCCH)
- Informs the RN about the resource allocation of DL-SCH, and Hybrid ARQ information related to DL-SCH;
- Carries the uplink scheduling grant.
Physical sidelink broadcast channel (PSBCH)
- Carries system and synchronization related information, transmitted from the UE.
Physical sidelink discovery channel (PSDCH)
- Carries sidelink discovery message from the UE.
Physical sidelink control channel (PSCCH)
- Carries control from a UE for sidelink communication and V2X sidelink communication.
Physical sidelink shared channel (PSSCH)
- Carries data from a UE for sidelink communication and V2X sidelink communication.
Narrowband Physical broadcast channel (NPBCH)
- The coded BCH transport block is mapped to sixty four subframes within a 640 ms interval;
- 640 ms timing is blindly detected, i.e. there is no explicit signalling indicating 640 ms timing.
Narrowband Physical downlink shared channel (NPDSCH)
3GPP
Release 17 66 3GPP TS 36.300 V17.2.0 (2022-09)
- Carries the DL-SCH and PCH for NB-IoT UEs.
Narrowband Physical downlink control channel (NPDCCH)
- Informs the NB-IoT UE about the resource allocation of PCH and DL-SCH;
- Carries the uplink scheduling grant for the NB-IoT UE;
- Carries the direct indication information.
Narrowband Physical uplink shared channel (NPUSCH)
- Carries the UL-SCH and Hybrid ARQ ACK/NAKs in response to downlink transmission for the NB-IoT UE;
- Carries SR for the NB-IoT UE.
Narrowband Physical random access channel (NPRACH)
- Carries the random access preamble for the NB-IoT UE;
- Carries SR for the NB-IoT UE.
5.1 Downlink Transmission Scheme

5.1.1 Basic transmission scheme based on OFDM
The downlink transmission scheme is based on conventional OFDM using a cyclic prefix. The OFDM sub-carrier
spacing is f = 15 kHz. 12 consecutive sub-carriers during one slot correspond to one downlink resource block. In the
frequency domain, the number of resource blocks, NRB, can range from NRB-min = 6 to NRB-max = 110 per CC or per Cell in
case of CA or DC.
In addition, there are also four reduced sub-carrier spacings, flow = 7.5 kHz, flow1 = 2.5 kHz, flow2 = 1.25 kHz and
flow3 ≈ 0.37 kHz for both MBMS-dedicated cell and MBMS/Unicast-mixed cell.
In case of 15 kHz sub-carrier spacing there are two cyclic-prefix lengths, corresponding to seven and six OFDM
symbols per slot respectively.
- Normal cyclic prefix: TCP = 160Ts (OFDM symbol #0), TCP = 144Ts (OFDM symbol #1 to #6)
- Extended cyclic prefix: TCP-e = 512Ts (OFDM symbol #0 to OFDM symbol #5)
where Ts = 1/ (2048  f)
In case of 7.5 kHz sub-carrier spacing, there is only a single cyclic prefix length TCP-low = 1024Ts, corresponding to 3
OFDM symbols per slot.
In case of 2.5 kHz sub-carrier spacing, there is only a single cyclic prefix length TCP-low1 = 3072Ts, corresponding to 1
OFDM symbol per slot.
OFDM symbol per subframe.
OFDM symbol per 3 ms slot as defined in TS 36.211 [4], clause 4.1.
For MBMS-dedicated cells, the PMCH bandwidth can be indicated to be larger than the carrier bandwidth. In particular,
a PMCH bandwidth of 30, 35 or 40 PRBs (corresponding to 6/ 7/ 8MHz) can be indicated when the carrier bandwidth is
15 or 25 PRBs (corresponding to 3/ 5 MHz).
In case of FDD, operation with half duplex from UE point of view is supported.
5.1.1a Basic transmission scheme based on OFDM for NB-IoT

The downlink transmission scheme for NB-IoT is as described in clause 5.1.1, with the differences that in the frequency
domain, there is one resource block for an NB-IoT carrier, the OFDM sub-carrier spacing f = 15 kHz always, and in
3GPP
Release 17 67 3GPP TS 36.300 V17.2.0 (2022-09)
case of FDD, only operation with half duplex from NB-IoT UE point of view is supported. There can be more than one
NB-IoT carrier configured as described in clause 5.5a.
5.1.2 Physical-layer processing

The downlink physical-layer processing of transport channels consists of the following steps:
- CRC insertion: 24 bit CRC for PDSCH and NPDSCH;
- Channel coding: Turbo coding based on QPP inner interleaving with trellis termination, or Tail Biting
Convolutional Coding for NPDSCH;
- Physical-layer hybrid-ARQ processing;
- Channel interleaving;
- Scrambling: transport-channel specific scrambling on DL-SCH, BCH, and PCH. Common MCH scrambling for
all cells involved in a specific MBSFN transmission;
- Modulation: QPSK, 16QAM, 64QAM, 256QAM and 1024QAM;
- Layer mapping and pre-coding;
- Mapping to assigned resources and antenna ports.
5.1.3 Physical downlink control channels

The downlink control signalling (PDCCH) is located in the first n OFDM symbols where n  4 and consists of:
- Transport format and resource allocation related to DL-SCH and PCH, and hybrid ARQ information related to
DL-SCH;
- Transport format, resource allocation, and hybrid-ARQ information related to UL-SCH;
- Resource allocation information related to SL-SCH and PSCCH.
Transmission of control signalling from these groups is mutually independent.
Multiple physical downlink control channels are supported and a UE monitors a set of control channels.
Control channels are formed by aggregation of control channel elements, each control channel element consisting of a
set of resource elements. Different code rates for the control channels are realized by aggregating different numbers of
control channel elements.
QPSK modulation is used for all control channels.
Each separate control channel has its own set of x-RNTI.
There is an implicit relation between the uplink resources used for dynamically scheduled data transmission, or the DL
control channel used for assignment, and the downlink ACK/NAK resource used for feedback.
The physical layer supports R-PDCCH for the relay.
The enhanced physical downlink control channel (EPDCCH) carries UE-specific signalling. It is located in UE-
specifically configured physical resource blocks and consists of:
- Transport format, resource allocation, and hybrid ARQ information related to DL-SCH;
- Resource allocation information related to SL-SCH and PSCCH.
Multiple EPDCCHs are supported and a UE monitors a set of EPDCCHs.
EPDCCHs are formed by aggregation of enhanced control channel elements, each enhanced control channel element
consisting of a set of resource elements. Different code rates for EPDCCHs are realized by aggregating different
3GPP
Release 17 68 3GPP TS 36.300 V17.2.0 (2022-09)
numbers of enhanced control channel elements. An EPDCCH can use either localized or distributed transmission,
differing in the mapping of enhanced control channel elements to the resource elements in the PRBs.
EPDCCH supports C-RNTI and SPS C-RNTI and UL Semi-Persistent Scheduling V-RNTI and SL-RNTI and SL-V-
RNTI and SL Semi-Persistent Scheduling V-RNTI, and AUL C-RNTI, and SRS-TPC-RNTI. If configured, EPDCCH is
applicable in the same way as PDCCH unless otherwise specified.
The MTC physical downlink control channel (MPDCCH) is used for bandwidth-reduced operation and carries common
and UE-specific signalling.
Multiple MPDCCHs are supported and a UE monitors a set of MPDCCHs.
MPDCCHs are formed by aggregation of enhanced control channel elements, each enhanced control channel element
consisting of a set of resource elements. Different code rates for MPDCCHs are realized by aggregating different
numbers of enhanced control channel elements. An MPDCCH can use either localized or distributed transmission,
differing in the mapping of enhanced control channel elements to the resource elements in the PRBs.
MPDCCH supports RA-RNTI, P-RNTI, C-RNTI, Temporary C-RNTI, SPS C-RNTI, SC-RNTI and G-RNTI. For non-
BL UEs in RRC_CONNECTED, MPDCCH supports SI-RNTI.
The short physical downlink control channel (SPDCCH) carries UE-specific signalling. It is located in UE-specifically
configured physical resource blocks and consists of:
- Transport format, resource allocation, and hybrid ARQ information related to DL-SCH;
Multiple SPDCCHs are supported and a UE monitors a set of SPDCCHs.
SPDCCHs are formed by aggregation of short control channel elements (SCCEs), each short control channel element
consisting of a set of resource elements. Different code rates for SPDCCHs are realized by aggregating different
numbers of SCCEs. An SPDCCH can use either localized or distributed transmission, differing in the mapping of
SCCEs to the resource elements in the PRBs.
SPDCCH supports C-RNTI and SPS C-RNTI. If configured, SPDCCH is applicable in the same way as PDCCH unless
otherwise specified.
For NB-IoT, the narrowband physical downlink control channel (NPDCCH) is located in available symbols of
configured subframes. Within a PRB pair, two control channel elements are defined, with each control channel element
composed of resources within a subframe. NPDCCH supports aggregations of 1 and 2 control channel elements and
repetition. NPDCCH supports C-RNTI, Temporary C-RNTI, P-RNTI, RA-RNTI, SC-RNTI, G-RNTI, and SPS C-
RNTI.
5.1.4 Downlink Reference signal and synchronization signals

The downlink cell-specific reference signals consist of known reference symbols inserted in the first and third last
OFDM symbol of each slot for antenna port 0 and 1. There is one cell-specific reference signal transmitted per
downlink antenna port. The number of downlink antenna ports for the transmission of cell-specific reference signals
equals 1, 2, or 4.
Physical layer provides 504 unique cell identities using Synchronization signals and resynchronization signals.
The downlink MBSFN reference signals consist of known reference symbols inserted every other sub-carrier in the 3rd,
7th and 11th OFDM symbol of sub-frame in case of 15 kHz sub-carrier spacing and extended cyclic prefix; every four
sub-carriers in the 2nd, 4th and 6th symbol of sub-frame in case of 7.5 kHz sub-carrier spacing; every four sub-carriers
in the single symbol of slot in case of 2.5 kHz sub-carrier spacing; every six sub-carriers in the single symbol of
subframe in case of 1.25 kHz sub-carrier spacing; and every twelve sub-carriers for MBSFN reference signal pattern
type 1 or every six sub-carriers for MBSFN reference signal pattern type 2 in the single symbol of 3 ms slot in case of
0.37 kHz sub-carrier spacing as defined in TS 36.211 [4], clauses 4.1 and 6.10.2.2.4.
In addition to cell-specific reference signals and MBSFN reference signals, the physical layer supports UE-specific
reference signals, positioning reference signals, CSI reference signals, and discovery signals.
A UE may assume presence of the discovery signals consisting of cell-specific reference signals, primary and secondary
synchronization signals, configurable resynchronization signals, and configurable CSI reference signals.
3GPP
Release 17 69 3GPP TS 36.300 V17.2.0 (2022-09)
5.1.4a Downlink Reference signal and synchronization signals for NB-IoT

The downlink narrowband reference signal consists of known reference symbols inserted in the last two, or the third and
fourth, OFDM symbols of each slot depending on the frame structure Type, for NB-IoT antenna port 0 and 1, except
invalid subframes, and subframes transmitting NPSS or NSSS, and certain subframes in frame structure Type 2. There
is one narrowband reference signal transmitted per downlink NB-IoT antenna port. The number of downlink NB-IoT
antenna ports equals 1 or 2.
In addition to narrowband reference signals, the physical layer supports Narrowband Positioning Reference Signals
(NPRS).
Physical layer provides 504 unique cell identities using the narrowband secondary synchronization signal. It is indicated
whether or not the UE may assume the cell ID is identical for NB-IoT and LTE. In case the cell IDs are identical, a UE
may use the downlink cell-specific reference signals for demodulation and/or measurements when the number of NB-
IoT antenna ports is the same as the number of downlink cell-specific reference signal antenna ports.
5.1.5 Downlink multi-antenna transmission

Multi-antenna transmission with up to 8 transmit antennas is supported. The maximum number of codeword is two
irrespective to the number of antennas with fixed mapping between code words to layers. For slot/subslot based
transmission, multi-antenna transmission with up to 4 transmit antennas is supported. The maximum number of
codeword is one irrespective of the number of antennas with fixed mapping between codewords and layers.
Spatial division multiplexing (SDM) of multiple modulation symbol streams to a single UE using the same time-
frequency (-code) resource, also referred to as Single-User MIMO (SU-MIMO) is supported. When a MIMO channel is
solely assigned to a single UE, it is known as SU-MIMO. Spatial division multiplexing of modulation symbol streams
to different UEs using the same time-frequency resource, also referred to as MU-MIMO, is also supported.
In addition, the following techniques are supported:
- Code-book-based pre-coding with a single pre-coding feedback per full system bandwidth when the system
bandwidth (or subset of resource blocks) is smaller or equal to12RB and per 5 adjacent resource blocks or the
full system bandwidth (or subset of resource blocks) when the system bandwidth is larger than 12RB.
- Non-code-book-based pre-coding with or without pre-coding feedback.
- Rank adaptation with single rank feedback referring to full system bandwidth. Node B can override rank report.
- Non-precoded CSI-RS operation is supported by CLASS A eMIMO-Type with one CSI-RS resource. This
operation comprises schemes where different CSI-RS ports have the same wide beam width and direction and
hence generally cell wide coverage.
- Beamformed CSI-RS operation is supported by CLASS B eMIMO-Type with one or more CSI-RS resources.
This operation comprises schemes where (at least at a given time/frequency) CSI-RS ports have narrow beam
widths and hence not cell wide coverage, and (at least from the eNB perspective) at least some CSI-RS port-
resource combinations have different beam directions.
5.1.5a Downlink multi-antenna transmission for NB-IoT

Transmit diversity, specifically space frequency block coding (SFBC), is supported if two NB-IoT antenna ports are
used.
5.1.6 MBSFN transmission

MBSFN is supported for the MCH transport channel. Multiplexing of transport channels using MBSFN and non-
MBSFN transmission is done on a per-sub-frame basis. Additional reference symbols, transmitted using MBSFN are
transmitted within MBSFN subframes.
3GPP
Release 17 70 3GPP TS 36.300 V17.2.0 (2022-09)
5.1.7 Physical layer procedure

5.1.7.1 Link adaptation
Link adaptation (AMC: adaptive modulation and coding) with various modulation schemes and channel coding rates is
applied to the shared data channel. 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 TTI and within a single stream.
5.1.7.2 Power Control
Downlink power control can be used.
5.1.7.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. E-UTRA cell search supports a scalable overall transmission bandwidth corresponding to 72 sub-carriers
and upwards.
E-UTRA cell search is based on following signals transmitted in the downlink: the primary and secondary
synchronization signals. If a resynchronization signal is transmitted in the downlink, it can be used to re-acquire time
and frequency synchronization with the cell.
The primary and secondary synchronization signals are transmitted over the centre 72 sub-carriers in the first and sixth
subframe of each frame. The resynchronization signals are transmitted over 2 consecutive PRBs. The time and
frequency positions of the resynchronization signal (if transmitted) are configurable.
Neighbour-cell search is based on the same downlink signals as initial cell search.
5.1.7.3a Cell search for NB-IoT

NB-IoT is based on following signals transmitted in the downlink: the primary and secondary narrowband
synchronization signals. The narrowband primary synchronization sequence is transmitted over 11 sub-carriers from the
first subcarrier to the eleventh subcarrier in the sixth subframe of each frame, and the narrowband secondary
synchronization sequence is transmitted over 12 sub-carriers in the NB-IoT carrier in the tenth subframe for FDD and
the first subframe for TDD of every other frame.
5.1.8 Physical layer measurements definition

The physical layer measurements to support mobility are classified as:
- within E-UTRAN (intra-frequency, inter-frequency);
- between E-UTRAN and GERAN/UTRAN (inter-RAT);
- between E-UTRAN and non-3GPP RAT (Inter 3GPP access system mobility).
For measurements within E-UTRAN two basic UE measurement quantities shall be supported:
- Reference signal received power (RSRP);
- Reference signal received quality (RSRQ).
In addition, the following UE measurement quantity may be supported:
- Received signal strength indicator (RSSI);
- Reference signal signal to noise and interference ratio (RS-SINR).
RSRP measurement is based on the following signals:
- Cell-specific reference signals; or
- CSI reference signals in configured discovery signals; or
- Resynchronization Signal; or
3GPP
Release 17 71 3GPP TS 36.300 V17.2.0 (2022-09)
- Narrowband secondary synchronization signal for NB-IoT UEs.
5.1.9 Coordinated Multi-Point transmission

For DL CoMP, multiple transmission points are coordinated in their downlink data transmission.
The UE may be configured to measure and report the CSI of a set of non-zero power CSI-RS resources.
The UE may also be configured with one or more interference measurements. Each interference measurement is
associated with one CSI-interference measurement (CSI-IM) resource, which is a set of REs on which the UE measures
interference.
The UE may also be configured with multiple CSI processes. Each CSI process defines the CSI measurement associated
with one non-zero power CSI-RS resource and one CSI-IM resource.
5.1.10 Wake-up signal for NB-IoT

The narrowband wake-up signal is transmitted over 12 sub-carriers in the frequency domain in the NB-IoT carrier in
available symbols of configured subframes. It conveys 504 unique cell identities, as per the narrowband secondary
synchronization signal.
5.1.11 Wake-up signal for BL UE or UE in enhanced coverage

The wake-up signal is transmitted over 2 physical resource blocks in the frequency domain in available symbols of
configured subframes. It conveys 504 unique cell identities, as per the secondary synchronization signal.
5.2 Uplink Transmission Scheme

5.2.1 Basic transmission scheme
For both FDD and TDD, the uplink transmission scheme is based on single-carrier FDMA, more specifically DFTS-
OFDM. It also supports multi-cluster assignment of DFTS-OFDM.
Figure 5.2.1-1: Transmitter scheme of SC-FDMA
The uplink sub-carrier spacing f = 15 kHz. The sub-carriers are grouped into sets of 12 consecutive sub-carriers,
corresponding to the uplink resource blocks. 12 consecutive sub-carriers during one slot correspond to one uplink
resource block. In the frequency domain, the number of resource blocks, NRB, can range from NRB-min = 6 to NRB-max =
110 per carrier or per CC in case of CA or DC.
There are two cyclic-prefix lengths defined: Normal cyclic prefix and extended cyclic prefix corresponding to seven
and six SC-FDMA symbol per slot respectively.
- Normal cyclic prefix: TCP = 160Ts (SC-FDMA symbol #0) , TCP = 144Ts (SC-FDMA symbol #1 to #6)
- Extended cyclic prefix: TCP-e = 512Ts (SC-FDMA symbol #0 to SC-FDMA symbol #5)
5.2.1a Basic transmission scheme for NB-IoT

For NB-IoT uplink transmission, both single-tone transmission and multi-tone transmission are defined.
For single-tone transmission, there are two numerologies defined: 3.75 kHz and 15 kHz subcarrier spacing, based on
single-carrier FDMA as described in clause 5.2.1, with the following differences: In the frequency domain, resource
blocks are not defined. If the uplink sub-carrier spacing f = 15 kHz, there are 12 consecutive sub-carriers. If the uplink
sub-carrier spacing f = 3.75 kHz, there are 48 consecutive sub-carriers.
3GPP
Release 17 72 3GPP TS 36.300 V17.2.0 (2022-09)
Single-tone transmission with 3.75 kHz subcarrier spacing is organized into slots with 2ms duration, each of which
consists of seven symbols located from beginning of the slot. The slot boundary is aligned with sub-frame boundaries of
frame structure Type 1. One symbol of 3.75 kHz subcarrier spacing consists of 8448 Ts of symbol with CP length of
256Ts. The remaining time (2304Ts) of the slot is used as a guard period.
Multi-tone transmission is based on single-carrier FDMA as described in clause 5.2.1, with the difference that resource
blocks are not defined. There are 12 consecutive uplink sub-carriers with uplink sub-carrier spacing f = 15 kHz. The
sub-carriers can be grouped into sets of 3, 6, or 12 consecutive subcarriers.
A resource unit, schedulable for single-tone NPUSCH with UL-SCH transmission, is defined as a single 3.75 kHz sub-
carrier for 32 ms or a single 15 kHz sub-carrier for 8 ms. A resource unit, schedulable for multi-tone NPUSCH with
UL-SCH transmission is defined as 3 sub-carriers for 4 ms; or 6 sub-carriers for 2 ms; or 12 sub-carriers for 1ms. A
resource unit, schedulable for NPUSCH with ACK/NAK transmission, is defined as a single 3.75 kHz sub-carrier for 8
ms or a single 15 kHz sub-carrier for 2 ms.
A UL-SCH transport block can be scheduled over one or more than one resource unit in time.

The uplink physical layer processing of transport channels consists of the following steps:
- CRC insertion: 24 bit CRC for PUSCH and NPUSCH;
- Channel coding: turbo coding based on QPP inner interleaving with trellis termination;
- Physical-layer hybrid-ARQ processing;
- Scrambling: UE-specific scrambling;
- Modulation: QPSK, 16QAM, 64QAM and 256 QAM (64 QAM and 256 QAM optional in UE) for full-PRB
transmission of PUSCH, and π/2-BPSK and QPSK for sub-PRB transmission of PUSCH (optional in UE); π/2-
BPSK and π/4-QPSK in single-tone transmission of NPUSCH, QPSK and optionally 16QAM for multi-tone
transmission of NPUSCH;
- Mapping to assigned resources and antennas ports.
5.2.3 Physical uplink control channel

The PUCCH/SPUCCH shall be mapped to a control channel resource in the uplink.
Depending on presence or absence of uplink timing synchronization, the uplink physical control signalling for
scheduling request can differ.
In the case of time synchronization being present for the pTAG, the outband control signalling consists of:
- CSI;
- ACK/NAK;
- Scheduling Request (SR).
The CSI informs the scheduler about the current channel conditions as seen by the UE. If MIMO transmission is used,
the CSI includes necessary MIMO-related feedback.
The HARQ feedback in response to downlink data transmission consists of a single ACK/NAK bit per transport block
in case of non-bundling configuration.
PUCCH/SPUCCH resources for SR, CSI reporting and possibly HARQ feedback are assigned and can be revoked
through RRC signalling. An SR is not necessarily assigned to UEs acquiring synchronization through the RACH (i.e.
synchronised UEs may or may not have a dedicated SR channel). PUCCH/SPUCCH resources for SR, CSI and HARQ
feedback are lost when the UE is no longer synchronized.
PUCCH/SPUCCH is transmitted on PCell, PUCCH SCell (if such is configured in CA) and on PSCell (in DC).
3GPP
Release 17 73 3GPP TS 36.300 V17.2.0 (2022-09)
The physical layer supports simultaneous transmission of PUCCH and subframe PUSCH, or of SPUCCH and (sub)slot-
PUSCH. In case of SPUCCH and (sub)slot-PUSCH transmission, both the shared channel and the associated control
channel shall be of the same transmission duration (slot or subslot).
5.2.3a Uplink control information for NB-IoT

The uplink control information consists of:
- ACK/NAK corresponding to NPDSCH;
- Scheduling Request (SR).
ACK/NAK corresponding to NPDSCH is transmitted with single-tone transmission on NPUSCH, with frequency
resource and time resource indicated by downlink grant.
SR may be transmitted with or without Hybrid ARQ ACK/NAKs corresponding to NPDSCH. Resources for SR are
assigned and can be revoked through RRC signaling. An SR is not necessarily assigned to NB-IoT UEs acquiring
synchronisation through the RACH (i.e. synchronised NB-IoT UEs may or may not have SR resources configured).
Resources for SR are lost when the NB-IoT UE is no longer synchronised.
5.2.4 Uplink Reference signal

For PUSCH demodulation, uplink demodulation reference signals are transmitted in the 4-th block of the slot in normal
CP. In case of subslot-PUSCH, the presence and position of demodulation reference signals are indicated to the UE.
Uplink demodulation reference signals are also transmitted for PUCCH demodulation. The uplink demodulation
reference signals sequence length equals the size (number of sub-carriers) of the assigned resource.
The uplink reference signals are based on sequences having constant amplitude and zero autocorrelation.
For full-PRB transmission, multiple reference signals can be created:
- Based on different base sequences;
- Different shifts of the same sequence;
- Different orthogonal sequences (OCC) on DM RS.
For sub-PRB transmission of PUSCH, multiple reference signals can be created:
- Different cyclic shifts of the same sequence;
- A common Gold sequence.
In addition to demodulation reference signals, the physical layer supports sounding reference signals (SRS).
5.2.4a Uplink Reference signal for NB-IoT

For single-tone NPUSCH with UL-SCH demodulation, uplink demodulation reference signals are transmitted in the 4-
th block of the slot for 15 kHz subcarrier spacing, and in the 5-th block of the slot for 3.75 kHz subcarrier spacing. For
multi-tone NPUSCH with UL-SCH demodulation, uplink demodulation reference signals are transmitted in the 4-th
block of the slot. The uplink demodulation reference signals sequence length is 16 for single-tone NPUSCH with UL-
SCH transmission, and equals the size (number of sub-carriers) of the assigned resource for multi-tone transmission.
For single-tone NPUSCH with UL-SCH transmission, multiple narrow band reference signals can be created:
- A common Gold sequence.
For multi-tone NPUSCH with UL-SCH transmission, multiple narrow band reference signals are created:
- Different cyclic shifts of the same sequence.
3GPP
Release 17 74 3GPP TS 36.300 V17.2.0 (2022-09)
For NPUSCH with ACK/NAK demodulation, uplink demodulation reference signals are transmitted in the 3-rd, 4-th
and 5-th block of the slot for 15 kHz subcarrier spacing, and in the 1-st, 2-nd and 3-rd block of the slot for 3.75 kHz
subcarrier spacing. Multiple narrow band reference signals can be created:
- A common Gold sequence;
- Different orthogonal sequences (OCC).
5.2.5 Random access preamble

The physical layer random access burst consists of a cyclic prefix, a preamble, and a guard time during which nothing is
transmitted.
The random access preambles are generated from Zadoff-Chu sequences with zero correlation zone, ZC-ZCZ,
generated from one or several root Zadoff-Chu sequences.
5.2.5a Random access preamble for NB-IoT

The physical layer random access transmission uses a 3.75 kHz or 1.25 kHz sub-carrier spacing and consists of symbol
groups with frequency hopping between symbol groups. Each symbol group has a cyclic prefix and a preamble. Symbol
groups with 3.75 kHz sub-scarrier spacing hop by one or six sub-carriers in frequency, and symbol groups with 1.25
kHz subcarrier spacing hop by one, three, or eighteen sub-carriers in frequency. Repetitions of groups of symbol groups
hop by a pseudo-random number of sub-carriers in frequency. There are two in FDD, and four in TDD, possible cyclic
prefix lengths for the random access transmission symbol groups, suitable for different maximum cell sizes.
5.2.6 Uplink multi-antenna transmission

The antenna configuration for uplink supports both SU-MIMO and MU-MIMO.
Closed loop and open loop types of adaptive antenna selection transmit diversity are supported for both FDD and TDD
by physical layer.
The physical layer supports transmit diversity of some control formats.
5.2.7 Physical channel procedure

5.2.7.1 Link adaptation
Uplink link adaptation is used in order to guarantee the required minimum transmission performance of each UE such
as the user data rate, packet error rate, and latency, while maximizing the system throughput.
Three types of link adaptation are performed according to the channel conditions, the UE capability such as the
maximum transmission power and maximum transmission bandwidth etc., and the required QoS such as the data rate,
latency, and packet error rate etc. Three link adaptation methods are as follows.
- Adaptive transmission bandwidth;
- Transmission power control;
- Adaptive modulation and channel coding rate.
5.2.7.2 Uplink Power control

Intra-cell power control: the power spectral density of the uplink transmissions can be influenced by the eNB. For DC,
two types of power control modes are defined, mode 1 and mode 2 as specified in TS 36.213 [6]. A UE capable of DC
supports at least power control mode 1 and the UE may additionally support power control mode 2. In both modes, the
UE is configured with a minimum guaranteed power for each CG, as a ratio of the configured maximum UE output
power Pcmax (see TS 36.101 [52] ). In power control mode 1, UE allocates up to the minimum guaranteed power to
each CG and any remaining power is shared across MCG and SCG on a per transmission basis according to a priority
order based on UCI type. In power control mode 2, the UE reserves the minimum guaranteed power to each CG and any
remaining power is first made available to the CG where transmission starts the earliest in time.
3GPP
Release 17 75 3GPP TS 36.300 V17.2.0 (2022-09)
5.2.7.3 Uplink timing control

The timing advance is derived from the UL received timing and sent by the eNB to the UE which the UE uses to
advance/delay its timings of transmissions to the eNB so as to compensate for propagation delay and thus time align the
transmissions from different UEs with the receiver window of the eNB.
The timing advance command for each TAG is on a per need basis with a granularity in the step size of 0.52 s (16Ts).
5.2.8 Coordinated Multi-Point reception

For UL CoMP, multiple reception points are coordinated in their uplink data reception.
The UE may be configured with UE-specific parameters of PUSCH DMRS sequence and cyclic shift hopping, PUCCH
sequence, and PUCCH region for hybrid-ARQ feedback. These UE-specific parameters can be configured
independently of the physical cell identity of the UE's serving cell.
5.3 Transport Channels

5.3.0 Transport channel types
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".
NOTE 1: 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.
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;
NOTE 2: the possibility to use slow power control depends on the physical layer.
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;
- mapped to physical resources which can be used dynamically also for traffic/other control channels.
4. Multicast Channel (MCH) characterised by:
- requirement to be broadcast in the entire coverage area of the cell;
- support for MBSFN combining of MBMS transmission on multiple cells;
3GPP
Release 17 76 3GPP TS 36.300 V17.2.0 (2022-09)
- support for semi-static resource allocation e.g. with a time frame of a long cyclic prefix.
Uplink transport channel types are:
1. Uplink Shared Channel (UL-SCH) characterised by:
- possibility to use beamforming; (likely no impact on specifications)
- 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.
NOTE 3: the possibility to use uplink synchronisation and timing advance depend on the physical layer.
2. Random Access Channel(s) (RACH) characterised by:
- limited control information;
- collision risk.
NOTE 4: The possibility to use open loop power control depends on the physical layer solution.
Sidelink transport channel types are:
1. Sidelink broadcast channel (SL-BCH) characterised by:
- pre-defined transport format.
2. Sidelink discovery channel (SL-DCH) characterised by:
- fixed size, pre-defined format periodic broadcast transmission;
- support for both UE autonomous resource selection and scheduled resource allocation by eNB;
- collision risk due to support of UE autonomous resource selection; no collision when UE is allocated
dedicated resources by the eNB;
- support for HARQ combining, but no support for HARQ feedback.
NOTE 5: the possibility to use uplink synchronisation and timing advance depends on the physical layer.
3. Sidelink shared channel (SL-SCH) characterised by:
- support for broadcast transmission;
- support for both UE autonomous resource selection and scheduled resource allocation by eNB;
- collision risk due to support of UE autonomous resource selection; no collision when UE is allocated
dedicated resources by the eNB;
- support for HARQ combining, but no support for HARQ feedback;
- support for dynamic link adaptation by varying the transmit power, modulation and coding.
NOTE 6: the possibility to use uplink synchronisation and timing advance depend on the physical layer.
5.3.1 Mapping between transport channels and physical channels

The figures below depict the mapping between transport and physical channels:
3GPP
Release 17 77 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 5.3.1-1: Mapping between downlink transport channels and downlink physical channels
Figure 5.3.1-2: Mapping between uplink transport channels and uplink physical channels
Figure 5.3.1-3: Mapping between sidelink transport channels and sidelink physical channels
5.3.1a Mapping between transport channels and narrowband physical

channels
The figures below depict the mapping between transport and narrowband physical channels:
Figure 5.3.1a-1: Mapping between downlink transport channels and downlink narrowband physical
channels
3GPP
Release 17 78 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 5.3.1a-2: Mapping between uplink transport channels and uplink narrowband physical
channels
5.4 E-UTRA physical layer model

The E-UTRAN physical layer model is captured in TS 36.302 [9].
5.4.1 Void
5.4.2 Void
5.5 Carrier Aggregation
5.5.0 General
In Carrier Aggregation (CA), two or more Component Carriers (CCs) are aggregated in order to support wider
transmission bandwidths up to 640MHz. 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). E-UTRAN 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 with each CC limited to a maximum of 110 Resource
Blocks in the frequency domain using the Rel-8/9 numerology.
CA is supported both between same and different duplex CCs.
It is possible to configure a UE to aggregate a different number of CCs originating from the same eNB and of possibly
different bandwidths in the UL and the DL:
- The number of DL CCs that can be configured depends on the DL aggregation capability of the UE;
- The number of UL CCs that can be configured depends on the UL aggregation capability of the UE;
- It is not possible to configure a UE with more UL CCs than DL CCs;
- In typical TDD deployments, the number of CCs and the bandwidth of each CC in UL and DL is the same.
- The number of TAGs that can be configured depends on the TAG capability of the UE.
CCs originating from the same eNB need not to provide the same coverage.
3GPP
Release 17 79 3GPP TS 36.300 V17.2.0 (2022-09)
CCs shall be LTE Rel-8/9 compatible. Nevertheless, existing mechanisms (e.g. barring) may be used to avoid Rel-8/9
UEs to camp on a CC.
The spacing between centre frequencies of contiguously aggregated CCs shall be a multiple of 300 kHz. This is in order
to be compatible with the 100 kHz frequency raster of Rel-8/9 and at the same time preserve orthogonality of the
subcarriers with 15 kHz spacing. Depending on the aggregation scenario, the n  300 kHz spacing can be facilitated by
insertion of a low number of unused subcarriers between contiguous CCs.
For TDD CA, the downlink/uplink configuration is identical across component carriers in the same band and may be the
same or different across component carriers in different bands.
5.5.1 SRS switching between component carriers

A UE supporting CA can be capable of aggregating more downlink CCs than uplink CCs, and hence a TDD CC may
operate in downlink without PUCCH/PUSCH. A UE may be configured with SRS switching between CCs so that SRS
can be transmitted on a TDD CC configured without PUCCH/PUSCH. When such SRS needs to be transmitted on a
TDD CC without PUCCH/PUSCH, the UE may transmit SRS on the TDD CC or skip the SRS transmission on the
TDD CC depending on the priority order for the operation of SRS switching between CCs.
5.5a Multi-carrier operation for NB-IoT

For NB-IoT, multi-carrier operation is supported.
The UE in RRC_CONNECTED can be configured, via UE-specific RRC signaling, to a non-anchor carrier, for all
unicast transmissions. The UE in RRC_IDLE, based on broadcast/multicast signaling, can use a non-anchor carrier for
SC-PTM reception. The UE in RRC_IDLE can, based on broadcast signaling, use a non-anchor carrier for paging
reception. The UE in RRC_IDLE or RRC_CONNECTED, based on broadcast signaling, can use a non-anchor carrier
for random access. If the non-anchor carrier is not configured for the UE, all transmissions occur on the anchor carrier.
The valid anchor and non-anchor carrier combinations are provided in Table 5.5a-1 for FDD and Table 5.5a-2 for TDD.
Table 5.5a-1: Anchor and non-anchor carrier deployment combinations in FDD
Anchor Carrier
In-band Guard-band Standalone
Valid (Note 2,
In-band Valid (Note 1) Valid (Note 1)
Note 3)
Non-Anchor Carrier
Valid (Note 2,
Guard-band Valid (Note 1) Valid (Note 1)
Note 3)
Valid (Note 2, Valid (Note 2,

Standalone Valid (Note 2)
Note 3) Note 3)
Table 5.5a-2: Anchor and non-anchor carrier deployment combinations in TDD
Anchor Carrier
In-band Guard-band Standalone
In-band Valid (Note 1) Valid (Note 1) Invalid

Non-Anchor Carrier
Guard-band Valid (Note 1) Valid (Note 1) Invalid
Standalone Invalid Invalid Valid (Note 2)
NOTE 1: Both carriers associated with the same LTE cell.
NOTE 2: Total frequency span to not exceed 20MHz and both anchor and non-anchor carriers synchronised.
3GPP
Release 17 80 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE 3: Not applicable to SC-PTM reception.
5.6 Sidelink
5.6.0 General
Sidelink comprises sidelink discovery, sidelink communication and V2X sidelink communication between UEs.
Sidelink uses uplink resources and physical channel structure similar to uplink transmissions. However, some changes,
noted below, are made to the physical channels.
5.6.1 Basic transmission scheme

Sidelink transmission uses the same basic transmission scheme as the UL transmission scheme. However, sidelink is
limited to single cluster transmissions for all the sidelink physical channels. Further, sidelink uses a 1 symbol gap at the
end of each sidelink sub-frame. For V2X sidelink communication, PSCCH and PSSCH are transmitted in the same
subframe.

The sidelink physical layer processing of transport channels differs from UL transmission in the following steps:
- Scrambling: for PSDCH and PSCCH, the scrambling is not UE-specific;
- Modulation: 256 QAM is not supported for sidelink. 64 QAM is only supported for V2X sidelink
communication.
5.6.3 Physical Sidelink control channel

PSCCH is mapped to the sidelink control resources.
PSCCH indicates resource and other transmission parameters used by a UE for PSSCH.
5.6.4 Sidelink reference signals

For PSDCH, PSCCH and PSSCH demodulation, reference signals similar to uplink demodulation reference signals are
transmitted in the 4-th symbol of the slot in normal CP and in the 3rd symbol of the slot in extended cyclic prefix. The
sidelink demodulation reference signals sequence length equals the size (number of sub-carriers) of the assigned
resource. For V2X sidelink communication, reference signals are transmitted in 3rd and 6th symbols of the first slot and
2nd and 5th symbols of the second slot in normal CP.
For PSDCH and PSCCH, reference signals are created based on a fixed base sequence, cyclic shift and orthogonal
cover code. For V2X sidelink communication, cyclic shift for PSCCH is randomly selected in each transmission.
5.6.5 Physical channel procedure

5.6.5.1 Sidelink power control
For in-coverage operation, the power spectral density of the sidelink transmissions can be influenced by the eNB.
5.6.6 Physical layer measurements definition

For measurement on the sidelink, the following basic UE measurement quantities are supported:
- Sidelink reference signal received power (S-RSRP).
- Sidelink discovery reference signal received power (SD-RSRP).
- PSSCH reference signal received power (PSSCH-RSRP).
- Sidelink reference signal strength indicator (S-RSSI).
3GPP
Release 17 81 3GPP TS 36.300 V17.2.0 (2022-09)
5.7 Licensed-Assisted Access

5.7.0 General
Carrier aggregation with at least one SCell operating in the unlicensed spectrum is referred to as Licensed-Assisted
Access (LAA). In LAA, the configured set of serving cells for a UE therefore always includes at least one SCell
operating in the unlicensed spectrum according to Frame structure Type 3, also called LAA SCell. Unless otherwise
specified, LAA SCells act as regular SCells.
LAA eNB and UE apply Listen-Before-Talk (LBT) before performing a transmission on LAA SCell. When LBT is
applied, the transmitter listens to/senses the channel to determine whether the channel is free or busy. If the channel is
determined to be free, the transmitter may perform the transmission; otherwise, it does not perform the transmission. If
an LAA eNB uses channel access signals of other technologies for the purpose of LAA channel access, it shall continue
to meet the LAA maximum energy detection threshold requirement.
The combined time of transmissions compliant with the channel access procedure described in clause 4.1.2 of TS
37.213 [90] by an eNB should not exceed 50 ms in any contiguous 1 second period on an LAA SCell.
Which LBT type (i.e. type 1 or type 2 uplink channel access) the UE applies is signalled via uplink grant for uplink
PUSCH transmission on LAA SCells, except for Autonomous Uplink (AUL) transmissions.
For type 1 uplink channel access on AUL, E-UTRAN signals the Channel Access Priority Class for each logical
channel and UE shall select the lowest Channel Access Priority Class (i.e, with a higher number in the Table 5.7.1-1) of
the logical channel(s) with MAC SDU multiplexed into the MAC PDU. The MAC CEs except padding BSR use the
highest Channel Access Priority Class (i.e, the lowest number in the Table 5.7.1-1).
For type 2 uplink channel access on AUL, the UE may select logical channels corresponding to any Channel Access
Priority Class for UL transmission in the subframes signalled by E-UTRAN in common downlink control signalling.
For uplink LAA operation, the eNB shall not schedule the UE more subframes than the minimum necessary to transmit
all the traffic corresponding to the selected Channel Access Priority Class or lower (i.e, with a lower number in the
Table 5.7.1-1), than the:
- Channel Access Priority Class signaled in UL grant based on the latest BSR and received uplink traffic from the
UE if type 1 uplink channel access procedure (see clause 4.2.1.1 of TS 37.213 [90]) is signalled to the UE;
- Channel Access Priority Class used by the eNB based on the downlink traffic, the latest BSR and received UL
traffic from the UE if type 2 uplink channel access procedure (see clause 4.2.1.2 of TS 37.213 [90]) is signalled
to the UE.
5.7.1 Channel Access Priority Classes

Four Channel Access Priority Classes (CAPC) are defined in TS 37.213 [90] which can be used when performing
uplink and downlink transmissions in LAA carriers. Table 5.7.1-1 shows which Channel Access Priority Class should
be used by traffic belonging to the different standardized QCIs. A non-standardized QCI (i.e. Operator specific QCI)
should use suitable Channel Access Priority Class based on the below table, i.e. the Channel Access Priority Class used
for a non-standardized QCI should be the Channel Access Priority Class of the standardized QCIs which best matches
the traffic class of the non-standardized QCI.
For uplink, the eNB selects the Channel Access Priority Class by taking into account the lowest priority QCI in a
Logical Channel Group.
Table 5.7.1-1: Mapping between Channel Access Priority Classes and QCI
Channel Access Priority Class ( p) QCI

1, 3, 5, 65, 66, 67, 69, 70, 79,
1
80, 82, 83, 84, 85
2 2, 7, 71
3 4, 6, 8, 9, 72, 73, 74, 76
4 -
3GPP
Release 17 82 3GPP TS 36.300 V17.2.0 (2022-09)
5.7.2 Multiplexing of data

Four Channel Access Priority Classes are defined in TS 37.213 [90]. If a DL transmission burst with PDSCH is
transmitted, for which channel access has been obtained using Channel Access Priority Class P (1...4), E-UTRAN shall
ensure the following where a DL transmission burst refers to the continuous transmission by E-UTRAN after a
successful LBT:
- the transmission duration of the DL transmission burst shall not exceed the minimum duration needed to transmit
all available buffered traffic corresponding to Channel Access Priority Class(es) ≤ P;
- the transmission duration of the DL transmission burst shall not exceed the Maximum Channel Occupancy Time
T
( mcot,p as defined in Table 4.1.1-1 of TS 37.213 [90]) for Channel Access Priority Class P;
- additional traffic corresponding to Channel Access Priority Class(s) > P may only be included in the DL
transmission burst once no more data corresponding to Channel Access Priority Class ≤ P is available for
transmission. In such cases, E-UTRAN should maximise occupancy of the remaining transmission resources in
the DL transmission burst with this additional traffic.
For uplink PUSCH transmission, there is no additional restriction at the UE (other than the multiplexing rules defined in
clause 5.4.3 of TS 36.321 [13]) on the type of the traffic that can be carried in the scheduled subframes.
5.8 Short Processing Time

If Short Processing Time (SPT) for 1 ms TTI length is configured, the minimum timing from UL grant transmission to
UL PUSCH transmission, and the timing from DL PDSCH transmission to HARQ feedback transmission is 3 ms.
5.9 Short Transmission Time Interval

Short TTI provides support for TTI length shorter than 1 ms DL-SCH and UL-SCH. To support the short TTI, the
associated control channels, SPDCCH and SPUCCH, are also transmitted with duration shorter than 1 ms.
Over the physical layer, DL and UL transmissions use either slots or subslots when short TTI is configured. A subslot is
defined to be of either 2 OFDM/SC-FDMA symbol or 3 OFDM/SC-FDMA symbol duration.
Table 5.9-1: Slot/subslot DL and UL transmission availability for different frame structure types
Frame Structure Type Supported DL and UL transmission

1 slot, subslot
2 slot
3 -
In case of Frame structure Type 1 the DL and UL transmission duration does not have to be the same. Table 5.9-2
shows the allowed DL and UL combinations.
Table 5.9-2: DL and UL combinations for Frame Structure Type 1
DL UL
Slot Slot
Subslot Slot
Subslot Subslot
When short TTI is configured, extended cyclic prefix is not supported.
6 Layer 2
6.0 Overview
Layer 2 is split into the following sublayers: Medium Access Control (MAC), Radio Link Control (RLC) and Packet
Data Convergence Protocol (PDCP).
3GPP
Release 17 83 3GPP TS 36.300 V17.2.0 (2022-09)
This clause gives a high level description of the Layer 2 sub-layers in terms of services and functions. The three figures
below depict the PDCP/RLC/MAC architecture for downlink, uplink and Sidelink, where:
- Service Access Points (SAP) for peer-to-peer communication are marked with circles at the interface between
sublayers. The SAP between the physical layer and the MAC sublayer provides the transport channels. The
SAPs between the MAC sublayer and the RLC sublayer provide the logical channels.
- The multiplexing of several logical channels (i.e. radio bearers) on the same transport channel (i.e. transport
block) is performed by the MAC sublayer;
- In both uplink and downlink, when neither CA nor DC are configured, only one transport block is generated per
TTI in the absence of spatial multiplexing;
- In Sidelink, only one transport block is generated per TTI for each carrier.
Figure 6-1: Layer 2 Structure for DL
Figure 6-2: Layer 2 Structure for UL
NOTE 1: The eNB may not be able to guarantee that a L2 buffer overflow will never occur. If such overflow
occurs, UE may discard packets in the L2 buffer.
3GPP
Release 17 84 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE 2: For a NB-IoT UE that only supports Control Plane CIoT EPS optimisations, as defined in TS 24.301 [20],
transfer or User Plane CIoT EPS optimisation, as defined in TS 24.301 [20], PDCP is also bypassed (i.e.
not used) until AS security is activated.
Figure 6-3: Layer 2 Structure for Sidelink
6.1 MAC Sublayer

6.1.0 General
This clause provides an overview on services and functions provided by the MAC sublayer.
6.1.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;
- Priority handling between logical channels of one UE;
- Priority handling between UEs by means of dynamic scheduling;
- MBMS service identification;
- Transport format selection;
- Padding.
The sidelink specific services and functions of the MAC sublayer include:
- Radio resource selection;
3GPP
Release 17 85 3GPP TS 36.300 V17.2.0 (2022-09)
- Packet filtering for sidelink communication and V2X sidelik communication.
- Transmission carrier selection for V2X sidelink communication.
6.1.2 Logical Channels

6.1.2.0 General
Different kinds of data transfer services as offered by MAC. Each logical channel type is defined by what type of
information is transferred.
A general classification of logical channels is into two groups:
- Control Channels (for the transfer of control plane information);
- Traffic Channels (for the transfer of user plane information).
There is one MAC entity per CG. MAC generally consists of several function blocks (transmission scheduling
functions, per UE functions, MBMS functions, MAC control functions, transport block generation…). Transparent
Mode is only applied to BCCH, BR-BCCH, PCCH and SBCCH.
NOTE: For a NB-IoT UE that only uses Control Plane CIoT EPS optimisations, as defined in TS 24.301 [20],
there is only one dedicated logical channel per UE.
6.1.2.1 Control Channels

Control channels are used for transfer of control plane information only. The control channels offered by MAC are:
- Broadcast Control Channel (BCCH)
A downlink channel for broadcasting system control information.
- Bandwidth Reduced Broadcast Control Channel (BR-BCCH)
A downlink channel for broadcasting system control information.
- Paging Control Channel (PCCH)
A downlink channel that transfers paging information and system information change notifications. This channel
is used for paging when the network does not know the location cell of the UE.
- 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.
- Multicast Control Channel (MCCH)
A point-to-multipoint downlink channel used for transmitting MBMS control information from the network to
the UE, for one or several MTCHs. This channel is only used by UEs that receive or are interested to receive
MBMS.
- Single-Cell Multicast Control Channel (SC-MCCH)
A point-to-multipoint downlink channel used for transmismitting MBMS control information from the network
to the UE, for one or several SC-MTCHs. This channel is only used by UEs that receive or are interested to
receive MBMS using SC-PTM.
- 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.
- Sidelink Broadcast Control Channel (SBCCH)
A sidelink channel for broadcasting sidelink system information from one UE to other UE(s).
3GPP
Release 17 86 3GPP TS 36.300 V17.2.0 (2022-09)
6.1.2.2 Traffic Channels

Traffic channels are used for the transfer of user plane information only. The traffic channels offered by MAC are:
- Dedicated Traffic Channel (DTCH)
A Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE, for the transfer of user
information. A DTCH can exist in both uplink and downlink. DTCH is not supported for a NB-IoT UE that only
uses Control Plane CIoT EPS optimisations, as defined in TS 24.301 [20].
- Multicast Traffic Channel (MTCH)
A point-to-multipoint downlink channel for transmitting traffic data from the network to the UE. This channel is
only used by UEs that receive MBMS.
- Single-Cell Multicast Traffic Channel (SC-MTCH)
A point-to-multipoint downlink channel for transmitting traffic data from the network to the UE using SC-PTM
transmission. This channel is only used by UEs that receive MBMS using SC-PTM.
- Sidelink Traffic Channel (STCH)
A Sidelink Traffic Channel (STCH) is a point-to-multipoint channel, for transfer of user information from one
UE to other UE(s). This channel is used only by sidelink communication capable UEs and V2X sidelink
communication capable UEs. Point-to-point communication between two sidelink communication capable UEs
is also realized with an STCH.
6.1.3 Mapping between logical channels and transport channels

6.1.3.1 Mapping in Uplink
The figure below depicts the mapping between uplink logical channels and uplink transport channels:
Figure 6.1.3.1-1: Mapping between uplink logical channels and uplink transport channels
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.1.3.2 Mapping in Downlink

The figure below depicts the mapping between downlink logical channels and downlink transport channels:
3GPP
Release 17 87 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 6.1.3.2-1: Mapping between downlink logical channels and downlink 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;
- BR-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;
- MTCH can be mapped to MCH;
- MCCH can be mapped to MCH;
- SC-MTCH can be mapped to DL-SCH;
- SC-MCCH can be mapped to DL-SCH.
6.1.3.3 Mapping in Sidelink
Figure 6.1.3.3-1: Mapping between Sidelink logical channels and Sidelink transport channels
In Sidelink, the following connections between logical channels and transport channels exist:
- STCH can be mapped to SL-SCH;
- SBCCH can be mapped to SL-BCH.
3GPP
Release 17 88 3GPP TS 36.300 V17.2.0 (2022-09)
6.2 RLC Sublayer

6.2.0 General
This clause provides an overview on services, functions and PDU structure provided by the RLC sublayer. Note that:
- The reliability of RLC is configurable: some radio bearers may tolerate rare losses (e.g. TCP traffic);
- Radio Bearers are not characterized by a fixed sized data unit (e.g. a fixed sized RLC PDU).

The main services and functions of the RLC sublayer include:
- Transfer of upper layer PDUs;
- Error Correction through ARQ (only for AM data transfer);
- Concatenation, segmentation and reassembly of RLC SDUs (only for UM and AM data transfer);
- Re-segmentation of RLC data PDUs (only for AM data transfer);
- Reordering of RLC data PDUs (only for UM and AM data transfer);
- Duplicate detection (only for UM and AM data transfer);
- Protocol error detection (only for AM data transfer);
- RLC SDU discard (only for UM and AM data transfer);
- RLC re-establishment, as defined in TS 24.301 [20];
6.2.2 PDU Structure

Figure 6.2.2-1 below depicts the RLC PDU structure where:
- The PDU sequence number carried by the RLC header is independent of the SDU sequence number (i.e. PDCP
sequence number);
- A red dotted line indicates the occurrence of segmentation;
- Because segmentation only occurs when needed and concatenation is done in sequence, the content of an RLC
PDU can generally be described by the following relations:
- {0; 1} last segment of SDUi + [0; n] complete SDUs + {0; 1} first segment of SDUi+n+1 ; or
- 1 segment of SDUi.
Figure 6.2.2-1: RLC PDU Structure
3GPP
Release 17 89 3GPP TS 36.300 V17.2.0 (2022-09)
6.3 PDCP Sublayer

6.3.0 General
This clause provides an overview on services, functions and PDU structure provided by the PDCP sublayer.

Except for NB-IoT, the main services and functions of the PDCP sublayer for the user plane include:
- Header compression and decompression using ROHC and/or EHC ;
- Compression and decompression of uplink PDCP SDUs: DEFLATE based UDC only;
- Transfer of user data;
- In-sequence delivery of upper layer PDUs at PDCP re-establishment procedure for RLC AM;
- For split bearers in DC (only support for RLC AM) and LWA bearers (only support for RLC AM and RLC
UM): PDCP PDU routing for transmission and PDCP PDU reordering for reception;
- Duplicate detection of lower layer SDUs at PDCP re-establishment procedure for RLC AM;
- Retransmission of PDCP SDUs at handover and, for split bearers in DC and LWA, of PDCP PDUs at PDCP
data-recovery procedure, for RLC AM;
- Ciphering and deciphering;
- Timer-based SDU discard in uplink;
- Duplication of PDCP PDUs;
- For PDCP duplication, reordering and duplicate detection at the receiver.
For NB-IoT UE when AS security is activated, the main services and functions of the PDCP sublayer for the user plane
include:
- Header compression and decompression: ROHC only;
- Transfer of user data;
- In-sequence delivery of upper layer PDUs at PDCP re-establishment procedure for RLC AM;
- Duplicate detection of lower layer SDUs at PDCP re-establishment procedure for RLC AM;
- Ciphering and deciphering;
- Timer-based SDU discard in uplink.
NOTE 1: When compared to UTRAN, the lossless DL RLC PDU size change is not required.
The main services and functions of the PDCP for the control plane include:
- Ciphering and Integrity Protection;
- Transfer of control plane data.
Except for NB-IoT, the main services and functions of the PDCP sublayer for the control plane also include:
- Duplication of PDCP PDUs;
- For PDCP duplication, reordering and duplicate detection at the receiver.
NOTE 2: For a NB-IoT UE that only supports Control Plane CIoT EPS optimisation, as defined in TS 24.301 [20],
transfer or User Plane CIoT EPS optimisation, as defined in TS 24.301 [20], PDCP is not used until AS
security is activated.
3GPP
Release 17 90 3GPP TS 36.300 V17.2.0 (2022-09)
6.3.2 PDU Structure

Figure 6.3.2-1 below depicts the PDCP PDU structure for user plane data, where:
- PDCP PDU and PDCP header are octet-aligned;
- PDCP header can be either 1 , 2 or 5 bytes long.
Figure 6.3.2-1: PDCP PDU Structure
The structures for control PDCP PDUs and for control plane PDCP data PDUs are specified in TS 36.323 [15].

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;
- In both uplink and downlink, there is one independent hybrid-ARQ entity per serving cell and one transport
block is generated per TTI per serving cell in the absence of spatial multiplexing. Each transport block and its
potential HARQ retransmissions are mapped to a single serving cell;
- HARQ operation is asynchronous for Licensed-Assisted Access (LAA) SCells.
Figure 6.4-1: Layer 2 Structure for DL with CA configured
3GPP
Release 17 91 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 6.4-2: Layer 2 Structure for UL with CA configured
In case of CA in sidelink, which applies to V2X sidelink communication, there is one independent HARQ entity per
carrier used for V2X sidelink communication and one transport block is generated per TTI per carrier. Each transport
block and its potential HARQ retransmissions are mapped to a single carrier.
Figure 6.4-3: Layer 2 Structure for Sidelink with CA configured
6.5 Dual Connectivity

In case of DC, the UE is configured with two MAC entities: one MAC entity for MeNB and one MAC entity for SeNB.
Figure 6.5-1 below describes the layer 2 structure for the downlink when both CA and DC are configured. In order to
simplify the figure, the BCH, PCH, MCH and corresponding logical channels are not included. Also, only UEn is shown
as having DC configured.
3GPP
Release 17 92 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 6.5-1: Layer 2 Structure for DL with CA and DC configured
Figure 6.5-2 below describes the layer 2 structure for the uplink when both CA and DC are configured. As explained in
clause 4.9.2, SRBs are always handled by the MeNB and as a result, CCCH is only shown for the MeNB. For a split
bearer, UE is configured over which link (or both) the UE transmits UL PDCP PDUs by the MeNB. On the link which
is not responsible for UL PDCP PDUs transmission, the RLC layer only transmits corresponding ARQ feedback for the
downlink data.
Figure 6.5-2: Layer 2 Structure for UL with CA and DC configured
3GPP
Release 17 93 3GPP TS 36.300 V17.2.0 (2022-09)
7 RRC
7.0 General
This clause provides an overview on services and functions provided by the RRC sublayer.
7.1 Services and Functions

The main services and functions of the RRC sublayer include:
- Broadcast of System Information related to the non-access stratum (NAS);
- Broadcast of System Information related to the access stratum (AS);
- Paging;
- Establishment, maintenance and release of an RRC connection between the UE and E-UTRAN including:
- Allocation of temporary identifiers between UE and E-UTRAN;
- Configuration of signalling radio bearer(s) for RRC connection:
- Low priority SRB and high priority SRB;
- For NB-IoT, a UE dedicated SRB is supported before AS security is activated and only one UE dedicated SRB is
supported after AS security is activated;
- For a NB-IoT UE that supports S1-U data transfer or User Plane CIoT EPS optimisation, as defined in TS 24.301
[20]; or
- For a NB-IoT UE that supports NG-U data transfer or User Plane CIoT 5GS Optimisation, as defined in TS
24.501 [91]:
- One DRB is supported by default and up to two DRBs are supported optionally;
- For a UE that supports User Plane CIoT EPS optimisation, as specified in TS 24.301 [20]; or
- For a UE that supports User Plane CIoT 5GS Optimisation, as specified in TS 24.501 [91]:
- Suspension/resuming of the RRC connection;
- Security functions including key management;
- Establishment, configuration, maintenance and release of point to point Radio Bearers;
- Mobility functions including:
- UE measurement reporting and control of the reporting for inter-cell and inter-RAT mobility;
- Handover;
- UE cell selection and reselection and control of cell selection and reselection;
- Context transfer at handover.
- Notification and counting for MBMS services;
- Establishment, configuration, maintenance and release of Radio Bearers for MBMS services;
- QoS management functions;
- UE measurement reporting and control of the reporting;
- NAS direct message transfer to/from NAS from/to UE.
3GPP
Release 17 94 3GPP TS 36.300 V17.2.0 (2022-09)
7.2 RRC protocol states & state transitions

RRC uses the following states:
- RRC_IDLE:
- PLMN selection;
- DRX configured by NAS;
- Broadcast of system information;
- Paging;
- Cell re-selection mobility;
- The UE shall have been allocated an id which uniquely identifies the UE in a tracking area;
- No RRC context stored in the eNB and ng-eNB (except for a UE that supports User Plane CIoT EPS
optimisation, as specified in TS 24.301 [20] and User Plane CIoT 5GS Optimisation, as specified in TS
24.501 [91], where a context may be stored for the resume procedure);
- Sidelink communication transmission and reception;
- Sidelink discovery announcement and monitoring;
- V2X sidelink communication transmission and reception;
- NR sidelink communication transmission and reception;
- MO-EDT;
- MT-EDT;
- Transmission using PUR.
- RRC_CONNECTED:
- UE has an E-UTRAN-RRC connection;
- UE has context in E-UTRAN;
- E-UTRAN knows the cell which the UE belongs to;
- Network can transmit and/or receive data to/from UE;
- Network controlled mobility (handover and inter-RAT cell change order to GERAN with NACC);
- Neighbour cell measurements;
- Sidelink communication transmission and reception;
- Sidelink discovery announcement and monitoring;
- V2X sidelink communication transmission and reception;
- NR sidelink communication transmission and reception;
- At PDCP/RLC/MAC level:
- UE can transmit and/or receive data to/from network;
- UE monitors control signalling channel for shared data channel to see if any transmission over the shared
data channel has been allocated to the UE;
- UE also reports channel quality information and feedback information to eNB;
3GPP
Release 17 95 3GPP TS 36.300 V17.2.0 (2022-09)
- DRX period can be configured according to UE activity level for UE power saving and efficient resource
utilization. This is under control of the eNB.
E-UTRA connected to 5GC additionally supports RRC_INACTIVE state, which has the same characteristics as
RRC_INACTIVE of NR connected to 5GC, as specified in TS 38.300 [79].
7.3 Transport of NAS messages

The AS provides reliable in-sequence delivery of NAS messages in a cell. During handover, message loss or duplication
of NAS messages can occur.
In E-UTRAN, NAS messages are either concatenated with RRC messages or carried in RRC without concatenation.
Upon arrival of concurrent NAS messages for the same UE requiring both concatenation with RRC for the high priority
queue and also without concatenation for the lower priority queue, the messages are first queued as necessary to
maintain in-sequence delivery.
In downlink, when an EPS bearer (EPC) or PDU Session (5GC) establishment or release procedure is triggered, or for
EDT in case of Control Plane CIoT EPS optimisation or Control Plane CIoT 5GS Optimisation, the NAS message
should normally be concatenated with the associated RRC message. When the EPS bearer (EPC) or PDU Session
(5GC) is modified and when the modification also depends on a modification of the radio bearer, the NAS message and
associated RRC message should normally be concatenated. Concatenation of DL NAS with RRC message is not
allowed otherwise. In uplink, concatenation of NAS messages with RRC message is used only for transferring the initial
NAS message during connection setup and for EDT in case of Control Plane CIoT EPS optimisation or Control Plane
CIoT 5GS Optimisation. Initial Direct Transfer is not used in E-UTRAN and no NAS message is concatenated with
RRC connection request.
Multiple NAS messages can be sent in a single downlink RRC message during EPS bearer (EPC) or PDU Session
(5GC) establishment or modification. In this case, the order of the NAS messages in the RRC message shall be kept the
same as that in the corresponding S1-AP (EPC) or NG-AP (5GC) message in order to ensure the in-sequence delivery
of NAS messages.
NOTE: NAS messages are integrity protected and ciphered by PDCP, in addition to the integrity protection and
ciphering performed by NAS.
7.3a CIoT signalling reduction optimisations

7.3a.1 General
Which solution of CIoT signalling reduction optimisations to be used is configured over NAS signalling between the
UE and the MME or the AMF.
For NB-IoT, PDCP is not used while AS security is not activated.
7.3a.2 Control Plane CIoT EPS/5GS optimisation

The RRC connection established for Control Plane CIoT EPS optimisation, as defined in TS 24.301 [20], and Control
Plane CIoT 5GS Optimisation, as defined in TS 24.501 [91], are characterized as below:
- A UL NAS signalling message or UL NAS message carrying data can be transmitted in a UL RRC container
message (see Figure 7.3a.2-1). A DL NAS signaling or DL NAS data can be transmitted in a DL RRC container
message;
- for NB-IoT:
- RRC connection reconfiguration is not supported;
- Data radio bearer (DRB) is not used;
- AS security is not used;
- A non-anchor carrier can be configured for all unicast transmissions during RRC connection establishment or
re-establishment.
- There is no differentiation between the different data types (i.e. IP, non-IP or SMS) in the AS.
3GPP
Release 17 96 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 7.3a.2-1: The RRC connection established for Control Plane CIoT EPS/5GS Optimisations
7.3a.3 User Plane CIoT EPS/5GS optimisations

The RRC connection established for User Plane CIoT EPS Optimisation, as defined in TS 24.301 [20], and User Plane
CIoT 5GS Optimisation, as defined in TS 24.501 [91], are characterized as below:
- A RRC connection suspend procedure is used at RRC connection release, the (ng-)eNB may request the UE to
retain the UE AS context including UE capability in RRC_IDLE;
- A RRC connection resume procedure is used at transition from RRC_IDLE to RRC_CONNECTED where
previously stored information in the UE as well as in the (ng-)eNB is utilised to resume the RRC connection. In
the message to resume, the UE provides a Resume ID (for EPS) or I-RNTI (for 5GS) to be used by the (ng-)eNB
to access the stored information required to resume the RRC connection;
- At suspend-resume, security is continued. Re-keying is not supported in RRC connection resume procedure. The
short MAC-I is reused as the authentication token at RRC connection reestablishment procedure and RRC
connection resume procedure by the UE. For EPS, the eNB provides the NCC in the RRCConnectionResume
message as well. And also the UE resets the COUNT;
- Multiplexing of CCCH and DTCH in the transition from RRC_IDLE to RRC CONNECTED is not supported;
- For NB-IoT, a non-anchor carrier can be configured for all unicast transmissions when an RRC connection is re-
established, resumed or reconfigured additionally when an RRC connection is established.
The RRC connection suspend and resume procedures are illustrated in Figures 7.3a.3-1/7.3a.3-1a and 7.3a.3-2/7.3a.3-
2a, respectively. Note that the description here is only intended as an overview and all parameters are therefore not
listed in the message flows.
3GPP
Release 17 97 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 7.3a.3-1: RRC Connection Suspend procedure in EPS
Figure 7.3a.3-1a: RRC Connection Suspend procedure in 5GS
1. Due to some triggers, e.g. the expiry of a UE inactivity timer, the (ng-)eNB decides to suspend the RRC
connection.
2. In EPS, the eNB initiates the S1-AP UE Context Suspend procedure to inform the MME that the RRC
connection is being suspended. In 5GS, the ng-eNB initiates the NG-AP UE Context Suspend procedure to
inform the AMF that the RRC connection is being suspended.
3. In EPS, the MME requests the S-GW to release all S1-U bearers for the UE. In 5GS, the AMF requests the SMF
to suspend the PDU session and the SMF requests the UPF to release the tunnel information for the UE.
4. MME/AMF Acks step 2.
5. The (ng-)eNB suspends the RRC connection by sending an RRCConnectionRelease message with the
releaseCause set to rrc-Suspend. For EPS, the message includes the Resume ID which is stored by the UE and
optionally, for EDT and transmission using PUR, the message also includes the NextHopChainingCount which
is stored by the UE. For 5GS, the message includes the I-RNTI and NextHopChainingCount which are stored by
the UE.
3GPP
Release 17 98 3GPP TS 36.300 V17.2.0 (2022-09)
6. The UE stores the AS context, suspends all SRBs and DRBs, and enters RRC_IDLE.
Figure 7.3a.3-2: RRC Connection Resume procedure in EPS
Figure 7.3a.3-2a: RRC Connection Resume procedure in 5GS
1. At some later point in time (e.g. when the UE is being paged or when new data arrives in the uplink buffer) the
UE resumes the connection by sending an RRCConnectionResumeRequest to the (ng-)eNB. The UE includes its
Resume ID (for EPS) or I-RNTI (for 5GS), the establishment cause, and authentication token. The authentication
token is calculated in the same way as the short MAC-I used in RRC connection re-establishment and allows the
(ng-)eNB to verify the UE identity. For 5GS, the UE resumes SRB1, derives new security keys using the
NextHopChainingCount provided in the RRCConnectionRelease message of the previous RRC connection and
re-establishes the AS security.
2. Provided that the Resume ID (for EPS) or I-RNTI (for 5GS) exists and the authentication token is successfully
validated, the (ng-)eNB responds with an RRCConnectionResume. For EPS, the message includes the Next Hop
Chaining Count (NCC) value which is required in order to re-establish the AS security.
3. For EPS, the UE resumes all SRBs and DRBs and re-establishes the AS security. For 5GS, the UE resumes all
other SRBs and all DRBs. The UE is now in RRC_CONNECTED.
3GPP
Release 17 99 3GPP TS 36.300 V17.2.0 (2022-09)
4. The UE responds with an RRCConnectionResumeComplete confirming that the RRC connection was resumed
successfully, along with an uplink Buffer Status Report, and/or UL data, whenever possible, to the (ng-)eNB.
5. For EPS, the eNB initiates the S1-AP Context Resume procedure to notify the MME about the UE state change.
For 5GS, the ng-eNB initiates the NG-AP Context Resume procedure to notify the AMF about the UE state
change.
6. For EPS, the MME requests the S-GW to activate the S1-U bearers for the UE. For 5GS, the AMF requests the
SMF to resume the PDU session and the SMF requests the UPF to establish the tunnel information for the UE.
An RRC connection can also be resumed in an (ng-)eNB (the new (ng-)eNB) different from the one where the
connection was suspended (the old (ng-)eNB). Inter (ng-)eNB connection resumption is handled using context fetching,
whereby the new (ng-)eNB retrieves the UE context from the old (ng-)eNB over the X2/Xn interface. The new
(ng-)eNB provides the Resume ID (for EPS) or I-RNTI (for 5GS) which is used by the old (ng-)eNB to identify the UE
context. This is illustrated in Figure 7.3a.3-3/7.3a.3-3a.
Figure 7.3a.3-3: RRC Connection Resume procedure in different eNB in EPS
3GPP
Release 17 100 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 7.3a.3-3a: RRC Connection Resume procedure in different ng-eNB in 5GS
1. Same as step 1 in the intra (ng-)eNB connection resumption.
2. The new (ng-)eNB locates the old (ng-)eNB using the Resume ID (for EPS) or I-RNTI (for 5GS) and retrieves
the UE context by means of the X2-AP (for EPS) or Xn-AP (for 5GS) Retrieve UE Context procedure.
3. The old (ng-)eNB responds with the UE context associated with the Resume ID (for EPS) or I-RNTI (for 5GS).
7. For EPS, the new eNB initiates the S1-AP Path Switch procedure to establish a S1 UE associated signalling
connection to the serving MME and to request the MME to resume the UE context. For 5GS, the new ng-eNB
initiates the NG-AP Path Switch procedure to establish a NG UE associated signalling connection to the serving
AMF and to request the AMF to resume the UE context.
8. For EPS, the MME requests the S-GW to activate the S1-U bearers for the UE and updates the downlink path.
For 5GS, the AMF requests the SMF to resume the PDU session and the SMF requests the UPF to create the
tunnel information for the UE and update the downlink path.
10. For EPS, after the S1-AP Path Switch procedure the new eNB triggers release of the UE context at the old eNB
by means of the X2-AP UE Context Release procedure. For 5GS, after the NG-AP Path Switch procedure the
new ng-eNB triggers release of the UE context at the old ng-eNB by means of the Xn-AP UE Context Release
procedure.
For a NB-IoT UE that supports Control Plane CIoT EPS optimisation and S1-U data transfer or User Plane CIoT EPS
optimisation, as defined in TS 24.301 [20], and for a NB-IoT UE that supports Control Plane CIoT 5GS Optimisation
3GPP
Release 17 101 3GPP TS 36.300 V17.2.0 (2022-09)
and NG-U data transfer or User Plane CIoT 5GS Optimisation, as defined in TS 24.501 [91], PDCP is not used until AS
7.3b MO-EDT
7.3b.1 General
MO-EDT allows one uplink data transmission optionally followed by one downlink data transmission during the
random access procedure.
MO-EDT is triggered when the upper layers have requested the establishment or resumption of the RRC Connection for
Mobile Originated data (i.e., not signalling or SMS) and the uplink data size is less than or equal to a TB size indicated
in the system information. MO-EDT is not used for data over the control plane when using the User Plane CIoT
EPS/5GS optimisations.
MO-EDT is only applicable to BL UEs, UEs in enhanced coverage and NB-IoT UEs.
7.3b.2 MO-EDT for Control Plane CIoT EPS/5GS optimisations

MO-EDT for Control Plane CIoT EPS optimisation, as defined in TS 24.301 [20], and Control Plane CIoT 5GS
Optimisation, as defined in TS 24.501 [91], are characterized as below:
- Uplink user data are transmitted in a NAS message concatenated in UL RRCEarlyDataRequest message on
CCCH;
- Downlink user data are optionally transmitted in a NAS message concatenated in DL RRCEarlyDataComplete
message on CCCH;
- There is no transition to RRC CONNECTED.
The MO-EDT procedure for Control Plane CIoT EPS optimisation and Control Plane CIoT 5GS Optimisation are
illustrated in Figure 7.3b-1 and Figure 7.3b-1a respectively.
UE eNB MME S-GW

Random Access Preamble
Random Access Response
1. RRCEarlyDataRequest
(S-TMSI, establishmentCause, dedicatedInfoNAS)
2. S1-AP: Initial UE message (NAS message)
3. Modify Bearer
4. Uplink data
5. Downlink data
6a. S1-AP: DL NAS TRANSPORT
6b. S1-AP: CONNECTION

ESTABLISHMENT INDICATION
7. RRCEarlyDataComplete
(dedicatedInfoNAS)
8. S1 release procedure 8. Modify Bearer
Figure 7.3b-1: MO-EDT for Control Plane CIoT EPS Optimisation
3GPP
Release 17 102 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 7.3b-1a: MO-EDT for Control Plane CIoT 5GS Optimisation
0. Upon connection establishment request for Mobile Originated data from the upper layers, the UE initiates the
MO-EDT procedure and selects a random access preamble configured for EDT.
1. UE sends RRCEarlyDataRequest message concatenating the user data on CCCH. For EPS if enabled in the cell,
or for 5GS, the UE may indicate AS Release Assistance Information.
2. For EPS, the eNB initiates the S1-AP Initial UE message procedure to forward the NAS message and establish
the S1 connection. For 5GS, the ng-eNB initiates the NG-AP Initial UE message procedure to forward the NAS
message.The (ng-)eNB may indicate in this procedure that this connection is triggered for EDT.
3. For EPS, the MME requests the S-GW to re-activate the EPS bearers for the UE. For 5GS, the AMF determines
the PDU session contained in the NAS message.
4. For EPS, the MME sends the uplink data to the S-GW. For 5GS, the AMF sends the PDU Session ID and the
uplink data to the SMF and the SMF forwards the uplink data to the UPF.
5. For EPS, if downlink data are available, the S-GW sends the downlink data to the MME. For 5GS, if downlink
data are available, the UPF forwards the downlink data to SMF and the SFM forwards the downlink data to
AMF.
6. If downlink data are received from the S-GW or SMF, the MME or AMF forwards the data to the eNB or ng-
eNB via DL NAS Transport procedure and may also indicate whether further data are expected. Otherwise, the
MME or AMF may trigger Connection Establishment Indication procedure and also indicate whether further
data are expected.
7. If no further data are expected, the (ng-)eNB can send the RRCEarlyDataComplete message on CCCH to keep
the UE in RRC_IDLE. If downlink data were received in step 6, they are concatenated in
RRCEarlyDataComplete message.
8. For EPS, the S1 connection is released and the EPS bearers are deactivated. For 5GS, the AN release procedure
is started.
NOTE 1: If the MME/AMF or the (ng-)eNB decides to move the UE in RRC_CONNECTED mode,
RRCConnectionSetup message is sent in step 7 to fall back to the legacy RRC Connection establishment
procedure; the (ng-)eNB will discard the zero-length NAS PDU received in
RRCConnectionSetupComplete message.
NOTE 2: If neither RRCEarlyDataComplete nor, in case of fallback, RRCConnectionSetup is received in response

to RRCEarlyDataRequest, the UE considers the UL data transmission not successful.
3GPP
Release 17 103 3GPP TS 36.300 V17.2.0 (2022-09)
7.3b.3 MO-EDT for User Plane CIoT EPS/5GS optimisations

MO-EDT for User Plane CIoT EPS optimisation, as defined in TS 24.301 [20], and for User Plane CIoT 5GS
Optimisation, as defined in TS 24.501 [91], are characterized as below:
- The UE has been provided with a NextHopChainingCount in the RRCConnectionRelease message with suspend
indication;
- Uplink user data are transmitted on DTCH multiplexed with UL RRCConnectionResumeRequest message on
CCCH;
- Downlink user data are optionally transmitted on DTCH multiplexed with DL RRCConnectionRelease message
on DCCH;
- The short resume MAC-I is reused as the authentication token for RRCConnectionResumeRequest message and
is calculated using the integrity key from the previous connection;
- The user data in uplink and downlink are ciphered. The keys are derived using the NextHopChainingCount
provided in the RRCConnectionRelease message of the previous RRC connection;
- The RRCConnectionRelease message is integrity protected and ciphered using the newly derived keys;
The MO-EDT procedure for User Plane CIoT EPS optimisation is illustrated in Figure 7.3b-2.
Figure 7.3b-2: MO-EDT for User Plane CIoT EPS Optimisation
0. Upon connection resumption request for Mobile Originated data from the upper layers, the UE initiates the MO-
EDT procedure and selects a random access preamble configured for EDT.
1. The UE sends an RRCConnectionResumeRequest to the eNB, including its Resume ID, the establishment cause,
and an authentication token. The UE resumes all SRBs and DRBs, derives new security keys using the
NextHopChainingCount provided in the RRCConnectionRelease message of the previous RRC connection and
re-establishes the AS security. The user data are ciphered and transmitted on DTCH multiplexed with the
RRCConnectionResumeRequest message on CCCH. If enabled in the cell, the UE may indicate AS Release
Assistance Information.
2. The eNB initiates the S1-AP Context Resume procedure to resume the S1 connection and re-activate the S1-U
bearers.
3. The MME requests the S-GW to re-activate the S1-U bearers for the UE.
3GPP
Release 17 104 3GPP TS 36.300 V17.2.0 (2022-09)
4. The MME confirms the UE context resumption to the eNB.
5. The uplink data are delivered to the S-GW.
6. If downlink data are available, the S-GW sends the downlink data to the eNB.
7. If no further data are expected, the eNB can initiate the suspension of the S1 connection and the deactivation of
the S1-U bearers.
8. The eNB sends the RRCConnectionRelease message to keep the UE in RRC_IDLE. The message includes the
releaseCause set to rrc-Suspend, the resumeID, the NextHopChainingCount and drb-ContinueROHC which are
stored by the UE. If downlink data were received in step 6, they are sent ciphered on DTCH multiplexed with the
RRCConnectionRelease message on DCCH. The procedure ends with the reception of the HARQ feedback
(ARQ) acknowledging the successful DL transmission.
The MO-EDT procedure for User Plane CIoT 5GS Optimisation is illustrated in Figure 7.3b-2a.
Figure 7.3b-2a: MO-EDT for User Plane CIoT 5GS Optimisation
0. Upon connection resumption request for Mobile Originated data from the upper layers, the UE initiates the MO-
EDT procedure and selects a random access preamble configured for EDT.
1. The UE sends an RRCConnectionResumeRequest to the ng-eNB, including its I-RNTI, the resume cause, and an
authentication token. The UE resumes all SRBs and DRBs, derives new security keys using the
NextHopChainingCount provided in the RRCConnectionRelease message of the previous connection and re-
establishes the AS security. The user data are ciphered and transmitted on DTCH multiplexed with the
RRCConnectionResumeRequest message on CCCH. The UE may indicate AS Release Assistance Information.
2. The uplink data are delivered to the UPF.
3. The ng-eNB sends a NG-AP Context Resume Request message to the AMF to resume the connection. If the UE
included AS Release Assistance information indicating No further UL/DL higher layer PDU in step 1, ng-eNB
may request for immediate transition to RRC IDLE with Suspend.
4. If the AMF does not receive a request for immediate transition to RRC IDLE with Suspend in step 3 or the AMF
is aware of downlink data or signalling pending, the AMF requests the SMF to resume the PDU session.
5. The AMF sends a NG-AP Context Resume Response to the ng-eNB. If the AMF receives a request for
immediate transition to RRC IDLE with Suspend in step 3 and there is no downlink data or signalling pending,
the AMF includes a Suspend indication, and keeps the UE in CM-IDLE with Suspend.
6. If the AMF includes Suspend indication in step 5, the ng-eNB proceeds to step 8. If the AMF does not include
Suspend indication and the UE included AS Release Assistance information indicating Only a single Downlink
3GPP
Release 17 105 3GPP TS 36.300 V17.2.0 (2022-09)
Data transmission subsequent to the Uplink transmission in step 1, the ng-eNB may wait for the DL data to
arrive, and proceeds to step 7.
7 The ng-eNB initiates the NG-AP UE Context Suspend procedure to inform the AMF that the RRC connection is
being suspended. The AMF requests the SMF to suspend the PDU session and the SMF requests the UPF to
release the tunnel information for the UE.
8. The eNB sends the RRCConnectionRelease message to keep the UE in RRC_IDLE. The message includes the
releaseCause set to rrc-Suspend, the I-RNTI, the NextHopChainingCount and drb-ContinueROHC which are
stored by the UE. If downlink data were received in step 6, they are sent ciphered on DTCH multiplexed with the
RRCConnectionRelease message on DCCH. The procedure ends with the reception of the HARQ feedback
(ARQ) acknowledging the successful DL transmission.
NOTE 1: If the MME/AMF or (ng-)eNB decides the UE to move in RRC_CONNECTED mode,

RRCConnectionResume message is sent in step 7 to fall back to the RRC Connection resume procedure.
In that case, the RRCConnectionResume message is integrity protected and ciphered with the keys derived
in step 1 and the UE ignores the NextHopChainingCount included in the RRCConnectionResume
message. Downlink data can be transmitted on DTCH multiplexed with the RRCConnectionResume
message. In addition, an RRCConnectionSetup can also be sent in step 7 to fall back to the RRC
Connection establishment procedure.
NOTE 2: If neither RRCConnectionRelease nor, in case of fallback, RRCConnectionResume is received in response

to RRCConnectionResumeRequest for MO-EDT, the UE considers the UL data transmission not
successful.
For MO-EDT for User Plane CIoT EPS Optimisation and User Plane CIoT 5GS Optimisation, an RRC connection can
also be resumed in an (ng-)eNB (the new (ng-)eNB) different from the one where the connection was suspended (the
old (ng-)eNB). Inter (ng-)eNB connection resumption is handled using context fetching, whereby the new (ng-)eNB
retrieves the UE context from the old (ng-)eNB over the X2 (Xn) interface. The new (ng-)eNB provides the Resume ID
for EPS or I-RNTI for 5GS which is used by the old (ng-)eNB to identify the UE context. This is illustrated in Figure
7.3b-3 and Figure 7.3b-3a for the case of User Plane CIoT EPS Optimisation and for the case of User Plane CIoT 5GS
Optimisation respectively.
3GPP
Release 17 106 3GPP TS 36.300 V17.2.0 (2022-09)
Figure: 7.3b-3: MO-EDT for User Plane CIoT EPS Optimisations in different eNB
3GPP
Release 17 107 3GPP TS 36.300 V17.2.0 (2022-09)
Figure: 7.3b-3a: MO-EDT for User Plane CIoT 5GS Optimisation in different ng-eNB
2. The new (ng-)eNB locates the old (ng-)eNB using the Resume ID (for EPS) or I-RNTI (for 5GS) and retrieves
the UE context by means of the X2-AP (for EPS) or Xn-AP (for 5GS) Retrieve UE Context procedure.
3. The old (ng-)eNB responds with the UE context associated with the Resume ID (for EPS) or I-RNTI (for 5GS).
4. For EPS, the new eNB initiates the S1-AP Path Switch procedure to establish a S1 UE associated signalling
connection to the serving MME and to request the MME to resume the UE context. For 5GS, the new ng-eNB
initiates the NG-AP Path Switch procedure to establish a NG UE associated signalling connection to the serving
AMF and to request the AMF to resume the UE context.
5. For EPS, the MME requests the S-GW to activate the S1-U bearers for the UE and updates the downlink path.
For 5GS, the AMF requests requests the SMF to resume the PDU session and the SMF requests the UPF to
create the tunnel information for the UE and update the downlink path.
7. For EPS, after the S1-AP Path Switch procedure the new eNB triggers release of the UE context at the old eNB
by means of the X2-AP UE Context Release procedure. For 5GS, after the NG-AP Path Switch procedure the
new ng-eNB triggers release of the UE context at the old ng-eNB by means of the Xn-AP UE Context Release
procedure.
8. For EPS, same as step 5 in the intra eNB connection resumption. For 5GS, the uplink data are delivered to the
UPF.
3GPP
Release 17 108 3GPP TS 36.300 V17.2.0 (2022-09)
7.3c MT-EDT
7.3c.1 General
MT-EDT is intended for a single downlink data transmission during the random access procedure.
MT-EDT is initiated by the MME if the UE and the network support MT-EDT and there is a single DL data
transmission for the UE.
MT-EDT for Control Plane CIoT EPS Optimisation and for User Plane CIoT EPS Optimisation, as defined in TS
23.401 [17], is characterised as below:
- Support for MT-EDT for the Control Plane CIoT EPS Optimisation and/or for the User Plane CIoT EPS
Optimisation is reported by UE at NAS level;
- DL data size is included in the S1-AP Paging message for the UE;
- MT-EDT indication is included in the Paging message for the UE over the Uu interface;
- For User Plane CIoT EPS Optimisation, the UE has been provided with a NextHopChainingCount in the
RRCConnectionRelease message with suspend indication;
- In response to the Paging message including MT-EDT indication, the UE triggers the MO-EDT procedure for
Control Plane CIoT EPS Optimisation or for User Plane CIoT EPS Optimisation if the upper layers request the
establishment or resumption of the RRC Connection for Mobile Terminated Call;
MT-EDT is only applicable to BL UEs, UEs in enhanced coverage and NB-IoT UEs.
7.3c.2 MT-EDT for Control Plane CIoT EPS Optimisation

The MT-EDT procedure for Control Plane CIoT EPS Optimisation is illustrated in Figure 7.3c-1.
Figure 7.3c-1: MT-EDT for Control Plane CIoT EPS Optimisation
1. Upon arrival of downlink data, the SGW may send the DL data size information to the MME for MT-EDT
consideration by the MME.
2. The MME includes the DL data size information in the S1-AP PAGING message to assist eNodeB in triggering
MT-EDT.
3. If the data can fit in one single downlink transmission according to the UE category included in the UE Radio
Capability for Paging provided in the S1-AP Paging message, the eNB includes mt-EDT indication in the Paging
message for the UE.
4. The UE initiates the MO-EDT procedure for the Control Plane CIoT EPS Optimisation as described in clause
7.3b.2 with the following differences:
- In step 1, the UE sends RRCEarlyDataRequest message with the establishment cause mt-Access and without
user data.
3GPP
Release 17 109 3GPP TS 36.300 V17.2.0 (2022-09)
- In step 7, in case of fallback to the RRC Connection establishment procedure, the downlink data may
optionally be included in RRCConnectionSetup message.
7.3c.3 MT-EDT for User Plane CIoT EPS Optimisation

The MT-EDT procedure for User Plane CIoT EPS Optimisation is illustrated in Figure 7.3c-2.
Figure 7.3c-2: MT-EDT for User Plane CIoT EPS Optimisation
1. Upon arrival of downlink data, the SGW may send the DL data size to the MME for MT-EDT consideration by
the MME.
2. The MME includes the DL data size in the S1-AP PAGING message to assist eNodeB in triggering MT- EDT.
3. If the data can fit in one single downlink transmission according to the UE category included in the UE Radio
Capability for Paging provided in the S1-AP Paging message, the eNB includes mt-EDT indication in the Paging
message for the UE.
4. The UE initiates the MO-EDT procedure for the User Plane CIoT EPS Optimisation as described in clause
7.3b.3/ figure 7.3b-2 with the following differences:
- In step 0, the UE selects a random access preamble not configured for EDT;
- In step 1, the UE sends RRCConnectionResumeRequest message with the resume cause mt-EDT and without
user data.
- In step 4, the MME may include the Pending Data Indication in the S1AP UE Context Resume Response
message to notify the eNB of further data traffic in excess of that initially signalled in step 2. The eNB may
use this indication to decide whether to release the UE.
7.3d Transmission using PUR

7.3d.1 General
Transmission using PUR allows one uplink transmission from RRC_IDLE using a preconfigured uplink resource
without performing the random access procedure.
Transmission using PUR is enabled by the (ng-)eNB if the UE and the (ng-)eNB support.
The UE may request to be configured with a PUR or to have a PUR configuration released while in
RRC_CONNECTED mode. The (ng-)eNB decides to configure a PUR that may be based on UE's request, UE's
subscription information and/or local policy. The PUR is only valid in the cell where the configuration was received.
Transmission using PUR is triggered when the upper layers request the establishment or resumption of the RRC
Connection and the UE has a valid PUR for transmission and meets the TA validation criteria as specified in TS 36.331
[16].
Transmission using PUR is only applicable to BL UEs, UEs in enhanced coverage and NB-IoT UEs.
3GPP
Release 17 110 3GPP TS 36.300 V17.2.0 (2022-09)
7.3d.2 PUR Configuration Request and PUR configuration

The procedure for PUR configuration request and PUR configuration is common to the Control Plane CIoT EPS/5GS
optimisations and the User Plane CIoT EPS/5GS optimisations and is illustrated in Figure 7.3d-1.
Figure 7.3d-1: PUR Configuration Request and PUR Configuration
0. The UE is in RRC_CONNECTED and PUR is enabled in the cell.
1. The UE may indicate to the (ng-)eNB that it is interested in being configured with PUR by sending
PURConfigurationRequest message providing information about the requested resource (e.g. No. of occurences,
periodicity, time offset, TBS, RRC Ack, etc.). Alternatively, the UE may indicate to the (ng-)eNB in the
PURConfigurationRequest message that it is interested in the configured PUR to be released.
2. When the (ng-)eNB moves the UE to RRC_IDLE, based on a precedent UE PUR configuration request,
subscription information and/or local policies, the (ng-)eNB may decide to provide a PUR resource to the UE or
to release an existing PUR resource. The (ng-)eNB includes the details of the PUR configuration or a PUR
release indication in the RRCConnectionRelease message.
For UEs using the Control Plane CIoT EPS/5GS optimisations, the (ng-)eNB may provide a PUR configuration
ID with the PUR configuration. If available, the UE includes the PUR configuration ID in
RRCConnectionSetupComplete message when establishing RRC connection(s) not using the PUR resource.
NOTE 1: The PUR configuration can be implicitly released at the UE and (ng-)eNB, when the UE accesses in
another cell, when PUR is no longer enabled in the cell, or when the PUR resource has not been used for
a configured number of consecutive occasions.
NOTE 2: It is up to (ng-)eNB implementation how UE and PUR configuration are linked according to the
configured PUR resources.
7.3d.3 Transmission using PUR for Control Plane CIoT EPS/5GS

Optimisations
Transmission using PUR for Control Plane CIoT EPS Optimisation, as defined in TS 24.301 [20], and for Control Plane
CIoT 5GS Optimisation, as defined in TS 24.501 [91], is characterised as below:
- Uplink user data are transmitted using the PUR resource in a NAS message concatenated in
RRCEarlyDataRequest message on CCCH;
- If there is no downlink data, the (ng-)eNB may terminate the procedure by sending a layer 1 acknowledgement
optionally containing a Time Advance Command, a MAC Time advance Command or RRCEarlyDataComplete
with no user data;
- Downlink user data, if any, are transmitted in a NAS message concatenated in RRCEarlyDataComplete message
on CCCH;
The procedure for transmission using PUR for the Control Plane CIoT EPS optimisation and for the Control Plane CIoT
5GS optimisation is illustrated in Figure 7.3d-2.
3GPP
Release 17 111 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 7.3d-2: Transmission using PUR for the Control Plane CIoT EPS/5GS Optimisations
0. The UE has determined that the PUR resource can be used (e.g. PUR enabled in the cell, valid Time Alignment,
etc.).
1 Same as step 1 in MO-EDT for Control Plane CIoT EPS/5GS optimisations in Figure 7.3b-1 and 7.3b-1a except
that the UE transmits over the PUR resource instead of a resource allocated in the random access response.
If the uplink data are too large to be included in RRCEarlyDataRequest, the UE can use the PUR resource to
transmit RRCConnectionRequest. The procedure will fall back to the legacy RRC Connection establishment
procedure, a new C-RNTI can be assigned.
After step 1, the (ng-)eNB may request the UE to abort the transmission using PUR by sending a Layer 1
fallback indication. UE actions upon reception of Layer 1 fallback indication are left up to UE implementation.
2..6 Same as MO-EDT for Control Plane CIoT EPS/5GS Optimisations in Figure 7.3b-1 and 7.3b-1a.
7a If the (ng-)eNB is aware that there is no pending downlink data or signalling, the (ng-)eNB can send a Layer 1
ACK optionally containing a Time Advance Adjustment to the UE to update the TA and terminate the
procedure.
7b If the (ng-)eNB is aware that there is no further data or signalling, the (ng-)eNB can send a Time Advance
Command to update the TA and terminate the procedure.
7c Same as step 7 in MO-EDT for Control Plane CIoT EPS/5GS Optimisations in Figure 7.3b-1 and 7.3b-1a except
that a Time Advance Command can also be included.
NOTE 1: If the MME/AMF or the (ng-)eNB decides to move the UE to RRC_CONNECTED mode,
RRCConnectionSetup message is sent in step 7 to fall back to the legacy RRC Connection establishment
procedure, a new C-RNTI can be assigned. The (ng-)eNB will discard the zero-length NAS PDU received
in RRCConnectionSetupComplete message.
NOTE 2: If none of Layer 1 Ack, MAC Time advance Command, RRCEarlyDataComplete and, in case of fallback,
RRCConnectionSetup is received in response to RRCEarlyDataRequest, the UE considers the UL data
transmission not successful.
7.3d.4 Transmission using PUR for User Plane CIoT EPS/5GS

Optimisations
Transmission using PUR for User Plane CIoT EPS Optimisation, as defined in TS 24.301 [20], and for User Plane CIoT
5GS Optimisation, as defined in TS 24.501 [91], are characterised as below:
- The UE is in RRC_IDLE and has a valid PUR resource;
- The UE has been provided with a NextHopChainingCount in the RRCConnectionRelease message with suspend
indication;
3GPP
Release 17 112 3GPP TS 36.300 V17.2.0 (2022-09)
- Uplink user data are transmitted on DTCH multiplexed with RRCConnectionResumeRequest message on CCCH;
- Downlink user data are optionally transmitted on DTCH multiplexed with RRCConnectionRelease message on
DCCH;
- The user data in uplink and downlink are ciphered. The keys are derived using the NextHopChainingCount
provided in the RRCConnectionRelease message of the previous RRC connection;
- The RRCConnectionRelease message is integrity protected and ciphered using the newly derived keys;
The procedure for transmission using PUR for the User Plane CIoT EPS optimisation and for the User Plane CIoT 5GS
optimisation is illustrated in Figure 7.3d-3 and Figure 7.3d-4 respectively.
Figure 7.3d-3: Transmission using PUR for the User Plane CIoT EPS Optimisation
Figure 7.3d-4: Transmission using PUR for the User Plane CIoT 5GS Optimisation
0. The UE has validated the PUR resource according to the configured criteria.
1 Same as step 1 in MO-EDT for User Plane CIoT EPS/5GS optimisations in Figure 7.3b-2 and 7.3b-2a except
that the UE transmits over the PUR resource instead of a resource allocated in the random access response.
If the user data are too large to be fully included in the transmission using PUR, the UE can use PUR to transmit
RRCConnectionResumeRequest and a segment of the user data. The procedure will fall back to the legacy RRC
Connection Resume procedure; a new C-RNTI can be assigned.
After step 1, the (ng-)eNB may request the UE to abort the transmission using PUR by sending a Layer 1
fallback indication. UE actions upon reception of Layer 1 fallback indication are left up to UE implementation.
2..7 Same as MO-EDT for User Plane CIoT EPS/5GS optimisations in Figure 7.3b-2 and 7.3b-2a.
8 Same as step 8 in MO-EDT for user Plane CIoT EPS/5GS optimisations in Figure 7.3b-2 and 7.3b-2a except that
a Time Advance Command can also be included.
3GPP
Release 17 113 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE 1: If the MME/AMF or the (ng-)eNB decides to move the UE to RRC_CONNECTED mode,
RRCConnectionResume message is sent in step 8 to fall back to the RRC Connection resume procedure.
In that case, the RRCConnectionResume message is integrity protected and ciphered with the keys derived
in step 1 and the UE ignores the NextHopChainingCount included in the RRCConnectionResume
message; a new C-RNTI can be assigned. Downlink data can be transmitted on DTCH multiplexed with
the RRCConnectionResume message. In addition, an RRCConnectionSetup can also be sent in step 8 to
fall back to the RRC Connection establishment procedure.
NOTE 2: If neither RRCConnectionRelease nor, in case of fallback, RRCConnectionResume is received in response

to RRCConnectionResumeRequest using PUR, the UE considers the UL data transmission not successful.
7.4 System Information

System information is divided into the MasterInformationBlock (MIB) and a number of SystemInformationBlocks
(SIBs):
- MasterInformationBlock defines the most essential physical layer information of the cell required to receive
further system information;
- SystemInformationBlockPos contains positioning assistance data;
- SystemInformationBlockType1 and SystemInformationBlockType1-BR (for a BL UE or UE in enhanced

coverage) contain information relevant when evaluating if a UE is allowed to access a cell and defines the
scheduling of other system information blocks;
- SystemInformationBlockType2 contains common and shared channel information;
- SystemInformationBlockType3 contains cell re-selection information, mainly related to the serving cell;
- SystemInformationBlockType4 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);
- SystemInformationBlockType5 contains information about other E-UTRA frequencies and inter-frequency

as well as cell specific re-selection parameters). It can also contain information about E-UTRA and NR
idle/inactive measurements;
- SystemInformationBlockType6 contains information about UTRA frequencies and 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);
- SystemInformationBlockType7 contains information about GERAN frequencies relevant for cell re-selection
(including cell re-selection parameters for each frequency);
- SystemInformationBlockType8 contains information about CDMA2000 frequencies and CDMA2000

as well as cell specific re-selection parameters);
- SystemInformationBlockType9 contains a home eNB name (HNB name);
- SystemInformationBlockType10 contains an ETWS primary notification;
- SystemInformationBlockType11 contains an ETWS secondary notification;
- SystemInformationBlockType12 contains a CMAS warning notification;
- SystemInformationBlockType13 contains MBMS-related information;
- SystemInformationBlockType14 contains information about Extended Access Barring for access control;
- SystemInformationBlockType15 contains information related to mobility procedures for MBMS reception;
- SystemInformationBlockType16 contains information related to GPS time and Coordinated Universal Time
(UTC);
3GPP
Release 17 114 3GPP TS 36.300 V17.2.0 (2022-09)
- SystemInformationBlockType17 contains information relevant for traffic steering between E-UTRAN and
WLAN;
- SystemInformationBlockType18 contains information related to sidelink communication;
- SystemInformationBlockType19 contains information related to sidelink discovery;
- SystemInformationBlockType20 contains information related to SC-PTM;
- SystemInformationBlockType21 contains information related to V2X sidelink communication;
- SystemInformationBlockType24 contains information about NR frequencies and NR neighbouring cells relevant

for cell re-selection (including cell re-selection parameters common for a frequency), which can also be used for
NR idle/inactive measurements;
- SystemInformationBlockType25 contains information about UAC parameters;
- SystemInformationBlockType26 contains additional information related to V2X sidelink communication;
- SystemInformationBlockType26a contains information related to NR bands list which can be used for EN-DC
operation with the serving cell;
- SystemInformationBlockType27 contains assistance information for inter-RAT cell selection to NB-IoT;
- SystemInformationBlockType28 contains information related to NR sidelink communication;
- SystemInformationBlockType29 contains information related to common resource reservation;
- SystemInformationBlockType30 contains information related to disaster roaming;
- SystemInformationBlockType31 contains information required for accessing an NTN cell;
- SystemInformationBlockType32 contains assistance information for discontinuous coverage in NTN.
System information for NB-IoT is divided into the MasterInformationBlock-NB (MIB-NB) and a number of
SystemInformationBlocks-NB (SIBs-NB):
- MasterInformationBlock-NB defines the most essential information of the cell required to receive further system
information;
- SystemInformationBlockType1-NB contains information relevant when evaluating if a UE is allowed to access a

cell and defines the scheduling of other system information blocks;
- SystemInformationBlockType2-NB contains common radio resource configuration information;
- SystemInformationBlockType3-NB contains cell re-selection information for intra-frequency, inter-frequency;
- SystemInformationBlockType4-NB contains neighboring cell related information relevant for intra-frequency cell
re-selection;
- SystemInformationBlockType5-NB contains neighboring cell related information relevant for inter-frequency cell
re-selection;
- SystemInformationBlockType14-NB contains information about access barring;
- SystemInformationBlockType15-NB contains information related to mobility procedures for MBMS reception;
- SystemInformationBlockType16-NB contains information related to GPS time and Coordinated Universal Time
(UTC);
- SystemInformationBlockType20-NB contains information related to SC-PTM;
- SystemInformationBlockType22-NB contains common radio resource configuration information for paging and
random access procedure on non-anchor carriers;
- SystemInformationBlockType23-NB contains common additional radio resource configuration information for

random access procedure on anchor and non-anchor carriers;
3GPP
Release 17 115 3GPP TS 36.300 V17.2.0 (2022-09)
- SystemInformationBlockType27-NB contains assistance information for inter-RAT cell selection to E-UTRAN

and/or GERAN;
- SystemInformationBlockType31-NB contains information required for accessing an NTN cell;
- SystemInformationBlockType32-NB contains assistance information for discontinuous coverage in NTN.
On MBMS-dedicated cell, only system information relevant for receiving MBMS service is broadcasted.
MasterInformationBlock-MBMS (MIB-MBMS) and SystemInformationBlockType1-MBMS (SIB1-MBMS) are used
instead of MIB and SIB1 respectively:
- MasterInformationBlock-MBMS defines the most essential physical layer information of the cell required to
receive further system information on MBMS-dedicated cell;
- SystemInformationBlockType1-MBMS contains information relevant for receiving MBMS service and defines
the scheduling of other system information blocks on MBMS-dedicated cell;
The MIB is mapped on the BCCH and carried on BCH while all other SI messages are mapped on the BCCH and BR-
BCCH, and carried on DL-SCH. Except for BL UEs, UEs in enhanced coverage and NB-IoT UEs, all other SI messages
than the MIB which are dynamically carried on DL-SCH, can be identified through the SI-RNTI (System Information
RNTI). Both the MIB and SystemInformationBlockType1 (SystemInformationBlockType1-BR for BL UEs and UEs in
enhanced coverage) use a fixed schedule with a periodicity of 40 and 80 ms respectively. The scheduling of other SI
messages is flexible and indicated by SystemInformationBlockType1 (SystemInformationBlockType1-BR for BL UEs
and UEs in enhanced coverage, and SystemInformationBlockType1-NB for NB-IoT). For NB-IoT, the MIB-NB is
mapped on the BCCH and carried on BCH while all other SI messages are mapped on the BCCH and carried on DL-
SCH. Both the MIB-NB and SystemInformationBlockType1-NB use a fixed schedule with a periodicity of 640 and 2560
ms respectively. The MIB-NB contains all information required to acquire SIB1-NB and SIB1-NB contains all
information required to acquire other SI messages.
On MBMS-dedicated cell, the MIB-MBMS and SIB1-MBMS use a fixed schedule with a periodicity of 160 ms.
Additionally, SIB1-MBMS may be scheduled in additional non-MBSFN subframes indicated in MIB-MBMS.
For NB-IoT, in TDD mode, the MIB-TDD-NB is transmitted on the same NB-IoT carrier as NPSS/NSSS,
SystemInformationBlockType1-NB can be transmitted on NB-IoT carrier other than the MIB-NB, and the SI messages
can be transmitted on a NB-IoT carrier other than the MIB-NB. At most two NB-IoT carriers are used to transmit the
MIB-NB, SystemInformationBlockType1-NB and the SI messages.
Except for NB-IoT, the eNB may schedule DL-SCH transmissions concerning logical channels other than BCCH or
BR-BCCH in the same subframe as used for BCCH or BR-BCCH. The minimum UE capability restricts the BCCH or
BR-BCCH mapped to DL-SCH e.g. regarding the maximum rate.
The Paging message is used to inform UEs in RRC_IDLE and UEs in RRC_CONNECTED about a system information
change. For NB-IoT UEs, BL UEs, and UEs in CE, the UE is not required to detect SIB changes when in
RRC_CONNECTED, and the network may release the NB-IoT UE, BL UE or UE in CE to RRC_IDLE if it wants the
NB-IoT UE, BL UE or UE in CE to acquire changed SIB(s).
Except for NB-IoT, system information may also be provided to the UE by means of dedicated signalling e.g. upon
handover.

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 (e.g. TAI), and at RRC connection re-
establishment/handover, one serving cell provides the security input. This cell is referred to as the Primary Cell (PCell).
In the downlink, the carrier corresponding to the PCell is the Downlink Primary Component Carrier (DL PCC) while in
the uplink it is the Uplink Primary Component Carrier (UL PCC).
Depending on UE capabilities, Secondary Cells (SCells) can be configured to form together with the PCell a set of
serving cells. In the downlink, the carrier corresponding to an SCell is a Downlink Secondary Component Carrier (DL
SCC) while in the uplink it is an Uplink Secondary Component Carrier (UL SCC).
The configured set of serving cells for a UE therefore always consists of one PCell and one or more SCells:
3GPP
Release 17 116 3GPP TS 36.300 V17.2.0 (2022-09)
- For each SCell the usage of uplink resources by the UE in addition to the downlink ones is configurable (the
number of DL SCCs configured is therefore always larger than or equal to the number of UL SCCs and no SCell
can be configured for usage of uplink resources only);
- An SCell may be configured to start in either deactivated, dormant or activated mode;
- From a UE viewpoint, each uplink resource only belongs to one serving cell;
- The number of serving cells that can be configured depends on the aggregation capability of the UE (see clause
5.5);
- PCell can only be changed with handover procedure (i.e. with security key change and, unless RACH-less HO is
configured, with RACH procedure);
- PCell is used for transmission of PUCCH;
- If DC is not configured one additional PUCCH can be configured on an SCell, the PUCCH SCell;
- Unlike SCells, PCell cannot be de-activated or be in dormant SCell state (see clause 11.2);
- Re-establishment is triggered when PCell experiences RLF, not when SCells experience RLF;
- NAS information is taken from PCell.
The reconfiguration, addition and removal of SCells can be performed by RRC. During connection resume from
suspended RRC connection or from RRC_INACTIVE, the network may decide to keep or release any previously
configured SCells from the UE context. At intra-LTE handover and during connection resume from RRC_INACTIVE,
the network can also add, remove, 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 broadcasted system information directly from the SCells. A common configuration, applicable for
multiple SCells, may be provided in addition to dedicated SCell configuration.
When a PUCCH SCell is configured, RRC configures the mapping of each serving cell to Primary PUCCH group or
Secondary PUCCH group, i.e., for each SCell whether the PCell or the PUCCH SCell is used for the transmission of
ACK/NAKs and CSI reports. A PUCCH SCell cannot be in dormant state.
For LAA SCell the following additional principles are applied:
- The eNB can configure whether the data of a logical channel can be transferred via LAA SCells.
7.6 Dual Connectivity

In DC, the configured set of serving cells for a UE consists of two subsets: the Master Cell Group (MCG) containing
the serving cells of the MeNB, and the Secondary Cell Group (SCG) containing the serving cells of the SeNB.
When a UE is configured with CA in the MCG, the same principles as described in clause 7.5 apply to MCG.
For SCG, the following principles are applied:
- At least one cell in SCG has a configured UL CC and one of them, named PSCell, is configured with PUCCH
resources;
- When SCG is configured, there is always at least one SCG bearer or one Split bearer;
- Upon detection of a physical layer problem or a random access problem on PSCell, or the maximum number of
RLC retransmissions has been reached associated with the SCG, or upon detection of an access problem on
PSCell (T307 expiry) during SCG change, or when exceeding the maximum transmission timing difference
between CGs:
- RRC connection Re-establishment procedure is not triggered;
- All UL transmissions towards all cells of the SCG are stopped;
- MeNB is informed by the UE of SCG failure type;
- For split bearer, the DL data transfer over the MeNB is maintained.
3GPP
Release 17 117 3GPP TS 36.300 V17.2.0 (2022-09)
- Only the RLC AM bearer can be configured for the split bearer;
- Like PCell, PSCell cannot be de-activated and cannot be in dormant SCell state (see clause 11.2);
- PSCell can only be changed with SCG change (i.e. with security key change and, unless RACH-less HO is
configured, with RACH procedure);
- Neither direct bearer type change between Split bearer and SCG bearer nor simultaneous configuration of SCG
and Split bearer are supported.
With respect to the interaction between MeNB and SeNB, the following principles are applied:
- Logical channel identities are independently allocated by the MeNB and the SeNB.
- The MeNB maintains the RRM measurement configuration of the UE and may, e.g. based on received
measurement reports or traffic conditions or bearer types, decide to ask a SeNB to provide additional resources
(serving cells) for a UE.
- Upon receiving the request from the MeNB, a SeNB may create the container that will result in the configuration
of additional serving cells for the UE (or decide that it has no resource available to do so).
- For UE capability coordination, the MeNB provides (part of) the AS configuration and the UE capabilities to the
SeNB.
- The MeNB and the SeNB exchange information about UE configuration by means of RRC containers (inter-
node messages) carried in X2 messages.
- The SeNB may initiate a reconfiguration of its existing serving cells (e.g., PUCCH towards the SeNB).
- The SeNB decides which cell is the PSCell within the SCG.
- The MeNB does not change the content of the RRC configuration provided by the SeNB.
- In the case of the SCG addition and SCG SCell addition, the MeNB may provide the latest measurement results
for the SCG cell(s).
- Both MeNB and SeNB know the SFN and subframe offset of each other by OAM or UE measurement, e.g., for
the purpose of DRX alignment and identification of measurement gap.
When adding a new SCG SCell, dedicated RRC signalling is used for sending all required system information of the
cell as for CA described in clause 7.5, except for the SFN acquired from MIB of the PSCell of SCG.
7.7 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.
In this version of the specification, segmentation applies only to the UECapabilityInformation,

RRCConnectionReconfiguration, and RRCConnectionResume messages.
8 E-UTRAN identities
8.1 E-UTRA related UE identities
The following E-UTRA related UE identities are used at cell level:
- C-RNTI: unique identification used for identifying RRC Connection and scheduling;
- Semi-Persistent Scheduling C-RNTI: unique identification used for semi-persistent scheduling;
- Temporary C-RNTI: identification used for the random access procedure;
3GPP
Release 17 118 3GPP TS 36.300 V17.2.0 (2022-09)
- TPC-PUSCH-RNTI: identification used for the power control of PUSCH;
- TPC-PUCCH-RNTI: identification used for the power control of PUCCH;
- SL-RNTI: identification used for sidelink communication scheduling;
- SL-V-RNTI: identification used for V2X sidelink communication scheduling;
- Random value for contention resolution: during some transient states, the UE is temporarily identified with a
random value used for contention resolution purposes;
- SRS-TPC-RNTI: identification used for triggering group SRS and power control of SRS for SRS-only SCells;
- SL Semi-Persistent Scheduling V-RNTI: identification used for semi-persistent scheduling for V2X sidelink
communication;
- UL Semi-Persistent Scheduling V-RNTI: identification used for multiple semi-persistent scheduling for UE
capable of V2X communication;
- AUL C-RNTI: unique identification used for autonomous uplink scheduling;
- PUR-RNTI: identification used for transmission using PUR.
In DC, two C-RNTIs are independently allocated to the UE: one for MCG, and one for SCG.
The following UE identity is only used for E-UTRA connected to EPC:
- Resume ID: unique identification used for the RRC connection resume procedure;
The following UE identity is only used for E-UTRA connected to 5GC:
- I-RNTI: unique identification used for the RRC connection resume procedure in RRC_INACTIVE or for the
User Plane CIoT 5GS Optimisation as specified for NR connected to 5GC in TS 38.300 [79];
8.2 Network entity related Identities

The following identities are used in E-UTRAN for identifying a specific network entity TS 36.413 [25]:
- Globally Unique MME Identity (GUMMEI): used to identify MME globally. The GUMMEI is constructed from
the PLMN identity the MME belongs to, the group identity of the MME group the MME belongs to and the
MME code (MMEC) of the MME within the MME group.
NOTE: GUMMEI or S-TMSI containing the MMEC is provided by the UE to the eNB according to TS 23.401
[17], TS 24.301 [20] and TS 36.331 [16].
- E-UTRAN Cell Global Identifier (ECGI): used to identify cells globally. The ECGI is constructed from the
PLMN identity the cell belongs to and the E-UTRA Cell Identifier of the cell. The included PLMN is the one
given by the first PLMN entry in SIB1 associated with the E-UTRA Cell Identifier of the cell, according to TS
36.331 [16].
- eNB Identifier (eNB ID): used to identify eNBs within a PLMN. The eNB ID is contained within the E-UTRA
Cell Identifier of its cells.
- Global eNB ID: used to identify eNBs globally. The Global eNB ID is constructed from the PLMN identity the
eNB belongs to and the eNB ID. The MCC and MNC are the same as included in the E-UTRAN Cell Global
Identifier (ECGI).
- The Global eNB ID of RN is the same as its serving DeNB.
- Tracking Area identity (TAI): used to identify tracking areas allocated by EPC or 5GC. The TAI is constructed
from the PLMN identity the tracking area belongs to and the TAC (Tracking Area Code) of the Tracking Area.
The TACs allocated to an ng-eNB by EPC and 5GC are separate.
- CSG identity (CSG ID): used to identify a CSG within a PLMN.
- EPS Bearer ID / E-RAB ID:
3GPP
Release 17 119 3GPP TS 36.300 V17.2.0 (2022-09)
- The value of the E-RAB ID used at S1 and X2 interfaces to identify an E-RAB allocated to the UE is the
same as the EPS Bearer ID value used at the Uu interface to identify the associated EPS Bearer (and also
used at the NAS layer as defined in TS 36.413 [25]).
- NR Cell Global Identifier (NCGI): specified in TS 38.300 [79].
- en-gNB Identifier (en-gNB ID): as specified for the gNB Identifier in TS 38.300 [79].
- Global en-gNB ID: as specified for the Global gNB ID in TS 38.300 [79].
The following identities are broadcast in every E-UTRAN cell (SIB1): CI, TAC, CSG ID (if any) and one or more
PLMN identities.
8.3 Sidelink communication and V2X Sidelink Communication

related identities
The following identities are used for sidelink communication and V2X sidelink communication:
- Source Layer-2 ID: Identifies the sender of the data in sidelink communication and V2X sidelink
communication. The Source Layer-2 ID is 24 bits long and is used together with Destination Layer-2 ID and
LCID for identification of the RLC UM entity and PDCP entity in the receiver;
- Destination Layer-2 ID: Identifies the target of the data in sidelink communication and V2X sidelink
communication. For 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 (8 bits) of Destination Layer-2 ID and forwarded to physical layer as Group
Destination ID. This identifies the target of the intended data in sidelink control information and is used for
filtering of packets at the physical layer.
- Second bit string is the MSB part (16 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.
- In case of V2X sidelink communication, Destination Layer-2 ID is not split and is carried within the MAC
header.
No Access Stratum signalling is required for group formation and to configure Source Layer-2 ID, Destination Layer-2
ID and Group Destination ID in the UE. These identities are either provided by higher layer or derived from identities
provided by higher layer. In case of groupcast and broadcast, the ProSe UE ID, as specified in TS 23.303 [62], provided
by higher layer is used directly as the Source Layer-2 ID and the ProSe Layer-2 Group ID, as specified in TS 23.303
[62], provided by higher layer is used directly as the Destination Layer-2 ID in the MAC layer. In case of one-to-one
communications, the ProSe UE ID, as specified in TS 23.303 [62], provided by higher layer is used directly as the
Source Layer-2 ID or the Destination Layer-2 ID in the MAC layer. In case of V2X sidelink communication, higher
layer provides Source Layer-2 ID and Destination Layer-2 ID, as specified in TS 23.285 [72].
8.4 MBMS related identities

The following identities are used for SC-PTM transmission:
- SC-RNTI: Identifies transmissions of the SC-MCCH, and for NB-IoT UEs, BL UEs or UEs in enhanced
coverage identifies SC-MCCH change notification;
- SC-N-RNTI: Identifies SC-MCCH change notification for UEs other than NB-IoT UEs, BL UEs or UEs in
enhanced coverage;
- G-RNTI: Identifies transmissions of a SC-MTCH, and for NB-IoT UEs, BL UEs or UEs in enhanced coverage
identifies SC-MCCH change notification.
3GPP
Release 17 120 3GPP TS 36.300 V17.2.0 (2022-09)
9 ARQ and HARQ

9.0 General
E-UTRAN provides ARQ and HARQ functionalities. The ARQ functionality provides error correction by
retransmissions in acknowledged mode at Layer 2. The HARQ functionality ensures delivery between peer entities at
Layer 1.
9.1 HARQ principles

The HARQ within the MAC sublayer has the following characteristics:
- HARQ transmits and retransmits transport blocks;
- In the downlink:
- N-process Stop-And-Wait;
- Asynchronous adaptive HARQ;
- Uplink ACK/NAKs in response to downlink (re)transmissions are sent on PUCCH or PUSCH (except for
NB-IoT and short TTI);
- For BL UEs or UEs in enhanced coverage, uplink ACK/NAKs are sent in response to transmission
bundles;
- For NB-IoT, Uplink ACK/NAKs in response to downlink (re)transmissions are sent on NPUSCH;
- For short TTI, Uplink ACK/NAKs in response to downlink (re)transmissions are sent on SPUCCH or
(sub)slot-PUSCH;
- PDCCH, MPDCCH, NPDCCH or SPDCCH signals the HARQ process identifier (except for NB-IoT when
only one HARQ process is configured) and if it is a transmission or retransmission;
- Retransmissions are always scheduled through PDCCH, MPDCCH, NPDCCH or SPDCCH.
- In the uplink:
- N-process Stop-And-Wait;
- Synchronous HARQ (except for the cases below;
- Asynchronous adaptive HARQ for NB-IoT, BL UEs, UEs in enhanced coverage, HARQ processes scheduled
with (sub)slot based PUSCH, HARQ processes scheduled with SPT, or for HARQ processes not configured
with AUL operation for SCells configured with uplink LAA or for SCells configured with PUSCH
enhancement mode;
- Autonomous HARQ for HARQ processes configured with AUL operation for SCells configured with uplink
LAA;
- Maximum number of retransmissions configured per UE (as opposed to per radio bearer) for synchronous
HARQ;
- For asynchronous adaptive HARQ, HARQ process identifier is either signalled by PDCCH, MPDCCH,
NPDCCH or SPDCCH, except for NB-IoT when only one HARQ process is configured the HARQ process
identifier is fixed (see clause 5.4.2.1 in TS 36.321 [13]);
- For Autonomous HARQ, UE selects HARQ process identifier from a pool of configured HARQ processes;
- Downlink ACK/NAKs in response to uplink (re)transmissions are sent on PHICH except for asynchronous
adaptive HARQ and autonomous HARQ;
- For autonomous HARQ, downlink ACK/NAKs in response to uplink (re)transmissions are sent on PDCCH;
3GPP
Release 17 121 3GPP TS 36.300 V17.2.0 (2022-09)
- HARQ operation in uplink is governed by the following principles (summarized in Table 9.1-1) except for
asynchronous adaptive HARQ:
1) Regardless of the content of the HARQ feedback (ACK or NACK), when a PDCCH for the UE is
correctly received, the UE follows what the PDCCH asks the UE to do i.e. perform a transmission or a
retransmission (referred to as adaptive retransmission);
2) When no PDCCH addressed to the C-RNTI of the UE is detected, the HARQ feedback dictates how the
UE performs retransmissions:
- NACK: the UE performs a non-adaptive retransmission i.e. a retransmission on the same uplink
resource as previously used by the same process;
- ACK: the UE does not perform any UL (re)transmission and keeps the data in the HARQ buffer. A
PDCCH is then required to perform a retransmission i.e. a non-adaptive retransmission cannot follow.
- For asynchronous adaptive HARQ, HARQ feedback is not sent, except for BL UEs and UEs in enhanced
coverage. The UE follows what the PDCCH, MPDCCH, NPDCCH or SPDCCH asks the UE to do i.e.
perform a transmission or a retransmission. For BL UEs or UEs in enhanced coverage, downlink ACK in
response to uplink (re)transmissions may be sent in the DCI with C-RNTI or SPS C-RNTI scheduling
MPDCCH.
- In the sidelink:
- No HARQ feedback;
- Retransmissions are always performed in a pre-defined/ configured number.
- Measurement gaps and sidelink discovery transmission during a sidelink discovery gap for transmission are of
higher priority than HARQ retransmissions: whenever an HARQ retransmission collides with a measurement
gap or sidelink discovery transmission during a sideink discovery gap for transmission, the HARQ
retransmission does not take place.
Table 9.1-1: UL synchronous HARQ Operation
HARQ feedback PDCCH

UE behaviour
seen by the UE seen by the UE
ACK or NACK New Transmission New transmission according to PDCCH
Retransmission according to PDCCH
ACK or NACK Retransmission
(adaptive retransmission)
No (re)transmission, keep data in HARQ
ACK None buffer and a PDDCH is required to resume
retransmissions
NACK None Non-adaptive retransmission
9.2 ARQ principles

The ARQ within the RLC sublayer has the following characteristics:
- ARQ retransmits RLC PDUs or RLC PDU 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 PDU or RLC PDU segment.
3GPP
Release 17 122 3GPP TS 36.300 V17.2.0 (2022-09)
9.3 Void
10 Mobility
10.0 General
Load balancing is achieved in E-UTRAN with handover, redirection mechanisms upon RRC release, DC 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 mobility are classified in at least four measurement types:
- Intra-frequency E-UTRAN measurements;
- Inter-frequency E-UTRAN measurements;
- Inter-RAT measurements for UTRAN and GERAN;
- Inter-RAT measurements of CDMA2000 HRPD or 1xRTT frequencies.
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 same RAT). By using
several measurement identities (one for each measurement object, reporting configuration pair) it is possible:
- To associate several reporting configurations to one measurement object and;
- To associate one reporting configuration to several measurement objects.
The measurements identity is as well used when reporting results of the measurements.
Measurement quantities are considered separately for each RAT.
Measurement commands are used by E-UTRAN to order the UE to start measurements, modify measurements or stop
measurements.
For NB-IoT:
- Handover, measurement reports and inter-RAT mobility are not supported;
- 10.1.1 Mobility Management in ECM-IDLE, 10.1.3 Measurements, 10.1.4 Paging and C-plane establishment,
10.1.5 Random Access Procedure, 10.1.6 Radio Link Failure, 10.1.7 Radio Access Network Sharing and all their
clauses are applicable;
- 10.2.6 Idle mode Inter-RAT Cell Selection to/from NB-IoT is supported;
- All other subclauses of clause 10 are not applicable.
10.1 Intra E-UTRAN

10.1.0 General
In E-UTRAN RRC_CONNECTED state, network-controlled UE-assisted handovers and DC specific activities are
performed, except for NB-IoT, and various DRX cycles are supported.
In E-UTRAN RRC_IDLE state, cell reselections are performed and DRX is supported.
3GPP
Release 17 123 3GPP TS 36.300 V17.2.0 (2022-09)
10.1.1 Mobility Management in ECM-IDLE

10.1.1.1 Cell selection
The principles of PLMN selection in E-UTRA are based on the 3GPP PLMN selection principles. Cell selection is
required on transition from EMM_DETACHED to EMM-REGISTERED and from ECM-IDLE or ECM-
CONNECTED.
Cell selection:
- The UE NAS layer identifies a selected PLMN and equivalent PLMNs;
- The UE searches the E-UTRA frequency bands and for each carrier frequency identifies the strongest cell. It
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.
Transition to RRC_IDLE:
On transition from RRC_CONNECTED to RRC_IDLE, a UE should camp on the last cell for which it was in
RRC_CONNECTED or a cell/any cell of set of cells or frequency be assigned by RRC in the state transition
message.
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.
10.1.1.2 Cell reselection

A UE in RRC_IDLE performs cell reselection. The principles of the procedure are the following:
- The UE makes measurements of attributes of the serving and neighbour cells to enable the reselection process:
- There is no need to indicate neighbouring cells in the serving cell system information to enable the UE to
search and measure a cell i.e. E-UTRAN relies on the UE to detect the neighbouring cells;
- For the search and measurement of inter-frequency neighbouring cells, only the carrier frequencies need to be
indicated;
- Measurements may be omitted if the serving cell attribute fulfils particular search or measurement criteria.
- 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, except for NB-IoT:
- 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. Absolute priorities for reselection are provided only by the RPLMN and are valid only
within the RPLMN; priorities are given by the system information and are valid for all UEs in a cell, specific
priorities per UE can be signalled in the RRC Connection Release message. A validity time can be associated
with UE specific priorities.
3GPP
Release 17 124 3GPP TS 36.300 V17.2.0 (2022-09)
- Inter-frequency E-UTRAN reselection can be also based on redistribution priority. A UE may be

redistributed to a redistribution target (frequency or cell) and will consider the redistribution target
(frequency or cell) as having the highest priority (i.e. higher than any network configured priority) for a
period of time (i.e. validity timer). The redistribution parameters are defined in system information and can
be triggered by Paging.
- For inter-frequency neighbouring cells, it is possible to indicate layer-specific cell reselection parameters
(e.g., layer specific offset). These parameters are common to all neighbouring cells on a frequency;
- An NCL can be provided by the serving cell to handle specific cases for intra- and inter-frequency
neighbouring cells. This NCL contains cell specific cell reselection parameters (e.g., cell specific offset) for
specific neighbouring cells;
- Exclude-lists can be provided to prevent the UE from reselecting to specific intra- and inter-frequency
neighbouring cells;
- Cell reselection can be speed dependent (speed detection based on UTRAN solution);
- Cell reselection parameters are applicable for all UEs in a cell, but it is possible to configure specific
reselection parameters per UE group or per UE.
For NB-IoT, cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria
which involve measurements of the serving and neighbour cells as follows:
- Intra-frequency reselection is based on ranking of cells (potentially with cell specific offsets);
- Inter-frequency reselection is based on ranking of frequencies (potentially with frequency specific offsets);
- Blind redirection supported for load balancing (potentially with a dedicated offset for the frequency where
the UE is redirected to).
Cell access restrictions apply as for UTRAN, which consist of access class (AC) barring and cell reservation (e.g. for
cells "reserved for operator use") applicable for mobiles in RRC_IDLE mode. For NB-IoT UEs, BL UEs or UEs in
enhanced coverage, E-UTRAN can also restrict access to the cell based on the level of coverage enhancements that
would be needed by the UE.
10.1.1.3 Void
10.1.1.4 Void
10.1.1.5 Void
10.1.2 Mobility Management in ECM-CONNECTED/CM-CONNECTED

10.1.2.0 General
The Intra-E-UTRAN-Access Mobility Support for UEs in ECM-CONNECTED/CM-CONNECTED handles all
necessary steps for
- Handover procedures, like processes that precede the final HO decision on the source network side (control and
evaluation of UE and eNB measurements taking into account certain UE specific roaming and access
restrictions), preparation of resources on the target network side, commanding the UE to the new radio resources
and finally releasing resources on the (old) source network side. It contains mechanisms to transfer context data
between evolved nodes, and to update node relations on C-plane and U-plane. A CHO (for more details, see
10.1.2.1a) configuration may be also included in the handover procedures.
- DC specific procedures, like processes that precede the final decision for a certain configuration of a SeNB
(control and evaluation of UE and network side measurements), preparation of respective resources on the
network side of a SeNB, commanding the UE to the new radio resources configuration for a second connection
and, if applicable, finally releasing resources of a SeNB. It contains mechanisms to transfer UE- and bearer-
context data between involved nodes, and to update node relations on C-plane and U-plane.
In E-UTRAN RRC_CONNECTED state, network-controlled UE-assisted handovers and DC specific activities are
performed and various DRX cycles are supported.
3GPP
Release 17 125 3GPP TS 36.300 V17.2.0 (2022-09)
The UE makes measurements of attributes of the serving and neighbour cells to enable the process:
- There is no need to indicate neighbouring cells to enable the UE to search and measure a cell i.e. E-UTRAN
relies on the UE to detect the neighbouring cells;
- For the search and measurement of inter-frequency neighbouring cells, at least the carrier frequencies need to be
indicated;
- The E-UTRAN signals reporting criteria for event-triggered and periodical reporting;
- An NCL can be provided by the serving cell by RRC dedicated signalling to handle specific cases for intra- and
inter-frequency neighbouring cells. This NCL contains cell specific measurement parameters (e.g. cell specific
offset) for specific neighbouring cells;
- Exclude-lists can be provided to prevent the UE from measuring specific neighbouring cells.
For the UE measuring discovery signals (i.e. CRS and/or CSI-RS) of the serving and neighbour cells, the E-UTRAN
indicates the measurement configuration to the UE, including the measurement timing configuration of the discovery
signals.
Depending on whether the UE needs transmission/reception gaps to perform the relevant measurements, measurements
are classified as gap assisted or non-gap assisted. A non-gap assisted measurement is a measurement on a cell that does
not require transmission/reception gaps to allow the measurement to be performed. A gap assisted measurement is a
measurement on a cell that does require transmission/reception gaps to allow the measurement to be performed. Gap
patterns (as opposed to individual gaps) are configured and activated by RRC.
In the text and figure(s) in the following clauses, intra-E-UTRA HO description is applicable for both intra-EPC and
intra-5GC cases. In addition, the following differences are applicable for intra-5GC:
- ng-eNB should be considered instead of eNB;
- 5GC should be considered instead of EPC, and NG interface should be considered instead of S1 interface;
- Xn interface should be considered instead of X2 interface and the messages sent between ng-eNBs over Xn are
defined in TS 38.423 [86];
- AMF should be considered intead of MME, and UPF should be considered instead of Serving Gateway;
- PDU session information should be considered instead of E-RAB QoS, and the QoS flow to DRB mapping rules
applied to the UE should be forwarded to the target ng-eNB;
- For the messages sent between MME and Serving Gateway, and between MME and eNB, use AMF/UPF/ng-
eNB respectively;
- The data forwarding defined in clause 9.2.3.2.3 in TS 38.300 [79] should be applied instead of clause 10.1.2.3;
- The Dual Connectivity operation in clause 10.1.2.8 is not applicable to intra-5GC mobility. The corresponding
Dual Connectivity operations for 5GC are described in TS 37.340 [76].
10.1.2.1 Handover
10.1.2.1.0 General
The intra E-UTRAN HO of a UE in RRC_CONNECTED state is a UE-assisted network-controlled HO, with HO
preparation signalling in E-UTRAN:
- Part of the HO command comes from the target eNB and is transparently forwarded to the UE by the source
eNB;
- To prepare the HO, the source eNB passes all necessary information to the target eNB (e.g. E-RAB attributes
and RRC context):
- When CA is configured and to enable SCell selection in the target eNB, the source eNB can provide in
decreasing order of radio quality a list of the best cells and optionally measurement result of the cells.
3GPP
Release 17 126 3GPP TS 36.300 V17.2.0 (2022-09)
- When DC is configured, the source MeNB provides the SCG configuration (in addition to the MCG
configuration) to the target MeNB.
- Both the source eNB and UE keep some context (e.g. C-RNTI) to enable the return of the UE in case of HO
failure;
- If RACH-less HO is not configured, the UE accesses the target cell via RACH following a contention-free
procedure using a dedicated RACH preamble or following a contention-based procedure if dedicated RACH
preambles are not available:
- the UE uses the dedicated preamble until the handover procedure is finished (successfully or unsuccessfully);
- If RACH-less HO is configured, the UE accesses the target cell via the uplink grant preallocated to the UE in the
RRC message. If the UE does not receive the preallocated uplink grant in the RRC message from the source
eNB, the UE monitors the PDCCH of the target cell;
- If DAPS handover is configured, the UE continues the downlink user data reception from the source eNB until
releasing the source cell and continues the uplink user data transmission to the source eNB until successful
random access procedure to the target eNB. Upon reception of the handover command, the UE:
- Creates a MAC entity for target cell;
- Establishes the RLC entity and an associated DTCH logical channel for target cell for each DRB configured
with DAPS;
- For the DRB(s) configured with DAPS, reconfigures the PDCP entity to configure DAPS with separate
security and ROHC functions for source and target and associates them with the RLC entities configured for
source and target respectively;
- Retains rest of the source link configurations until release of the source.
- UE maintains only PCell connection with both source and target eNBs. Any other configured serving cells,
NR sidelink configurations and V2X sidelink configurations are released by the network before the handover
command is sent to the UE.
NOTE: Void.
- If the access towards the target cell (using RACH or RACH-less procedure) is not successful within a certain
time, the UE initiates radio link failure recovery using a suitable cell except in DAPS handover or CHO
scenarios:
- When DAPS handover fails, the UE falls back to source cell configuration, resumes the connection with
source cell, and reports the DAPS handover failure via the source without triggering RRC connection re-
establishment if the source link is still available; Otherwise, RRC re-establishment is performed;
- When initial CHO execution attempt fails or Handover fails, if network configured the UE to try CHO after
HO/CHO failure and the UE performs cell selection to a CHO candidate cell, the UE attempts CHO
execution to that cell; Otherwise, RRC re-establishment is performed.
- No ROHC and EHC context is transferred at handover;
- No UDC context is transferred at handover;
- ROHC and EHC contexts can be kept at handover within the same eNB.
10.1.2.1.1 C-plane handling

The preparation and execution phase of the HO procedure is performed without EPC involvement, i.e. preparation
messages are directly exchanged between the eNBs. The release of the resources at the source side during the HO
completion phase is triggered by the eNB. In case an RN is involved, its DeNB relays the appropriate S1 messages
between the RN and the MME (S1-based handover) and X2 messages between the RN and target eNB (X2-based
handover); the DeNB is explicitly aware of a UE attached to the RN due to the S1 proxy and X2 proxy functionality
(see clause 4.7.6.6). The figure below depicts the basic handover scenario where neither MME nor Serving Gateway
changes:
3GPP
Release 17 127 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 10.1.2.1.1-1: Intra-MME/Serving Gateway HO
Below is a more detailed description of the intra-MME/Serving Gateway HO procedure:
0 The UE context within the source eNB contains information regarding roaming and access restrictions which
were provided either at connection establishment or at the last TA update.
1 The source eNB configures the UE measurement procedures according to the roaming and access restriction
information and e.g. the available multiple frequency band information. Measurements provided by the source
eNB may assist the function controlling the UE's connection mobility.
2 A MEASUREMENT REPORT is triggered and sent to the eNB.
3 The source eNB makes decision based on MEASUREMENT REPORT and RRM information to hand off the
UE.
3GPP
Release 17 128 3GPP TS 36.300 V17.2.0 (2022-09)
4 The source eNB issues a HANDOVER REQUEST message to the target eNB passing necessary information to
prepare the HO at the target side (UE X2 signalling context reference at source eNB, UE S1 EPC signalling
context reference, target cell ID, KeNB*, RRC context including the C-RNTI of the UE in the source eNB, AS-
configuration, E-RAB context and physical layer ID of the source cell + short MAC-I for possible RLF
recovery). The source eNB may also request a DAPS Handover for one or more E-RABs. UE X2 / UE S1
signalling references enable the target eNB to address the source eNB and the EPC. The E-RAB context includes
necessary RNL and TNL addressing information, and QoS profiles of the E-RABs.
5 Admission Control may be performed by the target eNB dependent on the received E-RAB QoS information to
increase the likelihood of a successful HO, if the resources can be granted by target eNB. The target eNB
configures the required resources according to the received E-RAB QoS information and reserves a C-RNTI and
optionally a RACH preamble. The AS-configuration to be used in the target cell can either be specified
independently (i.e. an "establishment") or as a delta compared to the AS-configuration used in the source cell
(i.e. a "reconfiguration").
6 The target eNB prepares HO with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the
source eNB. The HANDOVER REQUEST ACKNOWLEDGE message includes a transparent container to be
sent to the UE as an RRC message to perform the handover. The container includes a new C-RNTI, target eNB
security algorithm identifiers for the selected security algorithms, may include a dedicated RACH preamble, and
possibly some other parameters i.e. access parameters, SIBs, etc. If RACH-less HO is configured, the container
includes timing adjustment indication and optionally a preallocated uplink grant. The HANDOVER REQUEST
ACKNOWLEDGE message may also include RNL/TNL information for the forwarding tunnels, if necessary.
The target eNB also indicates if a DAPS Handover is accepted.
NOTE 1: As soon as the source eNB 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 1a: For E-RABs configured with DAPS, downlink PDCP SDUs are forwarded with SN assigned by the
source eNB, until SN assignment is handed over to the target eNB in step 11b, for which the normal data
forwarding follows as defined in 10.1.2.3.
Steps 7 to 16 provide means to avoid data loss during HO and are further detailed in 10.1.2.1.2 and 10.1.2.3.
7 The target eNB generates the RRC message to perform the handover, i.e. RRCConnectionReconfiguration
message including the mobilityControlInfo, to be sent by the source eNB towards the UE. The source eNB
performs the necessary integrity protection and ciphering of the message.
The UE receives the RRCConnectionReconfiguration message with necessary parameters (i.e. new C-RNTI,
target eNB security algorithm identifiers, and optionally dedicated RACH preamble, target eNB SIBs, etc.) and
is commanded by the source eNB to perform the HO. If RACH-less HO is configured, the
RRCConnectionReconfiguration includes timing adjustment indication and optionally preallocated uplink grant
for accessing the target eNB. If preallocated uplink grant is not included, the UE should monitor PDCCH of the
target eNB to receive an uplink grant. The UE does not need to delay the handover execution for delivering the
HARQ/ARQ responses to source eNB.
If Make-Before-Break HO is configured, the connection to the source cell is maintained after the reception of
RRCConnectionReconfiguration message with mobilityControlInfo before the UE executes initial uplink
transmission to the target cell.
NOTE 2: If Make-Before-Break HO is configured, the source eNB decides when to stop transmitting to the UE.
NOTE 3: The UE can be configured with Make-Before-Break HO and RACH-less HO simultaneously.
In case of DAPS Handover, the UE does not detach from the source cell upon receiving the
RRCConnectionReconfiguration message. The UE releases the source SRB resources, security configuration of
the source cell and stops DL/UL reception/transmission with the source upon receiving an explicit release from
the target node.
NOTE 3a: The DAPS Handover is considered to only be completed after the UE has released the source cell as
explicitly requested from the target node. Features that cannot be configured simultaneously with DAPS
Handover (CA, DC, EHC, UDC and CHO) can be configured earliest in the same
RRCConnectionReconfiguration message that releases the source cell. RRC suspend, a subsequent
handover or inter-RAT handover cannot be initiated until the source cell has been released.
3GPP
Release 17 129 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE 4: CA, DC, EHC, UDC, CHO or RACH-less HO cannot be configured simultaneously with DAPS
Handover and must be released by the source eNB before the DAPS Handover command is sent to the
UE.
NOTE 5: For E-RABs configured with DAPS, the source eNB does not stop transmitting downlink packets until it
receives the HANDOVER SUCCESS message from the target eNB in step 11a.
8a For E-RABs configured with DAPS, the source eNB 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 eNB forwards to the target eNB. The source eNB does not stop assigning PDCP
SNs to downlink packets until it sends the SN STATUS TRANSFER message to the target eNB in step 11b.
8 For E-RABs not configured with DAPS, the source eNB sends the SN STATUS TRANSFER message to the
target eNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of E-
RABs 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 SDU and may include a bit map of the receive status of the
out of sequence UL SDUs that the UE needs to retransmit in the target cell, if there are any such SDUs. The
downlink PDCP SN transmitter status indicates the next PDCP SN that the target eNB shall assign to new SDUs,
not having a PDCP SN yet. The source eNB may omit sending this message if none of the E-RABs of the UE
shall be treated with PDCP status preservation.
NOTE 6: In case of DAPS Handover, the uplink PDCP SN receiver status and the downlink PDCP SN transmitter
status for an E-RAB with RLC-AM and not configured with DAPS may be transferred by the SN
STATUS TRANSFER message in step 11b instead of step 8.
NOTE 7: For E-RABs configured with DAPS, the source eNB may additionally send the EARLY STATUS
TRANSFER message(s) between step 8 and step 11b, to inform discarding of already forwarded PDCP
SDUs. The target eNB 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.
9 If RACH-less HO is not configured, after receiving the RRCConnectionReconfiguration message including the
mobilityControlInfo, UE performs synchronisation to target eNB and accesses the target cell via RACH,
following a contention-free procedure if a dedicated RACH preamble was indicated in the mobilityControlInfo,
or following a contention-based procedure if no dedicated preamble was indicated. UE derives target eNB
specific keys and configures the selected security algorithms to be used in the target cell.
If RACH-less HO is configured, UE performs synchronisation to target eNB. UE derives target eNB specific
keys and configures the selected security algorithms to be used in the target cell.
10 If RACH-less HO is not configured, the target eNB responds with UL allocation and timing advance.
10a If RACH-less HO is configured and the UE did not get the periodic pre-allocated uplink grant in the
RRCConnectionReconfiguration message including the mobilityControlInfo, the UE receives uplink grant via the
PDCCH of the target cell. The UE uses the first available uplink grant after synchronization to the target cell.
11 When the RACH-less HO is not configured and the UE has successfully accessed the target cell, the UE sends
the RRCConnectionReconfigurationComplete message (C-RNTI) to confirm the handover, along with an uplink
Buffer Status Report, and/or UL data, whenever possible, to the target eNB, which indicates that the handover
procedure is completed for the UE. The target eNB verifies the C-RNTI sent in the
RRCConnectionReconfigurationComplete message. The target eNB can now begin sending data to the UE.
When the RACH-less HO is configured, after the UE has received uplink grant, the UE sends the
RRCConnectionReconfigurationComplete message (C-RNTI) to confirm the handover, along with an uplink
Buffer Status Report, and/or UL data, whenever possible, to the target eNB. The target eNB verifies the C-RNTI
sent in the RRCConnectionReconfigurationComplete message. The target eNB can now begin sending data to the
UE. The handover procedure is completed for the UE when the UE receives the UE contention resolution
identity MAC control element from the target eNB.
11a/b In case of DAPS Handover, the target eNB sends the HANDOVER SUCCESS message to the source eNB to
inform that the UE has successfully accessed the target cell. In return, the source eNB sends the SN STATUS
TRANSFER message for E-RABs configured with DAPS for which the description in step 8 applies, and the
normal data forwarding follows as defined in 10.1.2.3.
3GPP
Release 17 130 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE 8: For E-RABs configured with DAPS, the source eNB does not stop delivering uplink packets to the S-GW
until it sends the SN STATUS TRANSFER message in step 11b. The target eNB does not forward the
uplink PDCP SDUs successfully received in-sequence to the S-GW 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 S-GW. The target eNB does not deliver
any uplink packet which has an UL COUNT lower than the provided.
NOTE 9: Void.
12 The target eNB sends a PATH SWITCH REQUEST message to MME to inform that the UE has changed cell.
13 The MME sends a MODIFY BEARER REQUEST message to the Serving Gateway.
14 The Serving Gateway switches the downlink data path to the target side. The Serving gateway sends one or more
"end marker" packets on the old path to the source eNB and then can release any U-plane/TNL resources
towards the source eNB.
15 The Serving Gateway sends a MODIFY BEARER RESPONSE message to MME.
16 The MME confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST
ACKNOWLEDGE message.
17 By sending the UE CONTEXT RELEASE message, the target eNB informs success of HO to source eNB and
triggers the release of resources by the source eNB. The target eNB sends this message after the PATH SWITCH
REQUEST ACKNOWLEDGE message is received from the MME.
18 Upon reception of the UE CONTEXT RELEASE message, the source eNB can release radio and C-plane related
resources associated to the UE context. Any ongoing data forwarding may continue.
When an X2 handover is used involving HeNBs and when the source HeNB is connected to a HeNB GW, a UE
CONTEXT RELEASE REQUEST message including an explicit GW Context Release Indication is sent by the source
HeNB, in order to indicate that the HeNB GW may release of all the resources related to the UE context.
For DAPS handover, upon receiving DAPS handover command message, the UE suspends source cell SRBs, stops
sending and receiving any RRC control plane signalling towards 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 activates source cell SRBs for control plane
signalling. When DAPS handover is configured, PDCP duplication is not allowed.
10.1.2.1.2 U-plane handling

The U-plane handling during the Intra-E-UTRAN-Access mobility activity for UEs in ECM-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 eNB and the target eNB. There is
one tunnel established for uplink data forwarding and another one for downlink data forwarding for each E-RAB
for which data forwarding is applied. In the case of a UE under an RN performing handover, forwarding tunnels
can be established between the RN and the target eNB via the DeNB.
- During HO execution, user data can be forwarded from the source eNB to the target eNB. The forwarding may
take place in a service and deployment dependent and implementation specific way.
- Forwarding of downlink user data from the source to the target eNB should take place in order as long as
packets are received at the source eNB from the EPC or the source eNB buffer has not been emptied.
- During HO completion:
- The target eNB sends a PATH SWITCH message to MME to inform that the UE has gained access and
MME sends a MODIFY BEARER REQUEST message to the Serving Gateway, the U-plane path is switched
by the Serving Gateway from the source eNB to the target eNB.
- The source eNB should continue forwarding of U-plane data as long as packets are received at the source
eNB from the Serving Gateway or the source eNB buffer has not been emptied.
3GPP
Release 17 131 3GPP TS 36.300 V17.2.0 (2022-09)
For RLC-AM bearers:
- During normal HO not involving Full Configuration:
- For in-sequence delivery and duplication avoidance, PDCP SN is maintained on a bearer basis and the source
eNB informs the target eNB about the next DL PDCP SN to allocate to a packet which does not have a PDCP
sequence number yet (either from source eNB or from the Serving Gateway).
- For security synchronisation, HFN is also maintained and the source eNB 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 eNB, a window-based mechanism is needed for duplication detection.
- The occurrence of duplicates over the air interface in the target eNB is minimised by means of PDCP SN
based reporting at the target eNB by the UE. In uplink, the reporting is optionally configured on a bearer
basis by the eNB and the UE should first start by transmitting those reports when granted resources in the
target eNB. In downlink, the eNB 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 eNB re-transmits and prioritizes all downlink PDCP SDUs forwarded by the source eNB (i.e. the
target eNB should send data with PDCP SNs from X2 before sending data from S1), with the exception of
PDCP SDUs of which the reception was acknowledged through PDCP SN based reporting by the UE.
- The UE re-transmits in the target eNB all uplink PDCP SDUs starting from the first PDCP SDU following
the last consecutively confirmed PDCP SDU i.e. the oldest PDCP SDU that has not been acknowledged at
RLC in the source, excluding the PDCP SDUs of which the reception was acknowledged through PDCP SN
based reporting by the target.
- During HO involving Full Configuration:
- The following description below for RLC-UM bearers also applies for RLC-AM bearers. Data loss may
happen.
For RLC-UM bearers:
- The PDCP SN and HFN are reset in the target eNB, unless the bearer is configured with DAPS Handover.
- No PDCP SDUs are retransmitted in the target eNB.
- The target eNB prioritizes all downlink PDCP SDUs forwarded by the source eNB if any (i.e. the target eNB
should send data with PDCP SNs from X2 before sending data from S1).
- The UE PDCP entity does not attempt to retransmit any PDCP SDU in the target cell for which transmission had
been completed in the source cell. Instead UE PDCP entity starts the transmission with other PDCP SDUs.
For DAPS handover:
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 eNB is responsible for allocating downlink PDCP SNs until the SN assignment is handed over to the
target eNB and data forwarding in 10.1.2.3.1 (RLC-AM) or in 10.1.2.3.2 (RLC-UM) takes place. That is, the
source eNB 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 eNB.
- Upon allocation of downlink PDCP SNs by the source eNB, 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 eNB.
- For security synchronisation, HFN is maintained for the forwarded downlink SDUs with PDCP SNs assigned by
the source eNB. The source eNB 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 eNB forwards to the target eNB.
3GPP
Release 17 132 3GPP TS 36.300 V17.2.0 (2022-09)
- HFN and PDCP SN are maintained after the SN assignment is handed over to the target eNB. The SN STATUS
TRANSFER message indicates the next DL COUNT 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 eNBs 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 eNBs
until the source eNB connection is released by an explicit release command from the target eNB.
- During handover execution period, the UE PDCP entity configured with DAPS maintains separate security and
ROHC header decompression functions associated with each eNB, while maintaining common functions for
reordering, duplicate detection and discard, and PDCP SDUs in-sequence delivery to upper layers, PDCP SN
continuity will be supported for both RLC AM and UM DRBs configured with DAPS.
Uplink:
- The UE transmits UL data to the source eNB until the random access procedure towards the target eNB has been
successfully completed. Afterwards the UE switches its UL data transmission to the target eNB.
- Even after switching its UL data transmissions towards the target eNB, 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 eNB.
- During handover execution period, the UE maintains separate security context and ROHC header compressor
context for uplink transmissions towards the source and target eNBs. 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 eNBs 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 eNB. The SN STATUS TRANSFER message indicates the UL
COUNT of the first missing PDCP SDU that the target eNB should start delivering to the S-GW, even for RLC-
UM.
For DRBs not configured with DAPS, upon UE receiving DAPS handover command message, UE stops transmission
and reception of data from source cell and keeps source cell non-DAPS DRB configuration. When DAPS handover to
target cell fails and if source cell link is available then UE will revert back to source cell configuration prior to the
reception of DAPS handover command (including RLC, PDCP state variables and buffers).
10.1.2.1a Conditional Handover

10.1.2.1a.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) for CHO candidate cells upon
receiving the CHO configuration, and executes CHO once the execution condition(s) are met for a CHO candidate cell.
UE 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 each CHO candidate
cell and execution condition(s) generated by the source cell.
- An execution condition may consist of one or two trigger condition(s) (CHO events A3/A5). 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 evaluation of CHO execution condition of a single candidate cell.
- UE maintains connection with source eNB until UE determines a CHO execution condition is met for CHO
candidate cell.
3GPP
Release 17 133 3GPP TS 36.300 V17.2.0 (2022-09)
- 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 10.1.2.1, regardless of any previously received CHO
configuration.
- After source eNB sends CHO command to UE, the network is allowed to change source eNB configuration and
network can add, modify or release a configured CHO configuration using RRC message (i.e. until UE starts
executing CHO.
- While executing CHO, i.e. from the time when the UE starts synchronization with target cell, UE does not
monitor source cell.
NOTE 1: CHO is not supported for S1 based handover in this release of the specification.
NOTE 2: In case LTE-DC is configured, CHO is only supported in MeNB to eNB change procedure in this release
of the specification.
10.1.2.1a.2 C-plane handling

The figure below depicts the CHO scenario where neither MME nor Serving Gateway changes:
Figure 10.1.2.1a-1: Intra-MME/Serving Gateway Conditional Handover
1. The source eNB configures the UE with measurement configuration, which may be used by the UE to trigger
Measurement Reports for potential CHO candidate cell(s).
2. A MEASUREMENT REPORT is triggered and sent to the source eNB.
3. The source eNB makes decision on the usage of CHO to handoff the UE based on MEASUREMENT REPORT
information.
3GPP
Release 17 134 3GPP TS 36.300 V17.2.0 (2022-09)
4. The source eNB requests a CHO to the eNB(s) of candidate cell(s). A CHO request message is sent for each
candidate cell.
5. Same as step 5 in Figure 10.1.2.1.1-1 of clause 10.1.2.1.1.
6. The eNB(s) of candidate cell(s) sends CHO response including configuration of CHO candidate cell(s) to the
source eNB. The response message is also sent for each candidate cell.
7. The source eNB sends a RRCConnectionReconfiguration message to the UE, containing configuration of CHO
candidate cell(s) and CHO execution condition(s). The source eNB decides on the condition for the execution of
CHO and adds the condition(s) to the RRC message sent to the UE.
NOTE 1: The source eNB may reconfigure the UE's source configuration after providing CHO configuration for
candidate target cell(s).
NOTE 1a: A configuration of a CHO candidate cell cannot contain a DAPS handover.
8. The UE sends an RRCConnectionReconfigurationComplete message to the source eNB.
8a. If early data forwarding is applied, the source eNB sends the EARLY STATUS TRANSFER message.
9. The UE maintains connection with the source eNB after receiving CHO configuration, and starts evaluating the
CHO execution condition(s) for the CHO candidate cell(s). If at least one CHO candidate cell satisfies the
corresponding CHO execution condition, the UE detaches from the source eNB, applies the stored corresponding
configuration for that candidate cell and synchronises to that candidate cell.
10-11. The UE accesses to the target eNB and completes the handover procedure by sending
RRCConnectionReconfigurationComplete message to the target eNB. The UE releases the stored CHO
configurations after successful completion of RRC handover procedure.
11a/b. The target eNB sends the HANDOVER SUCCESS message to the source eNB to inform that the UE has
successfully accessed the target cell. In return, the source eNB sends the SN STATUS TRANSFER message.
NOTE 2: Late data forwarding may be initiated as soon as the source eNB receives the HANDOVER SUCCESS
message.
11c. The source eNB sends the HANDOVER CANCEL message toward the other signalling connections or other
potential target eNBs, if any, to cancel CHO for the UE.
12. Steps 12-18 as in Figure 10.1.2.1.1-1.
10.1.2.1a.3 U-plane handling

The U-plane handling for Conditional Handover follows the same principles for DAPS Handover in 10.1.2.1.2, if early
data forwarding is applied, except that, in case of Full Configuration, HFN and PDCP SN are reset in the target eNB
after the SN assignment is handed over to the target eNB. If late data forwarding is applied, the U-plane handling
follows the RLC-AM or RLC-UM bearer principles defined in 10.1.2.1.2.
10.1.2.1a.4 Data Forwarding

If late data forwarding is applied, the source eNB initiates data forwarding once it knows which target eNB the UE has
successfully accessed. In that case the behavior of the Conditional Handover data forwarding follows the same behavior
as defined in 10.1.2.3.1 and 10.1.2.3.2 for the intra-system handover data forwarding for RLC-AM and RLC-UM
bearers.
If early data forwarding is applied instead, the source eNB 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
10.1.2.3.5.
10.1.2.2 Path Switch

10.1.2.2.1 Path Switch upon handover
After the downlink path is switched at the Serving GW downlink packets on the forwarding path and on the new direct
path may arrive interchanged at the target eNB. The target eNodeB should first deliver all forwarded packets to the UE
3GPP
Release 17 135 3GPP TS 36.300 V17.2.0 (2022-09)
before delivering any of the packets received on the new direct path. The method employed in the target eNB to enforce
the correct delivery order of packets is outside the scope of the standard.
In order to assist the reordering function in the target eNB, the Serving GW shall send one or more "end marker"
packets on the old path immediately after switching the path for each E-RAB of the UE. The "end marker" packet shall
not contain user data. The "end marker" is indicated in the GTP header. After completing the sending of the tagged
packets the GW shall not send any further user data packets via the old path.
Upon receiving the "end marker" packets, the source eNB shall, if forwarding is activated for that bearer, forward the
packet toward the target eNB.
On detection of an "end marker" the target eNB shall discard the end marker packet and initiate any necessary
processing to maintain in sequence delivery of user data forwarded over X2 interface and user data received from the
serving GW over S1 as a result of the path switch.
On detection of the "end marker", the target eNB may also initiate the release of the data forwarding resource. However,
the release of the data forwarding resource is implementation dependent and could also be based on other mechanisms
(e.g. timer-based mechanism).
EPC may change the uplink end-point of the tunnels with Path Switch procedure. However, the EPC should keep the
old GTP tunnel end-point(s) sufficiently long time in order to minimise the probability of packet losses and avoid
unintentional release of respective E-RAB(s).
10.1.2.2.2 Path Update upon Dual Connectivity specific activities

Upon DC specific activities which involve the transfer of bearer contexts from one eNB to another, if one of the eNBs
involved in DC provides radio resources to the UE for one or several E-RABs configured with the SCG bearer option,
the update of the downlink path towards the EPC for the relevant E-RABs needs to be communicated by the MeNB to
the MME. The functions specified for the path switch for handover as specified in clause 10.1.2.2.1 are applicable for
the path update for DC with SCG bearer option as well except that:
- The role of involved eNBs are different: in DC, the "source eNB" as specified for handover, is the eNB from
which the bearer context is transferred and the "target eNB" is the eNB to which the bearer context is transferred.
- The EPC does not change the uplink end-point of the tunnels with the Path Update procedure in a way that this
would change the Serving GW.
10.1.2.2.3 Path Switch upon UE context resume

Upon resumption of a UE context in an eNB different from the one where the UE context was suspended, the Path
Switch procedure is used to request the MME to resume the UE context and related bearer contexts in the EPC and
update the downlink path.
10.1.2.3 Data forwarding

10.1.2.3.1 For RLC-AM DRBs
Upon handover, the source eNB may forward in order to the target eNB all downlink PDCP SDUs with their SN that
have not been acknowledged by the UE. In addition, the source eNB may also forward without a PDCP SN fresh data
arriving over S1 to the target eNB.
NOTE 1: The target eNB does not have to wait for the completion of forwarding from the source eNB before it
begins transmitting packets to the UE.
The source eNB discards any remaining downlink RLC PDUs. Correspondingly, the source eNB does not forward the
downlink RLC context to the target eNB.
NOTE 2: The source eNB does not need to abort ongoing RLC transmissions with the UE as it starts data
forwarding to the target eNB.
Upon handover, the source eNB forwards to the Serving Gateway the uplink PDCP SDUs successfully received in-
sequence until the sending of the Status Transfer message to the target eNB. Then at that point of time the source eNB
stops delivering uplink PDCP SDUs to the S-GW and shall discard any remaining uplink RLC PDUs. Correspondingly,
the source eNB does not forward the uplink RLC context to the target eNB.
3GPP
Release 17 136 3GPP TS 36.300 V17.2.0 (2022-09)
Then the source eNB shall either:
- discard the uplink PDCP SDUs received out of sequence if the source eNB has not accepted the request from the
target eNB for uplink forwarding or if the target eNB has not requested uplink forwarding for the bearer during
the Handover Preparation procedure,
- forward to the target eNB the uplink PDCP SDUs received out of sequence if the source eNB has accepted the
request from the target eNB for uplink forwarding for the bearer during the Handover Preparation procedure.
The PDCP SN of forwarded SDUs is carried in the "PDCP PDU number" field of the GTP-U extension header. The
target eNB shall use the PDCP SN if it is available in the forwarded GTP-U packet.
For normal HO in-sequence delivery of upper layer PDUs during handover is based on a continuous PDCP SN and is
provided by the "in-order delivery and duplicate elimination" function at the PDCP layer:
- in the downlink, the "in-order delivery and duplicate elimination" function at the UE PDCP layer guarantees in-
sequence delivery of downlink PDCP SDUs;
- in the uplink, the "in-order delivery and duplicate elimination" function at the target eNB PDCP layer guarantees
in-sequence delivery of uplink PDCP SDUs.
After a normal handover, when the UE receives a PDCP SDU from the target eNB, it can deliver it to higher layer
together with all PDCP SDUs with lower SNs regardless of possible gaps.
For handovers involving Full Configuration, the source eNB behaviour is unchanged from the description above. The
target eNB may not send PDCP SDUs for which delivery was attempted by the source eNB. The target eNB identifies
these by the presence of the PDCP SN in the forwarded GTP-U packet and discards them.
After a Full Configuration handover, the UE delivers received PDCP SDU from the source cell to the higher layer
regardless of possible gaps. UE discards uplink PDCP SDUs for which transmission was attempted and retransmission
of these over the target cell is not possible.
10.1.2.3.2 For RLC-UM DRBs

Upon handover, the source eNB does not forward to the target eNB downlink PDCP SDUs for which transmission had
been completed in the source cell. PDCP SDUs that have not been transmitted may be forwarded. In addition, the
source eNB may forward fresh downlink data arriving over S1 to the target eNB. The source eNB discards any
remaining downlink RLC PDUs. Correspondingly, the source eNB does not forward the downlink RLC context to the
target eNB.
Upon handover, the source eNB forwards all uplink PDCP SDUs successfully received to the Serving Gateway (i.e.
including the ones received out of sequence) and discards any remaining uplink RLC PDUs. Correspondingly, the
source eNB does not forward the uplink RLC context to the target eNB.
10.1.2.3.3 SRB handling

With respect to SRBs, the following principles apply at HO:
- No forwarding or retransmissions of RRC messages in the target;
- The PDCP SN and HFN are reset in the target.
10.1.2.3.4 User data forwarding for Dual Connectivity

Upon DC specific activities user data forwarding may be performed for E-RABs configured with the SCG bearer option
or with the split bearer option. The behaviour of the eNB from which data is forwarded is the same as specified for the
"source eNB" for handover, the behaviour of the eNB to which data is forwarded is the same as specified for the "target
eNB" for handover. If data forwarding for split bearer option is applied, the PDCP PDUs which are not acknowledged
by the UE are forwarded from the SeNB to the MeNB in the course of procedures involving the release of the SCG part
of the split bearer (e.g., SeNB Modification, SeNB Release, Change of SeNB).
10.1.2.3.5 For DRBs configured with DAPS Handover

Data forwarding after the source eNB receives the HANDOVER SUCCESS message from the target eNB follows the
same behaviors as defined in 10.1.2.3.1 if with RLC-AM and in 10.1.2.3.2 if with RLC-UM.
3GPP
Release 17 137 3GPP TS 36.300 V17.2.0 (2022-09)
Before the source eNB receives the HANDOVER SUCCESS message:
- The source eNB may forward to the target eNB downlink PDCP SDUs with SNs assigned by the source eNB.
No downlink PDCP SDU without a SN assigned is forwarded. No uplink PDCP SDU is forwarded.
- The source eNB sends the EARLY STATUS TRANSFER message to maintain HFN continuity by indicating
PDCP SN and HFN of the first PDCP SDU that the source eNB forwards to the target eNB. The subsequent
messages may be sent for discarding of already forwarded downlink PDCP SDUs in the target eNB.
- The source eNB does not stop transmitting downlink packets to the UE. The source eNB keeps forwarding to the
Serving Gateway the uplink PDCP SDUs successfully received in-sequence from the UE.
10.1.2.4 Void
10.1.2.5 Void
10.1.2.6 Void
10.1.2.7 Timing Advance
In RRC_CONNECTED, the eNB is responsible for maintaining the timing advance. Serving cells having UL to which
the same timing advance applies (typically corresponding to the serving cells hosted by the same receiver) and using the
same timing reference cell are grouped in a timing advance group (TAG). Each TAG contains at least one serving cell
with configured uplink, and the mapping of each serving cell to a TAG is configured by RRC. In case of DC, a TAG
only includes cells that are associated to the same CG and the maximum number of TAG is 8.
For the pTAG the UE uses the PCell in MCG and the PSCell in SCG as timing reference. In a sTAG, the UE may use
any of the activated SCells of this TAG as a timing reference cell, but should not change it unless necessary.
For NB-IoT, the UE uses the anchor carrier as timing reference no matter if the non-anchor carrier is configured or not.
In some cases (e.g. during DRX), the timing advance is not necessarily always maintained and the MAC sublayer
knows if the L1 is synchronised and which procedure to use to start transmitting in the uplink:
- as long as the L1 is non-synchronised, uplink transmission can only take place on PRACH.
For a TAG, cases where the UL synchronisation status moves from "synchronised" to "non-synchronised" include:
- Expiration of a timer specific to the TAG;
- Non-synchronised handover.
The synchronisation status of the UE follows the synchronisation status of the pTAG of MCG. The synchronisation
status of the UE w.r.t. SCG follows the synchronisation status of the pTAG of SCG. When the timer associated with
pTAG is not running, the timer associated with an sTAG in that CG shall not be running. Expiry of the timers
associated with one CG does not affect the operation of the other CG.
The value of the timer associated to the pTAG of MCG is either UE specific and managed through dedicated signalling
between the UE and the eNB, or cell specific and indicated via broadcast information. In both cases, the timer is
normally restarted whenever a new timing advance is given by the eNB for the pTAG:
- restarted to a UE specific value if any; or
- restarted to a cell specific value otherwise.
The value of the timer associated to a pTAG of SCG and the value of a timer associated to an sTAG of an MCG or an
sTAG of SCG are managed through dedicated signalling between the UE and the eNB, and the timers associated to
these TAGs can be configured with different values. The timers of these TAGs are normally restarted whenever a new
timing advance is given by the eNB for the corresponding TAG.
Upon DL data arrival or for positioning purpose, a dedicated signature on PRACH can be allocated by the eNB to the
UE. When a dedicated signature on PRACH is allocated, the UE shall perform the corresponding random access
procedure regardless of its L1 synchronisation status.
Timing advance updates are signalled by the eNB to the UE in MAC PDUs.
3GPP
Release 17 138 3GPP TS 36.300 V17.2.0 (2022-09)
With RACH-less HO, only timing adjustment indication, NTA=0 or reuse NTA from a source eNB, are allowed where
NTA denotes a parameter defined in TS36.213 [6] and TS36.211 [4].
10.1.2.8 Dual Connectivity operation

10.1.2.8.1 SeNB Addition
The SeNB Addition procedure is initiated by the MeNB and is used to establish a UE context at the SeNB in order to
provide radio resources from the SeNB to the UE. This procedure is used to add at least the first cell (PSCell) of the
SCG. Figure 10.1.2.8.1-1 shows the SeNB Addition procedure.
Figure 10.1.2.8.1-1: SeNB Addition procedure
1. The MeNB decides to request the SeNB to allocate radio resources for a specific E-RAB, indicating E-RAB
characteristics (E-RAB parameters, TNL address information corresponding to bearer type). In addition, MeNB
indicates within SCG-ConfigInfo the MCG configuration and the entire UE capabilities for UE capability
coordination to be used as basis for the reconfiguration by the SeNB, but does not include SCG configuration.
The MeNB can provide the latest measurement results for the SCG cell(s) requested to be added. The SeNB may
reject the request.
NOTE: In contrast to SCG bearer, for the split bearer option the MeNB may either decide to request resources
from the SeNB of such an amount, that the QoS for the respective E-RAB is guaranteed by the exact sum
of resources provided by the MeNB and the SeNB together, or even more. The MeNBs decision may be
reflected in step 1 by the E-RAB parameters signalled to the SeNB, which may differ from E-RAB
parameters received over S1.
NOTE: For a specific E-RAB, the MeNB may request the direct establishment of an SCG or a Split bearer, i.e.,
without first having to establish an MCG bearer.
2. If the RRM entity in the SeNB is able to admit the resource request, it allocates respective radio resources and,
dependent on the bearer option, respective transport network resources. The SeNB triggers Random Access so
that synchronisation of the SeNB radio resource configuration can be performed. The SeNB provides the new
radio resource of SCG in SCG-Config to the MeNB. For SCG bearers, the SeNB provides the new radio resource
of the SCG together with S1 DL TNL address information for the respective E-RAB and security algorithm, for
split bearers together with X2 DL TNL address information.
NOTE: In case of split bearers, transmission of user plane data may take place after step 2.
NOTE: In case of SCG bearers, data forwarding and the SN Status Transfer may take place after step 2.
3GPP
Release 17 139 3GPP TS 36.300 V17.2.0 (2022-09)
3. If the MeNB endorses the new configuration, the MeNB sends the RRCConnectionReconfiguration message to
the UE including the new radio resource configuration of SCG according to the SCG-Config.
4. The UE applies the new configuration and replies with RRCConnectionReconfigurationComplete message. In
case the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration
message, it performs the reconfiguration failure procedure.
5. The MeNB informs the SeNB that the UE has completed the reconfiguration procedure successfully.
6. The UE performs synchronisation towards the PSCell of the SeNB. The order the UE sends the
RRCConnectionReconfigurationComplete message and performs the Random Access procedure towards the
SCG is not defined. The successful RA procedure towards the SCG is not required for a successful completion of
the RRC Connection Reconfiguration procedure.
7./8. In case of SCG bearers, and dependent on the bearer characteristics of the respective E-RAB, the MeNB may
take actions to minimise service interruption due to activation of dual connectivity (Data forwarding, SN Status
Transfer).
9.-12. For SCG bearers, the update of the UP path towards the EPC is performed.
10.1.2.8.2 SeNB Modification

The SeNB Modification procedure may be initiated either by the MeNB or by the SeNB and be used to modify,
establish or release bearer contexts, to transfer bearer contexts to and from the SeNB or to modify other properties of
the UE context within the same SeNB.
The SeNB modification procedure does not necessarily need to involve signalling towards the UE.
MeNB initiated SeNB Modification
Figure 10.1.2.8.2-1: SeNB Modification procedure - MeNB initiated
The MeNB uses the procedure to initiate configuration changes of the SCG within the same SeNB, e.g. the addition or
release of SCG SCells, the addition, modification or release of SCG bearer(s) and the SCG part of split bearer(s) and to
trigger PSCell change involving PSCell release. The SeNB may reject the request, except if it concerns the release of
SCG cells, of SCG bearer(s) or the SCG part of split bearer(s). Figure 10.1.2.8.2-1 shows an example signalling flow
for a MeNB initiated SeNB Modification procedure.
1. The MeNB sends the SeNB Modification Request message, which may contain bearer context related or other
UE context related information, data forwarding address information (if applicable) and SCG-ConfigInfo which
contains the MCG configuration and the entire UE capabilities for UE capability coordination to be used as basis
3GPP
Release 17 140 3GPP TS 36.300 V17.2.0 (2022-09)
for the reconfiguration by the SeNB. In case of SCG SCell addition request, the MeNB can provide the latest
measurement results for the SCG cell(s) requested to be added and SCG serving cell(s). In case of SCG Change,
SCG Change Indication is included.
NOTE: MeNB may request the establishment or release of SCG or Split bearer while not reconfiguration to MCG
bearer, which can be performed without SCG change.
2. The SeNB responds with the SeNB Modification Request Acknowledge message, which may contain radio
configuration information within SCG-Config message and data forwarding address information (if applicable).
In this step, the SeNB does not initiate an SCG change i.e. the SCG-Config message indicates an SCG Change
only if the MeNB included the SCG Change Indication in the SeNB Modification Request message (as an SCG
change initiated by the SeNB would subsequently require an SCG counter from the MeNB). In case of SCG
Change, for E-RABs configured with the split bearer option for which no bearer type change is performed, the
SeNB provides a new DL GTP TEID to the MeNB. The MeNB shall continue sending DL PDCP PDUs to the
SeNB with the previous DL GTP TEID until it performs PDCP re-establishment or PDCP data recovery, and use
the new DL GTP TEID starting with the PDCP re-establishment or data recovery.
3/4. The MeNB initiates the RRC connection reconfiguration procedure. The UE applies the new configuration
and replies with RRCConnectionReconfigurationComplete. In case the UE is unable to comply with (part of) the
configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure
procedure.
5. Upon successful completion of the reconfiguration, the success of the procedure is indicated in the SeNB
Reconfiguration Complete message.
6. If instructed, the UE performs synchronisation towards the PSCell of the SeNB as described in SeNB addition
procedure. Otherwise, the UE may perform UL transmission after having applied the new configuration.
7/8. If applicable, data forwarding between MeNB and the SeNB takes place (Figure 10.1.2.8.2-1 depicts the case
where a bearer context is transferred from the MeNB to the SeNB).
9. If applicable, a path update is performed.
SeNB initiated SeNB Modification
Figure 10.1.2.8.2-2: SeNB Modification procedure - SeNB initiated
The SeNB uses the procedure to perform configuration changes of the SCG within the same SeNB, e.g. to trigger the
release of SCG SCell(s) (other than PSCell), SCG bearer(s) and the SCG part of split bearer(s) (upon which the MeNB
may release the bearer or reconfigure it to an MCG bearer), and to trigger PSCell change. The MeNB cannot reject the
release request of SCG SCells (other than PSCell), SCG bearer and the SCG part of split bearer. The SeNB cannot
3GPP
Release 17 141 3GPP TS 36.300 V17.2.0 (2022-09)
initiate an SCG SCell addition except for the case of SI update of an SCG SCell. Figure 10.1.2.8.2-2 shows an example
signalling flow for an SeNB initiated SeNB Modification procedure.
1. The SeNB sends the SeNB Modification Required message, which may contain bearer context related, other UE
context related information and SCG-Config which contains the new radio resource configuration of SCG. For
bearer release or modification a corresponding E-RAB list is included in the SeNB Modification Required
message. In case of SCG Change, SCG Change Indication together with SCG-Config are included. In case of
release of bearer served by SeNB, SCG-Config is not included.
The SeNB can decide whether the Random Access procedure is required, i.e. SCG change.
2./3. If data forwarding and/or SeNB security key change needs to be applied, the MeNB triggers the preparation
of the MeNB initiated SeNB Modification procedure and provides forwarding address and/or a new SeNB
security key information within the SeNB Modification Request message, respectively. If the SeNB requested to
release a bearer in step 1, and the MeNB decides to reconfigure it to an MCG bearer, the MeNB provides the
SCG Change Indication within the SeNB Modification Request message and the SeNB provides respective RRC
information in the SCG-Configuration within the SeNB Modification Request Acknowledgement message.
NOTE: When the SeNB Modification Required message contains SCG-Config in step 1, the following MeNB
initiated SeNB Modification procedure triggered by the MeNB in step 2 cannot be used for anything that
would require a new SCG configuration (as SCG-Config cannot be subsequently signalled by the SeNB).
NOTE: If only SeNB security key (i.e. without SCG Change Indication) is provided in step 2, the MeNB does not
need to wait for the reception of step 3 to initiate the RRC connection reconfiguration procedure.
4. If MeNB accepts the SeNB request, the MeNB sends the RRCConnectionReconfiguration message to the UE
including the new radio resource configuration of SCG according to the SCG-Config.
5. The UE applies the new configuration and replies the RRCConnectionReconfigurationComplete message. In case
the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration
message, it performs the reconfiguration failure procedure.
6. Upon successful completion of the reconfiguration, the success of the procedure related to SCG-Config is
indicated in the SeNB Modification Confirm message.
7. If instructed, the UE performs synchronisation towards the PSCell of the SeNB as described in SeNB addition
procedure. Otherwise, the UE may perform UL transmission after having applied the new configuration.
8/9. If applicable, data forwarding between MeNB and the SeNB takes place (Figure 10.1.2.8.2-2 depicts the case
where a bearer context is transferred from the SeNB to the MeNB).
10.1.2.8.2.1 Intra-MeNB handover involving SCG change
This procedure is used to perform handover within the same MeNB while keeping the SCG in the same SeNB.
3GPP
Release 17 142 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 10.1.2.8.2.1-1: Intra-MeNB handover procedure with SeNB configuration
1. The MeNB sends the SeNB Modification Request message, which may contain bearer context related or other
UE context related information, data forwarding address information (if applicable) and SCG-ConfigInfo which
contains the MCG configuration and the entire UE capabilities for UE capability coordination to be used as basis
for the reconfiguration by the SeNB. In case of SCG SCell addition request, the MeNB can provide the latest
measurement results for the SCG cell(s) requested to be added and SCG serving cell(s). For E-RABs configured
with the split bearer option for which no bearer type change is performed during the SCG Change procedure the
MeNB provides a new UL GTP TEID to the SeNB. The SeNB shall continue sending UL PDCP PDUs to the
MeNB with the previous UL GTP TEID until it re-establishes the RLC and use the new UL GTP TEID after
RLC re-establishment.
2. The SeNB responds with the SeNB Modification Request Acknowledge message, which may contain radio
configuration information within SCG-Config message and data forwarding address information (if applicable).
3. The MeNB triggers the UE to apply the new configuration including SCG configuration.
4/5. The UE synchronizes to the MeNB.
6. Upon successful completion of the reconfiguration, the success of the procedure is indicated in the SeNB
Reconfiguration Complete message.
7. The UE performs synchronisation towards the PSCell of the SeNB as described in SeNB addition procedure.
8/9. Data forwarding between MeNB and the SeNB may take place.
10.1.2.8.3 SeNB Release

The SeNB Release procedure may be initiated either by the MeNB or by the SeNB and is used to initiate the release of
the UE context at the SeNB. The recipient node of this request cannot reject.
It does not necessarily need to involve signalling towards the UE, e.g., RRC connection re-establishment due to Radio
Link Failure in MeNB.
MeNB initiated SeNB Release
3GPP
Release 17 143 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 10.1.2.8.3-1: SeNB Release procedure – MeNB initiated
Figure 10.1.2.8.3-1 shows an example signalling flow for the MeNB initiated SeNB Release procedure.
1. The MeNB initiates the procedure by sending the SeNB Release Request message. If data forwarding is
requested, the MeNB provides data forwarding addresses to the SeNB.
2/3. If required, the MeNB indicates in the RRCConnectionReconfiguration message towards the UE that the UE
shall release the entire SCG configuration. In case the UE is unable to comply with (part of) the configuration
included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.
NOTE: If data forwarding is applied, timely coordination between steps 1 and 2 may minimize gaps in service
provision, this is however regarded to be an implementation matter.
4/5. Data forwarding from the SeNB to the MeNB takes place.
6. If applicable, the path update procedure is initiated.
7. Upon reception of the UE Context Release message, the SeNB can release radio and C-plane related resource
associated to the UE context. Any ongoing data forwarding may continue.
SeNB initiated SeNB Release
Figure 10.1.2.8.3-2: SeNB Release procedure – SeNB initiated
Figure 10.1.2.8.3-2 shows an example signalling flow for the SeNB initiated SeNB Release procedure.
1. The SeNB initiates the procedure by sending the SeNB Release Required message which does not contain inter-
node message.
3GPP
Release 17 144 3GPP TS 36.300 V17.2.0 (2022-09)
2. If data forwarding is requested, the MeNB provides data forwarding addresses to the SeNB in the SeNB Release
Confirm message. The SeNB may start data forwarding and stop providing user data to the UE as early as it
receives the SeNB Release Confirm message.
3/4. If required, the MeNB indicates in the RRCConnectionReconfiguration message towards the UE that the UE
shall release the entire SCG configuration. In case the UE is unable to comply with (part of) the configuration
included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure procedure.
NOTE: If data forwarding is applied, timely coordination between steps 2 and 3 may minimize gaps in service
provision. This is however regarded to be an implementation matter.
5/6. Data forwarding from the SeNB to the MeNB takes place.
7. If applicable, the path update procedure is initiated.
8. Upon reception of the UE Context Release message, the SeNB can release radio and C-plane related resource
associated to the UE context. Any ongoing data forwarding may continue.
10.1.2.8.4 Change of SeNB

The change of SeNB procedure is initiated by MeNB and used to transfer a UE context from a source SeNB to a target
SeNB and to change the SCG configuration in UE from one SeNB to another.
Figure 10.1.2.8.4-1: Change of SeNB
Figure 10.1.2.8.4-1 shows an example signalling flow for the Change of SeNB:
1/2. The MeNB initiates the change of SeNB by requesting the target SeNB to allocate resources for the UE by
means of the SeNB Addition Preparation procedure. MeNB includes the SCG configuration of the old SeNB in
the SeNB Addition Request. If forwarding is needed, the target SeNB provides forwarding addresses to the
MeNB.
If RACH-less SeNB Change is configured, the target SeNB includes timing adjustment indication and optionally
a preallocated uplink grant in the container.
3. If the allocation of target SeNB resources was successful, the MeNB initiates the release of the source SeNB
resources towards the UE and the source SeNB. In case Make-Before-Break SeNB change is configured, the
source SeNB decides when to stop transmitting to the UE. If data forwarding is needed the MeNB provides data
forwarding addresses to the source SeNB. Either direct data forwarding or indirect data forwarding is used for
SCG bearer. Only indirect data forwarding is used for Split bearer. Reception of the SeNB Release Request
3GPP
Release 17 145 3GPP TS 36.300 V17.2.0 (2022-09)
message triggers the source SeNB to stop providing user data to the UE and, if applicable, to start data
forwarding.
4/5. The MeNB triggers the UE to apply the new configuration. The MeNB indicates the new configuration in the
RRCConnectionReconfiguration message towards the UE. In case the UE is unable to comply with (part of) the
configuration included in the RRCConnectionReconfiguration message, it performs the reconfiguration failure
procedure.
If Make-Before-Break SeNB change is configured, the connection to the source SeNB is maintained after the
reception of RRCConnectionReconfiguration message with mobilityControlInfoSCG before the UE executes
initial uplink transmission to the target cell.
NOTE: The UE can be configured with Make-Before-Break SeNB change and RACH-less SeNB change
simultaneously.
6. If the RRC connection reconfiguration procedure was successful, the MeNB informs the target SeNB.
7. The UE synchronizes to the target SeNB.
If RACH-less SeNB Change is configured, the preallocated uplink grant may be included in the
RRCConnectionReconfiguration message. If the preallocated uplink grant is not included, the UE should monitor
PDCCH of the target SeNB for uplink grant. The SeNB Change procedure is completed for the UE when the UE
receives the UE contention resolution identity.
8/9. If applicable, data forwarding from the source SeNB takes place. It may be initiated as early as the source
SeNB receives the SeNB Release Request message from the MeNB.
10-14. If one of the bearer contexts was configured with the SCG bearer option at the source SeNB, path update is
triggered by the MeNB.
15. Upon reception of the UE Context Release message, the source SeNB can release radio and C-plane related
resource associated to the UE context. Any ongoing data forwarding may continue.
10.1.2.8.5 MeNB to eNB Change

The MeNB to eNB Change procedure is used to transfer context data from a source MeNB/SeNB to a target eNB.
Figure 10.1.2.8.5-1: MeNB to eNB Change procedure
Figure 10.1.2.8.5-1 shows an example signalling flow for the MeNB to eNB Change procedure:
3GPP
Release 17 146 3GPP TS 36.300 V17.2.0 (2022-09)
1. The source MeNB starts the MeNB to eNB Change procedure by initiating the X2 Handover Preparation
procedure. The source MeNB includes the SCG configuration in the HandoverPreparationInformation.
2. The target eNB includes the field in HO command which releases SCG configuration, and may also provide
forwarding addresses to the source MeNB. The addition of an SeNB can be initiated only after completing HO.
3. If the allocation of target eNB resources was successful, the MeNB initiates the release of the source SeNB
resources towards the source SeNB. If data forwarding is needed, the MeNB provides data forwarding addresses
to the source SeNB. Either direct data forwarding or indirect data forwarding is used for SCG bearer. Only
indirect data forwarding is used for Split bearer. Reception of the SeNB Release Request message triggers the
source SeNB to stop providing user data to the UE and, if applicable, to start data forwarding.
NOTE 1: In case the handover is a conditional handover, step 3 is performed after the source MeNB receives an
indication that the UE has successfully accessed one of the potential target eNB (i.e. after step 6).
NOTE 2: In case the handover is a conditional handover, the Data Forwarding Address Indication procedure is
executed right after step 2. This Data Forwarding Address Indication informs conditional handover to the
source SeNB for which it may decide to perform, if applicable, early data forwarding for SN-terminated
bearers, together with the sending of an EARLY STATUS TRANSFER message to the source MeNB.
Separate Data Forwarding Address Indication procedures may be invoked to provide different forwarding
addresses of the prepared conditional handovers. In this case, it is up to the source MeNB and SeNB
implementations to make sure that the EARLY STATUS TRANSFER message(s) from the source SeNB,
if any, is forwarded to the right target destination. The Data Forwarding Address Indication procedure
may further be invoked to indicate to the SeNB to stop already initiated early data forwarding for some
SN-terminated bearers if they are no longer subject to data forwarding due to the modification or
cancellation of the prepared conditional handovers. If applicable, the normal data forwarding and SN
STATUS TRANSFER message would follow from the source SeNB once it receives SeNB release
request of the step 3 that is performed after step 6.
4. The MeNB triggers the UE to apply the new configuration. Upon receiving the new configuration, the UE
releases the entire SCG configuration.
5/6. The UE synchronizes to the target eNB.
7/8. If applicable, data forwarding from the source SeNB takes place. It may start as early as the source SeNB
receives the SeNB Release Request message from the MeNB.
9-13. The target eNB initiates the S1 Path Switch procedure.
14. The target eNB initiates the UE Context Release procedure towards the source MeNB.
15. Upon reception of the UE CONTEXT RELEASE message, the S-SeNB can release radio and C-plane related
resource associated to the UE context. Any ongoing data forwarding may continue.
10.1.2.8.6 SCG change

"SCG change" refers to a synchronous SCG reconfiguration procedure towards the UE involving random access on
PSCell. This procedure is used to establish SCG, and can be used to reconfigure the SCG configuration. During SCG
change, MAC configured for SCG is reset and RLC configured for SCG is re-established regardless of the bearer
type(s) established on SCG. For SCG bearer, PDCP configured for SCG is re-established. In case of reconfiguration
from split to MCG bearer, RLC configured for SCG is released. During SCG change, S-KeNB key is refreshed. To
perform SCG change within the same SeNB, the SeNB Modification procedure as described in clause 10.1.2.8.2 is used
and in this case, the path switch and data forwarding for DRB on SCG may be suppressed. To perform SCG change
between different SeNBs, the change of SeNB as described in clause 10.1.2.8.4 is used.
10.1.2.8.7 eNB to MeNB change

The eNB to MeNB change procedure is used to transfer context data from a source eNB to a target MeNB that adds an
SeNB during the handover.
3GPP
Release 17 147 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 10.1.2.8.7-1: eNB to MeNB change
Figure 10.1.2.8.7-1 shows an example signaling flow for eNB to MeNB change:
1. The source eNB starts the handover procedure by initiating the X2 Handover Preparation procedure.
2. The target MeNB sends SeNB Addition Request to the target SeNB.
3. The target SeNB replies with SeNB Addition Request Acknowledge. If data forwarding is needed, the target
SeNB provides forwarding addresses to the target MeNB.
4. The target MeNB includes within the Handover Request Acknowledge message a transparent container to be
sent to the UE as an RRC message to perform the handover which also includes the SCG configuration, and may
also provide forwarding addresses to the source eNB. Either direct data forwarding or indirect data forwarding is
used for SCG bearer. Only indirect data forwarding is used for split bearer.
5. The source eNB triggers the UE to apply the new configuration.
6/7. The UE synchronizes to the target MeNB and replies with RRCConnectionReconfigurationComplete
message.
8. The UE synchronizes to the target SeNB
9. If the RRC connection reconfiguration procedure was successful, the target MeNB informs the target SeNB.
10/11. Data forwarding from the source eNB takes place.
12-15. The target MeNB initiates the S1 Path Switch procedure.
NOTE: If new UL TEIDs of the S-GW are included, the target MeNB performs MeNB initiated SeNB
Modification procedure to provide them to the target SeNB.
16. The target MeNB initiates the UE Context Release procedure towards the source eNB.
10.1.2.8.8 Inter-MeNB handover without SeNB change

Inter-MeNB handover without SeNB change is used to transfer context data from a source MeNB to a target MeNB
while the context at the SeNB is kept.
3GPP
Release 17 148 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 10.1.2.8.8-1: Inter-MeNB handover without SeNB change
Figure 10.1.2.8.8-1 shows an example signaling flow for inter-MeNB handover without SeNB change:
1. The source MeNB starts the handover procedure by initiating the X2 Handover Preparation procedure. The
source MeNB includes the SCG configuration in the HandoverPreparationInformation. The source MeNB
includes the SeNB UE X2AP ID and SeNB ID as a reference to the UE context in the SeNB that was established
by the source MeNB in the Handover Request message.
2. If the target MeNB decides to keep the SeNB, the target MeNB sends SeNB Addition Request to the SeNB
including the SeNB UE X2AP ID as a reference to the UE context in the SeNB that was established by the
source MeNB.
3. The SeNB replies with SeNB Addition Request Acknowledge.
4. The target MeNB includes within the Handover Request Acknowledge message a transparent container to be
sent to the UE as an RRC message to perform the handover which also includes the SCG configuration, and may
also provide forwarding addresses to the source MeNB. The target MeNB indicates to the source MeNB that the
UE context in the SeNB is kept if the target MeNB and the SeNB decided to keep the UE context in the SeNB in
step 2 and step 3.
5. The source MeNB sends SeNB Release Request to the SeNB. The source MeNB indicates to the SeNB that the
UE context in SeNB is kept. If the indication as the UE context kept in SeNB is included, the SeNB keeps the
UE context.
6. The source MeNB triggers the UE to apply the new configuration.
7/8. The UE synchronizes to the target MeNB and replies with RRCConnectionReconfigurationComplete
message.
9. The UE synchronizes to the SeNB.
10. If the RRC connection reconfiguration procedure was successful, the target MeNB informs the SeNB.
11/12. Data forwarding from the source MeNB takes place. Data forwarding may be omitted for SCG bearers.
Direct data forwarding from the source MeNB to the SeNB is not possible for split bearers.
NOTE: Direct data forwarding may occur only for bearer type change.
13-16. The target MeNB initiates the S1 Path Switch procedure.
3GPP
Release 17 149 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE: If new UL TEIDs of the S-GW are included, the target MeNB performs MeNB initiated SeNB
Modification procedure to provide them to the SeNB.
17. The target MeNB initiates the UE Context Release procedure towards the source MeNB.
18. Upon reception of the UE Context Release message, the SeNB can release C-plane related resource associated to
the UE context towards the source MeNB. Any ongoing data forwarding may continue. The SeNB shall not
release the UE context associated with the target MeNB if the indication was included in the SeNB Release
Request in step 5.
3GPP
Release 17 150 3GPP TS 36.300 V17.2.0 (2022-09)
10.1.2.8.9 Addition of a hybrid HeNB as the SeNB
Figure 10.1.2.8.9-1: Addition of a hybrid cell as serving cell of the SeNB
Figure 10.1.2.8.9-1 shows the signalling flow for the addition of the hybrid cell as serving cell of the SeNB procedure:
3GPP
Release 17 151 3GPP TS 36.300 V17.2.0 (2022-09)
1a. The UE is connected to an MeNB and detects a potential candidate cell for dual connectivity.
1b. The UE reads System Information from the candidate cell (csg-Indication, csg-Identity).
1c. The MeNB receives CSG related information from the UE (csg-MemberStatus, csg-Identity).
2. The MeNB initiates the SeNB Addition preparation procedure including Memebership Status of the UE in the
hybrid HeNB.
3. The SeNB takes the membership information provided by the MeNB into account (even if this was not yet
verified with the MME).
4-7. No difference to the SeNB Addition Preparation procedure as described in 10.2.1.1.
8/9. The MeNB requests the MME to verify the membership status of the UE for the CSG-ID reported by the UE.
- For SCG bearer, the MeNB triggers the E-RAB Modification Indication procedure.
- For split bearer, the MeNB triggers the UE Context Modification Indication procedure.
10-13. If the result of the membership verification requires an update of the UE context at the SeNB, the MeNB
triggers the MeNB initiated SeNB Modification Preparation procedure. If the membership verification fails, it is
up to the SeNB to decide on further actions.
10.1.2.9 LWA mobility

10.1.2.9.1 Inter-eNB handover without WT change
Inter-eNB handover without WT change is used to transfer context data from a source eNB to a target eNB while the
LWA connectivity is kept.
Figure 10.1.2.9-1: Handover without WT change
1. The source eNB starts the handover procedure by initiating the X2 Handover Preparation procedure. The source
eNB includes the LWA configuration in the HANDOVER REQUEST: the Mobility Set currently valid for the
3GPP
Release 17 152 3GPP TS 36.300 V17.2.0 (2022-09)
UE, the WT UE XwAP ID and WT ID as a reference to the UE context in the WT that was established by the
source eNB.
2. If the target eNB decides to keep the LWA connection, the target eNB sends WT ADDITION REQUEST to the
WT including the WT UE XwAP ID as a reference to the UE context in the WT that was established by the
source eNB. The WT shall use this information to check if the UE context is present.
3. If successful, the WT replies with WT ADDITION REQUEST ACKNOWLEDGE.
4. If both, the target eNB and the WT decided to keep the LWA connection in steps 2 and 3 respectively, the target
eNB sends the HANDOVER REQUEST ACKNOWLEDGE message, which includes the LWA configuration
and the UE LWA Context Kept Indicator, and may also provide forwarding addresses to the source eNB.
5. The source eNB triggers the UE to apply the new configuration.
6a. After the UE applies the target eNB PDCP keys contained in the handover command for UL, the UL end marker
packet is sent to WT.
NOTE: The UE can change the DL and UL encryption keys at different times since it can receive an end marker
packet at a different time than changing the PDCP key for UL.
6b. WT forwards the UL end marker packet to the source eNB. If WT is able to distinguish the UL end marker
packet, it may also forward the end marker packet to target eNB.
6c. When the source eNB has sent the last DL packet to UE, it sends a DL end marker packet to the UE. When UE
receives the end marker packet, it starts using the target eNB PDCP keys for decoding of DL packets.
NOTE: The DL end marker packet should be sent before the UE completes the handover, i.e. before step 9.
7. The source eNB sends the WT Release Request to the WT, indicating whether the UE context has been matched
at the target. The WT keeps the relevant part of the UE context based on the identification information provided
from the target eNB at step 2.
NOTE: The source eNB may postpone sending the WT Release Request until the UE CONTEXT RELEASE is
received in step 12.
8-9. The UE synchronizes to the target eNB and replies with RRCConnectionReconfigurationComplete message.
10. The source eNB forwards the SN status to the target eNB.
11-12. The target eNB initiates the S1 Path Switch procedure.
13. The target eNB initiates the UE Context Release procedure towards the source eNB.
NOTE: Some time after the handover without WT change procedure, the target eNB may provide the UE and the
WT with new WLAN security information. Based on this information, the UE re-authenticates itself in
the WLAN network.
User plane aspects:
Before the source eNB initiates the WT Release Request, the WT is configured with bearer tunnels to both source and
target eNB (after WT Addition by the target eNB).
In the downlink, the source eNB forwards end marker packets immediately after the last data packets sent to the WT for
a particular bearer, and the WT forwards packets received from either eNB towards the UE. The end marker packets
may be used by the UE to switch the PDCP key.
In the uplink, the UE inserts end marker packets to indicate the key switch. The WT may use the end marker packets to
infer which packets should be forwarded to source eNB or target eNB. The source eNB may use the end marker packets
to infer which packets it should process or discard while the source Xw-u tunnel is operational. The target eNB
processes all received packets.
10.1.2.10 EN-DC Operation

Procedures to support EN-DC Operation are described in TS 37.340 [76].
3GPP
Release 17 153 3GPP TS 36.300 V17.2.0 (2022-09)
10.1.3 Measurements
10.1.3.0 General
Measurements to be performed by a UE for intra/inter-frequency/inter-RAT mobility can be controlled by E-UTRAN,
using broadcast or dedicated control. In RRC_IDLE state, a UE shall follow the measurement parameters defined for
cell reselection specified by the E-UTRAN broadcast. The use of dedicated measurement control for RRC_IDLE state
is possible through the provision of UE specific priorities (see clause 10.2.4). In RRC_CONNECTED state, a UE shall
follow the measurement configurations specified by RRC directed from the E-UTRAN (e.g. as in UTRAN
MEASUREMENT_CONTROL).
In RRC_IDLE and RRC_CONNECTED the UE may be configured to monitor some UTRA or E-UTRA carriers
according to reduced performance requirements as specified in TS 36.133 [21].
In RRC_IDLE, for NB-IoT UEs, BL UEs or UEs in enhanced coverage, the UE may further limit the intra-frequency
and inter-frequency measurements when the relaxed monitoring criterion is fulfilled as specified in TS 36.304 [11].
In RRC_IDLE, for NB-IoT UEs, when enabled in the cell and the relaxed monitoring criterion is fulfilled, the UE may
perform serving cell measurements on the non-anchor paging carrier as specified in TS 36.133 [21].
For CSI-RS based discovery signals measurements, "cell" should be interpreted as "transmission point of the concerned
cell" in the following descriptions.
Intra-frequency neighbour (cell) measurements, inter-frequency neighbour (cell) measurements and inter-RAT
measurements are defined as follows:
- Intra-frequency neighbour (cell) measurements: Neighbour cell measurements performed by the UE are intra-
frequency measurements when the current and target cell operates on the same carrier frequency.
- Inter-frequency neighbour (cell) measurements: Neighbour cell measurements performed by the UE are inter-
frequency measurements when the neighbour cell operates on a different carrier frequency, compared to the
current cell.
- Inter-RAT neighbour (cell) measurements: Neighbour cell measurements performed by the UE are inter-RAT
measurements when the neighbour cell operates on a different RAT, compared to the current cell.
Whether a measurement is non gap assisted or gap assisted depends on the UE's capability and the current operating
frequency. In non gap assisted scenarios, the UE shall be able to carry out such measurements without measurement
gaps. In gap assisted scenarios, the UE may not be able to perform such measurements without measurement gaps. The
UE determines whether a particular cell measurement needs to be performed in a transmission/reception gap and the
scheduler needs to know whether gaps are needed:
- Same carrier frequency and cell bandwidths (Scenario A): an intra-frequency scenario; not measurement gap
assisted.
- Same carrier frequency, bandwidth of the target cell smaller than the bandwidth of the current cell (Scenario B):
an intra-frequency scenario; not measurement gap assisted.
- Same carrier frequency, bandwidth of the target cell larger than the bandwidth of the current cell (Scenario C):
an intra-frequency scenario; not measurement gap assisted.
- Different carrier frequencies, bandwidth of the target cell smaller than the bandwidth of the current cell and
bandwidth of the target cell within bandwidth of the current cell (Scenario D): an inter-frequency scenario;
measurement gap-assisted scenario.
- Different carrier frequencies, bandwidth of the target cell larger than the bandwidth of the current cell and
bandwidth of the current cell within bandwidth of the target cell (Scenario E): an inter-frequency scenario;
- Different carrier frequencies and non-overlapping bandwidth, (Scenario F): an inter-frequency scenario;
- Same carrier frequency, the operating frequency of the bandwidth reduced low complexity (BL) UE or the UE in
Enhanced Coverage is not guaranteed to be aligned with the center frequency of the current cell (Scenario G): an
intra-frequency scenario; measurement gap assisted scenario.
3GPP
Release 17 154 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 10.1.3-1: Inter and Intra-frequency measurements scenarios
Measurement gaps may be needed by the UE to carry out inter-RAT measurements on NR frequencies. UE may need
measurement gaps to perform inter-RAT measurements on NR frequencies depending on the UE's need for gap
capability, as well as the UE capability to support independent FR measurement as specified in TS 38.306 [89]. The UE
may not be able to perform inter-RAT NR measurements without measurement gaps in the following cases:
- If the UE only supports per-UE gaps and the UE is required to measure NR frequencies:
- If the UE supports per-FR gaps and the UE is required to measure at least one NR frequency in FR1;
Measurement gaps patterns are configured and activated by RRC.
When CA is configured, the "current cell" above refers to any serving cell of the configured set of serving cells. For
instance, for the definition of intra and inter frequency measurements, this means:
- Intra-frequency neighbour (cell) measurements: Neighbour cell measurements performed by the UE are intra-
frequency measurements when one of the serving cells of the configured set and the target cell operates on the
same carrier frequency. The UE shall be able to carry out such measurements without measurement gaps.
- Inter-frequency neighbour (cell) measurements: Neighbour cell measurements performed by the UE are inter-
frequency measurements when the neighbour cell operates on a different carrier frequency than any serving cell
of the configured set. The UE may not be able to perform such measurements without measurement gaps.
When DC is configured, the following principles are applied:
- The configured set of serving cells includes all the cells from MCG and SCG as for CA;
- The measurement procedure of serving cells belonging to the SeNB shall not be impacted due to RLF of SeNB;
- Common gap for the MeNB and the SeNB is applied;
3GPP
Release 17 155 3GPP TS 36.300 V17.2.0 (2022-09)
- There is only a single measurement gap configuration for the UE which is controlled and informed by the
MeNB.
- UE determines the starting point of the measurement gap based on the SFN, subframe number and subframe
boundaries of the MCG serving cells.
When LAA is configured:
- The eNB configures the UE with one DMTC window for all neighbor cells as well as for the serving cell (if any)
on one frequency;
- The UE is only expected to detect and measure cells transmitting DRS during the configured DRS DMTC
window;
- For channel selection in an environment where hidden nodes may exist, UE may be configured with one RMTC
per a frequency to perform RSSI measurement, and to report average RSSI and channel occupancy (percentage
of measurement samples that RSSI value is above a threshold) in a reporting interval.
For NB-IoT, measurements in RRC_CONNECTED are optionally supported to reduce the time taken for RRC
reestablishment. The following principles are applied:
- The "current cell" above refers to the configured carrier in the serving cell. The "target cell" above refers to the
anchor carrier in the target cell. For instance, for the definition of intra and inter frequency measurements, this
means:
- Intra-frequency neighbour (carrier) measurements: Neighbour carrier measurements performed by the UE are
intra-frequency measurements when the configured carrier in the serving cell and the anchor carrier in the
target cell operates on the same carrier frequency. The UE shall be able to carry out such measurements
without measurement gaps.
- Inter-frequency neighbour (carrier) measurements: Neighbour cell measurements performed by the UE are
inter-frequency measurements when the configured carrier in the serving cell and the anchor carrier in the
target cell operates on a different carrier frequency. The UE may not be able to perform such measurements
without measurement gaps.
- The eNB configures the criteria to perform measurements via broadcast signalling;
- Dedicated measurements gaps are not supported. The UE may need to perform neighbour cell measurements
during DL/UL idle periods that are provided by DRX or packet scheduling;
- Measurement reporting is not supported.
10.1.3.1 Intra-frequency neighbour (cell) measurements

In a system with frequency reuse = 1, mobility within the same frequency layer (i.e. between cells with the same carrier
frequency) is predominant. Good neighbour cell measurements are needed for cells that have the same carrier frequency
as the serving cell in order to ensure good mobility support and easy network deployment. Search for neighbour cells
with the same carrier frequency as the serving cell, and measurements of the relevant quantities for identified cells are
needed.
NOTE: To avoid UE activity outside the DRX cycle, the reporting criteria for neighbour cell measurements
should match the used DRX cycle.
10.1.3.2 Inter-frequency neighbour (cell) measurements

Regarding mobility between different frequency layers (i.e. between cells with a different carrier frequency), UE may
need to perform neighbour cell measurements during DL/UL idle periods that are provided by DRX or packet
scheduling (i.e. gap assisted measurements).
Network may request UE to measure inter-frequency carriers in RRC_IDLE or RRC_INACTIVE via system
information or via dedicated measurement configuration in RRC Connection Release. The UE performs the requested
measurements and may provide an indication of the availability of measurement report to the eNB during RRC
Connection Setup or Resume procedure. The network may request UE to report those measurements after security
activation. The request for the measurements can be sent by the network immediately after transmitting the Security
Mode Command (i.e. before the reception of the Security Mode Complete from the UE). Alternatively, during
3GPP
Release 17 156 3GPP TS 36.300 V17.2.0 (2022-09)
connection resume from suspended RRC connection or from RRC_INACTIVE, the eNB can request the UE to provide
idle/inactive measurement results in the RRCConnectionResume message and then the UE can include the available
measurement results in the RRCConnectionResumeComplete message.
10.1.4 Paging and C-plane establishment

Paging groups (where multiple UEs can be addressed) are used on PDCCH:
- Precise UE identity is found on PCH;
- DRX configurable via BCCH and NAS;
- Only one subframe allocated per paging interval per UE;
- The network may divide UEs to different paging occasions in time;
- There is no grouping within paging occasion;
- One paging RNTI for PCH.
When extended DRX (eDRX) is used in idle mode, the following are applicable:
- The DRX cycle is extended up to and beyond 10.24s in idle mode, with a maximum value of 2621.44 seconds
(43.69 minutes); For NB-IoT, the maximum value of the DRX cycle is 10485.76 seconds (2.91 hours);
- The hyper SFN (H-SFN) is broadcast by the cell and increments by one when the SFN wraps around;
- Paging Hyperframe (PH) refers to the H-SFN in which the UE starts monitoring paging DRX during a Paging
Time Window (PTW) used in ECM-IDLE. The PH is determined based on a formula that is known by the
MME/AMF, UE and (ng-)eNB as a function of eDRX cycle and UE identity;
- During the PTW, the UE monitors paging for the duration of the PTW (as configured by NAS) or until a paging
message is including the UE's NAS identity received for the UE, whichever is earlier. The possible starting
offsets for the PTW are uniformly distributed within the PH and defined in TS 36.304 [11];
- MME/AMF uses the formulas defined in TS 36.304 [11] to determine the PH as well as the beginning of the
PTW and sends the S1 paging request just before the occurrence of the start of PTW or during PTW to avoid
storing paging messages in the (ng-)eNB;
- ETWS, CMAS, PWS requirement may not be met when a UE is in eDRX. For EAB, if the UE supports SIB14,
when in extended DRX, it acquires SIB14 before establishing the RRC connection;
- When the eDRX cycle is longer than the system information modification period, the UE verifies that stored
system information remains valid before establishing an RRC connection. Paging message can be used for
system information change notification, when including systemInfoModification-eDRX, for a UE configured with
eDRX cycle longer than the system information modification period.
NB-IoT UEs, BL UEs or UEs in enhanced coverage can use (G)WUS, when configured in the cell, to reduce the power
consumption related to paging monitoring. (G)WUS is only applicable in RRC_IDLE.
When GWUS is used in RRC_IDLE, the following are applicable:
- Multiple WUS groups, possibly distributed over multiple WUS resources, can be configured in the cell;
- If the UE supports WUS assistance information, the MME/AMF may provide the UE with UE paging
probability information (see TS 24.301 [20] and TS 24.501 [91]);
- UE selects one WUS group based on its UE paging probability information and /or its UE NAS identity as
defined in TS 36.304 [11];
- A common WUS group may be used to wake up all UEs monitoring the same WUS resource.
When (G)WUS is used in RRC_IDLE, the following are applicable:
- The UE monitors (G)WUS only in the last used cell as defined in TS 36.304 [11];
3GPP
Release 17 157 3GPP TS 36.300 V17.2.0 (2022-09)
- The WUS or WUS group is used to indicate that the UE shall monitor MPDCCH or NPDCCH to receive paging
in that cell;
- For a UE not configured with extended DRX, the WUS or WUS group is associated to one paging occasion (N =
1);
- For a UE configured with extended DRX, the WUS or WUS group can be associated to one or multiple paging
occasion(s) (N ≥ 1) in a PTW;
- If UE detects the WUS or WUS group, the UE shall monitor the following N paging occasions unless it has
received a paging message;
- The paging operation in the MME/AMF is not aware of the use of the WUS in the (ng-)eNB;
- To reduce WUS use in cells not monitored by the UE, WUS-capable (ng-)eNBs provide UE's last used cell
information to MME/AMF in the S1-AP/NG-AP UE Context Release Complete or UE Context Suspend Request
messages for all UEs, as described in TS 23.401 [17] and TS 23.501 [82]. In case of immediate suspension of a
UE, the WUS-capable ng-eNB also provides the UE's last cell information to the AMF in the UE Context
Resume Request message, as described in TS 23.501 [82].
The timing between WUS and the paging occasion (PO) is illustrated in Figure 10.1.4-1. The timing between GWUS
and the paging occasion (PO) is illustrated in Figure 10.1.4-2 and Figure 10.1.4-3. The UE can expect WUS repetitions
during "Configured maximum WUS duration" but the actual WUS transmission can be shorter, e.g. for UE in good
coverage. The UE does not monitor WUS during the non-zero "Gap".
WUS PO
Configured maximum Gap

WUS duration
Figure 10.1.4-1: Illustration of WUS timing
Figure 10.1.4-2: Illustration of GWUS timing for NB-IoT UEs
Figure 10.1.4-3: Illustration of GWUS timing for BL UEs and UEs in enhanced coverage
NOTE: WUS1/WUS3 could be higher or lower frequency than WUS0/WUS2.
For NB-IoT, UE in RRC_IDLE receives paging on the anchor carrier or on a non-anchor carrier based on system
information.
When coverage based paging is used in NB-IoT:
- Some paging carriers may be configured for lower levels of coverage enhancements;
3GPP
Release 17 158 3GPP TS 36.300 V17.2.0 (2022-09)
- The eNB can configure a UE during RRC connection release to select one of these paging carriers according to
coverage information provided by the eNB;
- If configured for coverage based paging, the UE only selects one of the coverage based paging carriers if its
NRSRP is suitable according to the coverage based paging configuration;
- Coverage based paging is only applicable in the last cell where the coverage information was received;- The
eNB includes the coverage based paging information provided to the UE within the information on the coverage
enhancement (CE) level described in clause 23.13.2.
10.1.5 Random Access Procedure

10.1.5.0 General
The random access procedure is characterized by:
- Common procedure for FDD and TDD;
- One procedure irrespective of cell size and the number of serving cells when CA is configured;
The random access procedure is performed for the following events related to the PCell:
- Initial access from RRC_IDLE;
- RRC Connection Re-establishment procedure, as defined in TS 24.301 [20];
- Handover, except for NB-IoT or when RACH-less HO is configured;
- DL data arrival during RRC_CONNECTED requiring random access procedure:
- E.g. when UL synchronisation status is "non-synchronised".
- UL data arrival during RRC_CONNECTED requiring random access procedure:
- E.g. when UL synchronisation status is "non-synchronised" or there are no PUCCH resources for SR
available.
- For positioning purpose during RRC_CONNECTED requiring random access procedure:
- E.g. when timing advance is needed for UE positioning.
The random access procedure is also performed on a SCell to establish time alignment for the corresponding sTAG.
For E-UTRA connected to 5GC, the random access procedure is also performed for the transition from
RRC_INACTIVE.
In DC, the random access procedure is also performed on at least PSCell upon SCG addition/modification, if instructed,
or upon DL/UL data arrival during RRC_CONNECTED requiring random access procedure. The UE initiated random
access procedure is performed only on PSCell for SCG.
Furthermore, the random access procedure takes two distinct forms:
- Contention based (applicable to all six events, but the sixth event for positioning is applicable for NB-IoT only);
- Non-contention based (applicable to only handover, DL data arrival, positioning and obtaining timing advance
alignment for a sTAG).
Normal DL/UL transmission can take place after the random access procedure.
An RN supports both contention-based and non-contention-based random access. When an RN performs the random
access procedure, it suspends any current RN subframe configuration, meaning it temporarily disregards the RN
subframe configuration. The RN subframe configuration is resumed at successful random access procedure completion.
For NB-IoT, the random access procedure is performed on the anchor carrier or on a non-anchor carrier based on
system information.
3GPP
Release 17 159 3GPP TS 36.300 V17.2.0 (2022-09)
10.1.5.1 Contention based random access procedure

The contention based random access procedure is outlined on Figure 10.1.5.1-1 below:
Figure 10.1.5.1-1: Contention based Random Access Procedure
The four steps of the contention based random access procedures are:
1) Random Access Preamble on RACH in uplink:
- There are two possible groups defined and one is optional. If both groups are configured the size of message
3 and the pathloss are used to determine which group a preamble is selected from. The group to which a
preamble belongs provides an indication of the size of the message 3 and the radio conditions at the UE. The
preamble group information along with the necessary thresholds are broadcast on system information.
2) Random Access Response generated by MAC on DL-SCH:
- Semi-synchronous (within a flexible window of which the size is one or more TTI) with message 1;
- No HARQ;
- Addressed to RA-RNTI on PDCCH;
- Conveys at least RA-preamble identifier, Timing Alignment information for the pTAG, initial UL grant and
assignment of Temporary C-RNTI (which may or may not be made permanent upon Contention Resolution);
- Intended for a variable number of UEs in one DL-SCH message.
3) First scheduled UL transmission on UL-SCH:
- Uses HARQ;
- Size of the transport blocks depends on the UL grant conveyed in step 2.
- For initial access:
- Conveys the RRC Connection Request generated by the RRC layer and transmitted via CCCH;
- Conveys at least NAS UE identifier but no NAS message;
- RLC TM: no segmentation.
- For RRC Connection Re-establishment procedure:
- Conveys the RRC Connection Re-establishment Request generated by the RRC layer and transmitted via
CCCH;
3GPP
Release 17 160 3GPP TS 36.300 V17.2.0 (2022-09)
- RLC TM: no segmentation;
- Does not contain any NAS message.
- After handover, in the target cell:
- Conveys the ciphered and integrity protected RRC Handover Confirm generated by the RRC layer and
transmitted via DCCH;
- Conveys the C-RNTI of the UE (which was allocated via the Handover Command);
- Includes an uplink Buffer Status Report when possible.
- For other events:
- Conveys at least the C-RNTI of the UE;
- In the procedure to resume the RRC connection or in the EDT procedure for User Plane CIoT EPS/5GS
Optimisations:
- Conveys the RRC Connection Resume Request generated by the RRC layer and transmitted via CCCH;
- Conveys a Resume ID (for EPS) or I-RNTI (for 5GS) to resume the RRC connection;
- For the MO-EDT procedure for User Plane CIoT EPS/5GS Optimisations:
- Conveys ciphered user data transmitted via DTCH;
- RLC UM/AM: no segmentation;
- Does not contain any NAS message.
- For NB-IoT:
- In the procedure to setup the RRC connection:
- An indication of the amount of data for subsequent transmission(s) on SRB or DRB can be indicated.
- For EDT for Control Plane CIoT EPS/5GS Optimisations:
- Conveys the RRC Early Data Request generated by the RRC layer and transmitted via CCCH;
- Conveys NAS UE identifier;
- For the MO-EDT procedure for Control Plane CIoT EPS/5GS Optimisations:
- Conveys user data concatenated in a NAS message;
- RLC TM: no segmentation.
4) Contention Resolution on DL:
- Early contention resolution shall be used i.e. eNB does not wait for NAS reply before resolving contention;
- For NB-IoT, for initial access, RRC connection resume procedure and RRC Connection Re-establishment
procedure, eNB may transmit MAC PDU containing the UE contention resolution identity MAC control
element without RRC response message;
NOTE: In Release 13, NB-IoT UEs do not support the MAC PDU containing the UE contention resolution
identity MAC control element without RRC response message for initial access, RRC connection
resume procedure and RRC Connection Re-establishment procedure.
- Not synchronised with message 3;
- HARQ is supported;
- Addressed to:
3GPP
Release 17 161 3GPP TS 36.300 V17.2.0 (2022-09)
- The Temporary C-RNTI on PDCCH for initial access and after radio link failure;
- The C-RNTI on PDCCH for UE in RRC_CONNECTED.
- HARQ feedback is transmitted only by the UE which detects its own UE identity, as provided in message 3,
echoed in the Contention Resolution message;
- For initial access, RRC Connection Re-establishment procedure and EDT for Control Plane CIoT EPS/5GS
Optimisations, no segmentation is used (RLC-TM).
The Temporary C-RNTI is promoted to C-RNTI for a UE which detects RA success and does not already have a C-
RNTI; it is dropped by others. A UE which detects RA success and already has a C-RNTI, resumes using its C-RNTI.
When CA is configured, the first three steps of the contention based random access procedures occur on the PCell while
contention resolution (step 4) can be cross-scheduled by the PCell.
When DC is configured, the first three steps of the contention based random access procedures occur on the PCell in
MCG and PSCell in SCG. When CA is configured in SCG, the first three steps of the contention based random access
procedures occur on the PSCell while contention resolution (step 4) can be cross-scheduled by the PSCell.
10.1.5.2 Non-contention based random access procedure

The non-contention based random access procedure is outlined on Figure 10.1.5.2-1 below:
Figure 10.1.5.2-1: Non-contention based Random Access Procedure
The three steps of the non-contention based random access procedures are:
0) Random Access Preamble assignment via dedicated signalling in DL:
- eNB assigns to UE a non-contention Random Access Preamble (a Random Access Preamble not within the
set sent in broadcast signalling).
- Signalled via:
- HO command generated by target eNB and sent via source eNB for handover;
- PDCCH in case of DL data arrival or positioning;
- PDCCH for initial UL time alignment for a sTAG.
1) Random Access Preamble on RACH in uplink:
- UE transmits the assigned non-contention Random Access Preamble.
2) Random Access Response on DL-SCH:
- Semi-synchronous (within a flexible window of which the size is two or more TTIs) with message 1;
- No HARQ;
3GPP
Release 17 162 3GPP TS 36.300 V17.2.0 (2022-09)
- Addressed to RA-RNTI on PDCCH;
- Conveys at least:
- Timing Alignment information and initial UL grant for handover;
- Timing Alignment information for DL data arrival;
- RA-preamble identifier;
- Intended for one or multiple UEs in one DL-SCH message.
When performing non-contention based random access on the PCell while CA is configured, the Random Access
Preamble assignment via PDCCH of step 0, step 1 and 2 of the non-contention based random access procedure occur on
the PCell. In order to establish timing advance for a sTAG, the eNB may initiate a non-contention based random access
procedure with a PDCCH order (step 0) that is sent on a scheduling cell of activated SCell of the sTAG. Preamble
transmission (step 1) is on the indicated SCell and Random Access Response (step 2) takes place on PCell.
When performing non-contention based random access on the PCell or PSCell while DC is configured, the Random
Access Preamble assignment via PDCCH of step 0, step 1 and 2 of the non-contention based random access procedure
occur on the corresponding cell. In order to establish timing advance for a sTAG, the eNB may initiate a non-contention
based random access procedure with a PDCCH order (step 0) that is sent on a scheduling cell of activated SCell of the
sTAG not including PSCell. Preamble transmission (step 1) is on the indicated SCell and Random Access Response
(step 2) takes place on PCell for MCG and PSCell for SCG.
10.1.5.3 Interaction model between L1 and L2/3 for Random Access Procedure
Random access procedure described above is modelled in Figure 10.1.5.3-1 below from L1 and L2/3 interaction point
of view. L2/L3 receives indication from L1 whether ACK is received or DTX is detected after indication of Random
Access Preamble transmission to L1. L2/3 indicates L1 to transmit first scheduled UL transmission (RRC Connection
Request in case of initial access) if necessary or Random Access Preamble based on the indication from L1.
Figure 10.1.5.3-1: Interaction model between L1 and L2/3 for Random Access Procedure
10.1.6 Radio Link Failure

Two phases govern the behaviour associated to radio link failure as shown on Figure 10.1.6-1:
- First phase:
- started upon radio problem detection;
- leads to radio link failure detection;
- no UE-based mobility;
- based on timer or other (e.g. counting) criteria (T1).
- Second Phase:
- started upon radio link failure detection or handover failure;
- leads to RRC_IDLE;
- UE-based mobility;
3GPP
Release 17 163 3GPP TS 36.300 V17.2.0 (2022-09)
- Timer based (T2).
Figure 10.1.6-1: Radio Link Failure
Table 10.1.6-1 below describes how mobility is handled with respect to radio link failure:
Table 10.1.6-1: Mobility and Radio Link Failure
Cases First Phase Second Phase T2 expired

UE returns to the same cell Continue as if no radio Activity is resumed by means Go via RRC_IDLE
problems occurred of explicit signalling between
UE and eNB
UE selects a different cell N/A Activity is resumed by means Go via RRC_IDLE
from the same eNB of explicit signalling between
UE and eNB
UE selects a cell of a N/A Activity is resumed by means Go via RRC_IDLE
prepared eNB (NOTE) of explicit signalling between
UE and eNB
UE selects a cell of a N/A Go via RRC_IDLE Go via RRC_IDLE
different eNB that is not
prepared (NOTE)
NOTE: a prepared eNB is an eNB which has admitted the UE during an earlier executed HO preparation phase,
or obtains the UE context during the Second Phase.
For a NB-IoT UE that only uses Control Plane CIoT EPS/5GS optimisations, as defined in TS 24.301 [20] and does not
support RRC Connection re-establishment for the control plane as defined in TS 36.331 [16], at the end of the first
phase, the UE enters RRC_IDLE (there is no second phase).In the Second Phase, in order to resume activity and avoid
going via RRC_IDLE when the UE returns to the same cell or when the UE selects a different cell from the same eNB,
or when the UE selects a cell from a different eNB, the following procedure applies:
- The UE stays in RRC_CONNECTED;
- The UE accesses the cell through the random access procedure;
- Except for a NB-IoT UE using only Control Plane CIoT EPS/5GS optimisations, the UE identifier used in the
random access procedure for contention resolution (i.e. C-RNTI of the UE in the cell where the RLF occurred +
physical layer identity of that cell + short MAC-I based on the keys of that cell) is used by the selected eNB to
authenticate the UE and check whether it has a context stored for that UE:
- If the eNB finds a context that matches the identity of the UE, or obtains this context from the previously
serving eNB, it indicates to the UE that its connection can be resumed;
- If the context is not found, RRC connection is released and UE initiates procedure to establish new RRC
connection. In this case UE is required to go via RRC_IDLE.
- For a NB-IoT UE using only Control Plane CIoT EPS/5GS optimisations, the UE identifier used in the random
access procedure for contention resolution (i.e. S-TMSI (for EPS) or truncated 5G-S-TMSI (for 5GS) of the UE
at the time where the RLF occurred + UL NAS MAC + UL NAS COUNT) is used by the selected (ng-)eNB to
request the MME/AMF to authenticate the UE's re-establishment request and provide the UE context:
- If the authentication of the UE is successful and a context is provided, it indicates to the UE that its
connection can be resumed;
3GPP
Release 17 164 3GPP TS 36.300 V17.2.0 (2022-09)
- If no context is provided, the RRC connection is released and UE initiates procedure to establish new RRC
connection. In this case UE is required to go via RRC_IDLE.
The radio link failure procedure applies also for RNs, with the exception that the RN is limited to select a cell from its
DeNB cell list. Upon detecting radio link failure, the RN discards any current RN subframe configuration (for
communication with its DeNB), enabling the RN to perform normal contention-based RACH as part of the re-
establishment. Upon successful re-establishment, an RN subframe configuration can be configured again using the RN
reconfiguration procedure.
For DC, PCell supports above phases. In addition, the first phase of the radio link failure procedure is supported for
PSCell. However, upon detecting RLF on the PSCell, the re-establishment procedure is not triggered at the end of the
first phase. Instead, UE shall inform the radio link failure of PSCell to the MeNB.
NOTE: If the recovery attempt in the second phase fails, the details of the RN behaviour in RRC_IDLE to recover
an RRC connection are up to the RN implementation.
In case of DAPS handover, the UE continues the detection of radio link failure at the source cell until the successful
completion of the random access procedure to the target cell. If RLF is declared in the source cell, the UE:
- stays in RRC_CONNECTED;
- stops any data transmission or reception via the source link and releases the source link, but maintains the source
RRC configuration;
- if handover failure is declared at the target cell after source cell RLF was declared,
- selects a suitable cell and initiates RRC re-establishment;
- enters RRC_IDLE if a suitable cell was not found within a certain time after handover failure was
declared.
In case of CHO, after RLF is declared in the source cell, the UE:
- stays in RRC_CONNECTED;
- selects a suitable cell and if the selected cell is a CHO candidate and if network configured the UE to try CHO at
the selected CHO candidate cell after RLF, then the UE attempts CHO execution, otherwise re-establishment is
performed;
- enters RRC_IDLE if a suitable cell was not found within a certain time after RLF was declared.
10.1.7 Radio Access Network Sharing

E-UTRAN shall support radio access network sharing based on support for multi-to-multi relationship between E-
UTRAN nodes and EPC nodes (S1-flex).
If the E-UTRAN is shared by multiple operators, the system information broadcasted in each shared cell contains the
PLMN-id of each operator (up to 6).
E-UTRA may provide a single tracking area code (TAC) and Cell Identity valid for all the PLMNs sharing the radio
access network resources. Alternatively, E-UTRA may provide TACs and Cell Identities valid only for a subset of the
PLMNs sharing the radio network resources. With both alternatives, E-UTRA provides only one TAC and one Cell
Identity per cell per PLMN.
The UE shall be able to read up to 6 PLMN-ids, to select one of the PLMN-ids at initial attachment and to indicate this
PLMN-id to the E-UTRAN in subsequent instances of the Random Access procedures (e.g. as defined in clause 10.1.5).
The E-UTRAN shall select an appropriate MME for the PLMN indicated by the UE. Once attached to an MME, the UE
shall be able to indicate the allocated MME in subsequent instances of the Random Access procedures. The indication
of the allocated MMEC is contained in the temporary UE identity.
Handling of roaming and access restrictions for UE in ECM-CONNECTED shall follow the principles specified in
clause 10.4a.
Each Cell Identity associated with a subset of PLMNs identifies its serving eNB.
3GPP
Release 17 165 3GPP TS 36.300 V17.2.0 (2022-09)
10.1.8 Handling of Roaming and Area Restrictions for UEs in ECM-

CONNECTED
NOTE: The term Roaming and Area Restrictions is not used in Rel-11 and onwards. It has been replaced by the
term Roaming and Access Restrictions, see clause 10.1.8a.
10.1.8a Handling of Roaming and Access Restrictions for UEs in ECM-

CONNECTED
Handling of roaming and access restrictions and handling of subscription specific preferences in ECM-CONNECTED
is performed in the eNB based on information provided by the EPC over the S1 interface.
10.1.9 Mobility in RRC_INACTIVE

10.1.9.1 Overview
Mobility procedures for the RRC_INACTIVE state as specified in clause 9.2.2.1 of TS 38.300 [79] also apply for
EUTRA connected to 5GC with the following differences:
- ng-eNB shall be considered instead of gNB.
10.1.9.2 Cell Reselection

A UE in RRC_INACTIVE performs cell reselection. The principles of the procedure are same as for the RRC_IDLE
state (see sublclause 10.1.1.2). In addition, for E-UTRA RRC_INACTIVE state:
- Cell reselection from E-UTRA RRC_INACTIVE to NR RRC_IDLE is supported;
- Cell reselection from E-UTRA RRC_INACTIVE to E-UTRA/EPC RRC_IDLE is supported.
10.1.9.3 RAN-Based Notification Area

A UE in the RRC_INACTIVE state can be configured with an RNA as it is specified in clause 9.2.2.3 of TS 38.300
[79].
10.1.9.4 State Transitions

10.1.9.4.1 UE triggered transition from RRC_INACTIVE to RRC_CONNECTED
The UE triggered transition from RRC_INACTIVE to RRC_CONNECTED procedure of clause 9.2.2.4.1 of TS 38.300
[79] is applicable with the following differences:
10.1.9.4.2 Network triggered transition from RRC_INACTIVE to RRC_CONNECTED

The Network triggered transition from RRC_INACTIVE to RRC_CONNECTED procedure of clause 9.2.2.4.2 of TS
38.300 [79] is applicable with the following differences:
- ng-eNB shall be considered instead of gNB;
- To resume from RRC_INACTIVE the procedure in clause 10.1.9.4.1 shall be applied.
10.1.9.5 RNA update

The RNA update procedure of clause 9.2.2.5 of TS 38.300 [79] is applicable with the following differences:
3GPP
Release 17 166 3GPP TS 36.300 V17.2.0 (2022-09)
10.2 Inter RAT

10.2.0 General
Service-based redirection between GERAN / UTRAN and E-UTRAN is supported in both directions. This should not
require inter-RAT reporting in RRC CONNECTION REQUEST.
10.2.1 Cell reselection

A UE in RRC_IDLE performs cell reselection. The principles of this procedure are as follows:
- The UE makes measurements of attributes of the serving and neighbour cells to enable the reselection process:
- For a UE to search and measure neighbouring GERAN cells, the ARFCNs of the BCCH carriers need to be
indicated in the serving cell system information (i.e., an NCL). The NCL does not contain BSICs or cell
specific offsets and Qrxlevmin is given per frequency band.
- For a UE to search and measure neighbouring UTRAN cells, the serving cell can indicate an NCL containing
a list of carrier frequencies and scrambling codes.
- For a UE to search and measure neighbouring NR cells, the serving cell can indicate the measured RS types
and parameters for cell quality derivation.
- Measurements may be omitted if the serving cell attribute fulfils particular search or measurement criteria.
involves measurements of the serving and neighbour cells:
- Inter-RAT reselection is based on absolute priorities where UE tries to camp on highest priority RAT
available. Absolute priorities for inter-RAT reselection are provided only by the RPLMN and valid only
within the RPLMN; priorities are given by the system information and valid for all UEs in a cell, specific
priorities per UE can be signalled in the RRC Connection Release message. A validity time can be associated
with UE specific priorities.
- It should be possible to prevent the UE from reselecting to specific detected neighbouring cells;
- The UE is allowed to "leave" the source E-UTRAN cell to read the target GERAN cell broadcast, in order to
determine its "suitability", prior to completing the cell reselection;
- Cell reselection can be speed dependent (speed detection based on UTRAN solution);
Cell access restrictions apply as for UTRAN, which consist of access class (AC) barring and cell reservation (e.g. for
cells "reserved for operator use") applicable for mobiles in RRC_IDLE mode.
When performing cell reselection while the UE is camped on another RAT, the principles of this procedure are as
follows:
- The UE measures attributes of the E-UTRA neighbouring cells:
- Only the carrier frequencies need to be indicated to enable the UE to search and measure E-UTRA
neighbouring cells;
involves measurements of the serving and neighbour cells:
- For E-UTRA neighbouring cells, there is no need to indicate cell-specific cell reselection parameters i.e.
these parameters are common to all neighbouring cells on an E-UTRA frequency;
- Cell reselection parameters are applicable to all UEs in a cell, but it is possible to configure specific reselection
parameters per UE group or per UE.
- It should be possible to prevent the UE from reselecting to specific detected neighbouring cells.
3GPP
Release 17 167 3GPP TS 36.300 V17.2.0 (2022-09)
10.2.2 Handover
Inter RAT HO is designed so that changes to GERAN, UTRAN and NR are minimised. This can be done by following
the principles specified for GERAN to/from UTRAN intersystem HO. In particular the following principles are applied
to E-UTRAN Inter RAT HO design:
1. Inter RAT HO is network controlled through source access system. The source access system decides about
starting the preparation and provides the necessary information to the target system in the format required by the
target system. That is, the source system adapts to the target system. The actual handover execution is decided in
the source system.
2. Inter RAT HO is backwards handover, i.e. radio resources are prepared in the target 3GPP access system before
the UE is commanded by the source 3GPP access system to change to the target 3GPP access system.
3. To enable backwards handover, and while RAN level interfaces are not available, a control interface exists in
CN level. In Inter RAT HO involving E-UTRAN access, this interface is between:
- 2G/3G SGSN and corresponding MME/Serving Gateway;
- AMF/UPF and corresponding MME/Serving Gateway.
4. The target access system will be responsible for giving exact guidance for the UE on how to make the radio
access there (this includes radio resource configuration, target cell system information etc.). This information is
given during the handover preparation and should be transported completely transparently through the source
access system to the UE.
5. Mechanisms for avoiding or mitigating the loss of user data (i.e. forwarding) can be used until the 3GPP Anchor
determines that it can send DL U-plane data directly to the target system.
6. The handover procedure should not require any UE to CN signalling in order for data to start to flow in the target
system. This requires that the security context, UE capability context and QoS context is transferred (or
translated) within the network between source and target system.
7. Similar handover procedure should apply for handovers of both real time and non-real time services.
8. Similar handover procedure should apply for Inter RAT Handover, intra-LTE Handover with EPC node change,
and intra-E-UTRA inter-system Handover.
9. Network controlled mobility is supported even if no prior UE measurements have been performed on the target
cell and/or frequency i.e. "blind HO" is supported.
10. Inter-RAT HO from E-UTRA with EN-DC configuration to GERAN/UTRAN/NR is supported.
11. Inter-RAT HO from GERAN/UTRAN to E-UTRA with EN-DC configuration is not supported.
12. Inter-RAT HO from NR standalone to E-UTRA with EN-DC configuration is supported.
10.2.2a Inter-RAT cell change order to GERAN with NACC

For interworking towards GERAN, inter-RAT cell change order with NACC is supported even if no prior UE
measurements have been performed on the system i.e. "blind NACC" is supported.
10.2.2b Inter-RAT handovers from E-UTRAN

10.2.2b.1 Data forwarding
10.2.2b.1.1 For RLC-AM bearers
Upon handover, the eNB may forward all downlink PDCP SDUs that have not been acknowledged by the UE, or all
downlink PDCP SDUs that have not been transmitted to the UE, to the target node. In addition, the eNB may forward
fresh data arriving over S1 to the target node.
NOTE: Any assigned PDCP SNs are not forwarded because of PDCP reset.
3GPP
Release 17 168 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE: Target node does not have to wait for the completion of forwarding from the eNB before it begins
transmitting packets to the UE.
The eNB discards any remaining downlink RLC PDUs.
Upon handover, all successfully received PDCP SDUs are delivered to the upper layers in the UE.
NOTE: eNB does not need to abort ongoing RLC transmissions with the UE as it starts data forwarding to the
target node.
Upon handover, the eNB may forward uplink PDCP SDUs successfully received to the Serving Gateway and shall
discard any remaining uplink RLC PDUs.
Correspondingly, the eNB does not forward the downlink and uplink RLC context.
For the uplink, the UE transmits over the target RAT from the first PDCP SDU for which transmission has not been
attempted in the source cell.
In-sequence delivery of upper layer PDUs during handover is not guaranteed.
10.2.2b.1.2 For RLC-UM bearers

Upon handover, the eNB does not forward to the target node downlink PDCP SDUs for which transmission had been
completed in the source cell. PDCP SDUs that have not been transmitted may be forwarded. In addition, the eNB may
forward fresh data arriving over S1 to the target node. The eNB discards any remaining downlink RLC PDUs.
Upon handover, all successfully received PDCP SDUs are delivered to the upper layers in the UE.
Upon handover, the eNB may forward all uplink PDCP SDUs successfully received to the Serving Gateway and
discards any remaining uplink RLC PDUs.
For the uplink, the UE transmits over the target RAT from the first PDCP SDU for which transmission has not been
attempted in the source cell.
Correspondingly, the eNB does not forward the downlink and uplink RLC context.
10.2.2c Intra-EUTRA inter-system Handover

For intra-EUTRA handover, the source node decides whether to trigger inter-system HO (with CN type change) or
intra-system HO (without CN type change). The UE gets the knowledge of the target CN type from handover command
during handover procedure.
10.2.3 Measurements
10.2.3.1 Inter-RAT handovers from E-UTRAN
Measurements to be performed by a UE for inter-RAT mobility can be controlled by E-UTRAN, using broadcast or
dedicated control. In RRC_CONNECTED state, a UE shall follow the measurement parameters specified by RRC
directed from the E-UTRAN (e.g. as in UTRAN MEASUREMENT_CONTROL).
UE performs inter-RAT neighbour cell measurements during DL/UL idle periods that are provided by the network
through suitable DRX/DTX period or packet scheduling if necessary.
10.2.3.2 Inter-RAT handovers to E-UTRAN

From UTRAN, UE performs E-UTRAN measurements by using idle periods created by compressed mode
(CELL_DCH) or DRX (other states) or measurement occasions (CELL_FACH).
From GERAN, E-UTRAN measurements are performed in the same way as WCDMA measurements for handover to
UTRAN: E-UTRAN measurements are performed in GSM idle frames in a time multiplexed manner.
For NR, UE performs E-UTRAN measurements according to the measurement configuration decided by gNB.
3GPP
Release 17 169 3GPP TS 36.300 V17.2.0 (2022-09)
10.2.3.3 Inter-RAT cell reselection from E-UTRAN

In RRC_IDLE state, a UE shall follow the measurement parameters specified by the E-UTRAN broadcast (as in
UTRAN SIB). The use of dedicated measurement control is possible through the provision of UE specific priorities (see
clause 10.2.4).
10.2.3.4 Limiting measurement load at UE

Introduction of E-UTRA implies co-existence of various UE capabilities. Each UE may support different combinations
of RATs, e.g., E-UTRA, UTRA, GSM, and non-3GPP RATs, and different combinations of frequency bands, e.g., 800
MHz, 1.7 GHz, 2 GHZ, etc. Despite such heterogeneous environment, the measurement load at UE should be
minimised. To limit the measurement load and the associated control load:
- E-UTRAN can configure the RATs to be measured by UE;
- The number of measurement criteria (event and periodic reporting criteria) should be limited (as in TS 25.133
[7] clause 8.3.2);
- E-UTRAN should be aware of the UE capabilities for efficient measurement control, to prevent unnecessary
waking up of the measurement entity;
- Blind HO (i.e., HO without measurement reports from UE) is possible.
10.2.3.5 Inter-RAT measurements in RRC_IDLE or RRC_INACTIVE

Network may request UE to measure NR carriers in RRC_IDLE or RRC_INACTIVE via system information or via
dedicated measurement configuration in RRC Connection Release. The UE performs the requested measurements and
provides indication of the availability of measurement report to the eNB during RRC Connection Setup or Resume
procedure. The network may request UE to report those measurements after security activation. The request for the
measurements can be sent by the network immediately after transmitting the Security Mode Command (i.e. before the
reception of the Security Mode Complete from the UE). Alternatively, during connection resume from suspended RRC
connection or from RRC_INACTIVE, the eNB can request the UE to provide the idle/inactive measurement results in
the RRCConnectionResume message and then the UE can include the available measurement results in the
RRCConnectionResumeComplete message.
10.2.4 Network Aspects

Inter-frequency/inter-RAT UE based mobility relies on a "priority based scheme", where the network configures a list
of RATs/frequencies to be taken as basis for UE's inter-frequency/inter-RAT cell reselection decisions in priority order.
E-UTRAN cells can enable inter-frequency/inter-RAT cell reselection by broadcasting a common priority valid for all
UEs in a given cell in addition to other inter-frequency/inter-RAT information.
NOTE: The same principles apply in UTRAN.
These common priorities can be overwritten by E-UTRAN through dedicated signalling to individual UEs at
RRC_CONNECTED to RRC_IDLE transition.
NOTE: In order to have consistent inter-RAT operation, the same principles apply to inter-RAT reselection to E-
UTRAN. For UTRAN this includes also the transitions within RRC_CONNECTED state from
CELL_DCH to CELL_PCH and URA_PCH.
Setting dedicated priorities by E-UTRAN can be based on subscription related information provided by the MME.
Based on operator policy the eNBs may be configured to always integrity protect the redirection to GERAN as
described in TS 33.401 [22].
10.2.5 CS fallback
CS fallback can be performed via different options. The following table summarize the various CS fallback options per
RAT, necessary UE capabilities and FGI index which should be set to '1'. The meaning of FGI index is specified in TS
36.331 [16], Annex B.
3GPP
Release 17 170 3GPP TS 36.300 V17.2.0 (2022-09)
Table 10.2.5-1: CS fallback options
Target RAT Solutions Release UE Capability FGI Index

CS fallback to RRC Connection Release with Rel-8 (NOTE 1)
UMTS Redirection without Sys Info Mandatory for UEs
supporting CS fallback to
UMTS
RRC Connection Release with Rel-9 (NOTE 1)
Redirection with Sys Info e-RedirectionUTRA
PS handover with DRB(s) Rel-8 (NOTE 1) FGI8, FGI22
Mandatory for UEs
UMTS
GSM Redirection without Sys Info Mandatory for UEs
GSM
RRC Connection Release with Rel-9 (NOTE 2)
Redirection with Sys Info Mandatory for UEs
GSM
Cell change order without Rel-8 (NOTE 2) FGI10
NACC Mandatory for UEs
GSM
Cell change order with NACC Rel-8 (NOTE 2) FGI10
Mandatory for UEs
GSM
PS handover Rel-8 (NOTE 2)
interRAT-PS-HO-
ToGERAN
NOTE 1: All CS fallback to UMTS capable UE shall indicate that it supports UTRA FDD or TDD and supported band
list in the UE capability.
NOTE 2: All CS fallback to GSM capable UE shall indicate that it supports GERAN and supported band list in the UE
capability.
NOTE 3: The measurement may be performed before any of the above CS fallback solution is triggered to select the
target cell or frequency layer more accurately based on eNB decision. eNB may trigger any of above CS
fallback solutions blindly.
10.2.6 Idle mode Inter-RAT Cell Selection to/from NB-IoT

NB-IoT may provide assistance information for inter-RAT cell selection to E-UTRAN/GERAN and E-UTRAN may
provide assistance information for inter-RAT cell selection to NB-IoT. A UE may use the assistance information
provided by the network for cell selection to/from NB-IoT.
10.3 Mobility between E-UTRAN and Non-3GPP radio

technologies
10.3.1 UE Capability Configuration
A UE shall be able to communicate with the E-UTRAN about its radio access capability, such as the system (including
the release and frequency band) it supports and its receive and transmit capabilities (single/dual radio, dual receiver).
UE shall transfer its capability about other radio technologies over E-UTRAN using the same procedure used to carry
its E-UTRAN radio capability.
10.3.2 Mobility between E-UTRAN and cdma2000 network

This clause describes the E-UTRAN mechanisms to support idle and active mode mobility between E-UTRAN and
cdma2000 HRPD or 1xRTT. The overall system is described in TS 23.401 [17].
3GPP
Release 17 171 3GPP TS 36.300 V17.2.0 (2022-09)
10.3.2.1 Tunnelling of cdma2000 Messages over E-UTRAN between UE and

cdma2000 Access Nodes
In order to efficiently support handover procedures when on E-UTRAN with a cdma2000 target system, cdma2000
messages are sent transparently to the target system over the E-UTRAN, with the eNB and MME acting as relay points.
To support the MME in its selection of the correct target system node to which it should route an Uplink tunnelled
message and to provide the target system with information that is needed to resolve technology-specific measurement
information (RouteUpdate and pilot strength measurements) that are delivered to the cdma2000 system, each eNB cell
is associated with a cdma2000 HRPD SectorID and/or with a cdma2000 1xRTT SectorID (generically referred to as
cdma2000 reference cellid). This cdma2000 reference cellid is provided by the eNB to the MME using the cdma2000
message transfer capability over S1-AP and forwarded to the target system via the S101 interface and corresponding
interface to the cdma2000 1xRTT system.
Tunnelling is achieved over the E-UTRAN radio interface by encapsulating tunnelled cdma2000 messages in the UL
Information Transfer (for pre-registration signalling) or UL Handover Preparation transfer (for handover signalling) and
DL Information Transfer RRC messages (e.g., similar to UMTS Uplink/Downlink Direct Transfer). The reason for
using different UL transfer messages is so that the UL Handover Preparation transfer messages can use a higher priority
signalling radio bearer. For the UL/DL Information Transfer messages a specific IE in these RRC messages is used to
identify the type of information contained in the message (e.g., NAS, TunneledMsg). Additionally if the message is
carrying a tunnelled message, an additional IE is included to carry cdma2000 specific RRC Tunnelling Procedure
Information (e.g. RAT type).
AS level security will be applied for these UL Information Transfer / UL Handover Preparation Transfer and DL
Information Transfer RRC messages as normal but there is no NAS level security for these tunnelled cdma2000
messages.
Figure 10.3.2.1-1: Downlink Direct Transfer
Figure 10.3.2.1-2: Uplink Direct Transfer
Tunnelling to the MME is achieved over the S1-MME interface by encapsulating the tunnelled cdma2000 message in a
new S1 CDMA tunnelling messages. These S1 messages carry in addition to the tunnelled message some additional
cdma2000 specific IEs (e.g. cdma2000 Reference Cell Id, RAT type, cdma2000 message type).
10.3.2.2 Mobility between E-UTRAN and HRPD

10.3.2.2.1 Mobility from E-UTRAN to HRPD
10.3.2.2.1.1 HRPD System Information Transmission in E-UTRAN
The HRPD system information block (SIB) shall be sent on the E-UTRAN BCCH. The UE shall monitor the E-
UTRAN BCCH during the RRC_IDLE and RRC_CONNECTED modes to retrieve the HRPD system information for
3GPP
Release 17 172 3GPP TS 36.300 V17.2.0 (2022-09)
the preparation of cell reselection or handover from the E-UTRAN to HRPD system. HRPD system information may
also be provided to the UE by means of dedicated signalling. The HRPD system information contains HRPD
neighbouring cell information, cdma timing information, as well as information controlling the HRPD pre-registration.
10.3.2.2.1.2 Measuring HRPD from E-UTRAN
Measurement events and parameters for HRPD measurements are to be aligned with those defined in clause 10.2.3.
10.3.2.2.1.2.1 Idle Mode Measurement Control
UE shall be able to make measurements on the HRPD cells in RRC_IDLE mode to perform cell re-selection.
The intra-3GPP inter-RAT idle mode measurement control is re-used to control the idle mode measurements on HRPD.
The UE performs measurement on HRPD when the signal quality from E-UTRAN serving cell falls below a given
threshold.
10.3.2.2.1.2.2 Active Mode Measurement Control
In RRC_CONNECTED mode, the UE shall perform radio measurements on the HRPD network when directed by the
E-UTRAN network. The network provides the required HRPD neighbour cell list information and measurement
controls to the UE through dedicated RRC signalling. When needed the eNB is responsible for configuring and
activating the HRPD measurements on the UE via the dedicated RRC signalling message. Periodic and event-triggered
measurements are supported.
For single-radio terminals, measurement gaps are needed to allow the UE to switch into the HRPD network and do
radio measurements. These measurement gaps are network-controlled. The eNB is responsible for configuring the gap
pattern and providing it to the UE through RRC dedicated signalling. Terminals with a dual receiver perform
measurements on HRPD neighbour cells without tuning away from the E-UTRAN network. No DL gap patterns will be
required for UEs which are capable of simultaneous reception on the involved frequency bands. No UL gap patterns
will be required for UEs which are capable simultaneous transmission in one access and measuring on another access.
10.3.2.2.1.2.3 Active Mode Measurement
In RRC_CONNECTED mode, the UE measures the strengths of each of the HRPD neighbour cells and reports them in
an RRC message.
10.3.2.2.1.3 Pre-registration to HRPD Procedure
Pre-registration allows a UE to establish a presence with an HRPD system in advance of a cell re-selection or handover.
E-UTRAN network instructs the UE whether the pre-registration is needed over broadcast channel and in a dedicated
RRC message.
The signalling procedure is transparent to E-UTRAN network. In the pre-registration to HRPD, messages shall be
tunnelled inside RRC and S1-AP messages between the UE and MME and in a generic "transfer" message between
source MME and target access network.
The UE is responsible for maintaining the HRPD context e.g. by performing periodic re-registrations if needed. The UE
will use pre-registration zone information (including the current HRPD Pre-registration Zone and a list of HRPD
Secondary Pre-registration Zone ID) to decide whether a re-registration shall be performed. A dual-receiver UE can
ignore the parameter. E-UTRAN will provide the pre-registration zone information on the E-UTRAN system
information broadcast channel or dedicated RRC signalling (unless it is determined that the UE will read the E-UTRAN
system information broadcast channel in RRC_CONNECTED). Re-registrations are only allowed in areas where pre-
registration is requested.
The managing of pre-registration and re-registration is handled by HRPD upper layer. The UE should indicate if it is
pre-registered when sending measurement reports on cdma2000 cells.
10.3.2.2.1.4 E-UTRAN to HRPD Cell Re-selection
For the "Optimized Idle-mode Mobility" in TS 23.402 [19], the pre-condition for cell re-selection from E-UTRAN to
HRPD is that the UE has previously established a presence in the target HRPD network, either through the pre-
registration procedure or previous HRPD attachment.
For the "Non-optimized Handover" in TS 23.402 [19], the above pre-condition does not apply.
The UE performs Cell re-selection to HRPD while in RRC_IDLE.
3GPP
Release 17 173 3GPP TS 36.300 V17.2.0 (2022-09)
Cell reselection from E-UTRAN to HRPD should be aligned with 3GPP inter RAT cell reselection mechanism.
10.3.2.2.1.5 E-UTRAN to HRPD Handover
The pre-condition for the E-UTRAN to HRPD Handover procedure is that the UE is attached in the E-UTRAN network
in E-UTRAN_ACTIVE state and has pre-registered with the HRPD network. Based on measurement reports received
from the UE the eNB initiates a handover by sending an RRC Handover FROM E-UTRA PREPARATION REQUEST
message to the UE to indicate to the UE that it should begin the handover procedure. This message shall include the
specified target RAT type and any cdma2000 specific HRPD parameters needed by the UE to create the appropriate
HRPD messages needed to request a connection. Upon reception of this message the UE should begin handover
signalling towards the HRPD access. The HRPD handover signalling is tunnelled through E-UTRAN between the UE
and HRPD network. These HRPD parameters and HRPD messages are transparent to E-UTRAN. The set of the
required HRPD parameters are out of scope of this specification.
The messages are transferred inside RRC transfer messages and S1 CDMA2000 tunnelling messages. The MME will,
based on indication provided by the HRPD network, get information about if the handover succeeded or failed making
it possible for the MME set the handover status in the S1 CDMA2000 tunnelling messages (e.g. handover success,
handover failure). In case the handover succeeded E-UTRAN will include the tunnelled "CDMA2000 handover
command", which will be sent to the UE, inside the RRC MOBILITY from E-UTRA COMMAND message.
The UE can continue to send and receive data on the E-UTRAN radio until it receives the RRC MOBILITY from E-
UTRA COMMAND message including a tunnelled "CDMA2000 handover command". After this message is received
by the UE, the UE shall leave the E-UTRAN radio and start acquiring the HRPD traffic channel. The HRPD handover
signalling is tunnelled between the UE and HRPD network.
10.3.2.2.2 Mobility from HRPD to E-UTRAN

Mobility from HRPD to E-UTRAN has no impact on the E-UTRAN.
10.3.2.3 Mobility between E-UTRAN and cdma2000 1xRTT

10.3.2.3.1 Mobility from E-UTRAN to cdma2000 1xRTT
10.3.2.3.1.1 cdma2000 1xRTT System Information Transmission in E-UTRAN
The cdma2000 1xRTT system information block (SIB) shall be sent on E-UTRAN BCCH. The UE shall monitor the E-
UTRAN BCCH during the RRC_IDLE and RRC_CONNECTED modes to retrieve the 1xRTT system information for
the preparation of handover from the E-UTRAN to cdma2000 1xRTT system. 1xRTT system information may also be
provided to the UE by means of dedicated signalling. The 1xRTT system information contains 1xRTT neighbouring
cell information, cdma timing information, and 1xRTT CS Fallback information.
10.3.2.3.1.2 Measuring cdma2000 1xRTT from E-UTRAN
Measurement events and parameters for 1xRTT measurements are to be aligned with those defined in clause 10.2.3.
10.3.2.3.1.2.1 Idle Mode Measurement Control
UE shall be able to make measurements on the 1xRTT system cells in LTE_IDLE mode to perform cell re-selection.
UE shall perform cdma2000 1xRTT neighbour cell measurements during DRX periods, between paging occasions.
The intra-3GPP inter-RAT idle mode measurement control is re-used to control the idle mode measurements on
cdma2000 1xRTT. The UE performs measurement on cdma2000 1xRTT when the signal quality from E-UTRAN
serving cell falls below a given threshold.
10.3.2.3.1.2.2 Active Mode Measurement Control
In the E-UTRAN network, in RRC_CONNECTED mode, the UE shall perform radio measurements on the cdma2000
1xRTT network when directed by the E-UTRAN network. The network provides the required cdma2000 1xRTT
neighbour cell list information and measurement controls to the UE through dedicated RRC signalling. When needed
the eNB is responsible for configuring and activating the cdma2000 1xRTT measurements on the UE via the dedicated
RRC signalling message. As for intra-3GPP inter-RAT measurement reporting, periodic and event-triggered
measurements are supported.
For single-radio terminals, measurement gaps are needed to allow the UE to switch into the cdma2000 1xRTT network
and do radio measurements. These Measurement gaps are network-controlled. The eNB is responsible for configuring
3GPP
Release 17 174 3GPP TS 36.300 V17.2.0 (2022-09)
the gap pattern and providing it to the UE through RRC dedicated signalling. Terminals with a dual receiver perform
measurements on cdma2000 1xRTT neighbour cells without tuning away from the E-UTRAN network. No DL gap
patterns will be required for UEs which are capable of simultaneous reception on the involved frequency bands. No UL
gap patterns will be required for UEs which are capable simultaneous transmission in one access and measuring on
another access.
10.3.2.3.1.2.3 Active Mode Measurement
In RRC_CONNECTED mode, the UE measures the strengths of each of the cdma2000 1xRTT neighbour cells and
reports them in an RRC Message.
10.3.2.3.1.3 E-UTRAN to cdma2000 1xRTT Cell Re-selection
UE performs Cell re-selection to cdma2000 1xRTT while in RRC_IDLE.
Cell reselection from E-UTRAN to 1xRTT should be aligned with 3GPP inter RAT cell reselection mechanism.
10.3.2.3.1.4 E-UTRAN to cdma2000 1xRTT Handover
In the high level procedure for handover from E-UTRAN to cdma2000 1xRTT except 1xRTT CS Fallback, registration
and handover is performed directly after the handover decision has been made. Based on measurement reports received
from the UE the eNB initiates a handover by sending a RRC Handover FROM E-UTRA PREPARATION REQUEST
message to the UE to indicate to the UE that it should begin the handover procedure. This message shall include the
specified target RAT type and any cdma2000 specific 1xRTT access parameters needed by the UE to create the
appropriate 1xRTT Origination Request message. The 1xRTT handover signalling is tunnelled between the UE and
1xRTT network. The 1xRTT access parameters and 1xRTT messages are transparent to E-UTRAN. The set of the
required 1xRTT access parameters are out of scope of this specification.
The messages are transferred inside RRC transfer messages and S1 CDMA2000 tunnelling messages. The MME will,
based on indication provided by the 1xRTT network, get information about if the handover succeeded or failed making
it possible for the MME set the handover status in the S1 CDMA2000 tunnelling messages (e.g. handover success,
handover failure). In case the handover succeeded E-UTRAN will include the tunnelled "CDMA2000 handover
command", which will be sent to the UE, inside the RRC MOBILITY FROM E-UTRA COMMAND message.
The UE can continue to send and receive data on the E-UTRAN radio until it receives the RRC MOBILITY FROM E-
UTRA COMMAND message including a tunnelled "CDMA2000 handover command". After this message is received
by the UE, the UE shall leave the E-UTRAN radio and start acquiring the 1xRTT traffic channel.
10.3.2.3.2 Mobility from cdma2000 1xRTT to E-UTRAN

Mobility from cdma2000 1xRTT has no impact on E-UTRAN.
10.3.2.3.3 1xRTT CS Fallback

CS fallback to 1xRTT enables the delivery of CS-domain services when a UE is being served by the E-UTRAN, as
The UE initiates 1xCSFB (e.g. to perform a 1xCS call origination or accept a 1xCS call termination) by using NAS
signalling to send a CSFB indication to the MME. The MME then indicates to the eNB that 1xCSFB is required, which
triggers the eNB to execute one of the following 1xCSFB procedures depending on network support and UE capability:
- Rel-8 1xCSFB, characterized by RRC connection release with redirection to 1xRTT;
- enhanced 1xCSFB, characterized by 1xRTT handover signalling tunnelled between the UE and 1xRTT network;
- dual receiver 1xCSFB, characterized by RRC connection release without redirection information; or
- dual receiver/transmitter enhanced 1xCSFB, characterized by either 1xRTT handover signalling tunnelled
between the UE and 1xRTT network, or redirection of the UE's second radio to 1xRTT.
The network advertises its support for Rel-8 1xCSFB by broadcasting 1xRTT pre-registration parameters in system
information (SIB8). The Rel-8 1xCSFB procedure is the default procedure, when no other 1xCSFB procedure can be
performed. If Rel-8 1xCSFB is to be performed, the eNB optionally solicits 1xRTT measurements from the UE, and
then sends an RRC Connection Release message with redirection to 1xRTT. The UE then performs the normal 1xCS
call origination or termination procedure in the 1xRTT access network.
3GPP
Release 17 175 3GPP TS 36.300 V17.2.0 (2022-09)
A network which advertises support for Rel-8 1xCSFB may also support enhanced 1xCSFB, in which case the eNB
determines to perform enhanced 1xCSFB based on UE capability. If enhanced 1xCSFB is to be performed, the eNB
optionally solicits 1xRTT measurements from the UE, and then sends it a Handover From EUTRA Preparation Request
message. This triggers the UE to send the UL Handover Preparation Transfer message containing 1xRTT dedicated
information. The 1xRTT information is contained inside RRC and S1-AP messages between the UE and MME and in a
generic "transfer" message between MME and 1xRTT network. The response from the 1xRTT network triggers the
eNB to send a Mobility From EUTRA Command message which includes a 1xRTT channel assignment message that
causes the UE to acquire a traffic channel in the 1xRTT access network. In addition to enhanced 1xCSFB, the eNB may
determine to perform concurrent mobility to HRPD based on UE capability; if so, then two separate UL Handover
Preparation Transfer messages are triggered from the UE containing 1xRTT and HRPD dedicated information,
respectively. The concurrent HRPD handover procedure is handled independently from the e1xCSFB procedure, except
that responses from the 1xRTT and HRPD networks shall be combined by the eNB into a single Mobility From EUTRA
Command message.
The network advertises support for dual receiver 1xCSFB by broadcasting the dual receiver 1xCSFB support indicator
in system information (SIB8). The eNB determines to perform dual receiver 1xCSFB if the UE has a dual Rx
configuration according to UE capability, and enhanced 1xCSFB cannot be performed (i.e. because enhanced 1xCSFB
is not supported by both network and UE). If dual receiver 1xCSFB is to be performed, the eNB sends an RRC
Connection Release message without including redirection information. The UE then performs the normal 1xCS call
origination or termination procedure in the 1xRTT access network. A UE with dual Rx configuration may initiate
1xCSFB to a network broadcasting 1xRTT pre-registration parameters but not broadcasting the dual receiver 1xCSFB
support indicator; in this case, the UE may receive an RRC Connection Release message with redirection to 1xRTT.
The network advertises support for dual receiver/transmitter enhanced 1xCSFB (dual Rx/Tx e1xCSFB) by broadcasting
the dual Rx/Tx e1xCSFB support indicator in system information (SIB8). The eNB determines to perform dual Rx/Tx
e1xCSFB if the UE supports dual Rx/Tx e1xCSFB according to UE capability. If the network does not advertise
support for dual Rx/Tx e1xCSFB, UE which have dual Rx/Tx configuration may decide to keep the 1xRTT
receiver/transmitter turned on in order to continuously operate in both 1xRTT and E-UTRAN. If dual Rx/Tx e1xCSFB
is to be performed, the eNB optionally solicits 1xRTT measurements from the UE, and then sends a Handover From
EUTRA Preparation Request message. This triggers the UE to perform one of the following:
- send the UL Handover Preparation Transfer message containing 1xRTT dedicated information. The 1xRTT
information is contained inside RRC and S1-AP messages between the UE and MME and in a generic "transfer"
message between MME and 1xRTT network. The response from the 1xRTT network triggers the eNB to send a
DL Information Transfer message which includes a 1xRTT channel assignment message that causes the UE to
acquire a traffic channel in the 1xRTT access network while continuing to be served by the E-UTRAN (for PS-
domain services).
- direct its second radio to 1xRTT, where it performs the 1xCS call origination or termination procedure in the
1xRTT access network while continuing to be served by the E-UTRAN (for PS-domain services).
The following table summarizes the various CS fallback options for 1xRTT, necessary UE capabilities and FGI index
which should be set to '1'. The meaning of FGI index is specified in TS 36.331 [16], Annex B.
3GPP
Release 17 176 3GPP TS 36.300 V17.2.0 (2022-09)
Table 10.3.2.3.3-1: CS fallback options
Target RAT Solutions Release UE Capability FGI Index

1xRTT Redirection Mandatory for UEs
1xRTT
enhanced 1xCSFB Rel-9 (NOTE 1)
e-CSFB-1XRTT
enhanced 1xCSFB with Rel-9 (NOTE 1) FGI12, FGI26
concurrent HRPD handover e-CSFB-ConcPS-
Mob1XRTT, Support of
HRPD,
supportedBandListHRPD
dual receiver 1xCSFB (RRC Rel-9 (NOTE 1)
Connection Release without rx-Config1XRTT (set to
Redirection) 'dual')
dual receiver/transmitter Rel-10 (NOTE 1)
enhanced 1xCSFB e-CSFB-dual-1XRTT
NOTE 1: All CS fallback to 1xRTT capable UE shall indicate that it supports 1xRTT and supported band list in the UE
capability.
NOTE 2: The measurement may be performed before any of the above CS fallback solution is triggered to select the
target cell or frequency layer more accurately based on eNB decision. eNB may trigger any of above CS
fallback solutions blindly.
10.3.2.3.3.1 Pre-registration Procedure for 1xRTT CSFB
A 1xCSFB capable terminal may pre-register in the 1xRTT network via the E-UTRAN in order to establish CS services
(e.g. originating and terminating voice calls) in the 1xRTT network. Pre-registration applies only to Rel-8 1xCSFB,
enhanced 1xCSFB and dual receiver/transmitter enhanced 1xCSFB. It does not apply to dual receiver 1xCSFB, since
the UE registers directly in the 1xRTT network using the normal 1xCS registration procedure.
The UE determines whether pre-registration is needed based on 1xRTT pre-registration parameters broadcast in system
information (SIB8). Before performing a 1xRTT pre-registration, the UE requests from the eNB the necessary
information to perform the 1xRTT pre-registration using the CDMA2000 CSFB Parameters Request message. The eNB
provides the necessary parameters in the CDMA2000 CSFB Parameters Response message. These necessary
parameters are pre-configured in the eNB and are transparent to E-UTRAN.
The UE is responsible for maintaining the 1xRTT context, e.g. by performing re-registrations if needed. The UE will
use the 1xRTT pre-registration information to decide whether a re-registration shall be performed. A dual receiver UE
which registers directly in the 1xRTT network can ignore these parameters. Re-registrations are only allowed in areas
where pre-registration is allowed.
The management of the pre-registration and re-registration is handled by the 1xRTT upper layer in the UE.
10.3.3 CDMA2000 interworking in LTE shared networks

LTE system information (SIB8) can contain parameters for multiple CDMA2000 networks to allow the different
PLMNs to inter-work with different CDMA2000 networks. There is a one to one mapping between PLMN and
CDMA2000 network in that each LTE PLMN in SIB1 can inter-work with only one CDMA2000 network. Thus the
UE, eNB and MME implicitly knows the CDMA2000 network from the UE's RPLMN. All UEs not supporting the per-
PLMN signalling inter-work with the same CDMA2000 network independent of their RPLMN.
10.4 Area Restrictions

NOTE: The term Area Restrictions is not used in Rel-11 and onwards. It has been replaced by the term Roaming
and Access Restrictions, see clause 10.4a.
10.4a Roaming and Access Restrictions

The roaming and access restriction information for a UE includes information on restrictions to be applied for
subsequent mobility action during ECM-CONNECTED state. It includes the Serving PLMN and may include a list of
3GPP
Release 17 177 3GPP TS 36.300 V17.2.0 (2022-09)
equivalent PLMNs and other information. It may be provided by the MME at context setup over the S1 interface, and
may be updated by the MME during S1 Handover, and when sending NAS Downlink messages.
NOTE: In case of GWCN network sharing scenario, the roaming and access restriction information should always
be provided by the MME to the eNBs.
Upon receiving the roaming and access restriction information for a UE, the eNB shall store it and thereafter it should
use it to determine whether to apply restriction handling for subsequent mobility action for which the eNB provides
information about the target of the mobility action towards the UE, e.g., handover and CCO, if applicable as specified in
TS 23.401 [17] and TS 23.272 [23]. If the roaming and access restriction information is not available at the eNB, the
eNB shall consider that there is no restriction for subsequent mobility actions.
Only if received via S1 signalling or X2 signalling, the roaming and access restriction information for a UE shall be
propagated by the source eNB over X2 at intra E-UTRAN handover. For the case when the X2 handover results in a
change of serving PLMN (to an equivalent PLMN), the source eNB shall replace the Serving PLMN with the identity of
the target PLMN and move the Serving PLMN to the equivalent PLMN list, before propagating the roaming and access
restriction information.
SCG selection for DC at the MeNB is based upon roaming and access restriction information. If the roaming and access
restriction information is not available at the MeNB, the MeNB shall consider that there is no restriction for the SCG
selection. In case of RAN sharing scenarios, the MeNB selects the serving PLMN ID of the SCG and provides it to the
SeNB.
SCG (re)selection for EN-DC at the SgNB is based on roaming and access restriction information in SgNB. If roaming
and access restriction information is not available at the SgNB, the SgNB shall consider that there is no restriction for
SCG (re)selection. Therefore, MeNB needs to convey the up-to-date roaming and access restriction information from
MME to SgNB via X2AP messages.
If eNBs with different versions of the X2AP or S1AP protocol are deployed, information provided by the EPC within
the S1AP Handover Restriction List may be lost in the course of X2 mobility. In order to avoid such loss of information
at X2 handover or UE context retrieval due to a source eNB or an old eNB not able to recognise the entire content, the
source eNB or the old eNB may provide an EPC Handover Restriction List Container to the target eNB or the new eNB,
containing the Handover Restriction List as received from the EPC. The target eNB or the new eNB shall use the
information contained in the EPC Handover Restriction List Container as the Handover Restriction List, except for the
Serving PLMN and the Equivalent PLMNs, which the eNB shall use from the X2AP Handover Restriction List. The
EPC Handover Restriction List Container may be propagated at future X2 handover and UE context retrieval.
NOTE: Alternatively, the EPC may provide the S1AP Handover Restriction List to the target eNB or new eNB at
path switch, either based on knowledge about the eNB's implementation status or always.
10.5 Mobility to and from CSG and Hybrid cells

10.5.0 Principles for idle-mode mobility with CSG cells
10.5.0.1 Intra-frequency mobility
Intra-frequency mobility in idle mode in the presence of CSG member cells is based on cell ranking and reselection
using the "best cell principle": For cell ranking and reselection, the UE may ignore all CSG cells that are known by the
UE not to be CSG member cells.
10.5.0.2 Inter-frequency mobility

For cell ranking and reselection, the UE should prioritize CSG member cells irrespective of normal network configured
frequency priorities.
10.5.0.3 Inter-RAT Mobility

Inter-RAT inbound mobility to E-UTRAN CSG cells is also supported by a UE autonomous search when the UE is
camped on a RAT other than E-UTRAN. The UE requirements are defined in the specifications of the concerned RAT.
3GPP
Release 17 178 3GPP TS 36.300 V17.2.0 (2022-09)
10.5.1 Inbound mobility to CSG cells

10.5.1.1 RRC_IDLE
Cell selection/reselection to CSG cells is based on a UE autonomous search function. The search function determines
itself when/where to search, and need not be assisted by the network with information about frequencies which are
dedicated to CSG cells.
To assist the search function on mixed carriers, all CSG cells on mixed carriers broadcast in system information a range
of PCI values reserved by the network for use by CSG cells. Optionally also non-CSG cells on the mixed carrier can
send this information in system information. The reserved PCI range is only applicable to the frequency of the PLMN
where the UE received this information. The UE considers the last received reserved range of PCI values for CSG cells
to be valid for a maximum of 24 hours within the entire PLMN. UE's use of the received PCI split information is UE
implementation dependent.
NOTE: In shared NW scenario, aligned PCI ranges are beneficial in the shared carrier frequency across the
involved PLMNs. Furthermore, in deployments where cells broadcast different primary PLMN (with or
without multiple PLMN IDs), it is beneficial that CSG and non-CSG cells will broadcast same PCI
ranges.
UE checks the suitability of CSG cells (identified by the 1 bit indicator) based on the Permitted CSG list in the UE
(provided by upper layers). Only CSG member cells are considered suitable.
The automated searching for the CSG cells by the UE shall be disabled by the search function, if the Permitted CSG list
configured in the UE is empty.
In addition, manual selection of CSG cells is supported.
Cell selection/reselection to CSG cells does not require the network to provide neighbour cell information to the UE.
The neighbour cell information can be provided to help the UE in specific cases, e.g. where the network wishes to
trigger the UE to search for CSG cells.
Cell Reselection between CSG member cells is based on normal cell reselection procedure.
10.5.1.2 RRC_CONNECTED
While the UE is in RRC_CONNECTED state, the UE performs normal measurement and mobility procedures based on
configuration provided by the network.
The UE is not required to support manual selection of CSG IDs while in RRC_CONNECTED state.
Handover to a HNB/HeNB follows the framework of UE assisted network controlled handover as described in 10.1.2.1.
Handover to a HNB/HeNB is different from the normal handover procedure in four aspects:
1. Proximity Estimation: in case the UE is able to determine, using autonomous search procedures, that it is near a
CSG member cell, the UE may provide to the source eNB an indication of proximity. The proximity indication
may be used as follows:
- If a measurement configuration is not present for the concerned frequency/RAT, the source eNB may
configure the UE to perform measurements and reporting for the concerned frequency/RAT.
- The source eNB may determine whether to perform other actions related to handover to HNB/HeNBs based
on having received a proximity indication (for example, the source eNB may not configure the UE to acquire
system information of the HNB/HeNB unless it has received a proximity indication).
2. PSC/PCI Confusion: due to the typical cell size of HNB/HeNBs being much smaller than macro cells, there can
be multiple HNBs/HeNBs within the coverage of the source eNB that have the same PSC/PCI. This leads to a
condition referred to as PSC/PCI confusion, wherein the source eNB is unable to determine the correct target cell
for handover from the PSC/PCI included in the measurement reports from the UE. PSC/PCI confusion is solved
by the UE reporting the global cell identity of the target HNB/HeNB.
3. Access Control: if the target cell is a hybrid cell, prioritization of allocated resources may be performed based
on the UE's membership status. Access control is done by a two step process, where first the UE reports whether
the target cell is a CSG member cell based on the UE's Permitted CSG list, and then the network verifies the
3GPP
Release 17 179 3GPP TS 36.300 V17.2.0 (2022-09)
reported status. When the UE has an emergency call the MME allows inbound mobility to CSG cells even if the
access control fails as specified in TS 23.401[17].
4. PLMN Selection: If the target cell is a shared CSG/hybrid cell, the UE reports the subset of the broadcasted
PLMN identities passing PLMN ID check and the Permitted CSG list of the UE includes an entry comprising of
the concerned PLMN identity and the CSG ID broadcast by the target cell. The source eNB performs PLMN ID
check for the PLMNs reported by the UE and selects one if multiple pass the PLMN ID check. Finally the MME
verifies the CSG membership according to the received CSG ID, the selected PLMN ID and stored subscription
CSG information of the UE.
Mobility from eNB/HeNB to a HeNB's CSG/hybrid cell may take place with the S1 Handover procedure. In the
following call flow the source cell can be an eNB or a HeNB.
The current version of the specification also supports mobility involving HeNBs by using X2 handover in some cases
(see clause 4.6.1). If membership verification is required for X2 mobility, the procedure described in clause 10.1.2.1
applies, with the following additions to the steps described in clause 10.1.2.1.1:
- In Step 4, the source eNB/HeNB includes the CSG membership status reported by the UE handed over in the
X2AP HANDOVER REQUEST message to the target HeNB; the target HeNB performs admission control
based on the CSG membership status reported by the UE;
- In Step 12, the target HeNB includes the CSG membership status of the UE handed over in the PATH SWITCH
REQUEST message to the MME;
- In Step 16, after the MME has performed membership verification for the UE handed over, the MME includes
its verified CSG membership status in the PATH SWITCH REQUEST ACKNOWLEDGE message to the target
HeNB; the target HeNB updates its membership information if needed.
The procedure below applies to any scenario where the CSG ID is provided by the UE or provided by the source eNB.
Figure 10.5.1.2-1: Mobility to HeNB's CSG and hybrid cells.
1) The source eNB configures the UE with proximity indication control.
2) The UE sends an "entering" proximity indication when it determines it may be near a CSG member cell (based
on autonomous search procedures). The proximity indication includes the RAT and frequency of the cell.
3GPP
Release 17 180 3GPP TS 36.300 V17.2.0 (2022-09)
3) If a measurement configuration is not present for the concerned frequency/RAT the source eNB configures the
UE with relevant measurement configuration including measurement gaps as needed, so that the UE can perform
measurements on the reported RAT and frequency. The network may also use the proximity indication to
minimize the requesting of handover preparation information of CSG/hybrid cells by avoiding requesting such
information when the UE is not in the geographical area where its CSG member cells are located.
4) The UE sends a measurement report including the PCI (e.g., due to triggered event A3).
5) The source eNB configures the UE to perform SI acquisition and reporting of a particular PCI.
6) The UE performs SI acquisition using autonomous gaps, i.e., the UE may suspend reception and transmission
with the source eNB within the limits defined in TS 36.133 [21] to acquire the relevant system information from
the target HeNB.
7) The UE sends a measurement report including (E-)CGI, TAI, CSG ID and "member/non-member" indication. If
the target cell is a shared CSG/hybrid cell, the measurement report also includes the subset of the broadcast
PLMN identities that pass PLMN ID check and for which the Permitted CSG list of the UE includes an entry
comprising the cell's CSG ID and the respective PLMN identity.
8) The source eNB includes the target E-CGI and the CSG ID in the Handover Required message sent to the MME.
If the target is a hybrid cell the Cell Access Mode of the target is included.
9) The MME performs UE access control to the CSG cell based on the CSG ID and the selected target PLMN
received in the Handover Required message and the stored CSG subscription data for the UE (see TS 23.401
[17]). If the access control procedure fails, the MME ends the handover procedure by replying with the
Handover Preparation Failure message. If the Cell Access Mode is present, the MME determines the CSG
Membership Status of the UE handing over to the hybrid cell and includes it in the Handover Request message.
10-11) The MME sends the Handover Request message to the target HeNB including the target CSG ID received in
the Handover Required message. If the target is a hybrid cell the CSG Membership Status will be included in the
Handover Request message.
12)The target HeNB verifies that the CSG ID received in the Handover Request message matches the CSG ID
broadcast in the target cell and if such validation is successful it allocates appropriate resources. UE prioritisation
may also be applied if the CSG Membership Status indicates that the UE is a member.
13-14) The target HeNB sends the Handover Request Acknowledge message to the MME via the HeNB GW if
present.
15)The MME sends the Handover Command message to the source eNB.
16)The source eNB transmits the Handover Command (RRC Connection Reconfiguration message including
mobility control information) to the UE.
NOTE: Steps 1-9, 15 and 16 also apply to inter-RAT mobility from LTE to HNB.
After sending an "entering" proximity indication (step 2), if the UE determines that it is no longer near a CSG member
cell, the UE sends a "leaving" proximity indication to the source eNB. Upon reception of this indication, the source eNB
may reconfigure the UE to stop measurements on the reported RAT and frequency.
In the above procedure, steps 2 and 3 may not be performed in case the UE has not previously visited the HeNB, e.g.,
when the UE first visits a hybrid cell.
The PCI confusion is resolved by steps 5, 6 and 7. The source eNB can request SI acquisition and reporting for any PCI,
not limited to PSCs/PCIs of CSG or hybrid cells.
10.5.2 Outbound mobility from CSG cells

10.5.2.1 RRC_IDLE
For a UE leaving a CSG cell in idle mode normal cell reselection based on configuration from the BCCH of the CSG
cell applies.
3GPP
Release 17 181 3GPP TS 36.300 V17.2.0 (2022-09)
10.5.2.2 RRC_CONNECTED
For a UE leaving a CSG cell in active mode normal network controlled mobility applies.
10.6 Measurement Model
Figure 10.6-1: Measurement model
- A: measurements (samples) internal to the physical layer.
- Layer 1 filtering: internal layer 1 filtering of the inputs measured at point A. Exact filtering is implementation
dependant. How the measurements are actually executed in the physical layer by an implementation (inputs A
and Layer 1 filtering) in not constrained by the standard.
- B: A measurement reported by layer 1 to layer 3 after layer 1 filtering.
- Layer 3 filtering: Filtering performed on the measurements provided at point B. The behaviour of the Layer 3
filters are 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: This 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 C'. The UE shall evaluate the reporting
criteria at least every time a new measurement result is reported at point C, C'. 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.
Layer 1 filtering will introduce a certain level of measurement averaging. How and when the UE exactly performs the
required measurements will be implementation specific to the point that the output at B fulfils the performance
requirements set in TS 36.133 [21]. Layer 3 filtering and parameters used is specified in TS 36.331 [16] and does not
introduce any delay in the sample availability between B and C. Measurement at point C, C' is the input used in the
event evaluation.
10.7 Hybrid Cells

10.7.0 General
Hybrid Cells have a CSG Indication bit set to FALSE but broadcast a CSG Identity and the PCI values for hybrid cells
are not contained within the reserved PCI range for CSG cells. Similar to CSG cells, the network can reserve a PCI list
for hybrid cells.
The network shall distinguish whether it is a hybrid cell, e.g. by reserving a PCI list for hybrid cells.
10.7.1 RRC_IDLE
When the CSG ID and associated PLMN ID of the hybrid cell belong to the Permitted CSG list of the UE, the hybrid
cell is considered by the UE as a CSG cell in idle mode cell selection/reselection procedures.
3GPP
Release 17 182 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE: The autonomous search for hybrid cells does not imply that a UE needs to constantly check the CSG ID
and associated PLMN ID of all cells it sees.
For all other UEs, normal cell selection/reselection procedures apply with hybrid cells (as for non CSG cells).
Manual selection of CSG IDs of hybrid cells is also supported in the same way as for CSG cells.
10.7.2 RRC_CONNECTED
10.7.2.1 Inbound Mobility
Inbound mobility to hybrid cells is described in clause 10.5.1.2.
10.7.2.2 Outbound Mobility

Procedure for outbound mobility from CSG cells applies (See clause 10.5.2.2).
11 Scheduling and Rate Control

11.0 General
In order to utilise the SCH resources efficiently, a scheduling function is used in MAC. In this clause, an overview of
the scheduler is given in terms of scheduler operation, signalling of scheduler decisions, and measurements to support
scheduler operation.
For NB-IoT, the Basic Scheduler Operation in 11.1, the uplink buffer status reports part in 11.3 and the DL channel
quality reporting in 11.7 are applicable, the UE-AMBR part in 11.4 is applicable only for UE which is enabled to use
S1-U data transfer or User Plane CIoT EPS optimisation or for UE which is enabled to use NG-U data transfer or User
Plane CIoT 5GS Optimisation, and all other subclauses of clause 11 are not applicable.
11.1 Basic Scheduler Operation

MAC in eNB includes dynamic resource schedulers that allocate physical layer resources for the DL-SCH, UL-SCH
and SL-SCH transport channels. Different schedulers operate for the DL-SCH, UL-SCH and SL-SCH.
The scheduler should take account of the traffic volume and the QoS requirements of each UE and associated radio
bearers, when sharing resources between UEs. Only "per UE" grants are used to grant the right to transmit on the UL-
SCH and SL-SCH (i.e. there are no "per UE per RB" grants).
Schedulers may assign resources taking account the radio conditions at the UE identified through measurements made
at the eNB and/or reported by the UE.
Radio resource allocations can be valid for one or multiple TTIs.
Resource assignment consists of physical resource blocks (PRB) and MCS. Allocations for time periods longer than one
TTI might also require additional information (allocation time, allocation repetition factor…).
When CA is configured, a UE may be scheduled over multiple serving cells simultaneously but at most one random
access procedure shall be ongoing at any time. Cross-carrier scheduling with the Carrier Indicator Field (CIF) allows
the PDCCH of a serving cell to schedule resources on another serving cell but with the following restrictions:
- Cross-carrier scheduling does not apply to PCell i.e. PCell is always scheduled via its PDCCH;
- When the PDCCH of an SCell is configured except for an LAA SCell, cross-carrier scheduling for uplink
transmission and downlink transmission does not apply to this SCell i.e. it is always scheduled for uplink
transmission and downlink transmission via its PDCCH;
- When the PDCCH of an LAA SCell is configured:
- If cross-carrier scheduling applies only to uplink transmission, it is scheduled for downlink transmission via
its PDCCH and for uplink transmission via the PDCCH of one other serving cell;
3GPP
Release 17 183 3GPP TS 36.300 V17.2.0 (2022-09)
- If self-scheduling applies to both uplink transmission and downlink transmission, it is always scheduled for
uplink transmission and downlink transmission via its PDCCH.
- When the PDCCH of an SCell is not configured, cross-carrier scheduling for uplink transmission and downlink
transmission applies and this SCell is always scheduled for uplink transmission and downlink transmission via
the PDCCH of one other serving cell.
A linking between UL and DL allows identifying the serving cell for which the DL assignment or UL grant applies
when the CIF is not present:
- DL assignment received on PCell corresponds to downlink transmission on PCell;
- For DC, DL assignment received on PSCell corresponds to downlink transmission on PSCell;
- UL grant received on PCell corresponds to uplink transmission on PCell, except for the UL grant in Random
Access Response from PCell in response to a random access preamble on SCell of MCG for which case the UL
grant is for the SCell where the preamble is sent;
- For DC, UL grant received on PSCell corresponds to uplink transmission on PSCell, except for the UL grant in
Random Access Response from PSCell in response to a random access preamble on SCell of SCG for which
case the UL grant is for the SCell where the preamble is sent.
- DL assignment received on SCelln corresponds to downlink transmission on SCelln;
- UL grant received on SCelln corresponds to uplink transmission on SCelln. If SCelln is not configured for uplink
usage by the UE, the grant is ignored by the UE.
When DC is configured, cross-carrier scheduling can only be used across serving cells within the same CG. Within a
CG, neither PCell of MCG nor PSCell of SCG can be cross-carrier scheduled.
When SPT is configured, cross-carrier scheduling can be used, but is limited to serving cells within the same PUCCH
group. In this case, both the scheduling cell and the scheduled cell shall be configured with SPT.
For BL UEs or UEs in enhanced coverage, when multi-TB scheduling is configured, a single MPDCCH can indicate
scheduling of multiple downlink transmissions, where each transmission corresponds to one HARQ process
11.1.1 Downlink Scheduling

In the downlink, E-UTRAN can dynamically allocate resources (PRBs and MCS) to UEs at each TTI via the C-RNTI
on PDCCH(s). A UE always monitors the PDCCH(s) in order to find possible allocation when its downlink reception is
enabled (activity governed by DRX when configured). When CA is configured, the same C-RNTI applies to all serving
cells.
In addition, E-UTRAN can allocate semi-persistent downlink resources for the first HARQ transmissions to UEs:
- RRC defines the periodicity of the semi-persistent downlink grant;
- PDCCH indicates whether the downlink grant is a semi-persistent one i.e. whether it can be implicitly reused in
the following TTIs according to the periodicity defined by RRC.
When required, retransmissions are explicitly signalled via the PDCCH(s). In the TTIs where the UE has semi-
persistent downlink resource, if the UE cannot find its C-RNTI on the PDCCH(s), a downlink transmission according to
the semi-persistent allocation that the UE has been assigned in the TTI is assumed. Otherwise, in the sub-TTIs where
the UE has semi-persistent downlink resource, if the UE finds its C-RNTI on the PDCCH(s), the PDCCH allocation
overrides the semi-persistent allocation for that TTI and the UE does not decode the semi-persistent resources.
Semi-persistent downlink resources can be configured per serving cell with the restriction that multiple DL SPS
configurations per serving cell are not supported. SPS configurations can be active simultaneously for different cells.
PDCCH allocations made on a given serving cell can only override the semi-persistent allocation for that serving cell.
For NB-IoT:
- Scheduling information for downlink data is transmitted on the downlink physical control channel NPDCCH.
The scheduled downlink data is transmitted on the shared data channel NPDSCH;
3GPP
Release 17 184 3GPP TS 36.300 V17.2.0 (2022-09)
- Only cross-subframe scheduling is supported, cross-carrier scheduling is not supported. The transmission
duration in number of sub-frames for the NPDCCH and the NPDSCH is variable;
- The transmission duration in number of sub-frames is semi-static for the NPDCCH and is indicated for the
NPDSCH as part of the scheduling information transmitted on the NPDCCH;
- The start time of the NPDSCH relative to the NPDCCH is signaled as part of the scheduling message;
- When multi-TB scheduling is configured, a single NPDCCH can indicate scheduling of multiple downlink
transmissions, where each transmission corresponds to one HARQ process.
11.1.2 Uplink Scheduling

In the uplink, E-UTRAN can dynamically allocate resources (PRBs and MCS) to UEs at each TTI via the C-RNTI on
PDCCH(s). A UE always monitors the PDCCH(s) in order to find possible allocation for uplink transmission when its
downlink reception is enabled (activity governed by DRX when configured). When CA is configured, the same C-RNTI
applies to all serving cells.
In addition, E-UTRAN can allocate a semi-persistent uplink resource or autonomous uplink resource for the first HARQ
transmissions and potentially retransmissions to UEs:
- RRC defines the periodicity of the semi-persistent uplink grant or the bitmap of the autonomous uplink grant;
- PDCCH indicates whether the uplink grant is a semi-persistent one or an autonomous uplink one i.e. whether it
can be implicitly reused in the following TTIs according to the periodicity or the bitmap defined by RRC.
In the TTIs where the UE has semi-persistent uplink resource or autonomous uplink resource, if the UE cannot find its
C-RNTI on the PDCCH(s), an uplink transmission according to the semi-persistent allocation or autonomous uplink
allocation that the UE has been assigned in the TTI can be made. The network performs decoding of the pre-defined
PRBs according to the pre-defined MCS. Otherwise, in theTTIs where the UE has semi-persistent uplink resource or
autonomous uplink resource, if the UE finds its C-RNTI on the PDCCH(s), the PDCCH allocation overrides the
persistent allocation or autonomous uplink allocation for that TTI and the UE's transmission follows the PDCCH
allocation, not the semi-persistent allocation or autonomous uplink. Retransmissions are either implicitly allocated in
which case the UE uses the semi-persistent uplink allocation or autonomous uplink allocation, or explicitly allocated via
PDCCH(s) in which case the UE does not follow the semi-persistent allocation or autonomous uplink allocation. The
UE is not allowed to use autonomous uplink resource for retransmission of dynamically scheduled transmission.
NOTE: there is no blind decoding in uplink and when the UE does not have enough data to fill the allocated
resource, padding is used.
When the UE is provided with valid uplink grants in several serving cells in one TTI, the order in which the grants are
processed during logical channel prioritisation and whether joint or serial processing is applied are left up to UE
implementation, while adhering to transmission restrictions of a logical channel via LAA SCells.
Similar to the downlink, semi-persistent uplink resources can be configured. Multiple UL SPS configurations are
supported per Serving Cell. On one Serving Cell, multiple such configurations can be active simultaneously only for the
same TTI length. SPS configurations can also be active simultaneously for different cells. PDCCH allocations made on
a given serving cell can only override the semi-persistent allocation for that serving cell.
When UL skipping is configured, the UE will not transmit a MAC PDU with only padding BSR and padding if no data
is available for transmission in the UE buffer. When UL Skippping and an SPS interval shorter than 10ms is configured,
a retransmission is prioritised over a new transmission on semi-persistent uplink resources if no dynamic grant is
allocated for that subframe.
For a UE capable of V2X communication, multiple semi-persistent configurations can be configured in uplink,
regardless of the specific services the UE is operating. The uplink resources for each semi-persistent configuration can
only be configured for the PCell. When DC is configured, the uplink resources for each semi-persistent configuration
can only be configured for the PCell or PSCell.
Autonomous uplink allocation can be configured for LAA SCell(s). The UE will not transmit on autonomous uplink
resources if no data is available for transmission.
For BL UEs or UEs in enhanced coverage, when multi-TB scheduling is configured, a single MPDCCH can indicate
scheduling of multiple uplink transmissions, where each transmission corresponds to one HARQ process.
3GPP
Release 17 185 3GPP TS 36.300 V17.2.0 (2022-09)
For BL UEs or UEs in enhanced coverage, E-UTRAN can allocate preconfigured uplink resources to be used in
RRC_IDLE for transmission using PUR, see clause 7.3d.
For NB-IoT:
- Scheduling information for uplink data is transmitted on the downlink physical control channel NPDCCH. The
scheduled uplink data is transmitted on the shared data channel NPUSCH;
- The transmission duration in number of sub-frames for the NPUSCH is variable;
- The transmission duration in number of sub-frames is semi-static for the NPDCCH and is indicated for the
NPUSCH as part of the scheduling information transmitted on the NPDCCH;
- The start time of the NPUSCH relative to the NPDCCH is signaled as part of the scheduling message;
- E-UTRAN can allocate semi-persistent uplink resource for sending a BSR acting as a Scheduling Request;
- When multi-TB scheduling is configured, a single NPDCCH can indicate scheduling of multiple uplink
transmissions, where each transmission corresponds to one HARQ process;
- E-UTRAN can allocate preconfigured uplink resources to be used in RRC_IDLE for transmission using PUR,
see clause 7.3d.
11.2 Activation/Deactivation Mechanism

To enable reasonable UE battery consumption when CA is configured, an activation/deactivation mechanism of SCells
is supported (i.e. activation/deactivation does not apply to PCell). When an SCell is deactivated, the UE does not need
to receive the corresponding PDCCH or PDSCH, cannot transmit in the corresponding uplink, nor is it required to
perform CQI measurements. Conversely, when an SCell is active, the UE shall receive PDSCH and PDCCH (if the UE
is configured to monitor PDCCH from this SCell), and is expected to be able to perform CQI measurements. To enable
faster CQI reporting, a temporary CQI reporting period (called short CQI period) can be supported during SCell
activation period. E-UTRAN ensures that while PUCCH SCell is deactivated, SCells of secondary PUCCH group
should not be activated or dormant. E-UTRAN ensures that SCells mapped to PUCCH SCell are deactivated before the
PUCCH SCell is changed or removed.
To enable faster transition to activated state, a dormant state for SCells (i.e. not PCell or PSCell) is supported. When an
SCell is in dormant state, the UE does not need to receive the corresponding PDCCH or PDSCH, cannot transmit in the
corresponding uplink, but is required to perform CQI measurements. A PUCCH SCell cannot be in dormant state.
The activation/deactivation mechanism is based on the combination of a MAC control element and deactivation timers.
The MAC control element carries a bitmap for the activation and deactivation of SCells: a bit set to 1 denotes activation
of the corresponding SCell, while a bit set to 0 denotes deactivation. With the bitmap, SCells can be activated and
deactivated individually, and a single activation/deactivation command can activate/deactivate a subset of the SCells.
One deactivation timer is maintained per SCell but one common value is configured per UE by RRC.
The state transitions to and from dormant Scell state use MAC control elements.
At reconfiguration without mobility control information:
- SCells added to the set of serving cells are initially "deactivated", "dormant" or "activated";
- SCells which remain in the set of serving cells (either unchanged or reconfigured) do not change their activation
status ("activated", "deactivated" or "dormant").
At reconfiguration with mobility control information (i.e. handover) or connection resume from RRC_INACTIVE:
- SCells are "deactivated", "dormant" or "activated".
In DC, the serving cells of the MCG other than the PCell can only be activated/deactivated by the MAC Control
Element received on MCG, and the serving cells of the SCG other than PSCell can only be activated/ deactivated by the
MAC Control Element received on SCG. The MAC entity applies the bitmap for the associated cells of either MCG or
SCG. PSCell in SCG is always activated like the PCell (i.e. deactivation timer is not applied to PSCell). With the
exception of PUCCH SCell, one deactivation timer is maintained per SCell but one common value is configured per CG
by RRC.
3GPP
Release 17 186 3GPP TS 36.300 V17.2.0 (2022-09)
11.3 Measurements to Support Scheduler Operation

Measurement reports are required to enable the scheduler to operate in both uplink and downlink. These include
transport volume and measurements of a UEs radio environment.
Uplink buffer status reports (BSR) are needed to provide support for QoS-aware packet scheduling. In E-UTRAN
uplink buffer status reports refer to the data that is buffered in for a group of logical channel (LCG) in the UE. Four
LCGs and two formats are used for reporting in uplink:
- A short format for which only one BSR (of one LCG) is reported;
- A long format for which all four BSRs (of all four LCGs) are reported.
Uplink buffer status reports are transmitted using MAC signalling.
In DC, LCG is configured per CG.
In DC, BSR configuration, triggering and reporting are independently performed per CG. For split bearers, the PDCP
data is considered in BSR in the CG(s) configured by RRC.For LWA bearers in the UL, the bearers configured to use
WLAN only do not trigger BSR. For bearers configured to use WLAN and LTE, only the data that may be sent over
LTE (i.e., excluding UL data already sent or decided to be sent over WLAN) is considered for BSR.
11.4 Rate Control of GBR, MBR and UE-AMBR

11.4.1 Downlink
The eNB guarantees the downlink GBR associated with a GBR bearer, enforces the downlink MBR associated with a
GBR bearer and enforces the downlink AMBR associated with a group of Non-GBR bearers.
11.4.2 Uplink
The UE has an uplink rate control function which manages the sharing of uplink resources between radio bearers. RRC
controls the uplink rate control function by giving each bearer a priority and a prioritised bit rate (PBR). The values
signalled may not be related to the ones signalled via S1 to the eNB.
The uplink rate control function ensures that the UE serves its radio bearer(s) in the following sequence:
1. All the radio bearer(s) in decreasing priority order up to their PBR;
2. All the radio bearer(s) in decreasing priority order for the remaining resources assigned by the grant.
NOTE1: In case the PBRs are all set to zero, the first step is skipped and the radio bearer(s) are served in strict
priority order: the UE maximises the transmission of higher priority data.
NOTE2: By limiting the total grant to the UE, the eNB can ensure that the UE-AMBR plus the sum of MBRs is
not exceeded.
NOTE3: Provided the higher layers are responsive to congestion indications, the eNB can enforce the MBR of an
uplink radio bearer by triggering congestion indications towards higher layers and by shaping the data
rate towards the S1 interface.
If more than one radio bearer has the same priority, the UE shall serve these radio bearers equally.
11.4.3 UE-AMBR for Dual Connectivity

In DC, the MeNB ensures that the UE-AMBR is not exceeded by:
1) limiting the resources it allocates to the UE in MCG; and
2) indicating to the SeNB a limit so that the SeNB can also in turn guarantee that this limit is not exceeded.
For split bearers the SeNB ignores the indicated downlink UE-AMBR. If the SeNB is not configured to serve the uplink
for split bearers, the SeNB ignores the indicated uplink UE-AMBR.
3GPP
Release 17 187 3GPP TS 36.300 V17.2.0 (2022-09)
11.5 CQI reporting for Scheduling

The time and frequency resources used by the UE to report CQI are under the control of the eNB. CQI reporting can be
either periodic or aperiodic. A UE can be configured to have both periodic and aperiodic reporting at the same time. In
case both periodic and aperiodic reporting occurs in the same subframe for a particular CG, only the aperiodic report is
transmitted in that subframe.
For efficient support of localized, distributed and MIMO transmissions, E-UTRA supports three types of CQI reporting:
- Wideband type: providing channel quality information of entire system bandwidth of the cell;
- Multi-band type: providing channel quality information of some subset(s) of system bandwidth of the cell;
- MIMO type: open loop or closed loop operation (with or without PMI feedback).
Periodic CQI reporting is defined by the following characteristics:
- When the UE is allocated PUSCH resources in a subframe where a periodic CQI report is configured to be sent,
the periodic CQI report is transmitted together with uplink data on the PUSCH. Otherwise, the periodic CQI
reports are sent on the PUCCH.
Aperiodic CQI reporting is defined by the following characteristics:
- The report is scheduled by the eNB via the PDCCH;
- Transmitted together with uplink data on PUSCH.
When a CQI report is transmitted together with uplink data on PUSCH, it is multiplexed with the transport block by L1
(i.e. the CQI report is not part of the uplink the transport block).
The eNB configures a set of sizes and formats of the reports. Size and format of the report depends on whether it is
transmitted over PUCCH or PUSCH and whether it is a periodic or aperiodic CQI report.
11.6 Explicit Congestion Notification

The eNB and the UE support of the Explicit Congestion Notification (ECN) is specified in clause 5 of IETF RFC 3168
[35] (i.e., the normative part of IETF RFC 3168 [35] that applies to the end-to-end flow of IP packets), and below. ECN
is beneficial especially for latency sensitive interactived applications such as chat and gaming as well as for real-time
voice and video, this because loss as a congestion signal is avoided, losses that would otherwise necessitate
retransmission of packets with additional application delay as a result.
The eNB should set the Congestion Experienced (CE) codepoint ('11') in PDCP SDUs in the downlink direction to
indicate downlink (radio) congestion if those PDCP SDUs have one of the two ECN-Capable Transport (ECT)
codepoints set. The eNB should set the Congestion Experienced (CE) codepoint ('11') in PDCP SDUs in the uplink
direction to indicate uplink (radio) congestion if those PDCP SDUs have one of the two ECN-Capable Transport (ECT)
codepoints set. ECN marking should be per the recommendations in IETF RFC 7567 [73].
11.7 DL channel quality reporting

The DL channel quality report is only applicable to BL UEs, UEs in enhanced coverage and NB-IoT UEs.
The DL channel quality report in RRC_IDLE is defined by the following characteristics:
- The reporting is configured by eNB via system information;
- For NB-IOT UEs:
- The report is related to the DL carrier used for the initial random access procedure;
- The report is carried in the RRC message during the random access procedure.
The DL channel quality report in RRC_CONNECTED is defined by the following characteristics:
- The reporting is triggered by the eNB via a MAC Control Element;
3GPP
Release 17 188 3GPP TS 36.300 V17.2.0 (2022-09)
- For NB-IOT UEs, the report is related to the configured DL carrier used in unicast transmission;
- The report is carried in a MAC Control Element.
12 DRX in RRC_CONNECTED
In order to enable reasonable UE battery consumption, DRX in E-UTRAN is characterised by the following:
- Per UE mechanism (as opposed to per radio bearer);
- No RRC or MAC substate to distinguish between different levels of DRX;
- Available DRX values are controlled by the network and start from non-DRX up to 10.24 seconds;
- Measurement requirement and reporting criteria can differ according to the length of the DRX interval i.e. long
DRX intervals may experience more relaxed requirements;
- Irrespective of DRX, UE may use first available RACH opportunity to send an UL measurement report;
- HARQ operation related to data transmission is independent of DRX operation and the UE wakes up to read the
PDCCH for possible retransmissions and/or ACK/NAK signalling regardless of DRX In the downlink, a timer is
used to limit the time the UE stays awake awaiting for a retransmission. In the uplink, for asynchronous HARQ,
a timer is used to limit the time the UE stays awake awaiting for a retransmission;
- When DRX is configured, the UE may be further configured with an "on-duration" timer during which time the
UE monitors the PDCCHs for possible allocations;
- When DRX is configured, periodic CQI reports can only be sent by the UE during the "active-time". RRC can
further restrict periodic CQI reports so that they are only sent during the on-duration;
- A timer per TAG in the UE is used to detect need for obtaining timing advance for each TAG.
The following definitions apply to DRX in E-UTRAN, except for NB-IoT:
- on-duration: duration in downlink subframes that the UE waits for, after waking up from DRX, to receive
PDCCHs. If the UE successfully decodes a PDCCH, the UE stays awake and starts the inactivity timer;
- inactivity-timer: duration in downlink subframes that the UE waits to successfully decode a PDCCH, from the
last successful decoding of a PDCCH, failing which it re-enters DRX. The UE shall restart the inactivity timer
following a single successful decoding of a PDCCH for a first transmission only (i.e. not for retransmissions).
- active-time: total duration that the UE is awake. This includes the "on-duration" of the DRX cycle, the time UE
is performing continuous reception while the inactivity timer has not expired and the time UE is performing
continuous reception while waiting for a DL retransmission after one HARQ RTT or, for asynchronous UL
HARQ operation, for an UL retransmission grant after one UL HARQ RTT. Based on the above the minimum
active time is of length equal to on-duration, and the maximum is undefined (infinite);
Of the above parameters the on-duration and inactivity-timer are of fixed lengths, while the active-time is of varying
lengths based on scheduling decision and UE decoding success. Only on-duration and inactivity-timer duration are
signalled to the UE by the eNB:
- There is only one DRX configuration applied in the UE at any time;
- UE shall apply an on-duration on wake-up from DRX sleep;
NOTE: this is also applicable for the case where the UE has only one service (e.g. Real Time) that is being
handled through the allocation of predefined resources; this allows for other signalling such as RRC to be
sent during the remaining portion of the active time.
- New transmissions can only take place during the active-time (so that when the UE is waiting for one
retransmission only, it does not have to be "awake" during the RTT).
- If PDCCH has not been successfully decoded during the on-duration, the UE shall follow the DRX configuration
(i.e. the UE can enter DRX sleep if allowed by the DRX configuration):
3GPP
Release 17 189 3GPP TS 36.300 V17.2.0 (2022-09)
- This applies also for the sub-frames where the UE has been allocated predefined resources.
- Except for NB-IoT, if it successfully decodes a PDCCH for a first transmission, the UE shall stay awake and
start the inactivity timer (even if a PDCCH is successfully decoded in the sub-frames where the UE has also been
allocated predefined resources) until a MAC control message tells the UE to re-enter DRX, or until the inactivity
timer expires. In both cases, the DRX cycle that the UE follows after re-entering DRX is given by the following
rules:
- If a short DRX cycle is configured; the UE first follows the short DRX cycle and after a longer period of
inactivity the UE follows the long DRX cycle;
- Else the UE follows the long DRX cycle directly.
NOTE: When DRX is configured, the network should detect whether UE remains in EUTRAN coverage by
requesting UE to send periodic signals to the network.
In CA, whenever a UE is configured with only one serving cell (i.e. PCell) Rel-8/9 DRX applies. In other cases, the
same DRX operation applies to all configured and activated serving cells (i.e. identical active time for PDCCH
monitoring).
In DC, separate DRX configurations can be applied to MCG and SCG, and the CG specific DRX operation applies to
all configured and activated serving cells in the same CG (i.e. identical active time for PDCCH monitoring).
13 QoS
13.0 General
An EPS bearer/E-RAB is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. That is, SDFs
mapped to the same EPS bearer receive the same bearer level packet forwarding treatment (e.g. scheduling policy,
queue management policy, rate shaping policy, RLC configuration, etc.), as specified in TS 23.401 [17].
One EPS bearer/E-RAB is established when the UE connects to a PDN, and that remains established throughout the
lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to
as the default bearer. Any additional EPS bearer/E-RAB that is established to the same PDN is referred to as a
dedicated bearer. The initial bearer level QoS parameter values of the default bearer are assigned by the network, based
on subscription data. The decision to establish or modify a dedicated bearer can only be taken by the EPC, and the
bearer level QoS parameter values are always assigned by the EPC.
An EPS bearer/E-RAB is referred to as a GBR bearer if dedicated network resources related to a Guaranteed Bit Rate
(GBR) value that is associated with the EPS bearer/E-RAB are permanently allocated (e.g. by an admission control
function in the eNodeB) at bearer establishment/modification. Otherwise, an EPS bearer/E-RAB is referred to as a Non-
GBR bearer. A dedicated bearer can either be a GBR or a Non-GBR bearer while a default bearer shall be a Non-GBR
bearer.
13.1 Bearer service architecture

The EPS bearer service layered architecture is depicted in Figure 13.1-1 below, where:
- An UL TFT in the UE binds an SDF to an EPS bearer in the uplink direction. Multiple SDFs can be multiplexed
onto the same EPS bearer by including multiple uplink packet filters in the UL TFT.
- A DL TFT in the PDN GW binds an SDF to an EPS bearer in the downlink direction. Multiple SDFs can be
multiplexed onto the same EPS bearer by including multiple downlink packet filters in the DL TFT.
- An E-RAB transports the packets of an EPS bearer between the UE and the EPC. When an E-RAB exists, there
is a one-to-one mapping between this E-RAB and an EPS bearer.
- A data radio bearer transports the packets of an EPS bearer between a UE and one or more eNB(s). When a data
radio bearer exists, there is a one-to-one mapping between this data radio bearer and the EPS bearer/E-RAB.
- An S1 bearer transports the packets of an E-RAB between an eNodeB and a Serving GW.
- An S5/S8 bearer transports the packets of an EPS bearer between a Serving GW and a PDN GW.
3GPP
Release 17 190 3GPP TS 36.300 V17.2.0 (2022-09)
- A UE stores a mapping between an uplink packet filter and a data radio bearer to create the binding between an
SDF and a data radio bearer in the uplink.
- A PDN GW stores a mapping between a downlink packet filter and an S5/S8a bearer to create the binding
between an SDF and an S5/S8a bearer in the downlink.
- An eNB stores a one-to-one mapping between a data radio bearer and an S1 bearer to create the binding between
a data radio bearer and an S1 bearer in both the uplink and downlink.
- A Serving GW stores a one-to-one mapping between an S1 bearer and an S5/S8a bearer to create the binding
between an S1 bearer and an S5/S8a bearer in both the uplink and downlink.
Figure 13.1-1: EPS Bearer Service Architecture
13.2 QoS parameters

The bearer level (i.e. per bearer or per bearer aggregate) QoS parameters are QCI, ARP, GBR, and AMBR, as specified
in TS 23.401 [17]. Each EPS bearer/E-RAB (GBR and Non-GBR) is associated with the following bearer level QoS
parameters:
- QoS Class Identifier (QCI): scalar that is used as a reference to access node-specific parameters that control
bearer level packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management
thresholds, link layer protocol configuration, etc.), and that have been pre-configured by the operator owning the
eNodeB. A one-to-one mapping of standardized QCI values to standardized characteristics is captured in TS
23.401 [17].
- Allocation and Retention Priority (ARP): the primary purpose of ARP is to decide whether a bearer
establishment / modification request can be accepted or needs to be rejected in case of resource limitations. In
addition, the ARP can be used by the eNodeB to decide which bearer(s) to drop during exceptional resource
limitations (e.g. at handover).
Each GBR bearer is additionally associated with the following bearer level QoS parameter:
- Guaranteed Bit Rate (GBR): the bit rate that can be expected to be provided by a GBR bearer;
- Maximum Bit Rate (MBR): the maximum bit rate that can be expected to be provided by a GBR bearer. MBR
can be greater or equal to the GBR.
Each APN access, by a UE, is associated with the following QoS parameter:
- per APN Aggregate Maximum Bit Rate (APN-AMBR).
Each UE in state EMM-REGISTERED is associated with the following bearer aggregate level QoS parameter:
3GPP
Release 17 191 3GPP TS 36.300 V17.2.0 (2022-09)
- per UE Aggregate Maximum Bit Rate (UE-AMBR).
The definitions of APN AMBR and UE-AMBR are captured in TS 23.401 [17].
The GBR and MBR denotes bit rate of traffic per bearer while UE-AMBR/APN-AMBR denote bit rate of traffic per
group of bearers. Each of those QoS parameters has an uplink and a downlink component.
13.3 QoS support in Hybrid Cells

The following principles apply to serving non CSG members and CSG members of a Hybrid Cell:
NOTE: The term "eNB" in this clause applies to HeNBs (as described in clause 4.6.1), as well as eNBs (as
denoted in the basic E-UTRAN architecture in Figure 4-1).
- When the UE connects to a Hybrid Cell, the MME shall inform the eNB serving this Hybrid Cell whether the UE
is a member or not of the CSG associated with this Hybrid Cell;
- Based on CSG membership, the offered QoS for UEs served by this Hybrid Cell may be modified as follows:
- The eNB serving this Hybrid Cell may distinguish between a CSG member and non-member when
determining whether to handover a UE, which GBR bearers to admit and which GBR bearers to deactivate;
- The eNB serving this Hybrid Cell may distinguish between a CSG member and non-member for handover
and packet scheduling on Uu interface (including reduced QoS) of non-GBR bearers.
14 Security
14.1 Overview and Principles
The following principles apply to E-UTRAN security:
- The keys used for NAS and AS protection shall be dependent on the algorithm with which they are used.
- The eNB keys are cryptographically separated from the EPC keys used for NAS protection (making it
impossible to use the eNB key to figure out an EPC key).
- For SCG bearers in DC, the SeNB keys are cryptographically separated from the eNB keys.
- The AS (RRC and UP) and NAS keys are derived in the EPC/UE from key material that was generated by a
NAS (EPC/UE) level AKA procedure (KASME) and identified with a key identifier (KSIASME).
- For SCG bearers in DC, the AS (UP) keys are derived in the SeNB/UE from key material that was generated in
the MeNB/UE.
- The eNB key (KeNB) is sent from the EPC to the eNB when the UE is entering ECM-CONNECTED state (i.e.
during RRC connection or S1 context setup).
- For SCG bearers in DC, the SeNB key (S-KeNB) is sent from the MeNB to the SeNB when adding an SCG.
- For LWA bearers, the WT Counter, if included in LWA Configuration, is used when computing the S-K WT (as
specified in TS 33.401 [22], clause G and TS 36.331 [16], clause 5.6.14.2). If WT Counter is not signalled to the
UE, the UE uses authentication methods specified in TS 33.402 [70], clause 6, as described in 22A.1.8.
- For LWIP, the LWIP Counter in the LWIP Configuration is used when computing the LWIP-PSK (as specified
in TS 33.401 [13], clause A.13, and TS 36.331 [16], subcause 5.6.17.2).
- Separate AS and NAS level security mode command procedures are used. AS level security mode command
procedure configures AS security (RRC and user plane) and NAS level security mode command procedure
configures NAS security. Both integrity protection and ciphering for RRC are activated within the same AS
SMC procedure. User plane ciphering is activated at the same time as RRC ciphering. An EN-DC capable UE
supporting user plane integrity protection (see TS 24.301 [20]) when connected to E-UTRA/EPC (as specified in
TS 33.401 [22]) shall support integrity protection for all DRBs (MN and SN terminated) at any data rate, up to
and including the highest data rate supported by the UE for both UL and DL. When supported, user plane
integrity protection with NR PDCP can be activated (on a per radio bearer basis) upon DRB addition.
3GPP
Release 17 192 3GPP TS 36.300 V17.2.0 (2022-09)
- Keys stored inside eNBs shall never leave a secure environment within the eNB (except when done in
accordance with this or other 3GPP specifications), and user plane data ciphering/deciphering shall take place
inside the secure environment where the related keys are stored.
- Key material for the eNB keys is sent between the eNBs during ECM-CONNECTED intra-E-UTRAN mobility
and from the MeNB to the SeNB in DC for SCG bearer during SCG addition and SCG change.
- A sequence number (COUNT) is used as input to the ciphering and integrity protection. A given sequence
number must only be used once for a given eNB key (except for identical re-transmission) on the same radio
bearer in the same direction. The same sequence number can be used for both ciphering and integrity protection.
- A hyper frame number (HFN) (i.e. an overflow counter mechanism) is used in the eNB and UE in order to limit
the actual number of sequence number bits that is needed to be sent over the radio. The HFN needs to be
synchronized between the UE and eNB.
- No integrity protection initialisation number (FRESH).
- Since SIM access is not granted in E-UTRAN TS 33.401 [22] except for making IMS Emergency calls, idle
mode UE not equipped with USIM shall not attempt to reselect to E-UTRAN unless it is originating an IMS
Emergency call. The RNC may try to prevent handover to E-UTRAN for example by identifying a SIM based
UE from the security keys provided by the CN.
A simplified key derivation is depicted on Figure 14.1-1 below, where:
- KNASint is a key, which shall only be used for the protection of NAS traffic with a particular integrity algorithm
This key is derived by UE and MME from KASME , as well as an identifier for the integrity algorithm.
- KNASenc is a key, which shall only be used for the protection of NAS traffic with a particular encryption
algorithm. This key is derived by UE and MME from KASME, as well as an identifier for the encryption algorithm.
- KeNB is a key derived by UE and MME from KASME. KeNB may also be derived by the target eNB from NH at
handover. KeNB shall be used for the derivation of KRRCint, KRRCenc and KUPenc, and for the derivation of KeNB* upon
handover.
- KeNB* is a key derived by UE and source eNB from either KeNB or from a fresh NH. KeNB* shall be used by UE and
target eNB as a new KeNB for RRC and UP traffic.
- KUPint is a key, which shall only be used for the protection of UP traffic with a particular integrity algorithm. This
key is derived by UE and eNB from KeNB, as well as an identifier for the integrity algorithm.
- KUPenc is a key, which shall only be used for the protection of UP traffic with a particular encryption algorithm.
This key is derived by UE and eNB from KeNB, as well as an identifier for the encryption algorithm.
- KRRCint is a key, which shall only be used for the protection of RRC traffic with a particular integrity algorithm.
KRRCint is derived by UE and eNB from KeNB, as well as an identifier for the integrity algorithm.
- KRRCenc is a key, which shall only be used for the protection of RRC traffic with a particular encryption
algorithm. KRRCenc is derived by UE and eNB from KeNB as well as an identifier for the encryption algorithm.
- Next Hop (NH) is used by UE and eNB in the derivation of KeNB* for the provision of "forward security", as
specified in TS 33.401 [22]. NH is derived by UE and MME from KASME and KeNB when the security context is
established, or from KASME and previous NH, otherwise.
- Next Hop Chaining Count (NCC) is a counter related to NH (i.e. the amount of Key chaining that has been
performed) which allow the UE to be synchronised with the eNB and to determine whether the next KeNB* needs
to be based on the current KeNB or a fresh NH.
3GPP
Release 17 193 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 14.1-1: Key Derivation
Key derivation for SCG bearers in DC is depicted on Figure 14.1-2 below, where:
- SCG Counter is a counter used as freshness input into S-KeNB derivations (see TS 33.401 [22], Annex E.2.4).
Figure 14.1-2: DC Key Derivation
The MME invokes the AKA procedures by requesting authentication vectors to the HE (Home environment) if no
unused EPS authentication vectors have been stored. The HE sends an authentication response back to the MME that
contains a fresh authentication vector, including a base-key named KASME. Thus, as a result of an AKA run, the EPC and
the UE share KASME. From KASME, the NAS keys, (and indirectly) KeNB keys and NH are derived. The KASME is never
transported to an entity outside of the EPC, but KeNB and NH are transported to the eNB from the EPC when the UE
transitions to ECM-CONNECTED. From the KeNB, the eNB and UE can derive the UP and RRC keys.
RRC and UP keys are refreshed at handover. KeNB* is derived by UE and source eNB from target PCI, target frequency
and KeNB (this is referred to as a horizontal key derivation and is indicated to UE with an NCC that does not increase) or
from target PCI, target frequency and NH (this is referred to as a vertical key derivation and is indicated to UE with an
NCC increase). KeNB* is then used as new KeNB for RRC and UP traffic at the target. When the UE goes into ECM-IDLE
all keys are deleted from the eNB except for the UE which was enabled to use User Plane CIoT EPS Optimisation.
For SCG Bearers in DC, UP keys are updated at SCG change by indicating in RRC signalling to the UE the value of the
SCG Counter to be used in key derivation. When KeNB is refreshed, SCG Counter shall be reset and S-KeNB shall be
newly derived from the KeNB.
3GPP
Release 17 194 3GPP TS 36.300 V17.2.0 (2022-09)
COUNT reusing avoidance for the same radio bearer identity in RRC_CONNECTED mode without K eNB change is left
to eNB implementation e.g. by using intra-cell handover, smart management of radio bearer identities or triggering a
transition to RRC_IDLE.
SCG bearers in DC share a common pool of radio bearer identities (DRB IDs) together with the MCG bearers and when
no new DRB ID can be allocated for an SCG bearer without guaranteeing COUNT reuse avoidance, the MeNB shall
derive a new S-KeNB. SeNB indicates to MeNB when uplink or downlink PDCP COUNTs are about to wrap around and
MeNB shall update the S-KeNB. To update the S-KeNB, the MeNB increases the SCG Counter and uses it to derive a new
S-KeNB from the currently active KeNB in the MeNB. The MeNB sends the newly derived S-KeNB to the SeNB. The
newly derived S-KeNB is then used by the SeNB in computing a new encryption key KUPenc which is used with all DRBs
in the SeNB for this UE. Furthermore, when the SCG Counter approaches its maximum value, the MeNB refreshes the
currently active KeNB, before any further S-KeNB is derived.
In case of HFN de-synchronisation in RRC_CONNECTED mode between the UE and eNB, the UE is pushed to IDLE.
When AS security context is to be established in the eNB, the MME sends the complete UE security capabilities to the
eNB (i.e. all bits for every EPS or NR security capability defined in TS 24.301 [20] and received in NAS signaling). At
handover (or during Dual Connectivity or at UE Context retrieval), the complete UE security capabilities are also sent
by the source eNB to the target eNB (or by the old eNB to the new eNB or by the MeNB to the SeNB respectively).
14.2 Security termination points

The table below describes the security termination points.
Table 14.2-1 Security Termination Points
Ciphering Integrity Protection

NAS Signalling Required and terminated in MME Required and terminated in MME
U-Plane Data Required and terminated in eNB Terminated in eNB
(NOTE 1)
RRC Signalling (AS) Required and terminated in eNB Required and terminated in eNB
MAC Signalling (AS) Not required Not required

NOTE 1: User Plane Integrity Protection may be supported by UEs capable of EN-DC operation. This version of
the specifications does not provide UPIP support for other UEs when using E-UTRA.
The table below describes the security termination points for DC with SCG bearers and split bearers.
Table 14.2-2 Security Termination Points in DC
Ciphering Integrity Protection

NAS Signalling Required and terminated in MME Required and terminated in MME
U-Plane Data for MCG Required and terminated in MeNB Not Required
bearers
U-Plane Data for SCG Required and terminated in SeNB Not Required
bearers
U-Plane Data for split Required and terminated in MeNB Not Required
bearers
RRC Signalling (AS) Required and terminated in MeNB Required and terminated in MeNB
3GPP
Release 17 195 3GPP TS 36.300 V17.2.0 (2022-09)
14.3 State Transitions and Mobility

14.3.1 RRC_IDLE to RRC_CONNECTED
As a general principle, on RRC_IDLE to RRC_CONNECTED transitions, RRC protection keys and UP protection keys
shall be generated while keys for NAS protection as well as higher layer keys are assumed to be already available in the
MME. These higher layer keys may have been established in the MME as a result of an AKA run, or as a result of a
transfer from another MME during handover or idle mode mobility, as specified in TS 33.401 [22].
14.3.2 RRC_CONNECTED to RRC_IDLE

Except for the UE which was enabled to use User Plane CIoT EPS Optimisation, on RRC_CONNECTED to
RRC_IDLE transitions, eNBs shall delete the keys they store such that state for idle mode UEs only has to be
maintained in MME. It is also assumed that eNB does no longer store state information about the corresponding UE and
deletes the current keys from its memory. In particular, on connected to idle transitions:
- The eNB and UE deletes NH, KeNB , KRRCenc , KRRCint and KUPenc and related NCC.
- MME and UE keeps KASME, KNASint and KNASenc stored.
On RRC_CONNECTED to RRC_IDLE transitions for the UE which was enabled to use User Plane CIoT EPS
Optimisation, the eNBs, the UE and MME shall maintain the keys they store.
14.3.3 Intra E-UTRAN Mobility

The key hierarchy does not allow, as is, explicit RRC and UP key updates, but RRC and UP keys are derived based on
the algorithm identifiers and KeNB which results with new RRC and UP keys at every handover:
- Source eNB and UE independently create KeNB* with the input parameters as described in TS 33.401 [22];
- KeNB* is given to Target eNB during the HO preparation phase;
- Both Target eNB and UE considers the new KeNB equal to the received KeNB*.
The handling of HFN and PDCP SN at handover depends on the type of radio bearer:
- SRB: HFN and PDCP SN are reset.
- RLC-UM bearers: HFN and PDCP SN are reset.
- RLC-AM bearers: PDCP SN and HFN are maintained (10.1.2.3).
NOTE: COUNT reusing avoidance is left to network implementation.
For LWA, eNB may not trigger the S-KWT update during handover without WT change. In such a case, the eNB sends
the WT counter to the UE after handover via a separate RRC reconfiguration procedure. The UE does not need to
perform reauthentication with WLAN immediately even though the KeNB is updated but shall use the updated WT
counter the next time the UE does re-association with WLAN. As the PDCP PDUs may continue to be transmitted over
WLAN during handover without WT change, the transmitter uses an end-marker PDCP control PDU to inform the
receiver of the last PDCP PDU encrypted with source KeNB, as described in 10.1.2.9.
14.3.4 SeNB Removal

For SCG bearers in DC, at SeNB removal, the SeNB shall delete the keys it stores. It is also assumed that SeNB does no
longer store state information about the corresponding UE and deletes the current keys from its memory. In particular,
at SeNB removal:
- The SeNB and UE delete S-KeNB and KUPenc.
- The MeNB and UE keep KeNB.
3GPP
Release 17 196 3GPP TS 36.300 V17.2.0 (2022-09)
14.4 AS Key Change in RRC_CONNECTED

If AS Keys (KUPenc, KRRCint, KRRCenc, KUPint) need to be changed in RRC_CONNECTED, an intra-cell handover shall be
used.
For SCG bearers in DC, if AS Key (KUPenc) needs to be changed, the SCG change shall be performed.
14.5 Security Interworking

Inter-RAT handover from UTRAN to E-UTRAN is only supported after activation of integrity protection in UTRAN.
Security may be activated in the target RAN using null ciphering algorithms. If ciphering was not running in UTRAN, it
will be activated at handover to E-UTRAN. Integrity protection shall be activated in E-UTRAN on handover from
UTRAN/GERAN.
For E-UTRAN to UTRAN/GERAN mobility, the MME shall derive and transfer to the SGSN a confidentially key and
an integrity key derived from KASME and other input parameters as specified in TS 33.401 [22]. Based on this
information, the SGSN can in turn derive appropriate keys to be used in the target RAN.
Similarly for UTRAN/GERAN to E-UTRAN mobility, the SGSN shall derive and transfer to the MME a confidentially
key and an integrity key CK and IK. Based on this information and other input parameters as specified in TS 33.401
[22], the MME and UE can in turn derive KASME.
14.6 RN integrity protection for DRB(s)

Between the DeNB and the RN, integrity protection is required for the DRB(s) carrying S1AP and/or X2AP signalling
and optional for other DRB(s).
KUPint, used for the integrity protection of the DRBs, is derived by the RN and the DeNB from KeNB, as well as an
identifier for the integrity algorithm used as specified in TS 33.401 [22]. KUPint is generated, changed or deleted when
other AS keys are generated, changed or deleted.
15 MBMS
15.0 MBMS-Specific Definitions
For MBMS, the following definitions are introduced:
MBSFN Synchronization Area: an area of the network where all eNodeBs can be synchronized and perform MBSFN
transmissions. MBSFN Synchronization Areas are capable of supporting one or more MBSFN Areas. On a given
frequency layer, a eNodeB can only belong to one MBSFN Synchronization Area. MBSFN Synchronization Areas are
independent from the definition of MBMS Service Areas
MBSFN Transmission or a transmission in MBSFN mode: a simulcast transmission technique realised by

transmission of identical waveforms at the same time from multiple cells. An MBSFN Transmission from multiple cells
within the MBSFN Area is seen as a single transmission by a UE.
MBSFN Area: an MBSFN Area consists of a group of cells within an MBSFN Synchronization Area of a network,
which are co-ordinated to achieve an MBSFN Transmission. Except for the MBSFN Area Reserved Cells, all cells
within an MBSFN Area contribute to the MBSFN Transmission and advertise its availability. The UE may only need to
consider a subset of the MBSFN areas that are configured, i.e. when it knows which MBSFN area applies for the
service(s) it is interested to receive.
3GPP
Release 17 197 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 15-1: MBMS Definitions
MBSFN Area Reserved Cell: A cell within a MBSFN Area which does not contribute to the MBSFN Transmission.
The cell may be allowed to transmit for other services but at restricted power on the resource allocated for the MBSFN
transmission.
Synchronisation Sequence: Each SYNC PDU contains a time stamp which indicates the start time of the
synchronisation sequence. For an MBMS service, each synchronisation sequence has the same duration which is
configured in the BM-SC and the MCE.
Synchronisation Period: The synchronisation period provides the time reference for the indication of the start time of
each synchronisation sequence. The time stamp which is provided in each SYNC PDU is a relative value which refers
to the start time of the synchronisation period. The duration of the synchronisation period is configurable.
15.1 General
15.1.0 Overview
In E-UTRAN, MBMS can be provided with single frequency network mode of operation (MBSFN) either on a
frequency layer shared with non-MBMS services (set of cells supporting both unicast and MBMS transmissions i.e. set
of "MBMS/Unicast-mixed cells") or on a frequency layer dedicated for MBMS (set of cells supporting MBMS
transmission only i.e. set of "MBMS-dedicated cells").
MBMS reception is possible for UEs in RRC_IDLE state, or except for NB- IoT UEs, BL UEs or UEs in enhanced
coverage, in RRC_CONNECTED state. Whenever receiving MBMS services, a user shall be notified of an incoming
call, and originating calls shall be possible.
ROHC for MBMS is supported by upper layers (outside of Access Stratum) and only for Mission Critical services, as
described in TS 23.280 [77].
RNs do not support MBMS.
HeNBs do not support MBMS.
For NB-IoT UEs, BL UEs or UEs in enhanced coverage:
- MBMS is provided in "MBMS/Unicast-mixed cells" with single-cell transmission.
- MBMS reception is possible only for UEs in RRC_IDLE state.
- Whenever receiving MBMS services, a user shall be notified of an incoming call, and originating calls shall be
possible:
- Mobile Terminated call has higher priority than MBMS reception;
- Mobile Originated signalling has higher priority than MBMS reception;
- Other cases are left to UE implementation.
3GPP
Release 17 198 3GPP TS 36.300 V17.2.0 (2022-09)
15.1.1 E-MBMS Logical Architecture
Figure 15.1.1-1: E-MBMS Logical Architecture
Figure 15.1.1-1 depicts the E-MBMS Logical Architecture.
Multi-cell/multicast Coordination Entity (MCE)
The MCE is a logical entity – this does not preclude the possibility that it may be part of another network element –
whose functions are:
- the admission control and the allocation of the radio resources used by all eNBs in the MBSFN area for multi-
cell MBMS transmissions using MBSFN operation. The MCE decides not to establish the radio bearer(s) of the
new MBMS service(s) if the radio resources are not sufficient for the corresponding MBMS service(s) or may
pre-empt radio resources from other radio bearer(s) of ongoing MBMS service(s) according to ARP. Besides
allocation of the time/ frequency radio resources this also includes deciding the further details of the radio
configuration e.g. the modulation and coding scheme.
- deciding on whether to use SC-PTM or MBSFN.
- counting and acquisition of counting results for MBMS service(s).
- resumption of MBMS session(s) within MBSFN area(s) based on e.g. the ARP and/or the counting results for the
corresponding MBMS service(s).
- suspension of MBMS session(s) within MBSFN area(s) based e.g. the ARP and/or on the counting results for the
corresponding MBMS service(s).
NOTE: In case of distributed MCE architecture, the MCE manages the above functions for a single eNB of a
MBSFN. The coordination of the functions between MCEs is provided by OAM, if needed.
The MCE is involved in MBMS Session Control Signalling. The MCE does not perform UE - MCE signalling.
An eNB is served by a single MCE.
E-MBMS Gateway (MBMS GW)
The MBMS GW is a logical entity – this does not preclude the possibility that it may be part of another network
element – that is present between the BMSC and eNBs whose principal functions is the sending/broadcasting of MBMS
packets to each eNB transmitting the service. The MBMS GW uses IP Multicast as the means of forwarding MBMS
user data to the eNB. The MBMS GW performs MBMS Session Control Signalling (Session start/update/stop) towards
the E-UTRAN via MME.
Control Plane Interfaces
"M3" Interface: MCE – MME
3GPP
Release 17 199 3GPP TS 36.300 V17.2.0 (2022-09)
An Application Part is defined for this interface between MME and MCE. This application part allows for MBMS
Session Control Signalling on E-RAB level (i.e. does not convey radio configuration data). The procedures comprise
e.g. MBMS Session Start and Stop. SCTP is used as signalling transport i.e. Point-to-Point signalling is applied.
"M2" Interface: MCE – eNB
An Application Part is defined for this interface, which conveys at least radio configuration data for the multi-cell
transmission mode eNBs and Session Control Signalling. SCTP is used as signalling transport i.e. Point-to-Point
signalling is applied.
User Plane Interface
"M1" Interface: MBMS GW – eNB
This interface is a pure user plane interface. Consequently no Control Plane Application Part is defined for this
interface. IP Multicast is used for point-to-multipoint delivery of user packets.
Deployment consideration
The two envisaged alternatives are shown in Figure 15.1.1-2.
The architecture on the right part is defined as the "distributed MCE architecture". In this architecture, a MCE is part of
the eNB and the M2 interface should be kept between the MCE and the corresponding eNB.
The architecture on the left part is defined as the "centralized MCE architecture". In this architecture, the MCE is a
logical entity which means it can be deployed as a stand-alone physical entity or collocated in another physical entity
e.g. eNB. In both cases of the centralized MCE architecture, the M2 interface is kept between the MCE and all eNB(s)
belonging to the corresponding MBSFN area.
Figure 15.1.1-2: eMBMS Architecture deployment alternatives
MBMS for V2X
When MBMS is used to deliver downlink V2X messages, the localized MBMS specified in TS 23.285 [72] may be
used to improve latency if desired.
Single TMGI in non-overlapped MBMS service areas or multiple TMGIs in overlapped MBMS service areas may be
used to support small MBMS areas for V2X.
3GPP
Release 17 200 3GPP TS 36.300 V17.2.0 (2022-09)
15.1.2 E-MBMS User Plane Protocol Architecture

The overall U-plane architecture of content synchronization is shown in Figure 15.1.2-1. This architecture is based on
the functional allocation for Unicast and the SYNC protocol layer is defined additionally on transport network layer to
support content synchronization mechanism.
Figure 15.1.2-1: The overall u-plane architecture of the MBMS content synchronization
The SYNC protocol is defined as a protocol to carry additional information that enable eNBs to identify the timing for
radio frame transmission and detect packet loss. Every E-MBMS service uses its own SYNC entity. The SYNC
protocol is applicable to DL and is terminated in the BM-SC.
15.1.3 E-MBMS Control Plane Protocol Architecture

The E-MBMS C-plane protocol architecture is shown in Figure 15.1.3-1.
Figure 15.1.3-1: The E-MBMS c-plane architecture
MCCH is terminated in the eNB on the network side. How to achieve the synchronisation of MCCH signalling is
described in clause 15.3.8.
3GPP
Release 17 201 3GPP TS 36.300 V17.2.0 (2022-09)
15.2 MBMS Cells

15.2.1 MBMS-dedicated cell
Cells performing only MBMS transmissions are referred to as MBMS-dedicated cells. UEs not supporting FeMBMS
are not supported on these cells. Paging is not supported on an MBMS-dedicated cell.
For MBMS-dedicated cells:
- MTCH and MCCH are mapped on MCH for MBSFN transmission;
MBMS-dedicated cells do not support unicast traffic in the downlink and these cells cannot be used as PCell or PSCell.
System information required to receive MBMS from MBMS-dedicated cells is broadcasted on non-MBSFN subframes.
The system information change notification as well as ETWS/CMAS notification are provided via L1 signalling on
non-MBSFN subframes. The PBCH of MBMS-dedicated cell, uses a different scrambling sequence initialization than
the PBCH of MBMS/Unicast-mixed cell which prevents UEs not supporting FeMBMS from camping on this cell.
15.2.2 MBMS/Unicast-mixed cell

Cells performing both MBMS and unicast transmissions are referred to as MBMS/Unicast-mixed cells.
For MBMS/Unicast mixed cells:
- MTCH and MCCH are mapped on MCH for MBSFN transmission;
- SC-MTCH and SC-MCCH are mapped on DL-SCH for SC-PTM transmission;
- Transmission of both unicast and MBMS in the cell is done in a co-ordinated manner.
15.2.2.1 FeMBMS/Unicast-mixed cell

An FeMBMS/Unicast-mixed cell is an MBMS/Unicast-mixed cell that operates with at least one of the following:
- subframes 4 or 9 or both configured as MBSFN subframes
- subframes that may not contain unicast control region
The FeMBMS/Unicast-mixed cell cannot be used as a PCell or PSCell. To provide unicast traffic on non-MBSFN
subframes, such cell needs to be configured as an SCell. UEs not supporting FeMBMS are not supported on these cells
and camping of such UEs is prevented by using cell barring mechanism of SIB1. Paging for incoming calls is not
supported on such cells and system information change notification as well as ETWS/CMAS notification are provided
with L1 signalling.
15.3 MBMS Transmission

15.3.1 General
Transmission of a MBMS in E-UTRAN uses either MBSFN transmission or SC-PTM transmission. The MCE makes
the decision on whether to use SC-PTM or MBSFN for each MBMS session.
15.3.2 Single-cell transmission

Single-cell transmission of MBMS is characterized by:
- MBMS is transmitted in the coverage of a single cell;
- One SC-MCCH and one or more SC-MTCH(s) are mapped on DL-SCH;
- Scheduling is done by the eNB;
- SC-MCCH and SC-MTCH transmissions are each indicated by a logical channel specific RNTI on PDCCH
(there is a one-to-one mapping between TMGI and G-RNTI used for the reception of the DL-SCH to which a
SC-MTCH is mapped);
3GPP
Release 17 202 3GPP TS 36.300 V17.2.0 (2022-09)
- A single transmission is used for DL-SCH (i.e. neither blind HARQ repetitions nor RLC quick repeat) on which
SC-MCCH or SC-MTCH is mapped;
- SC-MCCH and SC-MTCH use the RLC-UM mode.
For each SC-MTCH, the following scheduling information is provided on SC-MCCH:
- SC-MTCH scheduling cycle;
- SC-MTCH on-duration: duration in downlink subframes that the UE waits for, after waking up from DRX, to
receive PDCCHs. If the UE successfully decodes a PDCCH indicating the DL-SCH to which this SC-MTCH is
mapped, the UE stays awake and starts the inactivity timer;
- SC-MTCH inactivity-timer: duration in downlink subframes that the UE waits to successfully decode a
PDCCH, from the last successful decoding of a PDCCH indicating the DL-SCH to which this SC-MTCH is
mapped, failing which it re-enters DRX. The UE shall restart the inactivity timer following a single successful
decoding of a PDCCH.
NOTE 1: The SC-PTM reception opportunities are independent of the unicast DRX scheme.
NOTE 2: The SC-MTCH inactivity-timer may be set to 0.
NOTE 3: Although the above parameters are per SC-MTCH (i.e. per MBMS service), the network may configure
the same scheduling pattern for multiple SC-MTCHs (i.e. multiple MBMS services).
NOTE 4: For NB-IoT UEs, the definition of the above parameters does not apply.
NOTE 5: For BL UEs and UEs in enhanced coverage, the definition of the above parameters does not apply.
For BL UEs, UEs in enhanced coverage and NB-IoT UEs, when multi-TB scheduling is configured, a single
MPDCCH/NPDCCH can indicate scheduling of multiple downlink transmissions.
15.3.3 Multi-cell transmission

Multi-cell transmission of MBMS is characterized by:
- Synchronous transmission of MBMS within its MBSFN Area;
- Combining of MBMS transmission from multiple cells is supported;
- Scheduling of each MCH is done by the MCE;
- A single transmission is used for MCH (i.e. neither blind HARQ repetitions nor RLC quick repeat);
- A single Transport Block is used per TTI for MCH transmission, that TB uses all the MBSFN resources in that
subframe;
- MTCH and MCCH can be multiplexed on the same MCH and are mapped on MCH for p-t-m transmission;
- MTCH and MCCH use the RLC-UM mode;
- The MAC subheader indicates the LCID for MTCH and MCCH;
- The MBSFN Synchronization Area, the MBSFN Area, and the MBSFN cells are semi-statically configured e.g.
by O&M;
- MBSFN areas are static, unless changed by O&M (i.e. no dynamic change of areas);
NOTE: The UE is not required to receive services from more than one MBSFN Area simultaneously and may
support only a limited number of MTCHs.
Multiple MBMS services can be mapped to the same MCH and one MCH contains data belonging to only one MBSFN
Area. An MBSFN Area contains one or more MCHs. An MCH specific MCS is used for all subframes of the MCH that
do not use the MCS indicated in BCCH. All MCHs have the same coverage area.
For MCCH and MTCH, the UE shall not perform RLC re-establishment at cell change between cells of the same
MBSFN area. Within the MBSFN subframes, all MCHs within the same MBSFN area occupy a pattern of subframes,
3GPP
Release 17 203 3GPP TS 36.300 V17.2.0 (2022-09)
not necessarily adjacent in time, that is common for all these MCHs and is therefore called the Common Subframe
Allocation (CSA) Pattern. The CSA pattern is periodically repeated with the CSA period. The actual MCH subframe
allocation (MSA) for every MCH carrying MTCH is defined by the CSA pattern, the CSA period, and the MSA end,
that are all signalled on MCCH. The MSA end indicates the last subframe of the MCH within the CSA period.
Consequently, the MCHs are time multiplexed within the CSA period, which finally defines the interleaving degree
between the MCHs. It shall be possible for MCHs to not use all MBSFN resources signalled as part of the Rel-8
MBSFN signalling. Further, such MBSFN resource can be shared for more than one purpose (MBMS, Positioning,
etc.). During one MCH scheduling period (MSP), which is configurable per MCH, the eNB applies MAC multiplexing
of different MTCHs and optionally MCCH to be transmitted on this MCH.
MCH scheduling information (MSI) is provided per MCH to indicate which subframes are used by each MTCH during
the MSP, and to indicate whether transmission for an MTCH is going to be, or has been, suspended by the eNode B.
The following principles are used for the MSI:
- it is used both when services are multiplexed onto the MCH and when only a single service is transmitted on the
MCH;
- it is generated by the eNB and provided once at the beginning of the MSP;
- it has higher scheduling priority than the MCCH and, when needed, it appears first in the PDU;
- it allows the receiver to determine what subframes are used by every MTCH, sessions are scheduled in the order
in which they are included in the MCCH session list;
- it is carried in a MAC control element which cannot be segmented;
- it carries the mapping of MTCHs to the subframes of the associated MSP. This mapping is based on the indexing
of subframes belonging to one MSP;
- it carries an indication of whether the transmission of an MTCH is to be suspended by the eNode B.
The content synchronization for multi-cell transmission is provided by the following principles:
1. All eNBs in a given MBSFN Synchronization Area have a synchronized radio frame timing such that the radio
frames are transmitted at the same time and have the same SFN.
2. All eNBs have the same configuration of RLC/MAC/PHY for each MBMS service, and identical information
(e.g. time information, transmission order/priority information) such that synchronized MCH scheduling in the
eNBs is ensured. These are indicated in advance by the MCE.
3. An E-MBMS GW sends/broadcasts MBMS packet with the SYNC protocol to each eNB transmitting the
service.
4. The SYNC protocol provides additional information so that the eNBs identify the transmission radio frame(s).
The E-MBMS GW does not need accurate knowledge of radio resource allocation in terms of exact time division
(e.g. exact start time of the radio frame transmission).
5. eNB buffers MBMS packet and waits for the transmission timing indicated in the SYNC protocol.
6. The segmentation/concatenation is needed for MBMS packets and should be totally up to the RLC/MAC layer in
eNB.
7. The SYNC protocol provides means to detect packet loss(es) and supports a recovery mechanism robust against
loss of consecutive PDU packets (MBMS Packets with SYNC Header).
8. For the packet loss case the transmission of radio blocks potentially impacted by the lost packet should be muted.
9. The mechanism supports indication or detection of MBMS data burst termination (e.g. to identify and alternately
use available spare resources related to pauses in the MBMS PDU data flow).
10. If two or more consecutive SYNC SDUs within a SYNC bearer are not received by the eNB, or if no SYNC
PDUs of Type 0 or 3 are received for some synchronization sequence, the eNB may mute the exact subframes
impacted by lost SYNC PDUs using information provided by SYNC protocol. If not muting only those exact
subframes, the eNB stops transmitting the associated MCH from the subframe corresponding to the consecutive
losses until the end of the corresponding MSP and it does not transmit in the subframe corresponding to the MSI
of that MSP.
3GPP
Release 17 204 3GPP TS 36.300 V17.2.0 (2022-09)
11. The eNB sets VT(US) to zero in the RLC UM entity corresponding to an MCCH at its modification period
boundary.
12. The eNB sets VT(US) to zero in each RLC UM entity corresponding to an MTCH at the beginning of its MSP.
13. The eNB sets every bit in the MAC padding on MCH to "0".
14. The eNB's RLC concatenates as many RLC SDUs from the same radio bearer as possible.
15. The eNB's MAC multiplexes as many RLC PDUs as fit in the Transport Block.
16. The eNB sets every padding bit in the RLC UM PDU corresponding to an MTCH or MCCH to "0".
17. A MAC PDU including a MAC subheader for a MTCH MAC SDU always includes non-zero size of MTCH
MAC SDU.
18. A MAC PDU including a MAC subheader for a MSI MAC control element always includes non-zero size of
MSI MAC control element.
15.3.4 MBMS Reception States

UEs that are receiving MTCH and/or SC-MTCH transmissions can be in RRC_IDLE or except for NB-IoT UEs, BL
UEs or UEs in enhanced coverage, in RRC_CONNECTED state.
UEs except for NB-IoT UEs, BL UEs or UEs in enhanced coverage that are receiving MTCH can also be in Receive
Only Mode as defined in TS 23.246 [48].
15.3.5 MCCH Structure

The following principles govern the MCCH structure:
- One MBSFN Area is associated with one MCCH and one MCCH corresponds to one MBSFN Area;
- The MCCH is sent on MCH;
- MCCH consists of a single MBSFN Area configuration RRC message which lists all the MBMS services with
ongoing sessions and an optional MBMS counting request message which, when present, comes after the former
message in the repetition period;
- MCCH is transmitted by all cells within an MBSFN Area, except the MBSFN Area Reserved Cells;
- MCCH is transmitted by RRC every MCCH repetition period;
- MCCH uses a modification period;
- A notification mechanism is used to announce changes of MCCH due to either Session Start or the presence of
an MBMS counting request message;
- The notification is sent periodically throughout the modification period preceding the change of MCCH, in
MBSFN subframes configured for notification;
- The DCI format 1C with M-RNTI is used for notification and includes an 8-bit bitmap to indicate the one or
more MBSFN Area(s) in which the MCCH change(s);
- The UE monitors more than one notification subframe per modification period;
- When the UE receives a notification, it acquires the MCCH at the next modification period boundary;
- The UE detects changes to MCCH which are not announced by the notification mechanism by MCCH
monitoring at the modification period.
15.3.5a SC-MCCH structure

The following principles govern the SC-MCCH structure:
- there is one SC-MCCH per cell;
3GPP
Release 17 205 3GPP TS 36.300 V17.2.0 (2022-09)
- the SC-MCCH is sent on DL-SCH;
- the SC-MCCH provides the list of all MBMS services with ongoing sessions transmitted on SC-MTCH(s),
including for each MBMS service TMGI and optional session ID, associated G-RNTI and scheduling
information;
- SC-MCCH is transmitted by RRC every SC-MCCH repetition period;
- SC-MCCH uses a modification period;
- Except for NB-IoT UEs, BL UEs or UEs in enhanced coverage a notification mechanism is used to announce
changes of SC-MCCH due to Session Start:
- The notification is sent in the first subframe in a repetition period where the SC-MCCH can be scheduled.
The notification is sent using the DCI format 1C with SC-N-RNTI and one bit within the 8-bit bitmap;
- When the UE receives a notification, it acquires the SC-MCCH in the same subframe;
- For NB-IoT UEs, BL UEs or UEs in enhanced coverage:
- Two notification mechanisms are used to announce changes of SC-MCCH due to Session Start:
- A notification is sent in the DCI with SC-RNTI scheduling SC-MCCH. When the UE receives the
notification, it acquires the SC-MCCH in the same modification period;
- A notification is sent in the DCI with G-RNTI scheduling SC-MTCH. When the UE receives the
notification, it acquires the SC-MCCH in the next modification period;
- One notification mechanism is used to announce changes of SC-MCCH for the ongoing service:
- The notification is sent in the DCI with G-RNTI scheduling SC-MTCH. When the UE receives the
notification, it acquires the SC-MCCH in the next modification period.
- The UE detects changes to SC-MCCH which are not announced by the notification mechanism by SC-MCCH
monitoring at the modification period.
15.3.6 MBMS signalling on BCCH

- BCCH only points to the resources where the MCCH(s)/SC-MCCH can be found i.e. it does not indicate the
availability of the services;
- For each MCCH, BCCH indicates independently:
- the scheduling of the MCCH for multi-cell transmission on MCH;
- the MCCH modification period, repetition period radio frame offset and subframe allocation;
- an MCS which applies to the subframes indicated for MCCH scheduling and for the first subframe of all
MSPs in that MBSFN Area.
- For the notification commonly used for all MCCH, BCCH:
- configures the position of the MCCH change notification subframe and the number of occasions monitored
by the UE;
- indicates the mapping between the PDCCH bit(s) carried in the notification and the MCCH(s).
- BCCH indicates the SC-MCCH modification period, SC-MCCH repetition period and SC-MCCH subframe
offset.
15.3.7 MBMS User Data flow synchronisation

The synchronised radio interface transmission from the cells controlled by different eNBs requires a SYNC-protocol
support between the BM-SC and the eNBs.
3GPP
Release 17 206 3GPP TS 36.300 V17.2.0 (2022-09)
As part of the SYNC-protocol procedures the BM-SC shall include within the SYNC PDU packets a time stamp which
tells the timing based on which the eNB sends MBMS data over the air interface. This time stamp is based on a
common time reference, and common start of the first synchronisation period available at the BM-SC and the concerned
eNBs and represents a relative time value which refers to the start time of the synchronisation period.
The BM-SC shall set the timestamp of all SYNC PDU packets in one synchronisation sequence of an MBMS service to
the same value. The BM-SC should take into account the following factors for setting the timestamp: arrival time of
data, the Maximum Transmission Delay from the BM-SC to the farthermost eNB, the length of the synchronisation
sequence used for time stamping and other extra delay (e.g. processing delay in the eNB). The MSP length is one or
multiple times of the synchronisation sequence length for MBMS services in the MCH.
MBMS user data shall be time-stamped based on separable synchronisation sequences which are tied to multiples of the
TTI length. Each synchronisation sequence for each service is denoted by a single timestamp value working in such a
manner that an increase of the timestamp value by one or more synchronisation sequence lengths shall be interpreted as
an implicit start-of-a-new-synchronisation-sequence-indicator, so that the eNB becomes aware that a new sequence is
starting.
The BM-SC does not know the absolute time point at which a TTI starts, but the sequence length for the time stamp is
set by O&M like the delay parameters. The BM-SC will use the delay parameters to define the transmission time point
of that user data packet and for the following user data packets the sequence length for the time stamp: following user
data packets arriving within e.g. 40ms will receive the same time stamp value as the first data packet, if the sequence
length is set to be 40ms.
In MBSFN operation,the eNB shall schedule the received data packets in the first MSP following the time point
indicated by the timestamp unless the MBMS service is suspended, in which case no packet shall be sent by eNB. When
a suspended MBMS service is resumed, the eNB shall enable the transmission from the beginning of the Modification
Period indicated by the MCCH Update Time.
The elementary procedures related to the SYNC-protocol are defined in TS 25.446 [36].
Based on the parameters in the SYNC Header (e.g. Timestamp, Packet Number, Elapsed Octet Counter), the eNB is
able to derive the timing for downlink radio transmission and notice if any SYNC packets are lost during transmission
from BM-SC to the eNB. The eNB is also able to know the size of the lost SYNC packet in case a single SYNC packet
is lost. Furthermore, the eNB may also be able to know the sizes of each lost SYNC packet if multiple consecutive
SYNC packets are lost. Additionally the eNB is able to reorder the PDUs before passing them to RLC processing, if
needed.
At the end of each synchronisation sequence the BM-SC shall send to the eNBs a user data frame, which contains
counter information including 'Total Number Of Packet Counter' and 'Total Number Of Octet' without MBMS payload.
This Total Counter frame is implicitly marking the end-of-sync.seq. The Total Counter frame without payload may be
repeated in order to improve the reliability of the delivery to the eNBs.
In MBSFN operation, in case the SYNC protocol delivers more data for an MCH than the air interface can transport in
the scheduling period, the following procedure shall be used by the eNB. As long as the eNB must drop a packet
because it has too much data for this MCH scheduling period, it does the following,
- select the last bearer according to the order in the MCCH list with a SYNC SDU available for dropping;
- for the selected bearer, drop the available SYNC SDU with the highest Packet Number among the SYNC SDUs
with the latest Timestamp.
A SYNC SDU is considered available for dropping when the eNB knows its size and it has not been dropped by the
eNB.
In SC-PTM operation, if/how to use the timestamp information is left to eNB implementation.
15.3.8 Synchronisation of MCCH Update Signalling via M2

The synchronised radio interface transmission from the cells controlled by different eNBs require means to ensure that
the MCCH content is updated at the same modification period border in each cell belonging to the same MBSFN Area.
The MCE and the concerned eNBs maintain a common time reference which allows each node to be aware of the
modification period boundary within an MBSFN Area. In addition, each node maintains a counter of modification
periods which is incremented by one at each modification period boundary. This counter which is based on common
3GPP
Release 17 207 3GPP TS 36.300 V17.2.0 (2022-09)
start of the first MCCH modification period, allows the MCE to indicate to the eNBs at which modification period the
MCCH update shall take place. The MCE shall ensure that it starts to inform all eNBs within the MBSFN Area well in
advance. In case of the simultaneously change of the MCCH information and the MCCH related BCCH information,
the eNB may use this counter to decide after which BCCH modification period the MCCH related BCCH information
update takes place.
15.3.9 IP Multicast Distribution

To improve the transport efficiency the IP Multicast shall be used for the MBMS payload distribution in the backbone
network between the MBMS-GW and the eNBs that have joined the IP Multicast Group.
The MBMS-GW allocates the Transport Layer Address(es) used for the IP multicast and the DL TEID used for the M1
Transport association. The MBMS-GW sends this information to the MME(s) during the Session Start procedure. The
MCE(s) receives these parameters from the MME in the MBMS Session Start Request message. The MCE passes the
received parameters including at least one set of the Transport Layer Address to the relevant eNBs.
If the eNB accepts the MBMS Session Start request, or if it is required following the acceptance of the MBMS Session
Update request, the eNB joins the channel (IP Multicast and Source address) to the backbone in order to join the bearer
service multicast distribution.
The MBMS payload is forwarded by the MBMS-GW towards the IP Multicast address(es). The eNBs having joined
that IP Multicast will receive the user data packets (SYNC PDU) together with the synchronisation-related information
in header part of SYNC PDU.
15.4 Service Continuity

Mobility procedures for MBMS reception allow the UE to start or continue receiving MBMS service(s) via MBSFN or
SC-PTM when changing cell(s). For each MBMS service provided using SC-PTM, E-UTRAN indicates in the SC-
MCCH the list of neighbour cells providing this MBMS service so that the UE can request unicast reception of the
service before changing to a cell not providing the MBMS service using SC-PTM.
For MBSFN transmission, E-UTRAN procedures provide support for service continuity with respect to mobility within
the same MBSFN area. Within the same geographic area, MBMS services can be provided on more than one frequency
and the frequencies used to provide MBMS services may change from one geographic area to another within a PLMN.
UEs that are receiving MBMS service(s) in RRC_IDLE state performing cell reselection or are in RRC_CONNECTED
state obtain target cell (SC-)MTCH information from the target cell (SC-)MCCH.
To avoid the need to read MBMS related system information and potentially (SC-)MCCH on neighbour frequencies, the
UE is made aware of which frequency is providing which MBMS services via MBSFN or SC-PTM through the
combination of the following MBMS assistance information:
- user service description (USD): in the USD (see TS 26.346 [49]), the application/service layer provides for each
service the TMGI, the session start and end time, the frequencies and the MBMS service area identities (MBMS
SAIs, see definition in clause 15.3 of TS 23.003 [26]) belonging to the MBMS service area (see definition in TS
23.246 [48]);
- system information: MBMS and non-MBMS cells indicate in SystemInformationBlockType15 the MBMS SAIs
of the current frequency and of each neighbour frequency.
The MBMS SAIs of the neighbouring cell may be provided by X2 signalling (i.e. X2 Setup and eNB Configuration
Update procedures) or/and OAM.
When applying the procedures described below for UEs in RRC_IDLE and RRC_CONNECTED state:
- the UE does not need to verify that a frequency is providing a MBMS service by acquiring (SC-)MCCH and may
apply these procedures even though a MBMS service is not provided via MBSFN or SC-PTM;
- the UE may consider that a service is provided if a session of this service is ongoing as derived from the session
start and end times indicated for this service in the USD and if a frequency provides this service;
- the UE determines the frequency on which a service is provided according to the following:
3GPP
Release 17 208 3GPP TS 36.300 V17.2.0 (2022-09)
- if the serving cell provides SystemInformationBlockType15 (SystemInformationBlockType15-NB in NB-IoT),

the UE considers that a frequency is providing the MBMS service via MBSFN or SC-PTM if and only if one
of the MBMS SAI(s) of this frequency as indicated in SystemInformationBlockType15 of the serving cell is
indicated for this MBMS service in the USD;
- except for NB-IoT UEs, BL UEs or UEs in enhanced coverage, if the serving cell does not provide
SystemInformationBlockType15, the UE in RRC_IDLE state may consider that a frequency included in the
USD for the MBMS service is providing this MBMS service as long as the UE reselects cells where
SystemInformationBlockType13 is provided.
Except for NB-IoT UEs, BL UEs or UEs in enhanced coverage, in RRC_IDLE, the UE applies the normal cell
reselection rules with the following modifications:
- the UE which is receiving MBMS service(s) via MBSFN or SC-PTM and can only receive these MBMS
service(s) via MBSFN or SC-PTM while camping on the frequency providing these MBMS service(s) is allowed
to make this frequency highest priority;
- the UE which is interested in receiving MBMS service(s) via MBSFN or SC-PTM and can only receive these
MBMS service(s) via MBSFN or SC-PTM while camping on the frequency providing these MBMS service(s) is
allowed to make this frequency highest priority when it intends to receive these MBMS service(s);
- when the MBMS service(s) which the UE is interested in are no longer available (after the end of the session) or
the UE is no longer interested in receiving the service(s), the UE no longer prioritises the frequency providing
these MBMS service(s);
NOTE 1: In RRC IDLE, when the above modifications to cell reselection rules are applied, the prioritization
between the frequency providing these MBMS service(s) and the frequency of a CSG cell, and the
autonomous search are left to UE implementation.
For NB-IoT UEs, BL UEs or UEs in enhanced coverage, the UE applies the normal cell reselection rules with the
following modifications:
- the UE which is receiving MBMS service(s) via SC-PTM and can only receive these MBMS service(s) via SC-
PTM while camping on the frequency providing these MBMS service(s) applies an offset signalled in
SystemInformationBlockType5-NB for NB-IoT UEs and SystemInformationBlockType5 for BL UEs or UEs in
CE to this frequency in ranking based cell reselection;
- the UE which is interested in receiving MBMS service(s) via SC-PTM and can only receive these MBMS
service(s) via SC-PTM while camping on the frequency providing these MBMS service(s) applies an offset
signalled in SystemInformationBlockType5-NB for NB-IoT UEs and SystemInformationBlockType5 for BL UEs
or UEs in CE to this frequency in ranking based cell reselection;
- when the MBMS service(s) which the UE is interested in are no longer available (after the end of the session) or
the UE is no longer interested in receiving the service(s), the UE no longer apply the offset to the frequency
providing these MBMS service(s) in ranking based cell reselection.
Except for NB-IoT UEs, in RRC_CONNECTED, the UE that is receiving or interested to receive MBMS via MBSFN
or SC-PTM informs the network about its MBMS interest via a RRC message and the network does its best to ensure
that the UE is able to receive MBMS and unicast services subject to the UE's capabilities:
- the UE indicates the frequencies which provide the service(s) that the UE is receiving or is interested to receive
simultaneously, and which can be received simultaneously in accordance with the UE capabilities.
- if the PCell broadcasts SystemInformationBlockType20, the UE also indicates the list of services that the UE is
receiving or is interested to receive on the indicated frequencies.
- the UE indicates its MBMS interest at RRC connection establishment (the UE does not need to wait until AS
security is activated), and whenever the set of frequencies on which the UE is interested in receiving MBMS
services has changed compared with the last indication sent to the network (e.g. due to a change of user interest
or of service availability), and whenever the list of MBMS services that the UE is interested in receiving has
changed compared with the last indication sent to the network.
- the UE may only indicate its interest when the PCell provides SystemInformationBlockType15 and after having
acquired SystemInformationBlockType15 of the current PCell.
3GPP
Release 17 209 3GPP TS 36.300 V17.2.0 (2022-09)
- the UE may indicate its MBMS interest even if the current configured serving cell(s) do not prevent it from
receiving the MBMS services it is interested in.
- the UE indicates with a single bit whether it prioritises MBMS reception over unicast. This priority indication
applies to all unicast bearers and all MBMS frequencies. It is sent whether the MBMS frequencies are congested
or not.
- the E-UTRAN reuses the SupportedBandCombination IE to derive the UEs MBMS related reception
capabilities, i.e. the E-UTRAN tries to ensure that the UE is able to receive MBMS and unicast bearers by
providing them on the frequencies indicated in SupportedBandCombination IE signalled by the UE. The UE
supporting MBMS reception via MBSFN or SC-PTM shall support MBMS reception via MBSFN or SC-PTM
respectively, on any serving cell and on any cell that may be additionally configured as serving cell according to
the UE capabilities.
- the E-UTRAN tries to ensure that the UE which does not support simultaneous reception of unicast transmission
and SC-PTM transmission in one subframe on one carrier is able to receive the indicated MBMS services
transmitted via SC-PTM and to receive unicast bearers by scheduling them in different subframes.
- for handover preparation, the source eNB transfers the MBMS interest of the UE, if available, to the target eNB.
After handover, the UE reads SystemInformationBlockType15 before updating its MBMS interest. If
SystemInformationBlockType15 is provided on the target cell but not on the source cell, the UE indicates its
MBMS interest after handover.
If MBMS is prioritised and the unicast connection cannot be maintained because of congestion on the MBMS carrier
then the E-UTRAN releases unicast bearers. It is left to E-UTRAN implementation whether all bearers or only GBR
bearers are released. The E-UTRAN does not trigger re-establishment of the released unicast bearers. For congestion
control, the E-UTRAN can rely on existing access control mechanisms.
The E-UTRAN may take into account the UE priority for MBMS or unicast reception when receiving an indication of
proximity to a CSG cell from a UE which also indicated interest in MBMS reception (or vice-versa).
15.5 Network sharing

Unicast mobility shall not be affected by the sharing of MBMS resources by operators.
15.6 Network Functions for Support of Multiplexing

Considerable gain in radio resource efficiency can be achieved by multiplexing several E-MBMS services on a single
MCH. The services that share the resources are called E-MBMS Service Multiplex. The amount of common radio
resources allocated to such an E-MBMS Service Multiplex can be smaller than the sum of radio resources, which would
need to be allocated for the individual services without multiplexing. This represents the statistical multiplexing gain.
The MCE manages the E-MBMS Service Multiplex e.g. deciding which services are to be multiplexed on which MCH.
The duration of each E-MBMS service may be different, so there is a need to manage the Service Multiplex
dynamically, i.e. addition or removal of services into/from the E-MBMS Service Multiplex. The MCE allocates the
optimal amount of resources to multiplexed services, using service related information. The MCE selects the CSA
pattern for the MCHs and also the order in which the services appear in the MCCH. MBSFN transmission is ensured by
identical multiplexing of the services in all cells belonging to the same MBSFN area. The location of the multiplexing
function is in the eNB MAC layer.
These functions are supported by respective signalling information on M2 interface. This scheduling information is sent
to all eNBs via the M2 interface procedure "MBMS Scheduling Information".
Figure 15.6.1 MBMS Scheduling Information procedure message flow on M2 interface
3GPP
Release 17 210 3GPP TS 36.300 V17.2.0 (2022-09)
15.7 Procedures
15.7.1 Procedures for Broadcast mode
15.7.1.1 Session Start procedure
The purpose of the MBMS Session Start procedure is to request the E-UTRAN to notify UEs about an upcoming
MBMS Session of a given MBMS Bearer Service and to establish an MBMS E-RAB for this MBMS Session. The
MBMS Session Start procedure is triggered by the EPC.
Figure 15.7.1.1-1. Session Start procedure
1. The MME sends MBMS session start request message to the MCE(s) controlling eNBs in the targeted MBMS
service area. The message includes the IP multicast address, session attributes and the minimum time to wait
before the first data delivery, and includes the list of cell identities if available.
NOTE 1: The MME does not need to check the PLMN ID included in the TMGI
2. T he MCE decides whether to use SC-PTM or MBSFN to carry the MBMS bearer over the air interface.
In MBSFN operation, the MCE checks whether the radio resources are sufficient for the establishment of new
MBMS service(s) in the area it controls. If not, MCE decides not to establish the radio bearers of the MBMS
service(s) and does not forward the MBMS session start request message to the involved eNBs, or may pre-empt
radio resources from other radio bearer(s) of ongoing MBMS service(s) according to ARP. The MCE confirms
the reception of the MBMS Session Start request to the MME. This message can be transmitted before the step 4.
Only in case of distributed MCE architecture radio resource setup is scheduled according to the parameter "time
of MBMS data transfer" which indicates an absolute start time of data delivery, otherwise according to the
"minimum time to MBMS data transfer" parameter.
NOTE 2: In MBSFN operation, the MCE may send the MBMS SESSION START RESPONSE message after it
receives at least one confirmation from the eNB(s) (i.e. Step 4).
In SC-PTM operation, the MCE only confirms the reception of the MBMS Session Start request to the MME,
after the MCE receives at least one confirmation from the eNB(s) (i.e. Step 4).
3. In MBSFN operation, the MCE sends the MBMS Session Start Request message to the relevant eNBs. If the
MBMS Session Start message includes the MBMS Service Area Identity with value 0 as defined in TS 23.003
[26], the MCE shall consider that all those eNBs supporting the PLMN as indicated by the received MBMS
3GPP
Release 17 211 3GPP TS 36.300 V17.2.0 (2022-09)
Session Start Request message are involved. The MCE then determines in which MBSFN area(s) the service
should be delivered.
In SC-PTM operation, the MCE includes the SC-PTM information (i.e. list of cell identities and QoS
information received from the MME in Step 1) , in the MBMS Session Start Request message to the relevant
eNBs.
NOTE 3: The MCE does not need to check the PLMN ID included in the TMGI.
NOTE 4: When to send the MBMS Session Start message from MCE to eNB according to the minimum time to
wait indication is an MCE implementation issue.
4. In MBSFN operation, eNB confirms the reception of the MBMS Session Start message.
In SC-PTM operation, the eNB checks whether the radio resources are sufficient for the establishment of new
MBMS service(s) in the area it controls. If not, eNB decides not to establish the radio bearers of the MBMS
service(s), or may pre-empt radio resources from other radio bearer(s) according to ARP. eNB confirms the
reception of the MBMS Session Start message.
Step 5 and 6 are only applicable to MBSFN operation.
5. MCE sends the MBMS Scheduling Information message to the eNB including the updated MCCH information
which carries the MBMS service's configuration information. This message can be transmitted before the step 3.
6. eNB confirms the reception of the MBMS Scheduling Information message.
7. eNB indicates MBMS session start to UEs by MCCH change notification and updated MCCH information which
carries the MBMS service's configuration information.
8. eNB joins the IP multicast group to receive the MBMS User Plane data.
9. eNB sends the MBMS data to radio interface; In MBSFN operation, the MBMS data is sent at the determined
time.
15.7.1.2 Session Stop procedure

The MBMS Session Stop procedure is to request the E-UTRAN to notify UEs about the end of a given MBMS Session
and to release the corresponding MBMS E-RAB this MBMS Session. The MBMS Session Stop procedure is triggered
by the EPC.
Figure 15.7.1.2-1. Session Stop procedure
3GPP
Release 17 212 3GPP TS 36.300 V17.2.0 (2022-09)
1. The MME sends MBMS session stop request message to the MCE(s) controlling eNBs in the targeted MBMS
service area.
2. MCE confirms the reception of the MBMS Session stop request to the MME.
3. MCE forwards the MBMS Session stop message to the relevant eNBs.
4. eNB confirms the reception of the MBMS Session stop message.
Step 5 and 6 are only applicable to MBSFN operation.
5. MCE sends the MBMS Scheduling Information message to the eNB including the updated MCCH information
which carries the MBMS service's configuration information. This message can be transmitted before the step 3.
6. eNB confirms the reception of the MBMS Scheduling Information message.
7. eNB indicates MBMS session stop to UEs by removing any service configuration associated with the stopped
session from the updated MCCH message.
8. The corresponding E-RAB is released, and eNB leaves the IP multicast group.
15.7a M1 Interface
15.7a.1 M1 User Plane
The M1 user plane interface is defined between the eNB and the MBMS GW. The M1 user plane interface provides non
guaranteed delivery of user plane PDUs between the eNB and the MBMS GW. The user plane protocol stack on the M1
interface is shown in Figure 15.7a.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 eNB and the MBMS GW.
Figure 15.7a.1-1: M1 Interface User Plane (eNB – MBMS GW)
15.8 M2 Interface
15.8.1 M2 Control Plane
The M2 control plane interface is defined between the eNB and the MCE. The control plane protocol stack of the M2
interface is shown on Figure 15.8.1-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 M2AP (M2
Application Protocol).
3GPP
Release 17 213 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 15.8.1-1: M2 Interface Control Plane (eNB-MCE)
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.
A single SCTP association per eNB-MCE interface instance shall be used with one pair of stream identifiers for M2
common procedures. Only a few pairs of stream identifiers should be used for M2 MBMS-service-associated
procedures. eNB and MCE communication context identifiers that are assigned by the eNB and the MCE for M2
MBMS-service-associated procedures shall be used to distinguish MBMS service specific M2 signalling transport
bearers. The communication context identifiers are conveyed in the respective M2AP messages.
15.8.2 M2 Interface Functions

15.8.2.1 General
The M2 interface provides the following functions:
- MBMS Session Handling Function:
- MBMS Session Start, MBMS Session Stop, MBMS Session Update.
- MBMS Scheduling Information Provision Function.
- M2 Interface Management Function:
- Reset, Error Indication, Restoration.
- M2 Configuration Function.
- MBMS Service Counting Function.
- MBMS Service Suspension and Resumption Function.
15.8.2.2 MBMS Session Handling Function

The MBMS Session Handling Function enables the MCE to provide Session Start, Session Stop and Session Update
messages to the eNBs it is connected to. The MCE provides the information of the MBMS session, e.g., the MBMS
Service Area information, and the SC-PTM information to the eNB, where the SC-PTM information is included only in
case of SC-PTM operation.
15.8.2.3 MBMS Scheduling Information Provision Function

The MBMS Scheduling Information Provision Function enables the MCE to configure MCCH content according to the
expected or ongoing MBMS services, and to configure MCH Scheduling Information for suspension notification.
15.8.2.4 M2 Interface Management Function

The M2 interface management functions provide:
3GPP
Release 17 214 3GPP TS 36.300 V17.2.0 (2022-09)
- means to ensure a defined start of the M2 interface operation (reset);
- means to handle different versions of application part implementations and protocol errors (error indication);
- means to restore services following an eNB failure or an M2 path failure (restoration). The Restoration function
enables the MCE to restore in the eNB the MBMS sessions. This restoration function is implemented by the
MBMS Session Start procedure.
15.8.2.5 M2 Configuration Function

The M2 Configuration Function allows the eNB and MCE to exchange configuration information necessary for the
operation of the M2 interface, and MCCH related BCCH content.
15.8.2.6 MBMS Service Counting Function

The MBMS Service Counting Function enables the MCE to perform counting and to receive counting results per
MBMS service(s) within MBSFN area(s). MCE can perform counting only for those MBMS service(s) for which access
has not been denied by the admission control function for the corresponding MBMS session(s).
15.8.2.7 MBMS Service Suspension and Resumption Function

The MBMS Service Suspension and Resumption Function enables the MCE to request the eNB that it may release the
allocated RAN resources, may leave the IP multicast if already joined, shall update the MCCH information and shall
suspend the MBSFN transmission while keeping the MBMS context for that service in the eNB. If the MCE
subsequently requests the eNB for resumption, then the eNB shall allocate the RAN resources, shall send the MCCH
change notification, shall update the MCCH information, shall resume the MBSFN transmission and shall join IP
multicast if previously left. This MBMS Services Suspension and Resumption function is implemented by the MBMS
Scheduling Information procedure as described in clause 15.8.3.3.
Suspension/Resumption of MBMS service provision is applied to a whole MBSFN area.
15.8.2.8 MBMS Overload Notification Function

The MBMS Overload Notification Function enables the eNB to notify the MCE about MBMS overload status.
15.8.3 M2 Interface Signalling Procedures

15.8.3.1 General
The elementary procedures supported by the M2AP protocol are listed in Table 2 and Table 3 of TS 36.443 [44].
15.8.3.2 MBMS Session signalling procedure

The MBMS Session signalling procedure enables the MCE to deliver Session Start, Session Stop and Session Update
messages to the concerned eNBs. At Session Start and Session Update, the MCE provides the information of the
MBMS session, e.g., the MBMS Service Area information, and the SC-PTM information to the eNB, where the SC-
PTM information is included only in case of SC-PTM operation.
15.8.3.3 MBMS Scheduling Information procedure

The MBMS Scheduling Information procedure enables the MCE to update MCCH information whenever necessary.
Typically, the MCE issues an MBMS Scheduling Information procedure before user data transmission for an
announced MBMS service starts or after it has ended.
The MBMS Scheduling Information procedure also enables the MCE to update MCH Scheduling Information for
suspension notification.
15.8.3.4 M2 Interface Management procedures

15.8.3.4.1 Reset procedure
The Reset procedure is issued in order to re-initialize the peer entity or part of the peer entity after node setup and after
a failure event occurred. This procedure may be initiated by both the eNB and MCE.
3GPP
Release 17 215 3GPP TS 36.300 V17.2.0 (2022-09)
15.8.3.4.2 Error Indication procedure

The Error Indication procedure may be initiated by the eNB and the MCE. It is used to report detected errors in one
incoming message, if an appropriate failure message cannot be reported to the sending entity.
15.8.3.5 M2 Configuration procedures

15.8.3.5.1 M2 Setup procedure
The M2 Setup procedure allows the exchange of configured data which is required in the MCE and in the eNB
respectively to ensure a proper interoperation and MCCH related BCCH content. The M2 Setup procedure is triggered
by the eNB. The M2 Setup procedure is the first M2AP procedure executed on an M2 interface instance.
15.8.3.5.2 eNB Configuration Update procedure

The eNB Configuration Update procedure is used to provide updated configured data in the eNB and receive MCCH
related BCCH content from MCE. The eNB Configuration Update procedure is triggered by the eNB.
15.8.3.5.3 MCE Configuration Update procedure

The MCE Configuration Update procedure is used to provide updated configured data in the MCE and tell eNB updated
MCCH related BCCH content. The MCE Configuration Update procedure is triggered by the MCE.
15.8.3.6 MBMS Service Counting procedures

15.8.3.6.1 MBMS Service Counting procedure
The MBMS Service Counting procedure is used to trigger the eNB to count the number of connected mode UEs that
either are receiving the MBMS service(s) or are interested in the reception of the MBMS service(s).
15.8.3.6.2 MBMS Service Counting Results Report procedure

The MBMS Service Counting Results Report procedure is used by the eNB to provide the MCE with the number of
connected mode UEs that either are receiving the MBMS service(s) or are interested in the reception of the MBMS
service(s) based on counting performed by the eNB.
15.8.3.7 MBMS Overload Notification procedure

The MBMS Overload Notification procedure enables the eNB to notify the MCE about MBMS overload status.
15.9 M3 Interface
15.9.1 M3 Control Plane
The M3 control plane interface is defined between the MME and the MCE. The control plane protocol stack of the M3
interface is shown on Figure 15.9.1-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 M3AP (M3
Application Protocol).
3GPP
Release 17 216 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 15.9.1-1: M3 Interface Control Plane (MME-MCE)
A single SCTP association per MME-MCE interface instance shall be used with one pair of stream identifiers for M3
common procedures. Only a few pairs of stream identifiers should be used for M3 MBMS-service-associated
procedures. MME and MCE communication context identifiers that are assigned by the MME and the MCE for M3
MBMS-service-associated procedures shall be used to distinguish MBMS service specific M3 signalling transport
bearers. The communication context identifiers are conveyed in the respective M3AP messages.
15.9.2 M3 Interface Functions

15.9.2.1 General
The M3 interface provides the following functions:
- MBMS Session Handling Function:
- MBMS Session Start, MBMS Session Stop, MBMS Session Update.
- M3 Interface Management Function:
- Reset, Error Indication, Restoration.
- M3 Configuration Function (distributed MCE architecture only, see clause 15.1.1)
- M3 Setup, MCE Configuration Update.
15.9.2.2 MBMS Session Handling Function

The MBMS Session Handling Function enables the MME to provided Session Start, Session Stop and Session Update
messages to the MCEs it is connected to. The MME provides the information of the MBMS session, e.g., QoS, MBMS
Service Area, and the list of cell identities if available, to the MCEs.
In this release the MBMS Session Update procedure only supports the update of MBMS Service Area, the update of the
list of cell identities, the update of the allocation and retention priority of the MBMS session and the update of time of
MBMS data transfer where the last one is used in the distributed MCE architecture only.
15.9.2.3 M3 Interface Management Function

The M3 interface management functions provide:
- means to ensure a defined start of the M3 interface operation (reset);
- means to handle different versions of application part implementations and protocol errors (error indication);
3GPP
Release 17 217 3GPP TS 36.300 V17.2.0 (2022-09)
- means to restore services following an MCE failure or an M3 path failure (restoration).The Restoration function
enables the MME to restore in the MCE the MBMS sessions as specified in TS 23.007 [56]. This Restoration
function is implemented by the MBMS Session Start procedure.
15.9.2.4 M3 Configuration Function

The M3 Configuration Function allows the MCE to exchange with the MME node configuration information necessary
for the operation of the M3 interface such as the supported MBMS Service Area information.
15.9.3 M3 Interface Signalling Procedures

15.9.3.1 General
The elementary procedures supported by the M3AP protocol are listed in Table 8-1 and Table 8-2 of TS 36.444 [45].
15.9.3.2 MBMS Session signalling procedure

The MBMS Session signalling procedure enables the MME to deliver Session Start, Session Stop and Session Update
messages to the concerned MCEs. At Session Start and Session Update, the MME provides the information of the
MBMS session, e.g., QoS, MBMS Service Area, and the list of cell identities if available, to the MCEs.
In distributed MCE architecture only, the MME may also provide a "time of MBMS data transfer" to indicate the
absolute start time of data delivery, and a "time of MBMS data stop" to indicate the absolute end time of data delivery.
In this release the MBMS Session Update procedure only supports the update of MBMS Service Area, the update of the
list of cell identities if available, the update of the allocation and retention priority of the MBMS session and the update
of time of MBMS data transfer where the last one is used in the distributed MCE architecture only.
15.9.3.3 M3 Interface Management procedures

The Reset procedure is issued in order to re-initialize the peer entity or part of the peer entity after node setup and after
a failure event occurred. This procedure may be initiated by both the MME and MCE.
15.9.3.3.2 Error Indication procedure

The Error Indication procedure may be initiated by the MME and the MCE. It is used to report detected errors in one
incoming message, if an appropriate failure message cannot be reported to the sending entity.
15.9.3.4 M3 Configuration procedures

15.9.3.4.1 M3 Setup procedure
The M3 Setup procedure allows the initial exchange of configured data which is required in the MCE and in the MME
such as the supported MBMS Service Area information. The M3 Setup procedure is initiated by the MCE.
15.9.3.4.2 MCE Configuration Update procedure

The MCE Configuration Update procedure is used to provide updated configured data in the MCE to the MME. The
MCE Configuration Update procedure is triggered by the MCE.
15.10 MBMS Counting

15.10.1 General
MBMS counting in LTE is used to determine if there are sufficient UEs interested in receiving a service to enable the
operator to decide if it is appropriate to deliver the service via MBSFN. It allows the operator to choose between
enabling or disabling MBSFN transmission for the service. MBMS counting applies only to connected mode UEs.
Enabling and disabling MBSFN transmission is realized by MBMS Service Suspension and Resumption function in
clause 15.8.2.7.
The following principles are used for the MBMS counting:
3GPP
Release 17 218 3GPP TS 36.300 V17.2.0 (2022-09)
- Counting is supported for both a service already provided by MBSFN in an MBSFN area as well as for a service
not yet provided via MBSFN in an MBSFN area. A service not yet provided via MBSFN in an MBSFN area
may be:
- Service provided via unicast bearer.
- Service not yet provided either by MBSFN or by unicast.
- RAN is not aware of MBMS service provisioning through unicast bearers.
15.10.2 Counting Procedure

The Counting Procedure is initiated by the network. Initiation of the Counting Procedure results in a request to each
eNB involved in the providing MBSFN area to send a Counting Request (the Counting Request is included in the
directly extended MCCH message), which contains a list of TMGI's requiring UE feedback. The connected mode UEs
which are receiving or interested in the indicated services will respond with a RRC Counting Response message, which
includes short MBMS service identities (unique within the MBSFN service area) and may optionally include the
information to identify the MBSFN Area (if overlapping is configured).
The following principles are used for the Counting Procedure:
- Network has means to disable UE counting per service.
- The UE is able to report on multiple MBMS services via a single Counting Response message.
- It is unnecessary to retransmit the Counting Response when the UE moves within the same MBSFN area.
- The network only gets one response from a UE related to one Counting Request message, which is broadcast for
one modification period.
- The UE cannot automatically indicate to network a change of interest in MBMS service(s).
- The network counts UE interest per service.
15.11 MBMS service reception using Receive Only Mode

MBMS service(s) can be received by a UE in ROM as described in TS 23.246 [48], clause D.2.3 and in TS 26.346 [49].
A UE may receive or be interested to receive broadcast MBMS service(s) in ROM from a different eNB while receiving
unicast or MBMS service(s) from serving eNB. If UE baseband resources are shared for receiving unicast service and
MBMS service(s) in ROM from different eNBs, the UE may use MBMSInterestIndication signaling procedure as
described in TS 36.331 [16] to inform the unicast serving eNB about the baseband resources used for the purpose of
MBMS service(s) in ROM from a different eNB.
16 Radio Resource Management aspects

16.0 General
The purpose of radio resource management (RRM) is to ensure the efficient use the available radio resources and to
provide mechanisms that enable E-UTRAN to meet radio resource related requirements identified in clause 10 of TR
25.913 [2]. In particular, RRM in E-UTRAN provides means to manage (e.g. assign, re-assign and release) radio
resources taking into account single and multi-cell aspects.
16.1 RRM functions

16.1.1 Radio Bearer Control (RBC)
The establishment, maintenance and release of Radio Bearers involve the configuration of radio resources associated
with them. When setting up a radio bearer for a service, radio bearer control (RBC) takes into account the overall
resource situation in E-UTRAN, the QoS requirements of in-progress sessions and the QoS requirement for the new
service. RBC is also concerned with the maintenance of radio bearers of in-progress sessions at the change of the radio
resource situation due to mobility or other reasons. RBC is involved in the release of radio resources associated with
radio bearers at session termination, handover or at other occasions.
3GPP
Release 17 219 3GPP TS 36.300 V17.2.0 (2022-09)
RBC is located in the eNB.
16.1.2 Radio Admission Control (RAC)

The task of radio admission control (RAC) is to admit or reject the establishment requests for new radio bearers. In
order to do this, RAC takes into account the overall resource situation in E-UTRAN, the QoS requirements, the priority
levels and the provided QoS of in-progress sessions and the QoS requirement of the new radio bearer request. The goal
of RAC is to ensure high radio resource utilization (by accepting radio bearer requests as long as radio resources
available) and at the same time to ensure proper QoS for in-progress sessions (by rejecting radio bearer requests when
they cannot be accommodated).
RAC is located in the eNB.
16.1.3 Connection Mobility Control (CMC)

Connection mobility control (CMC) is concerned with the management of radio resources in connection with idle or
connected mode mobility. In idle mode, the cell reselection algorithms are controlled by setting of parameters
(thresholds and hysteresis values) that define the best cell and/or determine when the UE should select a new cell. Also,
E-UTRAN broadcasts parameters that configure the UE measurement and reporting procedures. In connected mode, the
mobility of radio connections has to be supported. Handover decisions may be based on UE and eNB measurements. In
addition, handover decisions may take other inputs, such as neighbour cell load, traffic distribution, transport and
hardware resources and Operator defined policies into account.
CMC is located in the eNB.
16.1.4 Dynamic Resource Allocation (DRA) - Packet Scheduling (PS)

The task of dynamic resource allocation (DRA) or packet scheduling (PS) is to allocate and de-allocate resources
(including buffer and processing resources and resource blocks (i.e. chunks)) to user and control plane packets. DRA
involves several sub-tasks, including the selection of radio bearers whose packets are to be scheduled and managing the
necessary resources (e.g. the power levels or the specific resource blocks used). PS typically takes into account the QoS
requirements associated with the radio bearers, the channel quality information for UEs, buffer status, interference
situation, etc. DRA may also take into account restrictions or preferences on some of the available resource blocks or
resource block sets due to inter-cell interference coordination considerations.
DRA is located in the eNB.
16.1.5 Inter-cell Interference Coordination (ICIC)

16.1.5.0 General
Inter-cell interference coordination has the task to manage radio resources such that inter-cell interference is kept under
control. ICIC mechanism includes a frequency domain component and time domain component. ICIC is inherently a
multi-cell RRM function that needs to take into account information (e.g. the resource usage status and traffic load
situation) from multiple cells. The preferred ICIC method may be different in the uplink and downlink.
The frequency domain ICIC manages radio resource, notably the radio resource blocks, such that multiple cells
coordinate use of frequency domain resources.
In TDD, intended UL-DL configuration may be exchanged through backhaul signalling, and frequency domain ICIC
information may be exchanged per subframe set, such that multiple cells may coordinate the usage of frequency domain
resources in the subframe sets.
For the time domain ICIC, subframe utilization across different cells are coordinated in time through backhaul
signalling or OAM configuration of so called Almost Blank Subframe patterns. The Almost Blank Subframes (ABSs) in
an aggressor cell are used to protect resources in subframes in the victim cell receiving strong inter-cell interference.
Almost blank subframes are subframes with reduced transmit power (including no transmission) on some physical
channels and/or reduced activity. The eNB ensures backwards compatibility towards UEs by transmitting necessary
control channels and physical signals as well as System Information. Patterns based on ABSs are signalled to the UE to
restrict the UE measurement to specific subframes, called measurement resource restrictions. There are different
patterns depending on the type of measured cell (serving or neighbour cell) and measurement type (e.g. RRM, RLM).
MBSFN subframes can be used for time domain ICIC when they are also included in ABS patterns. The eNB cannot
3GPP
Release 17 220 3GPP TS 36.300 V17.2.0 (2022-09)
configure MBSFN subframes, as specified in TS 36.211 [4], as ABSs when these MBSFN subframes are used for other
usages (e.g., MBMS, LCS).
Extending the coverage of a cell by means of connecting a UE to cell that is weaker than the strongest detected cell is
referred to as cell range extension (CRE). With time domain ICIC, a CRE UE may continue to be served by a victim
cell (i.e., the weaker cell) even while under strong interference from aggressor cells (i.e., the stronger cell).
A UE under strong interference from aggressor cells may need to mitigate interference from the aggressor cells on some
physical channels and signals in order to receive data from serving cell or to detect the weak cells or to perform
measurements on the weak cells.
The network may provide SIB1 to the UE in the CRE region by a dedicated RRC signalling to assist UE system
information acquisition.
ICIC is located in the eNB.
16.1.5.1 UE configurations for time domain ICIC

For the UE to measure "protected" resources of the serving cell and/or neighbour cells, RRM/RLM/CSI measurement
resource restriction is signalled to the UE. There are three kinds of measurement resource restriction patterns that may
be configured for the UE.
- Pattern 1: A single RRM/RLM measurement resource restriction for the PCell.
- Pattern 2: A single RRM measurement resource restriction for indicated list of neighbour cells operating in the
same carrier frequency as the PCell.
- Pattern 3: Resource restriction for CSI measurement of the PCell. If configured, two subframe subsets are
configured per UE. The UE reports CSI for each configured subframe subset.
For pattern 3, it is up to the network to choose the two subframe subsets but typically the two subframe subsets
are chosen with the expectation that CSI measurements using the two configured subframe subsets are subject to
different levels of interference (e.g., one subframe subset indicates ABSs while the second subframe subset
indicates non-ABSs). For periodic CSI reports, linkage of each CSI report to a configured subset of subframe is
defined in TS 36.331 [16]. For aperiodic CSI reports, the UE reports CSI based on the subframe subset
containing the CSI reference resource.
In RRC_CONNECTED, the RRM/RLM/CSI measurement resource restrictions are configured by dedicated RRC
signalling.
The network may configure the UE with CRS assistance information of the aggressor cells in order to aid the UE to
mitigate the interference from CRS of the aggressor cells.
16.1.5.2 OAM requirements for time domain ICIC

16.1.5.2.1 Configuration for CSG cell
When the time-domain inter-cell interference coordination is used for non-members UE in close proximity of a CSG
cell, OAM configures a CSG cell not to use a time domain resource set (i.e. a set of subframes), so that a non-member
UE in close proximity of the CSG cell can be still served by another cell. OAM also configures a cell neighbour to a
CSG cell with the protected time domain resource set not used by the CSG cell, so that the neighbour cell knows which
time domain resource can be used for a non-member UE in close proximity of the CSG cell.
16.1.5.2.2 Configuration for interfering non-CSG cell

When the time-domain inter-cell interference coordination is used to mitigate interference between two cells using X2
signalling of ABS patterns from an interfering eNB to an interfered eNB, the following OAM requirements are applied.
- OAM may configure association between eNBs to use the time-domain inter-cell interference coordination.
- For the deployment scenarios where common subset for ABS patterns from multiple interfering cells is
desirable, OAM configuration ensures that a 'common subset' exists between the ABS patterns of those
interfering cells.
3GPP
Release 17 221 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE 1: The possibility of whether the common ABS pattern from multiple eNBs is desirable or not depends on
the deployment cases of the time domain solution of inter-cell interference coordination.
NOTE 2: It is up to eNB implementation how a receiving eNB derives the 'usable ABS subset' from the ABS
patterns coming from multiple neighbour eNBs.
16.1.6 Load Balancing (LB)

Load balancing has the task to handle uneven distribution of the traffic load over multiple cells. The purpose of LB is
thus to influence the load distribution in such a manner that radio resources remain highly utilized and the QoS of in-
progress sessions are maintained to the extent possible and call dropping probabilities are kept sufficiently small. LB
algorithms may result in hand-over or cell reselection decisions with the purpose of redistribute traffic from highly
loaded cells to underutilized cells.
LB is located in the eNB.
16.1.7 Inter-RAT Radio Resource Management

Inter-RAT RRM is primarily concerned with the management of radio resources in connection with inter-RAT
mobility, notably inter-RAT handover. At inter-RAT handover, the handover decision may take into account the
involved RATs resource situation as well as UE capabilities and Operator policies. The importance of Inter-RAT RRM
may depend on the specific scenario in which E-UTRAN is deployed. Inter-RAT RRM may also include functionality
for inter-RAT load balancing for idle and connected mode UEs.
16.1.8 Subscriber Profile ID for RAT/Frequency Priority

The RRM strategy in E-UTRAN may be based on user specific information.
The Subscriber Profile ID for RAT/Frequency Priority (SPID) parameter and the Additional RRM Policy Index (ARPI)
received by the eNB via the S1 interface or the X2 interface are indices referring to user information (e.g. mobility
profile, service usage profile). The information is UE specific and applies to all its Radio Bearers.
NOTE: The Additional RRM Policy Index (ARPI) may be applied for specific RRM strategies independently or
in combination with the Subscriber Profile ID for RAT/Frequency Priority (SPID).
TS 23.401 [17] specifies that a target eNB may receive an ARPI from the MME while receiving an ARPI from the
source eNB, in which case information received from the MME shall prevail.
Both indices are mapped by the eNB to locally defined configuration in order to apply specific RRM strategies (e.g. to
define RRC_IDLE mode priorities and control inter-RAT/inter frequency handover in RRC_CONNECTED mode).
16.1.9 Inter-eNB CoMP

The task of inter-eNB CoMP is to coordinate multiple eNBs in order that the coverage of high data rates and the cell-
edge throughput are improved, and also the system throughput is increased. The coordination of multiple eNBs is
achieved by signalling between eNBs of hypothetical resource allocation information, CoMP hypotheses, associated
with benefit metrics. Each of the signalled CoMP hypotheses is concerned with a cell belonging to either the receiving
eNB, the sending eNB or their neighbour. The benefit metric associated with the CoMP hypotheses quantifies the
benefit assuming that the CoMP hypotheses are applied. The receiving eNB of the CoMP hypotheses and the benefit
metrics may take them into account for RRM.
RSRP measurement reports and CSI reports may be exploited for inter-eNB CoMP. For example, the RSRP
measurement reports and CSI reports can be used to determine and/or validate CoMP hypotheses and benefit metrics.
The enhanced RNTP may be used in inter-eNB CoMP to exchange information between eNBs concerning the adopted
power allocation.
Inter-eNB CoMP is located in the eNB.
16.1.10 Cell on/off and cell discovery

The eNB using cell on/off may adaptively turn the downlink transmission of a cell on and off. A cell whose downlink
transmission is turned off may be configured as a deactivated SCell for a UE. A cell performing on/off may transmit
only periodic discovery signals and UEs may be configured to measure the discovery signals for RRM. Cell on/off may
3GPP
Release 17 222 3GPP TS 36.300 V17.2.0 (2022-09)
be performed for the purpose of e.g. inter-cell interference coordination and avoidance, load balancing, and energy
saving, etc. The criteria used for cell on/off may be e.g. traffic load increase/decrease, UE arrival/departure (i.e. UE-cell
association), and packet arrival/completion.
A UE performs RRM measurement and may discover a cell or transmission point of a cell based on discovery signals
when the UE is configured with discovery-signal-based measurements.
16.1.11 Resource reservation

E-UTRAN may reserve resources in uplink and downlink on a NB-IoT non-anchor carrier to avoid resource overlap e.g.
with NR when NB-IoT is deployed within an NR carrier. The resource reservation signalled to the UE is carrier specific
and is for use in unicast transmission in connected mode.
For BL UEs or UEs in enhanced coverage, E-UTRAN may reserve resources in uplink and downlink to avoid resource
overlap e.g. with NR when it is deployed within an NR carrier. The resource reservation signalled to the UE is cell
specific and is for use in unicast transmission in connected mode.
16.2 RRM architecture

16.2.1 Centralised Handling of certain RRM Functions
Void.
16.2.2 De-Centralised RRM

16.2.2.1 UE History Information
The source eNB collects and stores the UE History Information for as long as the UE stays in one of its cells.
When information needs to be discarded because the list is full, such information will be discarded in order of its
position in the list, starting with the oldest cell record. If the list is full, and the UE history information from the UE is
available, the UE history information from the UE should also be discarded.
The resulting information is then used in subsequent handover preparations by means of the Handover Preparation
procedures over the S1 and X2 interfaces, which provide the target eNB with a list of previously visited cells and
associated (per-cell) information elements. The Handover Preparation procedures also trigger the target eNB to start
collection and storage of UE history Information and thus to propagate the collected information.
16.2.3 Void
16.3 UE assistance information for RRM, and UE power
optimisations and UE overheating
Except for NB-IoT UEs, in order to optimise the user experience and (for instance) to assist the eNB in configuring
connected mode parameters and connection release handling, the UE may be configured to send assistance information
to the eNB comprising:
- UE preference for power optimised configuration (1 bit):
- When this bit is sent by the UE, the UE shall set this in accordance with its preference for a configuration that
is primarily optimised for power saving (e.g. a long value for the long DRX cycle or RRC connection
release) or not;
- The details regarding how the UE sets the indicator are left to UE implementation.
- UE bandwidth preference on maximum PDSCH/PUSCH bandwidth:
- When this information is sent by the UE that supports CE mode, the UE shall set this in accordance with its
preference on maximum PDSCH/PUSCH bandwidth to assist the eNB for a reconfiguration of the CE mode
for the UE in RRC_CONNECTED state;
- The details regarding how the UE sets the bandwidth preference are left to UE implementation.
3GPP
Release 17 223 3GPP TS 36.300 V17.2.0 (2022-09)
- UE indication on detected overheating:
- When this information is send by the UE, the UE shall set this information to inform the eNB about UE
internal overheating caused by configurations concerning carrier aggregation/dual connectivity, MIMO
transmissions, and/or modulation schemes being concurrently configured. The eNB may mitigate the
indicated overheating by downgrading the UE configuration. Details regarding how the eNB mitigates the
overheating are left to implementation (e.g. the eNB may choose to mitigate overheating by downgrading E-
UTRA configuration and/or NR in case of EN-DC taking into account the assistance information provided by
the UE). If the eNB does not provide any mitigation, the UE may need to mitigate the indicated overheating
based on UE implementation.
- The details regarding how the UE detects the internal overheating are left to UE implementation.
In 5GS and, if configured, in EPS, a NB-IoT UE or BL UE may send assistance information to the eNB to assist the
eNB in connection release handling.
The network response to the UE assistance information is left to network implementation. The eNB ensures that an
appropriate QoS level is provided irrespective of received power preference indication or the bandwidth preference.
17 Void
17.1 Void
18 UE capabilities
RRC signalling carries AS capabilities and NAS signalling carries NAS capabilities. When a capability ID is used as
described below, the ID representing AS capabilities may be carried in NAS signalling. The UE capability information
is stored in the MME. In the uplink, except of NB-IoT no capability information is sent early in e.g.
RRCConnectionRequest message. For NB-IoT, early indications for multi-tone support (IOT bit) and multi-carrier
support (IOT bit) are sent in RRCConnectionRequest-NB message. In the downlink, enquiry procedure of the UE
capability is supported.
3GPP
Release 17 224 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 18-1: Initial UE Capability Handling
The MME stores the UE Radio Capability uploaded in the UE CAPABILITY INFO INDICATION message.
The possible RAT-Types are: EUTRAN, UTRAN, GERAN-PS, GERAN-CS, CDMA2000-1XRTT. The GERAN
capability is divided into separate parts. MS Classmark 2 and Classmark 3 are used for CS domain (in both AS and
NAS) and MS Radio Access Capability is used for PS domain. The main part of CDMA2000 capabilities is not handled
by the eNB or the MME, but is exchanged via tunnelling (see 10.3.2). The small part of CDMA2000 capabilities (for
CDMA2000-1XRTT) is needed for the eNB to be able to build messages for the target CDMA2000 RNC (see 10.3.2).
The eNB may acquire the UE capabilities after a Handover completion. The UE capabilities are then uploaded to the
MME.
Usually during handover preparation, the source RAN node transfers both the UE source RAT capabilities and the
target RAT capabilities to the target RAN node, in order to minimize interruptions and to follow the principles in clause
10.2.2. The source RAN is not mandated to acquire other RAT capabilities (i.e. other than the source and target RAT
capabilities) in order to start a handover preparation. This is described in clause 19.2.2.5.6. However, there are
exceptions to this principle:
- For handover from GERAN to EUTRAN, due to limitations in GERAN radio interface signalling, source RAT
(GERAN) never provides the EUTRA capabilities to the target RAN node.
- At handover from UTRAN to EUTRAN, it is optional to forward the UTRAN capabilities to the target RAN.
The UTRAN capabilities, i.e. the INTER RAT HANDOVER INFO, include START-CS, START-PS and "predefined
configurations", which are "dynamic" IEs. In order to avoid the START values desynchronisation and the key replaying
issue, the eNB always enquiry the UE UTRAN capabilities at transition from RRC_IDLE to RRC_CONNECTED and
before Handover to UTRAN. The eNB does not upload the UE UTRAN capabilities to the MME.
Due to limitations in radio interface signalling, transfer of EUTRA capabilities is not supported in GERAN.
3GPP
Release 17 225 3GPP TS 36.300 V17.2.0 (2022-09)
For BL UEs, UEs supporting Enhanced Coverage and NB-IoT UEs, the S1 signalling includes the UE Radio Capability
for Paging. The eNB uploads the UE Radio Capability for Paging to the MME in the UE CAPABILITY INFO
INDICATION message separately from the UE Radio Capability. The MME includes the UE Radio Capability for
Paging in the paging request to the eNB. The eNB may use the UE Radio Capability for Paging to determine how to
page the UE.
For a NB-IoT UE that supports S1-U data transfer or User Plane CIoT EPS optimisations, as defined in TS 24.301 [20],
the procedure in Figure 18-1 is applicable except that RAT-Types and handover are not supported.
If a request to retrieve the UE Radio Capability is included in the DOWNLINK NAS TRANSPORT message, the eNB
may request the UE Radio Capability from the UE and provide it to the MME in the UE CAPABILITY INFO
INDICATION message. The detailed procedure is defined in TS 36.413 [25].
For a UE that supports Control Plane CIoT EPS optimisation, as defined in TS 24.301 [20], the MME may initiate
Connection Establishment Indication procedure to provide UE Radio Capability to the eNB after receiving INITIAL UE
MESSAGE message. If the UE Radio Capability is not included in the procedure, this may trigger the eNB to request
the UE Radio Capability from the UE and to provide it to the MME in the UE CAPABILITY INFO INDICATION
message. The detailed procedure is defined in TS 36.413 [25].
In NB-IoT, for a UE that supports Control Plane CIoT EPS optimisations, as defined in TS 24.301 [20], the eNB, based
on configuration, may retrieve the UE Radio capability from the MME upon reception of RRC Connection Request as
defined in TS 23.401 [17], clauses 5.3.4B.2 and 5.3.4B.3.
If supported by the UE and the network, the UE may provide an ID in NAS signalling that represents its radio
capabilities for one or more RATs in order to reduce signalling overhead. The ID may be assigned either by the
manufacturer or by the serving PLMN. The manufacturer-assigned ID corresponds to a pre-provisioned set of
capabilities. In the case of the PLMN-assigned ID, assignment takes place in NAS signalling.
19 S1 Interface
19.1 S1 User plane
The S1 user plane interface (S1-U) is defined between the eNB and the S-GW. The S1-U interface provides non
guaranteed delivery of user plane PDUs between the eNB and the S-GW. The user plane protocol stack on the S1
interface is shown in Figure 19.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 eNB and the S-GW.
Figure 19.1-1: S1 Interface User Plane (eNB - S-GW)
3GPP
Release 17 226 3GPP TS 36.300 V17.2.0 (2022-09)
19.2 S1 Control Plane

19.2.0 General
The S1 control plane interface (S1-MME) is defined between the eNB and the MME. The control plane protocol stack
of the S1 interface is shown on Figure 19.2-1. The transport network layer is built on IP transport, similarly to the user
plane but for the reliable transport of signalling messages SCTP is added on top of IP. The application layer signalling
protocol is referred to as S1-AP (S1 Application Protocol).
Figure 19.2-1: S1 Interface Control Plane (eNB-MME)
A single SCTP association per S1-MME interface instance shall be used with one pair of stream identifiers for S1-
MME common procedures. Only a few pairs of stream identifiers should be used for S1-MME dedicated procedures.
MME communication context identifiers that are assigned by the MME for S1-MME dedicated procedures and eNB
communication context identifiers that are assigned by the eNB for S1-MME dedicated procedures shall be used to
distinguish UE specific S1-MME signalling transport bearers. The communication context identifiers are conveyed in
the respective S1-AP messages.
If the S1 signalling transport layer notifies the S1AP layer that the signalling connection broke:
- the MME
- either locally changes the state of the UEs which used this signalling connection to the ECM-IDLE state as
described in TS 23.401 [17] and removes suspended UE Context data for UEs in ECM-IDLE which have
used the S1 signalling connection before it was broken; or
- keep those UEs in ECM_CONNECTED and keep the suspended UE Context data for UEs in ECM-IDLE
which have used the S1 signalling connection before it was broken;
- the eNB
- either releases the RRC connection with those UEs and removes suspended UE Context data for UEs in
RRC_IDLE which have used the S1 signalling connection before it was broken; or
- keep those UEs in RRC_CONNECTED and keep the suspended UE Context data for UEs in ECM-IDLE
which have used the S1 signalling connection before it was broken.
If the S1 signalling transport layer notifies the S1AP layer that the signalling connection is operational again and the
eNB and the MME have decided to keep UEs in ECM-CONNECTED and RRC_CONNECTED respectively and keep
the suspended UE Context data for UEs in ECM-IDLE while the signalling connection was broken, handling of the UE-
related contexts and related signalling connections during the S1 Setup procedure that attempts to re-establish the
broken signalling connection is described in clause 19.2.2.8.
3GPP
Release 17 227 3GPP TS 36.300 V17.2.0 (2022-09)
RNs terminate S1-AP. In this case, there is one S1 interface relation between the RN and the DeNB, and one S1
interface relation between the DeNB and each of the MMEs in the MME pool. The S1 interface relation between the
RN and the DeNB carries non-UE-associated S1-AP signalling between RN and DeNB and UE-associated S1-AP
signalling for UEs connected to the RN. The S1 interface relation between the DeNB and an MME carries non-UE-
associated S1-AP signalling between DeNB and MME and UE-associated S1-AP signalling for UEs connected to the
RN and for UEs connected to the DeNB.
19.2.1 S1 Interface Functions

19.2.1.0 General
The S1 interface provides the following functions:
- E-RAB Service Management function:
- Setup, Modify, Release.
- Mobility Functions for UEs in ECM-CONNECTED:
- Intra-LTE Handover;
- Inter-3GPP-RAT Handover.
- S1 Paging function:
- NAS Signalling Transport function;
- LPPa Signalling Transport function;
- S1-interface management functions:
- Error indication;
- Reset.
- Network Sharing Function;
- Roaming and Access Restriction Support function;
- NAS Node Selection Function;
- Initial Context Setup Function;
- UE Context Modification Function;
- UE Context Resume Function;
- MME Load balancing Function;
- Location Reporting Function;
- PWS (which includes ETWS and CMAS) Message Transmission Function;
- Overload function;
- RAN Information Management Function;
- Configuration Transfer Function;
- S1 CDMA2000 Tunnelling function;
- Trace function;
- UE Radio Capability Match;
- Retrieve UE Information Function;
- UE Information Transfer Function;
3GPP
Release 17 228 3GPP TS 36.300 V17.2.0 (2022-09)
- Report of Secondary RAT data volumes Function;
- UE Radio Capability ID Mapping Function.
19.2.1.1 S1 Paging function

The paging function supports the sending of paging requests to all cells of the TA(s) the UE is registered.
Paging requests are sent to the relevant eNBs according to the mobility information kept in the UE's MM context in the
serving MME.
19.2.1.2 S1 UE Context Management function

In order to support UEs in ECM-CONNECTED, UE contexts need to be managed, i.e. established and released in the
eNodeB and in the EPC to support user individual signalling on S1.
19.2.1.3 Initial Context Setup Function

The Initial Context Setup function supports the establishment of the necessary overall initial UE Context including E-
RAB context, Security context, roaming and access restrictions, UE capability information, Subscriber Profile ID for
RAT/Frequency Priority, UE S1 signalling connection ID, etc. in the eNB to enable fast Idle-to-Active transition.
In addition to the setup of overall initial UE Contexts, Initial Context Setup function also supports the piggy-backing of
the corresponding NAS messages. Initial Context Setup is initiated by the MME.
19.2.1.3a UE Context Modification Function

The UE Context Modification function supports the modification of UE Context in eNB for UEs in active state.
19.2.1.3b UE Context Resume Function

The UE Context Resume function supports the suspension and resumption of an established UE Context and allows
keeping the UE Context in eNB for UEs that were sent to RRC_IDLE and may resume the RRC connection without the
necessity to re-establish the UE Context in the eNB.
19.2.1.4 Mobility Functions for UEs in ECM-CONNECTED

19.2.1.4.1 Intra-LTE Handover
The Intra-LTE-Handover function supports mobility for UEs in ECM-CONNECTED and comprises the preparation,
execution and completion of handover via the X2 and S1 interfaces.
19.2.1.4.2 Inter-3GPP-RAT Handover

The Inter-3GPP-RAT Handover function supports mobility to and from other 3GPP-RATs for UEs in ECM-
CONNECTED and comprises the preparation, execution and completion of handover via the S1 interface.
19.2.1.5 E-RAB Service Management function

The E-RAB Service management function is responsible for establishing, modifying and releasing E-UTRAN resources
for user data transport once a UE context is available in the eNB. The establishment and modification of E-UTRAN
resources is triggered by the MME and requires respective QoS information to be provided to the eNB. The release of
E-UTRAN resources is triggered by the MME either directly or following a request received from the eNB (optional).
For DC when SCG bearer option is applied, the modification of the E-RAB is triggered by the MeNB towards the MME
for the modification of the transport information.
19.2.1.6 NAS Signalling Transport function

The NAS Signalling Transport function provides means to transport or reroute a NAS message (e.g. for NAS mobility
management) for a specific UE on the S1 interface.
3GPP
Release 17 229 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.1.7 NAS Node Selection Function (NNSF)

The interconnection of eNBs or HeNB GW, if deployed, to multiple MME/Serving S-GWs is supported in the E-
UTRAN/EPC architecture. Therefore a NAS node selection function is located in the eNB or the HeNB GW, if
deployed, to determine the MME association of the UE, based on the UE's temporary identifier, which was assigned to
the UE by the CN node (e.g. MME or SGSN).
NOTE: In case the UE's temporary identifier is assigned by the SGSN, respective mapping rules are defined in TS
23.003 [26].
Depending on the actual scenario the NNSF determines the UE's MME association either based its S-TMSI (e.g. at
service request) or based on its GUMMEI and selected PLMN (e.g. at attach or tracking area update in non-registered
TA).
The NNSF in the eNB or HeNB GW, if deployed, may differentiate between a GUMMEI mapped from P-TMSI/RAI
and a native GUMMEI as described in TS 23.401 [17].
This functionality is located in the eNB or in the HeNB GW, if deployed, and enables proper routing via the S1
interface. On S1, no specific procedure corresponds to the NAS Node Selection Function.
eNB selects serving MME based on the DCN-ID provided by the UE and the configuration in eNB if a serving MME
corresponding to the information provided by the UE (e.g. GUTI, etc.) cannot be found by eNB as described in TS
23.401[17].
19.2.1.8 S1-interface management functions

The S1-interface management functions provide
- means to ensure a defined start of S1-interface operation (reset);
- means to handle different versions of application part implementations and protocol errors (error indication).
19.2.1.9 MME Load balancing Function

MME Load balancing is the function which achieves load-balanced MMEs with respect to their processing capacity
within a pool area during system operation. The means to load-balance MMEs is to distribute UEs newly entering the
pool to different MMEs in the MME pool. In addition the MME load balancing function is able to achieve equally
loaded MMEs within a pool area after the introduction of a new MME and after the removal of a MME from the
network.
The support of the MME load balancing function is achieved by indicating the relative MME capacity in the S1 Setup
procedure to all eNBs served by the MMEs of the pool area per MME. In order to support the introduction and/or
removal of MMEs the MME initiated S1 setup update procedure may be used by the operator indicating relative MME
capacity value changes. When there are more than one MME operational in the pool, the indicated relative MME
capacity steers the UE assignment for UEs newly entering the MME pool. When there is only one MME operational in
the pool, UEs may be assigned to this MME.
The MME Load balancing Function is described in detail in TS 23.401 [17].
When DCN are used, the MME Load Balancing function is only performed between MMEs that belong to the same
DCN. The MME Load Balancing for DCN is described in TS 23.401 [17].
19.2.1.10 Location Reporting Function

The Location Reporting function supports the MME requests to the eNB to report the location information of the UE.
19.2.1.11 Warning Message Transmission function

The warning message transmission function provides means to transfer warning message via S1 interface.
19.2.1.12 Overload Function

The overload function comprises the signalling means:
- to indicate to a proportion of eNBs that the serving MME is overloaded;
3GPP
Release 17 230 3GPP TS 36.300 V17.2.0 (2022-09)
- to indicate to the eNBs that the serving MME is back in the "normal operation mode".
19.2.1.13 RAN Information Management Function

The RAN Information Management (RIM) function is a generic mechanism that allows the request and transfer of
information (e.g. GERAN System information) between two RAN nodes via the core network.
19.2.1.14 S1 CDMA2000 Tunnelling function

The S1 CDMA2000 Tunnelling function transports CDMA2000 signalling between UE and CDMA2000 RAT over the
S1 Interface for mobility from E-UTRAN to CDMA2000 HRPD and CDMA2000 1xRTT and for circuit switched
fallback to CDMA2000 1xRTT.
19.2.1.15 Configuration Transfer Function

The Configuration Transfer function is a generic mechanism that allows the request and transfer of RAN configuration
information (e.g. SON information) between two RAN nodes via the core network.
19.2.1.16 LPPa Signalling Transport function

The LPPa Signalling Transport function provides means to transport an LPPa message on the S1 interface.
19.2.1.17 Trace Function

The Trace function provides means to control trace sessions in the eNB. The Trace function also provides means to
control MDT sessions as described in TS 32.422 [30] and TS 37.320 [43] or Application Layer Measurement
Collection, as described in clause 23.16.
19.2.1.18 UE Radio Capability Match

The UE Radio Capability Match function enables the eNB to provide an indication to the MME whether the UE radio
capabilities are compatible with the network configuration for voice continuity.
19.2.1.19 Retrieve UE Information Function

The Retrieve UE Information Function enables the eNB to retrieve the UE information from MME.
19.2.1.20 UE Information Transfer Function

The UE Information Transfer Function enables the MME to send the UE information to the eNB.
19.2.1.21 Report of Secondary RAT data volumes Function

The Report of Secondary RAT data volumes Function enables the eNB to report Secondary RAT usage data
information in case of EN-DC, either with a dedicated procedure or by including Secondary RAT usage data
information in other messages.
19.2.1.22 UE Radio Capability ID Mapping Function

The UE Radio Capability ID Mapping function enables the eNB to request the MME to provide the UE Radio
Capability information that maps to a specific UE Radio Capability ID.
19.2.2 S1 Interface Signalling Procedures

The elementary procedures supported by the S1AP protocol are listed in Table 1 and Table 2 of TS 36.413 [25].
3GPP
Release 17 231 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.0 General
19.2.2.1 Paging procedure
Figure 19.2.2.1-1: Paging procedure
The MME initiates the paging procedure by sending the PAGING message to each eNB with cells belonging to the
tracking area(s) in which the UE is registered. Each eNB can contain cells belonging to different tracking areas,
whereas each cell can only belong to one TA. In case MME initiates the paging procedure with eDRX configuration it
shall include the S-TMSI in the PAGING message.
The paging response back to the MME is initiated on NAS layer and is sent by the eNB based on NAS-level routing
information.
19.2.2.2 S1 UE Context Release procedure

19.2.2.2.0 General
The S1 UE Context Release procedure causes the eNB to remove all UE individual signalling resources and the related
user data transport resources. This procedure is initiated by the EPC and may be triggered on request of the serving
eNB.
19.2.2.2.1 S1 UE Context Release (EPC triggered)
Figure 19.2.2.2.1-1: S1 UE Context Release procedure (EPC triggered)
- The EPC initiates the UE Context Release procedure by sending the S1 UE Context Release Command towards
the E-UTRAN. The eNodeB releases all related signalling and user data transport resources.
- The eNB confirms the S1 UE Context Release activity with the S1 UE Context Release Complete message. The
behaviour of the eNodeB in case of Control Plane CIoT EPS Optimisation is specified in TS 23.401 [11].
- In the course of this procedure the EPC releases all related resources as well, except context resources in the
EPC for mobility management and the default EPS Bearer/E-RAB configuration.
19.2.2.2.2 S1 UE Context Release Request (eNB triggered)

The S1 UE Context Release Request procedure is initiated for E-UTRAN internal reasons and comprises the following
steps:
3GPP
Release 17 232 3GPP TS 36.300 V17.2.0 (2022-09)
- The eNB sends the S1 UE Context Release Request message to the EPC.
- The EPC triggers the EPC initiated UE context release procedure.
Figure 19.2.2.2.2-1: S1 UE Context Release Request procedure (eNB triggered)

and subsequent S1 UE Context Release procedure (EPC triggered)
If the E-UTRAN internal reason is a radio link failure detected in the eNB, the eNB shall wait a sufficient time before
triggering the S1 UE Context Release Request procedure in order to allow the UE to perform the NAS recovery
procedure, see TS 23.401 [17].
19.2.2.3 Initial Context Setup procedure

The Initial Context Setup procedure establishes the necessary overall initial UE context in the eNB in case of an Idle-to
Active transition. The Initial Context Setup procedure is initiated by the MME.
The Initial Context Setup procedure comprises the following steps:
- The MME initiates the Initial Context Setup procedure by sending INITIAL CONTEXT SETUP REQUEST to
the eNB. This message may include general UE Context (e.g. security context, roaming and access restrictions,
UE capability information, UE S1 signalling connection ID, CN assistance information, etc.), E-RAB context
(Serving GW TEID, QoS information, Correlation id i.e. collocated L-GW TEID or GRE key in case of LIPA
support or in case of SIPTO@LN with collocated L-GW support), and may be piggy-backed with the
corresponding NAS messages. When there are multiple NAS messages in the INITIAL CONTEXT SETUP
REQUEST message, the MME shall ensure that the NAS messages in the E-RAB to be Setup List are aligned in
the order of reception from the NAS layer to ensure the in-sequence delivery of the NAS messages.
- Upon receipt of INITIAL CONTEXT SETUP REQUEST, the eNB setup the context of the associated UE, and
perform the necessary RRC signalling towards the UE, e.g. Radio Bearer Setup procedure. When there are
multiple NAS messages to be sent in the RRC message, the order of the NAS messages in the RRC message
shall be kept the same as that in the INITIAL CONTEXT SETUP REQUEST message. If present, the eNB uses
the CN assistance information as defined in TS 23.401[17] and propagates it during inter-eNB mobility.
- The eNB responds with INITIAL CONTEXT SETUP RESPONSE to inform a successful operation, and with
INITIAL CONTEXT SETUP FAILURE to inform an unsuccessful operation.
NOTE: In case of failure, eNB and MME behaviours are not mandated. Both implicit release (local release at
each node) and explicit release (MME-initiated UE Context Release procedure) may in principle be
adopted. The eNB should ensure that no hanging resources remain at the eNB.
3GPP
Release 17 233 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.3-1: Initial Context Setup procedure (highlighted in blue) in Idle-to-Active procedure
19.2.2.3a UE Context Modification procedure

The UE Context Modification procedure enables the MME to modify the UE context in the eNB for UEs in active state.
The UE Context Modification procedure is initiated by the MME.
The UE Context Modification procedure comprises the following steps:
- The MME initiates the UE Context Modification procedure by sending UE CONTEXT MODIFICATION
REQUEST to the eNB to modify the UE context in the eNB for UEs in active state.
- The eNB responds with UE CONTEXT MODIFICATION RESPONSE in case of a successful operation
- If the UE is served by a CSG cell, and is no longer a member of the CSG cell, the eNB may initiate a
handover to another cell. If the UE is not handed over, the eNB should request the release of UE context;
- If the UE is served by a hybrid cell, and is no longer a CSG member of the hybrid cell, the eNB may provide
the QoS for the UE as a non CSG member.
- The eNB responds with UE CONTEXT MODIFICATION FAILURE in case of an unsuccessful operation.
3GPP
Release 17 234 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.3a-1: UE Context Modification procedure
19.2.2.4 E-RAB signalling procedures

19.2.2.4.1 E-RAB Setup procedure
Figure 19.2.2.4.1-1: E-RAB Setup procedure
The E-RAB Setup procedure is initiated by the MME to support:
- Assignment of resources to a dedicated E-RAB.
- Assignment of resources for a default E-RAB.
- Setup of S1 Bearer (on S1) and Data Radio Bearer (on Uu).
The E-RAB Setup procedure comprises the following steps:
- The E-RAB SETUP REQUEST message is sent by the MME to the eNB to setup resources on S1 and Uu for
one or several E-RAB(s). The E-RAB SETUP REQUEST message contains the Serving GW TEID, QoS
indicator(s) and the corresponding NAS message per E-RAB within the E-RAB To Be Setup List. It may also
include the Correlation id i.e. collocated L-GW TEID or GRE key in case of LIPA support or in case of
SIPTO@LN with collocated L-GW support. When there are multiple NAS messages in the E-RAB SETUP
REQUEST message, the MME shall ensure that the NAS messages in the E-RAB to be Setup List are aligned in
the order of reception from the NAS layer to ensure the in-sequence delivery of the NAS messages.
- Upon receipt of the E-RAB SETUP REQUEST message the eNB establishes the Data Radio Bearer(s) (RRC:
Radio Bearer Setup) and resources for S1 Bearers. When there are multiple NAS messages to be sent in the RRC
message, the order of the NAS messages in the RRC message shall be kept the same as that in the E-RAB
SETUP REQUEST message.
3GPP
Release 17 235 3GPP TS 36.300 V17.2.0 (2022-09)
- The eNB responds with a E-RAB SETUP RESPONSE messages to inform whether the setup of resources and
establishment of each E-RAB was successful or unsuccessful, with the E-RAB Setup list (E-RAB ID, eNB
TEID) and the E-RAB Failed to Setup list (E-RAB ID, Cause) The eNB also creates the binding between the S1
bearer(s) (DL/UL TEID) and the Data Radio Bearer(s).
Interactions with UE Context Release Request procedure:
In case of no response from the UE the eNB shall trigger the S1 UE Context Release Request procedure.
19.2.2.4.2 E-RAB Modification procedure
Figure 19.2.2.4.2-1: E-RAB Modification procedure
The E-RAB Modification procedure is initiated by the MME to support the modification of already established E-RAB
configurations:
- Modify of S1 Bearer (on S1) and Radio Bearer (on Uu).
- S-GW relocation without UE mobility.
The EPS Bearer Modification procedure comprises the following steps:
- The E-RAB MODIFY REQUEST message is sent by the MME to the eNB to modify one or several E-RAB(s).
The E-RAB MODIFY REQUEST message contains the QoS indicator(s), and the corresponding NAS message
per E-RAB in the E-RAB To Be Modified List. When there are multiple NAS messages in the E-RAB MODIFY
REQUEST message, the MME shall ensure that the NAS messages in the E-RAB to be Modified List are
aligned in the order of reception from the NAS layer to ensure the in-sequence delivery of the NAS messages.
The transport information for the new S-GW may be included in case of S-GW relocation without UE mobility.
- Upon receipt of the E-RAB MODIFY REQUEST message the eNB modifies the Data Radio Bearer
configuration (RRC procedure to modify the Data Radio bearer). When there are multiple NAS messages to be
sent in the RRC message, the order of the NAS messages in the RRC message shall be kept the same as that in
the E-RAB MODIFY REQUEST message. In case of S-GW relocation without UE mobility, if transport
information for the new S-GW is included, the eNB ignores the included QoS indicator and NAS message and
uses the included transport information for S-GW selection.
- The eNB responds with an E-RAB MODIFY RESPONSE message to inform whether the E-RAB modification
has succeeded or not indicating with the E-RAB Modify list and E-RAB Failed to Modify list. With E-RAB
ID(s) in the E-RAB Modify List or E-RAB Failed to Modify List the eNB identifies the E-RAB(s) successfully
modified or failed to modify.
In case of no response from the UE the eNB shall trigger the S1 UE Context Release Request procedure.
3GPP
Release 17 236 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.4.3 E-RAB Release procedure
Figure 19.2.2.4.3-1: E-RAB Release procedure
The E-RAB Release procedure is initiated by the MME to release resources for the indicated E-RABs.
The E-RAB Release procedure comprises the following steps:
- The E-RAB RELEASE COMMAND message is sent by the MME to the eNB to release resources on S1 and Uu
for one or several E-RAB(s). With the E-RAB ID(s) in the E-RAB To Be Released List contained in E-RAB
RELEASE COMMAND message the MME identifies, the E-RAB(s) to be released.
- Upon receipt of the E-RAB RELEASE COMMAND message the eNB releases the Data Radio Bearers (RRC:
Radio bearer release) and S1 Bearers.
- The eNB responds with an E-RAB RELEASE COMPLETE message containing E-RAB Release list and E-RAB
Failed to Release list. With the E-RAB IDs in the E-RAB Release List/E-RAB Failed to Release List the eNB
identifies the E-RAB(s) successfully released or failed to release.
In case of no response or negative response from the UE or in case the eNB cannot successfully perform the release of
any of the requested bearers, the eNB shall trigger the S1 UE Context Release Request procedure, except if the eNB has
already initiated the procedures associated with X2 Handover.
19.2.2.4.4 E-RAB Release Indication procedure
Figure 19.2.2.4.4-1: E-RAB Release Indication procedure
The E-RAB Release Indication procedure enables the E-UTRAN to send information about released resources for one
or several E-RABs to the MME. The eNB initiates the procedure by sending the E-RAB RELEASE INDICATION
message to the MME. The E-RAB ID(s) in the E-RAB Released List identifies the released E-RAB(s) in the eNB.
3GPP
Release 17 237 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.4.5 E-RAB Modification Indication procedure
Figure 19.2.2.4.5-1: E-RAB Modification Indication procedure
The E-RAB Modification Indication procedure is initiated by the eNB to support the modification of already established
E-RAB configurations and CSG membership verification. The current version of the specification supports the
modification of the transport information and CSG membership verification. This procedure is used for DC if the SCG
bearer option is applied.
If the EPC is able to apply the requested modification, the MME responds with the E-RAB MODIFICATION
CONFIRM.
If the EPC is not able to modify a transport path as requested, the MME responds with the list of E-RABs failed in the
E-RAB MODIFICATION CONFIRM, the MeNB either keeps the previous transport path unchanged and, if applicable,
triggers to release the corresponding SCG bearers, or tears down the corresponding E-RABs.
19.2.2.5 Handover signalling procedures

19.2.2.5.0 General
Handover signalling procedures support both, inter-eNB handover and inter-RAT handover.
Inter-RAT handovers shall be initiated via the S1 interface.
Inter-eNB handovers shall be initiated via the X2 interface except if any of the following conditions are true:
- the source eNB is not an RN and there is no X2 between source and target eNB.
- the source eNB is an RN and there is no X2 between DeNB and the target eNB or between the source RN and
the DeNB.
- the source eNB is an RN and the UE's serving MME is not included in the MME Pool(s) connected with the
target eNB.
- the source eNB has been configured to initiate handover to the particular target eNB via S1 interface in order to
enable the change of an EPC node (MME and/or Serving GW).
- the source eNB has attempted to start the inter-eNB HO via X2 but receives a negative reply from the target eNB
with a specific cause value.
Inter-eNB handovers shall be initiated via the S1 interface, if one of the above conditions applies.
19.2.2.5.1 Handover Preparation procedure

The Handover preparation procedure is initiated by the source eNB if it determines the necessity to initiate the handover
via the S1 interface.
3GPP
Release 17 238 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.5.1-1: Handover preparation procedure
The handover preparation comprises the following steps:
- The HANDOVER REQUIRED message is sent to the MME.
- The source eNB shall ensure that the size of the Source to Target Transparent Container does not exceed the
limits that can be handled by interfaces involved in the handover.
NOTE: For SRVCC handover, the size limit is 2560 octets (see AN-APDU in TS 29.002 [84]). For inter RAT PS
domain handover, the size limit is 4092 octets (see TS 25.412 [85]).
- The handover preparation phase is finished upon the reception of the HANDOVER COMMAND message in the
source eNB, which includes at least radio interface related information (HO Command for the UE), successfully
established E-RAB(s) and E-RAB(s) which failed to setup.
- In case the handover resource allocation is not successful (e.g. no resources are available on the target side) the
MME responds with the HANDOVER PREPARATION FAILURE message instead of the HANDOVER
COMMAND message.
19.2.2.5.2 Handover Resource Allocation procedure

The handover resource allocation comprises the following steps:
Figure 19.2.2.5.2-1: Handover resource allocation procedure
- The MME sends the HANDOVER REQUEST message including the E-RAB(s) which needs to be setup by the
target eNB.
- In the case of a UE performing handover toward an RN, the HANDOVER REQUEST is received by the DeNB,
which shall read the target cell ID from the message, find the target RN corresponding to the target cell ID, and
forward the message toward the target RN.
3GPP
Release 17 239 3GPP TS 36.300 V17.2.0 (2022-09)
- The target eNB responds with the HANDOVER REQUEST ACK message after the required resources for all
accepted E-RABs are allocated. The HANDOVER REQUEST ACK message contains successfully established
E-RAB(s), E-RAB(s) which failed to setup and radio interface related information (HO Command for the UE),
which is later sent transparently via the EPC/CN from the target RAT to the source RAT.
- If no resources are available on the target side, the target eNB responds with the HANDOVER FAILURE
message instead of the HANDOVER REQUEST ACK message.
19.2.2.5.3 Handover Notification procedure

The Handover Completion for S1 initiated handovers comprises the following steps:
- The HANDOVER NOTIFY message is sent by the target eNB to the MME when the UE has successfully been
transferred to the target cell. If the eNB supports SIPTO@LN with stand-alone gateway, the message shall
include the LHN ID.
Figure 19.2.2.5.3-1: Handover completion procedure
19.2.2.5.4 Handover Cancellation

This functionality is located in the source eNB to allow a final decision regarding the outcome of the handover, i.e.
either to proceed or to cancel the handover procedure.
Figure 19.2.2.5.4-1: Handover cancellation procedure
- The source eNB sends a HANDOVER CANCEL message to the MME indicating the reason for the handover
cancellation.
- The MME confirms the reception of the HANDOVER CANCEL message by returning the HANDOVER
CANCEL ACK message.
19.2.2.5.5 Path Switch procedure

The handover completion phase for X2 initiated handovers comprises the following steps:
- The PATH SWITCH message is sent by the target eNB to the MME when the UE has successfully been
transferred to the target cell. The PATH SWITCH message includes the outcome of the resource allocation:
successfully established E-RAB(s). If the eNB supports SIPTO@LN with stand-alone gateway, the message
shall include the LHN ID.
3GPP
Release 17 240 3GPP TS 36.300 V17.2.0 (2022-09)
- The MME responds with the PATH SWITCH ACK message which is sent to the eNB.
- The MME responds with the PATH SWITCH FAILURE message in case a failure occurs in the EPC.
Figure 19.2.2.5.5-1: Path Switch procedure
19.2.2.5.6 Message sequence diagrams

This clause complements TR 25.922 [27] clause 5.1.7.2 regarding the E-UTRAN handling of containers.
Most RRC information is carried by means of containers across interfaces other than Uu. The following sequence
diagrams illustrate which RRC information should be included within these containers used across the different network
interfaces.
NOTE: In order to maintain independence between protocols, no requirements are included in the interface
protocols that are used to transfer the RRC information.
SRVCC (see TS 23.216 [28]) is supported from EUTRAN to UTRAN or GERAN A/Gb mode and from UTRAN or
GERAN A/Gb mode to EUTRAN.
There is no support for interworking between EUTRAN and GERAN Iu-mode and between EUTRAN and GAN.
Figure 19.2.2.5.6-1 and 19.2.2.5.6-1a illustrate the message sequence for handover from GERAN to EUTRAN
procedure:
3GPP
Release 17 241 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.5.6-1. Handover of PS domain service from GERAN A/Gb mode to EUTRAN, normal flow
UE is not requested to provide E-UTRAN UE capabilities while in GERAN. Hence the HANDOVER REQUEST does
not contain E-UTRAN UE capabilities, and the capabilities are fetched by Target eNB from UE after handover is
completed.
3GPP
Release 17 242 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.5.6-1a. Handover of CS domain service from GERAN A/Gb mode to PS-domain service
in EUTRAN, normal flow
UE is not requested to provide E-UTRAN UE capabilities while in GERAN. Hence the HANDOVER REQUEST does
not contain E-UTRAN UE capabilities, and the capabilities are fetched by Target eNB from UE after completed
handover.
Figure 19.2.2.5.6-2 illustrates the message sequence for PS handover and CS handover from UTRAN to EUTRAN
procedure:
3GPP
Release 17 243 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.5.6-2: Handover of PS domain service and handover of CS domain service from UTRAN
to EUTRAN, normal flow
Figure 19.2.2.5.6-3 to Figure 19.2.2.5.6-5 illustrate the message sequence for the handover from EUTRAN to GERAN
A/Gb mode procedure:
3GPP
Release 17 244 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.5.6-3: Handover of CS domain service from EUTRAN to GERAN A/Gb mode, normal flow
3GPP
Release 17 245 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.5.6-4. Handover of PS domain service from EUTRAN to GERAN A/Gb mode, normal flow
3GPP
Release 17 246 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.5.6-5: Handover of CS and PS domain services from EUTRAN to GERAN A/Gb mode,
normal flow
Figure 19.2.2.5.6-6 and Figure 19.2.2.5.6-7 illustrate the message sequence for the handover from EUTRAN to UTRAN
procedure:
3GPP
Release 17 247 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.5.6-6. Handover of PS or CS domain service from EUTRAN to UTRAN, normal flow
3GPP
Release 17 248 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.5.6-7. Handover of PS and CS domain service from EUTRAN to UTRAN, normal flow
19.2.2.5.7 eNB Status Transfer procedure

The purpose of the eNB Status Transfer procedure is to transfer the uplink PDCP SN and HFN receiver status and the
downlink PDCP SN and HFN transmitter status from the eNB to the MME during an S1 handover for each respective
E-RAB for which PDCP SN and HFN status preservation applies.
3GPP
Release 17 249 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.5.7-1: eNB Status Transfer
19.2.2.5.8 MME Status Transfer procedure

The purpose of the MME Status Transfer procedure is to transfer the uplink PDCP SN and HFN receiver status and the
downlink PDCP SN and HFN transmitter status from the MME to the eNB during an S1 handover for each respective
E-RAB for which PDCP SN and HFN status preservation applies.
Figure 19.2.2.5.8-1: MME Status Transfer
19.2.2.6 NAS transport procedures

A NAS signalling message is transferred on the S1 interface in both directions. The procedures providing this
functionality are:
- Initial UE Message procedure (eNB initiated);
- Uplink NAS transport procedure (eNB initiated);
- Downlink NAS transport procedure (MME initiated);
- Downlink NAS non delivery indication procedure (eNB initiated)
- Downlink NAS delivery indication procedure; (eNB initiated);
- Reroute NAS Request procedure.
i) Initial UE Message procedure
3GPP
Release 17 250 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.6-1: Initial UE Message procedure
- The INITIAL UE MESSAGE procedure is initiated by the eNB by sending the INITIAL UE MESSAGE
message to the MME. The INITIAL UE MESSAGE contains a NAS message (e.g. Service Request), the UE
signalling reference ID and other S1 addressing information. If the eNB is a HeNB supporting LIPA, the
message shall include the HeNB collocated L-GW IP address to enable the establishment of a LIPA PDN
connection. If the eNB supports SIPTO@LN with collocated L-GW, the message shall include the collocated L-
GW IP address to enable the establishment of a SIPTO@LN PDN connection. If the eNB supports SIPTO@LN
with stand-alone gateway, the message shall include the LHN ID. In case of UE access to a CSG cell the
INITIAL UE MESSAGE contains the CSG id of the cell. In case of UE access to a hybrid cell the INITIAL UE
MESSAGE contains the CSG id and Access Mode of the cell.
ii) Uplink NAS Transport procedure (eNB initiated)
Figure 19.2.2.6-2: Uplink NAS Transport procedure
- The Uplink NAS Transport procedure is initiated by the eNB by sending the UPLINK NAS TRANSPORT
message to the MME. The UPLINK NAS TRANSPORT message contains a NAS message, UE identification
and other S1 related addressing information. If the eNB is a HeNB supporting LIPA, the message shall include
the HeNB collocated L-GW IP address to enable the establishment of a LIPA PDN connection. If the eNB
supports SIPTO@LN with collocated L-GW, the message shall include the collocated L-GW IP address to
enable the establishment of a SIPTO@LN PDN connection. If the eNB supports SIPTO@LN with stand-alone
gateway, the message shall include the LHN ID.
iii) Downlink NAS Transport procedure (MME initiated)
3GPP
Release 17 251 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.6-3: Downlink NAS Transport procedure
- The Downlink NAS Transport procedure is initiated by the MME by sending the DOWNLINK NAS
TRANSPORT message to the eNB. The DOWNLINK NAS TRANSPORT contains a NAS message, UE
identification and other S1 related addressing information and may contain the UE Radio Capability information.
In addition a request to indicate the successful delivery of the Downlink NAS PDU to the UE may be included in
the DOWNLINK NAS TRANSPORT message.
iv) Downlink NAS non delivery indication procedure
Figure 19.2.2.6-4: Downlink NAS Non Delivery Indication procedure
- When the eNB decides to not start the delivery of a NAS message that has been received from MME, it shall
report the non-delivery of this NAS message by sending a DOWNLINK NAS NON DELIVERY INDICATION
message to the MME including the non-delivered NAS message and an appropriate cause value.
v) Downlink NAS delivery indication procedure
Figure 19.2.2.6-5: Downlink NAS Delivery Indication procedure
- The eNB may be requested by the MME to provide an indication whether the Downlink NAS PDU has been
successfully delivered to the UE. The eNB then triggers the Downlink NAS Delivery Indication procedure per
downlink NAS PDU provided in a DOWNLINK NAS TRANSPORT as specified in TS 23.401 [17].
3GPP
Release 17 252 3GPP TS 36.300 V17.2.0 (2022-09)
vi) Reroute NAS Request procedure
Figure 19.2.2.6-6: Reroute NAS Request procedure
The Reroute NAS Request procedure is used to reroute a NAS message (and there by a UE) to another MME when
DCNs are used.
The procedure is initiated by the MME sending the REROUTE NAS REQUEST message. Upon receiving the
REROUTE NAS REQUEST message, the eNB selects a MME in the indicated DCN and sends the INITIAL UE
MESSAGE message to the new selected MME as described in TS 23.401 [17]. In case a UE-associated logical S1-
connection was established between the MME and the eNB, upon sending (respectively receiving) the REROUTE NAS
REQUEST message the MME (respectively eNB) shall locally remove the UE-associated logical S1-connection.
19.2.2.7 S1 interface Management procedures

The purpose of the Reset procedure is to re-initialize the peer entity or part of the peer entity after node setup and after a
failure event occurred. This procedure is initiated by both the eNB and MME.
19.2.2.7.1a eNB initiated Reset procedure
Figure 19.2.2.7.1a-1: eNB initiated Reset procedure
- The eNB triggers the RESET message to indicate that an initialisation in the MME is required. The MME
releases the corresponding references and resources.
- Afterwards the MME sends the RESET ACK message to confirm that the resources and references are cleared.
3GPP
Release 17 253 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.7.1b MME initiated Reset procedure
Figure 19.2.2.7.1b-1: MME initiated Reset procedure
- The MME triggers the RESET message to indicate that an initialisation in the eNB is required. The eNB releases
the corresponding references and resources.
- Afterwards the eNB sends the RESET ACK message to confirm that the resources and references are cleared.
19.2.2.7.2 Error Indication functions and procedures

The Error Indication procedure is initiated by the eNB and the MME, to report detected errors in one incoming
message, if an appropriate failure message cannot be reported to the sending entity.
19.2.2.7.2a eNB initiated error indication
Figure 19.2.2.7.2a-1: eNB initiated Error Indication procedure
The eNB sends the ERROR INDICATION message to report the peer entity which kind of error occurs.
19.2.2.7.2b MME initiated error indication
Figure 19.2.2.7.2b-1: MME initiated Error Indication procedure
The MME sends the ERROR INDICATION message to report the peer entity which kind of error occurs.
19.2.2.8 S1 Setup procedure

The S1 Setup procedure is used to exchange configured data which is required in the MME and in the eNB respectively
to ensure a proper interoperation. The S1 Setup procedure is triggered by the eNB. The S1 Setup procedure is the first
S1AP procedure which will be executed.
3GPP
Release 17 254 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.8-1: S1 Setup procedure
- The eNB initiates the S1 Setup procedure by sending the S1 SETUP REQUEST message including supported
TAs and broadcasted PLMNs to the MME.
- In the successful case the MME responds with the S1 SETUP RESPONSE message which includes served
PLMNs as well as a relative MME capacity indicator to achieve load balanced MMEs in the pool area.
The MME and the eNB may agree at the S1 Setup procedure that UE-related contexts and related signalling
connection that have been existing before the S1 Setup shall not be affected. The MME or eNB or both may
trigger an S1AP Reset procedure for any UE-related context and related signalling connection for UEs which
could not be kept in ECM_CONNECTED and RRC_CONNECTED or for UEs for which the MME or the eNB
decided to remove the UE-related context and related signalling connection. If either the MME and the eNB do
not agree to keep the UE-related contexts (if any), then they are removed and all related signalling connections
are erased.
- If the MME cannot accept the S1 Setup Request the MME responds with the S1 SETUP FAILURE message
indicating the reason of the denial. The MME optionally indicates in the S1 SETUP FAILURE message when
the eNB is allowed to re-initiate the S1 Setup Request procedure towards the same MME again.
19.2.2.9 eNB Configuration Update procedure

The eNB Configuration Update procedure is used to provide updated configured data in eNB. The eNB Configuration
Update procedure is triggered by the eNB.
Figure 19.2.2.9-1: eNB Configuration Update procedure
- The eNB initiates the eNB Configuration Update procedure by sending the ENB CONFIGURATION UPDATE
message including updated configured data like supported TAs and broadcasted PLMNs to the MME. In case
one or more supported TA(s) needs to be updated, the eNB shall provide the whole list of TA(s), including those
which has not been changed, in the ENB CONFIGURATION UPDATE message.
- The MME responds with the ENB CONFIGURATION UPDATE ACKNOWLEDGE message to acknowledge
that the provided configuration data are successfully updated.
- The MME shall overwrite and store the received configuration data which are included in the ENB
CONFIGURATION UPDATE message. Configuration data which has not been included in the ENB
3GPP
Release 17 255 3GPP TS 36.300 V17.2.0 (2022-09)
CONFIGURATION UPDATE message are interpreted by the MME as still valid. For the provided TA(s) the
MME shall overwrite the whole list of supported TA(s).
- In case the MME cannot accept the received configuration updates the MME shall respond with the ENB
CONFIGURATION UPDATE FAILURE message including an appropriate cause value to indicate the reason of
the denial. The MME optionally indicates in the ENB CONFIGURATION UPDATE FAILURE message when
the eNB is allowed to re-initiate the eNB Configuration Update procedure towards the same MME again. For the
unsuccessful update case the eNB and the MME shall continue with the existing configuration data.
19.2.2.9a eNB Configuration Transfer procedure

The eNB Configuration Transfer procedure is initiated by the eNB to request and/or transfer RAN configuration
information via the core network.
Figure 19.2.2.9a-1: eNB Configuration Transfer procedure
The eNB Configuration Transfer procedure is initiated by the eNB by sending the eNB CONFIGURATION
TRANSFER message to the MME. The eNB CONFIGURATION TRANSFER message contains RAN configuration
information (e.g. SON information) and other relevant information such as the routing address which identifies the final
RAN destination node.
19.2.2.10 MME Configuration Update procedure

The MME Configuration Update procedure is used to provide updated configured data and changes of the relative
MME capacity values in the MME. The MME Configuration Update procedure is triggered by the MME.
Figure 19.2.2.10-1: MME Configuration Update procedure
- The MME initiates the MME Configuration Update procedure by sending the MME CONFIGURATION
UPDATE message including updated configured data like served PLMNs and changes of the relative MME
capacity values to the eNB.
- The eNB responds with the MME CONFIGURATION UPDATE ACKNOWLEDGE message to acknowledge
that the provided configuration data and the relative MME capacity values are successfully updated.
- The eNB shall overwrite and store the received configuration data and relative MME capacity values which are
included in the MME CONFIGURATION UPDATE message. Configuration data which has not been included
in the MME CONFIGURATION UPDATE message are interpreted by the eNB as still valid.
3GPP
Release 17 256 3GPP TS 36.300 V17.2.0 (2022-09)
- In case the eNB cannot accept the received configuration updates the eNB shall respond with the MME
CONFIGURATION UPDATE FAILURE message including an appropriate cause value to indicate the reason of
the denial. The eNB optionally indicates in the MME CONFIGURATION UPDATE FAILURE message when
the MME is allowed to re-initiate the MME Configuration Update procedure towards the same eNB again. For
the unsuccessful update case the eNB and the MME shall continue with the existing configuration data and
relative MME capacity values.
19.2.2.10a MME Configuration Transfer procedure

The MME Configuration Transfer procedure is initiated by the MME to request and/or transfer RAN configuration
information to the eNB.
Figure 19.2.2.10a-1: MME Configuration Transfer procedure
The MME Configuration Transfer procedure is initiated by the MME by sending the MME CONFIGURATION
TRANSFER message to the eNB. The MME CONFIGURATION TRANSFER message contains RAN configuration
information (e.g. SON information) and other relevant information.
19.2.2.11 Location Reporting procedures

19.2.2.11.0 General
The Location Reporting procedures provide the means to report the current location of a specific UE.
The procedures providing this function are:
- Location Reporting Control procedure;
- Location Report procedure;
- Location Report Failure Indication procedure.
If DC is configured for a specific UE, the location reported refers to the cell served by the MeNB. If EN-DC is
configured for a specific UE, the location reported refers to the cell served by the MeNB and, if requested, the PSCell at
the en-gNB.
NOTE: The following S1AP procedures are able to provide location information without the reporting being
triggered by the Location Reporting Control procedure:
S1 UE Context Release, UE Context Suspend, E-RAB Release, E-RAB Release Indication, Path Switch,
Handover Notification, Initial UE Message, Uplink NAS Transport, Secondary RAT Data Usage Report.
3GPP
Release 17 257 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.11.1 Location Reporting Control procedure
Figure 19.2.2.11.1-1: Location Reporting Control procedure
The Location Reporting Control procedure is initiated by the MME sending the LOCATION REPORTING CONTROL
to the eNB to request the current location information, e.g. Cell ID, of a specific UE, and how the information shall be
reported, e.g. direct report, report every cell change. The Location Reporting Control procedure is also used to terminate
reporting on cell change.
If the Location Reporting Control procedure fails, e.g. due to an interaction with an initiated handover then the eNB
shall indicate the failure using the Location Report Failure Indication procedure.
If the Location Reporting Control procedure is on going for a specific UE and the eNB received an UE CONTEXT
RELEASE COMMAND message from MME this specific UE then the eNB shall terminate the on-going Location
Reporting.
19.2.2.11.2 Location Report procedure
Figure 19.2.2.11.2-1: Location Report procedure
The Location Report procedure is initiated by the eNB by sending the LOCATION REPORT to the MME to report the
current location information of a specific UE as a standalone report, or every time UE changes cell.
19.2.2.11.3 Location Report Failure Indication procedure
Figure 19.2.2.11.3-1: Location Report Failure Indication procedure
The Location Report Failure Indication procedure is initiated by the eNB by sending the LOCATION REPORT
FAILURE INDICATION to the MME to indicate that the Location Report Control procedure has failed due to e.g. UE
has performed inter-eNB handover.
3GPP
Release 17 258 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.12 Overload procedure

19.2.2.12.1 Overload Start procedure
The Overload Start procedure is used by the MME to indicate to a proportion of eNBs to which the MME has an S1
interface connection that the MME is overloaded. The Overload Start procedure is used to provide an indication of
which type of RRC connections needs to be rejected/permitted only.
Figure 19.2.2.12.1-1 Overload Start procedure
If the OVERLOAD START message contains a list of GUMMEIs, the eNB shall select the new RRC connections to be
rejected based on this list.
The eNB may also trigger EAB as specified in TS 23.401 [17] clause 4.3.7.4.1 and TS 23.251 [54] clause 4.6.
19.2.2.12.2 Overload Stop procedure

The Overload Stop procedure is used by the MME to indicate the concerned eNB(s) that the MME is no longer
overloaded.
Figure 19.2.2.12.2-1: Overload Stop procedure
If the OVERLOAD STOP message contains a list of GUMMEIs, the eNB shall stop rejecting the new RRC connections
corresponding to each received GUMMEI value if applicable.
The eNB may also stop ongoing EAB actions.
3GPP
Release 17 259 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.13 Write-Replace Warning procedure
Figure 19.2.2.13.1-1: Write-Replace Warning procedure
The Write-Replace Warning procedure is used to start the broadcasting of a PWS warning message.
ETWS is an example of PWS warning system using this procedure where one message at a time can be delivered over
the radio.
CMAS is another example of PWS warning system using this procedure which allows the broadcast of multiple
concurrent warning messages over the radio.
The procedure is initiated by the MME by sending WRITE-REPLACE WARNING REQUEST message containing at
least the Message Identifier, Warning Area list, information on how the broadcast should be performed, and the
contents of the warning message to be broadcast.
The eNB responds with WRITE-REPLACE WARNING RESPONSE message to acknowledge that the requested PWS
warning message broadcast was initiated.
ETWS and CMAS are independent services and ETWS and CMAS messages are differentiated over S1 in order to
allow different handling.
In the case of ETWS, the Write-Replace Warning procedure can also be used to overwrite the ongoing broadcasting of
an ETWS warning message.
19.2.2.14 eNB Direct Information Transfer procedure

The eNB Direct Information Transfer procedure is initiated by the eNB to request and transfer information to the core
network.
Figure 19.2.2.14-1: eNB Direct Information Transfer procedure
The eNB Direct Information Transfer procedure is initiated by the eNB by sending the eNB DIRECT INFORMATION
TRANSFER message to the MME. The eNB DIRECT INFORMATION TRANSFER message contains RIM
information and RIM routing address which identifies the final RAN destination node.
3GPP
Release 17 260 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.15 MME Direct Information Transfer procedure

The MME Direct Information Transfer procedure is initiated by the MME to request and transfer information to the
eNB.
Figure 19.2.2.15-1: MME Direct Information Transfer procedure
The MME Direct Information Transfer procedure is initiated by the MME by sending the MME DIRECT
INFORMATION TRANSFER message to the eNB. The MME DIRECT INFORMATION TRANSFER message
contains RIM information.
19.2.2.16 S1 CDMA2000 Tunnelling procedures

The S1 CDMA2000 Tunnelling procedures carry CDMA2000 signalling messages between UE and CDMA2000 RAT
over the S1 Interface. This includes signalling for pre-registration and handover preparation for optimized mobility
from E-UTRAN to CDMA2000 HRPD, signalling for handover preparation for mobility from E-UTRAN to
CDMA2000 1xRTT and signalling to support CS fallback to CDMA2000 1xRTT for mobile originated and mobile
terminated CS domain services. The CDMA2000 messages are tunnelled transparently to the eNB and MME, however,
additional information may be sent along with the tunnelled CDMA2000 message to assist the eNodeB and MME in the
Tunnelling procedure. The procedures providing this functionality are:
- Downlink S1 CDMA2000 Tunnelling procedure;
- Uplink S1 CDMA2000 Tunnelling procedure.
19.2.2.16.1 Downlink S1 CDMA2000 Tunnelling procedure

The MME sends the DOWNLINK S1 CDMA2000 TUNNELLING message to the eNB to forward a CDMA2000
message towards an UE for which a logical S1 connection exists (see Figure 19.2.2.16.1-1 below).
Figure 19.2.2.16.1-1: Downlink S1 CDMA2000 Tunnelling procedure
19.2.2.16.2 Uplink S1 CDMA2000 Tunnelling procedure

The eNB sends the UPLINK S1 CDMA2000 TUNNELLING message to the MME to forward a CDMA2000 message
towards the CDMA2000 RAT (HRPD or 1xRTT) as depicted on Figure 19.2.2.16.2-1 below.
3GPP
Release 17 261 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.16.2-1: Uplink S1 CDMA2000 Tunnelling procedure
19.2.2.17 Kill procedure
Figure 19.2.2.17-1: Kill procedure
The Kill procedure is used to stop the broadcasting of a PWS warning message or all PWS warning messages.
CMAS is an example of warning system using this procedure. The ETWS warning system doesn't use this procedure.
The procedure is initiated by the MME sending the KILL REQUEST message containing at least the Message Identifier
and serial number of the message to be killed and the Warning Area List where it shall be killed.
The eNB responds with a KILL RESPONSE message to acknowledge that the requested PWS message broadcast
delivery has actually been stopped.
19.2.2.18 LPPa Transport procedures

19.2.2.18.0 General
An LPPa signalling message is transferred on the S1 interface in both directions. The procedures providing this
functionality are:
- Downlink UE Associated LPPa Transport procedure;
- Uplink UE Associated LPPa Transport procedure;
- Downlink Non UE Associated LPPa Transport procedure;
- Uplink Non UE Associated LPPa Transport procedure.
The UE-associated signalling is used to support E-CID positioning of a specific UE. The non-UE associated signalling
is used to obtain assistance data from an eNodeB to support OTDOA positioning for any UE.
3GPP
Release 17 262 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.18.1 Downlink UE Associated LPPa Transport procedure

The Downlink UE Associated LPPa Transport procedure is initiated by the MME by sending the DOWNLINK UE
ASSOCIATED LPPA TRANSPORT message to the eNB. The DOWNLINK UE ASSOCIATED LPPA TRANSPORT
contains an LPPa message.
Figure 19.2.2.18.1-1: Downlink UE Associated LPPa Transport procedure
19.2.2.18.2 Uplink UE Associated LPPa Transport procedure

The Uplink UE Associated LPPa Transport procedure is initiated by the eNB by sending the UPLINK UE
ASSOCIATED LPPA TRANSPORT message to the MME. The UPLINK UE ASSOCIATED LPPA TRANSPORT
message contains a LPPa message.
Figure 19.2.2.18.2-1: Uplink UE Associated LPPa Transport procedure
19.2.2.18.3 Downlink Non UE Associated LPPa Transport procedure

The Downlink Non UE Associated LPPa Transport procedure is initiated by the MME by sending the DOWNLINK
NON UE ASSOCIATED LPPA TRANSPORT message to the eNB. The DOWNLINK NON UE ASSOCIATED LPPA
TRANSPORT contains a LPPa message.
Figure 19.2.2.18.3-1: Downlink Non UE Associated LPPa Transport procedure
3GPP
Release 17 263 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.18.4 Uplink Non UE Associated LPPa Transport procedure

The Uplink Non UE Associated LPPa Transport procedure is initiated by the eNB by sending the UPLINK NON UE
ASSOCIATED LPPA TRANSPORT message to the MME. The UPLINK NON UE ASSOCIATED LPPA
TRANSPORT message contains an LPPa message.
Figure 19.2.2.18.4-1: Uplink Non UE Associated LPPa Transport procedure
19.2.2.19 Trace procedures

19.2.2.19.0 General
The Trace procedures provide the means to control trace sessions and MDT sessions in the eNB for both signalling and
management triggered sessions.
The procedures providing this function are:
- Trace Start procedure;
- Trace Failure Indication procedure;
- Deactivate Trace procedure;
- Cell Traffic Trace procedure.
19.2.2.19.1 Trace Start procedure
Figure 19.2.2.19.1-1: Trace Start procedure
The Trace Start procedure is initiated by the MME by sending the TRACE START message to the eNB in order to
request the initiation of a trace session for a specific UE in ECM_CONNECTED mode or request the initiation of an
MDT session for a specific UE.
3GPP
Release 17 264 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.19.2 Trace Failure Indication procedure
Figure 19.2.2.19.2-1: Trace Failure Indication procedure
The Trace Failure Indication procedure is initiated by the eNB by sending the TRACE FAILURE INDICATION
message to the MME to report that a Trace Start procedure or a Deactivate Trace procedure has failed due to an
interaction with a handover procedure.
19.2.2.19.3 Deactivate Trace procedure
Figure 19.2.2.19.3-1: Deactivate Trace procedure
The Deactivate Trace procedure is initiated by the MME by sending the DEACTIVATE TRACE message to the eNB to
request the termination of an ongoing trace session.
19.2.2.19.4 Cell Traffic Trace procedure
Figure 19.2.2.19.4-1: Cell Traffic Trace procedure
The Cell Traffic Trace procedure is initiated by the eNB by sending the CELL TRAFFIC TRACE message to the MME
to report the allocated Trace Recording Session Reference and the Trace Reference to MME. This procedure is used to
support management triggered trace.
19.2.2.20 UE Capability Info Indication procedure

The purpose of the UE Capability Info Indication procedure is to enable the eNB to provide to the MME UE capability-
related information, as described in TS 23.401 [17].
3GPP
Release 17 265 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 19.2.2.20-1: UE Capability Info Indication procedure
19.2.2.21 UE Radio Capability Match procedure
Figure 19.2.2.21-1: UE Radio Capability Match procedure
The UE Radio Capability Match procedure is initiated by the MME to request an indication on whether the UE Radio
capabilities match the network configuration for voice continuity.
19.2.2.22 PWS Restart Indication procedure
Figure 19.2.2.22-1: PWS Restart Indication procedure
The PWS Restart Indication procedure is used to inform the MME that PWS information for some cells or all cells of
the eNB are available for reloading from the CBC if needed.
The procedure is initiated by the eNB sending the PWS RESTART INDICATION message.
3GPP
Release 17 266 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.23 PWS Failure Indication procedure
Figure 19.2.2.23-1: PWS Failure Indication procedure
The PWS Failure Indication procedure is used to inform the MME that ongoing PWS operation has failed for one or
more cells.
The procedure is initiated by the eNB sending the PWS FAILURE INDICATION message.
19.2.2.24 UE Context Modification Indication procedure
Figure 19.2.2.24-1: UE Context Modification Indication procedure
The UE Context Modification Indication procedure enables the eNB to request the modifications of the UE Context.
In the current version of the specification, the procedure is only used for CSG membership verification for Dual
Connectivity.
This procedure is initiated by the eNB.
19.2.2.25 Connection Establishment Indication procedure
Figure 19.2.2.25-1: Connection Establishment Indication procedure
3GPP
Release 17 267 3GPP TS 36.300 V17.2.0 (2022-09)
The Connection Establishment Indication procedure is used in case of CIoT EPS Optimisation and it enables the MME
to provide information to the eNB to complete the establishment of the UE-associated logical S1-connection and/or to
trigger the eNB to obtain and report UE Radio Capability.
The MME may trigger Connection Establishment Indication procedure either
- after receiving INITIAL UE MESSAGE message, if the MME has no NAS PDU to send in DL in case of
Control Plane CIoT EPS Optimisation, or
- after receiving an eNB CP RELOCATION INDICATION message in case of Control Plane CIoT EPS
Optimisation, or
- when deciding to trigger the eNB to obtain and report UE Radio Capability.
The UE Radio Capability may be provided from the MME to the eNB in this procedure. If the UE radio capability is not
included, this may trigger the eNB to request the UE Radio Capability from the UE and to provide it to the MME in the
UE CAPABILITY INFO INDICATION message.
NAS-level security information may be provided from the MME to the eNB in this procedure in case the UE-associated
logical S1-signalling connection is established for a NB-IOT UE using Control Plane CIoT EPS optimisations after the
MME receives an eNB CP RELOCATION INDICATION message from the eNB, as described in TS 33.401 [22].
This procedure is initiated by the MME.
19.2.2.26 UE Context Suspend procedure
Figure 19.2.2.26-1: UE Context Suspend procedure
The UE Context Suspend procedure is initiated by the eNB to request the MME to suspend the UE context and the
related bearer contexts in the EPC after which the eNB sends the UE to RRC_IDLE.
After successful completion of the UE Context Suspend procedure the UE-associated signalling connection is said to be
suspended. The eNB and the MME keep all context data necessary to resume the UE-associated signalling connection
so that there is no need to exchange information that has been provided to the respective node already before the UE-
associated signalling connection has been suspended. Only the following S1AP procedures are allowed to take place on
a suspendend UE-associated signalling connection:
- UE Context Resume;
- S1AP UE Context Release (eNB and MME initiated);
3GPP
Release 17 268 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.27 UE Context Resume procedure
Figure 19.2.2.27-1: UE Context Resume procedure
The UE Context Resume procedure is initiated by the eNB to indicate that the UE has resumed the RRC connection and
to request the MME to resume the UE context and related bearer contexts in the EPC. In case the UE context cannot be
resumed in the EPC this is indicated by the MME by sending the UE CONTEXT RESUME FAILURE message.
19.2.2.28 Retrieve UE Information procedure
Figure 19.2.2.28: Retrieve UE Information procedure
The Retrieve UE Information procedure is initiated by the eNB to request the UE information (i.e. QoS parameters, UE
capability) from MME for NB-IoT UE using Control Plane CIoT EPS Optimisation, as specified in TS 23.401 [17].
19.2.2.29 UE Information Transfer procedure
Figure 19.2.2.29: UE Information Transfer procedure
3GPP
Release 17 269 3GPP TS 36.300 V17.2.0 (2022-09)
The UE Information Transfer procedure is initiated by the MME to send the UE information (i.e. QoS parameters, UE
capability) to the eNB for NB-IoT UE using Control Plane CIoT EPS Optimisation, as specified in TS 23.401 [17].
19.2.2.30 eNB CP Relocation Indication

The eNB CP Relocation Indication procedure is only applicable for NB-IOT UEs using Control Plane CIoT EPS
optimisations. The purpose of the eNB CP Relocation Indication procedure is to request the MME to authenticate the
UE's re-establishment request as described in TS 33.401 [22], and initiate the establishment of the UE-associated logical
S1-connection after the UE has initiated a RRC Re-establishment procedure in an eNB.
When the eNB receives the RRCConnectionReestablishmentRequest message, it triggers the eNB CP Relocation
Indication procedure including NAS-level security information received from the UE. If the MME authenticates the
request, it initiates the Connection Establishment Indication procedure including NAS-level security information to be
sent to the UE in the RRCConnectionReestablishment message. In case the MME cannot authenticate the UE's request,
the CONNECTION ESTABLISHMENT INDICATION message does not contain security information, and the eNB
shall fail the RRC Re-establishment. In case of authentication failure, the eNB and the MME should locally release the
allocated S1 resources, if any.
Figure 19.2.2.30-1: eNB CP Relocation Indication procedure (highlighted in blue)
Interactions with the MME CP Relocation and UE Context Release procedures:
In case of successful UE authentication, the MME initiates the UE Context Release procedure to release the UE's old
S1-connection. The MME may initiate the MME CP Relocation procedure before the release procedure in order to
trigger the return of non-delivered NAS PDUs to the MME.
19.2.2.31 MME CP Relocation Indication

The MME CP Relocation Indication procedure is only applicable for UEs using Control Plane CIoT EPS optimisations.
The purpose of the MME CP Relocation Indication procedure is to inform the previously serving eNB that the UE's
connection is to be relocated to a new eNB.
Upon reception of the MME CP RELOCATION INDICATION message, the old eNB shall terminate the delivery of
downlink NAS PDUs towards the UE, and initiate NAS Non Delivery Indication procedure(s) to report the non-delivery
of any NAS PDUs previously received from the MME.
Figure 19.2.2.31-1: MME CP Relocation Indication procedure (highlighted in blue).
3GPP
Release 17 270 3GPP TS 36.300 V17.2.0 (2022-09)
19.2.2.32 Secondary RAT Report

The Secondary RAT Report procedure is used by the eNB during mobility procedures or for periodic reporting to
provide information on the used NR resources during EN-DC.
Figure 19.2.2.32-1: Secondary RAT Report Procedure.
19.2.2.33 UE Radio Capability ID Mapping procedure

The UE Radio Capability ID Mapping procedure is initiated by the eNB to request the UE Radio Capability information
that maps to a specific capability ID from the MME.
Figure 19.2.2.33-1: UE radio capability ID mapping procedure
The UE Radio Capability ID Mapping procedure comprises the following steps:
- The eNB initiates the UE Radio Capability ID Mapping procedure by sending UE RADIO CAPABILITY ID
MAPPING REQUEST to the MME.
- The MME responds with UE RADIO CAPABILITY ID MAPPING RESPONSE including the UE radio
capability information.
20 X2 Interface
20.1 User Plane
The X2 user plane interface (X2-U) is defined between eNBs. The X2-U interface provides non guaranteed delivery of
user plane PDUs. The user plane protocol stack on the X2 interface is shown in Figure 20.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.
The X2-U interface protocol stack is identical to the S1-U protocol stack.
For DC, if X2-U user data bearers are associated with E-RABs for which the split bearer option is configured, GTP-U
conveys PDCP PDUs in uplink and downlink and a RAN Container containing flow control information. The RAN
Container is carried in the "RAN Container" field of the GTP-U extension header.
3GPP
Release 17 271 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.1-1: X2 Interface User Plane (eNB-eNB)
20.1.1 Flow Control Functions

The Flow Control function is applied when an E-RAB is configured for the split bearer option and only for DL i.e. the
flow control information is provided only by the SeNB to the MeNB for the MeNB to control the downlink user data
flow to the SeNB. The flow control function is further described in TS 36.425 [61].
20.2 Control Plane

20.2.0 X2-CP Overview
The X2 control plane interface (X2-CP) is defined between two neighbour eNBs. The control plane protocol stack of
the X2 interface is shown on Figure 20.2-1 below. The transport network layer is built on SCTP on top of IP. The
application layer signalling protocol is referred to as X2-AP (X2 Application Protocol).
Figure 20.2-1: X2 Interface Control Plane
A single SCTP association per X2-C interface instance shall be used with one pair of stream identifiers for X2-C
common procedures. Only a few pairs of stream identifiers should be used for X2-C dedicated procedures.
Source-eNB communication context identifiers that are assigned by the source-eNB for X2-C dedicated procedures, and
target-eNB communication context identifiers that are assigned by the target-eNB for X2-C dedicated procedures, shall
be used to distinguish UE specific X2-C signalling transport bearers. The communication context identifiers are
conveyed in the respective X2AP messages.
RNs terminate X2-AP. In this case, there is one X2 interface relation between the RN and the DeNB.
3GPP
Release 17 272 3GPP TS 36.300 V17.2.0 (2022-09)
20.2.1 X2-CP Functions

The X2AP protocol supports the following functions:
- Intra LTE-Access-System Mobility Support for UE in ECM-CONNECTED:
- Context transfer from source eNB to target eNB;
- Control of user plane tunnels between source eNB and target eNB;
- Handover cancellation.
- Support of DC for UE in ECM-CONNECTED:
- Establishment, Modification and Release of a UE context at the SeNB;
- Control of user plane tunnels between MeNB and SeNB for a specific UE for split bearer and data
forwarding;
- Provision of the TNL information of the S1 user plane tunnels for SCG bearers.
- Support of EN-DC for UE in ECM-CONNECTED:
- Establishment, Modification and Release of a UE context at the SgNB;
- Control of user plane tunnels between MeNB and SgNB for a specific UE for split bearer, SCG split bearer
and data forwarding;
- Provision of the TNL information of the S1 user plane tunnels for SCG bearers and SCG split bearers.
- Support of inter-eNB UE Context Resume:
- Retrieval of UE context for a UE which attempts to resume its RRC connection in an eNB different from
where the RRC connection was suspended.
- Load Management;
- General X2 management and error handling functions:
- Error indication;
- Setting up the X2;
- Resetting the X2;
- Updating the X2 configuration data;
- X2 Release;
- X2AP Message Transfer;
- Registration;
- X2 Removal.
- Mobility failure event notification and information exchange in support of handover settings negotiation;
- Energy Saving. This function allows decreasing energy consumption by enabling indication of cell
activation/deactivation.
- Support of cell resource coordination between eNB and en-gNB.
- Support of UE Radio Capability ID Mapping between eNB and en-gNB.
3GPP
Release 17 273 3GPP TS 36.300 V17.2.0 (2022-09)
20.2.2 X2-CP Procedures

20.2.2.0 Overview of X2-CP procedures
The elementary procedures supported by the X2AP protocol are listed in Table 8.1-1 and Table 8.1-2 of TS 36.423 [42].
20.2.2.1 Handover Preparation procedure

The Handover preparation procedure is initiated by the source eNB if it determines the necessity to initiate the handover
via the X2 interface.
Figure 20.2.2.1-1: Handover Preparation procedure
The source eNB sends a HANDOVER REQUEST to the target eNB including the bearers to be setup by the target
ENB.
The handover preparation phase is finished upon the reception of the HANDOVER REQUEST ACKNOWLEDGE
message in the source eNB, which includes at least radio interface related information (HO Command for the UE),
successfully established E-RAB(s) and failed established E-RAB(s).
In case the handover resource allocation is not successful (e.g. no resources are available on the target side) the target
eNB responds with the HANDOVER PREPARATION FAILURE message instead of the HANDOVER REQUEST
ACKNOWLEDGE message.
If eNB received NAS message from MME during X2 handover procedure, it shall be acted as specified in clause
19.2.2.6.
20.2.2.2 Handover Cancel procedure

This functionality is located in the source eNB to allow cancellation of the handover procedure.
Figure 20.2.2.2-1: Handover Cancel procedure
3GPP
Release 17 274 3GPP TS 36.300 V17.2.0 (2022-09)
The source eNB sends a HANDOVER CANCEL message to the target eNB indicating the reason for the handover
cancellation.
20.2.2.2a SeNB Addition Preparation procedure

The SeNB Addition Preparation procedure is initiated by the MeNB to request the SeNB to allocate resources for DC
operation for a specific UE.
Figure 20.2.2.2a-1: SeNB Addition Preparation procedure
The MeNB sends an SENB ADDITION REQUEST message to the SeNB including the bearers for which DC shall be
configured.
In case resource allocation at the SeNB has been performed successfully, the SeNB responds with an SENB
ADDITION REQUEST ACKNOWLEDGE message, which includes radio interface related information, successfully
established and failed to be established bearers for DC.
In case the SeNB addition is not successful (e.g. no resources are available on the SeNB side) the SeNB responds with
the SENB ADDITION REJECT message instead.
20.2.2.2b SeNB Reconfiguration Completion procedure

The SeNB Reconfiguration Complete procedure is initiated by the MeNB to indicate to the SeNB that the UE has been
successfully configured with the requested SeNB radio configuration.
Figure 20.2.2.2b-1: SeNB Reconfiguration Completion procedure
The same procedure is also used by the MeNB to indicate that the MeNB finally decided to not request the UE to apply
the radio configuration requested by the SeNB.
The SeNB Reconfiguration Completion procedure is used in the course of an SeNB Addition and in the course of an
MeNB initiated SeNB Modification if the MeNB initiated SeNB Modification requires signalling towards the UE.
20.2.2.2c MeNB initiated SeNB Modification Preparation procedure

The MeNB initiated SeNB Modification Preparation procedure is initiated by the MeNB to request the SeNB to modify
resources allocated for a specific UE at the SeNB.
3GPP
Release 17 275 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.2c-1: MeNB initiated SeNB Modification Preparation procedure
The MeNB initiated SeNB Modification does not necessarily result in communication towards the UE.
In case resource modification at the SeNB has been performed successfully, the SeNB responds with an SENB
MODICATION REQUEST ACKNOWLEDGE message.
In case the SeNB modification is not successful (e.g. no resources are available on the SeNB side), the SeNB responds
with the SENB MODIFICATION REQUEST REJECT message instead.
20.2.2.2d SeNB initiated SeNB Modification procedure

The SeNB initiated SeNB Modification Preparation procedure is initiated to request the modification of the UE context
at the SeNB.
Figure 20.2.2.2d-1: SeNB initiated SeNB Modification procedure
The SeNB initiated SeNB Modification does not necessarily result in communication towards the UE.
If the MeNB decides to not follow the SeNBs request it replies with an SENB MODIFICATION REFUSE message.
20.2.2.2e MeNB initiated SeNB Release procedure

The MeNB initiated SeNB Release procedure is triggered by the MeNB to initiate the release of the resources for a
specific UE at the SeNB.
3GPP
Release 17 276 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.2e-1: MeNB initiated SeNB Release procedure
20.2.2.2f SeNB initiated SeNB Release procedure

The SeNB initiated SeNB Release procedure is triggered by the SeNB to initiate the release of the resources for a
specific UE at the SeNB.
Figure 20.2.2.2f-1: SeNB initiated SeNB Release procedure
20.2.2.2g SeNB Counter Check procedure

The SeNB Counter Check procedure is initiated by the SeNB to request the MeNB to execute a counter check
procedure to verify the value of the PDCP COUNTs associated with SCG bearers established in the SeNB.
Figure 20.2.2.2g-1: SeNB Counter Check procedure
20.2.2.3 UE Context Release procedure

At handover, the UE Context Release procedure is initiated by the target eNB to signal to the source eNB that resources
for the handed over UE context can be released.
For DC, the UE Context Release procedure is initiated by the MeNB to finally release the resources at the SeNB for the
specific UE once either the SeNB initiated or the MeNB initiated SeNB Release Procedure has been performed.
3GPP
Release 17 277 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.3-1: UE Context Release procedure for handover and DC.
At handover, by sending UE CONTEXT RELEASE the target eNB informs the source eNB of Handover success and
triggers the release of resources.
Figure 20.2.2.3-2: UE Context Release procedure for EN-DC.
For EN-DC, the UE Context Release procedure is initiated by the MeNB to finally release the UE context at the SgNB
for the specific UE once either the SgNB initiated or the MeNB initiated SgNB Release Procedure has been performed.
20.2.2.4 SN Status Transfer procedure

The purpose of the SN Status Transfer procedure is to transfer the uplink PDCP SN and HFN receiver status and the
downlink PDCP SN and HFN transmitter status from the source to the target eNB during an X2 handover, or between
MeNB and SgNB involved in EN-DC, or between the old and the new eNB at RRC connection re-establishment for
each respective E-RAB for which PDCP SN and HFN status preservation applies.
Figure 20.2.2.4-1: SN Status Transfer procedure for handover.
3GPP
Release 17 278 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.4-2: MeNB-initiated SN Status Transfer procedure for EN-DC.
Figure 20.2.2.4-3: SgNB-initiated SN Status Transfer procedure for EN-DC.
Figure 20.2.2.4-4: SN Status Transfer procedure for RRC Connection Re-establishment.
20.2.2.5 Error Indication procedure

The Error Indication procedure is initiated by an eNB or an en-gNB to signal to a peer E-UTRAN node an error
situation in a received message, provided it cannot be reported by an appropriate failure message.
3GPP
Release 17 279 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.5-1: Error Indication procedure between eNB and eNB
Figure 20.2.2.5-2: en-gNB-initiated Error Indication procedure between en-gNB and eNB
Figure 20.2.2.5-3: eNB-initiated Error Indication procedure between eNB and en-gNB
20.2.2.6 Load Indication procedure

Inter-cell interference coordination in E-UTRAN is performed through the X2 interface. In case of variation in the
interference conditions, the eNB signals the new condition to its neighbour eNBs e.g. the neighbour eNBs for which an
X2 interface is configured due to mobility reasons.
When the time-domain inter-cell interference coordination is used to mitigate interference, the eNB signals its almost
blank subframe (ABS) patterns to its neighbour eNBs, so that the receiving eNB can utilize the ABS of the sending eNB
with less interference.
NOTE: A typical use case of the time-domain solution of inter-cell interference coordination is the one where an
eNB providing broader coverage and therefore being more capacity constrained determines its ABS
patterns and indicates them to eNBs, providing smaller coverage residing in its area.
When inter-eNB CoMP is used, the eNB signals the CoMP hypotheses and associated benefit metrics to its neighbour
eNB(s), so that the receiving eNB may take them into account for RRM.
3GPP
Release 17 280 3GPP TS 36.300 V17.2.0 (2022-09)
The Load Indication procedure is used to transfer interference co-ordination information between neighbouring eNBs
managing intra-frequency cells, and adjacent frequency TDD cells.
Figure 20.2.2.6-1: Load Indication procedure
20.2.2.7 X2 Setup procedure

The purpose of the X2 Setup procedure is to exchange application level data needed for two eNBs to interoperate
correctly over the X2 interface.
Figure 20.2.2.7-1: X2 Setup procedure
20.2.2.8 eNB Configuration Update procedure

The purpose of the eNB Configuration Update procedure is to update application level configuration data needed for
two eNBs to interoperate correctly over the X2 interface.
Figure 20.2.2.8-1: eNB Configuration Update procedure
3GPP
Release 17 281 3GPP TS 36.300 V17.2.0 (2022-09)
20.2.2.9 Reset procedure

The Reset procedure is initiated by an eNB or an en-gNB to align the resources with a peer E-UTRAN node in the event
of an abnormal failure. The procedure resets the whole X2 interface.
Figure 20.2.2.9-1: Reset procedure between eNBs
Figure 20.2.2.9-2: eNB-initiated Reset procedure between eNB and en-gNB
Figure 20.2.2.9-3: en-gNB-initiated Reset procedure between en-gNB and eNB
20.2.2.10 Resource Status Reporting Initiation procedure

The Resource Status Reporting Initiation procedure is used by an eNB to request measurements from another eNB.
3GPP
Release 17 282 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.10-1: Resource Status Reporting Initiation procedure
20.2.2.11 Resource Status Reporting procedure

The Resource Status Reporting procedure reports measurement results requested by another eNB.
Figure 20.2.2.11-1: Resource Status Reporting procedure
20.2.2.12 Radio Link Failure Indication procedure

The purpose of the Radio Link Failure Indication procedure is to enable mobility robustness and radio link failure
recovery improvement in E-UTRAN by passing information about a failure event over the X2 interface.
When a re-establishment request is received or a connection failure reported after RRC connection setup or an incoming
successful handover, the eNB uses the cell identifiers provided by the UE to identify the potentially previous serving
cell/eNB. The eNB that received the information about the failure sends a RLF INDICATION message to the concerned
eNB(s). The previously serving eNB may then match the correct context, or use the information available in the RLF
Report, if included in the RLF INDICATION message, to analyze the possible root cause of the failure. If the previous
serving eNB matches the correct context, it may also trigger the Handover Preparation procedure towards the eNB that
initiated the Radio Link Failure Indication procedure.
NOTE: When deciding whether to trigger the Handover preparation procedure the previously serving eNB may
take into account a number of factors, e.g. the CSFB indicator in the UE Context.
Figure 20.2.2.12-1: Radio Link Failure Indication procedure
3GPP
Release 17 283 3GPP TS 36.300 V17.2.0 (2022-09)
20.2.2.13 Handover Report procedure

The purpose of the Handover Report procedure is to enable mobility robustness improvement in E-UTRAN.
The Handover Report procedure is used to pass information connected to the analysis of an RLF which occurred shortly
after a successful handover.
The eNB where the RLF occurred (original target eNB) sends a HANDOVER REPORT message to the original source
eNB, identifying the source cell, the target cell, and the cell where re-establishment took place.
The Handover Report procedure is also used to pass information connected to potential inter-RAT ping-pong cases. The
eNB that detected the potential ping-pong cases sends a HANDOVER REPORT message to the source eNB of the first
inter-RAT handover, identifying the source and the target cells of the first inter-RAT handover, and the target cell of the
second inter-RAT handover.
Figure 20.2.2.13-1: Handover Report procedure
20.2.2.14 Mobility Settings Change procedure

The purpose of the MOBILITY SETTINGS CHANGE procedure is to enable an eNB to send a MOBILITY CHANGE
REQUEST message to a peer eNB to negotiate the handover trigger settings.
Figure 20.2.2.14-1: Mobility Settings Change procedure
20.2.2.15 Cell Activation procedure

The purpose of the Cell Activation procedure is to enable an eNB to send a CELL ACTIVATION REQUEST message
to a peer eNB to request the re-activation of one or more cells, controlled by the peer eNB and which had been
previously indicated as dormant.
3GPP
Release 17 284 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.15-1: Cell Activation procedure
20.2.2.16 X2 Release procedure

The purpose of the X2 Release procedure is to enable an X2 GW to inform the relevant (H)eNBs that the signalling (i.e.
SCTP) connection to a peer (H)eNB is unavailable.
Figure 20.2.2.16-1: X2 Release procedure
20.2.2.17 X2AP Message Transfer procedure

The purpose of the X2AP Message Transfer procedure is to allow indirect transport of an X2AP message (except the
X2AP MESSAGE TRANSFER message) between two (H)eNBs through an X2 GW, and to allow an (H)eNB to
register with an X2 GW.
Figure 20.2.2.17-1: X2AP Message Transfer procedure
20.2.2.18 X2 Removal procedure

The purpose of the X2 Removal procedure is to perform the removal of X2 connectivity between two eNBs in a
controlled manner. If the procedure is successful, the receiving eNB responds with the X2 REMOVAL RESPONSE
message, after which both eNBs remove the X2 signalling connection between them and may release all associated
resources. In case the receiving eNB cannot remove the X2 signalling connection (e.g. because of an ongoing procedure
and/or due to local configuration), it responds with the X2 REMOVAL FAILURE message. The initiating eNB may
include an X2 removal threshold for removal of a signalling connection.
3GPP
Release 17 285 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.18-1: X2 Removal procedure
20.2.2.19 Retrieve UE Context

The purpose of the Retrieve UE Context procedure is to retrieve the UE context for a UE which attempts to resume its
RRC connection in an eNB (the new eNB) different from the eNB (the old eNB) where the RRC connection was
suspended or for a UE which attempts to re-establish its RRC connection in an eNB (the new eNB) different from the
eNB (the old eNB) where the RRC connection failed, e.g. due to RLF.
If the new eNB is able to identify the old eNB based on the Resume ID or based on the Physical Cell ID received from
the UE, it triggers the Retrieve UE Context procedure towards the old eNB.
If the old eNB is able to match the UE context with the Resume ID or with the ShortMAC-I, C-RNTI, failed PCI and
new E-UTRAN Cell Identifier included in the RETRIEVE UE CONTEXT REQUEST message it responds with the
RETRIEVE UE CONTEXT RESPONSE message containing UE context information.
Upon resumption of the UE Context in the new eNB, the new eNB resumes/re-establishes the RRC connection and
performs the S1-AP Path Switch procedure to establish a S1 UE associated signalling connection to the serving MME
and to request the MME to resume the UE context and related bearer contexts in the EPC (for resuming UEs) and
update the downlink path (for resuming and re-establishing UEs). In case of re-establishment of the RRC connection,
the new eNB may provide a data forwarding address per re-established E-RAB to the old eNB by means of the X2-AP
Data Forwarding Address Indication procedure if DL forwarding was proposed by the old eNB. After the S1-AP Path
Switch procedure the new eNB triggers release of the UE Context at the old eNB by means of the X2-AP UE Context
Release procedure.
Figure 20.2.2.19-1: Retrieve UE Context procedure (highlighted in blue) for cases of UE context
resumption. Successful case
3GPP
Release 17 286 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.19-1A: Retrieve UE Context procedure (highlighted in blue) for cases of UE re-
establishment. Successful case
In case the old eNB cannot find UE Context Information corresponding to the Resume ID or to the ShortMAC-I, C-
RNTI, failed PCI and new E-UTRAN Cell Identifier received from the UE, it responds with the RETRIEVE UE
CONTEXT FAILURE message and the new eNB fails the RRC connection resume/re-establishment procedure as
Figure 20.2.2.19-2: Retrieve UE Context procedure (highlighted in blue) for cases of UE context
resumption. Unsuccessful case
Figure 20.2.2.19-3: Retrieve UE Context procedure (highlighted in blue) for cases of UE re-
establishment. Unsuccessful case
3GPP
Release 17 287 3GPP TS 36.300 V17.2.0 (2022-09)
20.2.2.20 SgNB Addition Preparation procedure

The SgNB Addition Preparation procedure is initiated by the MeNB to request the SgNB to allocate resources for EN-
DC operation for a specific UE.
Figure 20.2.2.20-1: SgNB Addition Preparation procedure
The MeNB sends an SGNB ADDITION REQUEST message to the SgNB including the bearers for which EN-DC shall
be configured.
In case resource allocation at the SgNB has been performed successfully, the SgNB responds with an SGNB
ADDITION REQUEST ACKNOWLEDGE message, which includes radio interface related information, successfully
established and failed to be established bearers for EN-DC.
In case the SgNB Addition is not successful (e.g. no resources are available on the SgNB side) the SgNB responds with
the SGNB ADDITION REJECT message instead.
20.2.2.21 SgNB Reconfiguration Completion procedure

The SgNB Reconfiguration Complete procedure is initiated by the MeNB to indicate to the SgNB that the UE has been
successfully configured with the requested SgNB radio configuration.
Figure 20.2.2.21-1: SgNB Reconfiguration Completion procedure
The same procedure is also used by the MeNB to indicate that the MeNB finally decided to not request the UE to apply
the radio configuration requested by the SgNB.
The SgNB Reconfiguration Completion procedure is used in the course of an SgNB Addition and in the course of an
MeNB initiated SgNB Modification if the MeNB initiated SgNB Modification requires signalling towards the UE.
20.2.2.22 MeNB initiated SgNB Modification Preparation procedure

The MeNB initiated SgNB Modification Preparation procedure is initiated by the MeNB to request the SgNB to modify
resources allocated for a specific UE at the SgNB.
3GPP
Release 17 288 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.22-1: MeNB initiated SgNB Modification Preparation procedure
The MeNB initiated SgNB Modification does not necessarily result in communication towards the UE.
In case resource modification at the SgNB has been performed successfully, the SgNB responds with an SGNB
MODICATION REQUEST ACKNOWLEDGE message.
In case the SgNB modification is not successful (e.g. no resources are available on the SgNB side), the SgNB responds
with the SGNB MODIFICATION REQUEST REJECT message instead.
20.2.2.23 SgNB initiated SgNB Modification Preparation procedure

The SgNB initiated SgNB Modification Preparation procedure is initiated to request the modification of the UE context
at the SgNB.
Figure 20.2.2.23-1: SgNB initiated SgNB Modification procedure
The SgNB initiated SgNB Modification does not necessarily result in communication towards the UE.
If the MeNB decides to not follow the SgNBs request it replies with an SGNB MODIFICATION REFUSE message.
20.2.2.24 MeNB initiated SgNB Release procedure

The MeNB initiated SgNB Release procedure is triggered by the MeNB to initiate the release of the resources for a
specific UE at the SgNB.
Figure 20.2.2.24-1: MeNB initiated SgNB Release procedure
3GPP
Release 17 289 3GPP TS 36.300 V17.2.0 (2022-09)
20.2.2.25 SgNB initiated SgNB Release procedure

The SgNB initiated SgNB Release procedure is triggered by the SgNB to initiate the release of the resources for a
specific UE at the SgNB.
Figure 20.2.2.25-1: SgNB initiated SgNB Release procedure
20.2.2.26 SgNB initiated SgNB Change procedure

The SgNB initiated SgNB Change procedure is triggered by the SgNB to initiate the transfer of the resources for a
specific UE at the SgNB to another en-gNB.
Figure 20.2.2.26-1: SgNB initiated SgNB Change procedure
In case the transfer of the UE context to the target en-gNB has been performed successfully, the MeNB responds with
an SGNB CHANGE CONFIRM message.
If the MeNB is not able to transfer the UE context to the target en-gNB, it replies with an SGNB CHANGE FAILURE
message.
20.2.2.27 SgNB Counter Check procedure

The SgNB Counter Check procedure is initiated by the SgNB to request the MeNB to execute a counter check
procedure to verify the value of the PDCP COUNTs associated with SCG bearers or SCG split bearers.
Figure 20.2.2.27-1: SgNB Counter Check procedure
3GPP
Release 17 290 3GPP TS 36.300 V17.2.0 (2022-09)
20.2.2.28 EN-DC X2 Setup procedure

The purpose of the EN-DC X2 Setup procedure is to exchange application level data needed for an eNB and an en-gNB
to interoperate correctly over the X2 interface in EN-DC case. The procedure is triggered by the eNB or by the en-gNB.
Figure 20.2.2.28-1: EN-DC X2 Setup procedure triggered by the eNB.
Figure 20.2.2.28-2: EN-DC X2 Setup procedure triggered by the en-gNB.
20.2.2.29 EN-DC Configuration Update procedure

The purpose of the EN-DC Configuration Update procedure is to update application level configuration data needed for
an eNB and an en-gNB to interoperate correctly over the X2 interface in EN-DC case. The procedure is triggered by the
eNB or by the en-gNB.
Figure 20.2.2.29-1: EN-DC Configuration Update procedure triggered by the eNB.
3GPP
Release 17 291 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.29-2: EN-DC Configuration Update procedure triggered by the en-gNB.
20.2.2.30 EN-DC Cell Activation procedure

The purpose of the EN-DC Cell Activation procedure is to enable an eNB to request the re-activation of one or more
NR cells controlled by an en-gNB, and which had been previously indicated as dormant.
eNB en-gNB
X2-AP: EN-DC CELL ACTIVATION REQUEST
X2-AP: EN-DC CELL ACTIVATION RESPONSE
X2-AP: EN-DC CELL ACTIVATION FAILURE
Figure 20.2.2.30-1: EN-DC Cell Activation procedure
20.2.2.31 E-UTRA - NR Cell Resource Coordination procedure

The purpose of the E-UTRA - NR Cell Resource Coordination procedure is to exchange information needed for an eNB
and an en-gNB to coordinate cell resources when E-UTRA and NR cells are deployed on overlapping carrier. The
procedure is triggered by the eNB or by the en-gNB.
3GPP
Release 17 292 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.31-1: E-UTRA - NR Cell Resource Coordination procedure triggered by the eNB.
Figure 20.2.2.31-2: E-UTRA - NR Cell Resource Coordination procedure triggered by the en-gNB.
20.2.2.32 Partial Reset procedure for EN-DC

The Partial Reset procedure for EN-DC is triggered by the en-gNB or the MeNB to initiate the release of the resources
for a list of UEs with the EN-DC configuration.
Figure 20.2.2.32-1: Partial Reset procedure for EN-DC (initiated at the en-gNB)
3GPP
Release 17 293 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 20.2.2.32-2: Partial Reset procedure for EN-DC (initiated at the MeNB)
20.2.2.33 UE Radio Capability ID Mapping procedure

The purpose of the UE Radio Capability ID Mapping Request procedure is to enable the en-gNB to request the MeNB
to provide the UE Radio Capability information that maps to a specific UE Radio Capability ID.
Figure 20.2.2.33-1: UE Radio Capability ID Mapping procedure
20.2.3 Void
21 Void
21.1 Void
21.2 Void
21.3 Void
22 Support for self-configuration and self-optimisation

22.1 Definitions
This concept includes several different functions from eNB activation to radio parameter tuning. Figure 22.1-1 is a basic
framework for all self-configuration /self-optimisation functions.
Self-configuration process is defined as the process where newly deployed nodes are configured by automatic
installation procedures to get the necessary basic configuration for system operation.
This process works in pre-operational state. Pre-operational state is understood as the state from when the eNB is
powered up and has backbone connectivity until the RF transmitter is switched on.
As described in Figure 21.1, functions handled in the pre-operational state like:
- Basic Setup; and
- Initial Radio Configuration.
are covered by the Self Configuration process.
3GPP
Release 17 294 3GPP TS 36.300 V17.2.0 (2022-09)
Self-optimisation process is defined as the process where UE & eNB measurements and performance measurements
are used to auto-tune the network.
This process works in operational state. Operational state is understood as the state where the RF interface is
additionally switched on.
As described in Figure 21.1, functions handled in the operational state like:
- Optimisation / Adaptation
are covered by the Self Optimisation process.
Figure 22.1-1: Ramifications of Self-Configuration /Self-Optimisation functionality
22.2 UE Support for self-configuration and self-optimisation

UE shall support measurements and procedures which can be used for self-configuration and self-optimisation of the E-
UTRAN system.
- UE shall support measurements and measurement reporting to support self-optimisation of the E-UTRAN
system. Measurements and reports used for the normal system operation, should be used as input for the self-
optimisation process as far as possible.
- The network is able to configure the measurements and the reporting for self-optimisation support by RRC
signalling messages.
22.3 Self-configuration
22.3.1 Dynamic configuration of the S1-MME interface
22.3.1.1 Prerequisites
The following prerequisites are assumed:
3GPP
Release 17 295 3GPP TS 36.300 V17.2.0 (2022-09)
- An initial remote IP end point to be used for SCTP initialisation is provided to the eNB for each MME. The eNB
may be in pre-operational or operational state when this occurs.
How the eNB gets the remote IP end point(s) and its own IP address are outside the scope of this specification.
22.3.1.2 SCTP initialization

For each MME the eNodeB tries to initialize a SCTP association as described in IETF RFC 4960 [8], using a known
initial remote IP Endpoint as the starting point, until SCTP connectivity is established.
NOTE: The eNB may use different source and/or destination IP end point(s) if the SCTP establishment towards
one IP endpoint fails.
22.3.1.3 Application layer initialization

Once SCTP connectivity has been established, the eNodeB and MME shall exchange application level configuration
data over the S1-MME application protocol with the S1 Setup Procedure, which is needed for these two nodes to
interwork correctly on the S1 interface.
- The eNodeB provides the relevant configuration information to the MME, which includes list of supported
TA(s), etc.
- The MME provides the relevant configuration information to the eNodeB, which includes PLMN ID, etc.
- When the application layer initialization is successfully concluded, the dynamic configuration procedure is
completed and the S1-MME interface is operational.
In addition, an eNB which has become X2-C connected to an en-gNB provides the connected en-gNB's Global en-gNB
Identifier to the MME.
22.3.2 Dynamic Configuration of the X2 interface

- An initial local IP end point to be used for SCTP initialisation is provided to the eNB/en-gNB.
- For EN-DC, the en-gNB is provided with an initial remote IP end point of an eNB to be used for SCTP
initialisation.

For candidate eNB/en-gNB the eNB/en-gNB tries to initialize a SCTP association as described in IETF RFC 4960 [8],
using a known initial remote IP Endpoint as the starting point, until SCTP connectivity is established.
NOTE: The eNB/en-gNB may use different source and/or destination IP end point(s) if the SCTP establishment
towards one IP endpoint fails.

In the below, one of the involved eNBs (initiating or candidate eNB) may instead be an en-gNB.
- Once SCTP connectivity has been established, the eNB and its candidate peer eNB are in a position to exchange
application level configuration data over the X2 application protocol needed for the two nodes to interwork
correctly on the X2 interface.
- The eNB provides the relevant configuration information to the candidate eNB, which includes served cell
information, etc.
- The candidate eNB provides the relevant configuration information to the initiating eNB, which includes
served cell information, etc.
completed and the X2 interface is operational.
3GPP
Release 17 296 3GPP TS 36.300 V17.2.0 (2022-09)
The following principles apply for the exchange of served cell information:
- eNBs shall keep neighbouring eNBs and en-gNBs updated with the complete list of served E-UTRA cells while
the X2 interface is operational.
- en-gNBs shall inform neighbouring eNBs of the full or partial list of served NR served cell during application
layer initialization, and keep neighbouring eNBs updated with the full or partial list of served NR served cells,
or, if requested by the eNB, with a limited list of served NR cells, while the X2 interface is operational.
22.3.2a Automatic Neighbour Relation Function

The purpose of the Automatic Neighbour Relation (ANR) function is to relieve the operator from the burden of
manually managing Neighbour Cell Relations (NCRs). Figure 22.3.2a-1 shows ANR and its environment:
Figure 22.3.2a-1: Interaction between eNB and O&M due to ANR
The ANR function resides in the eNB and manages the conceptual Neighbour Cell Relation Table (NCRT). Located
within ANR, the Neighbour Detection Function finds new neighbours and adds them to the NCRT. ANR also contains
the Neighbour Removal Function which removes outdated NCRs. The Neighbour Detection Function and the
Neighbour Removal Function are implementation specific.
A Neighbour Cell Relation (NCR) in the context of ANR is defined as follows:
An existing Neighbour Relation from a source cell to a target cell means that eNB controlling the source cell:
3GPP
Release 17 297 3GPP TS 36.300 V17.2.0 (2022-09)
a) Knows the ECGI/CGI and PCI of the target cell.
b) Has an entry in the Neighbour Cell Relation Table for the source cell identifying the target cell.
c) Has the attributes in this Neighbour Cell Relation Table entry defined, either by O&M or set to default values.
For each cell that the eNB has, the eNB keeps a NCRT, see Figure 22.3.2a-1. For each NCR, the NCRT contains the
Target Cell Identifier (TCI), which identifies the target cell. For E-UTRAN, the TCI corresponds to the E-UTAN Cell
Global Identifier (ECGI) and Physical Cell Identifier (PCI) of the target cell. Furthermore, each NCR has three
attributes, the NoRemove, the NoHO and the NoX2 attribute. These attributes have the following definitions:
- No Remove: If checked, the eNB shall not remove the Neighbour Cell Relation from the NRT.
- No HO: If checked, the Neighbour Cell Relation shall not be used by the eNB for handover reasons.
- No X2: If checked, the Neighbour Relation shall not use an X2 interface in order to initiate procedures towards
the eNB parenting the target cell.
Neighbour Cell Relations are cell-to-cell relations, while an X2 link is set up between two eNBs. Neighbour Cell
Relations are unidirectional, while an X2 link is bidirectional.
NOTE: The neighbour information exchange, which occurs during the X2 Setup procedure or in the eNB
Configuration Update procedure, may be used for ANR purpose.
The ANR function also allows O&M to manage the NCRT. O&M can add and delete NCRs. It can also change the
attributes of the NCRT. The O&M system is informed about changes in the NCRT.
22.3.3 Intra-LTE/frequency Automatic Neighbour Relation Function

The ANR (Automatic Neighbour Relation) function relies on cells broadcasting their identity on global level, E-
UTRAN Cell Global Identifier (ECGI).
Figure 22.3.3-1: Automatic Neighbour Relation Function
The function works as follows:
The eNB serving cell A has an ANR function. As a part of the normal call procedure, the eNB instructs each UE to
perform measurements on neighbour cells. The eNB may use different policies for instructing the UE to do
measurements, and when to report them to the eNB. This measurement procedure is as specified in TS 36.331 [16].
3GPP
Release 17 298 3GPP TS 36.300 V17.2.0 (2022-09)
1. The UE sends a measurement report regarding cell B. This report contains Cell B's PCI, but not its ECGI.
When the eNB receives a UE measurement report containing the PCI, the following sequence may be used.
2. The eNB instructs the UE, using the newly discovered PCI as parameter, to read the ECGI, the TAC and all
available PLMN ID(s) of the related neighbour cell. To do so, the eNB may need to schedule appropriate idle
periods to allow the UE to read the ECGI from the broadcast channel of the detected neighbour cell. How the UE
reads the ECGI is specified in TS 36.331 [16].
3. When the UE has found out the new cell's ECGI, the UE reports the detected ECGI to the serving cell eNB. In
addition, the UE reports the tracking area code and all PLMN IDs that have been detected. If the detected cell is
a CSG or hybrid cell, the UE also reports the CSG ID to the serving cell eNB.
4. The eNB decides to add this neighbour relation, and can use PCI and ECGI to:
a Lookup a transport layer address to the new eNB.
b Update the Neighbour Relation List.
c If needed, setup a new X2 interface towards this eNB. The setup of the X2 interface is described in clause
22.3.2.
NOTE: The eNB may differentiate the open access HeNB from the other types of (H)eNB by the PCI
configuration or ECGI configuration.
22.3.4 Inter-RAT/Inter-frequency Automatic Neighbour Relation Function
Figure 22.3.4-1: Automatic Neighbour Relation Function in case of e.g. UTRAN detected cell
For Inter-RAT and Inter-Frequency ANR, each cell contains an Inter Frequency Search list. This list contains all
frequencies that shall be searched.
For Inter-RAT cells, the NoX2 attribute in the NCRT is absent, as X2 is only defined for E-UTRAN.
3GPP
Release 17 299 3GPP TS 36.300 V17.2.0 (2022-09)
The eNB serving cell A has an ANR function. During connected mode, the eNB can instruct a UE to perform
measurements and detect cells on other RATs/frequencies. The eNB may use different policies for instructing the UE to
do measurements, and when to report them to the eNB.
1 The eNB instructs a UE to look for neighbour cells in the target RATs/frequencies. To do so the eNB may need
to schedule appropriate idle periods to allow the UE to scan all cells in the target RATs/frequencies.
2 The UE reports the PCI of the detected cells in the target RATs/frequencies. The PCI is defined by the carrier
frequency and the Primary Scrambling Code (PSC) in case of UTRAN FDD cell, by the carrier frequency and
the cell parameter ID in case of UTRAN TDD cell, by the Band Indicator + BSIC + BCCH ARFCN in case of
GERAN cell, by the PN Offset in case of CDMA2000 cell, and by the NR PSS/SSS in case of NR cell.
When the eNB receives UE reports containing PCIs of cell(s) the following sequence may be used.
3 The eNB instructs the UE, using the newly discovered PCI as parameter, to read the CGI and the RAC of the
detected neighbour cell in case of GERAN detected cells, CGI, LAC, RAC and all broadcasted PLMN-ID(s) in
case of UTRAN detected cells, CGI in case of CDMA2000 detected cells, and NCGI(s), TAC(s), RANAC(s), all
available PLMN ID(s), gNB identity length(s) and all available NR frequency band(s) in case of NR detected
cells. For the Inter-frequency case, the eNB instructs the UE, using the newly discovered PCI as parameter, to
read the ECGI, TAC and all available PLMN ID(s) of the inter-frequency detected cell. The UE ignores
transmissions from the serving cell while finding the requested information transmitted in the broadcast channel
of the detected inter-system/inter-frequency neighbour cell. To do so, the eNB may need to schedule appropriate
idle periods to allow the UE to read the requested information from the broadcast channel of the detected inter-
RAT/inter-frequency neighbour cell.
4 After the UE has read the requested information in the new cell, it reports the detected CGI and RAC (in case of
GERAN detected cells) or CGI, LAC, RAC and all broadcasted PLMN-ID(s) (in case of UTRAN detected cells)
or CGI (in case of CDMA2000 detected cells) or all broadcast NCGI(s), TAC(s), RANAC(s), PLMN-ID(s),
gNB identity length(s) and NR frequency band(s) (in case of NR detected cells) to the serving cell eNB. In the
inter-RAT NR case, the UE may report noSIB1 indication in case the detected NR cell does not broadcast SIB1,
as described in TS 36.331 [16]. In the inter-frequency case, the UE reports the ECGI, the, tracking area code and
all PLMN-ID(s) that have been detected. If the detected cell is a CSG or hybrid cell, the UE also reports the CSG
ID to the serving cell eNB.
5 The eNB updates its inter-RAT/inter-frequency Neighbour Cell Relation Table.
In the inter-frequency case and if needed, the eNB can use the PCI and ECGI for a new X2 interface setup towards this
eNB. The setup of the X2 interface is described in clause 22.3.2.
NOTE: The eNB may differentiate the open access HeNB from the other types of (H)eNB by the PCI
configuration or ECGI configuration.
22.3.4a Automatic Neighbour Relation Function towards NR

The ANR function described in clause 22.3.2 and 22.3.4 applies towards NR with enhancements as follows:
An existing NCR from a source E-UTRA cell to a target NR cell means that eNB controlling the source cell knows the
NCGI and PCI of the target cell.
If an NCR from a source E-UTRA cell to a target E-UTRA cell exists, the eNB controlling the source cell has
information whether the target E-UTRA cell has an existing NCR to a target NR cell for performing EN-DC.
An X2 link may be set up between eNB and en-gNB. The NoRemove, the NoHO and the NoX2 attributes apply when
the en-gNB parents the target cell. Each NCR has the following additional attribute:
- No EN-DC: If checked, the Neighbour Cell Relation shall not be used by the eNB for EN-DC.
Each E-UTRA cell contains an Inter Frequency Search list. This list contains all frequencies that shall be searched.
The PCI is defined by the frequency of the SSB associated with SIB1, and NR-PCI.
22.3.4b Automatic Neighbour Relation Function in NB-IoT

The ANR (Automatic Neighbour Relation) function relies on cells broadcasting their identity on global level, E-
UTRAN Cell Global Identifier (ECGI).
3GPP
Release 17 300 3GPP TS 36.300 V17.2.0 (2022-09)
Cell A Cell B
Phy-CID=3 Phy-CID=5
Global-CID =17 Global
4) Request ANR report 1) ANR measurement configuration

& RRC connection release
2b) Read BCCH
Figure 22.3.4b-1: Automatic Neighbour Relation Function in case of NB-IoT
The purpose of SON/ANR reporting in NB-IoT is network optimisation. The measurements are performed when the UE
is in RRC_IDLE and reported next time the UE enters RRC_CONNECTED. ANR measurement reporting is not
supported when the UE uses the Control Plane CIoT EPS Optimisation.
The eNB serving cell A has an ANR function. During connected mode, the eNB can configure the UE to perform
measurements on a frequency and read the CGI of the strongest cell if the quality is above a given RSRP threshold. The
eNB may use different policies for instructing the UE to do measurements.
1 When releasing the RRC connection, the eNB configures the UE to perform ANR measurements on one or more
frequencies. The RRC connection is released and the UE enters RRC_IDLE.
When the UE is in RRC_IDLE and remains camped on the cell from which the ANR measurement configuration was
received, the UE performs the ANR measurements requested by the eNB:
2a For each of the configured frequency, the UE performs measurements, identifies the strongest cell and stores the
cell measurement results for later reporting.
2b For each of the configured frequency, if the NRSRP of the strongest cell is above the configured threshold, the
UE reads the ECGI, the TAC and all available PLMN ID(s) of the related neighbour cell and stores the
information for later reporting.
NOTE: While performing an ANR measurement, the UE performs inter-frequency measurements on the
configured frequency regardless of the measurement rules for cell re-selection and the relaxed monitoring
measurement rules as specified in TS 36.304 [11].
When the UE establishes or resumes the RRC connection:
3 The UE reports the availability of an ANR report.
When the eNB receives the indication of the ANR report availability, the following sequence may be used whilst UE is
in RRC_CONNECTED mode:
3GPP
Release 17 301 3GPP TS 36.300 V17.2.0 (2022-09)
4 The eNB requests the UE to provide the report.
5 The UE reports the stored cells and associated information.
The UE discards the ANR configuration and the ANR report when returning to RRC_IDLE after it has indicated the
availability of the ANR report, after 96 hours of receiving the configuration, upon power off, upon detach or upon RAT
change.
22.3.5 Framework for PCI Selection

The eNB shall base the selection of its PCI either on a centralized or distributed PCI assignment algorithm:
[Centralized PCI assignment] The OAM signals a specific PCI value. The eNB shall select this value as its PCI.
[Distributed PCI assignment] The OAM signals a list of PCI values. The eNB may restrict this list by removing PCI-s
that are:
a) reported by UEs;
b) reported over the X2 interface by neighbouring eNBs; and/or
c) acquired through other implementation dependent methods, e.g. heard over the air using a downlink receiver.
The eNB shall select a PCI value randomly from the remaining list of PCIs.
22.3.6 TNL address discovery

22.3.6.1 TNL address discovery of candidate eNB via S1 interface
If the eNB is aware of the eNB ID of the candidate eNB (e.g. via the ANR function) but not a TNL address suitable for
SCTP connectivity, then the eNB can utilize the Configuration Transfer Function to determine the TNL address as
follows:
- The eNB sends the eNB CONFIGURATION TRANSFER message to the MME to request the TNL address of
the candidate eNB, and includes relevant information such as the source and target eNB ID.
- The MME relays the request by sending the MME CONFIGURATION TRANSFER message to the candidate
eNB identified by the target eNB ID.
- The candidate eNB responds by sending the eNB CONFIGURATION TRANSFER message containing one or
more TNL addresses to be used for SCTP connectivity with the initiating eNB, and includes other relevant
information such as the source and target eNB ID.
- The MME relays the response by sending the MME CONFIGURATION TRANSFER message to the initiating
22.3.6.2 TNL address discovery of a candidate en-gNB via the S1 interface

If the eNB is aware of the en-gNB ID of the candidate en-gNB but not a TNL address suitable for SCTP connectivity
between the eNB and the en-gNB, then the eNB utilizes the Configuration Transfer Function to determine the TNL
address as follows:
- The eNB sends the eNB CONFIGURATION TRANSFER message to the MME to request the TNL address of
the candidate en-gNB. The eNB includes its own (source) eNB ID and the candidate (target) en-gNB ID.
- The eNB may include in the eNB CONFIGURATION TRANSFER message, if available,
- a target eNB ID, if the eNB has knowledge that the target eNB ID is X2 connected to the candidate en-gNB;
- a TAI associated with the target en-gNB, if the eNB has knowledge about a TAI broadcast in the coverage
area of an NR cell served by the candidate en-gNB.
- The MME relays the request by sending the MME CONFIGURATION TRANSFER message to an eNB known
to be connected to the candidate en-gNB.
3GPP
Release 17 302 3GPP TS 36.300 V17.2.0 (2022-09)
- The eNB connected to the candidate en-gNB relays the request to the candidate en-gNB by means of the X2AP
EN-DC Configuration Transfer procedure.
- The candidate en-gNB sends its X2 TNL Configuration Information to the same eNB using the X2AP EN-DC
Configuration Transfer procedure, and identifying the initiating eNB as the target eNB ID.
- The eNB connected to the candidate en-gNB forwards the received X2 TNL Configuration Information to the
MME in the eNB CONFIGURATION TRANSFER message.
- The MME relays the response by sending the MME CONFIGURATION TRANSFER message to the initiating
NOTE: An NR cell does not broadcast a Tracking Area Code applicable for the EPS. In case that inter-MME X2
TNL address discovery procedures are required, the source MME may use the available information to
identify the target MME.
22.3.6.3 TNL address discovery of a candidate en-gNB via inter-system signalling

If the MME is aware that the en-gNB serves cells which provide access to 5GS, the MME may relay the request
towards a suitable AMF via inter-system signalling based on a broadcast 5G TAC. Upon receiving a reply from the
AMF, the MME may relay this reply to the target eNB using a MME CONFIGURATION TRANSFER message.
22.3.7 Dynamic configuration of the Xw-C interface

- An initial remote IP end point to be used for SCTP initialisation is provided to the eNB.
How the eNB gets the remote IP end point(s) and its own IP address are outside the scope of this specification.

For each WT the eNB tries to initialize a SCTP association as described in IETF RFC 4960 [8], using a known initial
remote IP endpoint as the starting point, until SCTP connectivity is established.

Once SCTP connectivity has been established, the eNB and candidate WT shall exchange application level
configuration data over the Xw-C application protocol with the Xw Setup Procedure, which is needed for these two
nodes to interwork correctly on the Xw interface.
- The eNB provides the relevant configuration information to the WT, which includes the Global eNB ID.
- The WT provides the relevant configuration information to the eNB, which includes WLAN information, etc.
completed and the Xw-C interface is operational.
22.4 Self-optimisation
22.4.1 Support for Mobility Load Balancing
22.4.1.1 General
The objective of load balancing is to distribute cell load evenly among cells or to transfer part of the traffic from
congested cells. This is done by the means of self-optimisation of mobility parameters or handover actions.
Self-optimisation of the intra-LTE, inter-RAT and inter-system mobility parameters to the current load in the cell and in
the adjacent cells can improve the system capacity compared to static/non-optimised cell reselection/handover
parameters. Such optimisation can also minimize human intervention in the network management and optimisation
tasks.
3GPP
Release 17 303 3GPP TS 36.300 V17.2.0 (2022-09)
Support for mobility load balancing consists of one or more of following functions:
- Load reporting (for intra-LTE, inter-RAT, EN-DC and inter-system scenarios);
- Load balancing action based on handovers;
- Adapting handover and/or reselection configuration.
Triggering of each of these functions is optional and depends on implementation. Functional architecture is presented in
Figure 22.4.1.1-1.
Figure 22.4.1.1-1: Functional architecture of SON load balancing
22.4.1.2 Load reporting

The load reporting function is executed by exchanging cell specific load information between neighbour eNBs over the
X2 interface (intra-LTE scenario) or S1 (inter-RAT scenario and EN-DC scenario). The load reporting function for
inter-system load balancing is executed by exchanging load information between E-UTRAN and NG-RAN.
22.4.1.2.1 Load reporting for intra-LTE scenario

The load information consists of:
- radio resource usage (UL/DL GBR PRB usage, UL/DL non-GBR PRB usage, UL/DL total PRB usage);
- HW load indicator (UL/DL HW load: low, mid, high, overload);
3GPP
Release 17 304 3GPP TS 36.300 V17.2.0 (2022-09)
- TNL load indicator (UL/DL TNL load: low, mid, high, overload);
- (Optionally) Cell Capacity Class value (UL/DL relative capacity indicator: the same scale shall apply to E-
UTRAN, UTRAN and GERAN cells when mapping cell capacities on this value);
- Capacity value (UL/DL available capacity for load balancing as percentage of total cell capacity).
NOTE 1: Capacity value is expressed in available E-UTRAN resources.
NOTE 2: A cell is expected to accept traffic corresponding to the indicated available capacity.
22.4.1.2.2 Load reporting for inter-RAT scenario

The load information consists of:
- Cell Capacity Class value (UL/DL relative capacity indicator: the same scale shall apply to E-UTRAN, UTRAN,
GERAN and eHRPD cells when mapping cell capacities on this value);
- Capacity value (UL/DL available capacity for load balancing as percentage of total cell capacity).
NOTE 1: Capacity value is expressed in available E-UTRAN resources.
NOTE 2: A cell is expected to accept traffic corresponding to the indicated available capacity.
Event-triggered inter-RAT load reports are sent when the reporting node detects crossing of cell load thresholds.
Load information shall be provided in a procedure separated from existing active mode mobility procedures, which
shall be used infrequently and with lower priority with respect to the UE dedicated signalling.
22.4.1.2.3 Load reporting for EN-DC scenario

The load reporting function is executed by the way that an en-gNB provides its load information toward an eNB over
the X2 interface.
For an NR cell, the following load related information should be supported which consists of:
- Radio resource usage (per-SSB-area PRB usage: DL/UL/SUL GBR PRB usage, DL/UL/SUL non-GBR PRB
usage, DL/UL/SUL total PRB usage, and DL/UL/SUL scheduling PDCCH CCE usage);
- TNL capacity indicator (UL/DL TNL offered capacity and available capacity);
- Cell Capacity Class value (UL/DL relative capacity indicator);
- Capacity value (UL/DL available capacity);
To achieve load reporting function, EN-DC Resource Status Reporting Initiation & EN-DC Resource Status Reporting
procedures are used.
22.4.1.2.4 Load reporting for inter-system load balancing

Both event-triggered and periodic inter-system load reporting are supported. Event-triggered inter-system load reports
are sent when the reporting node detects crossing of cell load thresholds.
The following load related information should be supported which consists of:
- Cell Capacity Class value (UL/DL relative capacity indicator);
- Capacity value (per cell: UL/DL available capacity);
- RRC connections (number of RRC connections, and available RRC Connection Capacity);
- Number of active UEs;
- Radio Resource Status (per cell PRB usage: UL/DL GBR PRB usage, DL/UL non-GBR PRB usage, DL/UL
total PRB usage, and DL/UL scheduling PDCCH CCE usage).
3GPP
Release 17 305 3GPP TS 36.300 V17.2.0 (2022-09)
NGAP procedures used for inter-system load balancing are Uplink RAN Configuration Transfer and Downlink RAN
Configuration Transfer.
S1AP procedures used for inter-system load balancing are eNB Configuration Transfer and MME Configuration
Transfer.
22.4.1.3 Load balancing action based on handovers

The source cell may initiate handover due to load (see clauses 10.1.2 and 10.2.2). The target cell performs admission
control for the load balancing handovers. A handover preparation related to a mobility load balancing action shall be
distinguishable from other handovers, so that the target cell is able to apply appropriate admission control.
22.4.1.4 Adapting handover and/or reselection configuration

This function enables requesting of a change of handover and/or reselection parameters at target cell. The source cell
that initialized the load balancing estimates if it is needed to change mobility configuration in the source and/or target
cell. If the amendment is needed, the source cell initializes mobility negotiation procedure toward the target cell.
The source cell informs the target cell about the new mobility setting and provides cause for the change (e.g. load
balancing related request). The proposed change is expressed by the means of the difference (delta) between the current
and the new values of the handover trigger. The handover trigger is the cell specific offset that corresponds to the
threshold at which a cell initialises the handover preparation procedure. Cell reselection configuration may be amended
to reflect changes in the HO setting. The target cell responds to the information from the source cell. The allowed delta
range for HO trigger parameter may be carried in the failure response message. The source cell should consider the
responses before executing the planned change of its mobility setting.
All automatic changes on the HO and/or reselection parameters must be within the range allowed by OAM.
22.4.2 Support for Mobility Robustness Optimisation

22.4.2.1 General
Mobility Robustness Optimisation aims at detecting and enabling correction of following problems:
- Connection failure due to intra-LTE or inter-RAT mobility;
- Unnecessary HO to another RAT (too early IRAT HO with no radio link failure);
- Inter-RAT ping-pong;
- Inter-system ping-pong.
22.4.2.2 Connection failure due to intra-LTE mobility

One of the functions of Mobility Robustness Optimisation is to detect connection failures that occur due to Too Early or
Too Late Handovers, or Handover to Wrong Cell. These problems are defined as follows:
- [Too Late Handover] An RLF occurs after the UE has stayed for a long period of time in the cell; the UE
attempts to re-establish the radio link connection in a different cell.
- [Too Early Handover] An RLF occurs shortly after a successful handover from a source cell to a target cell or a
handover failure occurs during the handover procedure; the UE attempts to re-establish the radio link connection
in the source cell.
- [Handover to Wrong Cell] An RLF occurs shortly after a successful handover from a source cell to a target cell
or a handover failure occurs during the handover procedure; the UE attempts to re-establish the radio link
connection in a cell other than the source cell and the target cell.
In the definition above, the "successful handover" refers to the UE state, namely the successful completion of the RA
procedure.
In addition, MRO provides means to distinguish the above problems from LTE coverage related problems and other
problems, not related to mobility.
Solution for failure scenarios consists of one or more of following functions:
3GPP
Release 17 306 3GPP TS 36.300 V17.2.0 (2022-09)
- Detection of the failure after RRC re-establishment attempt;
- Detection of the failure after RRC connection setup;
- Retrieval of information needed for problem analysis.
Triggering of each of these functions is optional and depends on situation and implementation.
Detection of the failure after RRC re-establishment attempt:
Detection mechanisms for Too Late Handover, Too Early Handover and Handover to Wrong Cell are carried out
through the following:
- [Too Late Handover]

If the UE attempts to re-establish the radio link connection in a cell that belongs to eNB B, indicating as the last
serving cell a cell belonging to eNB A, different from eNB B, then eNB B may report this event to eNB A by
means of the RLF Indication Procedure. eNB A may then use information in the RLF INDICATION message to
determine whether the failure occurred in the serving cell.
- [Too Early Handover]

If the target cell belongs to an eNB B different from the eNB A that controls the source cell, the eNB B may
send a HANDOVER REPORT message indicating a Too Early Handover event to eNB A upon eNB B receives
an RLF INDICATION message from eNB A and if eNB B has sent the UE CONTEXT RELEASE message to
eNB A related to the completion of an incoming handover for the same UE within the last Tstore_UE_cntxt
seconds or there exists a prepared handover for the same UE in eNB B.
- [Handover to Wrong Cell]

If the type of the failure is Radio Link Failure and the target cell belongs to eNB B that is different from the eNB
A that controls the source cell, the eNB B may send a HANDOVER REPORT message indicating a Handover
To Wrong Cell event to eNB A upon eNB B receives an RLF INDICATION message from eNB C, and if eNB
B has sent the UE CONTEXT RELEASE message to eNB A related to the completion of an incoming handover
for the same UE within the last Tstore_UE_cntxt seconds or there exists a prepared handover for the same UE in
eNB B. This also applies when eNB A and eNB C are the same. The HANDOVER REPORT message may also
be sent if eNB B and eNB C are the same and the RLF Indication is internal to this eNB.
If the type of the failure is Handover Failure during a handover from a cell in eNB A, and the UE attempts to re-
establish the radio link connection to a cell in eNB C, then eNB C may send a RLF INDICATION message to
eNB A.
The detection of the above events, when involving more than one eNB, is enabled by the RLF Indication, Handover
Report and MME Configuration Transfer procedures.
The RLF Indication procedure may be initiated after a UE attempts to re-establish the radio link connection at eNB B
after a failure at eNB A. The RLF INDICATION message sent from eNB B to eNB A shall contain the following
information elements:
- Failure Cell ID: PCI of the cell in which the UE was connected prior to the failure occurred;
- Reestablishment Cell ID: ECGI of the cell where RL re-establishment attempt is made;
- C-RNTI: C-RNTI of the UE in the cell where UE was connected prior to the failure occurred;
- shortMAC-I (optionally): the 16 least significant bits of the MAC-I calculated using the security configuration of
the source cell and the re-establishment cell identity;
- UE RLF Report Container (optionally): the RLF Report received from the UE, as specified in TS 36.331 [16];
- Reestablishment Cause (optionally): provided by the UE during the RRC connection re-establishment attempt.
eNB B may initiate RLF Indication towards multiple eNBs if they control cells which use the PCI signalled by the UE
during the re-establishment procedure. The eNB A selects the UE context that matches the received Failure Cell ID and
C-RNTI, and, if available, uses the shortMAC-I to confirm this identification, by calculating the shortMAC-I and
comparing it to the received IE.
The Handover Report procedure is used in the case of recently completed handovers, when a failure occurs in the target
cell (in eNB B) shortly after it sent the UE Context Release message to the source eNB A. The Handover Report
3GPP
Release 17 307 3GPP TS 36.300 V17.2.0 (2022-09)
procedure is also used when an RLF occurs before the UE Context Release message is sent, if the random access
procedure in the target cell was completed successfully. The HANDOVER REPORT message contains the following
information:
- Type of detected handover problem (Too Early Handover, Handover to Wrong Cell);
- ECGI of source and target cells in the handover;
- ECGI of the re-establishment cell (in the case of Handover to Wrong Cell);
- Handover cause (signalled by the source during handover preparation);
- C-RNTI allocated for the UE in the source cell (if available);
- Mobility Information (optionally);
- UE RLF Report (optionally): the RLF Report received from the UE and forwarded in the RLF INDICATION
message.
UE may provide the RLF Report to the eNB after successful RRC re-establishment. The radio measurements contained
in the RLF Report may be used e.g. to identify coverage issues as the potential cause of the failure. The cause for the
RLF contained in the RLF Report may be used to identify the cause of the failure and exclude the events that are
irrelevant for MRO evaluation.
Detection of the failure after RRC connection setup:
In case the RRC re-establishment fails or the UE does not perform any RRC re-establishment, the UE makes the RLF
Report available to the eNB after reconnecting from idle mode. The RLF Report is described in clause 22.4.5.
Availability of the RLF Report at the RRC connection setup procedure is the indication that the UE suffered from a
connection failure and that the RLF Report from this failure was not yet delivered to the network. The RLF Report from
the UE includes the following information:
- The E-CGI of the last cell that served the UE (in case of RLF) or the target of the handover (in case of handover
failure). If the E-CGI is not known, the PCI and frequency information are used instead.
- E-CGI of the cell that the re-establishment attempt was made at.
- E-CGI of the cell that served the UE at the last handover initialisation, i.e. when message 7
(RRCConnectionReconfiguration) was received by the UE, as presented in Figure 10.1.2.1.1-1.
- Time elapsed since the last handover initialisation until connection failure.
- An indication whether the connection failure was due to RLF or handover failure.
- The radio measurements.
- C-RNTI allocated for the UE in the last serving cell.
- RLF trigger of the last RLF that was detected.
- Time elapsed from the connection failure till RLF Report signalling.
The eNB receiving the RLF Report from the UE may forward the report to the eNB that served the UE before the
reported connection failure using the RLF INDICATION message. In case the RLF Report is received in an NG-RAN
node (as defined in TS 38.300 [79]), it may be delivered to the eNB that served the UE before the reported connection
failure using the MME Configuration Transfer procedure. The radio measurements contained in the RLF Report may be
used e.g. to identify coverage issues as the potential cause of the failure. The cause for the RLF contained in the RLF
Report may be used to identify the cause of the failure and exclude the irrelevant events that are irrelevant for MRO
evaluation.
Detection of Too Late Handover, Too Early Handover and Handover to Wrong Cell is carried out through the
following:
- [Too Late Handover]

There is no recent handover for the UE prior to the connection failure i.e. the UE reported timer is absent or
larger than the configured threshold, e.g. Tstore_UE_cntxt.
3GPP
Release 17 308 3GPP TS 36.300 V17.2.0 (2022-09)
- [Too Early Handover]

There is a recent handover for the UE prior to the connection failure i.e. the UE reported timer is smaller than the
configured threshold, e.g. Tstore_UE_cntxt, and the first re-establishment attempt cell is the cell that served the
UE at the last handover initialisation.
- [Handover to Wrong Cell]

There is a recent handover for the UE prior to the connection failure i.e. the UE reported timer is smaller than the
configured threshold, e.g. Tstore_UE_cntxt, and the first re-establishment attempt cell is neither the cell that
served the UE at the last handover initialisation nor the cell that served the UE where the RLF happened or the
cell that the handover was initialised toward.
The "UE reported timer" above indicates the time elapsed since the last handover initialisation until connection failure.
In case of Too Early Handover or Handover to Wrong Cell, the eNB receiving the RLF INDICATION message may
use the HANDOVER REPORT message to inform the eNB controlling the cell where the mobility configuration caused
the failure.
Retrieval of information needed for problem analysis
The information needed for detailed problem analysis may be retrieved from both, the UE and the network sides. The
information that is collected at the UE is provided to the network with the RLF Report, which may be forwarded to the
last serving node in the RLF INDICATION message and, in case of "Too Early HO" or "HO to Wrong Cell", further in
the HANDOVER REPORT message.
In order to retrieve relevant information collected at the network side as part of the UE context, the UE provides C-
RNTI used in the last serving cell. If the cause for the failure is identified as a "Too Early HO" or a "HO to Wrong
Cell", the eNB controlling the last serving cell shall, if supported, include in the HANDOVER REPORT message the
C-RNTI used in the source cell of the last completed handover before the failure. If the eNB controlling that source cell
provided the Mobility Information, it is included in the HANDOVER REPORT message. If used, the Mobility
Information is prepared at the source eNB of a handover and may refer to or identify any handover-related data at this
eNB.
Handling multiple reports from a single failure event
In case the RRC re-establishment fails and the RRC connection setup succeeds, MRO evaluation of intra-LTE mobility
connection failures may be triggered twice for the same failure event. In this case, only one failure event should be
counted.
22.4.2.2a Connection failure due to inter-RAT mobility

One of the functions of Mobility Robustness Optimisation is to detect connection failures that occurred due to Too
Early or Too Late inter-RAT handovers. These problems are defined as follows:
- [Too Late Inter-RAT Handover] An RLF occurs after the UE has stayed in an E-UTRAN cell for a long period
of time; the UE attempts to re-connect to a UTRAN cell.
- [Too Early Inter-RAT Handover] An RLF occurs shortly after a successful handover from a UTRAN cell to a
target cell in E-UTRAN; the UE attempts to re-connect to the source cell or to another UTRAN cell.
The UE makes the RLF Report available to an eNB, when RLF happens in E-UTRAN and the UE re-connects to an
eNB cell. Availability of the RLF Report at the RRC connection setup or at a handover to E-UTRAN cell is the
indication that the UE suffered a connection failure and that the RLF Report from this failure was not yet delivered to
the network.
reported connection failure using the RLF INDICATION message over X2 or by means of the eNB configuration
transfer procedure and MME configuration transfer procedure over S1. If present in the RLF Report, the radio
measurements may be used to identify lack of coverage as the potential cause of the failure. This information may be
used to exclude those events from the MRO evaluation and redirect them as input to other algorithms.
Detection mechanisms for Too Late Inter-RAT Handover and Too Early Inter-RAT Handover are carried out through
the following:
- [Too Late Inter-RAT Handover]

The connection failure occurs while being connected to an LTE cell, and there is no recent handover for the UE
3GPP
Release 17 309 3GPP TS 36.300 V17.2.0 (2022-09)
prior to the connection failure i.e., the UE reported timer is absent or larger than the configured threshold, e.g.,
Tstore_UE_cntxt, and the first cell where the UE attempts to re-connect is a UTRAN cell.
- [Too Early Inter-RAT Handover]

The connection failure occurs while being connected to an LTE cell, and there is a recent inter-RAT handover
for the UE prior to the connection failure i.e., the UE reported timer is smaller than the configured threshold,
e.g., Tstore_UE_cntxt, and the first cell where the UE attempts to re-connect and the cell that served the UE at
the last handover initialisation are both UTRAN cells.
The "UE reported timer" above indicates the time elapsed since the last handover initialisation until connection failure.
In case the failure is a Too Early Inter-RAT Handover, the eNB receiving the RLF INDICATION message may inform
the UTRAN node by means of the eNB Direct Information Transfer procedure over S1. The information contains:
- Type of detected handover problem (Too Early Inter-RAT Handover);
- UE RLF Report Container: the RLF Report received from the UE, as specified in TS 36.331 [16];
- Mobility Information (optionally, if provided in the last Handover Resource Allocation procedure from the
UTRAN node);
22.4.2.3 Unnecessary HO to another RAT

One of the purposes of inter-RAT Mobility Robustness Optimisation is the detection of a non-optimal use of network
resources. In particular, in case of inter-RAT operations and when E-UTRAN is considered, the case known as
Unnecessary HO to another RAT is identified. The problem is defined as follows:
- UE is handed over from E-UTRAN to other RAT (e.g. GERAN or UTRAN) even though quality of the E-
UTRAN coverage was sufficient for the service used by the UE. The handover may therefore be considered as
unnecessary HO to another RAT (too early IRAT HO without connection failure).
In inter-RAT HO, if the serving cell threshold (E-UTRAN) is set too high, and another RAT with good signal strength
is available, a handover to another RAT (e.g. UTRAN or GERAN) may be triggered unnecessarily, resulting in an
inefficient use of the networks. With a lower threshold the UE could have continued in the source RAT (E-UTRAN).
To be able to detect the Unnecessary HO to another RAT, an eNB may choose to put additional coverage and quality
condition information into the HANDOVER REQUIRED message in the Handover Preparation procedure when an
inter-RAT HO from E-UTRAN to another RAT occurs. The RAN node in the other RAT, upon receiving this additional
coverage and quality information, may instruct the UE to continue measuring the source RAT (E-UTRAN) during a
period of time, while being connected to another RAT (e.g. UTRAN or GERAN), and send periodic or single
measurement reports to the other RAT (e.g. UTRAN or GERAN). When the period of time indicated by the source
RAT (E-UTRAN) expires, the RAN node in the other RAT (e.g. UTRAN or GERAN), may evaluate the received
measurement reports with the coverage/quality condition received during the inter-RAT HO procedure and decide if an
inter-RAT unnecessary HO report should be sent to the RAN node in the source RAT (E-UTRAN). The inter-RAT
unnecessary HO report should include the following information:
- Handover type (LTE to UTRAN, LTE to GERAN);
- Type of detected handover problem (Unnecessary HO to another RAT);
- ECGI of the source cell in the handover;
- Cell ID of the target cell;
- A list of cells whose radio quality, as reported in the UE's first measurement report following the handover,
exceeds the threshold indicated in the additional coverage and quality information in the Handover Preparation
procedure.
The inter-RAT unnecessary HO report shall only be sent in cases where, in all UE measurement reports collected during
the measurement period, any source RAT cells exceed the radio coverage and/or quality threshold (the radio threshold
RSRP or/and RSRQ and the measurement period are indicated in the additional coverage and quality information in the
Handover Preparation procedure). If an inter-RAT handover towards LTE is executed from RNC within the indicated
measurement period, the measurement period expires. In this case, the RNC may also send the HO Report. No HO
Report shall be sent in case no E-UTRAN cell could be included, or if the indicated period of time is interrupted by an
3GPP
Release 17 310 3GPP TS 36.300 V17.2.0 (2022-09)
inter-RAT handover to a RAT different than LTE or by an intra-UMTS handover with SRNC relocation or inter-BSS
handover.
The RAN node in the source RAT (E-UTRAN) upon receiving of the report, can decide if/how its parameters (e.g.,
threshold to trigger IRAT HO) should be adjusted.
22.4.2.4 O&M Requirements

All automatic changes of the HO and/or reselection parameters for mobility robustness optimisation shall be within the
range allowed by OAM.
The following control parameters shall be provided by OAM to control MRO behaviour:
- Maximum deviation of Handover Trigger

This parameter defines the maximum allowed absolute deviation of the Handover Trigger (as defined in
22.4.1.4), from the default point of operation defined by the parameter values assigned by OAM.
- Minimum time between Handover Trigger changes

This parameter defines the minimum allowed time interval between two Handover Trigger change performed by
MRO. This is used to control the stability and convergence of the algorithm.
Furthermore, in order to support the solutions for detection of Too Late and Too Early HO, the parameter
Tstore_UE_cntxt shall be configurable by the OAM system.
OAM may define multiple coverage configurations for each cell served by an eNB. The coverage configuration may
also mean a cell is inactive (no coverage). The eNB may dynamically select the most appropriate coverage
configuration for its served cells.
22.4.2.5 Inter-RAT ping-pong

One of the functions of Mobility Robustness Optimisation is to detect ping-pongs that occur in inter-RAT environment.
The problem is defined as follows:
- A UE is handed over from a cell in a source RAT (e.g. E-UTRAN) to a cell in a target RAT different from the
source RAT (e.g. UTRAN), then within a predefined limited time the UE is handed over back to a cell in the
source RAT, while the coverage of the source RAT was sufficient for the service used by the UE. The event may
occur more than once.
The solution for the problem may consist of the following steps:
1) Statistics regarding inter-RAT ping-pong occurrences are collected by the responsible node.
2) Coverage verification is performed to check if the mobility to other RAT was inevitable.
The statistics regarding ping-pong occurrence may be based on evaluation of the UE History Information IE in the
HANDOVER REQUIRED message. If the evaluation indicates a potential ping-pong case and the source eNB of the 1 st
inter-RAT handover is different than the target eNB of the 2nd inter-RAT handover, the target eNB may use the
HANDOVER REPORT message to indicate the occurrence of potential ping-pong cases to the source eNB. The
HANDOVER REPORT message for ping-pong indication contains the following information:
- Type of detected handover problem (InterRAT ping-pong);
- ECGI of the source cell in the handover from E-UTRAN to UTRAN;
- ECGI of the target in the handover from UTRAN to E-UTRAN;
- Cell Identifier of the target UTRAN cell in the first inter-RAT handover;
- Cause of the first handover (signalled by the source during handover preparation).
If E-UTRAN coverage during the potential ping-pong event needs to be verified for the purpose of determining
corrective measures, the Unnecessary HO to another RAT procedure may be used
3GPP
Release 17 311 3GPP TS 36.300 V17.2.0 (2022-09)
22.4.2.6 Dynamic coverage configuration changes

Each eNB may be configured with alternative coverage configurations and an eNB may autonomously select and switch
between these configurations, e.g. using the Active Antenna Systems functions.
An eNB may notify its neighbour eNBs about the coverage reconfiguration using the ENB CONFIGURATION
UPDATE message with the list of cells with modified coverage included. The list contains the ECGI of each modified
cell and its coverage state indicator. The indicator may be used at the receiving eNB to adjust the functions of the
Mobility Robustness Optimisation, e.g. by using the indicator to retrieve a previously stored Mobility Robustness
Optimisation state. If the list includes indication about planned reconfiguration and possibly a list of replacing cells, the
receiving eNB may use this to avoid connection or re-establishment failures during the reconfiguration. Also, if the
sending eNB adds cells in inactive state, the receiving eNB may use this information to avoid connection or re-
establishment failures.
The receiving node may also use the notification to reduce the impact on mobility. For example, the receiving eNB
should avoid triggering handovers towards cell(s) that are indicated to be inactive.
22.4.2.7 Connection failure due to Radio Link Failure in NB-IoT

In NB-IoT, the function of Mobility Robustness Optimization is to detect connection failures due to radio link failure.
Solution for failure scenarios consists of one or more of following functions:
- Detection of the failure after RRC re-establishment attempt;
- Detection of the failure after RRC connection setup;
- Retrieval of information needed for problem analysis.
Triggering of each of these functions is optional and depends on situation and implementation.
Detection of the failure after RRC re-establishment attempt:
UE provides the RLF Report to the eNB after successful RRC connection re-establishment.
Detection of the failure after RRC connection setup:
In case the RRC connection re-establishment fails or the UE does not perform any RRC connection re-establishment,
the UE makes the RLF Report available to the eNB after reconnecting from idle mode. Availability of the RLF Report
at the RRC connection setup procedure is the indication that a RLF failure occured and that the RLF Report from this
occurence could be obtained by the network.
Retrieval of information needed for problem analysis
The information needed for detailed problem analysis may be retrieved from both, the UE and the network sides. The
information that is collected at the UE is provided to the network with the RLF Report.
The RLF Report from the UE includes the following information:
- The E-CGI of the last cell that served the UE.
- The radio measurements of the last cell that served the UE.
- Time elapsed from the connection failure till RLF Report signalling.
reported connection failure using the RLF INDICATION message.
22.4.2.8 Inter-system Ping-Pong

One of the functions of Mobility Robustness Optimization is to detect ping-pongs that occur in inter-system
environment. The problem is defined as follows:
- A UE is handed over from a cell in a source system (e.g. E-UTRAN) to a cell in a target system different from
the source system (e.g. NG-RAN), then within a predefined limited time the UE is handed over back to a cell in
3GPP
Release 17 312 3GPP TS 36.300 V17.2.0 (2022-09)
the source system, while the coverage of the source system was sufficient for the service used by the UE. The
event may occur more than once.
The solution for the problem may consist of the following steps:
1) Statistics regarding inter-system ping-pong occurrences are collected by the responsible node.
2) Coverage verification is performed to check if the mobility to other system was inevitable.
The statistics regarding ping-pong occurrence may be based on evaluation of the UE History Information IE in the
HANDOVER REQUIRED message. If the evaluation indicates a potential ping-pong case and the source E-UTRAN
node of the 1st inter-system handover is different than the target E-UTRAN node of the 2nd inter-system handover, the
target E-UTRAN node may use the HANDOVER REPORT message to indicate the occurrence of potential ping-pong
cases to the source E-UTRAN node.
22.4.3 Support for RACH Optimisation

22.4.3.1 General
The aim of this function is to support RACH Optimisation. RACH optimisation is supported by UE reported
information and by RACH parameters exchange between:
- E-UTRA cells;
- NR cells, in case of EN-DC.
22.4.3.2 Solution description

22.4.3.2.1 E-UTRA cell case
The setting of RACH parameters that can be optimized are:
- RACH configuration (resource unit allocation);
- RACH preamble split (among dedicated, group A, group B, RSRP level, NRSRP level (for NB-IoT), NPRACH
resource pools (for NB-IoT), EDT);
- RACH backoff parameter value;
- RACH transmission power control parameters.
RACH optimisation is supported by UE reported information and by PRACH parameters exchange or NPRACH
parameters (for NB-IoT) between eNBs.
UEs which receive polling signalling shall report the below information:
- Number of RACH preambles sent until the successful RACH completion;
- Contention resolution failure;
- For BL UE or UE in enhanced coverage or NB-IoT UE, the RSRP (NRSRP for NB-IoT) level in which the UE
started the random access procedure;
- For BL UE or UE in enhanced coverage or NB-IoT UE, an EDT fallback indication.
UE reporting of RACH information is not supported for a NB-IoT UE using the Control Plane CIoT EPS Optimisation,
22.4.3.2.2 NR cell in EN-DC case

The solution applies to an en-gNB supporting EN-DC operation. RACH optimisation is supported by UE reported
information (RACH information report, see TS 38.300 [79]) made available at the eNB and further forwarded to the en-
gNB, and by PRACH parameters exchanged (see TS 38.300 [79]) between en-gNBs and eNBs.
3GPP
Release 17 313 3GPP TS 36.300 V17.2.0 (2022-09)
22.4.4 Support for Energy Saving

22.4.4.1 General
The aim of this function is to reduce operational expenses through energy savings.
The function allows, for example in a deployment where capacity boosters can be distinguished from cells providing
basic coverage, to optimize energy consumption enabling the possibility for a E-UTRA or EN-DC cell or NR cell
providing additional capacity via single or dual connectivity, to be switched off when its capacity is no longer needed
and to be re-activated on a need basis. The basic coverage may be provided by
- E-UTRAN, UTRAN or GERAN cells, in the case of E-UTRA cells;
- E-UTRA cells, in the case of EN-DC cells.
22.4.4.2 Solution description

22.4.4.2.1 E-UTRA cell case
The solution builds upon the possibility for the eNB owning a capacity booster cell to autonomously decide to switch-
off such cell to lower energy consumption (dormant state). The decision is typically based on cell load information,
consistently with configured information. The switch-off decision may also be taken by O&M.
The eNB may initiate handover actions in order to off-load the cell being switched off and may indicate the reason for
handover with an appropriate cause value to support the target node in taking subsequent actions, e.g. when selecting
the target cell for subsequent handovers.
All peer eNBs are informed by the eNB owning the concerned cell about the switch-off actions over the X2 interface,
by means of the eNB Configuration Update procedure. The eNB indicates the switch-off action to a GERAN and/or
UTRAN node by means of the eNB Direct Information Transfer procedure over S1.
All informed nodes maintain the cell configuration data, e.g., neighbour relationship configuration, also when a certain
cell is dormant. If basic coverage is ensured by E-UTRAN cells, eNBs owning non-capacity boosting cells may request
a re-activation over the X2 interface if capacity needs in such cells demand to do so. This is achieved via the Cell
Activation procedure. If basic coverage is ensured by UTRAN or GERAN cells, the eNB owning the capacity booster
cell may receive a re-activation request from a GERAN or UTRAN node by means of the MME Direct Information
Transfer procedure over S1. The eNB owning the capacity booster cell may also receive from the sending GERAN or
UTRAN node the minimum time before that cell switches off; during this time, the same eNB may prevent idle mode
UEs from camping on the cell and may prevent incoming handovers to the same cell.
The eNB owning the dormant cell should normally obey a request. The switch-on decision may also be taken by O&M.
All peer eNBs are informed by the eNB owning the concerned cell about the re-activation by an indication on the X2
interface. The eNB indicates the re-activation action to a GERAN and/or UTRAN node by means of the eNB Direct
Information Transfer procedure over S1. The eNB owning the concerned cell may choose to delay or not to send
indication(s) if the sending GERAN or UTRAN node has included the minimum activation time in the re-activation
request.
22.4.4.2.2 EN-DC cell case

The solution applies to an en-gNB supporting EN-DC operation.
The en-gNB may autonomously decide to switch-off NR cells to lower energy consumption. MeNBs are informed by
the en-gNB owning the concerned cell about the switch-off actions over the X2 interface, by means of the EN-DC
Configuration Update procedure.
The en-gNB may initiate dual connectivity procedures towards the MeNB in order to off-load the cell being switched
off, and may indicate the reason for release or modification with an appropriate cause value to support the master node
in taking subsequent actions.
The MeNB may request a re-activation over the X2 interface if capacity needs demand to do so. This is achieved via the
EN-DC Cell Activation procedure. The en-gNB owning the dormant NR cell should normally obey a request. The
switch-on decision may also be taken by O&M. All peer eNBs are informed by the en-gNB owning the concerned NR
cell about the re-activation by an indication on the X2 interface.
3GPP
Release 17 314 3GPP TS 36.300 V17.2.0 (2022-09)
22.4.4.2.3 NR cell case

For Inter-RAT Inter-system energy saving, in case the eNB provides basic coverage, it may request a NR cell re-
activation based on its own cell load information or neighbour cell load information and receive the cell re-activation
reply. The switch-on decision may also be taken by O&M. The eNB can be notified of the status of the concerned NR
cell. The cell activation, cell activation reply and cell status notification information are transferred over S1 interface
and NG interface.
22.4.4.3 O&M requirements

Operators should be able to configure the energy saving function.
The configured information should include:
- The ability of an eNB to perform autonomous cell switch-off.
- The ability of an eNB to request the re-activation of a configured list of dormant cells owned by a peer eNB.
- The ability of an eNB to request the re-activation of a configured list of dormant cells owned by a peer gNB.
O&M may also configure
- policies used by the eNB for cell switch-off decision.
- policies used by peer eNBs for requesting the re-activation of a dormant cell.
22.4.5 Radio Link Failure report

The RLF Report from the UE can be used for both coverage optimisation and mobility robustness optimisation.
Except for NB-IoT, the UE stores the latest RLF or handover failure related information, and indicates RLF report
availability at each subsequent LTE RRC connection (re-)establishment and handover to an LTE cell until the RLF
report is fetched by the network or for 48 hours after the RLF or handover failure is detected.
Except for NB-IoT, the UE keeps the information during state transitions and RAT changes, and indicates RLF report
availability again after it returns to the LTE RAT.
For NB-IoT, the UE stores the latest RLF related information and indicates RLF report availability at the subsequent
RRC connections (re-)establishment. The UE discards the RLF report when returning to RRC_IDLE after it has
indicated RLF report availability, after 48 hours of the RLF detection, upon power off, upon detach or upon RAT
change.
The UE only indicates RLF report availability and only provides the RLF report to the network if the current RPLMN is
a PLMN that was present in the UE's EPLMN List or was the RPLMN at the time the RLF or handover failure was
detected.UE reporting of RLF information is not supported for a NB-IoT UE using the Control Plane CIoT EPS
Optimisation.
22.5 Void
22.6 Void
22A LTE-WLAN Aggregation and RAN Controlled LTE-

WLAN Interworking
22A.1 LTE-WLAN Aggregation
22A.1.1 General
E-UTRAN supports LTE-WLAN aggregation (LWA) operation whereby a UE in RRC_CONNECTED is configured by
the eNB to utilize radio resources of LTE and WLAN. Two scenarios are supported depending on the backhaul
connection between LTE and WLAN:
3GPP
Release 17 315 3GPP TS 36.300 V17.2.0 (2022-09)
- non-collocated LWA scenario for a non-ideal backhaul;
- collocated LWA scenario for an ideal/internal backhaul;
The overall architecture for the non-collocated LWA scenario is illustrated in Figure 22A.1.1-1 below where the
WLAN Termination (WT) terminates the Xw interface for WLAN.
Figure 22A.1.1-1: Non-collocated LWA Overall Architecture
22A.1.2 Radio Protocol Architecture

In LWA, the radio protocol architecture that a particular bearer uses depends on the LWA backhaul scenario and how
the bearer is set up. Two bearer types exist for LWA: split LWA bearer and switched LWA bearer. Those two bearer
types are depicted on Figure 22A.1.2-1 for the collocated scenario and on Figure 22A.1.2-2 for the non-collocated
scenario.
Figure 22A.1.2-1: LWA Radio Protocol Architecture for the Collocated Scenario
3GPP
Release 17 316 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22A.1.2-2: LWA Radio Protocol Architecture for the Non-Collocated Scenario
In the downlink, for PDUs sent over WLAN in LWA operation, the LWAAP entity, as specified in TS 36.360 [66]
generates LWAAP PDU containing a DRB identity and the WT uses the LWA EtherType 0x9E65 for forwarding the
data to the UE over WLAN. The UE uses the LWA EtherType to determine that the received PDU belongs to an LWA
bearer and uses the DRB identity to determine to which LWA bearer the PDU belongs to.
In the uplink, for PDUs sent over WLAN in LWA operation, the LWAAP entity in the UE generates LWAAP PDU
containing a DRB identity and the UE uses the LWA EtherType 0x9E65 for sending the data over WLAN.
LWA supports split bearer operation where the PDCP sublayer supports in-sequence delivery of upper layer PDUs
based on the reordering procedure introduced for DC.
The UE supporting LWA may be configured by the eNB to send PDCP status report or LWA status report, as specified
in TS 36.323 [15], in cases where feedback from WT is not available.
Only RLC AM and RLC UM can be configured for an LWA bearer.
E-UTRAN does not configure LWA with DC, LWIP or RCLWI simultaneously for the same UE.
If LWA and RAN assisted WLAN interworking are simultaneously configured for the same UE, in
RRC_CONNECTED, the UE only applies LWA.
For LWA bearer, if the data available for transmission is equal to or exceeds the threshold configured by E-UTRAN the
UE decides which PDCP PDUs are sent over WLAN or LTE. If the data available is below the threshold, the UE
transmits PDCP PDUs on LTE or WLAN as configured by E-UTRAN.
For each LWA DRB, E-UTRAN may configure the IEEE 802.11 AC value to be used for the PDCP PDUs that are sent
over WLAN in the uplink.
For LWA bearer, for routing of UL data over WLAN, the WT MAC address may be provided to the UE by the E-
UTRAN or using other WLAN procedure.
22A.1.3 Network Interfaces

22A.1.3.1 General
In the non-collocated LWA scenario, the eNB is connected to one or more WTs via an Xw interface. In the collocated
LWA scenario the interface between LTE and WLAN is up to implementation. For LWA, the only required interfaces
to the Core Network are S1-U and S1-MME which are terminated at the eNB. No Core Network interface is required
for the WLAN.
NOTE 1: WT is a logical node and 3GPP does not specify where it is implemented.
NOTE 2: LTE-WLAN aggregation support at a WLAN does not preclude the implementation of legacy WLAN
interworking (e.g. S2a, S2b or NSWO) in the same WLAN.
22A.1.3.2 User Plane

In the non-collocated LWA scenario, the Xw user plane interface (Xw-U) is defined between eNB and WT. The Xw-U
interface supports flow control based on feedback from WT.
3GPP
Release 17 317 3GPP TS 36.300 V17.2.0 (2022-09)
The Flow Control function is applied in the downlink when an E-RAB is mapped onto an LWA bearer, i.e. the flow
control information is provided by the WT to the eNB for the eNB to control the downlink user data flow to the WT for
the LWA bearer. The OAM configures the eNB with the information of whether the Xw DL delivery status provided
from a connected WT concerns LWAAP PDUs successfully delivered to the UE or successfully transferred toward the
UE.
The Xw-U interface is used to deliver LWAAP PDUs between eNB and WT.
For LWA, the S1-U terminates in the eNB and, if Xw-U user data bearers are associated with E-RABs for which the
LWA bearer option is configured, the user plane data is transferred from eNB to WT using the Xw-U interface.
Figure 22A.1.3.2-1 shows U-plane connectivity of eNB and WT involved in LWA for a certain UE: the S1-U is
terminated at the eNB; the eNB and the WT are interconnected via Xw-U.
Figure 22A.1.3.2-1: U-Plane connectivity of eNB and WT for LWA
22A.1.3.3 Control Plane

In the non-collocated LWA scenario, the Xw control plane interface (Xw-C) is defined between eNB and WT. The
application layer signalling protocol is referred to as Xw-AP (Xw Application Protocol).
The Xw-AP protocol supports the following functions:
- Transfer of WLAN metrics (e.g. bss load) from WT to eNB;
- Support of LWA for UE in ECM-CONNECTED:
- Establishment, Modification and Release of a UE context at the WT;
- Control of user plane tunnels between eNB and WT for a specific UE for LWA bearers.
- General Xw management and error handling functions:
- Error indication;
- Setting up the Xw;
- Resetting the Xw;
- Updating the WT configuration data.
eNB-WT control plane signalling for LWA is performed by means of Xw-C interface signalling.
There is only one S1-MME connection per LWA UE between the eNB and the MME. Respective coordination between
eNB and WT is performed by means of Xw interface signalling.
Figure 22A.1.3.3-1 shows C-plane connectivity of eNB and WT involved in LWA for a certain UE: the S1-MME is
terminated in eNB; the eNB and the WT are interconnected via Xw-C.
3GPP
Release 17 318 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22A.1.3.3-1: C-Plane connectivity of eNB and WT for LWA
22A.1.4 Mobility
A WLAN mobility set is a set of one or more WLAN Access Points (APs) identified by one or more
BSSID/HESSID/SSIDs, within which WLAN mobility mechanisms apply while the UE is configured with LWA
bearer(s), i.e., the UE may perform mobility between WLAN APs belonging to the mobility set without informing the
eNB.
The eNB provides the UE with a WLAN mobility set. When the UE is configured with a WLAN mobility set, it will
attempt to connect to a WLAN whose identifiers match the ones of the configured mobility set. UE mobility to WLAN
APs not belonging to the UE mobility set is controlled by the eNB e.g. updating the WLAN mobility set based on
measurement reports provided by the UE. A UE is connected to at most one mobility set at a time.
All APs belonging to a mobility set share a common WT which terminates Xw-C and Xw-U. The termination endpoints
for Xw-C and Xw-U may differ.The WLAN identifiers belonging to a mobility set may be a subset of all WLAN
identifiers associated to the WT.
22A.1.5 WLAN Measurements

The UE supporting LWA may be configured by the E-UTRAN to perform WLAN measurements. WLAN measurement
object can be configured using WLAN identifiers (BSSID, HESSID and SSID), WLAN carrier information and WLAN
band (2.4GHz, 5GHz and 60GHz). WLAN measurement reporting is triggered using RSSI. WLAN measurement report
contains, for each included WLAN, RSSI and WLAN identifier, and may contain WLAN carrier information, WLAN
band, channel utilization, station count, admission capacity, backhaul rate and an indication whether the UE is
connected to the WLAN.
WLAN measurements may be configured to support the following:
1. LWA activation;
2. Inter WLAN mobility set mobility;
3. LWA deactivation.
UE is configured with measurements for WLAN using IEEE terminology, as specified in IEEE 802.11, Part 11 [65],
(e.g. 'Country', 'Operating Class', and/or 'Channel Number').
22A.1.6 Procedure for WLAN Connection Status Reporting

The purpose of the WLAN Connection Status Reporting procedure is to provide feedback to the eNB related to the
WLAN status and operation. The WLAN Connection Status Reporting procedure supports the following indications:
1. WLAN connection failure;
2. WLAN connection success;
3. WLAN temporary suspension;
3GPP
Release 17 319 3GPP TS 36.300 V17.2.0 (2022-09)
4. WLAN connection resumption.
When a UE configured with at least one LWA bearer becomes unable to establish or continue LWA operation, the UE
sends the WLANConnectionStatusReport message to indicate "WLAN connection failure" to the eNB. When a UE
configured with at least one LWA bearer is not able to support the LWA operation for a temporary duration, the UE
may suspend the LWA operation by sending the WLANConnectionStatusReport message to indicate "WLAN temporary
suspension" to the eNB.
The criteria to determine WLAN connection failure or WLAN temporary suspension is left for UE implementation.
Upon WLAN connection failure or WLAN temporary suspension, the UE RRC connection re-establishment is not
triggered, data reception on WLAN is suspended, and there is no impact to LTE part of the LWA split bearer. Upon
WLAN temporary suspension, UE keeps the LWA configuration including LWA bearer configuration.
When a UE configured with at least one LWA bearer successfully connects to an AP, the UE sends the
WLANConnectionStatusReport message to indicate "WLAN connection success", if configured by the eNB. When a UE
configured with at least one LWA bearer that has previously indicated WLAN temporary suspension is able to resume
the LWA operation, the UE shall send the WLANConnectionStatusReport message to indicate "WLAN connection
resumption" to the eNB.
22A.1.7 LTE-WLAN Aggregation Operation

22A.1.7.1 WT Addition
The WT Addition procedure is initiated by the eNB and is used to establish a UE context at the WT in order to provide
WLAN resources to the UE.
Figure 22A.1.7.1-1: WT Addition procedure
1. The eNB sends the WT Addition Request message to request the WT to allocate WLAN resources for specific
E-RABs, indicating E-RAB characteristics. The WT may reject the request.
NOTE: The eNB may either decide to request resources from the WT of such an amount, that the QoS for the
respective E-RAB is guaranteed by the exact sum of resources provided by the eNB and the WT together,
or even more. The eNB's decision may be reflected in step 1 by the E-RAB parameters signalled to the
WT, which may differ from E-RAB parameters received over S1.
2. If the WT is able to admit the full or partial WLAN resource request, it responds with the WT Addition Request
Acknowledge message.
3. The eNB sends the RRCConnectionReconfiguration message to the UE including the new radio resource
configuration. The eNB may include the Access Categories for uplink E-RABs, if received from the WT in step
2.
3GPP
Release 17 320 3GPP TS 36.300 V17.2.0 (2022-09)
4. The UE applies the new configuration and replies with the RRCConnectionReconfigurationComplete message.
5. The UE performs WLAN Association.
6. The WT, if supported, sends the WT Association Confirmation message.
7. If configured by the eNB, the UE may send the WLANConnectionStatusReport message.
22A.1.7.2 WT Modification
The WT Modification procedure may be initiated either by the eNB or by the WT and be used to modify, establish or
release bearer contexts or to modify other properties of the UE context within the same WT.
The WT Modification procedure does not necessarily need to involve signalling towards the UE.
eNB initiated WT Modification
Figure 22A.1.7.2-1: WT Modification procedure – eNB initiated
1. The eNB sends the WT Modification Request message to request the WT to modify the WLAN resources for
specific E-RABs.
NOTE: The eNB may either decide to request resources from the WT of such an amount, that the QoS for the
respective E-RAB is guaranteed by the exact sum of resources provided by the eNB and the WT together,
or even more. The eNB's decision may be reflected in step 1 by the E-RAB parameters signalled to the
WT, which may differ from E-RAB parameters received over S1.
2. If the WT accepts the request, it applies the modified WLAN resource configuration and responds with the WT
Modification Request Acknowledge message.
3. If the modification requires RRC configuration, eNB sends the RRCConnectionReconfiguration message to the
UE including the new WLAN radio resource configuration. The eNB may include the Access Categories for
uplink E-RABs, if received from the WT in step 2.
4. The UE applies the new RRC configuration and replies with the RRCConnectionReconfigurationComplete
message.
5. The UE starts utilizing the new LWA configuration.
WT initiated WT Modification
3GPP
Release 17 321 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22A.1.7.2-2: WT Modification procedure – WT initiated
1. The WT sends the WT Modification Required message to the eNB to modify the WLAN resources for specific
E-RABs.
2. The eNB replies with the WT Modification Confirm message.
3. If the modification requires RRC configuration, eNB sends the RRCConnectionReconfiguration message to the
UE including the new WLAN radio resource configuration. The eNB may include the Access Categories for
uplink E-RABs, if received from the WT in step 1.
4. The UE applies the new RRC configuration and replies with the RRCConnectionReconfigurationComplete
message.
5. The UE starts utilizing the new LWA configuration.
22A.1.7.3 WT Release
The WT Release procedure may be initiated either by the eNB or by the WT and is used to initiate the release of the UE
context at the WT. The recipient node of this request cannot reject.
The WT Release procedure does not necessarily need to involve signalling towards the UE.
eNB initiated WT Release
3GPP
Release 17 322 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22A.1.7.3-1: WT Release procedure –eNB initiated
1. The eNB sends the WT Release Request message to request WT to release the allocated WLAN resources.
2. The WT initiates release of all allocated WLAN resources.
3. If required, the eNB sends the RRCConnectionReconfiguration message to the UE indicating the release of
WLAN radio resource configuration.
4. The UE releases the LWA configuration.
5. The UE replies with the RRCConnectionReconfigurationComplete message.
NOTE 1: It is up to UE implementation what happens with WLAN association after LWA configuration has been
released.
WT initiated WT Release
Figure 22A.1.7.3-2: WT Release procedure –WT initiated
1. The WT sends the WT Release Required message to the eNB to request the release of the allocated WLAN
resources.
2. The eNB replies with the WT Release Confirm message.
3GPP
Release 17 323 3GPP TS 36.300 V17.2.0 (2022-09)
3. The WT initiates release of all allocated WLAN resources.
4. If required, the eNB sends the RRCConnectionReconfiguration message to the UE indicating the release of
WLAN radio resource configuration.
5. The UE releases the LWA configuration.
6. The UE replies with the RRCConnectionReconfigurationComplete message.
NOTE 2: It is up to UE implementation what happens with WLAN association after LWA configuration has been
released.
22A.1.7.4 Change of WT
The change of WT procedure is initiated by eNB and used to transfer a UE context from a source WT to a target WT.
This procedure can be realized using WT Release and WT Addtion procedures.
22A.1.8 WLAN Authentication

For a UE supporting LWA, WLAN authentication is performed as follows:
If WT Counter is included in LWA Configuration in the RRC Connection Reconfiguration message, the UE shall start
using the S-KWT derived using the WT Counter value and KeNB as PMK or PSK as specified in TS 33.401 [22], clause G
and TS 36.331 [16], clause 5.6.14.2. For a UE already authenticated with WLAN, configuration of a new PMK or PSK
triggers refreshing the IEEE 802.11 security using the new PMK or PSK.
If WT Counter is not included in LWA Configuration in the RRC Connection Reconfiguration message:
- if WT Counter has not been previously configured for the UE, the UE which is not already authenticated with a
WLAN in the WLAN mobility set shall use authentication methods specified in TS 33.402 [70], clause 6;
- if WT Counter has been previously configured for the UE, the UE which is not already authenticated with a
WLAN in the WLAN mobility set shall keep using the S-KWT previously derived using the WT Counter value
and KeNB as PMK or PSK as specified in TS 33.401 [22], clause G and TS 36.331 [16], clause 5.6.14.2;
- the UE which is already authenticated with a WLAN in the WLAN mobility set continues using the previously
configured authentication method and is not required to refresh IEEE 802.11 security.
22A.2 RAN Controlled LTE WLAN Interworking

22A.2.1 General
E-UTRAN supports E-UTRAN controlled bi-directional traffic steering between E-UTRAN and WLAN for UEs in
RRC_CONNECTED: RAN Controlled WLAN Interworking (RCLWI). E-UTRAN may send a steering command to
the UE indicating to steer traffic from E-UTRAN to WLAN or from WLAN to E-UTRAN. The upper layers in the UE
shall be notified (see TS 24.302 [67]) upon reception of such a command. Upper layers determine which traffic is
offloadable to WLAN. Similarly as for LWA, two scenarios are supported depending on the backhaul connection
between LTE and WLAN (non-collocated RCLWI scenario for a non-ideal backhaul and collocated RCLWI scenario
for an ideal/internal backhaul), and the overall architecture for the non-collocated RCLWI scenario is the same as
illustrated for LWA in Figure 22A.1.1-1 above.
If the UE supporting RCLWI supports access network selection and traffic steering rules defined in TS 36.304 [11], the
UE applies the rules in RRC_IDLE using WLAN identifiers provided in WLAN mobility set. If the UE supporting
RCLWI and traffic steering rules defined in TS 36.304 [11], has not been configured with a WLAN mobility set, it
applies the broadcasted WLAN identifiers. If the UE supporting RCLWI does not support the traffic steering rules
defined in TS 36.304 [11], it keeps traffic on WLAN within the configured WLAN mobility set (if any) in RRC_IDLE
until WLAN connection fails.
E-UTRAN does not configure RCLWI with DC, LWA or LWIP simultaneously for the same UE.
If RCLWI and RAN assisted WLAN interworking are simultaneously configured for the same UE, in
RRC_CONNECTED, the UE only applies RCLWI.
3GPP
Release 17 324 3GPP TS 36.300 V17.2.0 (2022-09)

22A.2.2.1 General
Similarly as for LWA, in the non-collocated RCLWI scenario, the eNB is connected to one or more WT logical nodes
via an Xw interface and in the collocated RCLWI scenario the interface between LTE and WLAN is up to
implementation.
22A.2.2.2 User Plane Plane

There is no user plane interface defined between the eNB and the WT in RCLWI.

In the non-collocated RCLWI scenario, the Xw control plane interface (Xw-C) is defined between the eNB and the WT
and is similar to what is defined for LWA in clause 22A.1.3.3. LWA specific funtions are not part of RCLWI.
22A.2.3 Mobility
A WLAN mobility set is a set of one or more BSSID/HESSID/SSIDs, within which WLAN mobility mechanisms apply
while the UE has moved offloadable traffic to WLAN according to a steering command, i.e. the UE may perform
mobility between WLAN APs belonging to the mobility set without informing the eNB.
22A.2.4 WLAN Measurements

The UE supporting RCLWI may be configured by the E-UTRAN to perform WLAN measurements. WLAN
measurement object can be configured using WLAN identifiers (BSSID, HESSID and SSID), WLAN carrier
information and WLAN band. WLAN measurement reporting is triggered using RSSI. WLAN measurement report
contains, for each included WLAN, RSSI and WLAN identifier, and may contain WLAN carrier information, WLAN
band, channel utilization, station count, admission capacity, backhaul rate and an indication whether the UE is
connected to the WLAN.
22A.2.5 Procedure for WLAN Connection Status Reporting

The purpose of the WLAN Connection Status Reporting procedure is to provide feedback to the eNB related to the
WLAN status and operation. The WLAN Connection Status Reporting procedure supports the following indications:
1. Failure of establishing/maintaining a WLAN connection.
When a UE configured to offload to WLAN becomes unable to establish or continue WLAN offloading, the UE sends
the WLANConnectionStatusReport message to indicate to the eNB that the WLAN connection failed and the UE moves
all the offloaded traffic to E-UTRAN (see TS 24.302 [67]).
The criteria to determine WLAN connection failure is left for UE implementation.
22A.2.6 Traffic Steering Operation

22A.2.6.1 Traffic Steering from E-UTRAN to WLAN
The traffic steering from E-UTRAN to WLAN procedure is initiated by the eNB.
3GPP
Release 17 325 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22A.2.6.1-1: Traffic steering from E-UTRAN to WLAN procedure
1. The eNB sends the RRCConnectionReconfiguration message to the UE indicating the UE to steer traffic from E-
UTRAN to WLAN.
2. The UE forward the indication to upper layers and replies with RRCConnectionReconfigurationComplete
message.
3. The UE performs WLAN Association and after successful connection to WLAN, steers traffic from E-UTRAN
to WLAN (subject to upper layer).
4. If WLAN association failed, the UE sends WLANConnectionStatusReport message.
22A.2.6.2 Traffic Steering from WLAN to E-UTRAN

The traffic steering from WLAN to E-UTRAN procedure is initiated by the eNB.
Figure 22A.2.6.2-1: Traffic steering from WLAN to E-UTRAN procedure
1. The eNB sends the RRCConnectionReconfiguration message to the UE indicating the UE to steer traffic
fromWLAN to E-UTRAN.
2. The UE forward the indication to upper layers and replies with RRCConnectionReconfigurationComplete
message.
3. The UE steers traffic from WLAN to E-UTRAN.
22A.3 LTE/WLAN Radio Level Integration with IPsec Tunnel

22A.3.0 General
LTE/WLAN Radio Level Integration with IPsec Tunnel (LWIP) feature allows a UE in RRC_CONNECTED to be
configured by the eNB to utilize WLAN radio resources via IPsec tunnelling.
The overall architecture for LWIP is illustrated in Figure 22A.3-1. Connectivity between eNB and LWIP-SeGW is
provided by the Xw interface .
3GPP
Release 17 326 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22A.3-1: LWIP Overall Architecture
The protocol architecture for LWIP is illustrated in Figure 22A.3-2.
The IP Packets transferred between the UE and LWIP-SeGW are encapsulated using IPsec, as specified in TS 33.401
[22], in order to provide security to the packets that traverse WLAN.The IP packets are then transported between the
LWIP-SeGW and eNB via the Xw interface. The end to end path between the UE and eNB via the WLAN network is
referred to as the LWIP tunnel.
Figure 22A.3-2: LWIP Protocol Architecture
The end to end protocol stack for the bearer transported over the LWIP tunnel is illustrated in figure 22A.3-3.
3GPP
Release 17 327 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22A.3-3: Bearer over LWIP Tunnel - Protocol Stack
The RRCConnectionReconfiguration message provides the necessary parameters for the UE to initiate the
establishment of the IPSec tunnel for the DRB. When the IPsec tunnel is established a data bearer can be configured to
use LWIP resources. The DRB configuration on the LTE access corresponding to the data bearer using IPsec resources
shall not be released. The data bearer refers to the EPS bearer mapped to the data radio bearer (DRB) which is
maintained on the LTE side.
The IPsec tunnel is established following the exchange of security information between the eNB and LWIP-SeGW
using the XwAP LWIP Addition Preparation procedure.
A single IPSec tunnel is used per UE for all the data bearers that are configured to send and/ or receive data over
WLAN. The data corresponding to each IPSec Tunnel is transported over the Xw interface on a single GTP-U tunnel.
Each data bearer may be configured so that traffic for that bearer can be routed over the IPsec tunnel in only downlink,
only uplink, or both uplink and downlink over WLAN. SRBs are carried over LTE only. eNB configures specific
bearer(s) to use the IPsec tunnel.
NOTE: If the IPsec tunnel is established then it is expected that eNB routes packets belonging to the data bearer
via the LTE access or via the IPSec tunnel. If eNB implementation routes packets to both LTE Access
and the IPSec tunnel simultaneously, then delivery of packets to upper layers at the UE may occur out of
order.
For the DL of a data bearer, the packets received from the IPsec tunnel are forwarded directly to upper layers.
For the UL, the eNB configures the UE to route the uplink data either via LTE or via WLAN using RRC signalling. If
routed via WLAN then all UL traffic of the data bearer is offloaded to the WLAN.
UL bearer packets sent over the LWIP tunnel are encapsulated using LWIPEP as specified in TS 36.361 [68] with the
'Key' field in the LWIPEP header populated with the DRB Identity associated with offloaded UL bearer.
If aggregation over LWIP is enabled in UL or DL, the corresponding (UL or DL) packets sent over the LWIP tunnel
and LTE are encapsulated using LWIPEP as specified in TS 36.361 [68]. The LWIPEP layer assigns sequence numbers
to all packets and uses this sequence numbers to populate the 'Sequence Number' field in the LWIPEP header. The 'Key'
field in the LWIPEP header is populated with the DRB Identity of the associated DRB.
The release of the IPsec tunnel is initiated by the eNB. Upon receiving the Handover Command or on transition to
RRC_IDLE state, the UE shall autonomously release IPsec tunnel configuration and the use of it by the data bearers.
A UE supporting LWIP may be configured for WLAN measurements as per clause 22A.1.5.
The same mobility concept as specified in 22A.1.4 for LWA is also used for LWIP. Since, WT node does not exist in
LWIP operation, WT related description and procedures does not apply to LWIP. Mobility Set should be considered as
the set of WLAN APs across which UE can perform mobility without informing the eNB, when applying the concept
for LWIP operation.
E-UTRAN does not configure LWIP with DC, LWA or RCLWI simultaneously for the same UE.
If LWIP and RAN assisted WLAN interworking are simultaneously configured for the same UE, in
RRC_CONNECTED, the UE only applies LWIP.
3GPP
Release 17 328 3GPP TS 36.300 V17.2.0 (2022-09)
22A.3.1 LWIP Operation

22A.3.1.1 LWIP Tunnel Setup and Data Bearer Configuration
Figure 22A.3.1.1-1 shows the procedure of configuring a data bearer to be transported over the LWIP tunnel.
Figure 22A.3.1.1-1: LWIP Tunnel for data bearer setup procedure
1. The eNB configures the UE to perform WLAN measurements for LWIP operation.
2. The UE applies the new configuration and replies with RRCConnectionReconfigurationComplete message.
3. UE sends WLAN measurements to the eNB.
3a. The eNB sends the LWIP Addition Request message to request the LWIP-SeGW to allocate resources for a
specific UE, including security material.
3b. If the LWIP-SeGW is able to admit the tunnel request, it responds with the LWIP Addition Request
Acknowledge message.
4. The eNB sends the RRCConnectionReconfiguration message to the UE including the WLAN mobility set.
6. UE associates with WLAN in consideration of the mobility set, if not already associated.
7. UE sends confirmation of the WLAN association to the eNB.
8. The eNB sends the RRCConnectionReconfiguration message to the UE including the necessary parameters to
establish IPSec tunnel over WLAN and may, configure data bearers to utilise the IPsec tunnel.
3GPP
Release 17 329 3GPP TS 36.300 V17.2.0 (2022-09)
The UE uses the parameters in the new radio resource configuration to setup the IPsec tunnel with the LWIP-SeGW to
complete the establishment of the LWIP tunnel with the eNB over the WLAN access. eNB may add or remove data
bearers to utilise the LWIP tunnel at any time after the establishment of the LWIP tunnel by sending the
RRCConnectionReconfiguration message to the UE.
22A.3.1.2 Reconfiguration to Remove WLAN Resources from Data Bearer

Figure 22A.3.1.2-1 shows the procedure of re-configuring to remove the WLAN radio resources from the data bearer.
Figure 22A.3.1.2-1: Reconfiguration procedure to remove WLAN resources from a Data Bearer
UE and eNB have the LWIP tunnel setup via WLAN.
1. The UE is configured to receive data from a data bearer over the LWIP tunnel.
2. The eNB determines that it needs to remove the WLAN resources for the data bearer.
3. The eNB sends the RRCConnectionReconfiguration message to the UE including the necessary parameters to
remove WLAN resources for the data bearer.
5. UE stops receiving data for the data bearer over the LWIP tunnel.
22A.3.1.3 LWIP Tunnel Release

Figure 22A.3.1.3-1 shows the procedure of eNB initiated LWIP tunnel release.
3GPP
Release 17 330 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22A.3.1.3-1: LWIP tunnel release procedure
UE and eNB have the LWIP tunnel setup via WLAN.
1. The eNB determines that it needs to release the LWIP tunnel and initiates the release of the IPsec tunnel between
the UE and LWIP-SeGW.
2. The eNB sends the RRCConnectionReconfiguration message to the UE including the indication to release the
LWIP tunnel.
3. The UE applies the new configuration and replies with the RRCConnectionReconfigurationComplete message.
4. The UE releases the IPsec tunnel and associated data bearer configuration, and terminates the LWIP tunnel.
5. The eNB sends the LWIP-SeGW Tunnel Release Request message to release remaining resources at the LWIP-
SeGW.

22A.3.2.1 General
The eNB is connected to one or more LWIP-SeGWs via an Xw interface. In addition to the functionality described in
this clause and in TS 33.401 [22], LWIP-SeGW supports the subset of WT functionality and additional functionality
required to support LWIP.
22A.3.2.2 User Plane

The Xw user plane interface (Xw-U) is used between eNB and LWIP-SeGW. The Xw-U interface is used to deliver
LWIPEP PDUs between eNB and LWIP-SeGW using a single tunnel for all bearers configured for LWIP. The Xw-U
interface supports flow control based on feedback from LWIP-SeGW.

The Xw control plane interface (Xw-C) is used between eNB and LWIP-SeGW.
The LWIP-SeGW supports the following functions:
- Transfer of WLAN metrics (e.g. bss load) from LWIP-SeGW to eNB;
- Support of LWIP for UE in ECM-CONNECTED:
- Establishment, Modification and Release of a IPSec tunnel between the UE and the LWIP-SeGW;
- General Xw management and error handling functions:
- Error indication;
3GPP
Release 17 331 3GPP TS 36.300 V17.2.0 (2022-09)
- Setting up the Xw;
- Resetting the Xw;
- Updating the configuration data.
22B Xw Interface
22B.1 User Plane
The Xw user plane interface (Xw-U) is defined between eNB and WT. The Xw-U interface provides non guaranteed
delivery of user plane PDUs. The user plane protocol stack on the Xw interface is shown in Figure 22B.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 22B.1-1: Xw Interface User Plane
For LWA, if Xw-U user data bearers are associated with E-RABs for which the LWA bearer is configured, GTP-U
conveys LWAAP PDUs and a RAN Container containing flow control information. The RAN Container is carried in
the "RAN Container" field of the GTP-U extension header.
For the transfer of the uplink data, the WT may use either separate GTP-U tunnels as configured for each LWA bearer
(based on the DRB Identity), or a single GTP-U tunnel. In the latter case, the WT shall use the tunnel associated with
the lowest E-RAB ID.
22B.2 Control Plane

22B.2.0 General
The Xw control plane interface (Xw-C) is defined between an eNB and a WT. The control plane protocol stack of the
Xw interface is shown on Figure 22B.2-1 below. The transport network layer is built on SCTP on top of IP. The
application layer signalling protocol is referred to as Xw-AP (Xw Application Protocol).
3GPP
Release 17 332 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22B.2-1: Xw Interface Control Plane
22B.2.1 Xw-CP Functions

The elementary functions supported by the Xw-AP protocol are listed in TS 36.463 [69].
22B.2.2 Xw-CP Procedures

The elementary procedures supported by the Xw-AP protocol are listed in TS 36.463 [69].
22B.2.2.1 WT Addition Preparation procedure

The WT Addition Preparation procedure is initiated by the eNB to request the WT to establish LWA bearer(s) for a
specific UE.
Figure 22B.2.2.1-1: WT Addition Preparation procedure
The eNB sends a WT ADDITION REQUEST message to the WT including the LWA bearer(s) for the specific UE.
In case one or more GTP tunnel(s) at the WT has been established successfully, the WT responds with a WT
ADDITION REQUEST ACKNOWLEDGE message, which includes successfully established and failed to be
established bearers for LWA.
In case WT addition is not successful, the WT responds with WT ADDITION REQUEST REJECT message instead.
22B.2.2.2 WT Association Confirmation procedure

The WT Association Confirmation procedure is initiated by the WT to give confirmation to the eNB about the
association establishment between a specific UE and the WLAN.
3GPP
Release 17 333 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22B.2.2.2-1: WT Association Confirmation procedure
22B.2.2.3 eNB initiated WT Modification Preparation procedure

The eNB initiated WT Modification Preparation procedure is initiated by the eNB to request the WT to modify LWA
bearer(s) for a specific UE at the WT.
Figure 22B.2.2.3-1: eNB initiated WT Modification Preparation procedure
The eNB sends a WT MODIFICATION REQUEST message to the WT including the LWA bearer(s) for the specific
UE.
In case resource modification at the WT has been performed successfully, the WT responds with a WT
MODIFICATION REQUEST ACKNOWLEDGE message.
In case the WT modification is not successful the WT responds with a WT MODIFICATION REQUEST REJECT
message instead.
22B.2.2.4 WT initiated WT Modification procedure

The WT initiated WT Modification Preparation procedure is initiated by the WT to request the eNB to modify the
WLAN resources for the specific UE.
3GPP
Release 17 334 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22B.2.2.4-1: WT initiated WT Modification procedure
The WT sends a WT MODIFICATION REQUIRED message to the eNB to request to modify the WLAN resources for
the specific UE.
If the WT modification is successful, the eNB replies with a WT MODIFICATION CONFIRM message.
22B.2.2.5 eNB initiated WT Release procedure

The eNB initiated WT Release procedure is triggered by the eNB to initiate the release of the resources for a specific
UE at the WT.
Figure 22B.2.2.5-1: eNB initiated WT Release procedure
22B.2.2.6 WT initiated WT Release procedure

The WT initiated WT Release procedure is triggered by the WT to initiate the release of the resources for a specific UE
at the WT.
Figure 22B.2.2.6-1: WT initiated WT Release procedure
The WT sends a WT RELEASE REQUIRED message to the eNB to request the release of the allocated WLAN
resources for the specific UE.
If the WT release is successful, eNB replies with a WT RELEASE CONFIRM message.
22B.2.2.7 WT Status Reporting Initiation

The WT Status Reporting Initiation procedure is used by the eNB to request measurements from the WT.
3GPP
Release 17 335 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22B.2.2.7-1: WT Status Reporting Initiation procedure
The eNB sends a WT STATUS REQUEST message to the WT to request measurements from the WT.
In case the requested measurements are successfully initiated, the WT responds with a WT STATUS RESPONSE
message.
In case none of the requested measurements can be initiated, the WT responds with a WT STATUS FAILURE message
instead.
22B.2.2.8 WT Status Reporting

The WT Status Reporting procedure reports measurement results requested by the eNB as described in 22B.2.2.7.
Figure 22B.2.2.8-1: WT Status Reporting procedure
22B.2.2.9 Xw Setup procedure

The purpose of the Xw Setup procedure initiated by the eNB is to exchange application level data needed for eNB and
WT to interoperate correctly over the Xw interface. The Xw Setup procedure is triggered by the eNB. The Xw Setup
procedure is the first Xw-AP procedure which will be executed.
3GPP
Release 17 336 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22B.2.2.9-1: Xw Setup procedure
The eNB sends an Xw SETUP REQUEST message to the WT.
In case Xw setup has been performed successfully by the WT, the WT responds with an Xw SETUP RESPONSE
message.
In case Xw setup is not successful, the WT responds with an Xw SETUP FAILURE message instead.
22B.2.2.10 WT Configuration Update procedure

The purpose of the WT Configuration Update procedure initiated by the WT is to update application level configuration
data needed for the WT to interoperate correctly over the Xw interface.
Figure 22B.2.2.10-1: WT Configuration Update procedure
The WT sends a WT CONFIGURATION UPDATE message to the eNB.
In case WT Configuration Update procedure has been performed successfully by the eNB, the eNB responds with a WT
CONFIGURATION UPDATE ACKNOWLEDGE message.
In case WT Configuration Update procedure is not successful, the eNB responds with a WT CONFIGURATION
UPDATE FAILURE message instead.
22B.2.2.11 Error Indication procedure

22B.2.2.11.0 General
The Error Indication procedure is initiated by the eNB or the WT, to report an error situation in a received message,
provided it cannot be reported by an appropriate failure message.
3GPP
Release 17 337 3GPP TS 36.300 V17.2.0 (2022-09)
22B.2.2.11.1 WT initiated error indication
Figure 22B.2.2.11.1-1: Error Indication procedure initiated by WT
The WT sends the ERROR INDICATION message to report the eNB which kind of error occured.
22B.2.2.11.2 eNB initiated error indication
Figure 22B.2.2.11.2-1: Error Indication procedure initiated by eNB
The eNB sends the ERROR INDICATION message to report the WT which kind of error occured.
22B.2.2.12 Reset procedure

22B.2.2.12.0 General
The Reset procedure is initiated by the eNB/WT to align the resources with the WT/eNB in the event of an abnormal
failure. The procedure resets the whole Xw interface.
22B.2.2.12.1 WT initiated reset
Figure 22B.2.2.12.1-1: Reset procedure initiated by WT
The WT triggers the RESET message to indicate that an initialisation in the eNB is required. The eNB releases the
corresponding references and resources.
Afterwards the eNB sends the RESET RESPONSE message to confirm that the resources and references are cleared.
3GPP
Release 17 338 3GPP TS 36.300 V17.2.0 (2022-09)
22B.2.2.12.2 eNB initiated reset
Figure 22B.2.2.12.2-1: Reset procedure initiated by eNB
The eNB triggers the RESET message to indicate that an initialisation in the WT is required. The WT releases the
corresponding references and resources.
Afterwards the WT sends the RESET RESPONSE message to confirm that the resources and references are cleared.
22B.2.2.13 LWIP Addition Preparation procedure

The LWIP Addition Preparation procedure is initiated by the eNB to request the LWIP-SeGW to establish LWIP bearer
for a specific UE.
Figure 22B.2.2.13-1: LWIP-SeGW Addition Preparation procedure
The eNB sends a LWIP ADDITION REQUEST message to the LWIP-SeGW including security information for the
specific UE.
In case the GTP tunnel at the LWIP-SeGW has been established successfully, the LWIP-SeGW responds with a LWIP
ADDITION REQUEST ACKNOWLEDGE message.
In case LWIP-SeGW Addition is not successful, the LWIP-SeGW responds with LWIP ADDITION REQUEST
REJECT message instead.
22B.2.2.14 eNB initiated LWIP Modification Preparation procedure

The eNB initiated LWIP Modification Preparation procedure is initiated by the eNB to request the LWIP-SeGW to
modify resources for a specific UE at the LWIP-SeGW.
3GPP
Release 17 339 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 22B.2.2.14-1: eNB initiated LWIP-SeGW Modification Preparation procedure
The eNB sends a LWIP MODIFICATION REQUEST message to the LWIP-SeGW including requested modifications.
In case resource modification at the LWIP-SeGW has been performed successfully, the LWIP-SeGW responds with a
LWIP MODIFICATION REQUEST ACKNOWLEDGE message.
In case the LWIP-SeGW modification is not successful the LWIP-SeGW responds with a LWIP MODIFICATION
REQUEST REJECT message instead.
22B.2.2.15 eNB initiated LWIP Release procedure

The eNB initiated LWIP Release procedure is triggered by the eNB to initiate the release of the resources for a specific
UE at the LWIP-SeGW.
Figure 22B.2.2.15-1: eNB initiated LWIP-SeGW Release procedure
22B.2.2.16 LWIP-SeGW initiated LWIP Release procedure

The LWIP-SeGW initiated LWIP Release procedure is triggered by the LWIP-SeGW to initiate the release of the
resources for a specific UE at the LWIP-SeGW.
Figure 22B.2.2.16-1: LWIP-SeGW initiated LWIP-SeGW Release procedure
The LWIP-SeGW sends a LWIP RELEASE REQUIRED message to the eNB to request the release of the allocated
WLAN resources for the specific UE.
3GPP
Release 17 340 3GPP TS 36.300 V17.2.0 (2022-09)
If the LWIP-SeGW release is successful, eNB replies with a LWIP RELEASE CONFIRM message.
23 Others
23.1 Support for real time IMS services
23.1.1 IMS Emergency Call
IMS emergency calls are supported in this release of the specification and UE may initiate an IMS emergency call on
the PS domain if the network supports it. IMS Emergency call support indication is provided to inform the UE that
emergency bearer services are supported. This is sent via NAS messaging for normal service mode UE and via a BCCH
indicator for limited service mode UE TS 23.401 [17]. The BCCH indicator is set to 'support' if any of the MMEs in a
non-shared environment or one of PLMNs in a shared network environment supports IMS emergency bearer services.
If at the time of an IMS emergency call origination, the UE is already RRC connected to a CN that does not support
IMS emergency calls, it should autonomously release the RRC connection and originate a fresh RRC connection in a
cell that is capable of handling emergency calls. Call admission control for IMS emergency call is based on bearer QoS
(e.g. the ARP).
Security procedures are activated for emergency calls. For UE in limited service mode and the UE is not authenticated
(as defined in TS 33.401 [22], clause 15.2.2), 'NULL' algorithms for ciphering and integrity protection are used and the
related keys are set to specified value and may be ignored by the receiving node. During handover from cell in non-
restricted area to restricted area, security is handled normally with normal key derivation etc. for both the intra-LTE and
inter-RAT handover. For inter-RAT handover from LTE, if 'NULL' Integrity Protection algorithms are used in LTE,
security is stopped after the handover. For inter-RAT handover to LTE, security is activated after the handover with
'NULL' algorithms if security is not activated in the source RAT.
23.2 Subscriber and equipment trace

23.2.0 General
Support for subscriber and equipment trace for E-UTRAN and EPC shall be as specified in TS 32.421 [29], TS 32.422
[30] and TS 32.423 [31].
23.2.1 Signalling activation

All traces are initiated by the core network, even if the trace shall be carried out in the radio network.
If the eNB has received an UE CONTEXT RELEASE COMMAND message where the UE is associated to an E-
UTRAN Trace Id then the eNB shall terminate the on-going Trace.
The following functionality is needed on the S1 and X2 interface:
- Support for inclusion of subscriber and equipment trace information in INITIAL CONTEXT SETUP REQUEST
message over the S1 interface.
- Support for an explicit TRACE START message over the S1 interface.
- Support for inclusion of subscriber and equipment trace information in the HANDOVER REQUEST message
over the X2 interface.
- Support for inclusion of subscriber and equipment trace information in the HANDOVER REQUEST message
over the S1 interface.
- Support for TRACE FAILURE INDICATION for the purpose of informing MME that the requested trace action
cannot be performed due to an on-going handover preparation over the X2 interface.
A trace setup in the radio network will be propagated at handover. If the eNB receives trace information for a given UE,
and a handover preparation is not already ongoing for the same UE, it shall store the trace information and propagate it
to the target eNB in the case of a X2 based HO. In the case of S1 based HO, the propagation is handled by the MME.
3GPP
Release 17 341 3GPP TS 36.300 V17.2.0 (2022-09)
23.2.2 Management activation

All conditions for Cell Traffic Trace are defined by the O&M. When the condition to start the trace recording is fulfilled
the eNB will allocate a Trace Recording Session Reference and send it together with the Trace Reference to the MME
in a CELL TRAFFIC TRACE message over the S1 interface.
Cell Traffic trace actions will not be propagated on the X2 interface or on the S1 interface in case of handover.
23.3 E-UTRAN Support for Warning Systems

23.3.0 General
The E-UTRAN provides support for warning systems through means of system information broadcast capability. The
E-UTRAN performs scheduling and broadcasting of the "warning message content" received from the CBC, which is
forwarded to the E-UTRAN by the MME. The schedule information for the broadcast is received along with the
"warning message content" from the CBC. The E-UTRAN is also responsible for paging the UE to provide indication
that the warning notification is being broadcast. The "warning message content" received by the E-UTRAN contains an
instance of the warning notification. Depending on the size, E-UTRAN may segment the secondary notification before
sending it over the radio interface.
23.3.1 Earthquake and Tsunami Warning System

ETWS is a public warning system developed to meet the regulatory requirements for warning notifications related to
earthquake and/or tsunami events. ETWS warning notifications can either be a primary notification (short notifications
delivered within 4 seconds, see TS 22.168 [37]) or secondary notification (providing detailed information). The ETWS
primary notification is broadcast in SystemInformationBlockType10 while the secondary notification is broadcast in
SystemInformationBlockType11.
23.3.2 Commercial Mobile Alert System

CMAS is a public warning system developed for the delivery of multiple, concurrent warning notifications (see TS
22.268 [34]). The CMAS warning notifications are short text messages (CMAS alerts). The CMAS warning
notifications are broadcast in SystemInformationBlockType12. The E-UTRAN manages the delivery of multiple,
concurrent CMAS warning notifications to the UE and is also responsible for handling any updates of CMAS warning
notifications.
23.3.3 Korean Public Alert System

KPAS is a Korean public warning system developed for the delivery of multiple, concurrent warning notifications (see
TS 22.268 [34]). The Korean Public Alarm System (KPAS) uses the same AS mechanisms as CMAS. Therefore, the E-
UTRAN procedures defined for CMAS equally apply for KPAS.
23.3.4 EU-Alert
The European Union Warning System EU-Alert is a public warning system developed for the delivery of multiple,
concurrent warning notifications (see TS 22.268 [34]). The EU-Alert warning system uses the same AS mechanisms as
CMAS. Therefore, the E-UTRAN procedures defined for CMAS equally apply for EU-Alert.
23.4 Interference avoidance for in-device coexistence

23.4.1 Problems
In order to allow users to access various networks and services ubiquitously, an increasing number of UEs are equipped
with multiple radio transceivers. For example, a UE may be equipped with LTE, WiFi, and Bluetooth transceivers, and
GNSS receivers. Due to extreme proximity of multiple radio transceivers within the same UE operating on adjacent
frequencies or sub-harmonic frequencies, the interference power coming from a transmitter of the collocated radio may
be much higher than the actual received power level of the desired signal for a receiver. This situation causes In-Device
Coexistence (IDC) interference and is referred to as IDC problems. The challenge lies in avoiding or minimizing IDC
interference between those collocated radio transceivers, as current state-of-the-art filter technology might not provide
sufficient rejection for certain scenarios (see TR 36.816 [50]). IDC problem can happen when the UE (intends to) uses
WLAN on the overlapped carrier/band or adjacent carrier/band to the unlicensed carrier used for LAA operation, e.g.
3GPP
Release 17 342 3GPP TS 36.300 V17.2.0 (2022-09)
when related UE hardware components, such as antennas, are shared between LAA and WLAN operations. If there is a
risk of IDC problem which cannot be avoided (e.g. by level of regulation), the IDC functionality for a UE should be
configured by the eNB when the UE is configured for LAA operation.
23.4.2 Solutions
When a UE experiences IDC problems that it cannot solve by itself and a network intervention is required, it sends an
IDC indication via dedicated RRC signalling to report the IDC problems to the eNB. The UE may rely on existing LTE
measurements and/or UE internal coordination to assess the interference and the details are left up to UE
implementation.
NOTE: For instance, the interference is applicable over several subframes/slots where not necessarily all the
subframes/slots are affected and consists of interference caused by the aggressor radio to the victim radio
during either active data exchange or upcoming data activity which is expected in up to a few hundred
milliseconds.
A UE that supports IDC functionality indicates related capabilities to the network, and the network can then configure
by dedicated signalling whether the UE is allowed to send an IDC indication. The IDC indication can only be triggered
for frequencies for which a measurement object is configured and when:
- for the primary frequency, the UE is experiencing IDC problems that it cannot solve by itself;
- for a secondary frequency, regardless of the activation state of the corresponding SCell, the UE is experiencing
or expects to experience upon activation IDC problems that it cannot solve by itself;
- for a non-serving frequency, the UE expects to experience IDC problems that it cannot solve by itself if that non-
serving frequency becomes a serving one.
When notified of IDC problems through an IDC indication from the UE, the eNB can choose to apply a Frequency
Division Multiplexing (FDM) solution or a Time Division Multiplexing (TDM) solution:
- The basic concept of an FDM solution is to move the LTE signal away from the ISM band by e.g., performing
inter-frequency handover within E-UTRAN, removing SCells from the set of serving cells or de-activation of
affected SCells, or in case of uplink CA operations, allocate uplink PRB resources on CC(s) whose inter-
modulation distortion and harmonics does not fall into the frequency range of the victim system receiver.
- The basic concept of a TDM solution is to ensure that transmission of a radio signal does not coincide with
reception of another radio signal. LTE DRX mechanism is used to provide TDM patterns (i.e. periods during
which the LTE UE may be scheduled or is not scheduled) to resolve the IDC issues. DRX based TDM solution
should be used in a predictable way, i.e. the eNB should ensure a predictable pattern of unscheduled periods by
means of e.g. DRX mechanism or de-activation of affected SCells.
To assist the eNB in selecting an appropriate solution, all necessary/available assistance information for both FDM and
TDM solutions is sent together in the IDC indication to the eNB. The IDC assistance information contains the list of E-
UTRA carriers suffering from IDC problems, the direction of the interference and, depending on the scenario (see TR
36.816 [50]), it also contains TDM patterns or parameters to enable appropriate DRX configuration for TDM solutions
on the serving E-UTRA carrier. Furthermore, the IDC indication can also be configured to include uplink CA related
assistance information containing the victim system as well as the list of supported uplink CA combinations suffering
from IDC problems. Furthermore, the IDC indication can also be configured to indicate that the cause of IDC problems
is hardware sharing between LAA and WLAN operation, in which case the UE may omit the TDM assistance
information. The IDC indication is also used to update the IDC assistance information, including for the cases when the
UE no longer suffers from IDC problems. In case of inter-eNB handover, the IDC assistance information is transferred
from the source eNB to the target eNB.
IDC interference situation can be divided into following three phases as shown in Figure 23.4.2-1:
- Phase 1: The UE detects start of IDC interference but does not initiate the transmission of the IDC indication to
the eNB yet.
- Phase 2: The UE has initiated the transmission of the IDC indication to the eNB and no solution is yet
configured by the eNB to solve the IDC issue.
- Phase 3: The eNB has provided a solution that solved the IDC interference to the UE.
3GPP
Release 17 343 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 23.4.2-1: Different phases of IDC interference related operations by UE
In different phases, UE behaviours related to RRM, RLM, and CSI measurements are shown in Table 23.4.2-1.
Table 23.4.2-1: RRM/RLM/CSI measurements in different phases of IDC interference
Phases of IDC RRM Measurements RLM Measurements CSI Measurements

Interference
Phase 1 Up to UE implementation Up to UE implementation Up to UE implementation
and RRM measurement and RLM measurement and CSI measurement
requirements (see TS requirements (see TS requirements (see TS
36.133 [21]) apply 36.133 [21]) apply 36.101 [52]) apply
Phase 2 UE shall ensure the UE shall ensure the (NOTE 4)
measurements are free of measurements are free of
IDC interference and IDC interference and RLM
RRM measurement measurement
requirements (see TS requirements (see TS
36.133 [21]) apply 36.133 [21]) apply
(NOTE 4) (NOTE 1)
Phase 3 UE shall ensure the UE shall ensure the
measurements are free of measurements are free of
IDC interference and IDC interference and RLM
RRM measurement measurement
requirements (see TS requirements (see TS
36.133 [21]) apply 36.133 [21]) apply
NOTE 1: The UE should attempt to maintain connectivity to LTE in this phase meaning that RLM measurements
are not impacted by IDC interference. If no solution is provided within a time which is up to UE
implementation, the UE may need to declare RLF or it may continue to deny the ISM transmission. In
DC, when the UE experiences IDC problems in SCG, if no solution is provided within a time which is up
to UE implementation, the UE may need to declare RLF in SCG or it may continue to deny the ISM
transmission in SCG.
NOTE 2: If the UE determines in Phase 2 that the network does not provide a solution that resolves its IDC
problems, it performs measurements as defined for Phase 1.
NOTE 3: If the IDC indication message reports the IDC interference on a neighbour frequency, it performs RRM
measurements for that frequency as defined for Phase 2.
NOTE 4: When experiencing IDC problem caused by the hardware sharing between LAA and WLAN the UE
shall be allowed to relax the existing RRM/CSI measurement requirement during phase 2 (see TS
36.133 [21]).
In addition, once configured by the network, the UE can autonomously deny LTE UL transmission in all phases to
protect ISM in rare cases if other solutions cannot be used. Conversely, it is assumed that the UE also autonomously
denies ISM transmission in order to ensure connectivity with the eNB to perform necessary LTE procedures, e.g., RRC
connection reconfiguration and paging reception, etc. The network may configure a long-term denial rate by dedicated
RRC signalling to limit the amount of LTE UL autonomous denials. Otherwise, the UE shall not perform any LTE UL
autonomous denials.
23.5 TDD Enhanced Interference Management and Traffic

Adaptation (eIMTA)
TDD enhanced Interference Management and Traffic Adaptation (eIMTA) allows adaptation of uplink-downlink
configuration via L1 signalling. The E-UTRAN configures which UEs are subject to the TDD eIMTA operation.
3GPP
Release 17 344 3GPP TS 36.300 V17.2.0 (2022-09)
For Uplink scheduling and HARQ timing, the UE follows the reference uplink-downlink configuration based on the one
provided in SIB1. For Downlink HARQ timing, the UE follows the reference uplink-downlink configuration provided
through dedicated signalling.
Downlink subframes in the reference configuration provided in SIB1 remain unchanged whereas only a subset of uplink
and special subframes may be reconfigured to downlink subframes. E-UTRAN sends a L1 signalling to the UE on PCell
PDCCH to indicate which uplink-downlink configuration defined in TS 36.211 [4] is currently used for one or more
serving cell(s). This uplink-downlink configuration provided by the L1 signalling applies for a RRC-configured number
of radio frames.
The UE uses the L1-signalled uplink-downlink configuration for (E)PDCCH monitoring and CSI measurements.
The UE RRM/RLM measurements are not affected by the TDD eIMTA configuration.
For DL CSI measurements of each serving cell, two subframe sets may be configured via RRC signalling.
For PUSCH/SRS UL power control of each serving cell, two subframe sets with separate power control parameters may
be configured via RRC signalling.
Subframe-set dependent overload indication and uplink-downlink configuration intended to be used by a cell may be
exchanged between eNBs over the X2 interface to facilitate the TDD eIMTA operation.
23.6 RAN assisted WLAN interworking

23.6.0 General
This clause describes the mechanisms to support traffic steering between E-UTRAN and WLAN.
23.6.1 General principles

This version of the specification supports E-UTRAN assisted UE based bi-directional traffic steering between E-
UTRAN and WLAN for UEs in RRC_IDLE and RRC_CONNECTED.
E-UTRAN provides assistance parameters via broadcast and dedicated RRC signalling to the UE. The RAN assistance
parameters may include E-UTRAN signal strength thresholds, WLAN channel utilization thresholds, WLAN backhaul
data rate thresholds, WLAN signal strength thresholds and Offload Preference Indicator (OPI). E-UTRAN can also
provide a list of WLAN identifiers to the UE via broadcast signalling. The UE uses the RAN assistance parameters in
the evaluation of:
- Access network selection and traffic steering rules defined in TS 36.304 [11]; or
- ANDSF policies defined in TS 24.312 [58].
for traffic steering decisions between E-UTRAN and WLAN as specified in TS 23.402[19].
The OPI is only used in ANDSF policies as specified in TS 24.312 [58].
WLAN identifiers are only used in access network selection and traffic steering rules defined in TS 36.304 [11].
If the UE is provisioned with ANDSF policies it shall forward the received RAN assistance parameters to upper layers,
otherwise it shall use them in the access network selection and traffic steering rules defined in clause 23.6.2 and in TS
36.304 [11]. The access network selection and traffic steering rules defined in clause 23.6.2 and in TS 36.304 [11] are
applied only to the WLANs of which identifiers are provided by the E-UTRAN.
The UE in RRC_CONNECTED shall apply the parameters obtained via dedicated signalling if such have been received
from the serving cell; otherwise, the UE shall apply the parameters obtained via broadcast signalling.
The UE in RRC_IDLE shall keep and apply the parameters obtained via dedicated signalling, until selection/reselection
of another cell than the one where these parameters were received or a timer has expired since the UE entered
RRC_IDLE upon which the UE shall apply the parameters obtained via broadcast signalling.
In the case of RAN sharing, each PLMN sharing the RAN can provide independent sets of RAN assistance parameters.
3GPP
Release 17 345 3GPP TS 36.300 V17.2.0 (2022-09)
23.6.2 Access network selection and traffic steering rules

The UE indicates to upper layers when (and for which WLAN identifiers) access network selection and traffic steering
rules defined in TS 36.304 [11] are fulfilled. The selection among WLANs that fulfil the access network selection and
traffic steering rules is up to UE implementation.
When the UE applies the access network selection and traffic steering rules defined in TS 36.304 [11], higher layers
perform traffic steering between E-UTRAN and WLAN.
23.7 Support of Low Complexity UEs

Low complexity UEs are targeted to low-end (e.g. low average revenue per user, low data rate, delay tolerant)
applications, e.g. some Machine-Type Communications.
A low complexity UE has reduced Tx and Rx capabilities compared to other UE of different categories.
A Category 0 low complexity UE may access a cell only if SIB1 indicates that access of Category 0 UEs is supported. If
the cell does not support access of Category 0 UEs, the UE considers the cell as barred.
The eNB determines that a UE is a Category 0 UE based on the LCID for CCCH and the UE capability.
The S1 signalling has been extended to include the UE Radio Capability for paging. This paging specific capability
information is provided by the eNB to the MME, and the MME uses this information to indicate to the eNB that the
paging request from the MME concerns a low complexity UE.
23.7a Support of Bandwidth Reduced Low Complexity UEs

A bandwidth reduced low complexity (BL) UE can operate in any LTE system bandwidth but with a limited channel
bandwidth of 6 PRBs (corresponding to the maximum channel bandwidth available in a 1.4 MHz LTE system) in
downlink and uplink. Interworking with NR is not supported by BL UE (e.g. functions like NR measurement reporting,
reselection to NR, handover to NR, redirection to NR are not supported).
To enable higher data rates a BL UE can optionally support a larger maximum PDSCH/PUSCH channel bandwidth of
24 PRBs in downlink and a non-BL UE operating in enhanced coverage can optionally support a larger maximum
PDSCH/PUSCH channel bandwidth of 24 or 96 PRBs in downlink, and 24 PRBs in uplink in connected mode for
unicast transmission. Table 23.7.a-1 summarizes the maximum PDSCH/PUSCH bandwidth in connected mode for
unicast transmission depending on the UE category and enhanced coverage mode (see clause 23.7b). The maximum
PDSCH/PUSCH channel bandwidth is configured separately for PDSCH and PUSCH via dedicated RRC signaling.
Table 23.7a-1: Maximum PDSCH/PUSCH bandwidth (in PRBs)
UE category/CE mode CE mode A CE mode B
BL (Category M1) 6/6 6/6
BL (Category M2) 24/24 24/6

Non-BL (Category 0 and 96 (or
96 (or 24)/6
higher) 24)/24
A BL UE may access a cell only if the MIB of the cell indicates that scheduling information for SIB1 specific for BL
UEs is scheduled. If not, the UE considers the cell as barred.
A BL UE receives a separate occurrence of system information blocks (sent using different time/frequency resources).
A BL UE has a transport block size (TBS) limited to 1000 bit for broadcast. The BL UE determines the scheduling
information for SIB1 specific for BL UEs based on information in MIB. Scheduling information for other SIBs is given
in SIB1 specific for BL UEs. The BCCH modification period for BL UEs is a multiple of the BCCH modification
period provided in SIB2. The SIB transmission occasions within an SI-window are provided in the SIB1 specific for BL
UEs. A BL UE can acquire SI messages across SI windows. The maximum number of SI messages that can be acquired
across SI windows is 4. A BL UE is not required to detect SIB change when in RRC_CONNECTED.
3GPP
Release 17 346 3GPP TS 36.300 V17.2.0 (2022-09)
A BL UE is paged based on paging occasions in time domain, and paging narrowbands in frequency domain. The
starting subframe of a paging occasion is determined in the same way as the paging occasion in the legacy paging
mechanism.
A set of PRACH resources (e.g. time, frequency, preamble), each associated with BL UEs in normal coverage, is
provided in SIB. Number of PRACH repetitions and number of maximum preamble transmission attempts for BL UEs
in normal coverage are provided in SIB. Time/frequency resources and repetition factor for random access response
messages for BL UEs are derived from the used PRACH resources.
23.7b Support of UEs in Enhanced Coverage

A UE in enhanced coverage is a UE that requires the use of enhanced coverage functionality to access the cell. In this
release of the specification two enhanced coverage modes (mode A, mode B) are supported. The support of enhanced
coverage mode A is mandatory for a BL UE. The maximum PDSCH/PUSCH bandwidth in connected mode for unicast
transmission depends on the UE category and enhanced coverage mode as summarized in table 23.7a-1.
A UE may access a cell using enhanced coverage functionality only if the MIB of the cell indicates that scheduling
information for SIB1 specific for BL UEs is scheduled. System information procedures for UEs in enhanced coverage
are identical to the system information procedures for bandwidth reduced low complexity UEs. A UE capable of
enhanced coverage acquires, if needed, and uses legacy system information when in normal coverage if it is not a BL
UE. A UE capable of enhanced coverage acquires, if needed, and uses system information specific for UEs in enhanced
coverage. A UE in enhanced coverage is not required to detect SIB change when in RRC_CONNECTED.
A set of PRACH resources (e.g. time, frequency, preamble); each associated with a coverage enhancement level, is
provided in SIB. Number of PRACH repetitions and number of maximum preamble transmission attempts per coverage
enhancement level are provided in SIB. UEs in same enhanced coverage level use random access resources associated
with the same enhanced coverage level. Time/frequency resources and repetition factor for random access response
messages for UEs in enhanced coverage are derived from the used PRACH resources.
A UE in enhanced coverage is paged using the same mechanism for paging BL UEs. The starting subframe of a paging
occasion and the repetition pattern (in both time and frequency domain for downlink common control signaling) of that
paging occasion are determined irrespective of the UEs enhanced coverage level.
The paging request from the MME or the AMF for a UE supporting enhanced coverage functionality may contain
enhanced coverage level related information and corresponding cell ID. If neither the UE Radio Capability for Paging
IE nor the Assistance Data for Paging IE is included in the paging request from the MME or the AMF, the (ng-)eNB
may need to page the UE in both PDCCH and MPDCCH.
A UE in RRC_IDLE does not inform the network when it changes the enhanced coverage level.
A UE in enhanced coverage camps on a suitable cell where S criterion for UEs in enhanced coverage is fullfilled.The
UE shall re-select to inter-frequency cells in which it is able to operate in normal coverage over cells in which it has to
be in enhanced coverage.
Connected mode mobility mechanisms such as measurement reporting, network controlled handover etc., are supported
for UEs in enhanced coverage. At handover from a source cell in normal or enhanced coverage mode to a target cell in
enhanced coverage mode, the network may provide SIB1-BR to the UE in the handover command. No additional
mechanisms are introduced to support the use of enhanced coverage functionality to access an E-UTRA cell during
inter-RAT handovers.
Reconfiguration of a UE in connected mode from normal to enhanced coverage mode (and vice versa) is supported by a
means of intra-cell handover or RRC configuration without handover.
23.8 Support for Radio Interface based Synchronization

Radio-interface based synchronization (RIBS) enables an eNB to monitor the reference signals of another eNB for the
purpose of over the air synchronization by means of network listening. This requires OAM to configure the eNBs with
reference signal information, i.e. pattern, periodicity and offset, where the reference signals are available. The OAM
should coordinate the reference signal information, for example via one to one mapping between stratum level and
reference signal. To improve the hearability of reference signals, the listening eNB may request the interfering eNB(s)
to enable subframe muting by means of network signalling.
3GPP
Release 17 347 3GPP TS 36.300 V17.2.0 (2022-09)
23.9 Network-assisted interference cancellation/suppression

A UE that supports network assisted interference cancellation/suppression (NAICS) receiver functionality can mitigate
PDSCH and CRS interference from aggressor cells in order to better receive a PDSCH from its serving cell.
The network may configure the UE with NAICS information of the aggressor cells in order to help the UE to mitigate
the PDSCH and CRS interference of the aggressor cells. To support NAICS, an eNB may exchange NAICS information
with its neighbour eNBs through X2 signalling.
23.10 Support for sidelink communication

23.10.1 General
Sidelink communication is a mode of communication whereby UEs can communicate with each other directly over the
PC5 interface, as specified in TS 23.303 [62]. This communication mode is supported when the UE is served by E-
UTRAN and when the UE is outside of E-UTRA coverage. Only those UEs authorised to be used for public safety
operation can perform sidelink communication.
In order to perform synchronisation for out of coverage operation UE(s) may act as a synchronisation source by
transmitting SBCCH and a synchronisation signal. SBCCH carries the most essential system information needed to
receive other sidelink channels and signals. SBCCH along with a synchronisation signal is transmitted with a fixed
periodicity of 40ms. When the UE is in network coverage, the contents of SBCCH are derived from the parameters
signalled by the eNB. When the UE is out of coverage, if the UE selects another UE as a synchronisation reference,
then the content of SBCCH is derived from the received SBCCH; otherwise UE uses pre-configured parameters. SIB18
provides the resource information for synchronisation signal and SBCCH transmission. There are two pre-configured
subframes every 40ms for out of coverage operation. UE receives synchronisation signal and SBCCH in one subframe
and transmit synchronisation signal and SBCCH on another subframe if UE becomes synchronisation source based on
defined criterion, as specified in [16].
UE performs sidelink communication on subframes defined over the duration of Sidelink Control period. The Sidelink
Control period is the period over which resources allocated in a cell for sidelink control information and sidelink data
transmissions occur. Within the Sidelink Control period the UE sends sidelink control information followed by sidelink
data. Sidelink control information indicates a Layer 1 ID and characteristics of the transmissions (e.g. MCS, location of
the resource(s) over the duration of Sidelink Control period, timing alignment).
The UE performs transmission and reception over Uu and PC5 with the following decreasing priority order in case
Sidelink Discovery Gap is not configured:
- Uu transmission/reception (highest priority);
- PC5 sidelink communication transmission/reception;
- PC5 sidelink discovery announcement/monitoring (lowest priority).
The UE performs transmission and reception over Uu and PC5 with the following decreasing priority order in case
Sidelink Discovery Gap is configured:
- Uu transmission/reception for RACH;
- PC5 sidelink discovery announcement during a Sidelink Discovery Gap for transmission;
- Non-RACH Uu transmission;
- PC5 sidelink discovery monitoring during a Sidelink Discovery Gap for reception;
- Non-RACH Uu reception;
- PC5 sidelink communication transmission/reception.
3GPP
Release 17 348 3GPP TS 36.300 V17.2.0 (2022-09)

23.10.2.0 General
In this clause, the UE radio protocol architecture for sidelink communication is given for the user plane and the control
plane.
23.10.2.1 User plane

Figure 23.10.2.1-1 shows the protocol stack for the user plane, where PDCP, RLC and MAC sublayers (terminate at the
other UE) perform the functions listed for the user plane in clause 6.
The Access Stratum protocol stack in the PC5 interface consists of PDCP, RLC, MAC and PHY as shown below in
Figure 23.10.2.1-1.
Figure 23.10.2.1-1: User-Plane protocol stack for sidelink communication
User plane details of sidelink communication:
- There is no HARQ feedback for sidelink communication;
- RLC UM is used for sidelink communication;
- A receiving UE needs to maintain at least one RLC UM entity per transmitting peer UE;
- A receiving RLC UM entity used for sidelink communication does not need to be configured prior to reception
of the first RLC UMD PDU;
- ROHC Unidirectional Mode is used for header compression in PDCP for sidelink communication;
- UDC is not used for sidelink communication.
A UE may establish multiple logical channels. LCID included within the MAC subheader uniquely identifies a logical
channel within the scope of one Source Layer-2 ID and Destination Layer-2 ID combination. Parameters for logical
channel prioritization are not configured. The Access stratum (AS) is provided with the PPPP of a protocol data unit
transmitted over PC5 interface by higher layer. There is a PPPP associated with each logical channel.
23.10.2.2 Control plane

A UE does not establish and maintain a logical connection to receiving UEs prior to one-to-many a sidelink
communication. Higher layer establishes and maintains a logical connection for one-to-one sidelink communication
including ProSe UE-to-Network Relay operation.
The Access Stratum protocol stack for SBCCH in the PC5 interface consists of RRC, RLC, MAC and PHY as shown
below in Figure 23.10.2.2-1.
3GPP
Release 17 349 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 23.10.2.2-1: Control-Plane protocol stack for SBCCH
The control plane for establishing, maintaining and releasing the logical connection for one-to-one sidelink
communication is shown in Figure 23.10.2.2-2.
Figure 23.10.2.2-2: Control-Plane protocol stack for one-to-one sidelink communication
23.10.3 Radio resource allocation

23.10.3.0 General
The UE supporting sidelink communication can operate in two modes for resource allocation:
- Scheduled resource allocation is characterized by:
- The UE needs to be RRC_CONNECTED in order to transmit data;
- The UE requests transmission resources from the eNB. The eNB schedules transmission resources for
transmission of sidelink control information and data;
- The UE sends a scheduling request (D-SR or Random Access) to the eNB followed by a Sidelink BSR.
Based on the Sidelink BSR the eNB can determine that the UE has data for a sidelink communication
transmission and estimate the resources needed for transmission. eNB can schedule transmission
resources for sidelink communication using configured SL-RNTI.
- UE autonomous resource selection is characterized by:
- A UE on its own selects resources from resource pools and performs transport format selection to transmit
sidelink control information and data;
- There can be up to 8 transmission pools either pre-configured for out of coverage operation or provided by
RRC signalling for in-coverage operation. Each pool can have one or more PPPP associated with it. For
transmission of a MAC PDU, the UE selects a transmission pool in which one of the associated PPPP is
equal to the PPPP of a logical channel with highest PPPP among the logical channel identified in the MAC
PDU. It is up to UE implementation how the UE selects amongst multiple pools with same associated PPPP.
There is a one to one association between sidelink control pool and sidelink data pool;
- Once the resource pool is selected, the selection is valid for the entire Sidelink Control period. After the
Sidelink Control period is finished the UE may perform resource pool selection again.
NOTE: The UE is allowed to perform multiple transmissions to different destinations in a single Sidelink Control
period.
3GPP
Release 17 350 3GPP TS 36.300 V17.2.0 (2022-09)
A UE in RRC_CONNECTED may send a Sidelink UE Information message to eNB when UE becomes interested in
sidelink communication. In response eNB may configure the UE with a SL-RNTI.
A UE is considered in-coverage for sidelink communication whenever it detects a cell on a Public Safety ProSe Carrier
as per criteria specified in, as specified in TS 36.331 [16]. The following rules apply for the UE:
- If the UE is out of coverage for sidelink communication it can only use UE autonomous resource selection;
- If the UE is in coverage for sidelink communication it may use scheduled resource allocation or UE autonomous
resource selection as per eNB configuration;
- If the UE is in coverage for sidelink communication it shall use only the resource allocation mode indicated by
eNB configuration unless one of the exceptional cases as specified in TS 36.331 [16] occurs:
- When an exceptional case occurs the UE is allowed to use UE autonomous resource selection temporarily
even though it was configured to use scheduled resource allocation. Resource pool to be used during
exceptional case may be provided by eNB.
A UE that is camped or connected on one carrier frequency but interested in sidelink communication operation on
another carrier frequency (i.e. Public Safety ProSe Carrier) shall attempt to find cells on the Public Safety ProSe
Carrier.
- An RRC_IDLE UE camped on a cell in another carrier frequency, but in the coverage area of an E-UTRA cell
on Public Safety ProSe Carrier may consider the Public Safety ProSe carrier to be the highest priority; and
reselects to the cell on the Public Safety ProSe Carrier. UE may consider a frequency (non-Public Safety ProSe
carrier) to be the highest priority if it can perform sidelink communication only while camping on the frequency.
- An RRC_CONNECTED UE served by a cell in another carrier frequency may send a Sidelink UE Information
message to its serving cell when it wants to perform sidelink communication. The indication contains the
intended Public Safety ProSe Carrier:
- The serving cell indicates with the presence of SIB18 whether the UE is allowed to send a ProSe UE
Information indication;
- The serving cell may configure an inter-frequency RRM measurement on the Public Safety ProSe Carrier;
- Once the UE enters coverage of a cell on the Public Safety ProSe Carrier, based on measurement report the
eNB performs inter-frequency mobility to the Public Safety ProSe Carrier;
- If inter-frequency mobility is not performed by the serving cell (e.g. the serving cell does not broadcast
SIB18 or if handover fails), the UE may still perform sidelink communication using UE autonomous resource
selection from the resource pools, if any, broadcasted by the detected E-UTRA cell on the Public Safety
ProSe Carrier.
- If the UE does not detect an E-UTRA cell on the Public Safety ProSe Carrier, the UE can use Public Safety
ProSe Carrier resources preconfigured in the UICC or ME for out of coverage sidelink communication;
- If the UE detects an E-UTRA cell on the Public Safety ProSe Carrier, the UE stops using resources
preconfigured in the UICC or ME. UE may use UE autonomous resource selection from the resource pools, if
any, broadcasted by the detected E-UTRA cell on the Public Safety ProSe Carrier.
NOTE: For Rel-12 all ProSe communication (for a UE) is performed on a single preconfigured Public Safety
ProSe Carrier, which is valid in the operating region. Higher layers check validity of the Public Safety
ProSe Carrier in the operating region.
The cell on the Public Safety ProSe Carrier may select one of the following options:
- The cell on the Public Safety ProSe Carrier may provide a transmission resource pool for UE autonomous
resource selection in SIB18:
- UEs that are authorized for sidelink communication may use these resources for sidelink communication in
RRC_IDLE in the cell on the same carrier (i.e. Public Safety ProSe Carrier);
- UEs that are authorized for sidelink communication may use these resources for sidelink communication in
RRC_IDLE or RRC_CONNECTED in a cell on another carrier.
3GPP
Release 17 351 3GPP TS 36.300 V17.2.0 (2022-09)
- The cell on the Public Safety ProSe Carrier may indicate in SIB18 that it supports sidelink communication but
does not provide transmission resources. UEs need to enter RRC_CONNECTED to perform sidelink
communication transmission. In this case the cell on the Public Safety ProSe Carrier may provide in broadcast
signalling an exceptional transmission resource pool for UE autonomous resource selection, to be used by the
UE in exceptional cases, as specified in TS 36.331 [16]:
- A UE in RRC_CONNECTED that is authorized to perform sidelink communication transmission indicates to

the serving eNB that it wants to perform sidelink communication transmissions;
- The eNB validates whether the UE is authorized for sidelink communication transmission using the UE
context received from MME;
- The eNB may configure a UE by dedicated signalling with a transmission resource pool for UE autonomous
resource selection; that may be used without constraints while the UE is in RRC_CONNECTED.
Alternatively, the eNB may configure a UE to use the exceptional transmission resource pool for UE
autonomous resource selection which the UE is allowed to use only in exceptional cases, as specified in TS
36.331 [16], and rely on scheduled resource allocation otherwise.
23.10.3.1 Resource Pool for sidelink control information

A set of transmission and reception resource pools for sidelink control information when the UE is out of coverage for
sidelink communication is pre-configured in the UE.
The resource pools for sidelink control information when the UE is in coverage for sidelink communication are
configured as below:
- The resource pools used for reception are configured by the eNB via RRC, in broadcast signalling;
- The resource pool used for transmission is configured by the eNB via RRC, in dedicated or broadcast signalling,
if UE autonomous resource selection is used;
- The resource pool used for transmission is configured by the eNB via RRC, in dedicated signalling if scheduled
resource allocation is used:
- The eNB schedules the specific resource(s) for sidelink control information transmission within the
configured reception pools.
NOTE: In order to perform communication even when some UEs are in-coverage and some UEs are out of
coverage, all UEs (i.e. both in and out of coverage) should be configured with resource pools for
reception of sidelink control information which are the union of the resource pools used for transmission
of sidelink control information from a) the serving cell, b) neighbour cells and c) out of coverage (i.e. pre-
configured transmission resource pools).
23.10.3.2 Resource Pool for sidelink data

A set of transmission and reception resource pools for data when the UE is out of coverage for sidelink communication
is pre-configured in the UE.
The resource pools for data when the UE is in coverage for sidelink communication are configured as below:
- The resource pools used for transmission and reception are configured by the eNB via RRC, in dedicated or
broadcast signalling, if UE autonomous resource selection is used;
- There is no resource pool for transmission and reception if scheduled resource allocation is used.
23.10.4 Sidelink Communication via ProSe UE-to-Network Relay

A ProSe UE-to-Network Relay provides a generic L3 forwarding function that can relay any type of IP traffic between
the Remote UE and the network. One-to-one and one-to-many sidelink communications are used between the Remote
UE(s) and the ProSe UE-to-Network Relay. For both Remote UE and Relay UE only one single carrier (i.e., Public
Safety ProSe Carrier) operation is supported (i.e., Uu and PC5 should be same carrier for Relay/ Remote UE). The
Remote UE is authorised by upper layers and can be in-coverage of the Public Safety ProSe Carrier or out-of-coverage
on any supported carriers including Public Safety ProSe Carrier for UE-to-Network Relay discovery, (re)selection and
communication. The ProSe UE-to-Network Relay is always in-coverage of EUTRAN. The ProSe UE-to-Network Relay
3GPP
Release 17 352 3GPP TS 36.300 V17.2.0 (2022-09)
and the Remote UE perform sidelink communication and sidelink discovery as described in clause 23.10 and 23.11
respectively.
The eNB controls whether the UE can act as a ProSe UE-to-Network Relay:
- If the eNB broadcast any information associated to ProSe UE-to-Network Relay operation, then ProSe UE-to-
Network Relay operation is supported in the cell;
- The eNB may provide:
- Transmission resources for ProSe UE-to-Network Relay discovery using broadcast signalling for RRC_IDLE
state and dedicated signalling for RRC_CONNECTED state;
- Reception resources for ProSe UE-to-Network Relay discovery using broadcast signalling;
- The eNB may broadcasts a minimum and/or a maximum Uu link quality (RSRP) threshold(s) that the ProSe
UE-to-Network Relay needs to respect before it can initiate a UE-to-Network Relay discovery procedure. In
RRC_IDLE, when the eNB broadcasts transmission resource pools, the UE uses the threshold(s) to
autonomouslystartor stop the UE-to-Network Relay discovery procedure. In RRC_CONNECTED, the UE
uses the threshold(s) to determine if it can indicate to eNB that it is a Relay UE and wants to start ProSe UE-
to-Network Relay discovery;
- If the eNB does not broadcast transmission resource pools for ProSe-UE-to-Network Relay discovery, then a
UE can initiate a request for ProSe-UE-to-Network Relay discovery resources by dedicated signalling,
respecting these broadcasted threshold(s).
- If the ProSe-UE-to-Network Relay is initiated by broadcast signalling, it can perform ProSe UE-to-Network
Relay discovery when in RRC_IDLE. If the ProSe UE-to-Network Relay is initiated by dedicated signalling, it
can perform relay discovery as long as it is in RRC_CONNECTED.
A ProSe UE-to-Network Relay performing sidelink communication for ProSe UE-to-Network Relay operation has to be
in RRC_CONNECTED. After receiving a layer-2 link establishment request or TMGI monitoring request (upper layer
message), as specified in TS 23.303 [62], from the Remote UE, the ProSe UE-to-Network Relay indicates to the eNB
that it is a ProSe UE-to-Network Relay and intends to perform ProSe UE-to-Network Relay sidelink communication.
The eNB may provide resources for ProSe UE-to-Network Relay communication.
The remote UE can decide when to start monitoring for ProSe UE-to-Network Relay discovery. The Remote UE can
transmit ProSe UE-to-Network Relay discovery solicitation messages while in RRC_IDLE or in RRC_CONNECTED
depending on the configuration of resources for ProSe UE-to-Network Relay discovery. The eNB may broadcast a
threshold, which is used by the Remote UE to determine if it can transmit ProSe UE-to-Network Relay discovery
solicitation messages, to connect or communicate with ProSe UE-to-Network Relay UE. The RRC_CONNECTED
Remote UE, uses the broadcasted threshold to determine if it can indicate to eNB that it is a Remote UE and wants to
participate in ProSe UE-to-Network Relay discovery and/or communication. The eNB may provide, transmission
resources using broadcast or dedicated signalling and reception resources using broadcast signalling for ProSe UE-to-
Network Relay Operation. The Remote UE stops using ProSe UE-to-Network Relay discovery and communication
resources when RSRP goes above the broadcasted threshold.
NOTE: Exact time of traffic switching from Uu to PC5 or vice versa is up to higher layer.
The Remote UE performs radio measurements at PC5 interface and uses them for ProSe UE-to-Network Relay
selection and reselection along with higher layer criterion, as specified in TS 23.303 [62]. A ProSe UE-to-Network
Relay is considered suitable in terms of radio criteria if the PC5 link quality exceeds configured threshold (pre-
configured or provided by eNB). The Remote UE selects the ProSe UE-to-Network Relay, which satisfies higher layer
criterion and has best PC5 link quality among all suitable ProSe UE-to-Network Relays.
The Remote UE triggers ProSe UE-to-Network Relay reselection when:
- PC5 signal strength of current ProSe UE-to-Network Relay is below configured signal strength threshold;
- It receives a layer-2 link release message (upper layer message), as specified in TS 23.303 [62], from ProSe UE-
to-Network Relay.
3GPP
Release 17 353 3GPP TS 36.300 V17.2.0 (2022-09)
23.11 Support for sidelink discovery

23.11.1 General
Sidelink discovery is defined as the procedure used by the UE supporting sidelink discovery to discover other UE(s) in
its proximity, using E-UTRA direct radio signals via PC5. Sidelink discovery is supported both when UE is served by
EUTRAN and when UE is out of EUTRA coverage. Only ProSe-enabled Public safety UE can perform sidelink
discovery when it is out of EUTRA coverage. For public safety sidelink discovery the allowed frequency is pre-
configured in the UE, and is used even when UE is out of coverage of EUTRA in that frequency. The pre-configured
frequency is the same frequency as the Public Safety ProSe Carrier.
Figure 23.11.1-1: PC5 interface for sidelink discovery (see TS 23.303 [62])
Upper layer handles authorization for announcement and monitoring of discovery message.
Content of discovery message is transparent to Access Stratum (AS) and no distinction in AS is made for sidelink
discovery models and types of sidelink discovery, as specified in TS 23.303 [62]. However higher layer informs
whether the sidelink discovery announcement is related to public safety or non-Public safety discovery. Higher layer
also informs whether the discovery announcement/monitoring is related to ProSe UE-to-Network Relay discovery or
other public safety discovery.
NOTE: The ProSe Protocol ensures that only valid discovery messages are delivered to AS for announcement.
The UE can participate in announcing and monitoring of discovery message in both RRC_IDLE and
RRC_CONNECTED states as per eNB configuration. The UE announces and monitors its discovery message subject to
the half-duplex constraint.
The UE that participates in announcing and monitoring of discovery messages maintains the current UTC time. The UE
that participates in announcing transmits the discovery message, which is generated by the ProSe Protocol taking into
account the UTC time upon transmission of the discovery message. In the monitoring UE, the ProSe Protocol provides
the message to be verified together with the UTC time upon reception of the message to the ProSe Function.
NOTE: UE may obtain UTC time from the RAN via SIB16 or from other sources such as NITZ, NTP, and GNSS
depending on their availability.
In order to perform synchronisation UE(s) participating in announcing of discovery messages may act as a
synchronisation source by transmitting SBCCH and a synchronisation signal based on the resource information for
synchronisation signals provided in SIB19.
There are three range classes. Upper layer authorisation provides applicable range class of the UE. Maximum allowed
transmission power for each range class is signalled in SIB19. UE uses the applicable maximum allowed transmission
power corresponding to its authorised range class. This puts an upper limit on the determined transmit power based on
open loop power control parameters.

The Access Stratum protocol stack for sidelink discovery consists of only MAC and PHY.
The AS layer performs the following functions:
- Interfaces with upper layer (ProSe Protocol): The MAC layer receives the discovery message from the upper
layer (ProSe Protocol). The IP layer is not used for transmitting the discovery message;
3GPP
Release 17 354 3GPP TS 36.300 V17.2.0 (2022-09)
- Scheduling: The MAC layer determines the radio resource to be used for announcing the discovery message
received from upper layer;
- Discovery PDU generation: The MAC layer builds the MAC PDU carrying the discovery message and sends the
MAC PDU to the physical layer for transmission in the determined radio resource. No MAC header is added.
23.11.3 Radio resource allocation

There are two types of resource allocation for discovery message announcement.
- UE autonomous resource selection: A resource allocation procedure where resources for announcing of
discovery message are allocated on a non UE specific basis, further characterized by:
- The eNB provides the UE(s) with the resource pool configuration used for announcing of discovery message.
The configuration may be signalled in broadcast or dedicated signalling;
- The UE autonomously selects radio resource(s) from the indicated resource pool and announces discovery
message;
- The UE can announce discovery message on a randomly selected discovery resource during each discovery
period.
- Scheduled resource allocation: A resource allocation procedure where resources for announcing of discovery
message are allocated on per UE specific basis, further characterized by:
- The UE in RRC_CONNECTED may request resource(s) for announcing of discovery message from the eNB
via RRC;
- The eNB assigns resource(s) via RRC;
- The resources are allocated within the resource pool that is configured in UEs for announcement.
For UEs in RRC_IDLE:
- The eNB may select one of the following options:
- The eNB may provide resource pools for UE autonomous resource selection based discovery message
announcement in SIB19. UEs that are authorized for sidelink discovery use these resources for announcing
discovery message in RRC_IDLE;
- The eNB may indicate in SIB19 that it supports sidelink discovery but does not provide resources for
discovery message announcement. UEs need to enter RRC_CONNECTED in order to request resources for
discovery message announcement.
For UEs in RRC_CONNECTED:
- A UE authorized to perform sidelink discovery announcement indicates to the eNB that it wants to perform
sidelink discovery announcement. A UE can also indicate to the eNB the frequency(s) in which sidelink
discovery announcement is desired;
- The eNB validates whether the UE is authorized for sidelink discovery announcement using the UE context
received from MME;
- The eNB may configure the UE with resource pool for UE autonomous resource selection for discovery message
announcement via dedicated signalling;
- The eNB may configure resource pool along with dedicated resource in the form of time and frequency indices
for discovery message announcement via dedicated RRC signalling;
- The resources allocated by the eNB via dedicated signalling are valid until;
- The eNB re-configures the resource(s) by RRC signalling or;
- The UE enters RRC_IDLE.
3GPP
Release 17 355 3GPP TS 36.300 V17.2.0 (2022-09)
Authorised receiving UEs in RRC_IDLE and RRC_CONNECTED monitor resource pools used for UE autonomous
resource selection and resource pools for scheduled resource allocation. The eNB provides the resource pool
configuration used for discovery message monitoring on intra frequency, inter frequency of same or different PLMNs
cells in RRC signalling (SIB19). The RRC signalling (SIB19 or dedicated) may contain detailed sidelink discovery
configuration used for announcement of sidelink discovery in cells of intra-frequency, inter-frequency of same or
different PLMNs.
Synchronous and asynchronous deployments are supported. Discovery resources can be overlapping or non-overlapping
across cells.
A UE, if authorised by the NW, can announce discovery messages in the same as well as other frequencies than the
serving cell, in same or different PLMNs. The UE can monitor discovery resources in the same as well as other
frequencies than the serving cell, in same or different PLMNs:
- The serving cell may provide in SIB19 a list of frequencies along with PLMN ID on which the UE may aim to
monitor discovery message. The serving cell may provide in SIB19 a list of frequencies along with PLMN ID on
which the UE is allowed to announce discovery message.
- The serving cell may not provide detailed sidelink discovery configuration and cell (re)selection parameters for
other carrier frequencies of same or other PLMNs in RRC signalling.
- If detailed sidelink discovery configuration and cell (re)selection parameters for other frequencties of same or
different PLMN is not provided by serving cell in SIB19, the eNB may indicate if the UE should read SIB19 and
other relevant SIBs on other carriers or the UE should request detailed sidelink discovery configuration from
serving cell, if it wants to perform discovery message announcement on those carriers of same or other PLMNs.
A UE only reads SIB19 and other relevant SIBs of authorised carriers and authorised PLMN:
- Obtaining sidelink discovery configuration by reading SIB19 (and other SIBs) of an inter-frequency and/or
inter-PLMN cell shall not affect the UE's Uu reception on the serving cell(s).
- If a UE performs sidelink discovery announcement on another frequency, irrespective of whether the eNB
provides cell (re)selection parameters for the other frequency of same or different PLMN, the UE follows the
same legacy cell (re)selection procedure.
- If SIB19 is not broadcasted by the serving cell, the UE may perform sidelink discovery announcement and
monitoring on another carrier of same or different PLMN that is authorised by the network, as long as it does not
affect Uu operation.
- The UE is not expected to perform any PLMN change for the purpose of inter-PLMN sidelink discovery
announcement.
- If the UE autonomously reads SIB 19 of the other carrier of same or different PLMN to acquire resource for
sidelink discovery announcement and that carrier does not provide resources for sidelink discovery
announcement in SIB19, then the UE shall not perform sidelink discovery announcement on that carrier.
- The UE performs intra-frequency and inter-frequency of same or different PLMN sidelink discovery
announcement or monitoring in subframes in which a sidelink discovery resource pool is configured.
- To enhance intra-frequency and inter-frequency sidelink discovery performance for the non-dedicated
transceiver case the eNB may provide gaps to the UE, so that RF transmitter/receiver chain can be reused for
sidelink discovery transmissions/receptions:
- The gaps provided for sidelink discovery transmission and/or reception takes into account any additional
overhead (e.g. for synchronization, subframe offset between serving carrier and sidelink discovery carrier,
interruption time for retuning). The eNB can deconfigure a configured sidelink discovery transmission and
/or reception gaps.
- Configured discovery gaps are applicable for all configured cells of a UE.
- If SIB19 is not broadcasted by the serving cell the UE shall not enter RRC_CONNECTED on the serving cell
to request gaps or resources for sidelink discovery announcement.
- The eNB may indicate in broadcast or dedicated signalling if the UE can request gaps. Based on
implementation the UE can trigger a gap request for sidelink discovery announcement or monitoring. In the
3GPP
Release 17 356 3GPP TS 36.300 V17.2.0 (2022-09)
request the UE informs the eNB of the subframes (with respect to the timing of serving cell) on which the UE
needs gaps.
NOTE: The UE is not expected to monitor any physical downlink channels during sidelink discovery reception
gaps. During transmission gap, the UE prioritizes discovery announcement over Uu uplink transmission
and sidelink communication transmission only when a conflict with sidelink discovery announcement
occurs. The UE prioritizes the RACH procedure over the sidelink gaps.
NOTE: Measurement requirements on the serving frequency should not be affected by sidelink gaps.
- If network does not configure transmission and reception gaps for sidelink discovery.
- Intra-frequency, inter-frequency of same and other PLMN sidelink discovery announcement shall not affect
Uu transmission:
- Intra-frequency, inter-frequency and inter-PLMN sidelink discovery monitoring shall not affect Uu reception:
- The UE shall not create autonomous gaps for announcement or monitoring of sidelink discovery.
- The UE uses DRX occasions in RRC_IDLE and RRC_CONNECTED or second RX chain if it is available,
for intra- frequency, inter-frequency and inter-PLMN discovery message monitoring;
- An RRC_CONNECTED UE sends a Sidelink UE Information message to the serving cell if it is interested or no

longer interested in intra-frequency, inter-frequency or inter-PLMN discovery message monitoring.
If the S-Criteria on the ProSe carrier for Public Safety is not met, the UE can use Public Safety ProSe Carrier discovery
resources preconfigured in the UICC or ME for out of coverage sidelink discovery.
NOTE: All sidelink discovery for Public Safety (for a UE) is performed on a single preconfigured Public Safety
ProSe Carrier, which is valid in the operating region. Higher layers check validity of the Public Safety
ProSe Carrier in the operating region.
23.12 Resource usage reporting for shared networks

The eNB may be configured to report the resource usage as data volume for the different PLMN identities of the
operators in a shared network. The measurements, which are defined in TS 36.314 [63], are based on the QoS parameter
values exchanged at E-RAB setup/modification.
OAM configures data volume reporting criteria. The configured data volume criteria define the PLMN IDs and the QoS
profile criteria for the collection and reporting. The data volume reports are per configured PLMN ID and per
configured QoS profile per DL/UL.
The QoS profile configuration shall be the same for all configured PLMN IDs and for all eNBs. The configured QoS
profile criteria can differ in UL and DL in terms of GBR ranges. It shall be possible to collect and report up to 200
counter types and a maximum of 200 counter instances.
Data volumes for the DL/UL direction of a GBR bearer shall be collected within a given DL/UL GBR range if the
DL/UL E-RAB guaranteed bit rate is within a configured DL/UL range delimited by a minimum and maximum value.
The GBR ranges shall be five in number for DL and five in number for UL. GBR ranges shall be non-overlapping and
configurable. The configured set of GBR ranges applies to the whole RAN and to all PLMN IDs in the RAN.
23.13 Optimising signalling load and resource usage for paging

23.13.1 General paging optimisation
Paging can be optimised by the MME and the E-UTRAN as described in TS 23.401 [17].
As a part of this, an eNB may inform the MME about a list of recommended eNBs for paging. If a recommended eNB
in this list is a HeNB behind a HeNB GW, the paging target is identified by the TAI instead of the eNB identity.
Paging Attempt Information consists of a Paging Attempt Count and the Intended Number of Paging Attempts and may
include the Next Paging Area Scope. If Paging Attempt Information is included in the Paging message, each paged eNB
receives the same information during a paging attempt. The Paging Attempt Count shall be increased by one at each
new paging attempt. The Next Paging Area Scope, when present, indicates whether the MME plans to modify the
3GPP
Release 17 357 3GPP TS 36.300 V17.2.0 (2022-09)
paging area currently selected at next paging attempt. If the UE has changed its mobility state to ECM CONNECTED
the Paging Attempt Count is reset.
23.13.2 Paging optimisation for UEs in enhanced coverage

Information on the coverage enhancement (CE) level, if available for the UE, is provided transparently by the serving
eNB to the MME at transition to ECM_IDLE together with the respective cell identifier and is provided to the E-
UTRAN during paging. The Paging Attempt Information, as defined in 23.13.1, is always provided to all paged eNBs
for UEs for which the information on the coverage enhancement level has been received.
23.14 Support for V2X services

23.14.1 General
23.14.1.0 Overview
Vehicular communication services, represented by V2X services, can consist of the following four different types:
V2V, V2I, V2N and V2P, as specified in TS 22.185 [71].
V2X services can be provided by PC5 interface and/or Uu interface. Support of V2X services via PC5 interface is
provided by V2X sidelink communication as specified in TS 23.285 [72] and/or NR sidelink communication as
specified in TS 23.287 [93], which are modes of communication whereby UEs can communicate with each other
directly over the PC5 interface. Both communication modes may be supported when the UE is served by E-UTRAN
and when the UE is outside of E-UTRA coverage. Only the UEs authorised to be used for V2X services can perform
V2X sidelink communication and/or NR sidelink communications for V2X services.
23.14.1.1 Support for V2X sidelink communication

The user plane protocol stack and functions, as specified in clause 23.10.2.1 for sidelink communication, are also used
for V2X sidelink communication. In addition, for V2X sidelink communication:
- STCH for sidelink communication is also used for V2X sidelink communication.
- Non-V2X (e.g. Public Safety) data is not multiplexed with V2X data transmitted in resources configured for
V2X sidelink communication.
- The Access Stratum (AS) is provided with the PPPP and PPPR of a protocol data unit transmitted over PC5
interface by upper layers. The packet delay budget (PDB) of the protocol data unit can be determined from the
PPPP. The low PDB is mapped to the high priority PPPP value (TS 23.285 [72]).
- The Access Stratum (AS) is provided with a transmit profile (TS 23.285 [72]) of a protocol data unit transmitted
over PC5 interface by upper layers.
- The logical channel prioritization based on PPPP is used for V2X sidelink communication.
Control plane protocol stack for SBCCH as specified in clause 23.10.2.2 for sidelink communication is also used for
V2X sidelink communication.
The UE supporting V2X sidelink communication can operate in two modes for resource allocation:
- Scheduled resource allocation, characterized by:
- The UE needs to be RRC_CONNECTED in order to transmit data;
- The UE requests transmission resources from the eNB. The eNB schedules transmission resources for
transmission of sidelink control information and data. Sidelink SPS is supported for scheduled resource
allocation;
- UE autonomous resource selection, characterized by:
- The UE on its own selects resources from resource pools and performs transport format selection to transmit
sidelink control information and data;
3GPP
Release 17 358 3GPP TS 36.300 V17.2.0 (2022-09)
- If mapping between the zones and V2X sidelink transmission resource pools is configured, the UE selects
V2X sidelink resource pool based on the zone UE is located in.
- The UE performs sensing for (re)selection of sidelink resources. Based on sensing results, the UE (re)selects
some specific sidelink resources and reserves multiple sidelink resources. Up to 2 parallel independent
resource reservation processes are allowed to be performed by the UE. The UE is also allowed to perform a
single resource selection for its V2X sidelink transmission.
In order to assist the eNB to provide sidelink resources, the UE in RRC_CONNECTED may report geographical
location information to the eNB. The eNB can configure the UE to report the complete UE geographical location
information based on periodic reporting via the existing measurement report signaling.
Geographical zones can be configured by the eNB or pre-configured. When zones are (pre)configured, the world is
divided into geographical zones using a single fixed reference point (i.e. geographical coordinates (0, 0)), length and
width. The UE determines the zone identity by means of modulo operation using length and width of each zone, number
of zones in length, number of zones in width, the single fixed reference point and the geographical coordinates of the
UE's current location. The length and width of each zone, number of zones in length and number of zones in width are
provided by the eNB when the UE is in coverage and pre-configured when the UE is out of coverage. The zone is
configurable for both in coverage and out of coverage.
For in coverage UE, when the UE uses UE autonomous resource selection, the eNB can provide the mapping between
zone(s) and V2X sidelink transmission resource pools in RRC signalling. For out of coverage UEs, the mapping
between the zone(s) and V2X sidelink transmission resource pools can be pre-configured. If a mapping between zone(s)
and V2X sidelink transmission resource pool is (pre-)configured, the UE selects transmission sidelink resources from
the resource pool corresponding to the zone where it is currently located. The zone concept is not applied to exceptional
V2X sidelink transmission pools as well as reception pools. Resource pools for V2X sidelink communication are not
configured based on priority.
For V2X sidelink transmission, during handover, transmission resource pool configurations including exceptional
transmission resource pool for the target cell can be signaled in the handover command to reduce the transmission
interruption. In this way, the UE may use the V2X sidelink transmission resource pools of the target cell before the
handover is completed as long as either synchronization is performed with the target cell in case eNB is configured as
synchronization source or synchronization is performed with GNSS in case GNSS is configured as synchronization
source. If the exceptional transmission resource pool is included in the handover command, the UE uses randomly
selected resources from the exceptional transmission resource pool, starting from the reception of handover command.
If the UE is configured with scheduled resource allocation in the handover command, the UE continues to use the
exceptional transmission resource pool while the timer associated with handover is running. If the UE is configured
with autonomous resource selection in the target cell the UE continues to use the exceptional transmission resource pool
until the sensing results on the transmission resource pools for autonomous resource selection are available. For
exceptional cases (e.g. during RLF, during transition from RRC IDLE to RRC CONNECTED or during change of
dedicated V2X sidelink resource pools within a cell), the UE may select resources in the exceptional pool provided in
serving cell's SIB21 or in dedicated signalling based on random selection, and uses them temporarily. During cell
reselection, the RRC_IDLE UE may use the randomly selected resources from the exceptional transmission resource
pool of the reselected cell until the sensing results on the transmission resource pools for autonomous resource selection
are available.
In order to avoid interruption time in receiving V2X messages due to delay in acquiring reception pools broadcasted
from the target cell, synchronisation configuration and reception resource pool configuration for the target cell can be
signaled to RRC_CONNECTED UEs in the handover command. For RRC_IDLE UE, it is up to UE implementation to
minimize V2X sidelink transmission/reception interruption time associated with acquisition of SIB21 of the target cell.
A UE is considered in-coverage on the carrier used for V2X sidelink communication whenever it detects a cell on that
carrier as per criteria specified in TS 36.331 [16]. If the UE that is authorized for V2X sidelink communication is in-
coverage on the frequency used for V2X sidelink communication or if the eNB provides V2X sidelink configuration for
that frequency (including the case where UE is out of coverage on that frequency), the UE uses the scheduled resource
allocation or UE autonomous resource selection as per eNB configuration. When the UE is out of coverage on the
frequency used for V2X sidelink communication and if the eNB does not provide V2X sidelink configuration for that
frequency, the UE may use a set of transmission and reception resource pools pre-configured in the UE. V2X sidelink
communication resources are not shared with other non-V2X data transmitted over sidelink.
An RRC_CONNECTED UE may send a Sidelink UE Information message to the serving cell if it is interested in V2X
sidelink communication transmission in order to request sidelink resources.
3GPP
Release 17 359 3GPP TS 36.300 V17.2.0 (2022-09)
If the UE is configured by upper layers to receive V2X sidelink communication and V2X sidelink reception resource
pools are provided, the UE receives on those provided resources.
Reception of V2X sidelink communication in different carriers/PLMNs can be supported by having multiple receiver
chains in the UE.
For sidelink SPS, maximum 8 SPS configurations with different parameters can be configured by eNB and all SPS
configurations can be active at the same time. The activation/deactivation of SPS configuration is signalled via PDCCH
by eNB. The existing logical channel prioritization based on PPPP is used for sidelink SPS.
UE assistance information can be provided to eNB. Reporting of UE assistance information is configured by eNB for
V2X sidelink communication. The UE assistance information used for V2X sidelink communication includes traffic
characteristic parameters (e.g. a set of preferred SPS interval, timing offset with respect to subframe 0 of the SFN 0,
PPPP, PPPR, Destination Layer-2 ID, and maximum TB size based on observed traffic pattern) related to the SPS
configuration. The UE assistance information can be reported in case either SPS is already configured or not. Triggering
of UE assistance information transmission is left to UE implementation. For instance, the UE is allowed to report UE
assistance information when change in estimated periodicity and/or timing offset of packet arrival occurs. SR mask per
traffic type is not supported for V2X sidelink communication.
The serving cell can provide synchronization configuration for the carrier used for V2X sidelink communication. In this
case, the UE follows the synchronization configuration received from serving cell. In case there is no cell detected on
the carrier used for V2X sidelink communication and the UE does not receive synchronization configuration from
serving cell, the UE follows preconfigured synchronization configuration. There are three types of synchronization
reference, namely eNB, UE and GNSS. In case GNSS is configured as synchronization source, the UE utilizes the UTC
time and (pre)configured DFN offset to calculate direct frame number and subframe number. In case eNB timing is
configured as synchronization reference to the UE, for synchronization and DL measurements, the UE follows the cell
associated with the concerned frequency (when in-coverage on this frequency), or the PCell or the serving cell (when
out of coverage on the concerned frequency). UE can indicate the current synchronization reference type it is using to
the eNB. One transmission pool for scheduled resource allocation is configured, taking into account the synchronization
reference of the UE.
For controlling channel utilization, the network is able to indicate how the UE adapts its transmission parameters for
each transmission pool depending on the Channel Busy Ratio (CBR). The UE measures all the configured transmission
pools including exceptional pool. If a pool is (pre)configured such that a UE shall always transmit PSCCH and PSSCH
in adjacent resource blocks the UE measures PSCCH and PSSCH resources together. If a pool is (pre)configured such
that a UE may transmit PSCCH and the corresponding PSSCH in non-adjacent resource blocks in a subframe then
PSSCH pool and PSCCH pool are measured separately.
A UE in RRC_CONNECTED can be configured to report CBR measurement results. For CBR reporting, periodic
reporting and event triggered reporting are supported. Two reporting events are introduced for event-triggered CBR
reporting. In case PSSCH and PSCCH resources are placed non-adjacently, only PSSCH pool measurement is used for
event-triggered CBR reporting. In case PSSCH and PSCCH resources are placed adjacently, CBR measurement of both
the PSSCH and PSCCH resources is used for event-triggered CBR reporting. Event-triggered CBR reporting is
triggered by overloaded threshold and/or less-loaded threshold. The network can configure which of the transmission
pools the UE needs to report.
A UE (regardless of its RRC state) performs transmission parameter adaptation based on the CBR. In case PSSCH and
PSCCH resources are placed non-adjacently, only PSSCH pool measurement is used for transmission parameter
adaptation. In case PSSCH and PSCCH resources are placed adjacently, CBR measurement of both the PSSCH and
PSCCH resources is used for transmission parameter adaptation. When CBR measurements are not available, the
default transmission parameters are used. The exemplary adapted transmission parameters include maximum
transmission power, range of the number of retransmission per TB, range of PSSCH RB number, range of MCS,
maximum limit on channel occupancy ratio. The transmission parameter adaption applies to all transmission pools
including exceptional pool.
A UE using scheduled resource allocation may be configured to perform sensing and periodically report the sensing
result. The UE performs sensing only in the V2X sidelink transmission resource pool(s) for which reporting is
configured.
For V2X sidelink communication, sidelink transmission and/or reception resources including exceptional pool for
different frequencies for scheduled resource allocation and UE autonomous resource selection may be provided. The
sidelink resources for different frequencies can be provided via dedicated signalling, SIB21 and/or preconfiguration.
The serving cell may indicate to the UE only the frequency on which the UE may acquire the resource configuration for
3GPP
Release 17 360 3GPP TS 36.300 V17.2.0 (2022-09)
V2X sidelink communication. If multiple frequencies and associated resource information are provided, it is up to UE
implementation to select the frequency among the provided frequencies. The UE shall not use preconfigured
transmission resource if the UE detects a cell providing resource configuration or inter-carrier resource configuration
for V2X sidelink communication. Frequencies which may provide V2X sidelink communication resource configuration
or cross-carrier configuration can be signalled in SIB21 or pre-configured in the UE. The RRC_IDLE UE may prioritize
the frequency that provides cross-carrier resource configuration for V2X sidelink communication during cell
reselection.
If the UE supports multiple transmission chains, it may simultaneously transmit on multiple carriers via PC5. For the
case where multiple frequencies for V2X are supported, a mapping between V2X service types and V2X frequencies is
configured by upper layers. The UE should ensure a V2X service to be transmitted on the corresponding frequency. For
scheduled resource allocation, the eNB can schedule a V2X transmission on a frequency based on the Sidelink BSR, as
specified in TS 36.321 [13], in which the UE includes the Destination Index uniquely associated with a frequency
reported by the UE to the eNB in Sidelink UE Information message as specified in TS 36.331 [16].
Carrier aggregation (CA) in sidelink is supported for V2X sidelink communication. It applies to both in coverage UEs
and out of coverage UEs. For CA in sidelink, neither primary component carrier nor secondary component carriers are
defined. Each resource pool (pre)configured for V2X sidelink communication transmission or reception is associated to
a single carrier. When a UE supporting CA in sidelink uses autonomous resource selection, it performs carrier selection
and may select one or more carriers used for V2X sidelink communication transmission. The carrier selection is
performed at MAC layer, depending on the CBR of the (pre)configured carriers for V2X sidelink communication and
the PPPP(s) of the V2X messages to be transmitted. The carrier reselection may be performed when resource
reselection is triggered and is triggered for each sidelink process. In order to avoid frequent switching across different
carriers, the UE may keep using a carrier already selected for transmission, if the measured CBR on this carrier is lower
than a (pre)configured threshold. All selected carriers should have the same synchronization reference or the same
synchronization priority configuration. For a UE using autonomous resource selection, logical channel prioritization is
performed for a sidelink resource on a carrier depending on the CBR measured on the carrier and the PPPP of the
sidelink logical channels as specified in TS 36.321 [13].
Sidelink packet duplication is supported for V2X sidelink communication and is performed at PDCP layer of the UE.
For sidelink packet duplication for transmission, a PDCP PDU is duplicated at the PDCP entity. The duplicated PDCP
PDUs of the same PDCP entity are submitted to two different RLC entities and associated to two different sidelink
logical channels respectively. The duplicated PDCP PDUs of the same PDCP entity are only allowed to be transmitted
on different sidelink carriers. A UE can activate or deactivate sidelink packet duplication based on (pre)configuration.
Sidelink packet duplication does not apply to transmission with Rel-14 transmit profile (TS 23.285 [72]). The PPPR
value(s) for which sidelink packet duplication is supported can be (pre)configured via a PPPR threshold. For UE
autonomous resource selection and scheduled resource allocation, the UE shall perform sidelink packet duplication for
the data with the configured PPPR value(s) until packet duplication is deconfigured for these PPPR value(s). For
scheduled resource allocation, the UE reports the amount of data associated with one or more PPPR values, and the
destination(s) to which the data belongs via sidelink BSR(s). A mapping of PPPR values to logical channel groups can
be configured by the eNB, and the PPPR value(s) are reflected by the associated logical channel group ID included in
the sidelink BSR(s). A list of PPPR value(s) may be reported in Sidelink UE information by an RRC_CONNECTED
UE.
For a UE using scheduled resource allocation, two non-overlapped sets of carriers are configured by the eNB per
Destination reported by the UE to the network, and they apply to all the PPPR(s) that are configured for sidelink packet
duplication. The UE then associates two duplicated sidelink logical channels corresponding to the same PDCP entity
respectively with the two sets of carriers configured for the Destination of the two sidelink logical channels. The
association between the duplicated sidelink logical channel and the carrier set is up to UE implementation. Data of a
duplicated sidelink logical channel can only be transmitted on the carrier(s) in the associated carrier set.
For V2X sidelink communication reception, packet duplication detection is performed at PDCP layer of the UE.
Reordering function is also supported at PDCP layer and how to set the reordering timer at the PDCP layer is up to UE
implementation. There are specific logical channel identities which apply to the sidelink logical channel used for
sidelink packet duplication exclusively as specified in TS 36.321 [13].
The UE may receive the V2X sidelink communication of other PLMNs. The serving cell can indicate to the UE the
resource configuration for V2X sidelink communication reception for inter-PLMN operation directly or only the
frequency on which the UE may acquire the inter-PLMN resource configuration for V2X sidelink communication
reception. V2X sidelink communication transmission in other PLMNs is not allowed.
When UL transmission overlaps in time domain with V2X sidelink transmission in the same frequency, the UE
prioritizes the V2X sidelink transmission over the UL transmission if the PPPP of sidelink MAC PDU is lower than a
3GPP
Release 17 361 3GPP TS 36.300 V17.2.0 (2022-09)
(pre)configured PPPP threshold; otherwise, the UE prioritizes the UL transmission over the V2X sidelink transmission.
When UL transmission overlaps in time domain with V2X sidelink transmission in different frequency, the UE may
prioritize the V2X sidelink transmission over the UL transmission or reduce UL transmission power if the PPPP of
sidelink MAC PDU is lower than a (pre)configured PPPP threshold; otherwise, the UE prioritizes the UL transmission
over the V2X sidelink transmission or reduces V2X sidelink transmission power. However, if UL transmission is
prioritized by upper layer as specified in TS 24.386 [75] or random access procedure is performed, the UE prioritizes
UL transmission over any V2X sidelink transmission (i.e. irrespectively of the sidelink MAC PDU's PPPP).
Resource pool for transmission of pedestrian UE (P-UE) may be overlapped with resources for V2X sidelink
communication. For each transmission pool, resource selection mechanism (i.e. random selection, partial sensing based
selection or either random selection or partial sensing based selection), which is allowed to be used in this pool, is also
configured. If P-UE is configured to use either random selection or partial sensing based selection for one transmission
pool, it is up to UE implementation to select a specific resource selection mechanism. If the P-UE is configured to use
partial sensing based selection only, the P-UE shall use partial sensing based selection in the pool. The P-UE shall not
do random selection in the pool wherein only partial sensing is allowed. If the eNB does not provide a random selection
pool, the P-UEs that support only random selection cannot perform sidelink transmission. In exceptional pool, the P-UE
uses random selection. The P-UE can send Sidelink UE Information message to indicate that it requests resource pools
for P2X-related V2X sidelink communication transmission as specified in TS 36.331 [16].
It is not mandatory for P-UE to support zone based resource selection. The P-UE reports whether it supports zone based
resource selection as part of UE capability signalling. If the P-UE supports zone based resource selection, the network
can provide zone based configuration via only dedicated signalling.
Power saving of P-UE can be achieved by UE implementation and upper layer mechanisms. P-UE does not perform
CBR measurement. However, P-UE adjusts the transmission parameters based on the default transmission parameter
configuration, which can be provided to the P-UE via RRC signalling.
To support the co-existence of CEN DSRC and V2X sidelink communication, the upper layers of the UE which is
performing V2X sidelink communication send an indication to lower layers when the UE is within the proximity of
CEN DSRC tolling station(s).
23.14.1.2 Support for V2X communication via Uu

For V2X communication in uplink, maximum 8 SPS configurations with different parameters can be configured by
eNB and all SPS configurations can be active at the same time. The activation/deactivation of each SPS configuration is
signalled via PDCCH by eNB. The existing logical channel prioritization for Uu is used.
For V2X communication, UE assistance information can be provided to eNB. Reporting of UE assistance information is
configured by eNB. The UE assistance information includes parameters (e.g. a set of preferred SPS interval, timing
offset with respect to subframe 0 of the SFN 0, LCID and maximum TB size based on observed traffic pattern) related
to the SPS configuration. Triggering of UE assistance information transmission is left to UE implementation. For
instance, the UE is allowed to report the UE assistance information when change in estimated periodicity and/or timing
offset of packet arrival occurs. For V2X communication via Uu, SR mask as per legacy mechanism can be used.
For unicast transmission of V2X messages, the V2X message can be delivered via Non-GBR bearers as well as GBR
bearers. In order to meet the QoS requirements for V2X message delivery for V2X services, a Non-GBR QCI value and
a GBR QCI value for V2X messages are used as specified in TS 23.285 [72].
For broadcasting V2X messages, SC-PTM or MBSFN transmission can be used. In order to reduce SC-PTM/MBSFN
latency, shorter (SC-)MCCH repetition period for SC-PTM/MBSFN, modification period for SC-PTM/MBSFN and
MCH scheduling period for MBSFN are supported. Reception of downlink broadcast of V2X messages in different
carriers/PLMNs can be supported by having multiple receiver chains in the UE. A GBR QCI value is used for the
delivery of V2X messages over MBMS bearers as specified in TS 23.285 [72].
23.14.1.3 Void
23.15 Support for MMTEL voice and video enhancements

23.15.1 RAN-assisted codec adaptation
RAN-assisted codec adaptation provides a means for the eNB to send codec adaptation indication with recommended
bit rate to assist the UE to select or adapt to a codec rate for MMTEL voice or MMTEL video. The RAN-assisted codec
adaptation mechanism supports the uplink/downlink bit rate increase or decrease. For a bearer associated with
3GPP
Release 17 362 3GPP TS 36.300 V17.2.0 (2022-09)
configuration of MBR greater than GBR (see clauses 11.4 and 13.2), the recommended uplink/downlink bit rate is
within boundaries set by the MBR and GBR of the concerned bearer.
For uplink or downlink bit rate adaptation, eNB may send a recommended bit rate to the UE to inform the UE on the
currently recommended transport bit rate on the local uplink or downlink, which the UE may use in combination with
other information to adapt the bit rate, e.g. the UE may send a bit rate request to the peer UE via application layer
messages as specified in TS 26.114 [74], which the peer UE may use in combination with other information to adapt the
codec bit rate. The recommended bit rate is in kbps at the physical layer at the time when the decision is made.
The recommended bit rate for UL and DL is conveyed as a MAC Control Element (CE) from the eNB to the UE as
outlined in Figure 23.15.1-1.
Figure 23.15.1-1: UL or DL bit rate recommendation
Based on the recommended bit rate from the eNB, a UE may initiate an end-to-end bit rate adaptation with its peer (UE
or MGW). The UE may also send a query message to its local eNB to check if a bit rate recommended by its peer can
be provided by the eNB. The UE is not expected to go beyond the recommended bit rate from the eNB.
The recommended bit rate query message is conveyed as a MAC Control Element (CE) from the UE to the eNB as
outlined in Figure 23.15.1-2.
Figure 23.15.1-2: UL or DL bit rate recommendation query
A prohibit timer can be configured per logical channel by the network to limit UEs sending frequent query MAC CEs.
Independent prohibit timers are used for each direction (uplink and downlink) to prohibit the UE from retransmitting
exactly the same query MAC CE to the eNB during the configured time.
23.15.2 MMTEL signalling optimisation

In case of network congestion (e.g. maximum number of users that can be connected, poor radio conditions, etc), an
operator may want to prioritize MMTEL voice/MMTEL video access. For both type of accesses, the MO voice call
cause value is used.
During the re-direction procedure, if the UE receives the RRC Connection Release message with redirection and the
voice call is ongoing, the UE keeps the call in the application layer. After the UE re-accesses the network, the voice
GBR bearer can be recovered immediately.
23.15.3 MMTEL voice quality/coverage enhancements

In order to enhance the voice quality and coverage, the techniques for PUSCH coverage enhancement introduced in
Rel-13 for CE Mode A can be configured also for UEs in non-CE mode. These techniques are applied in a new PUSCH
enhancement mode and include:
3GPP
Release 17 363 3GPP TS 36.300 V17.2.0 (2022-09)
- PUSCH subframe repetition with intra-bundle or inter-bundle frequency hopping and
- UL asynchronous HARQ operation.
The PUSCH enhancement mode can be enabled only on PCell. In the PUSCH enhancement mode, the PUSCH
maximum bandwidth is 20MHz. The UE transition between normal mode and PUSCH enhancement mode is controlled
and triggered by RRC signalling, As part of the transition procedure, the UL HARQ operation switches between
synchronous (normal mode) and asynchronous (PUSCH enhancement mode), with a partial MAC reset.
PUSCH coverage enhancement requires that air interface delay budget can be relaxed to increase the robustness of the
transmission. Such relaxation may be achieved when a UE in good coverage indicates a preference to the eNB to reduce
the local air interface delay by sending a UEAssistanceInformation message with delayBudgetReport set to type1 to
decrease the DRX cycle length, so that the E2E delay and jitter can be reduced. The peer UE in bad coverage can send a
UEAssistanceInformation message with delayBudgetReport set to type2 to its eNB to indicate a preference on Uu air
interface delay adjustments, see TS 36.331 [16], TS 36.211 [4] and TS 36.213 [6]. Based on the UE report and other
information, the E-UTRAN may configure the UE with coverage enhancement techniques. When the UE detects
changes such as end-to-end MMTEL voice quality or local radio quality, the UE may inform the eNB its new
preference by sending UEAssistanceInformation messages with updated contents.
23.16 Application Layer Measurement Collection

This function enables collection of application layer measurements from the UE. The supported service types are QoE
Measurement Collection for streaming services and QoE Measurement Collection for MTSI services. The feature is
activated by Trace Function from the MDT framework (see clause 19.2.1.17 and TS 37.320 [43]). Both signalling based
and management based initiation cases are allowed. For the signalling based case, the Application Layer Measurement
Collection is initiated towards a specific UE from CN nodes using the MDT mechanism as described in clause 5.1.3 of
TS 37.320 [43]; for the management based case, the Application Layer Measurement Collection is initiated from OAM
targeting an area (without targeting a specific UE).
Application layer measurement configuration received from OAM or CN is encapsulated in a transparent container,
which is forwarded to UE in a downlink RRC message. Application layer measurements received from UE's higher
layer are encapsulated in a transparent container and sent to network in an uplink RRC message, as specified in TS
36.331 [16]. The application layer measurement configuration and measurement reporting are supported in
RRC_CONNECTED state only. E-UTRAN can release the application layer measurement configuration towards the
UE at any time.
23.17 Support for Aerial UE communication

23.17.1 General
E-UTRAN based mechanisms providing LTE connection to UEs capable of Aerial communication are supported via the
following functionalities:
- subscription-based Aerial UE identification and authorization, as specified in TS 23.401 [17], clause 4.3.31.
- height reporting based on the event that the UE's altitude has crossed a network-configured reference altitude
threshold.
- interference detection based on a measurement reporting that is triggered when a configured number of cells (i.e.
larger than one) fulfills the triggering criteria simultaneously.
- signalling of flight path information from UE to E-UTRAN.
- Location information reporting, including UE's horizontal and vertical velocity.
23.17.2 Subscription based identification of Aerial UE function

Support of Aerial UE function is stored in the user's subscription information in HSS. HSS transfers this information to
the MME during Attach, Service Request and Tracking Area Update procedures.
The subscription information can be provided from the MME to the eNB via the S1-AP Initial Context Setup Request
during Attach, Tracking Area Update and Service Request procedures. The subscription information can also be
3GPP
Release 17 364 3GPP TS 36.300 V17.2.0 (2022-09)
updated via the S1-AP UE Context Modification Request message. In addition, for X2-based handover, the source
eNodeB can include the subscription information in the X2-AP Handover Request message to the target eNodeB.
For the intra and inter MME S1 based handover, the MME provides the subscription information to the target eNB after
the handover procedure.
23.17.3 Height based reporting for Aerial UE communication

An aerial UE can be configured with event based height reporting. UE sends height report when the altitude of the aerial
UE is above or below a configured threshold. The report contains height and location if configured as described in
23.17.6.
23.17.4 Interference detection and mitigation for Aerial UE communication

For interference detection, an aerial UE can be configured with RRM event A3, A4 or A5 that triggers measurement
report when individual (per cell) RSRP values for a configured number of cells fulfill the configured event. Once such
condition is met and a measurement report is sent, the list of triggered cells is updated when subsequent cell(s) fulfil the
event, however further measurement reports are not sent while the list of triggered cells remains larger than the
configured number of cells. The report contains RRM results and location if configured, as described in 23.17.6.
For interference mitigation an aerial UE can be configured with a dedicated UE-specific alpha parameter for PUSCH
power control.
23.17.5 Flight path information reporting

E-UTRAN can request a UE to report flight path information consisting of a number of waypoints defined as 3D
locations as defined in TS 36.355 [78]. A UE reports up to configured number of waypoints if flight path information is
available at the UE. The report can consist also time stamps per waypoint if configured in the request and if available at
the UE.
23.17.6 Location reporting for Aerial UE communication

Location information for Aerial UE communication can include horizontal and vertical speed if configured. Location
information can be included in RRM report and in height report.
23.18 PDCP packet duplication

PDCP packet duplication is configured for a RB by RRC where two logical channels are configured for the RB. The
two logical channels can either belong to the same MAC entity (referred to as CA duplication) or different MAC
entities (referred to as DC duplication). When activated, PDCP packet duplication allows sending the same PDCP PDU
on two independent transmission paths: via the primary RLC entity and a secondary RLC entity, thus increasing
reliability and reducing latency.
PDCP packet duplication is supported in the following cases:
- for SRBs using RLC AM;
- for DRBs using RLC UM or AM.
For DRBs, duplication can be activated and deactivated by a MAC CE. In addition, for DRBs, PDCP packet duplication
can be activated upon configuration by RRC signalling. For SRBs, once duplication is configured, it is always activated.
When PDCP packet duplication is activated, the associated logical channels are restricted to be sent only on certain
serving cells to ensure the duplicates are sent on different serving cells. The restriction is lifted when PDCP packet
duplication is deactivated. When CA duplication is configured for an SRB, one of the logical channels associated to the
SRB is restricted to be sent only on the serving cells including PCell and PSCell.
At the receiver, PDCP enables reordering and duplication detection when PDCP packet duplication is configured.
When activating duplication for a DRB, E-UTRAN should ensure that at least one serving cell is activated for each
logical channel of the DRB; and when the deactivation of SCells leaves no serving cells activated for a logical channel
of the DRB, E-UTRAN should ensure that duplication is also deactivated.
3GPP
Release 17 365 3GPP TS 36.300 V17.2.0 (2022-09)
23.19 E-UTRAN control for NR sidelink communication

NR sidelink communication may be used to support other services than V2X services as in clause 23.14.1.0. When the
UE is served by E-UTRAN, if the UE supports and is authorized to perform NR sidelink communication in E-UTRAN,
NR sidelink communication can be configured and controlled by E-UTRAN via dedicated signaling and/or system
information, using the procedures specified in TS 38.300 [79], with the following restrictions to operation of NR
sidelink communication controlled by E-UTRAN:
- Dynamic sidelink scheduling and the configured sidelink grant with type 2 are not supported for the UE served
by E-UTRAN.
- The prioritization between EUTRA UL transmission and NR SL transmission, if needed, is performed based on
the priority of sidelink MAC PDU only, except that the UL transmission is prioritized by upper layer as
specified in TS 24.386 [75] or random access procedure is performed.
23.20 Support for Multi-USIM devices

23.20.1 General
E-UTRAN may support one or more of the following enhancements for MUSIM UE operation:
- Paging Collision Avoidance, as described in clause 23.20.2;
23.20.2 Paging Collision Avoidance

The purpose of paging collision avoidance is to address the overlap of paging occasions on both USIMs when a
MUSIM (e.g. dual USIM device) is in RRC_IDLE/RRC_INACTIVE state in both the networks (e.g. Network A and
Network B) associated with respective USIMs.
A MUSIM device UE may determine potential paging collision on two networks and may trigger actions to prevent
potential paging collision on E-UTRA connected to EPC as specified in TS 23.401 [17] or E-UTRA connected to 5GC
as specified in TS 23.501 [82].
Editor's Note: It is left to UE implementation as to how it selects one of the two RATs/networks for paging collision
avoidance.
23.21 Support for BL UEs, UEs in enhanced coverage and NB-IoT

UEs over Non-Terrestrial Networks
23.21.1 General
Support for BL UEs, UEs in enhanced coverage and NB-IoT UEs over Non-Terrestrial Networks (see clause 4.12) is
only applicable to E-UTRA connected to EPC. UEs not supporting NTN are barred from accessing an NTN cell.
In NTN, only BL UEs, UEs in enhanced coverage and NB-IoT UEs with GNSS capability are supported in this release
of the specification.
To accommodate long propagation delays in NTN, increased timer values and window sizes, or delayed starting times
are supported for the physical layer and for higher layers.
UL segmented transmission is supported for UL transmission with repetitions. The UE shall apply UE pre-
compensation per segment of UL transmission of PUSCH/PUCCH/PRACH for BL UEs or UEs in enhanced coverage
and NPUSCH/NPRACH for NB-IoT UEs from one segment to the next segment.
23.21.2 Timing and synchronization

23.21.2.1 Scheduling timing
DL and UL are frame aligned at the uplink time synchronization reference point (RP) with an offset given by N TA , offset .
3GPP
Release 17 366 3GPP TS 36.300 V17.2.0 (2022-09)
To accommodate the long propagation delays in NTN, several timing relationships are enhanced by Common TA and
two scheduling offsets: K offset and K mac illustrated in Figure 23.21.2.1-1:
- CommonTA is a configured offset corresponding to the RTT between the RP and the NTN payload.
- K offset is a configured scheduling offset approximately corresponding to the sum of the service link RTT and the
common TA.
- K mac is a configured offset approximately corresponding to the RTT between the RP and the eNB.
Figure 23.21.2.1-1 Timing relationship parameters
The scheduling offset K offset is used to allow the UE sufficient processing time between a downlink reception and an
uplink transmission, see TS 36.213 [6].
The offset K mac is used to delay the application of a downlink configuration indicated by a MAC CE received on
NPDSCH/PDSCH, see TS 36.213 [6], and to determine the UE-eNB RTT, see TS 36.321 [13].
23.21.2.2 Pre-compensation by the UE

For the serving cell, the network broadcast ephemeris information and common Timing Advance (common TA)
parameters.
The UE shall have valid GNSS position as well as the satellite ephemeris and common TA before connecting to an
NTN cell. To achieve synchronisation, before and during connection to a cell, the UE shall autonomously pre-
compensate the Timing Advance (TTA, see TS 36.211 [4] clause 8.1), see Figure 23.21.2.2-1, as well as the frequency
doppler shift by considering the common TA, UE position and the satellite position through the satellite ephemeris.
In connected mode, the UE shall continuously update the Timing Advance and frequency pre-compensation, but the UE
is not expected to perform GNSS acquisition. In connected mode, upon outdated satellite ephemeris and common
Timing Advance, the UE re-acquires the broadcasted parameters and upon outdated GNSS position the UE moves to
idle mode.
The UEs may be configured to report Timing Advance at initial access or in connected mode. In connected mode
triggered reporting of the Timing Advance is supported.
3GPP
Release 17 367 3GPP TS 36.300 V17.2.0 (2022-09)
Figure 23.21.2.2-1 Illustration of Uplink/Downlink Radio Frame Timing at the UE
While the pre-compensation of the instantaneous Doppler shift experienced on the service link is to be performed by the
UE, the management of Doppler shift experienced over the feeder link and transponder frequency error, whether
introduced in Downlink or Uplink, is left to network implementation.
23.21.3 Support of discontinuous coverage

As a satellite moves on a specified orbit, for example in case of a NGSO satellite, the satellite beam(s) coverage area
may move and cover different portions of a geographical area due to the orbital movement of the satellite. As a
consequence, a UE located in the concerned geographical area may experience a situation of discontinuous coverage,
due to e.g. a sparse satellite constellation deployment.
To enable the UE, in RRC_IDLE, to save power during periods of no coverage, the network provides satellite assistance
information (e.g. satellite ephemeris parameters, the start-time of upcoming satellite's coverage) to enable the UE to
predict when coverage will be provided by upcoming satellites. Predicting out of coverage and in coverage is up to UE
implementation. When out of coverage, the UE is not required to perform AS functions.
23.21.4 Mobility Management

23.21.4.1 Mobility Management in ECM-IDLE
The principles described in clause 10.1.1 apply in NTN unless specified otherwise hereafter.
The network may broadcast more than one TAC per PLMN in a cell in order to reduce the signalling load at cell edge in
NTN, in particular for Earth-moving cell coverage. The AS layer indicates all received TACs for the selected PLMN to
the NAS layer. The network may update the UEs upon TAC removal. UEs may by UE implementation also check
whether a TAC has been removed.
For quasi-Earth-fixed cells, timing information on when the cell is going to stop serving the area may be broadcast by
the network. This may be used by the UE to start measurements on neighbour cells before the broadcast stop time of the
serving cell, while the exact start of the measurements is up to UE implementation.
23.21.4.2 Mobility Management in ECM-CONNECTED

Radio link failure and RRC connection re-establishment are supported in NTN. The principles described in clause
10.1.6 apply unless specified otherwise.
To enable mobility in NTN, the network provides target cell satellite parameters needed to access the NTN cell in the
handover command.
Conditional handover is supported for BL UEs and UEs in enhanced coverage.
23.21.5 Switchover
23.21.5.1 Definitions
A feeder link switchover is the procedure where the feeder link is changed from a source NTN Gateway to a target NTN
Gateway for a specific NTN payload. The feeder link switchover is a Transport Network Layer procedure.
Both hard and soft feeder link switchover are applicable to NTN.
23.21.5.2 Assumptions
A feeder link switchover may result in transferring the established connection for the affected UEs between two eNBs.
3GPP
Release 17 368 3GPP TS 36.300 V17.2.0 (2022-09)
For soft feeder link switchover, an NTN payload is able to connect to more than one NTN Gateway during a given
period i.e. a temporary overlap can be ensured during the transition between the feeder links.
For hard feeder link switchover, an NTN payload only connects to one NTN Gateway at any given time i.e. a radio link
interruption may occur during the transition between the feeder links.
23.21.5.3 Procedures
The NTN control function determines the point in time when the feeder link switchover between two eNBs is
performed. For BL UEs and UEs in enhanced coverage, the transfer of the affected UEs' context between the two eNBs
at feeder link switchover is performed by means of either S1 based or X2 based handover, and it depends on the eNBs'
implementation and configuration information provided to the eNBs by the NTN Control function.
23.21.6 Signalling
The Cell Identity, as defined in TS 36.413 [25] and TS 36.423 [42], corresponds to a Mapped Cell ID, irrespective of
the orbit of the NTN payload or the types of service links supported in the following cases:
- The Cell Identity indicated by the eNB to the Core Network as part of the User Location Information, or as E-
UTRAN CGI in the related S1AP messages;
- The Cell Identity used for Paging Optimization in S1 interface;
- The Cell Identity used for PWS.
For a BL UE or a UE in enhanced coverage, the Cell Identity included within the target identification of the handover
messages allows identifying the correct target cell.
The mapping between Mapped Cell ID(s) and geographical area(s) is configured in the RAN and Core Network.
NOTE 1: A specific geographical location may be mapped to multiple Mapped Cell ID(s), and such Mapped Cell
IDs may be configured to indicate different geographical areas (e.g. overlapping and/or with different
dimensions).
For a BL UE or a UE in enhanced coverage or a NB-IoT UE that supports S1-U data transfer or User Plane CIoT EPS
optimisation, the eNB is responsible for constructing the Mapped Cell ID based on the UE location information
received from the UE, if available. The mapping may be pre-configured (e.g., depending on operator's policy) or up to
implementation.
NOTE 2: As described in TS 23.401 [17], the User Location Information may enable the MME to determine
whether the UE is allowed to operate at its present location. Special Mapped Cell IDs or TACs may be
used to indicate areas outside the serving PLMN's country.
The eNB reports the broadcasted TAC(s) of the selected PLMN to the MME. In case the eNB knows the UE's location
information, the eNB may determine the TAI the UE is currently located in and provide that TAI to the MME.
23.21.7 MME(Re-)Selection by eNB

The eNB implements the NAS Node Selection Function specified in TS 36.410 [95].
For a RRC_CONNECTED UE, the eNB is configured to ensure that the BL UE or the UE in enhanced coverage is
using an MME that serves the country in which the UE is located. If the eNB detects that a BL UE or a UE in enhanced
coverage is in a different country to that served by the serving MME, it should perform an S1 handover to change to an
appropriate MME or initiate an UE Context Release Request procedure towards the serving MME (in which case the
MME may decide to detach the UE).
For an RRC_CONNECTED NB-IoT UE, when the eNB is configured to ensure that the NB-IoT UE is using an MME
that serves the country in which the UE is located. If the eNB detects that the UE is in a different country to that served
by the serving MME, it should initiate a UE Context Release Request procedure towards the serving MME (in which
case the MME may decide to detach the UE).
23.21.8 O&M Requirements

The NTN related parameters shall be provided by O&M to the eNB providing non-terrestrial access, as specified in TS
38.300 [79].
3GPP
Release 17 369 3GPP TS 36.300 V17.2.0 (2022-09)
23.21.9 Coarse UE location reporting

Upon network request, after AS security is established in connected mode, BL UEs and UEs in enhanced coverage can
report its coarse UE location information (most significant bits of the GNSS coordinates, ensuring an accuracy in the
order of 2km) to the eNB.
24 Support for 5GC

24.1 General
The E-UTRA connected to 5GC is supported as part of NG-RAN. The E-UTRA can be connected to both EPC and
5GC.
The overall architecture of E-UTRA connected to 5GC as part of NG-RAN is described in TS 38.300 [79], where the
term "ng-eNB" is used for E-UTRA connected to 5GC. However, in this specification the term "eNB" is used for both
cases unless there is a specific need to disambiguate between eNB and ng-eNB.
E-UTRA connected to 5GC supports the following functions:
- 5G NAS message transport (see clause 7.3);
- 5G security framework (see TS 38.300 [79]), except that data integrity protection is not supported;
- Access Control (see TS 38.300 [79]);
- Flow-based QoS (see TS 38.300 [79]);
- Network slicing (see TS 38.300 [79]);
- SDAP (see TS 37.324 [80]) , except for NB-IoT;
- NR PDCP (see TS 38.323 [81]) , except for NB-IoT;
- Support of UEs in RRC_INACTIVE state, except for NB-IoT.
- CIoT 5GS Optimisations for BL UEs, UEs in enhanced coverage and NB-IoT UEs (see clause 7.3a);
- MO-EDT for BL UEs, UEs in enhanced coverage and NB-IoT UEs (see clause 7.3b);
- Transmission using PUR for BL UEs, UEs in enhanced coverage and NB-IoT UEs (see clause 7.3d).
24.2 Radio Protocol Architecture

24.2.1 User Plane
Except for NB-IoT, the figure below shows the protocol stack for the user plane, where SDAP, NR PDCP, RLC and
MAC sublayers perform the functions listed in clause 6.5 of TS 38.300 [79], clause 6.4 of TS 38.300 [79], clause 6.3,
and clause 6.2 respectively.
Figure 24.2.1-1: User Plane Protocol Stack
3GPP
Release 17 370 3GPP TS 36.300 V17.2.0 (2022-09)
For NB-IoT, the protocol stack for the user plane is described in clause 4.3 where eNB should be understood as ng-
eNB. PDCP, RLC and MAC sublayers perform the functions listed in clause 6.3, clause 6.2 and clause 6.1 respectively.
NOTE 1: For a NB-IoT UE that only supports Control Plane CIoT 5GS Optimisation, as defined in TS 25.401 [91],
PDCP is bypassed and DTCH is not supported.
NOTE 2: For a NB-IoT UE that supports Control Plane CIoT 5GS Optimisation and NG-U data transfer or User
Plane CIoT 5GS Optimisation, as defined in TS 25.401 [91], PDCP is also bypassed (i.e. not used) until
AS security is activated.
24.2.2 Control Plane

Except for NB-IoT, the figure below shows the protocol stack for the control plane, where:
- NR PDCP sublayer (terminated in ng-eNB on the network side) performs the functions listed for the control
plane in clause 6.4 of TS 38.300 [79]. The UE uses only NR PDCP for both SRBs and DRBs when connected to
5GC;
- RLC and MAC sublayers (terminated in ng-eNB on the network side) perform the functions listed in clause 6.2
and 6.1;
- RRC (terminated in ng-eNB 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 [82],
for instance: authentication, mobility management, security control.
Figure 24.2.2-1: Control Plane Protocol Stack
For NB-IoT, the protocol stack for the control plane is described in clause 4.3 where eNB and MME should be
understood as ng-eNB and AMF respectively.
- PDCP sublayer (terminated in ng-eNB on the network side) performs the functions listed for the control plane in
clause 6.3;
- RLC and MAC sublayers (terminated in ng-eNB on the network side) performs the functions listed for the
control plane in clause 6.2 and clause 6.1 respectively;
- RRC (terminated in ng-eNB 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 24.501 [91].
NOTE: For a NB-IoT UE that only supports Control Plane CIoT 5GS Optimisation, as defined in TS 24.501 [91],
PDCP is bypassed. For a NB-IoT UE that supports Control Plane CIoT 5GS Optimisation and NG-U data
transfer or User Plane CIoT 5GS Optimisation, as defined in TS 24.501 [91], PDCP is not used until AS
3GPP
Release 17 371 3GPP TS 36.300 V17.2.0 (2022-09)
24.3 Layer 2
Except for NB-IoT, the layer 2 of E-UTRA connected to 5GC is split into the following sublayers: Medium Access
Control (MAC), Radio Link Control (RLC), NR Packet Data Convergence Protocol (PDCP) and Service Data
Adaptation Protocol (SDAP).
- The physical layer offers to the MAC sublayer transport channels, see clause 5;
- The MAC sublayer offers to the RLC sublayer logical channels, see clause 6.1;
- The RLC sublayer offers to the NR PDCP sublayer RLC channels, see clause 6.2;
- The NR PDCP sublayer offers to the SDAP sublayer data radio bearers, and offers to the RRC sublayer
signalling radio bearers, see TS 38.323 [81];
- The SDAP sublayer offers to 5GC QoS flows, see TS 37.324 [80].
For NB-IoT, the layer 2 of E-UTRA connected to 5GC is split into the following sublayers: Medium Access Control
(MAC), Radio Link Control (RLC), and Packet Data Convergence Protocol (PDCP).
- The physical layer offers to the MAC sublayer transport channels, see clause 5;
- The MAC sublayer offers to the RLC sublayer logical channels, see clause 6.1;
- The RLC sublayer offers to the PDCP sublayer RLC channels, see clause 6.2;
- The PDCP sublayer offers to the 5GC QoS flows data radio bearers, and offers to the RRC sublayer signalling
radio bearers, see clause 6.3.
24.4 CN Selection
For a cell that provides E-UTRA connectivity to both 5GC and EPC within a PLMN, the UE upper layer performs CN
selection between EPC and 5GC. The UE AS layer indicates available CN type(s) to upper layers for CN type selection
and in addition for BL UEs, UEs in enhanced coverage and NB-IoT UEs, the supported CIoT features. The UE NAS
layer indicates selected CN type (if available) with selected PLMN during PLMN selection procedure, as defined in TS
36.304 [11].
24.5 Mobility
Intra-EUTRA inter-system Handover (i.e., handover between E-UTRA connected to 5GC and E-UTRA connected to
EPC) is described in clause 10.2.2c and in TS 23.502 [83].
Neither DAPS Handover nor Conditional Handover are supported for E-UTRA connected to 5GC.
The inter-RAT intra-5GC Handover (i.e., handover between E-UTRA connected to 5GC and NR connected to 5GC) is
described in clause 9.3.1.2 of TS 38.300 [79].
Inter-RAT handover to/from GERAN/UTRAN/CDMA2000 and cell change order to GERAN with NACC are not
supported, and CS fallback described in clause 10.2.5 is not applied except for the functionality of release with
redirection to GERAN/UTRAN.
The following mobility procedures are supported:
- RRC Connection Release with Redirection to GERAN/UTRAN/CDMA2000/EUTRAN;
- Cell Change Order to GERAN without NACC.
When the UE is connected to E-UTRA/5GC, inter system fallback towards E-UTRAN is performed when 5GC does not
support some services, see TS 23.501 [82]. 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 [82] and TS 36.331 [16].
Except for NB-IoT, in the N2 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 ng-eNB node. When
3GPP
Release 17 372 3GPP TS 36.300 V17.2.0 (2022-09)
the target CN type is received by ng-eNB, the target CN type is also conveyed to the UE in RRC Connection Release
message.
The mobility in RRC_INACTIVE is described in clause 10.1.9.
For E-UTRA connected to 5GC, in RRC_IDLE the UE monitors the PCCH for CN-initiated paging information, in
RRC_INACTIVE, except for NB-IoT, the UE monitors the PCCH for RAN-initiated and CN-initiated paging
information. The RAN-initiated and CN-initiated paging occasions overlap and the same paging mechanism is used for
both. Except for BL UEs, UEs in enhanced coverage and NB-IoT UEs, the extended DRX (eDRX) is not used for E-
UTRA connected to 5GC. For BL UEs and UEs in enhanced coverage in RRC_INACTIVE, extended DRX cycles up to
10.24 s without PTW are supported. The paging optimisation in clause 23.13 is also applicable, where AMF shall be
considered instead of MME and ng-eNB shall be considered instead of eNB.
24.6 Slicing
E-UTRA connected to 5GC supports network slicing functionality. The details of network slicing are specified in TS
23.501 [82] and clause 16.3 of TS 38.300 [79].
24.7 Access Control

E-UTRA connected to 5GC supports unified access control (UAC) functionality. The details of UAC are defined in TS
38.300 [79].
For E-UTRA connected to both EPC and 5GC, E-UTRA broadcasts the access control information associated with EPC
and 5GC separately and the UE AS uses the access control information associated with the core network type selected
by NAS.
24.8 Radio access network sharing

E-UTRA connected to 5GC supports radio access network sharing as specified in TS 23.501 [82].
For E-UTRA connected to both EPC and 5GC, E-UTRA broadcasts the access control information associated with EPC
and 5GC separately and the UE AS uses the access control information associated with the core network type selected
by NAS.
If E-UTRA connected to 5GC is shared, system information broadcast in a shared cell indicates a TAC and a Cell
Identity for each subset of PLMNs (up to 6). E-UTRA provides only one TAC and one Cell Identity per cell per PLMN.
Each Cell Identity associated with a subset of PLMNs identifies its serving ng-eNB node.
NOTE 1: How to manage the scenario where a different PLMN ID has been allocated by the operator for an ECGI
is left to OAM and/or implementation.
NOTE 2: It is not precluded that a cell served by an eNB does not broadcast the PLMN ID included in the Global
eNB ID.
24.9 Sidelink
E-UTRA connected to 5GC can support V2X sidelink communication and NR sidelink communication for UEs in
RRC_IDLE, RRC_INACTIVE and RRC_CONNECTED. The details of NR sidelink communication are defined in TS
38.300 [79].
24.10 Minimization of Service Interruption

In case of a disaster, a radio access network can experience outage, which can result in that UEs belonging to the
network experience service interruptions. For this scenario, another network not affected by the disaster, which during
non-disaster situations is considered by the UEs as a forbidden network, can allow roaming of the UEs belonging to the
network experiencing such disaster service interruptions. Such roaming is referred to as disaster roaming. This is further
described in clause 5.40 of TS 23.501 [82] and 3.10 of TS 23.122 [94].
To allow such disaster roaming, a cell can broadcast a list of PLMNs with disaster conditions for which disaster
roaming is offered. Disaster roaming service is provided only for the area that covers the area with disaster condition.
3GPP
Release 17 373 3GPP TS 36.300 V17.2.0 (2022-09)
Further, to be able to control the load that disaster roaming UEs put on a cell, the cell can broadcast access control
parameters applicable specifically for disaster roaming UEs. Access attempts of disaster roaming UEs are based on
Access Identity 3. The network can for example set the access control parameters for Access Identity 3 so that access
attempts of disaster roaming UEs are more likely to be barred compared to non-disaster roaming UEs.
3GPP
Release 17 374 3GPP TS 36.300 V17.2.0 (2022-09)
Annex A (informative):
NAS Overview
This clause provides for information an overview on services and functions provided by the NAS control protocol.
A.1 Services and Functions

The main services and functions of the NAS sublayer include:
- EPS Bearer control (see TR 23.401 [17]);
- ECM-IDLE mobility handling;
- Paging origination;
- Configuration and control of Security.
A.2 NAS protocol states & state transitions

The NAS state model is based on a two-dimensional model which consists of EPS Mobility Management (EMM) states
describing the mobility management states that result from the mobility management procedures e.g. Attach and
Tracking Area Update procedures, and of EPS Connection Management (ECM) states describing the signalling
connectivity between the UE and the EPC (see TS 23.401 [17]).
NOTE: The ECM and EMM states are independent of each other and when the UE is in EMM-CONNECTED
state this does not imply that the user plane (radio and S1 bearers) is established.
The relation between NAS and AS states is characterised by the following principles:
- EMM-DEREGISTERED & ECM-IDLE  RRC_IDLE:
- Mobility: PLMN selection:
- UE Position: not known by the network.
- EMM-REGISTERED & ECM-IDLE  RRC_IDLE:
- Mobility: cell reselection;
- UE Position: known by the network at tracking area level.
- EMM-REGISTERED & ECM-CONNECTED with radio bearers established  RRC_CONNECTED.
- Mobility: handover;
- UE Position: known by the network at cell level.
3GPP
Release 17 375 3GPP TS 36.300 V17.2.0 (2022-09)
Annex B (informative):
MAC and RRC Control
The E-UTRA supports control signalling in terms of MAC control signalling (PDCCH and MAC control PDU) and
RRC control signalling (RRC message).
B.1 Difference between MAC and RRC control

The different characteristics of MAC and RRC control are summarized in the table below.
Table B.1-1: Summary of the difference between MAC and RRC control
MAC control RRC control
Control entity MAC RRC
Signalling PDCCH MAC control PDU RRC message
Signalling reliability ~ 10-2 (no retransmission) ~ 10-3 (after HARQ) ~ 10-6 (after ARQ)
Control delay Very short Short Longer
Extensibility None or very limited Limited High
Security No integrity protection No integrity protection Integrity protection

No ciphering No ciphering Ciphering
The main difference between MAC and RRC control lies in the signalling reliability. Due to the signalling reliability,
signalling involving state transitions and radio bearer configurations should be performed by RRC. Basically, all
signalling performed by RRC in UTRA should also be performed by RRC also for E-UTRA.
B.2 Void
3GPP
Release 17 376 3GPP TS 36.300 V17.2.0 (2022-09)
Annex C (informative):
Void
Annex D (informative):
Void
Annex E (informative):
Void
Annex F (informative):
Void
3GPP
Release 17 377 3GPP TS 36.300 V17.2.0 (2022-09)
Annex G (informative):
Guideline for E-UTRAN UE capabilities
Each radio access technology has defined specific "classes" of terminals in terms of radio capabilities. E.g. in GPRS the
"multislot classes" are defined, in UMTS R'99 different dedicated bearer classes are defined and for HSDPA and
HSUPA 12 respectively 6 physical layer categories are defined. The definition of UMTS R'99 UE classes lead to 7 DL
classes and 7 UL classes for FDD out of which only 2 DL and 3 UL classes were commercially realized. Furthermore
the lower end classes (e.g. 64 UL and 64 DL) disappeared from the market with commercialization of the UMTS
networks quite soon. Besides these class definitions a huge number of possible parameter combinations (to achieve
certain data rates) exist with UMTS R'99 which lead to the huge number of RAB and RB combinations defined. Further
activities in the early phase of UMTS standardization aimed to reduce the number of possible combinations
significantly.
For HSDPA two "simple" DL categories (11 & 12) with lowered complexity were defined with the intent to speed up
commercialization of HSDPA. Originally those categories should have been removed for Rel-6. Out of the 12 defined
categories only approx. 4 will be realized in commercial HSDPA platform products. A similar situation is likely for
HSUPA as well as for the combinations of HSDPA/HSUPA.
Generally the aim to mandate certain essential functions/requirements can help to simplify the system definition as well
as the realization options (e.g. mandating 20 MHz of DL reception as well as 20 MHz UL transmission bandwidth
significantly reduced the E-UTRAN system complexity). Especially mandating certain terminal functions could be
useful for the system design if a defined subset of parameter combinations are also supported by the systems, e.g. the
eNB scheduler. However, there is also a risk that not all the defined E-UTRA features are deployed in the networks at
the time when terminals are made commercially available on the market place. Some features are likely to be rather
large and complex, which further increases the risk of interoperability problems unless these features have undergone
sufficient interoperability testing (IOT) on real network equipment, and preferably with more than one network in order
to improve the confidence of the UE implementation. Thus, avoiding unnecessary UE mandatory features but instead
defining a limited set of UE radio classes allows simplification for the interoperability testing.
Given the discussion above, it seems beneficial for the introduction of E-UTRAN to limit the combination of radio
capabilities to a clearly defined subset and ensure that a given set of parameters is supported by certain UE classes as
well as networks for rapid E-UTRAN deployment. It seems unrealistic to mandate only one single UE class which
always mandates the maximum capability.
In order to address the different market requirements (low end, medium and high end), the definition of the following
UE classes are proposed:
Table G-1: E-UTRAN UE Classes
Class UL DL
A [50] Mbps [100] Mbps
B [25] Mbps [50] Mbps
C [2] Mbps [2] Mbps
NOTE: For simplification reasons, the table only depict the UE capabilities in terms of uplink and downlink peak
data rates supported. However, it should be noted that further discussion on other features is expected
once the work progresses.
It may require further discussion whether there be a need for an additional terminal class between 2 Mbps and 50 Mbps
classes. It might make sense, since up to 5 MHz band allocations may be rather common in real deployments for several
years. This would point to bit rate class of 25 Mbps in DL and 10 Mbps in UL.
The above given data rates are indicative and should be subject for further discussions in 3GPP RAN working groups.
Depending on the different solutions to reach those data rates, the target should be to define [3..4] UE classes in
different data rate ranges, and other parameters affecting device complexity and cost. The definition of the required
parameters/features is for further study for each of the classes. For instance, half-duplex UEs form a specific category
that may be frequency band specific.
3GPP
Release 17 378 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE: the support of half-duplex UEs is mandatory for the eNB where such a category is allowed in the
frequency band supported by the eNB.
The aim is to ensure on the one hand that high end E-UTRAN UEs, supporting data rates representing state of the art
level and competitive with other radio technologies are defined, while the medium and lower data rates aim to reduce
implementation cost for chipset/terminal vendors and allow adoption of most cost efficient solutions for different
market segments. It is expected that the support of the high end data rate terminals is ensured from the very beginning.
Another clear exception from this exercise is that on the low end very cheap product implementation is possible (e.g. for
the machine-to-machine market or the voice and very low data rate only segment – to substitute GSM in the medium
term) while top end performance is needed for data applications in notebooks, wireless gateways ("wireless DSL"), etc.
Another important aspect that must be ensured is that a higher capability UE can be treated in exactly the same way as
for a lower capability UE, if the network wishes to do so, e.g., in case the network does not support some higher
capability features. In HSDPA, there have been problems in this respect due to 2-stage rate matching in HARQ. Such
problems should be avoided in E-UTRAN, and E-UTRAN UE capabilities should provide the compatibility to ease
implementation and interoperability testing.
Annex H (informative):
Void
Annex I (informative):
SPID ranges and mapping of SPID values to cell reselection
and inter-RAT/inter frequency handover priorities
This Annex defines two ranges of SPID (Subscriber Profile ID for RAT/Frequency Priority) values, respectively
Operator Specific and Reference values. The mapping at eNB of Reference SPID values to cell reselection and inter-
RAT/inter frequency handover priorities is defined.
I.1 SPID ranges

Values 1- 128 - Operator specific SPID values;
Values 129 - 256- Reference values.
I.2 Reference SPID values

SPID = 256
3GPP
Release 17 379 3GPP TS 36.300 V17.2.0 (2022-09)
Table I.2-1: eNB local configuration in idle and connected mode for SPID = 256
Configuration parameter Value Meaning

E-UTRAN carriers priority high The selection priorities for idle and
connected mode of all E-UTRAN carriers
are higher than the priorities for all
UTRAN and GERAN carriers
UTRAN carriers priority medium The selection priorities for idle and
connected mode of all UTRAN carriers
are lower than the priorities for all E-
UTRAN carriers and higher than the
priorities for all GERAN carriers
GERAN carriers priority low The selection priorities for idle and
connected mode of all GERAN carriers
are lower than the priorities for all E-
UTRAN and UTRAN carriers
SPID = 255

UTRAN carriers priority high The selection priorities for idle and
GERAN and E-UTRAN carriers
GERAN carriers priority medium The selection priorities for idle and
are lower than the priorities for all
UTRAN carriers and higher than the
priorities for all E-UTRAN carriers
E-UTRAN carriers priority low The selection priorities for idle and
UTRAN and GERAN carriers
SPID = 254

GERAN carriers priority high The selection priorities for idle and
UTRAN and E-UTRAN carriers
UTRAN carriers priority medium The selection priorities for idle and
GERAN carriers and higher than the
priorities for all E-UTRAN carriers
E-UTRAN carriers priority low The selection priorities for idle and
GERAN and UTRAN carriers
SPID = 253
3GPP
Release 17 380 3GPP TS 36.300 V17.2.0 (2022-09)
automotive device subscriber true The selection provides information that

subscriber is using an automotive device and is
permitted to utilise a minimum of two Rx antenna
ports for the NR bands where four Rx antenna
ports are baseline as given in TS 38.101-1 [88].
3GPP
Release 17 381 3GPP TS 36.300 V17.2.0 (2022-09)
Annex J (informative):
Carrier Aggregation
J.1 Deployment Scenarios
Table J.1-1 shows some of the potential deployment scenarios for CA. In Rel-10, for the uplink, the focus is laid on the
support of intra-band carrier aggregations (e.g. scenarios #1, as well as scenarios #2 and #3 when F1 and F2 are in the
same band). Scenarios related to uplink inter-band CA are supported from Rel-11. For the downlink, all scenarios
should be supported in Rel-10.
Table J.1-1: CA Deployment Scenarios (F2 > F1).
# Description Example
1 F1 and F2 cells are co-located and overlaid, providing nearly
the same coverage. Both layers provide sufficient coverage
and mobility can be supported on both layers. Likely scenario
is when F1 and F2 are of the same band, e.g., 2 GHz, 800
MHz, etc. It is expected that aggregation is possible between
overlaid F1 and F2 cells.
2 F1 and F2 cells are co-located and overlaid, but F2 has

smaller coverage due to larger path loss. Only F1 provides
sufficient coverage and F2 is used to improve throughput.
Mobility is performed based on F1 coverage. Likely scenario
when F1 and F2 are of different bands, e.g., F1 = {800 MHz, 2
GHz} and F2 = {3.5 GHz}, etc. It is expected that aggregation
is possible between overlaid F1 and F2 cells.
3 F1 and F2 cells are co-located but F2 antennas are directed to

the cell boundaries of F1 so that cell edge throughput is
increased. F1 provides sufficient coverage but F2 potentially
has holes, e.g., due to larger path loss. Mobility is based on
F1 coverage. Likely scenario is when F1 and F2 are of
different bands, e.g., F1 = {800 MHz, 2 GHz} and F2 = {3.5
GHz}, etc. It is expected that F1 and F2 cells of the same eNB
can be aggregated where coverage overlaps.
4 F1 provides macro coverage and on F2 Remote Radio Heads
(RRHs) are used to improve throughput at hot spots. Mobility
is performed based on F1 coverage. Likely scenarios are both
when F1 and F2 are DL non-contiguous carrier on the same
band, e.g., 1.7 GHz, etc. and F1 and F2 are of different bands,
e.g., F1 = {800 MHz, 2 GHz} and F2 = {3.5 GHz}, etc. It is
expected that F2 RRHs cells can be aggregated with the
underlying F1 macro cells.
5 Similar to scenario #2, but frequency selective repeaters are
deployed so that coverage is extended for one of the carrier
frequencies. It is expected that F1 and F2 cells of the same
eNB can be aggregated where coverage overlaps.
The reception timing difference at the physical layer of DL assignments and UL grants for the same TTI but from
different serving cells (e.g. depending on number of control symbols, propagation and deployment scenario) does not
affect MAC operation. A UE should cope with a relative propagation delay difference up to 30 s among the
component carriers to be aggregated in both intra-band non-contiguous and inter-band non-contiguous CA. This implies
that a UE should cope with a delay spread of up to 30.26 s among the component carriers monitored at the receiver,
3GPP
Release 17 382 3GPP TS 36.300 V17.2.0 (2022-09)
since the BS time alignment is specified to be up to 0.26 s. This also implies that the UE should cope with a maximum
uplink transmission timing difference between TAGs of 32.47s for inter-band carrier aggregation with multiple TAGs.
When CA is deployed frame timing and SFN are aligned across cells that can be aggregated.
J.2 Void
J.3 Void
J.4 Void
J.5 Void
J.6 Void
Annex K (informative):
Time domain ICIC
This Annex reflects the agreements reached on time domain ICIC that may not necessarily fit in the core of the
specification but which needs to be captured in the absence of corresponding details in Stage 3 specifications.
K.1 Deployment scenarios

Two scenarios have been identified where conventional ICIC techniques are insufficient to overcome co-channel
interference, the CSG scenario and the Pico scenario. The identified scenarios are examples of network configurations
that are intended to depict the basic concept of time domain ICIC and it should be understood that other network
deployment scenarios are also possible.
K.1.1 CSG scenario

Dominant interference condition may happen when non-member users are in close proximity of a CSG cell. Depending
on network deployment and strategy, it may not be possible to divert the users suffering from inter-cell interference to
another E-UTRA carrier or other RAT. Time domain ICIC may be used to allow such non-member UEs to remain
served by the macro cell on the same frequency layer.
Such interference may be mitigated by the CSG cell utilizing Almost Blank Subframes to protect the corresponding
macro cell's subframes from the interference. A non-member UE may be signalled to utilize the protected resources for
cell measurements (RRM), radio link monitoring (RLM) and CSI measurements for the serving macro cell, allowing the
UE to continue to be served by the macro cell under strong interference from the CSG cell.
3GPP
Release 17 383 3GPP TS 36.300 V17.2.0 (2022-09)
Figure K.1.1-1: Time domain ICIC: CSG scenario
In RRC_CONNECTED, the network can find out that the UE is subject to dominant interference from a CSG cell
which the UE is not a member of through the existing measurement events (defined in release-8/9), at which point the
network may choose to configure the RRM/RLM/CSI measurement resource restriction for the UE. The network may
also configure RRM measurement resource restriction for neighbour cells in order to facilitate mobility from the serving
macro cell. The network may release the RRM/RLM/CSI measurement resource restriction when it detects that the UE
is no longer severely interfered by the CSG cell.
K.1.2 Pico scenario

Time domain ICIC may be utilized for pico users who served in the edge of the serving pico cell, e.g. for traffic off-
loading from a macro cell to a pico cell. Time domain ICIC may be utilized to allow such UEs to remain served by the
pico cell on the same frequency layer.
Such interference may be mitigated by the macro cell(s) utilizing Almost Blank Subframes to protect the corresponding
pico cell's subframes from the interference. A UE served by a pico cell uses the protected resources for cell
measurements (RRM), radio link monitoring (RLM) and CSI measurements for the serving pico cell.
3GPP
Release 17 384 3GPP TS 36.300 V17.2.0 (2022-09)
Figure K.1.2-1: Time domain ICIC: Pico scenario
For a UE served by a pico cell, the RRM/RLM/CSI measurement resource restriction may allow more accurate
measurement of pico cell under strong interference from the macro cell(s). The pico cell may selectively configure the
RRM/RLM/CSI measurement resource restriction only for those UEs subject to strong interference from the macro
cell(s). Also, for a UE served by a macro cell, the network may configure RRM measurement resource restriction for
neighbour cells in order to facilitate mobility from the macro cell to a pico cell.
Annex L (informative):
Void
3GPP
Release 17 385 3GPP TS 36.300 V17.2.0 (2022-09)
Annex M (informative):
Dual Connectivity
M.1 Dual Connectivity operation
For Dual Connectivity, the UE is configured with two cell groups (CGs). A CG may only include cells that are
associated to the same eNB and those cells are synchronized at the eNB level similar as for carrier aggregation. Two
operations are defined: synchronous and asynchronous DC. In synchronous DC operation, the UE can cope with a
maximum reception timing difference up to at least 33µs and maximum transmission timing difference up to at least
35.21µs between CGs. In asynchronous DC operation, the UE can cope with a maximum reception/transmission timing
difference up to 500µs between CGs.
When DC is deployed, frame timing and SFN are aligned among the component carriers to be aggregated within a CG,
and may or may not be aligned between different CGs.
M.2 Operation Overview

Table M.2-1 below gives a network overview of the DC operations.
Table M.2-1: Dual Connectivity Operations
# Network Action Corresponding clause Remarks

1 Intra-PCell Handover 10.1.2.8.2.1 Intra-MeNB handover Causes also intra-PSCell Change or Intra-
involving SCG change SeNB Change.
Also used for KeNB refresh.
Done via Handover like in Rel-8; SCG can be
retained during the Handover.
2 Intra-PSCell SCG 10.1.2.8.2 SeNB Modification Also used for S-KeNB refresh.
Change (MeNB initiated SeNB Modification) Does not require intra-PCell Handover.
(SeNB initiated SeNB Modification)
3 Intra-MeNB Handover 10.1.2.8.2.1 Intra-MeNB handover Causes also intra-PSCell Change or Intra-
involving SCG change SeNB Change.
Done via Handover like in Rel-8; SCG can be
retained during the Change.
4 Intra-SeNB SCG 10.1.2.8.2 SeNB Modification Requires SCG change but does not require
Change (MeNB initiated SeNB Modification) intra-PCell Handover.
(SeNB initiated SeNB Modification)
5 Inter-MeNB Handover 10.1.2.8.5 MeNB to eNB Change Done via Handover like in Rel-8; Involves SCG
10.1.2.8.7 eNB to MeNB change release, or intra SeNB Change or inter-SeNB
10.1.2.8.8 Inter-MeNB handover Change.
without SeNB change
6 Inter-SeNB SCG 10.1.2.8.4 Change of SeNB Requires SCG change.
Change
7 SCG addition by 10.1.2.8.1 SeNB Addition Only the MeNB can request an SCG to be
MeNB 10.1.2.8.7 eNB to MeNB change added.
8 SCG SCell addition by 10.1.2.8.2 SeNB Modification Only the MeNB can request to add SCells to
MeNB (MeNB initiated SeNB Modification) the SCG.If the SeNB wants to use the new
SCell as PSCell it needs to initiate an SeNB
modification.
9 Non-last SCG SCell 10.1.2.8.2 SeNB Modification For requesting the release of the last SCG
release by MeNB (MeNB initiated SeNB Modification) SCell i.e. PSCell, the MeNB has to request
SCG release instead.
10 Non-last SCG SCell 10.1.2.8.2 SeNB Modification For requesting the release of the last SCG
release by SeNB (SeNB initiated SeNB Modification) SCell i.e. PSCell, the SeNB has to request
SCG release instead.
The SeNB can request to release the PSCell
only if it also chooses a new PSCell.
11 SCG release by MeNB 10.1.2.8.3 SeNB Release (MeNB The MeNB can always request the release of
initiated SeNB Release) the SCG and the SeNB has to comply.
3GPP
Release 17 386 3GPP TS 36.300 V17.2.0 (2022-09)
12 SCG release by SeNB 10.1.2.8.3 SeNB Release (SeNB The SeNB can always request the release of
initiated SeNB Release) the SCG and the MeNB has to comply
13 SCG bearer addition 10.1.2.8.2 SeNB Modification If this is the first bearer to be added in the
by MeNB (MeNB initiated SeNB Modification) SeNB, SCG addition is used instead.
(10.1.2.8.1 MeNB initiated SeNB
Addition)
14 SCG bearer release 10.1.2.8.2 SeNB Modification Allowed for both the MeNB and the SeNB, but
(MeNB initiated SeNB Modification) the SeNB cannot request to release the last
10.1.2.8.2 SeNB Modification SCG bearer if that would result in no bearers
(SeNB initiated SeNB Modification) in SeNB - SCG release should be used
instead.
The SeNB cannot initiate the release of an
SCG bearer and make changes to SCG-
Config at the same time e.g. change the
configuration of the physical layer.
15 Split bearer addition 10.1.2.8.2 SeNB Modification
by MeNB (MeNB initiated SeNB Modification)
16 Split bearer release 10.1.2.8.2 SeNB Modification Allowed for both the MeNB and the SeNB, but
(MeNB initiated SeNB Modification) the SeNB cannot request to release the last
10.1.2.8.2 SeNB Modification split bearer if that would result in no bearers in
(SeNB initiated SeNB Modification) SeNB - SCG release should be used instead.
The SeNB cannot initiate the release of an
SCG bearer and make changes to SCG-
Config at the same time e.g. change the
configuration of the physical layer.
17 MCG to SCG bearer 10.1.2.8.2 SeNB Modification Either the MeNB or the SeNB can request to
type change (and vice (MeNB initiated SeNB Modification) release an SCG bearer.
versa) 10.1.2.8.2 SeNB Modification Done via SCG change, i.e. L2 reset is required
(SeNB initiated SeNB Modification) for the UE.
The SeNB can only request change from SCG
to MCG by requesting release of SCG bearer.
The MeNB makes the decision on whether to
release the DRB entirely or change it to MCG
bearer.
18 MCG to Split Bearer 10.1.2.8.2 SeNB Modification The SeNB can always request to release the
Change (and vice (MeNB initiated SeNB Modification) SCG part of a split bearer.
versa) 10.1.2.8.2 SeNB Modification Done via SCG change, i.e. L2 reset is required
(SeNB initiated SeNB Modification) for the UE.
MeNB makes the decision on whether to
release the DRB entirely or change it to MCG
bearer.
3GPP
Release 17 387 3GPP TS 36.300 V17.2.0 (2022-09)
Annex N (informative):
Sidelink communication
N.1 Deployment Scenarios
Table N.1-1 shows scenarios for sidelink communication where UE A and UE B are located in-coverage /out-of-
coverage of a cell. When UE A has a role as transmitter, UE A sends message and UE B receives it. UE A and UE B
can change their transmission and reception role. The transmission from UE A can be received by one or more UEs like
UE B.
Table N.1-1: Sidelink communication Scenarios
# Description UE A UE B Example
1A Out-of-Coverage Out-of- Out-of-
Coverage Coverage
1B Partial-Coverage In-Coverage Out-of-

Coverage
1C In-Coverage- In-Coverage In-Coverage

Single-Cell
1D In-Coverage- In-Coverage In-Coverage

Multi-Cell
Annex O (informative):
E-UTRAN Architecture for Radio Access Network Sharing
with multiple cell ID broadcast
Each E-UTRAN node serving a cell identified by a Cell Identity associated with a subset of PLMNs is connected to
another E-UTRAN node via a single X2-C interface instance.
Each X2-C interface instance is setup and removed individually.
X2-C interface instances terminating at E-UTRAN nodes which share the same physical radio resources may share the
same signalling transport resources. If this option is applied,
- non-UE associated signalling is associated to an X2-C interface instance by including an Interface Instance
Indication in the X2AP message.
NOTE 1: The Interface Instance Indication is only included in EN-DC related X2AP messages.
- node related, non-UE associated X2-C interface signalling may provide information destined for multiple logical
nodes in a single X2AP procedure instance once the X2-C interface instance is setup.
3GPP
Release 17 388 3GPP TS 36.300 V17.2.0 (2022-09)
NOTE 2: If the Interface Instance Indication corresponds to more than one interface instance, the respective X2AP
message carries information destined for multiple logical nodes.
- a UE associated signalling connection is associated to an X2-C interface instance by allocating the corresponding
eNB UE X2AP IDs or en-gNB UE X2AP IDs so that they can be mapped to that X2-C interface instance.
NOTE 3: One possible implementation is to partition the value ranges of the eNB UE X2AP IDs or en-gNB UE
X2AP IDs and associate each value range with an X2-C interface instance.
Annex P (informative):
Example implementation of Non-Terrestrial Networks
The following figure illustrates an example implementation of a Non-Terrestrial Network for transparent NTN payload:
Figure P-1: NTN based E-UTRAN
The eNB depicted in Figure P-1 may be subdivided into non-NTN infrastructure eNB functions and the NTN Service
Link provisioning System. The NTN infrastructure may be thought of being subdivided into the NTN Service Link
provisioning System and the NTN Control function. The NTN Service Link provisioning System may consist of one or
more NTN payloads and NTN Gateways.
The NTN payload is embarked on a spaceborne vehicle, providing a structure, power, commanding, telemetry, attitude
control for the satellite and possibly an appropriate thermal environment and radiation shielding.
The NTN Service Link provisioning System maps the Uu radio protocol over radio resources of the NTN infrastructure
(e.g. beams, channels, Tx power).
The NTN control function controls the spaceborne vehicles as well as the radio resources of the NTN infrastructure
(NTN payload(s) & NTN Gateway(s)). It provides control data, e.g. Ephemeris, to the non-NTN infrastructure eNB
functions of the eNB.
Provision of NTN control data to the eNB is out of 3GPP scope.
NOTE: The transport of Uu protocol between the NTN Service Link provisioning system and the non-NTN
infrastructure eNB functions is out of 3GPP scope.
At least the following NTN related parameters are expected to be provided by O&M to the eNB for its operation.
a) Earth fixed beams: for each beam provided by a given NTN-payload:
- The Cell identifier (S1 and Uu) mapped to the beam;
- The Cell's reference location (e.g. cell's center and range).
b) Quasi Earth fixed beams: for each beam provided by a given NTN-payload:
- The Cell identifier (S1 and Uu) and time window mapped to a beam;
3GPP
Release 17 389 3GPP TS 36.300 V17.2.0 (2022-09)
- The Cell's/beam's reference location (e.g. cell's center and range);
- The time window of the successive switchovers (feeder link, service link);
- The identifier and time window of all serving satellites and NTN-Gateways.
c) Earth moving beams: for each beam provided by a given NTN-payload:
- The Uu Cell identifier mapped to a beam and mapping information to fixed geographical areas reported on
NG, including information about the beams direction and motion of the beam's foot print on Earth;
- Its elevation with regard to NTN-payload;
- Schedule of successive serving NTN-Gateways/eNBs;
- Schedule of successive switchovers (feeder link, service link).
3GPP
Release 17 390 3GPP TS 36.300 V17.2.0 (2022-09)
Annex Q (informative):
Change history
Change history (before approval)
Date TSG # TSG Doc. CR Rev Subject/Comment Old New
2006-06 RAN2 Ad. R2-062020 First version. 0.0.0
2006-06 RAN2 Ad. R2-062026 RLC operation clarified; 0.0.0 0.0.1
High priority and low priority SRBs listed in RRC;
New clause on RRC procedures;
Organisation of paging groups explained;
New clause on Support for self-configuration and self-optimisation.
2006-06 RAN2 Ad. R2-062036 Four possible types of allocation added to clause 11; 0.0.1 0.0.2
New clause for the support for real time IMS services.
2006-08 RAN2#54 R2-062206 Annex B on RRC and MAC control added. 0.0.2 0.0.3
Minor editorial clarifications.
2006-09 RAN#34 RP-060603 Clause 4 on "Overall Architecture" reorganised; 0.0.3 0.0.4
Details on RLC operation included (segmentation, PDU size);
Overview of System Information and RACH procedure added.
2006-10 RAN2#55 R2-063012 Ciphering for RRC signalling required in eNB as agreed in SA3; 0.0.4 0.0.5
Agreements on RLC operation included: concatenation, discard,
polling and status reports;
Agreed text proposal in R3-061428 on Self Configuration added to
clause 19;
Context transfer of header compression at UPE relocation listed as
FFS.
Outline of the RACH procedure described.
2006-10 RAN2#55 R2-063039 Miscellaneous editorial corrections; 0.0.5 0.1.0
Agreed text proposal R3-061606 on Current status of E-UTRAN
Architecture description added to clause 4;
Agreed text proposal in R3-061613 on Support for self-
configuration and self-optimisation added to clause 19.
Agreed Physical layer model R2-063031 added to clause 5
2006-11 RAN2#56 R2-063656 Annex C on system information classification added (R2-063064); 0.1.0 0.2.0
Integrity protection for the control plane only (SA3 agreement);
Agreements on PDCP and RLC PDU structure/handling reflected;
Decisions on mobility aspects such as load balancing, handover,
radio link failure and random access procedure added;
Agreed MBMS deployment scenarios listed together with MBMS
transmissions and principles from 25.813;
Agreed text proposal R3-061936 on Radio Resource Management
added to clause 15;
Agreed text proposal R3-061940 on RAN Sharing added to clause
10;
Agreed text proposal R3-061943 on Roaming/Area Restrictions in
SAE/LTE added to clause 10;
Agreed text proposal R3-062008 on S1 C-Plane Functions and
procedures added to clause 18;
Agreed text proposal R3-062011 on X2 interface added to clause
19.
2006-11 RAN2#56 R2-063680 Incorporation of RAN1 agreement regarding the mandatory support 0.2.0 0.3.0
of 20Mhz DL bandwidth for UEs i.e. removal of clause 16.1;
Editorial corrections.
2006-11 RAN2#56 R2-063681 Removal of the SA3 agreement on integrity protection for the user 0.3.0 0.3.1
plane;
Addition of Annex D on MBMS Transmission;
Editorial corrections.
2006-11 RAN#34 RP-060806 Clean version 0.3.1 0.3.1
2007-01 RAN2#56 R2-070403 SA3 agreement on integrity protection for the user plane included 0.3.1 0.4.0
bis (R2-070016);
Annex E on drivers for mobility control added (R2-070276);
Agreements on the details of the random access procedure added
in clause 10.1.5 (R2-070365);
New clause on UL rate control included (R2-070410);
RRC security principles listed in clause 13.1 (R2-070044);
Agreement on MAC security added to clause 13 (R2-062100);
Basis for DL scheduling put in clause 11.1;
Assumptions on neighbour cell list included in clause 10.
2007-02 RAN2#57 R2-070451 Number of bits for RACH in TDD clarified; 0.4.0 0.5.0
Miscellaneous editorial corrections.
2007-02 RAN2#57 R2-071073 Architecture updated according to R3-070397; 0.5.0 0.6.0
Agreements from R2-070802.
3GPP
Release 17 391 3GPP TS 36.300 V17.2.0 (2022-09)
2007-02 RAN2#57 R2-071120 RACH model for initial access described; 0.6.0 0.7.0
Mapping of the BCCH and System Information principles added;
Agreements on DRX included in clause 12.
2007-02 RAN2#57 R2-071122 Miscellaneous clarifications 0.7.0 0.7.1
2007-02 RAN2#57 R2-071123 CCCH in DL listed as FFS; 0.7.1 0.8.0
SAE Gateway ID removed from clause 8.2;
PDCP for the control plane listed as FFS in clause 4.3.2;
Agreements on intra-E-UTRAN handover procedure included in
clause 10.1.2 (R3-062020).
2007-03 RAN2#57 R2-071124 Agreement on Radio Access Network Sharing (R2-070551) added 0.8.0 0.9.0
to clause 10.1.7;
Overview of the physical layer (R1-071251) included to clause 5;
Agreed text proposals on S1 interface included in clause 19 (R3-
070289, R3-070402);
Agreed text proposal R3-070409 on network sharing included in
clause 10.1.7;
Agreed text proposal R3-070411 on Area Restrictions included in
clause 10.4;
Agreed text proposal R3-070448 on Assembly of Intra-E-UTRAN
handover command included in clause 10.1.2.1.1;
Agreed text proposal R3-070451 on inter RAT HO principles
included in clause 10.2.2;
Agreed text proposal R3-070472 on Addressing on S1-C and X2-C
added to clauses 19.2 and 20.2;
Agreed text proposal R3-070494 on Initial Context Setup Function
and Procedure added to clause 19;
Agreed text proposal R3-070495 on S1 Paging function and
procedure added to clause 19
Figures for mapping between channels split into Uplink and
Downlink parts in clause 5.3.1 and 6.1.3.
2007-03 RAN#35 RP-070136 S1-U and S1-MME used throughout the document; 0.9.0 1.0.0
aGW replaced by EPC when still used;
Clean version for information
Change history (after approval)

Date TSG # TSG Doc. CR Rev Cat Subject/Comment New
version
2007-03 RP-35 RP-070136 - Approved at TSG-RAN #35 and placed under Change Control 8.0.0
2007-06 RP-36 RP-070399 0001 1 Changes to management-, handover-, paging- and NAS functions, node- 8.1.0
synchronization, X2 UP protocol stack, X2 inter cell load management, IP
fragmentation, intra-LTE HO, and TA relation to cells in eNB
RP-36 RP-070494 0002 1 Update on Mobility, Security, Random Access Procedure, etc… 8.1.0
RP-36 RP-070399 0003 - Update on MBMS 8.1.0
2007-09 RP-37 RP-070637 0004 1 Update on Security, System Information, Mobility, MBMS and DRX 8.2.0
RP-37 RP-070637 0005 1 Correction of synchronization, handover, trace, eMBMS architecture, and 8.2.0
S1 common functions and procedures
2007-12 RP-38 RP-070913 0006 1 Clean up and update on security, scheduling, mobility, MBMS and DRX 8.3.0
RP-38 RP-070913 0007 - Mobility management 8.3.0
RP-38 RP-070913 0008 - Correction of eMBMS functions and NAS handling during X2 handover 8.3.0
RP-38 RP-071048 0009 - Update of Stage 2 to incorporate Interworking with cdma2000 8.3.0
2008-03 RP-39 RP-080192 0010 - CR to 36.300 on NAS States, Persistent Scheduling, C-RNTI Allocation at 8.4.0
Handover…
RP-39 RP-080192 0011 - RAN3 corrections to 36.300 (CR0011) 8.4.0
2008-05 RP-40 RP-080406 0012 1 Introduction of optimized FS2 for TDD 8.5.0
RP-40 RP-080406 0013 1 System Information, Mobilty, QoS and miscellaneous updates 8.5.0
RP-40 RP-080406 0014 - Updates to Stage 2 based on Stage 3 progress on CDMA inter-working 8.5.0
RP-40 RP-080406 0016 1 CR 0016r1 to 36.300 on CSG mobility performance guidelines 8.5.0
RP-40 RP-080406 0017 - CR to 36.300 on AS-NAS interaction 8.5.0
RP-40 RP-080420 0018 1 RAN3 agreed changes to TS 36.300 8.5.0
RP-40 RP-080463 0019 - Network Interface for ETWS support based on CBS solution 8.5.0
2008-09 RP-41 RP-080688 0020 - Correction for Rename of L1/L2 control channel 8.6.0
RP-41 RP-080688 0021 - CR to 36.300 on Paging Channel Description 8.6.0
RP-41 RP-080688 0022 - Proposed updates to Stage 2 for CDMA2000 handover 8.6.0
RP-41 RP-080688 0023 - CR to 36.300 on Semi-Persistent Scheduling 8.6.0
RP-41 RP-080688 0024 - CR to 36.300 on System Information 8.6.0
RP-41 RP-080688 0026 - Clarification of PDCCH description 8.6.0
RP-41 RP-080688 0027 - Removal of DRX interval threshold in 36.300 8.6.0
RP-41 RP-080688 0028 - CR on Randon Access procedure 8.6.0
RP-41 RP-080688 0032 1 Transport of NAS messages by AS during Handover 8.6.0
RP-41 RP-080688 0034 - CR to 36.300 capturing home eNB conclusions of RAN2 #63 8.6.0
RP-41 RP-080688 0035 - Changes to TS 36.300 agreed in RAN3#61 8.6.0
3GPP
Release 17 392 3GPP TS 36.300 V17.2.0 (2022-09)
2008-12 RP-42 RP-081016 0036 - CR0036 to 36.300 [Rel-8] on Contention Resolution 8.7.0
RP-42 RP-081016 0037 - CR0037 to 36.300 [Rel-8] on ETWS SIB 8.7.0
RP-42 RP-081016 0038 - Alignment of 36.300 with stage 3 on 1xRTT CSfallback 8.7.0
RP-42 RP-081016 0039 1 Data handling in UE during Inter-RAT mobility 8.7.0
RP-42 RP-081016 0040 - Removing of end time for dedicated preamble 8.7.0
RP-42 RP-081016 0041 - Remove the Note about RA preamble for FS2 8.7.0
RP-42 RP-081016 0042 - Clarification of AS-NAS concatenation - Stage 2 8.7.0
RP-42 RP-081016 0044 - CR 0044 to 36.300 on Miscellaneous corrections 8.7.0
RP-42 RP-081016 0046 1 Proposed CR to 36.300 [Rel-8] on Security Overview 8.7.0
RP-42 RP-081016 0047 - Proposed CR to 36.300 [Rel-8] on MBMS 8.7.0
RP-42 RP-081016 0050 - PDCP reordering function removal 8.7.0
RP-42 RP-081016 0052 - Align Number of Cell Identities 8.7.0
RP-42 RP-081016 0055 2 Periodic Updates In Connected Mode DRX 8.7.0
RP-42 RP-081016 0056 - Cleaning of the figure w.r.t Handover Control Plane - CR to TS 36.300 8.7.0
RP-42 RP-081016 0057 - CR to 36.300 to capture measurement model for EUTRAN 8.7.0
RP-42 RP-081016 0058 2 CSG Mobility Updates from RAN2 #63bis and RAN2 #64 8.7.0
RP-42 RP-081016 0059 - CR to 36.300 on Correction of the Description of FS2 8.7.0
RP-42 RP-081016 0060 - Changes to TS 36.300 agreed in RAN3#61bis and RAN3#62 8.7.0
2009-03 RP-43 RP-090123 0061 1 CR to 36.300 - Clarification on RAPreambles 8.8.0
RP-43 RP-090123 0062 - CR to 36.300 on E-UTRAN Identities 8.8.0
RP-43 RP-090123 0063 1 CR to 36.300 - MME in temporary UE identity 8.8.0
RP-43 RP-090123 0064 - UE with SIM in EUTRA 8.8.0
RP-43 RP-090123 0065 - Collected 36.300 corrections 8.8.0
RP-43 RP-090123 0066 - CR for 36.300 on Local NACK feature 8.8.0
RP-43 RP-090123 0067 - CR for allowed CSG list 8.8.0
RP-43 RP-090123 0068 3 UE capability transfer upon handover to E-UTRA 8.8.0
RP-43 RP-090123 0069 1 Inter-RAT ANR Function for CDMA2000 8.8.0
RP-43 RP-090123 0070 - Corrections to Handover Scenario 8.8.0
RP-43 RP-090123 0071 - Corrections to Security for alignment with 33.401 8.8.0
RP-43 RP-090134 0072 - Establishment of X2 Interface to HeNB GW 8.8.0
RP-43 RP-090134 0073 - Clarification of PLMN id to be used in E-CGI and Global eNB ID 8.8.0
RP-43 RP-090134 0074 - Specification of UL PDUs handling 8.8.0
RP-43 RP-090134 0075 - Update of AMBR Concept with UE-AMBR and APN-AMBR 8.8.0
RP-43 RP-090134 0076 - Aligning E-RAB release request procedure with E-RAB release indication 8.8.0
in 36.413
RP-43 RP-090134 0077 - Stage 2 CR on S1 CDMA2000 Tunnelling Function 8.8.0
RP-43 RP-090134 0078 - Finalisation of dynamic configuration of the X2 and S1 interfaces 8.8.0
RP-43 RP-090134 0079 - Addition and correction of X2 procedures in stage 2 specification 8.8.0
RP-43 RP-090134 0080 - NNSF Description 8.8.0
RP-43 RP-090134 0081 - Collection of minor corrections to 36.300 agreed by RAN3 8.8.0
RP-43 RP-090134 0082 - Data Forwarding Resource Release 8.8.0
RP-43 RP-090134 0083 - Support of Paging Optimisation for CSG cells 8.8.0
RP-43 RP-090134 0084 - Handling of trace session and location reporting during UE context release 8.8.0
2009-06 RP-44 RP-090507 0085 - Proposed CR to 36.300 on RLC status report triggers 8.9.0
RP-44 RP-090507 0086 2 Updates on UE capability transfer and container handling for E-UTRA 8.9.0
RP-44 RP-090507 0089 - Proposed CR to 36.300 Rel-8 on FFS and outdated statements 8.9.0
RP-44 RP-090508 0096 - Removal of no longer necessary notes 8.9.0
RP-44 RP-090508 0097 - Introduction of support for Cell traffic trace 8.9.0
RP-44 RP-090508 0098 - Correction the text about the UE History Information 8.9.0
RP-44 RP-090538 0102 - Configuration transfer 8.9.0
2009-06 RP-44 - - - TS 36.300 v9.0.0 was created based on TS 36.300 v8.9.0 9.0.0
RP-44 RP-090523 0087 1 MBMS baseline for Rel-9 LTE 9.0.0
RP-44 RP-090524 0088 - Idle mode requirements to support Hybrid Cells 9.0.0
RP-44 RP-090523 0099 - eMBMS Stage 2 description 9.0.0
RP-44 RP-090523 0100 - CR for eMBMS Deployment Alternatives in 36.300 9.0.0
RP-44 RP-090534 0101 1 QoS support for Hybrid CSG cells 9.0.0
RP-44 RP-090537 0103 - TAI based handover routing for HeNBs 9.0.0
2009-09 RP-45 RP-090906 0106 1 Correction regarding SRVCC 9.1.0
RP-45 RP-090906 0108 - Clarification on UE behaviour in case of L2 buffer overflow 9.1.0
RP-45 RP-090926 0112 1 IMS Emergency Call 9.1.0
RP-45 RP-090927 0113 - Introduction of position cause for dedicated PRACH allocation 9.1.0
RP-45 RP-090929 0114 - Adding Support for Explicit Congestion Notification 9.1.0
RP-45 RP-090930 0115 2 Agreements on inbound mobility to CSG 9.1.0
RP-45 RP-090934 0116 - Alignment to the stage3 specification 9.1.0
RP-45 RP-090928 0117 2 MBMS agreements RAN2#66bis and RAN2#67 9.1.0
RP-45 RP-090934 0123 - CR to 36.300 for Stage 2 alignment of Enhanced CSFB to 1xRTT 9.1.0
RP-45 RP-090906 0129 - Corrections to ECGI Specification 9.1.0
RP-45 RP-090932 0130 - Support for Mobility Robustness Optimization SON Function 9.1.0
RP-45 RP-090919 0132 - Addition of missing Resource Status Reporting procedures 9.1.0
RP-45 RP-090931 0133 - HeNB Access Mode Sginalling 9.1.0
3GPP
Release 17 393 3GPP TS 36.300 V17.2.0 (2022-09)
RP-45 RP-090931 0134 - QoS principles in Hybrid access cell 9.1.0

RP-45 RP-090933 0136 - Introduction of PWS (which includes ETWS and CMAS) delivery function 9.1.0
RP-45 RP-090928 0137 1 Dynamic service multiplexing 9.1.0
RP-45 RP-090928 0138 - MBMS SYNC configuration 9.1.0
RP-45 RP-090932 0140 - Adding Mobility Load Balancing (MLB) use case to the SON clause 9.1.0
RP-45 RP-090919 0141 - Handling of Radio Link Failure and S1 UE Context Release Request 9.1.0
RP-45 RP-090919 0142 - Introduction of informative text on Initial Context Setup failure 9.1.0
RP-45 RP-090931 0143 - Support for paging optimization with CSG membership changes 9.1.0
2009-12 RP-46 RP-091314 0145 - CR on the usage of Transparent Mode MAC 9.2.0
RP-46 RP-091343 0146 2 Capturing HeNB inbound mobility agreements 9.2.0
RP-46 RP-091331 0148 1 ETWS correction to 36.300 9.2.0
RP-46 RP-091314 0150 - Inclusion of INTER RAT HANDOVER INFO at HO from UTRAN to GERAN 9.2.0
RP-46 RP-091341 0151 1 MBMS Agreements 9.2.0
RP-46 RP-091346 0152 - Measurement Overview 9.2.0
RP-46 RP-091345 0153 1 High level feature description of CMAS 9.2.0
RP-46 RP-091344 0154 1 RACH optimization in 36.300 9.2.0
RP-46 RP-091314 0156 1 Correction on the precondition for cell reselection to HRPD 9.2.0
RP-46 RP-091346 0158 1 Miscellaneous corrections to 36.300 (Rel-9) 9.2.0
RP-46 RP-091343 0162 - Renaming Allowed CSG List (36.300, Rel-9) 9.2.0
RP-46 RP-091344 0165 - The scope and method for HO negotiations 9.2.0
RP-46 RP-091151 0166 1 Access control for handover procedures to LTE CSG/hybrid cells 9.2.0
RP-46 RP-091341 0167 - Admission Control in MCE 9.2.0
RP-46 RP-091341 0168 - Clarification on SFN Synchronization 9.2.0
RP-46 RP-091341 0169 1 BMSC-MCE signaling synchronization in session start message 9.2.0
RP-46 RP-091341 0170 - CR on multiplexing decision and DSP length 9.2.0
RP-46 RP-091237 0171 1 M3AP stage 2 9.2.0
RP-46 RP-091150 0172 1 M2AP stage 2 9.2.0
RP-46 RP-091340 0173 - CR for Transportation support for LPPa 9.2.0
RP-46 RP-091341 0174 - Introduction of MBMS for LTE: C- and U-Plane synchronisation principles 9.2.0
RP-46 RP-091341 0175 - CR on Mechanism for Consecutive Packet Loss in 36.300 9.2.0
RP-46 RP-091332 0177 - Overload reduction 9.2.0
RP-46 RP-091344 0178 - The scope and method for HO negotiations 9.2.0
RP-46 RP-091344 0179 - Introduction of MRO procedures in stage 2 9.2.0
RP-46 RP-091341 0180 1 MCE to MME session start response 9.2.0
RP-46 RP-091332 0182 - In order delivery of the multiple NAS PDUs 9.2.0
2010-03 RP-47 RP-100305 0183 - Correction regarding support of multiple MBSFN areas 9.3.0
RP-47 RP-100305 0184 1 Correction to MBMS terminology 9.3.0
RP-47 RP-100305 0185 - Corrections on eNB muting MBSFN transmission 9.3.0
RP-47 RP-100305 0186 - Corrections to TS 36.300 on MBMS 9.3.0
RP-47 RP-100306 0187 - CR capturing HeNB inbound mobility agreeements 9.3.0
RP-47 RP-100308 0188 - Remove FFSs from RAN2 specifications 9.3.0
RP-47 RP-100296 0189 - SIM based access for Emergency calls in LTE 9.3.0
RP-47 RP-100304 0191 - RA for Positioning 9.3.0
RP-47 RP-100305 0192 - Corrections to TS 36.300 on MBMS 9.3.0
RP-47 RP-100308 0196 1 Stage 2 update for Full Configuration Handover for handling earlier eNB 9.3.0
releases
RP-47 RP-100296 0197 - Handling Kasme mismatch for IMS Emergency calls 9.3.0
RP-47 RP-100308 0199 - Correction to MTU endpoint 9.3.0
RP-47 RP-100307 0200 - Stage 2 correction of Load Reporting for MLB 9.3.0
RP-47 RP-100307 0201 - CR for Allowed Range in Negotiation 9.3.0
RP-47 RP-100307 0202 - Clarification of definitions of HO failure cases 9.3.0
RP-47 RP-100307 0203 - Clarification on the usage of the mechanism to transfer IRAT MLB 9.3.0
information
RP-47 RP-100305 0204 - MBMS Session Update in M3AP stage 2 9.3.0
RP-47 RP-100305 0205 - Correction on radio bearer configuration 9.3.0
RP-47 RP-100305 0206 - Correction to the MSAP occasion implied by SYNC timestamp 9.3.0
RP-47 RP-100305 0207 - MCCH related BCCH content 9.3.0
RP-47 RP-100305 0208 - MCCH update synchronization 9.3.0
RP-47 RP-100305 0209 - MBMS Session Update in M2AP stage 2 9.3.0
RP-47 RP-100305 0210 - CR for MBMS User Data flow synchronisation in 36.300 9.3.0
RP-47 RP-100305 0211 - MBMS User Data flow synchronisation 9.3.0
RP-47 RP-100305 0212 - Packet dropping 9.3.0
RP-47 RP-100305 0213 - SYNC sequence duration configuration in MCE 9.3.0
RP-47 RP-100305 0214 - Adding the description of simultaneously change of SIB13 and MCCH 9.3.0
RP-47 RP-100305 0215 - Addition u-plane protocol stack for M1 9.3.0
RP-47 RP-100295 0217 - Queue concurrent NAS messages if necessary for in seq delivery 9.3.0
RP-47 RP-100295 0219 - Support of X2 Inter-PLMN HO 9.3.0
RP-47 RP-100300 0220 - Clarifications on CSG process definition and mobility procedures 9.3.0
RP-47 RP-100300 0221 - Corrections of HeNB 9.3.0
RP-47 RP-100300 0222 - CSG expiry Handling 9.3.0
3GPP
Release 17 394 3GPP TS 36.300 V17.2.0 (2022-09)
RP-47 RP-100295 0224 - eNB/MME Status Transfer procedure 9.3.0

RP-47 RP-100308 0225 - SPID implementation guidelines 9.3.0
RP-47 RP-100308 0226 - Handling of handover restriction for emergency call 9.3.0
RP-47 RP-100300 0227 - Some corrections for HeNB 9.3.0
2010-06 RP-48 RP-100556 0228 - CR to 36.300 for CSFB to 1xRTT 9.4.0
RP-48 RP-100554 0229 1 Proposed CR to 36.322 on RLC re-establishment for MBMS 9.4.0
RP-48 RP-100551 0231 - Stage2 correction for HeNB inbound handover 9.4.0
RP-48 RP-100554 0235 - CR to 36.300 on MBMS terminology 9.4.0
RP-48 RP-100570 0238 1 Add MOBILITY SETTINGS CHANGE Procedure to X2-CP Procedure 9.4.0
clause
RP-48 RP-100556 0239 - Introduction of trace functions and procedures in S1 clauses of 36.300 9.4.0
(contact: Motorola)
RP-48 RP-100554 0240 - Correction of Synchronization Sequence (contact: Alcatel-Lucent Shanghai 9.4.0
Bell, Alcatel-Lucent)
RP-48 RP-100552 0241 - Clarification of CSG / Hybrid cell definitions (contact: Ericsson) 9.4.0
RP-48 RP-100555 0242 - SON stage 2 clean up (contact: Samsung, Nokia Siemens Networks) 9.4.0
RP-48 RP-100555 0243 - Updating Stage-2 on R9 Automatic Neighbour Relation Function (contact: 9.4.0
ETRI, Samsung)
RP-48 RP-100554 0244 1 Adding of description in EUTRAN for IP Multicast (contact: NEC) 9.4.0
RP-48 RP-100556 0245 - Correction of trace failure description in Stage 2 (contact: NEC, Motorola, 9.4.0
Huawei)
RP-48 RP-100554 0246 - Correction of packet dropping (contact: Alcatel-Lucent Shanghai Bell, 9.4.0
Alcatel-Lucent)
RP-48 RP-100552 0247 - Clarification of paging optimization (contact: Qualcomm) 9.4.0
RP-48 RP-100561 0230 3 Stage 2 description of Carrier Aggregation 10.0.0
RP-48 RP-100562 0232 1 Stage-2 description of relaying into 36.300 10.0.0
2010-09 RP-49 RP-100865 0248 4 Corrections and new Agreements on Carrier Aggregation 10.1.0
RP-49 RP-100866 0249 1 36.300 CR for stage 2 RAN #70bis and #71 agreements of relaying 10.1.0
RP-49 RP-100866 0255 - Start-up procedure for relays 10.1.0
RP-49 RP-100851 0257 - Keeping neighbouring eNBs up-to-date with complete list of served cells 10.1.0
(contact: NSN)
RP-49 RP-100851 0259 - Description of Energy Saving mechanisms (contact: Ericsson) 10.1.0
RP-49 RP-100866 0260 - Handover request routing toward RN (contact: Huawei) 10.1.0
RP-49 RP-100853 0262 - MBMS Session Update procedure (contact: Motorola) 10.1.0
RP-49 RP-100860 0264 - CS Fallback Indication and Handover Restriction List (contact: NEC) 10.1.0
RP-49 RP-100866 0265 - X2-AP non UE dedicated messages handling (contact: Huawei) 10.1.0
RP-49 RP-100866 0266 - Detach procedure for relays (contact: NTT DOCOMO) 10.1.0
RP-49 RP-100866 0267 1 RN and DeNB OAMs should be able to exchange info (contact: Ericsson) 10.1.0
RP-49 RP-100882 0268 - CSFB summary 10.1.0
2010-12 RP-50 RP-101226 0269 2 Corrections and new agreements on Carrier Aggregation 10.2.0
RP-50 RP-101206 0271 - 36300_CRxxx_Handover for Hybrid Cells 10.2.0
RP-50 RP-101208 0273 - Correction on MAC padding on MCH 10.2.0
RP-50 RP-101228 0274 3 Additions and corrections to relaying description 10.2.0
RP-50 RP-101231 0275 1 LTE - Stage 2 agreements on MBMS enhancement 10.2.0
RP-50 RP-101214 0276 1 CR to 36.300 adding e1xCSFB support for dual Rx/Tx UE 10.2.0
RP-50 RP-101214 0277 - Editorial Clean-Up 10.2.0
RP-50 RP-101229 0278 1 Introduction of enhanced ICIC 10.2.0
RP-50 RP-101214 0285 2 Setting of Maximum Bit Rate (MBR) to be greater than the Guaranteed Bit 10.2.0
Rate (GBR) over E-UTRA: MBR enforcement at eNB side.
RP-50 RP-101214 0286 - CR for Description of Energy Saving 10.2.0
RP-50 RP-101228 0287 - S1 non UE associated message handling 10.2.0
RP-50 RP-101214 0288 - Clarification to ANR Operation 10.2.0
RP-50 RP-101228 0289 - P-GW function embedded in DeNB and addressing requirements 10.2.0
RP-50 RP-101228 0290 - eNB Configuration Update procedure in RN startup and detach procedure 10.2.0
RP-50 RP-101231 0291 - Introduction of MCE initiated MBMS Session Start Request 10.2.0
RP-50 RP-101228 0292 - No NNSF function in RN 10.2.0
RP-50 RP-101228 0293 - S1 handover routing toward RN 10.2.0
RP-50 RP-101228 0294 - TNL address Handling 10.2.0
RP-50 RP-101214 0295 - Correction on SPID Transfer 10.2.0
RP-50 RP-101231 0296 - Support of ARP Pre-emption 10.2.0
RP-50 RP-101231 0297 - Support of MBMS Service Counting Report procedure 10.2.0
RP-50 RP-101222 0298 - Stage 2 for the X2 based mobility enhancement between HeNBs 10.2.0
RP-50 RP-101230 0299 - Introduction of event-triggered inter-RAT cell load reporting 10.2.0
RP-50 RP-101216 0300 - Introduction of LIPA function 10.2.0
RP-50 RP-101228 0301 - OAM requirements for QCI to DSCP mapping config for relays 10.2.0
RP-50 RP-101228 0302 - Non UE associated message handling 10.2.0
RP-50 RP-101224 0303 - Introduction of MTC Overload Support 10.2.0
RP-50 RP-101228 0304 - Relay Node Un Signalling Transport Support 10.2.0
RP-50 RP-101214 0305 - Complete S1 Interface Signalling Procedures 10.2.0
3GPP
Release 17 395 3GPP TS 36.300 V17.2.0 (2022-09)
RP-50 RP-101229 0306 1 X2 procedure and OAM requirements to support eICIC 10.2.0
RP-50 RP-101228 0307 - Stage-2 updates to RN initial attachment 10.2.0
RP-50 RP-101230 0308 - Functionality of SON MRO defined for Rel.10 10.2.0
2011-03 RP-51 RP-110280 0309 - Enforcing uplink MBR in the eNodeB 10.3.0
RP-51 RP-110291 0310 - Implementation Updates on Non-UE associated S1X2 message Handling 10.3.0
RP-51 RP-110292 0311 - Introduction of 2 subsets for pattern 3 10.3.0
RP-51 RP-110280 0312 - MBR management for uplink grant 10.3.0
RP-51 RP-110289 0313 - Measurements in CA 10.3.0
RP-51 RP-110289 0314 1 Annex J Clean Up 10.3.0
RP-51 RP-110291 0317 - Stage-2 relay updates 10.3.0
RP-51 RP-110291 0320 2 stage-2 clarification on relay security 10.3.0
RP-51 RP-110280 0321 - stage-2 Clarification on handover and system information description 10.3.0
RP-51 RP-110280 0324 - CR to 36.300 adding UE capability indicator for dual Rx/Tx e1xCSFB 10.3.0
RP-51 RP-110292 0328 1 Update of Inter-cell Interference Coordination Feature Description 10.3.0
RP-51 RP-110292 0330 1 CR on ABS definition 10.3.0
RP-51 RP-110280 0331 - Fix incorrect name for CT4 GTP message in HO Procedure 10.3.0
RP-51 RP-110280 0332 - CR for MBMS User Data flow synchronisation 10.3.0
RP-51 RP-110294 0333 - Remove Procedure Lists for MBMS 10.3.0
RP-51 RP-110283 0334 - Routing functionality for X2 handover between HeNB 10.3.0
RP-51 RP-110291 0335 - Update to OAM Traffic QoS requirements 10.3.0
RP-51 RP-110278 0336 - Completion of LIPA feature 10.3.0
RP-51 RP-110293 0337 - Editorial update for inter-RAT load reporting 10.3.0
RP-51 RP-110280 0338 - Correction of MBMS Deployment consideration 10.3.0
RP-51 RP-110292 0339 - OAM requirement for time domain eICIC for macro-pico scenario 10.3.0
RP-51 RP-110293 0340 - Cleanup of MRO 10.3.0
RP-51 RP-110291 0341 - Stage-2 Updates of Relaying 10.3.0
RP-51 RP-110278 0342 - Clean up of LIPA 10.3.0
RP-51 RP-110272 0344 - Correction to usage of Handover Report for MRO 10.3.0
RP-51 RP-110291 0345 - Clarification of the RN authorisation 10.3.0
RP-51 RP-110293 0346 - Requirements for OAM control of MRO 10.3.0
RP-51 RP-110278 0347 - LIPA packets reordering in downlink 10.3.0
RP-51 RP-110282 0348 - Support for MDT 10.3.0
RP-51 RP-110280 0349 - Introduction of a Stepwise Load Reduction Indication for the Overload 10.3.0
procedure in Stage 2
RP-51 RP-110294 0350 - Remove FFS on Differentiating the Receiving or Interested UEs 10.3.0
RP-51 RP-110223 0352 - Correction on MBMS Reset procedure 10.3.0
RP-51 RP-110291 0353 - Clarification of RN Architecture and Startup 10.3.0
RP-51 RP-110291 0354 - Miscellaneous small corrections to TS 36.300 on Relay 10.3.0
RP-51 RP-110294 0355 - Suspension and Resume function 10.3.0
RP-51 RP-110280 0356 - Correction on physical layer part on TS 36.300 10.3.0
RP-51 RP-110405 0358 3 CSFB to GERAN 10.3.0
2011-06 RP-52 RP-110839 0359 - clarification on redirection in 36.300 10.4.0
RP-52 RP-110850 0360 - CR to 36.300 for eICIC updates 10.4.0
RP-52 RP-110836 0361 - Update of the MCCH Structure description for CountingRequest message 10.4.0
RP-52 RP-110839 0362 - Miscellaneous corrections to 36.300 10.4.0
RP-52 RP-110850 0363 1 Correctoin on eICIC description 10.4.0
RP-52 RP-110839 0365 2 Some small corrections to 36.300 10.4.0
RP-52 RP-110846 0369 - UE receiver window for Inter-band non-contiguous CA 10.4.0
RP-52 RP-110843 0370 1 Capture the stage2 RLF agreement 10.4.0
RP-52 RP-110839 0372 - Clarification on MME selection 10.4.0
RP-52 RP-110839 0373 - Correction on the Release of Supporting SRVCC 10.4.0
RP-52 RP-110839 0374 - Correction of the area restrictions description 10.4.0
RP-52 RP-110839 0375 - Correcting the Note regarding the usage of the GUMMEI 10.4.0
RP-52 RP-110836 0376 - Correction of Counting Function 10.4.0
RP-52 RP-110836 0377 - Correction of MBMS Service Suspension and Resumption Function 10.4.0
RP-52 RP-110849 0378 - Relaying Stage 2 Corrections 10.4.0
RP-52 RP-110839 0379 - Correction of Reset 10.4.0
RP-52 RP-110839 0380 - Cleanup general topics before Rel-10 closure 10.4.0
RP-52 RP-110839 0381 - Cleanup of HeNB related topics before Rel-10 closure 10.4.0
RP-52 RP-110713 0382 - Clarification to detection of unnecessary IRAT handover 10.4.0
RP-52 RP-110714 0383 - Release the UE context in the source HeNB-GW after HeNB-HeNB X2 HO 10.4.0
RP-52 RP-110851 0384 - Corrections of MRO 10.4.0
2011-09 RP-53 RP-111280 0388 - RLC/MAC synchronization for MBSFN 10.5.0
RP-53 RP-111297 0390 - Miscellaneous correction to 36.300 on Security Overview 10.5.0
RP-53 RP-111297 0391 - Corrections to 1xRTT CS Fallback 10.5.0
RP-53 RP-111287 0392 - Corrections on MCCH and MBMS counting 10.5.0
RP-53 RP-111297 0393 - Correction on the MME Direct Information Transfer procedure 10.5.0
RP-53 RP-111290 0394 - Security Mechanism for H(e)NB "no-IPsec" usage option 10.5.0
RP-53 RP-111287 0395 - Correction of MBMS Suspension Function 10.5.0
RP-53 RP-111288 0396 - Cleanup of editor's notes for relay 10.5.0
3GPP
Release 17 396 3GPP TS 36.300 V17.2.0 (2022-09)
RP-53 RP-111292 0397 - Correction on LIPA PDN Deactivation for X2 HO 10.5.0

RP-53 RP-111290 0398 - Correction of Release Indication 10.5.0
RP-53 RP-111297 0399 - Correction of Trace Function 10.5.0
RP-53 RP-111288 0400 - RN security correction 10.5.0
RP-53 RP-111297 0401 - Correction of Emergency Call 10.5.0
RP-53 RP-111290 0402 - Overload Handling by HeNB GW 10.5.0
RP-53 RP-111287 0403 - Synchronisation of MBMS Service Resumption 10.5.0
RP-53 RP-111287 0404 - Miscellaneous Correction for MBMS 10.5.0
RP-53 RP-111291 0405 1 Small correction on unnecessary IRAT HO 10.5.0
RP-53 RP-111297 0406 - Clarification of TAI handling between MME and HeNB(-GW) 10.5.0
2011-12 RP-54 RP-111714 0411 - Correction on RN security 10.6.0
RP-54 RP-111711 0413 - HeNB Architecture Clarification 10.6.0
RP-54 RP-111604 0414 1 Correction of Support for RACH optimization 10.6.0
RP-54 RP-111711 0415 - Correction of inbound mobility 10.6.0
RP-54 RP-111714 0416 - Correction of MBMS Resumption Function 10.6.0
RP-54 RP-111711 0418 - Routing of MME Direct Information Transfer message 10.6.0
RP-54 RP-111714 0419 - Correction of support for Mobility Robustness Optimisation 10.6.0
RP-54 RP-111714 0420 - Clarification of MRO Unnecessary Handover 10.6.0
RP-54 RP-111716 0421 - Correction of the MRO stage-2 description 10.6.0
RP-54 RP-111644 0417 1 MME behavior in case of broken SCTP connection 11.0.0
RP-54 RP-111721 0422 - Addition of M3 Setup 11.0.0
RP-54 RP-111721 0423 - Correction of MCCH Update Synchronization mechanism 11.0.0
2012-03 RP-55 RP-120327 0425 - Correction to the handling of RRC container during the inter-RAT handover 11.1.0
RP-55 RP-120329 0431 - Correction on MME/eNB behaviour in case of broken SCTP connection 11.1.0
RP-55 RP-120329 0432 - Correction of Emergency Call 11.1.0
RP-55 RP-120232 0434 - Correction on unnecessary HO 11.1.0
RP-55 RP-120326 0435 - CR for clarification of eMBMS architecture description 11.1.0
RP-55 RP-120326 0437 - Restriction on Rel-10 X2-based handover between HeNBs 11.1.0
2012-06 RP-56 RP-120821 0439 3 Introduction of service continuity improvements for MBMS on LTE 11.2.0
RP-56 RP-120807 0441 - Clarification on networking sharing for MBMS 11.2.0
RP-56 RP-120812 0444 - Correction to Measurement Restriction Description of eICIC in 36.300 11.2.0
RP-56 RP-120817 0445 - Introduction of Absolute Priority Based Cell Reselection to CELL_FACH in 11.2.0
36.300
RP-56 RP-120823 0446 1 Stage-2 CR on signalling and procedure for interference avoidance for IDC 11.2.0
RP-56 RP-120822 0450 3 Stage 2 CR on eDDA UE assistance information 11.2.0
RP-56 RP-120813 0452 1 Korean Public Alert System (KPAS) and EU-Alert in relation to CMAS 11.2.0
RP-56 RP-120819 0453 1 Introduction of MDT enhancements - multi-PLMN RLF Report 11.2.0
RP-56 RP-120811 0456 - Correction on Session Start and Session Stop procedure 11.2.0
RP-56 RP-120812 0457 - Correction of the MRO definitions 11.2.0
RP-56 RP-120812 0459 - Clarification on MME's support for inter-PLMN handover to CSG and 11.2.0
hybrid cells
RP-56 RP-120811 0461 - GUMMEI handling by RN and HeNB 11.2.0
RP-56 RP-120811 0462 - Clarification on TAC in X2 Setup 11.2.0
RP-56 RP-120811 0463 - Correction of Session Update 11.2.0
RP-56 RP-120824 0464 - Addition of Energy Saving function for Inter-RAT scenario 11.2.0
RP-56 RP-120807 0465 - MCE and MBSFN role for distributed MCE architecture 11.2.0
RP-56 RP-120881 0470 1 PCI range note on RAN sharing 11.2.0
2012-09 RP-57 RP-121371 0472 - Introduction of EAB 11.3.0
RP-57 RP-121395 0475 - Corrections to physical channels of RN and the number of measurement 11.3.0
types
RP-57 RP-121374 0476 1 Network Based Positioning Support 11.3.0
RP-57 RP-121379 0481 - 36300_CR on the addition of the stage-2 agreements on IDC 11.3.0
RP-57 RP-121377 0483 1 Introduction of Carrier aggregation enhancements 11.3.0
RP-57 RP-121137 0493 - Support of MBMS Service Continuity 11.3.0
RP-57 RP-121140 0494 - Correction of GUMMEI 11.3.0
RP-57 RP-121382 0495 - Verification of HeNB Identity 11.3.0
RP-57 RP-121140 0496 - Introduction of UE Radio Capability Match procedure 11.3.0
RP-57 RP-121372 0497 - Support for inter-RAT MRO 11.3.0
RP-57 RP-121140 0498 - EAB for CN Overload Control 11.3.0
RP-57 RP-121372 0499 - Description of the failure information retrieval function for SON MRO 11.3.0
purposes
RP-57 RP-121372 0500 - Description of the inter-RAT ping-pong problem 11.3.0
RP-57 RP-121138 0501 - Addition of UE measurements solution for Inter-RAT energy saving 11.3.0
scenario
2012-12 RP-58 RP-121953 0502 - Addition of the stage-2 agreements on IDC 11.4.0
RP-58 RP-121940 0503 - Clarification on PCell SIB15 11.4.0
RP-58 RP-121957 0504 - Clarification on Radio link failure recovery 11.4.0
RP-58 RP-121959 0505 - CR to 36.300 on introducing ROHC context continue for intra-ENB 11.4.0
handover
3GPP
Release 17 397 3GPP TS 36.300 V17.2.0 (2022-09)
RP-58 RP-121958 0506 - Introduction of network sharing for CDMA2000 inter-working 11.4.0
RP-58 RP-121932 0510 - Correction on effect of MBMS on unicast mobility procedures 11.4.0
RP-58 RP-121957 0512 - Clarification on sending timing advance updates 11.4.0
RP-58 RP-121957 0513 - Clarification on inter-RAT handover 11.4.0
RP-58 RP-121932 0518 - Correction to padding on RLC UM PDU corresponding to MTCH/MCCH 11.4.0
RP-58 RP-121952 0519 - Stage 2 aspects of UE assistance information 11.4.0
RP-58 RP-121950 0521 - Stage 2 for the FeICIC 11.4.0
RP-58 RP-121933 0528 - correction for Inter-RAT ANR 11.4.0
RP-58 RP-121955 0529 1 Introduction of CoMP 11.4.0
RP-58 RP-121948 0530 - HeNB Mobility enhancement 11.4.0
RP-58 RP-121957 0531 - Verification of HeNB 11.4.0
RP-58 RP-121957 0532 - Clarification of scenario for Handover Report procedure 11.4.0
RP-58 RP-121957 0533 - Correction of GUMMEI Type for RN 11.4.0
RP-58 RP-121948 0534 - UE context release in source HeNB GW after X2 handover from HeNB to 11.4.0
eNB
RP-58 RP-121947 0535 - Update of the stage-2 MRO specification for inter-RAT failure detection 11.4.0
RP-58 RP-121947 0536 - Update of the stage-2 MRO specification for intra-RAT HetNet failure 11.4.0
detection
RP-58 RP-121947 0537 - Update of the stage-2 MRO specification for inter-RAT ping-pong detection 11.4.0
RP-58 RP-121936 0538 - Restriction of Resource Allocation during SCell activation 11.4.0
RP-58 RP-121932 0539 - Misc corrections on MBMS 11.4.0
RP-58 RP-121957 0540 - Correction on UE Radio Capability Match 11.4.0
RP-58 RP-121957 0541 - Clarification on the use of HRL in GWCN scenarios 11.4.0
RP-58 RP-121732 0542 - Membership Verification for HeNB Enhanced Mobility 11.4.0
RP-58 RP-121739 0543 - New Information for BBF access 11.4.0
2013-03 RP-59 RP-130248 0544 2 Clarification on the ANR when UTRAN is shared 11.5.0
RP-59 RP-130241 0545 - IDC Problem Reporting 11.5.0
RP-59 RP-130247 0548 - Corrections on mobility to CSG and hybrid cells 11.5.0
RP-59 RP-130248 0550 - 36300 CR(Rel-11)_Miscellaneous correction to 36.300 on handover 11.5.0
RP-59 RP-130248 0551 - Clarification on PS handover from GERAN to EUTRAN 11.5.0
RP-59 RP-130241 0556 - Introduction of EPDCCH in TS 36.300 11.5.0
RP-59 RP-130241 0557 - Clarifying the impact of PPI on QoS 11.5.0
RP-59 RP-130241 0559 - Correction of BBF Access Interworking 11.5.0
RP-59 RP-130248 0560 - Correction of GUMMEI Type mandatory inclusion 11.5.0
RP-59 RP-130240 0561 - Correction of IRAT MRO 11.5.0
RP-59 RP-130248 0562 1 Clarification on the Absence of HRL 11.5.0
RP-59 RP-130248 0563 - Correction of update of MBMS parameters 11.5.0
2013-06 RP-60 RP-130809 0564 - Introduction of SIB16 11.6.0
RP-60 RP-130808 0565 - Correction of timing reference of sTAG 11.6.0
RP-60 RP-130809 0566 - Correction on physical layer part on TS 36.300 11.6.0
RP-60 RP-130805 0571 - Correction to correlation ID in LIPA 11.6.0
RP-60 RP-130804 0573 - Correction on the another secured interface for LIPA 11.6.0
RP-60 RP-130809 0574 - Clarification on area restriction information propagation 11.6.0
RP-60 RP-130809 0575 - Correction on the update of time of MBMS data transfer 11.6.0
RP-60 RP-130640 0577 - Correction on RLF Indication procedure 11.6.0
RP-60 RP-130809 0578 - Clarification on the UE reported timer in MRO 11.6.0
2013-09 RP-61 RP-131315 0582 - Modification to CA downlink timing difference 11.7.0
RP-61 RP-131319 0583 - Correction on the MBMS session update 11.7.0
RP-61 RP-131315 0585 - Transfer GRE key to MME for PMIP-based S5 11.7.0
RP-61 RP-131319 0586 - Correction of HeNB Verification 11.7.0
RP-61 RP-131320 0587 - Correction of Service Area Identity Null 11.7.0
RP-61 RP-131152 0588 1 Correction of terminology concerning the mobility restriction function 11.7.0
2013-12 RP-62 RP-131995 0589 - Clarification on Minimum Transport Block Size of Msg3 11.8.0
RP-62 RP-131989 0593 1 Maximum uplink transmission difference 11.8.0
RP-62 RP-131995 0604 - Correction of Weight Factor 11.8.0
RP-62 RP-132001 0597 - Load reporting between LTE and eHRPD 12.0.0
RP-62 RP-132002 0598 - LAPI for NNSF 12.0.0
RP-62 RP-132002 0599 - Restoration of eMBMS Bearer Services 12.0.0
RP-62 RP-131910 0600 - Kill All Warning Messages 12.0.0
RP-62 RP-131999 0602 - Introduction of Collocated L-GW for SIPTO@LN 12.0.0
RP-62 RP-131999 0603 - Introduction of SIPTO@LN Stand-Alone in LTE Stage 2 12.0.0
RP-62 RP-131916 0606 - Support for connected mode inbound mobility to shared CSG/hybrid cell 12.0.0
2014-03 RP-63 RP-140353 0610 - Introduction of CS to PS SRVCC 12.1.0
RP-63 RP-140351 0615 - Reporting of User Location Information at E-RAB release 12.1.0
RP-63 RP-140360 0616 - PWS Restart Indication 12.1.0
2014-06 RP-64 RP-140876 0616a 1 Update of CA deployment scenarios 12.2.0
NOTE
RP-64 RP-140892 0626 - Outdated Statement on Security Key Corruption 12.2.0
RP-64 RP-140884 0627 - Stage 2 description of eIMTA feature 12.2.0
RP-64 RP-140881 0628 - Stage 2 description of Power Saving Mode feature for LTE 12.2.0
3GPP
Release 17 398 3GPP TS 36.300 V17.2.0 (2022-09)
RP-64 RP-140888 0630 - Introduction of TDD-FDD CA into stage 2 12.2.0

RP-64 RP-140883 0636 - Stage-2 details of WLAN/3GPP Radio Interworking for LTE 12.2.0
RP-64 RP-140884 0637 - Introduction of LTE TDD eIMTA 12.2.0
RP-64 RP-140891 0638 - MBMS Bearer priority Update 12.2.0
RP-64 RP-140886 0639 - HeNB ID verification in PWS Restart Indication message 12.2.0
RP-64 RP-140897 0640 - Updating X2 GW Stage 2 Description 12.2.0
2014-09 RP-65 RP-141504 0642 - Stage-2 details of WLAN/3GPP Radio Interworking for LTE 12.3.0
RP-65 RP-141496 0645 - Clarification on Service Continuity 12.3.0
RP-65 RP-141506 0652 3 Stage 2 aspects of low complexity UE features 12.3.0
RP-65 RP-141520 0653 - Introduction of the UE history reported from the UE 12.3.0
RP-65 RP-141498 0655 - Corrections to MBMS SAI 0 12.3.0
RP-65 RP-141509 0656 - Introduction of inter-eNB CoMP 12.3.0
RP-65 RP-141505 0657 - Stage 2 alignment following introduction of context fetch 12.3.0
RP-65 RP-141511 0658 - Delete stage 3 detail on cause of the RLF 12.3.0
RP-65 RP-141508 0659 - Support of Radio-interface Based Synchronization by OAM configuration 12.3.0
RP-65 RP-141518 0660 - Introduction of CN assistance information 12.3.0
2014-12 RP-66 RP-142122 0661 - Corrections for RAN assisted WLAN interworking 12.4.0
RP-66 RP-142122 0663 - Clarification on handling of dedicated parameters upon cell 12.4.0
selection&reselection
RP-66 RP-142128 0673 - Stage-2 description of Increased Carrier monitoring feature 12.4.0
RP-66 RP-142122 0665 - Addition of SystemInformationBlockType17 into Stage 2 description 12.4.0
RP-66 RP-142115 0670 - Order of MCCH messages in a MAC PDU 12.4.0
RP-66 RP-142132 0667 - Stage-2 description of Small Cell Enhancements Physical Layer 12.4.0
RP-66 RP-142139 0671 - Introduction of NAICS 12.4.0
RP-66 RP-142129 0666 - Correction to stage 2 description of Low Complexity UEs 12.4.0
RP-66 RP-142135 0675 - Introduction of Dual Connectivity 12.4.0
RP-66 RP-142137 0681 1 Introduction of ProSe 12.4.0
RP-66 RP-142082 0683 - Addition of RLF reporting over S1 12.4.0
RP-66 RP-142132 0684 - Further detail on the required OAM configuration to support RIBS 12.4.0
RP-66 RP-142136 0685 - Completion of stage-2 inter-eNB CoMP 12.4.0
RP-66 RP-142093 0686 - TNL address selection for HeNB scenario 12.4.0
RP-66 RP-142094 0687 - X2 Removal Signaling Description 12.4.0
RP-66 RP-142140 0688 - Clarification of the usage of radio measurements in the RLF report 12.4.0
2015-03 RP-67 RP-150374 0693 - Corrections to stage 2 description of ProSe 12.5.0
RP-67 RP-150373 0692 - Addition of PDCP-PDU retransmission to PDCP functions 12.5.0
RP-67 RP-150373 0691 - Clarification on DC 12.5.0
RP-67 RP-150373 0705 - Clarification on SCG change definition 12.5.0
RP-67 RP-150375 0700 - Introduction of MBMS congestion management for Public Safety Group 12.5.0
Call
RP-67 RP-150348 0707 - Correction of the Usage of the MultibandInfoList IE 12.5.0
RP-67 RP-150373 0708 - Clarification of the description of the NAICS procedure 12.5.0
RP-67 RP-150373 0709 - Correction on SeNB behaviour for distinguishing uplink PDCP PDUs 12.5.0
RP-67 RP-150373 0710 - Correction on DL Data Forwarding for Split Bearer 12.5.0
RP-67 RP-150373 0698 1 Minor corrections on DC 36.300 12.5.0
2015-06 RP-68 RP-150921 0756 - Resource pool for out of coverage UE 12.6.0
RP-68 RP-150921 0757 - Dual Connectivity Corrections 12.6.0
RP-68 RP-150921 0758 - Corrections on Stage-2 descriptions for ProSe 12.6.0
RP-68 RP-150921 0759 1 Need for SIB18 in a cell on non-Public Safety ProSe Carrier 12.6.0
RP-68 RP-150921 0761 - Allocation of LCID in DC 12.6.0
RP-68 RP-150921 0760 2 Addition of DC Operation Overview and Minor Clarifications 12.6.0
RP-68 RP-150921 0763 - Clarification on CQI reporting in dual connectivity 12.6.0
RP-68 RP-150921 0764 - Correction to the characteristics of SL-DCH 12.6.0
RP-68 RP-150943 0712 1 Clarification on UE-AMBR for split bearer 12.6.0
RP-68 RP-150921 0723 1 Introduction of Group Call eMBMS congestion management 12.6.0
RP-68 RP-150921 0721 2 Correction on SeNB initiated SeNB Modification procedure 12.6.0
RP-68 RP-150921 0733 - Correction on MeNB behaviour for distinguishing downlink PDCP PDUs 12.6.0
2015-06 RP-68 RP-150946 0771 - eMBMS Alternative IP Multicast distribution address 13.0.0
RP-68 RP-150925 0711 4 Introduction of enhanced inter-eNB CoMP 13.0.0
RP-68 RP-150945 0730 6 SON support for dynamic deployment changes 13.0.0
2015-09 RP-69 RP-151520 0792 - Sidelink terminology alignment in TS 36.300 13.1.0
2015-12 RP-70 RP-152074 0796 - Introduction of DC enhancement 13.2.0
RP-70 RP-152075 0801 - Introduction of RS-SINR measurements 13.2.0
RP-70 RP-152053 0803 - Corrections on sidelink related description in TS 36.300 13.2.0
RP-70 RP-152077 0809 1 Introduction of LTE-WLAN Radio Level Integration and Interworking 13.2.0
Enhancement stage-2
RP-70 RP-152080 0799 1 Introduction of SC-PTM 13.2.0
RP-70 RP-152081 0797 1 Removing SCG change restrictions regarding upon handover 13.2.0
RP-70 RP-152075 0806 2 Introduction of MCLD 13.2.0
RP-70 RP-152069 0810 2 Introduction of low complexity UE and enhanced coverage features 13.2.0
RP-70 RP-152072 0820 - Introduction of eD2D 13.2.0
3GPP
Release 17 399 3GPP TS 36.300 V17.2.0 (2022-09)
RP-70 RP-152080 0813 - Introduction of SC-PTM 13.2.0

RP-70 RP-152084 0814 - Introduction of PWS Failure Indication message 13.2.0
RP-70 RP-152084 0815 - Addition of the information on the notification for planned reconfiguration 13.2.0
RP-70 RP-152070 0816 - Enhanced overload procedure in RAN sharing 13.2.0
RP-70 RP-152081 0817 - Tunnel Information of BBAI in Dual Connectivity 13.2.0
RP-70 RP-152081 0818 - Adding CSG support to DC 13.2.0
RP-70 RP-152081 0819 - Support of SIPTO@LN and LIPA for DC 13.2.0
RP-70 RP-152070 0728 11 Monitoring traffic volume per QoS group per PLMN 13.2.0
RP-70 RP-152081 0772 6 Introduction of handover enhancement for Dual Connectivity 13.2.0
RP-70 RP-152067 0779 5 Introduction of Dedicated Core Network (DECOR) feature 13.2.0
RP-70 RP-152076 0821 - Introducing extended DRX 13.2.0
RP-70 RP-152078 0798 2 Introduction of Licensed-Assisted Access using LTE 13.2.0
RP-70 RP-152050 0794 1 IDC Overview Correction 13.2.0
RP-70 RP-152083 0800 3 Introduction of Stage 2 text for LTE-WiFi integration for legacy WLAN 13.2.0
RP-70 RP-151957 0822 - 36.300 CR for capturing B5C and PUCCH on SCell 13.2.0
2016-03 RP-71 RP-160470 0824 1 Clarification on SC-PTM 13.3.0
RP-71 RP-160470 0825 1 Clarification related to SC-MCCH Change Notification 13.3.0
RP-71 RP-160467 0827 - Clarification on Split bearer 13.3.0
RP-71 RP-160470 0829 3 IDC support in LAA 13.3.0
RP-71 RP-160456 0830 - Paging occasion monitoring when eDRX is configured 13.3.0
RP-71 RP-160458 0839 4 Stage-2 text for LWIP Tunnel Clarifications 13.3.0
RP-71 RP-160457 0840 2 TS 36.300 Stage-2 CR correction for LWA 13.3.0
RP-71 RP-160454 0841 2 Clean up and corrections for eD2D 13.3.0
RP-71 RP-160470 0842 1 Mapping between Channel Access Priority Classes and QCI values 13.3.0
RP-71 RP-160470 0843 2 Multiplexing of data in LAA 13.3.0
RP-71 RP-160470 0847 - Clarification on the synchornized MBSFN transmission 13.3.0
RP-71 RP-160467 0848 - Maximum UL transmission timing reference in DC 13.3.0
RP-71 RP-160457 0849 2 Stage 2 CR on LTE-WLAN Radio Level 13.3.0
RP-71 RP-160470 0852 - Correction on SC-MCCH change notification 13.3.0
RP-71 RP-160457 0853 - QoS parameters handling during LWA bearer establishment/modification 13.3.0
RP-71 RP-160470 0854 - Correction on overload enhancement 13.3.0
RP-71 RP-160453 0855 - Introduction of Paging Optimisation and Paging for Coverage 13.3.0
Enhancement capable UEs
RP-71 RP-160457 0856 - Configuration of the flow control type 13.3.0
RP-71 RP-160457 0857 - Xw Dynamic Configuration 13.3.0
RP-71 RP-160449 0858 - UE context retention at SCTP recovery 13.3.0
RP-71 RP-160449 0859 - Addition of X2 Removal Threshold to the X2 Removal Request message 13.3.0
RP-71 RP-160470 0860 - SC-PTM reception on non-Pcell 13.3.0
RP-71 RP-160451 0863 - Correction on CSG and LIPA/SIPTO support to DC 13.3.0
2016-06 RP-72 RP-161080 0864 - Corrections to MTCe in TS 36.300 13.4.0
RP-72 RP-161080 0872 - Measurement gap assisted intra-frequency measurement in case of 13.4.0
narrowband operation
RP-72 RP-161080 0875 - Correction to eMTC message classes and logical channels 13.4.0
RP-72 RP-161080 0865 - Clarification on LWA 13.4.0
RP-72 RP-161080 0869 - Miscellaneous Stage-2 corrections for LWA 13.4.0
RP-72 RP-161080 0873 - Correction of RCLWI call flow 13.4.0
RP-72 RP-161080 0866 - Clarification on DC 13.4.0
RP-72 RP-161080 0878 - Stage 2 aspects of HARQ functionality for eMTC UEs 13.4.0
RP-72 RP-161080 0867 - Corrections for sidelink description 13.4.0
RP-72 RP-161080 0868 1 Correction on conditions for Relay and Remote UE operation 13.4.0
RP-72 RP-161080 0874 1 Correction on UL asynchronous HARQ 13.4.0
RP-72 RP-161080 0879 1 Clarification on WLAN connection status reporting for RCLWI 13.4.0
RP-72 RP-161080 0884 - Correction on WT Association Confirmation 13.4.0
RP-72 RP-161080 0885 - Correction on WT initiated WT Modification procedure 13.4.0
RP-72 RP-161080 0886 - Correction on flow control 13.4.0
RP-72 RP-161080 0881 1 Correction on DRS Duty Cycle 13.4.0
RP-72 RP-161081 0880 3 Introduction of NB-IoT 13.4.0
RP-72 RP-161081 0882 - Introduction Control Plane CIoT EPS Optimization 13.4.0
RP-72 RP-161081 0883 - Introduction of the UE context resume function 13.4.0
RP-72 RP-161082 0887 - Correction of Reroute NAS Request 13.4.0
2016-09 RP-73 RP-161757 0889 1 Clarification on LWIP 13.5.0
RP-73 RP-161755 0890 1 Clarification on HARQ 13.5.0
RP-73 RP-161756 0891 - Small corrections to LWA 13.5.0
RP-73 RP-161757 0893 2 Corrections to the coexistence of LWIP and DC, LWA, RCLWI, RAN 13.5.0
assisted WLAN interworking
RP-73 RP-161756 0894 1 Corrections to RCLWI procedure 13.5.0
RP-73 RP-161756 0895 1 Corrections to WLAN measurement 13.5.0
RP-73 RP-161756 0896 2 Corrections to WLAN connection status report for LWA 13.5.0
RP-73 RP-161756 0897 2 Corrections to the coexistence of LWA, RCLWI and DC, LWIP, RAN 13.5.0
assisted WLAN interworking
3GPP
Release 17 400 3GPP TS 36.300 V17.2.0 (2022-09)
RP-73 RP-161756 0898 1 Correction on WLAN authentication 13.5.0

RP-73 RP-161755 0900 - Clarification on system information 13.5.0
RP-73 RP-161758 0903 1 Corrections to NB-IoT description in TS 36.300 13.5.0
RP-73 RP-161762 0904 - Introduction of EB/FD-MIMO Terminologies 13.5.0
RP-73 RP-161759 0905 - Keys storage on C-IoT optimizations for non-NB-IoT UE 13.5.0
RP-73 RP-161756 0907 - RCLWI traffic steering granularity 13.5.0
RP-73 RP-161758 0909 1 Corrections to C-IoT optimisations in Stage-2 13.5.0
RP-73 RP-161549 0912 - Correction on CSG support in Dual Connectivity 13.5.0
RP-73 RP-161759 0913 - Correction of UE Radio Capability Information 13.5.0
RP-73 RP-161756 0914 - Correction on WT initiated WT modification procedure 13.5.0
2016-09 RP-73 RP-161745 0910 - Stage 2 CR for eLAA 14.0.0
RP-73 RP-161745 0911 - IDC support in eLAA 14.0.0
RP-73 RP-161746 0915 - Introduction of V2V services based on LTE sidelink 14.0.0
2016-12 RP-74 RP-162314 0918 - Clarification on DRX 14.1.0
RP-74 RP-162318 0920 1 Clarification on CIoT 14.1.0
RP-74 RP-162313 0922 - Corrections to stage 2 description for eMTC and NB-IoT 14.1.0
RP-74 RP-162317 0924 1 Adding missing description of Frame structure type 3 for LAA 14.1.0
RP-74 RP-162321 0926 - Correction on cross carrier scheduling for eLAA 14.1.0
RP-74 RP-162321 0927 - Correction on LBT for eLAA 14.1.0
RP-74 RP-162328 0930 1 Miscellaneous corrections on V2V 14.1.0
RP-74 RP-162312 0932 - eDRX correction on MME sending Paging message to eNB 14.1.0
RP-74 RP-162310 0933 - UL grant in Random Access Response from PCell and PSCell for SCell 14.1.0
RP-74 RP-162316 0935 - Clarifications on LWA and LWIP 14.1.0
RP-74 RP-162324 0936 1 Introduction of SRS switching for LTE 14.1.0
RP-74 RP-162327 0937 1 Stage-2 for LWIP aggregation 14.1.0
RP-74 RP-162314 0939 - Editorial correction for NB-IoT 14.1.0
RP-74 RP-162311 0941 1 Correction for traffic steering granularity for RAN assisted WLAN 14.1.0
interworking
RP-74 RP-162314 0943 - Definition of valid anchor and non-anchor carrier combinations 14.1.0
RP-74 RP-162314 0945 - Corrections to User Plane CIoT optimisations 14.1.0
RP-74 RP-162328 0946 1 Addition of UE geographical information reporting in 36.300 14.1.0
RP-74 RP-162323 0948 2 Receive Only Mode for enTV 14.1.0
RP-74 RP-162314 0951 - Timing reference for NB-IoT UEs in multi-carrier operation 14.1.0
RP-74 RP-162311 0954 - Introduction of solution to solve CSFB setup delay problem 14.1.0
RP-74 RP-162312 0956 - Correction of eDRX Information 14.1.0
2017-03 RP-75 RP-170656 0950 3 A Correction to CP only mode support in NB-IoT 14.2.0
RP-75 RP-170642 0959 1 F Clarification on the use of Explicit Congestion Notification (ECN) 14.2.0
RP-75 RP-170657 0963 - A Correct that in NB-IoT PDCP linked to support of S1-U data transfer 14.2.0
RP-75 RP-170626 0964 - F Correction on HARQ principles for eLAA 14.2.0
RP-75 RP-170626 0965 - F Correction on LBT type for eLAA 14.2.0
RP-75 RP-170643 0966 1 F CR for the usage of transmission sidelink resource pools of the target cell 14.2.0
RP-75 RP-170643 0967 1 F Correction on exceptional pool's resource selection 14.2.0
RP-75 RP-170630 0968 2 B Introduction of RACH-less and make before break 14.2.0
RP-75 RP-170636 0969 3 B Stage 2 CR on FeMTC UE CE mode and maximum PDSCH/PUSCH BW 14.2.0
preference
RP-75 RP-170643 0970 1 F Corrections on V2V description in TS 36.300 14.2.0
RP-75 RP-170637 0971 2 B Introduction of Rel-14 NB-IoT Enhancements 14.2.0
RP-75 RP-170636 0972 2 B Introduction of Rel-14 FeMTC 14.2.0
RP-75 RP-170668 0973 - B Introducing 256QAM in UL 14.2.0
RP-75 RP-170633 0974 1 B Introduction of FeMBMS to 36.300 14.2.0
RP-75 RP-170628 0975 1 B Introduction of Enhanced LTE-WLAN Aggregation (eLWA) 14.2.0
RP-75 RP-170638 0977 4 B Introduction of Voice and Video enhancements for LTE 14.2.0
RP-75 RP-170652 0979 - A Providing SIB1-BR via dedicated RRC signalling 14.2.0
RP-75 RP-170635 0981 - B Introduction of MBMS deployment for V2X 14.2.0
RP-75 RP-170637 0982 - C Handling of NB-IOT UE capabilities 14.2.0
RP-75 RP-170642 0983 - B Reliable DL NAS delivery based on hop-by-hop acknowledgements 14.2.0
RP-75 RP-170628 0984 - B Inter-eNB mobility with LWA active 14.2.0
RP-75 RP-170628 0985 - B Enabling uplink data bearers for LWA 14.2.0
RP-75 RP-170641 0986 - B Introduction of eDECOR in RAN 14.2.0
RP-75 RP-170637 0987 - B Introduction of S1 UE information retrieve procedure 14.2.0
RP-75 RP-170633 0988 1 B PLMN ID Check and Enhanced TV Services 14.2.0
RP-75 RP-170635 0989 - B Introduction of V2X feature in 36.300 14.2.0
RP-75 RP-170550 0990 - B Introducing eLWIP enhancements 14.2.0
2017-06 RP-76 RP-171243 0995 2 A Correction on radio protocol architecture for DC 14.3.0
RP-76 RP-171244 0996 1 F Correction on HARQ principles for eMTC 14.3.0
RP-76 RP-171236 0997 2 F Correction on eLWA 14.3.0
RP-76 RP-171223 0999 3 F Corrections to stage 2 description of FeMTC and eNB-IoT 14.3.0
RP-76 RP-171235 1000 1 F Corrections to stage 2 description for voice and video enhancements for 14.3.0
LTE
RP-76 RP-171224 1006 1 F Corrections to NB-IoT Enhancements 14.3.0
3GPP
Release 17 401 3GPP TS 36.300 V17.2.0 (2022-09)
RP-76 RP-171226 1009 2 F Indication of in proximity of CEN DSRC 14.3.0

RP-76 RP-171223 1010 1 C CE mode configuration/deconfiguration without handover 14.3.0
RP-76 RP-171236 1014 r F Clarification of the end marker solution for eLWA 14.3.0
RP-76 RP-171226 1017 2 F CR to cell reselection for V2X in TS 36.300 14.3.0
RP-76 RP-171243 1023 4 A LAA/WiFi sharing indication 14.3.0
RP-76 RP-171245 1024 1 A Clarification of UE-AMBR support for NB-IoT 14.3.0
RP-76 RP-171245 1027 - A Miscellaneous corrections for NB-IoT 14.3.0
RP-76 RP-171224 1028 2 F Resources selection for PRACH triggered by a PDCCH order in eNB- 14.3.0
IoT(Option2)
RP-76 RP-171227 1029 1 F Editorial Corrections to Support of Multiple SPS Configurations 14.3.0
RP-76 RP-171246 1034 1 B EUTRAN sharing enhancement 14.3.0
RP-76 RP-171224 1038 - B Introduction of RRC connection re-establishment for NB-IoT control plane 14.3.0
RP-76 RP-171225 1040 1 F Correction on UE-AMBR for NB-IoT UE using CP solution 14.3.0
RP-76 RP-171224 1041 - B Support of RLF for CP CIoT Optimisation 14.3.0
2017-09 RP-77 RP-171915 1031 2 C Support of RLC UM for LWA bearer 14.4.0
RP-77 RP-171913 1032 4 F Correction of RACH-less handover 14.4.0
RP-77 RP-171915 1042 - F Correction on UE states for MBMS reception 14.4.0
RP-77 RP-171915 1053 1 F RAN-recommended bit rate restriction 14.4.0
RP-77 RP-171910 1057 1 F Correction of MBMS-dedicated cell definition 14.4.0
RP-77 RP-171913 1058 2 C Introduction of Release Assistance Indication 14.4.0
RP-77 RP-171915 1059 - F Remove the description of Inter RAT Redirection value for MMTEL 14.4.0
RP-77 RP-171919 1061 - A Clarification on SCell status during PUCCH SCell change/removal 14.4.0
2017-12 RP-78 RP-172615 1048 7 B Introduction of the overheating indication 14.5.0
RP-78 RP-172624 1055 4 A Corrections on paging monitoring in RRC_CONNECTED in Rel-13 eMTC 14.5.0
RP-78 RP-172617 1062 3 F Corrections to V2X in TS 36.300 14.5.0
RP-78 RP-172616 1066 1 F Correction on TS 36.300 for support of larger maximum PDSCH/PUSCH 14.5.0
channel bandwidth for feMTC
RP-78 RP-172617 1083 1 F Clarification to Mapping Between Service Types and V2X Frequencies 14.5.0
RP-78 RP-172615 1085 - F Protection of Redirection to GERAN 14.5.0
2017-12 RP-78 RP-172614 1086 1 B Baseline CR for Rel.15 NR (RAN3 part) 15.0.0
2018-03 RP-79 RP-180444 1088 - A CR on CBR measurement 15.1.0
RP-79 RP-180444 1089 3 A Miscellaneous correction to V2X in TS 36.300 15.1.0
RP-79 RP-180445 1094 1 A Missing description of RRC Connection Re-establishment for the Control 15.1.0
plane
RP-79 RP-180441 1101 1 A Correction on the SI-RNTI for MPDCCH 15.1.0
RP-79 RP-180440 1104 - F Clarification for the use of en-gNB in LTE Stage-2 15.1.0
RP-79 RP-180441 1107 1 A Measurement Requirements for LAA/WiFi Hardware Sharing Problem 15.1.0
RP-79 RP-180443 1113 - A Reference Signals for MBSFN with 1.25kHz and 7.5khz sub-carrier 15.1.0
spacing
RP-79 RP-180447 1116 - F RoHC support for Mission Critical services over MBMS 15.1.0
RP-79 RP-180440 1117 - F Clarification on HRL for EN-DC 15.1.0
RP-79 RP-180440 1118 - F Stage 2 alignment for NSA Energy Savings 15.1.0
RP-79 RP-180442 1121 - A Paging failure in CE Capable UEs 15.1.0
RP-79 RP-180440 1122 - B E-UTRA - NR Cell Resource Coordination 15.1.0
2018-06 RP-80 RP-181216 0998 6 B Introduction of New Radio Access Technology in TS 36.300 15.2.0
RP-80 RP-181222 1073 1 B Introduction of QoE Measurement Collection for LTE 15.2.0
RP-80 RP-181221 1076 4 B Running 36.300 CR to introduce assistance information for local cache 15.2.0
RP-80 RP-181218 1084 2 B Introduction of shortened TTI and processing time for LTE 15.2.0
RP-80 RP-181226 1090 3 B Introduction of DEFLATE based UDC Solution 15.2.0
RP-80 RP-181171 1102 5 A Introduction of support for MAC PDU containing UE contention resolution 15.2.0
identity MAC control element without RRC response message in NB-IoT
RP-80 RP-181234 1124 2 A Correction to V2X descriptions in TS 36.300 15.2.0
RP-80 RP-181248 1126 3 B Introduction of eV2X in TS 36.300 15.2.0
RP-80 RP-181252 1127 3 B Introduction of further NB-IoT enhancements other than EDT in TS 36.300 15.2.0
RP-80 RP-181224 1128 3 B Introduction of EDT for eMTC and NB-IoT enhancements in TS 36.300 15.2.0
RP-80 RP-181224 1134 2 B Introduction of enhancements for eMTC excluding EDT 15.2.0
RP-80 RP-181214 1135 - F Adding en-gNB definition to LTE Stage-2 15.2.0
RP-80 RP-181250 1137 1 B Stage-2 description of euCA 15.2.0
RP-80 RP-181228 1138 - B Enabling MBMS Bearer Event Notification 15.2.0
RP-80 RP-181253 1139 4 B Introduction on Rel-15 Aerial UE functionality 15.2.0
RP-80 RP-181233 1141 1 F Corrections on Delivering Data with Complete Message 15.2.0
RP-80 RP-181233 1144 - A Introduction of UL skipping for latency reduction 15.2.0
RP-80 RP-181216 1145 2 B Introduce reportCGI towards NR neighbour cell 15.2.0
RP-80 RP-181235 1147 - A Introduction of relaxed monitoring for NB-IoT and MTC 15.2.0
RP-80 RP-181216 1148 2 F Support for inter-RAT handover from EN-DC 15.2.0
RP-80 RP-181234 1150 2 A Corrections to V-RNTI Handling 15.2.0
RP-80 RP-181223 1151 1 B Introduction of E-UTRA connected to 5GCN 15.2.0
RP-80 RP-181215 1152 - F X2 partial reset for EN-DC 15.2.0
RP-80 RP-181215 1153 - F List of served cells for X2 connection between eNB and en-gNB 15.2.0
RP-80 RP-181215 1154 - F Addition of 'No EN-DC' attribute for the Neighbour Relation Table 15.2.0
3GPP
Release 17 402 3GPP TS 36.300 V17.2.0 (2022-09)
RP-80 RP-181247 1156 1 B Introduction of Ultra Reliable Low Latency Communication for LTE 15.2.0
RP-80 RP-181232 1159 - A Clarification on Connection Establishment Indication procedure scenarios 15.2.0
RP-80 RP-181228 1160 - B Triggering UE capability info retrieval using DL NAS TRANSPORT (Stage 15.2.0
2)
RP-80 RP-181255 1162 - A UE Radio Access Capability Size Reduction 15.2.0
RP-80 RP-181216 1163 3 F ANR stage 2 clean up 15.2.0
RP-80 RP-181228 1164 - B Retrieve UE Context at UE Re-establishment 15.2.0
RP-80 RP-181249 1166 - B Introduce feLAA in TS 36.300 15.2.0
2018-09 RP-81 RP-181960 1140 1 B Introduction of QoE Measurement Collection for MTSI services 15.3.0
RP-81 RP-181939 1155 2 C Clarification on LTE Overheating mechanism in EN-DC 15.3.0
RP-81 RP-181949 1170 - D Independent cell (de)activation and duplication (de)activation 15.3.0
RP-81 RP-181948 1171 1 F CR on RAN1 synchronization agreement in 36.300 15.3.0
RP-81 RP-181945 1172 - F Corrections to carrier definition for TDD in 36.300 15.3.0
RP-81 RP-181944 1175 - F Minor corrections for TS 36300 for eMTC excluding EDT 15.3.0
RP-81 RP-181946 1184 - F Miscellaneous correction to FeLAA in TS 36.300 15.3.0
RP-81 RP-181950 1185 - F Stage 2 Changes based on CN type indication for Redirection from ng- 15.3.0
eNB to E-UTRA
RP-81 RP-181942 1186 1 F Clarification on SCTP association establishment – for 36.300 15.3.0
RP-81 RP-181963 1188 1 A Correction on Authentication Failure handling in case of eNB CP 15.3.0
Relocation
RP-81 RP-181960 1189 1 F Data forwarding for Retrieve UE Context in case of RRC connection re- 15.3.0
establishment
RP-81 RP-181942 1190 - F Corrections on resource coordination in stage-2 15.3.0
RP-81 RP-181941 1192 - F [SON/ANR] Stage 2 updates 15.3.0
2018-12 RP-82 RP-182675 1182 6 F Corrections on handover for E-UTRA connected to 5GC 15.4.0
RP-82 RP-182678 1193 F Correction for duplication based on Rel-14 TX profile 15.4.0
RP-82 RP-182675 1195 F Clarification of features not supported in NB-IoT 15.4.0
RP-82 RP-182671 1197 F EDT when resuming in a new eNB 15.4.0
RP-82 RP-182678 1199 F Correction on V2X sidelink communication in TS 36.300 15.4.0
RP-82 RP-182675 1200 F Inter-RAT Handover from GERAN or UTRAN to E-UTRA configured with 15.4.0
EN-DC (36.300)
RP-82 RP-182671 1201 F Clarification on when UL data transmission in EDT is not considered 15.4.0
successful
RP-82 RP-182649 1202 F Correction for E-UTRA connected to 5GC Stage-2 15.4.0
RP-82 RP-182681 1203 F Corrections on EDT 15.4.0
RP-82 RP-182660 1206 F Stage 2 CR on Measurement gap configuration scenarios 15.4.0
RP-82 RP-182672 1207 B MBMS reception in Receive Only Mode 15.4.0
RP-82 RP-182676 1209 F Removing NG-RAN specific statements 15.4.0
RP-82 RP-182665 1210 F Correction on ANR related information 15.4.0
RP-82 RP-182665 1211 F 36.300 CR on Correction of Physical Layer Resource to Cell Resource 15.4.0
RP-82 RP-182847 1212 2 B Addition of an SPID value for vehicle UE subscriber 15.4.0
2019-03 RP-83 RP-190553 1213 1 F Corrections to LTE Stage-2 15.5.0
RP-83 RP-190552 1216 1 F Cross-carrier scheduling configuration with shortened processing time 15.5.0
RP-83 RP-190551 1219 2 F Correction to EDT 15.5.0
RP-83 RP-190549 1224 1 F Correction for non-anchor carrier configuration for (CP) connection re- 15.5.0
establishment
RP-83 RP-190548 1226 - A Removal of 62MHz frequency seperation restriction for LTE LAA DL 15.5.0
operations
RP-83 RP-190548 1227 - F Correction on eNB CP Relocation 15.5.0
RP-83 RP-190544 1228 - F Introducing a target E-UTRA cell's NCR towards an NR cell for performing 15.5.0
EN-DC
RP-83 RP-190561 1229 - F Introduction of TNL Address discovery for EN-DC 15.5.0
RP-83 RP-190553 1230 - F Adding the transfer of the PSCell information for LI purposes 15.5.0
2019-06 RP-84 RP-191387 1233 - F Miscellaneous corrections to LTE Stage-2 15.6.0
RP-84 RP-191374 1234 - F No support of IRAT HO from NR to EN-DC 15.6.0
RP-84 RP-191386 1235 1 F CR on 36.300 for SRB cell mapping for CA duplication 15.6.0
RP-84 RP-191387 1236 1 F SN Status Transfer applicability for Re-establishment 15.6.0
RP-84 RP-191383 1238 - A Multiple Cell ID broadcast for E-UTRAN sharing 15.6.0
RP-84 RP-191428 1239 2 F RAN sharing with multiple Cell ID broadcast 15.6.0
2019-09 RP-85 RP-192197 1241 1 F Add new release 15 QCIs into CAPC mapping table 15.7.0
RP-85 RP-192196 1243 1 F Correction on EPS fallback for LTE-5GC 15.7.0
RP-85 RP-192195 1245 1 A Introduction of DL channel quality reporting 15.7.0
RP-85 RP-192190 1249 - F Independent migration to IPv6 on S1-U for en-gNB's 15.7.0
RP-85 RP-192194 1250 1 F Location Reporting: effective PSCell ID reporting 15.7.0
2019-12 RP-86 RP-192941 1252 3 F Correction on inter-frequency neighbour cell measurements 15.8.0
RP-86 RP-192946 1256 - B Introduction of Additional RRM Policy Index (ARPI) 16.0.0
RP-86 RP-192946 1257 - F TS36.300 Removal of Requirement for Exchanging Complete Cell List 16.0.0
over X2
2020-03 RP-87 RP-200341 1240 5 F Missing QCI to CAPC mapping 16.1.0
RP-87 RP-200351 1258 1 B Introduction of RACS and DL RRC segmentation 16.1.0
3GPP
Release 17 403 3GPP TS 36.300 V17.2.0 (2022-09)
RP-87 RP-200361 1259 1 B Introduction of additional enhancements for NB-IoT in TS 36.300 16.1.0
RP-87 RP-200336 1263 1 A Handling of UE Radio Capability for Paging in NB-IoT and eMTC 16.1.0
RP-87 RP-200360 1267 1 B Introduction of Rel-16 eMTC additional enhancements 16.1.0
RP-87 RP-200348 1268 2 B CR for 36.300 for CA&DC enh 16.1.0
RP-87 RP-200364 1270 2 B Introduction of even further mobility enhancement in E-UTRAN 16.1.0
RP-87 RP-200346 1271 - B Introduction of 5G V2X with NR Sidelink 16.1.0
RP-87 RP-200334 1273 - A Propagation of Roaming and Access Restriction information in E-UTRAN 16.1.0
in non-homogenous eNB deployments
RP-87 RP-200352 1276 - B Introduction of NR Industrial IoT features 16.1.0
2020-07 RP-88 RP-201193 1277 3 F Miscellaneous corrections to TS 36.300 for Rel-16 NB-IoT 16.2.0
RP-88 RP-201181 1280 1 F Stage-2 updates for IIOT (36.300) 16.2.0
RP-88 RP-201192 1281 2 F Miscellaneous corrections to Rel-16 eMTC enhancements 16.2.0
RP-88 RP-201195 1284 1 F Corrections to even further mobility enhancement in E-UTRAN 16.2.0
RP-88 RP-201190 1286 1 F CR to 36.300 on support of inter-RAT HO from SA to EN-DC 16.2.0
RP-88 RP-201176 1287 1 F Correction for NR sidelink communication 16.2.0
RP-88 RP-201165 1289 - A Correction of connected en-gNB Identifier 16.2.0
RP-88 RP-201165 1291 - A Correction for Network Sharing 16.2.0
RP-88 RP-201168 1293 - A CR 36.300 for support of WUS 16.2.0
RP-88 RP-201180 1294 - B Signalling UE capability Identity 16.2.0
RP-88 RP-201184 1295 - B Addition of SON features 16.2.0
RP-88 RP-201195 1296 1 B Baseline CR for introducing Rel-16 LTE further mobility enhancements 16.2.0
2020-09 RP-89 RP-201936 1265 3 F System support for Wake Up Signal 16.3.0
RP-89 RP-201928 1297 - F Addition of PUR RNTI in E-UTRA related UE identities 16.3.0
RP-89 RP-201928 1300 1 F Miscellaneous corrections to NB-IoT and eMTC Rel-16 enhancements 16.3.0
RP-89 RP-201933 1302 - F DAPS handover corrections 16.3.0
RP-89 RP-201922 1306 1 F Misc corrections for Rel-16 DCCA 16.3.0
RP-89 RP-201933 1309 1 F Correction on TS36.300 for CHO 16.3.0
RP-89 RP-201938 1311 3 F CR to 36.300 on support of NeedForGap capability 16.3.0
RP-89 RP-201931 1314 1 F Introducing UE Radio Capability Mapping procedure for EN-DC 16.3.0
2020-12 RP-90 RP-202788 1299 2 A Clarification to completion of UP-EDT procedure when using RLC AM 16.4.0
RP-90 RP-202782 1320 1 F Clarification on no support of CA or DC with DAPS 16.4.0
RP-90 RP-202780 1322 1 F CP length and reference signal for MBSFN with sub-carrier spacing of 16.4.0
0.375 kHz and 2.5 kHz
RP-90 RP-202788 1324 1 F Miscellaneous Stage-2 corrections 16.4.0
RP-90 RP-202782 1330 - F MobEnh Stage-2 corrections 16.4.0
RP-90 RP-202782 1331 - F Correction for LTE CHO and Full Configuration 16.4.0
RP-90 RP-202779 1332 - F Correction on immediate suspension 16.4.0
2021-03 RP-91 RP-210698 1335 - F Non-support of CHO/CPC with LTE/5GC 16.5.0
2021-06 RP-92 RP-211473 1336 1 F Removing ambiguous legacy and normal terms from handover 16.6.0
descriptions
RP-92 RP-211470 1338 1 F Clarification on LTE DAPS and sidelink on 36.300 16.6.0
RP-92 RP-211479 1339 1 F Clarification on RLF detection of source PCell 16.6.0
RP-92 RP-211479 1341 1 F Miscellaneous corrections to DAPS handover 16.6.0
RP-92 RP-211344 1346 1 F Correction on LTE aerial feature 16.6.0
RP-92 RP-211479 1347 - F 36.300 correction for CHO early data forwarding in MeNB to eNB Change 16.6.0
scenario
2021-12 RP-94 RP-213342 1350 1 F Miscellaneous corrections 16.7.0
2022-03 RP-95 RP-220472 1358 - A Clarification of RSRP measurement triggering for number of cells for UAVs 16.8.0
2022-03 RP-95 RP-220506 1333 3 D Inclusive Language Review for TS 36.300 17.0.0
RP-95 RP-220837 1352 1 B Introduction of MINT [MINT] 17.0.0
RP-95 RP-220495 1353 1 B Introducing support of UP IP for EPC connected architectures using NR 17.0.0
PDCP
RP-95 RP-220507 1354 1 B Introduction of Rel-17 enhancements for NB-IoT and eMTC 17.0.0
RP-95 RP-220488 1355 - B Running CR to 36300 for Multi-USIM devices support 17.0.0
RP-95 RP-220509 1356 2 B Introduction of IoT NTN Stage 2 17.0.0
RP-95 RP-220510 1359 1 C UE Security Capabilities signaling in E-UTRAN [UE_Sec_Caps] 17.0.0
RP-95 RP-220508 1360 - B Introduction of new bands and bandwidth allocation for LTE-based 5G 17.0.0
terrestrial broadcast
RP-95 RP-220839 1362 - B BLCR to 36.300_Addition of SON features enhancement 17.0.0
2022-06 RP-96 RP-221738 1363 2 B Introduction of gNB ID length reporting in the NR CGI report 17.1.0
[gNB_ID_Length]
RP-96 RP-221737 1364 2 F IoT NTN Stage 2 Corrections 17.1.0
RP-96 RP-221733 1366 1 F RACH optimisation in EN-DC secondary cell 17.1.0
RP-96 RP-221733 1368 1 F Correction on R17 SON MDT for TS36.300 17.1.0
2022-09 RP-97 RP-222522 1369 1 F Correction to IoT NTN stage 2 description 17.2.0
NOTE: The CR number, 0616 in RP-140876 was renumbered into 0616a in CR database since the CR number
was double allocated in RP-140351 at RAN #63 and in RP-140876 at RAN#64.
3GPP

3GPP TS 36.300: Technical Specification

Uploaded by

Copyright:

Available Formats

3GPP TS 36.300: Technical Specification

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3GPP TS 36.300: Technical Specification

Uploaded by

Copyright:

Available Formats

3GPP TS 36.300 V17.2.

3GPP support office address

No part may be reproduced except as authorized by written permission.

5.5a Multi-carrier operation for NB-IoT...................................................................................................................

10.1.2.8.9 Addition of a hybrid HeNB as the SeNB.......................................................................................149

10.3.2.3.1 Mobility from E-UTRAN to cdma2000 1xRTT.............................................................................172

14.4 AS Key Change in RRC_CONNECTED........................................................................................................

15.9.1 M3 Control Plane.......................................................................................................................................214

19.2.1.4.1 Intra-LTE Handover.......................................................................................................................227

19.2.2.11.2 Location Report procedure.............................................................................................................256

20.2.2.9 Reset procedure....................................................................................................................................280

22.4.1.2.3 Load reporting for EN-DC scenario...............................................................................................303

22A.3.1.2 Reconfiguration to Remove WLAN Resources from Data Bearer......................................................328

24.2.1 User Plane..................................................................................................................................................368

Annex A (informative): NAS Overview....................................................................................................372

Annex K (informative): Time domain ICIC.............................................................................................380

Annex L (informative): Void......................................................................................................................382

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.

- For a specific reference, subsequent revisions do not apply.

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[8] IETF RFC 4960 (09/2007): "Stream Control Transmission Protocol".

[22] 3GPP TS 33.401: "3GPP System Architecture Evolution: Security Architecture".

[26] 3GPP TS 23.003: "Numbering, addressing and identification".

[27] 3GPP TR 25.922: "Radio Resource Management Strategies".

[34] 3GPP TS 22.268: "Public Warning System (PWS) Requirements".

[36] 3GPP TS 25.446: "MBMS synchronisation protocol (SYNC)".

[64] 3GPP TR 36.889: "Study on Licensed-Assisted Access to Unlicensed Spectrum".

[66] 3GPP TS 36.360: "LTE-WLAN Aggregation Adaptation Protocol (LWAAP) specification".

[80] 3GPP TS 37.324: "NR; Service Data Protocol (SDAP) specification".

[83] 3GPP TS 23.502: "Procedures for the 5G System; Stage 2".

[84] 3GPP TS 29.002: "Mobile Application Part (MAP) specification".

[85] 3GPP TS 25.412: "UTRAN Iu interface signalling transport".

[86] 3GPP TS 38.423: "NG-RAN; Xn Application Protocol (XnAP)".

3 Definitions, symbols and abbreviations

Aerial UE communication: functionality enabling Aerial UE function as defined in 23.17.

Carrier frequency: center frequency of the cell.

DCN-ID: DCN identity identifies a specific dedicated core network (DCN).

en-gNB: as defined in TS 37.340 [76].

Frequency layer: set of cells with the same carrier frequency.

FeMBMS: further enhanced multimedia broadcast multicast service.

Handover: procedure that changes the serving cell of a UE in RRC_CONNECTED.

Local Home Network: as defined in TS 23.401 [17].

Mapped Cell ID: in NTN, it corresponds to a fixed geographical area.

MBMS-dedicated cell: cell dedicated to MBMS transmission.

MBMS/Unicast-mixed cell: cell supporting both unicast and MBMS transmissions.

NB-IoT UE: a UE that uses NB-IoT.

NR: NR radio access

PUCCH group: either primary PUCCH group or a secondary PUCCH group.

PUCCH SCell: a Secondary Cell configured with PUCCH.

Receive Only Mode: See TS 23.246 [48].

Short TTI: TTI length based on a slot or a subslot.

1xCSFB Circuit Switched Fallback to 1xRTT

ARQ Automatic Repeat Request

EPS Evolved Packet System

MME Mobility Management Entity

PPPR ProSe Per-Packet Reliability