24 Support for 5GC

36.3003GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)Overall descriptionRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

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

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 security is activated.

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 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].

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.

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.

Annex A (informative):
NAS Overview

This clause provides for information an overview on services and functions provided by the NAS control protocol.