5.3.1 Introduction

36.3313GPPEvolved Universal Terrestrial Radio Access (E-UTRA)Protocol specificationRadio Resource Control (RRC)Release 15TS

5.3.1.1 RRC connection control

RRC connection establishment involves the establishment of SRB1. Except for EDT, E-UTRAN completes RRC connection establishment prior to completing the establishment of the S1 connection, i.e. prior to receiving the UE context information from the EPC. Consequently, AS security is not activated during the initial phase of the RRC connection. During this initial phase of the RRC connection, the E-UTRAN may configure the UE to perform measurement reporting, but the UE only sends the corresponding measurement reports after successful security activation. However, the UE only accepts a handover message when security has been activated.

NOTE 1: In case the serving frequency broadcasts multiple overlapping bands, E-UTRAN can only configure measurements after having obtained the UE capabilities, as the measurement configuration needs to be set according to the band selected by the UE.

Upon receiving the UE context from the EPC, E-UTRAN activates security (both ciphering and integrity protection) using the initial security activation procedure. The RRC messages to activate security (command and successful response) are integrity protected, while ciphering is started only after completion of the procedure. That is, the response to the message used to activate security is not ciphered, while the subsequent messages (e.g. used to establish SRB2 and DRBs) are both integrity protected and ciphered.

After having initiated the initial security activation procedure, E-UTRAN initiates the establishment of SRB2 and DRBs, i.e. E-UTRAN may do this prior to receiving the confirmation of the initial security activation from the UE. In any case, E-UTRAN will apply both ciphering and integrity protection for the RRC connection reconfiguration messages used to establish SRB2 and DRBs. E-UTRAN should release the RRC connection if the initial security activation and/ or the radio bearer establishment fails (i.e. security activation and DRB establishment are triggered by a joint S1-procedure, which does not support partial success).

For SRB2 and DRBs, security is always activated from the start, i.e. the E-UTRAN does not establish these bearers prior to activating security.

For some radio configuration fields, a critical extension has been defined. A switch from the original version of the field to the critically extended version is allowed using any connection reconfiguration. The UE reverts to the original version of some critically extended fields upon handover and re-establishment as specified elsewhere in this specification. Otherwise, switching a field from the critically extended version to the original version is only possible using the handover or re-establishment procedure with the full configuration option. This also applies for fields that are critically extended within a release (i.e. original and extended version defined in same release).

After having initiated the initial security activation procedure, E-UTRAN may configure a UE that supports CA, with one or more SCells in addition to the PCell that was initially configured during connection establishment. The PCell is used to provide the security inputs and upper layer system information (i.e. the NAS mobility information e.g. TAI). SCells are used to provide additional downlink and optionally uplink radio resources. When not configured with any kind of DC, all SCells the UE is configured with, if any, are part of the MCG.

When configured with DC, some of the SCells are part of a SCG. In this case, user data carried by a DRB may either be transferred via MCG (i.e. MCG-DRB), via SCG (SCG-DRB) or via both MCG and SCG in DL while E-UTRAN configures the CG used in UL (split DRB). An RRC connection reconfiguration message may be used to change the DRB type from MCG-DRB to SCG-DRB or to split DRB, as well as from SCG-DRB or split DRB to MCG-DRB.

DC employs SCG change, which is a synchronous SCG reconfiguration procedure (i.e. involving RA to the PSCell) including reset/ re-establishment of layer 2 and, if SCG DRBs are configured, refresh of security. The procedure is used in a number of different scenarios e.g. SCG establishment, PSCell change, Key refresh, change of DRB type. The UE performs the SCG change related actions upon receiving an RRCConnectionReconfiguration message including mobilityControlInfoSCG, see 5.3.10.10.

In case of MR-DC, the cells of one CG use another RAT, namely NR. The configuration of an NR CG is specified in TS 38.331 [82]. When configured with MR-DC, user data carried by a DRB may either be transferred via MCG, via NR SCG or via both MCG and NR SCG. Also RRC signalling carried by a SRB may either be transferred via MCG or via both MCG and NR SCG. When DRBs and SRBs are configured with transmission via both MCG and SCG, duplication may be used in both DL and UL.

Change to NR PDCP or vice versa, that in case of EN-DC may be done for both SRBs and DRBs, can be performed using an RRCConnectionReconfiguration message including the mobilityControlInfo (handover) by release and addition of the concerned RB (for DRBs) or of the concerned PDCP entity (for SRBs). The same RRCConnectionReconfiguration message may be used to make changes regarding the CG(s) used for transmission. For SRB1, change from E-UTRA PDCP to NR PDCP type may, before initial security activation, also be performed using an RRCConnectionReconfiguration message not including the mobilityControlInfo.

In case of (NG)EN-DC, there are three types of NR SCG reconfigurations:

– Reconfiguration with sync and key change i.e. a procedure involving RA to the PSCell, including NR MAC reset, re-establishment of NR RLC and NR PDCP and refresh of NR SCG security; and

– Reconfiguration with sync but without key change i.e. a procedure involving RA to the PSCell, including NR MAC reset and NR RLC re-establishment and PDCP data recovery (for AM DRB); and

– Regular NR SCG reconfiguration neither involving refresh of NR SCG security, nor RA to the PSCell, NR MAC reset or NR RLC re-establishment;

The network is only required to use the NR SCG reconfiguration with sync and key change in case the NR SCG security key changes (i.e. handover, change of SNs, S-KgNB refresh). Further details are specified in NR RRC TS 38.331 [82].

NOTE 2: In case of MR-DC, E-UTRA RRC configuration parameters should only affect E-UTRA operation. E.g., s-Measure only affects measurements configured by parameters defined in this specification. Should an E-UTRA RRC configuration change require a change of NR RRC configuration, the network should indicate such NR change by NR RRC signalling. E.g. a specific indication is used to trigger RLC re-establishment upon reconfigurations changing the CG(s) used for transmission (in DL or UL) that otherwise would only involve NR RRC signalling.

In this release of the specification, change between DC and MR-DC as well as change between DC and E-UTRA configured with SN terminated DRB without SCG are not supported (i.e. neither the direct reconfiguration nor specific measurement events). Likewise, the direct transition between (NG)EN-DC and NR DC or NE-DC is not supported in this release of the specification.

The release of the RRC connection normally is initiated by E-UTRAN. The procedure may be used to re-direct the UE to an E-UTRA frequency or an inter-RAT carrier frequency. Only in exceptional cases, as specified within this specification, TS 36.300 [9], TS 36.304 [4] or TS 24.301 [35], may the UE abort the RRC connection, i.e. move to RRC_IDLE without notifying E-UTRAN.

The suspension of the RRC connection is initiated by E-UTRAN. When the RRC connection is suspended, the UE stores the UE AS context and the resumeIdentity, and transitions to RRC_IDLE state. The RRC message to suspend the RRC connection is integrity protected and ciphered. Suspension can only be performed when at least 1 DRB is successfully established.

The resumption of a suspended RRC connection is initiated by upper layers when the UE has a stored UE AS context, RRC connection resume is permitted by E-UTRAN and the UE needs to transit from RRC_IDLE state to RRC_CONNECTED state. When the RRC connection is resumed, RRC configures the UE according to the RRC connection resume procedure based on the stored UE AS context and any RRC configuration received from E-UTRAN. The RRC connection resume procedure re-activates security and re-establishes SRB(s) and DRB(s). The request to resume the RRC connection includes the resumeIdentity. The request is not ciphered, but protected with a message authentication code.

In response to a request to resume the RRC connection, E-UTRAN may resume the suspended RRC connection, reject the request to resume and instruct the UE to either keep or discard the stored context, or setup a new RRC connection.

In case of CP-EDT, the data are appended in the RRCEarlyDataRequest and RRCEarlyDataComplete messages, if available, and sent over SRB0. In case of UP-EDT, security is re-activated prior to transmission of RRC message using the nextHopChainingCount provided in the RRCConnectionRelease message with suspend indication during the preceding suspend procedure and the radio bearers are re-established. The uplink data are transmitted ciphered on DTCH multiplexed with the RRCConnectionResumeRequest message on CCCH. In the downlink, the data, if available, are transmitted on DTCH multiplexed with the RRCConnectionRelease message on DCCH. In response to a request for EDT, E-UTRAN may also choose to establish or resume the RRC connection.

A UE in RRC_CONNECTED enters RRC_INACTIVE when the network indicates RRC connection suspension in RRCConnectionRelease message. When entering RRC_INACTIVE, the UE stores the UE Inactive AS context and any RRC configuration received from the network.

The resumption of an RRC connection from RRC_INACTIVE is initiated by upper layers when the UE needs to transit from RRC_INACTIVE state to RRC_CONNECTED state or by RRC layer for, e.g. RNAU or reception of RAN paging. When the RRC connection is resumed, network configures the UE according to the RRC connection resume procedure based on the stored UE Inactive AS context and any RRC configuration received from the network. The RRC connection resume procedure re-activates security and re-establishes SRB(s) and DRB(s).

In response to a request to resume the RRC connection from RRC_INACTIVE, the network may resume the suspended RRC connection and UE enters to RRC_CONNECTED, or reject the request to resume using RRC message without security protection and send UE to RRC_INACTIVE with wait time, or directly re-suspend the RRC connection and send UE to RRC_INACTIVE, or directly release the RRC connection and send UE to RRC_IDLE, or instruct the UE to initiate NAS level recovery.

5.3.1.2 Security

AS security comprises of the integrity protection of RRC signalling (SRBs) as well as the ciphering of RRC signalling (SRBs) and user data (DRBs).

RRC handles the configuration of the security parameters which are part of the AS configuration: the integrity protection algorithm, the ciphering algorithm and two parameters, namely the keyChangeIndicator and the nextHopChainingCount, which are used by the UE to determine the AS security keys upon handover, connection re-establishment, connection resume and/ or UP-EDT.

The integrity protection algorithm is common for signalling radio bearers SRB1, SRB2 and SRB4. When configured with MCG only, the ciphering algorithm is common for all radio bearers (i.e. SRB1, SRB2, SRB4 and DRBs). Neither integrity protection nor ciphering applies for SRB0.

RRC integrity and ciphering are always activated together, i.e. in one message/ procedure. RRC integrity and ciphering are never de-activated. However, it is possible to switch to a ‘NULL’ ciphering algorithm (eea0).

The ‘NULL’ integrity protection algorithm (eia0) is used only for the UE in limited service mode, as specified in TS 33.401 [32]. In case the ‘NULL’ integrity protection algorithm is used, ‘NULL’ ciphering algorithm is also used.

NOTE 1: Lower layers discard RRC messages for which the integrity check has failed and indicate the integrity verification check failure to RRC.

The AS applies three different security keys: one for the integrity protection of RRC signalling (KRRCint), one for the ciphering of RRC signalling (KRRCenc) and one for the ciphering of user data (KUPenc). All three AS keys are derived from the KeNB key. The KeNB is based on the KASME key for E-UTRA/EPC, or KAMF for E-UTRA/5GC, which is handled by upper layers.

Upon connection establishment new AS keys are derived. No AS-parameters are exchanged to serve as inputs for the derivation of the new AS keys at connection establishment.

The integrity and ciphering of the RRC message used to perform handover is based on the security configuration used prior to the handover and is performed by the source eNB.

The integrity and ciphering algorithms can only be changed upon handover. The four AS keys (KeNB, KRRCint, KRRCenc and KUPenc) change upon every handover, connection re-establishment, connection resume and UP-EDT. The keyChangeIndicator is used upon handover and indicates whether the UE should use the keys associated with the KASME key for E-UTRA/EPC, or KAMF for E-UTRA/5GC, taken into use with the latest successful NAS SMC procedure. The nextHopChainingCount parameter is used upon handover, connection re-establishment, connection resume and UP-EDT by the UE when deriving the new KeNB that is used to generate KRRCint, KRRCenc and KUPenc (see TS 33.401 [32]). An intra cell handover procedure may be used to change the keys in RRC_CONNECTED.

For each radio bearer an independent counter (COUNT, as specified in TS 36.323 [8] for E-UTRA/EPC, and TS 38.323 [83] for E-UTRA/5GC) is maintained for each direction. For each DRB, the COUNT is used as input for ciphering. For each SRB, the COUNT is used as input for both ciphering and integrity protection. It is not allowed to use the same COUNT value more than once for a given security key. At connection resume the COUNT is reset. As specified in TS 33.401 clause 7.2.9.1 [32], the eNB is responsible for avoiding reuse of the COUNT with the same RB identity and with the same KeNB, e.g. due to the transfer of large volumes of data, release and establishment of new RBs, and multiple termination point changes for RLC-UM bearers, multiple termination point changes for RLC-AM bearer with SN terminated PDCP re-establishment (COUNT reset) due to SN only full configuration whilst the key stream inputs (i.e. bearer ID, security key) at MN have not been updated. In order to avoid such re-use, the eNB may e.g. use different RB identities for successive RB establishments, trigger an intra cell handover or by triggering a transition from RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE and then back to RRC_CONNECTED.

In order to limit the signalling overhead, individual messages/ packets include a short sequence number (PDCP SN, as specified in TS 36.323 [8] for E-UTRA/EPC, and TS 38.323 [83] for E-UTRA/5GC). In addition, an overflow counter mechanism is used: the hyper frame number (TX_HFN and RX_HFN, as specified in TS 36.323 [8] for E-UTRA/EPC, and HFN as specified in TS 38.323 [83] for E-UTRA/5GC). The HFN needs to be synchronized between the UE and the eNB.

For each SRB, the value provided by RRC to lower layers to derive the 5-bit BEARER parameter used as input for ciphering and for integrity protection is the value of the corresponding srb-Identity with the MSBs padded with zeroes.

With E-UTRA/5GC for a UE not capable of NGEN-DC, the same ciphering algorithm signalled at SMC or handover is used for all radio bearers. Likewise, the same integrity algorithm signalled at SMC or handover is used for all SRBs.

In case of DC, a separate KeNB is used for SCG-DRBs (S-KeNB). This key is derived from the key used for the MCG (KeNB) and an SCG counter that is used to ensure freshness. To refresh the S-KeNB e.g. when the COUNT will wrap around, E-UTRAN employs an SCG change, i.e. an RRCConnectionReconfiguration message including mobilityControlInfoSCG. When performing handover, while at least one SCG-DRB remains configured, both KeNB and S-KeNB are refreshed. In such case E-UTRAN performs handover with SCG change i.e. an RRCConnectionReconfiguration message including both mobilityControlInfo and mobilityControlInfoSCG. The ciphering algorithm is common for all radio bearers within a CG but may be different between MCG and SCG. The ciphering algorithm for SCG DRBs can only be changed upon SCG change.

In case of (NG)EN-DC or of SN terminated RB without SCG, the network indicates whether the UE shall use either KeNB or S-KgNB for a particular DRB. In case of NE-DC, the network indicates whether the UE shall use either KgNB or S-KeNB for a particular DRB. S-KgNB/S-KeNB is derived from KeNB/KgNB as defined in TS 33.501 [86], uses a different counter (sk-Counter) and is used only for DRBs using NR PDCP. Whenever there is a need to refresh S-KgNB/S-KeNB, e.g. upon change of MN or SN, the NR SCG reconfiguration with sync and key change is used for S-KgNB refresh (see 5.3.1.1) and the RRCConnectionReconfiguration message including mobilityControlInfoSCG is used for S-KeNB refresh (see 5.3.10.10). E-UTRAN provides a UE configured with (NG)EN-DC with an sk-Counter even when no DRB is setup using S-KgNB i.e. to facilitate configuration of SRB3. The same ciphering algorithm as signalled by nr-RadioBearerConfig1 and nr-RadioBearerConfig2 as defined in TS 38.331 [82] is used for all radio bearers using the same key (i.e. KeNB or S-KgNB). Likewise, the same integrity algorithm as signalled by nr-RadioBearerConfig1 and nr-RadioBearerConfig2 as defined in TS 38.331 [82] is used for all SRBs using the same key. Although NR RRC uses different values for the security algorithms than E-UTRA, the actual algorithms are the same in case of (NG)EN-DC and NE-DC in this version of the specification. Hence, for such algorithms, the security capabilities supported by a UE are consistent across these RATs. For MR-DC, integrity protection is not enabled for DRBs terminated on eNB or when the master node is an ng-eNB.

NOTE 2: The network ensures that different values are used for the SCG counter and for the sk-Counter when deriving S-KgNB and/or S-KeNB from the same master key.

5.3.1.2a RN security

For RNs, AS security follows the procedures in 5.3.1.2. Furthermore, E-UTRAN may configure per DRB whether or not integrity protection is used. The use of integrity protection may be configured only upon DRB establishment and reconfigured only upon handover or upon the first reconfiguration following RRC connection re-establishment.

To provide integrity protection on DRBs between the RN and the E-UTRAN, the KUPint key is derived from the KeNB key as described in TS 33.401 [32]. The same integrity protection algorithm used for SRBs also applies to the DRBs. The KUPint changes at every handover and RRC connection re-establishment and is based on an updated KeNB which is derived by taking into account the nextHopChainingCount. The COUNT value maintained for DRB ciphering is also used for integrity protection, if the integrity protection is configured for the DRB.

5.3.1.3 Connected mode mobility

In RRC_CONNECTED, the network controls UE mobility, i.e. the network decides when the UE shall connect to which E-UTRA cell(s), or inter-RAT cell. For network controlled mobility in RRC_CONNECTED, the PCell can be changed using an RRCConnectionReconfiguration message including the mobilityControlInfo (handover), whereas the SCell(s) can be changed using the RRCConnectionReconfiguration message either with or without the mobilityControlInfo.

In DC, an SCG can be established, reconfigured or released by using an RRCConnectionReconfiguration message with or without the mobilityControlInfo. In case Random Access to the PSCell or initial PUSCH transmission to the PSCell if rach-SkipSCG is configured is required upon SCG reconfiguration, E-UTRAN employs the SCG change procedure (i.e. an RRCConnectionReconfiguration message including the mobilityControlInfoSCG). The PSCell can only be changed using the SCG change procedure and by release and addition of the PSCell.

In (NG)EN-DC, an NR SCG can be established or reconfigured by using an RRCConnectionReconfiguration message containing nr-secondaryCellGroupConfig and nr-RadioBearerConfig. The contents of nr-secondaryCellGroupConfig and nr-RadioBearerConfig, of other (NG)EN-DC fields as well as the associated procedures are specified in TS 38.331 [82]. In (NG)EN-DC, the PSCell can only be changed using the Reconfiguration with sync procedure, with or without MR-DC release and addition.

The network triggers the handover procedure e.g. based on radio conditions, load. To facilitate this, the network may configure the UE to perform measurement reporting (possibly including the configuration of measurement gaps). The network may also initiate handover blindly, i.e. without having received measurement reports from the UE.

Before sending the handover message to the UE, the source eNB prepares one or more target cells. The source eNB selects the target PCell. The source eNB may also provide the target eNB with a list of best cells on each frequency for which measurement information is available, in order of decreasing RSRP. The source eNB may also include available measurement information for the cells provided in the list. The target eNB decides which SCells are configured for use after handover, which may include cells other than the ones indicated by the source eNB. If an SCG is configured, handover involves either SCG release or either SCG change (in case of DC) or an NR SCG reconfiguration with sync and key change (in case of EN-DC and NGEN-DC). In case the UE was configured with (EN-) DC or NGEN-DC, the target eNB indicates in the handover message whether the UE shall release the entire (NR) SCG configuration. Upon connection re-establishment, the UE releases the entire SCG configuration except for the DRB configuration, while E-UTRAN in the first reconfiguration message following the re-establishment either releases the DRB(s) or reconfigures the DRB(s) to MCG DRB(s).

The target eNB generates the message used to perform the handover, i.e. the message including the AS-configuration to be used in the target cell(s). The source eNB transparently (i.e. does not alter values/ content) forwards the handover message/ information received from the target to the UE. When appropriate, the source eNB may initiate data forwarding for (a subset of) the DRBs.

After receiving the handover message, the UE attempts to access the target PCell at the first available RACH occasion according to Random Access resource selection defined in TS 36.321 [6], i.e. the handover is asynchronous, or at the first available PUSCH occasion if rach-Skip is configured. Consequently, when allocating a dedicated preamble for the random access in the target PCell, E-UTRA shall ensure it is available from the first RACH occasion the UE may use. The first available PUSCH occasion is provided by ul-ConfigInfo, if configured, otherwise UE shall monitor the PDCCH of target eNB. Upon successful completion of the handover, the UE sends a message used to confirm the handover.

If the target eNB does not support the release of RRC protocol which the source eNB used to configure the UE, the target eNB may be unable to comprehend the UE configuration provided by the source eNB. In this case, the target eNB should use the full configuration option to reconfigure the UE for Handover and Re-establishment. Full configuration option includes an initialization of the radio configuration, which makes the procedure independent of the configuration used in the source cell(s) with the exception that the security algorithms are continued for the RRC re-establishment.

The same behavior applies in (NG)EN-DC, if upon handover the target eNB is unable to comprehend the MCG part of the UE configuration i.e. the target eNB uses the full configuration option which involves release and configuration of (most of the) MCG and NR SCG configuration. In case of (NG)EN-DC, the target SgNB may be unable to comprehend the NR SCG configuration provided by the source SgNB. In such a case, release and addition may be applied for the NR SCG part of the configuration.

NOTE 1: When using release and addition for the NR SCG configuration during handover or SN change, E-UTRAN includes drb-ToReleaseList for the SN terminated RBs. For SN modification case, see TS 37.340 [81].

After the successful completion of handover, PDCP SDUs may be re-transmitted in the target cell(s). This only applies for DRBs using RLC-AM mode and for handovers not involving full configuration option. The further details are specified in TS 36.323 [8]. After the successful completion of handover not involving full configuration option, the SN and the HFN are reset except for the DRBs using RLC-AM mode (for which both SN and HFN continue). For reconfigurations involving the full configuration option, the PDCP entities are newly established (SN and HFN do not continue) for all DRBs irrespective of the RLC mode. The further details are specified in TS 36.323 [8].

One UE behaviour to be performed upon handover is specified, i.e. this is regardless of the handover procedures used within the network (e.g. whether the handover includes X2 or S1 signalling procedures).

The source eNB should, for some time, maintain a context to enable the UE to return in case of handover failure. After having detected handover failure, the UE attempts to resume the RRC connection either in the source PCell or in another cell using the RRC re-establishment procedure. This connection resumption succeeds only if the accessed cell is prepared, i.e. concerns a cell of the source eNB or of another eNB towards which handover preparation has been performed. The cell in which the re-establishment procedure succeeds becomes the PCell while SCells and STAGs, if configured, are released.

Normal measurement and mobility procedures are used to support handover to cells broadcasting a CSG identity. In addition, E-UTRAN may configure the UE to report that it is entering or leaving the proximity of cell(s) included in its CSG whitelist. Furthermore, E-UTRAN may request the UE to provide additional information broadcast by the handover candidate cell e.g. global cell identity, CSG identity, CSG membership status.

NOTE 2: E-UTRAN may use the ‘proximity report’ to configure measurements as well as to decide whether or not to request additional information broadcast by the handover candidate cell. The additional information is used to verify whether or not the UE is authorised to access the target PCell and may also be needed to identify handover candidate cell (PCI confusion i.e. when the physical layer identity that is included in the measurement report does not uniquely identify the cell).

5.3.1.4 Connection control in NB-IoT

In NB-IoT, during the RRC connection establishment procedure, SRB1bis is established implicitly with SRB1. SRB1bis uses the logical channel identity defined in 9.1.2a, with the same configuration as SRB1 but no PDCP entity. SRB1bis is used until security is activated. The RRC messages to activate security (command and successful response) are sent over SRB1 being integrity protected and ciphering is started after completion of the procedure. In case of unsuccessful security activation, the failure message is sent over SRB1 and subsequent messages are sent over SRB1bis. Once security is activated, new RRC messages shall be transmitted using SRB1. A NB-IoT UE that only supports the Control Plane CIoT EPS optimisation (see TS 24.301 [35]) only establishes SRB1bis.

A NB-IoT UE only supports 0, 1 or 2 DRBs, depending on its capability. A NB-IoT UE that only supports the Control Plane CIoT EPS optimisation (see TS 24.301 [35]) does not need to support any DRBs and associated procedures.

Table 5.3.1.4-1 lists the procedures that are applicable for NB-IoT. All other procedures are not applicable; this is not further stated in the corresponding procedures.

Table 5.3.1.4-1: Connection control procedures applicable to a NB-IoT UE

Clause

Procedures

5.3.2

Paging

5.3.3

RRC connection establishment

RRC connection resume (see NOTE)

CP-EDT

UP-EDT (see NOTE)

5.3.4

Initial security activation (see NOTE)

5.3.5

RRC connection reconfiguration (see NOTE)

5.3.7

RRC connection re-establishment

5.3.8

RRC connection release

5.3.9

RRC connection release requested by upper layers

5.3.10

Radio resource configuration

5.3.11

Radio link failure related actions

5.3.12

UE actions upon leaving RRC_CONNECTED

NOTE: Not applicable for a UE that only supports the Control Plane CIoT EPS optimisation (see TS 24.301 [35]).