5.1 General

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

5.1.1 Introduction

The procedural requirements are structured according to the main functional areas: system information (5.2), connection control (5.3), inter-RAT mobility (5.4) and measurements (5.5). In addition, clause 5.6 covers other aspects e.g. NAS dedicated information transfer, UE capability transfer, clause 5.7 specifies the generic error handling, clause 5.8 covers MBMS (i.e. MBMS service reception via MRB), clause 5.8a covers SC-PTM (i.e. MBMS service reception via SC-MRB), clause 5.9 covers RN-specific procedures and clause 5.10 covers sidelink.

For NB-IoT, only a subset of the above procedural requirements applies: system information (5.2), connection control (5.3), some part of other aspects (5.6), general error handling (5.7), and SC-PTM (5.8a). Clauses inter-RAT mobility (5.4), measurements (5.5), MBMS (5.8), RN procedures (5.9) and Sidelink (5.10) are not applicable in NB-IoT.

5.1.2 General requirements

The UE shall:

1> process the received messages in order of reception by RRC, i.e. the processing of a message shall be completed before starting the processing of a subsequent message;

NOTE 1: E-UTRAN may initiate a subsequent procedure prior to receiving the UE’s response of a previously initiated procedure.

1> within a clause execute the steps according to the order specified in the procedural description;

1> consider the term ‘radio bearer’ (RB) to cover SRBs and DRBs but not MRBs or SC-MRBs unless explicitly stated otherwise;

1> set the rrc-TransactionIdentifier in the response message, if included, to the same value as included in the received RRC message that triggered the response message;

1> upon receiving a choice value set to setup:

2> apply the corresponding received configuration and start using the associated resources, unless explicitly specified otherwise;

1> upon receiving a choice value set to release:

2> clear the corresponding configuration and stop using the associated resources;

NOTE 1a: Following receipt of choice value set to release, the UE considers the field as if it was never configured.

1> upon handover to E-UTRA; or

1> upon receiving an RRCConnectionReconfiguration message including the fullConfig:

2> apply the Conditions in the ASN.1 for inclusion of the fields for the DRB/PDCP/RLC setup during the reconfiguration of the DRBs included in the drb-ToAddModList;

NOTE 2: At each point in time, the UE keeps a single value for each field except for during handover when the UE temporarily stores the previous configuration so it can revert back upon handover failure. In other words: when the UE reconfigures a field, the existing value is released except for during handover.

NOTE 3: Although not explicitly stated, the UE initially considers all functionality to be deactivated/ released until it is explicitly stated that the functionality is setup/ activated. Correspondingly, the UE initially considers lists to be empty e.g. the list of radio bearers, the list of measurements.

1> upon receiving an extension field comprising the entries in addition to the ones carried by the original field (regardless of whether E-UTRAN may signal more entries in total); apply the following generic behaviour if explicitly stated to be applicable:

2> create a combined list by concatenating the additional entries included in the extension field to the original field while maintaining the order among both the original and the additional entries;

2> for the combined list, created according to the previous, apply the same behaviour as defined for the original field;

NOTE 4: A field comprising a list of entries normally includes ‘list’ in the field name. The typical way to extend (the size of) such a list is to introduce a field comprising the additional entries, which should include ‘listExt’ in the name of the field/ IE. E.g. field1List-RAT, field1ListExt-RAT.

1> consider the term DC to cover the case of an E-UTRA MCG and SCG; Likewise, MCG covers the case of an E-UTRA MCG, SCG covers the case of an E-UTRA SCG, serving cell covers the case of an E-UTRA serving cell, PDCP covers the case of PDCP defined by E-UTRA specifications;

NOTE 5: In this specification, UE configuration refers to the parameters configured by E-UTRA RRC unless stated otherwise. Likewise, when a procedure is mentioned, this concerns the procedure defined by E-UTRA RRC unless stated otherwise.

5.1.3 Requirements for UE in MR-DC

In this specification, the UE considers itself to be configured with;

– EN-DC if and only if it is configured with nr-SecondaryCellGroupConfig and it is connected to EPC,

– NGEN-DC if and only if it is configured with nr-SecondaryCellGroupConfig and it is connected to 5GC,

– NE-DC if and only if it is configured with mrdc-SecondaryCellGroup set to eutra-SCG according to TS 38.331[82],

– MR-DC if and only if it is configured with (NG)EN-DC or NE-DC.

NOTE 1: The above deviates from the definition in TS 37.340 [81] (and some other specifications) i.e. according to TS 37.340 [81] a UE that is not configured with an SCG is in MR-DC when one or more bearers are terminated in the secondary node (i.e. using NR PDCP).

NOTE 2: MR-DC includes NR-DC, but that option is not relevant for this specification.

The UE configured with NE-DC only executes a subclause of clause 5 from this specification when the concerned subclause:

– is referrenced from a subclause, either in this specification or in TS 38.331 [82], that is executed by the UE; or

– covers actions upon (re-)configuration of field(s), IE(s), UE variable(s) or timer(s) applicable for NE-DC;

When executing a subclause of clause 5 in this specification, the UE also follows the related general requirements as defined in clause 5.1.2 and other subclauses of this specification e.g. message processing delay requirements.