36.3313GPPEvolved Universal Terrestrial Radio Access (E-UTRA)Protocol specificationRadio Resource Control (RRC)Release 15TS
In this specification, (parts of) procedures and messages specified for the UE equally apply to the RN for functionality necessary for the RN. There are also (parts of) procedures and messages which are only applicable to the RN in its communication with the E-UTRAN, in which case the specification denotes the RN instead of the UE. Such RN‑specific aspects are not applicable to the UE.
This specification covers MR-DC i.e. the case in which the UE is configured with resources belonging to another node using NR RAT. The NR related configuration is performed using NR RRC as specified in TS 38.331 .
NB-IoT is a non backward compatible variant of E-UTRAN supporting a reduced set of functionality. In this specification, (parts of) procedures and messages specified for the UE equally apply to the UE in NB-IoT. There are also some features and related procedures and messages that are not supported by UEs in NB-IoT.
In particular, the following features are not supported in NB-IoT and corresponding procedures and messages do not apply to the UE in NB-IoT:
– Connected mode mobility (Handover and measurement reporting);
– Inter-RAT cell reselection or inter-RAT mobility in connected mode;
– E-UTRA connected to 5GC;
– Relay Node (RN);
– Carrier Aggregation (CA);
– Dual connectivity (DC);
– Multi-Radio Dual Connectivity (MR-DC);
– PDCP duplication;
– GBR (QoS);
– ACB, EAB, SSAC and ACDC;
– MBMS, except for MBMS via SC-PTM in Idle mode;
– Self-configuration and self-optimisation;
– Measurement logging and reporting for network performance optimisation;
– Public warning systems e.g. CMAS, ETWS and PWS;
– Broadcast of positioning assistance data;
– Real time services (including emergency call);
– CS services and CS fallback;
– In-device coexistence;
– RAN assisted WLAN interworking;
– Network-assisted interference cancellation/suppression;
– Sidelink (including direct communication and direct discovery).
NOTE: In regard to mobility, NB-IoT is a separate RAT from E-UTRAN.
In this specification, there are also (parts of) procedures and messages which are only applicable to UEs in NB-IoT, in which case this is stated explicitly.
This specification is organised as follows:
– clause 4.2 describes the RRC protocol model;
– clause 4.3 specifies the services provided to upper layers as well as the services expected from lower layers;
– clause 4.4 lists the RRC functions;
– clause 5 specifies RRC procedures, including UE state transitions;
– clause 6 specifies the RRC message in a mixed format (i.e. tabular & ASN.1 together);
– clause 7 specifies the variables (including protocol timers and constants) and counters to be used by the UE;
– clause 8 specifies the encoding of the RRC messages;
– clause 9 specifies the specified and default radio configurations;
– clause 10 specifies the RRC messages transferred across network nodes;
– clause 11 specifies the UE capability related constraints and performance requirements.
4.2.1 UE states and state transitions including inter RAT
A UE is in RRC_CONNECTED when an RRC connection has been established or in RRC_INACTIVE (if the UE is connected to 5GC) when RRC connection is suspended. If this is not the case, i.e. no RRC connection is established, the UE is in RRC_IDLE state. The RRC states can further be characterised as follows:
– A UE specific DRX may be configured by upper layers (not applicable for NB-IoT);
– UE controlled mobility;
– The UE:
– Monitors a Paging channel to detect incoming calls (by CN paging), system information change, for ETWS capable UEs, ETWS notification, and for CMAS capable UEs, CMAS notification;
– Performs neighbouring cell measurements and cell (re-)selection;
– Acquires system information;
– Performs logging of available measurements together with location and time for logged measurement configured UEs;
– May perform EDT.
– A UE specific DRX may be configured by upper layers or by RRC layer;
– A RAN-based notification area is configured by RRC layer;
– The UE stores the UE Inactive AS context;
– The UE:
– Applies RRC_IDLE procedures unless specified otherwise;
– Monitors a Paging channel for CN paging using 5G-S-TMSI and RAN paging using fullI-RNTI;
– Performs periodic RAN-based notification area update;
– Performs RAN-based notification area update when moving out of the configured RAN-based notification area.
– Transfer of unicast data to/from UE;
– At lower layers, the UE may be configured with a UE specific DRX;
– For UEs supporting CA, use of one or more SCells, aggregated with the PCell, for increased bandwidth;
– For UEs supporting DC, use of one SCG, aggregated with the MCG, for increased bandwidth;
– For UEs supporting (NG)EN-DC, option to configure one NR SCG in conjunction with the MCG for DRBs and SRBs, for improved performance (SRBs) and increased bandwidth (DRBs);
– For UEs supporting NE-DC, option to configure one SCG in conjunction with the NR MCG for DRBs and SRBs, for improved performance (SRBs) and increased bandwidth (DRBs);
– Network controlled mobility, i.e. handover and cell change order with optional network assistance (NACC) to GERAN (not applicable for NB-IoT);
– The UE:
– Monitors a Paging channel and/ or System Information Block Type 1 contents to detect system information change, for ETWS capable UEs, ETWS notification, and for CMAS capable UEs, CMAS notification (not applicable for BL UEs, UEs in CE and NB-IoT UEs);
– Monitors control channels associated with the shared data channel to determine if data is scheduled for it;
– Provides channel quality and feedback information (not applicable for NB-IoT);
– Performs neighbouring cell measurements and measurement reporting (not applicable for NB-IoT);
– Acquires system information (not applicable for BL UEs, UEs in CE and NB-IoT UEs).
NOTE: The term "UE is connected to 5GC" covers the scenarios that the UE is connected to 5GC and the UE is requesting to connect with 5GC.
Figure 4.2.1-1 not only provides an overview of the RRC states in E-UTRA/EPC, but also illustrates the mobility support between E-UTRA/EPC, UTRAN and GERAN.
Figure 4.2.1-1: E-UTRA/EPC states and inter RAT mobility procedures, 3GPP
Figure 4.2.1-2 illustrates the mobility support between E-UTRA/EPC, CDMA2000 1xRTT and CDMA2000 HRPD. The details of the CDMA2000 state models are out of the scope of this specification.
Figure 4.2.1-2: Mobility procedures between E-UTRA/EPC and CDMA2000
Figure 4.2.1-3 not only provides an overview of the RRC states in E-UTRA/5GC, but also illustrates the mobility support between E-UTRA/5GC, UTRAN and GERAN.
Figure 4.2.1-3: E-UTRA/5GC states and inter RAT mobility procedures, 3GPP
Figure 4.2.1-4 illustrates the mobility procedures supported between E-UTRA/5GC, CDMA2000 1xRTT and CDMA2000 HRPD. The details of the CDMA2000 state models are out of the scope of this specification.
Figure 4.2.1-4: Mobility procedures between E-UTRA/5GC and CDMA2000
Figure 4.2.1-5 illustrates the mobility procedures supported between E-UTRA/5GC and E-UTRA/EPC.
Figure 4.2.1-5: Mobility procedures between E-UTRA/5GC and E-UTRA/EPC
Figure 4.2.1-6 illustrates the mobility procedures supported between E-UTRA/EPC, E-UTRA/5GC and NR.
Figure 4.2.1-6: Mobility procedures between E-UTRA/EPC, E-UTRA/5GC and NR
The inter-RAT handover procedure(s) supports the case of signalling, conversational services, non-conversational services and combinations of these.
In addition to the state transitions shown in figures above, there is support for connection release with redirection information from E-UTRA RRC_CONNECTED to GERAN, UTRAN, CDMA2000 (HRPD Idle/ 1xRTT Dormant mode) and NR. A UE in RRC_INACTIVE enters RRC_IDLE when it enters another RAT or switches to another CN type.
For NB-IoT, mobility between E-UTRA and UTRAN, GERAN and between E-UTRA and CDMA2000 1xRTT and CDMA2000 HRPD is not supported at AS level and hence only the E-UTRA states depicted in Figure 4.2.1-1 are applicable.
4.2.2 Signalling radio bearers
"Signalling Radio Bearers" (SRBs) are defined as Radio Bearers (RB) that are used only for the transmission of RRC and NAS messages. More specifically, the following SRBs are defined:
– SRB0 is for RRC messages using the CCCH logical channel;
– SRB1 is for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the establishment of SRB2, all using DCCH logical channel;
– For NB-IoT, SRB1bis is for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the activation of security, all using DCCH logical channel;
– SRB2 is for RRC messages which include logged measurement information as well as for NAS messages, all using DCCH logical channel. SRB2 has a lower-priority than SRB1 and is always configured by E-UTRAN after security activation. SRB2 is not applicable for NB-IoT;
– SRB4 is for RRC messages which include application layer measurement reporting information, all using DCCH logical channel. SRB4 can only be configured by E-UTRAN after security activation. SRB4 is not applicable for NB-IoT.
In downlink piggybacking of NAS messages is used only for one dependant (i.e. with joint success/ failure) procedure: bearer establishment/ modification/ release. In uplink NAS message piggybacking is used only for transferring the initial NAS message during connection setup.
NOTE 1: The NAS messages transferred via SRB2 are also contained in RRC messages, which however do not include any RRC protocol control information.
Once security is activated, all RRC messages on SRB1, SRB2 and SRB4, including those containing NAS or non-3GPP messages, are integrity protected and ciphered by PDCP. NAS independently applies integrity protection and ciphering to the NAS messages.
For a UE configured with DC, all RRC messages, regardless of the SRB used and both in downlink and uplink, are transferred via the MCG. In case of EN-DC, after connection establishment NR PDCP may be configured for both SRB1 and SRB2 and if so, these SRBs may be configured as split SRB. In case of NGEN-DC and NE-DC, NR PDCP is always configured. For a split SRB, the UE receives RRC messages via both MCG and NR SCG i.e. handles out of order and duplicate PDUs as specified in TS 38.323 . For a split SRB, the network configures via which cell group(s) the UE sends uplink RRC messages.
NOTE 2: In case of (NG)EN-DC, SRB3 may be configured for the transfer of some NR RRC messages between UE and SgNB via the NR radio interface, see TS 38.331 .
An SRB can be configured with PDCP duplication, either by two logical channels within the same CG (CA duplication) or by two logical channels each within a different CG (DC duplication).
4.3.1 Services provided to upper layers
The RRC protocol offers the following services to upper layers:
– Broadcast of common control information;
– Broadcast of positioning assistance data;
– Notification of UEs in RRC_IDLE and RRC_INACTIVE, e.g. about a terminating call, for ETWS, for CMAS;
– Transfer of dedicated control information, i.e. information for one specific UE.
4.3.2 Services expected from lower layers
In brief, the following are the main services that RRC expects from lower layers:
– PDCP: integrity protection and ciphering;
– RLC: reliable and in-sequence transfer of information, without introducing duplicates and with support for segmentation and concatenation.
Further details about the services provided by Packet Data Convergence Protocol layer (e.g. integrity and ciphering) are provided in TS 36.323 . The services provided by Radio Link Control layer (e.g. the RLC modes) are specified in TS 36.322 . Further details about the services provided by Medium Access Control layer (e.g. the logical channels) are provided in TS 36.321 . The services provided by physical layer (e.g. the transport channels) are specified in TS 36.302 .
The RRC protocol includes the following main functions:
– Broadcast of system information:
– Including NAS common information;
– Information applicable for UEs in RRC_IDLE, e.g. cell (re-)selection parameters, neighbouring cell information and information (also) applicable for UEs in RRC_CONNECTED, e.g. common channel configuration information;
– Including ETWS notification, CMAS notification (not applicable for NB-IoT);
– Including positioning assistance data.
– RRC connection control:
– Establishment/ modification/ suspension / resumption / release of RRC connection, including e.g. assignment/ modification of UE identity (C-RNTI), establishment/ modification/ suspension/ resumption/ release of SRB1, SRB1bis, SRB2 and SRB4, access class barring;
– Initial security activation, i.e. initial configuration of AS integrity protection (SRBs) and AS ciphering (SRBs, DRBs);
– For RNs, configuration of AS integrity protection for DRBs;
– RRC connection mobility including e.g. intra-frequency and inter-frequency handover, associated security handling, i.e. key/ algorithm change, specification of RRC context information transferred between network nodes;
NOTE 1: In NB-IoT, only key change (but no re-keying) at RRC Connection Resumption and RRC context information transfer are applicable.
– Establishment/ modification/ release of RBs carrying user data (DRBs);
– Radio configuration control including e.g. assignment/ modification of ARQ configuration, HARQ configuration, DRX configuration;
– For RNs, RN-specific radio configuration control for the radio interface between RN and E-UTRAN;
– In case of CA, cell management including e.g. change of PCell, addition/ modification/ release of SCell(s) and addition/modification/release of STAG(s);
– In case of DC, cell management including e.g. change of PSCell, addition/ modification/ release of SCG cell(s) and addition/modification/release of SCG TAG(s);
– In case of (NG)EN-DC, transparent transfer of NR RRC messages (e.g. DL: reconfiguration messages used to add or modify the NR SCG configuration or to (re-)configure measurements; UL: measurement reports and reconfiguration complete messages) and of configurations of radio bearers using NR PDCP;
– QoS control including assignment/ modification of semi-persistent scheduling (SPS) configuration information for DL and UL, assignment/ modification of parameters for UL rate control in the UE, i.e. allocation of a priority and a prioritised bit rate (PBR) for each RB (not applicable for NB-IoT);
– Recovery from radio link failure;
– In case of LWA, RCLWI and LWIP, WLAN mobility set management including e.g. addition/ modification/ release of WLAN(s) from the WLAN mobility set;
– Inter-RAT mobility including e.g. security activation, transfer of RRC context information (not applicable for NB-IoT);
– Measurement configuration and reporting (not applicable for NB-IoT):
– Establishment/ modification/ release of measurements (e.g. intra-frequency, inter-frequency and inter- RAT measurements);
– Setup and release of measurement gaps;
– Measurement reporting;
– Other functions including e.g. transfer of dedicated NAS information and non-3GPP dedicated information, transfer of UE radio access capability information, support for E-UTRAN sharing (multiple PLMN identities);
– Generic protocol error handling;
– Support of self-configuration and self-optimisation (not applicable for NB-IoT);
– Support of measurement logging and reporting for network performance optimisation, as specified in TS 37.320  (not applicable for NB-IoT).
NOTE 2: Random access is specified entirely in the MAC including initial transmission power estimation.
4.5 Data available for transmission for NB-IoT
For the purpose of MAC Data Volume and Power Headroom reporting, the NB-IoT UE shall consider the following as data available for transmission in the RRC layer:
– For SDUs to be submitted to lower layers:
– the SDU itself, if the SDU has not yet been processed by RRC; or
– the PDU if the SDU has been processed by RRC;
– The data available for transmission in upper layers not submitted to the RRC layer.