5.2 System information

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

5.2.1 Introduction

5.2.1.1 General

System information is divided into the MasterInformationBlock (MIB) and a number of SystemInformationBlocks (SIBs) and SystemInformationBlockPos (posSIBs). The MIB includes a limited number of most essential and most frequently transmitted parameters that are needed to acquire other information from the cell, and is transmitted on BCH. SIBs other than SystemInformationBlockType1 and posSIBs are carried in SystemInformation (SI) messages. The mapping of SIBs and posSIBs to SI messages is flexibly configurable by schedulingInfoList and posSchedulingInfoList, respectively, included in SystemInformationBlockType1, with restrictions that: each SIB is contained only in a single SI message and each SIB and posSIB is contained at most once in that SI message; only SIBs and posSIBs having the same scheduling requirement (periodicity) can be mapped to the same SI message; SystemInformationBlockType2 is always mapped to the SI message that corresponds to the first entry in the list of SI messages in schedulingInfoList. There may be multiple SI messages transmitted with the same periodicity. SystemInformationBlockType1 and all SI messages are transmitted on DL-SCH.

The Bandwidth reduced Low Complexity (BL) UEs and UEs in Coverage Enhancement (CE) apply Bandwidth Reduced (BR) version of the SIB, posSIB or SI messages. A UE considers itself in enhanced coverage as specified in TS 36.304 [4]. In this and subsequent clauses, anything applicable for a particular SIB, posSIB or SI message equally applies to the corresponding BR version unless explicitly stated otherwise.

For NB-IoT, a reduced set of system information block with similar functionality but different content is defined; the UE applies the NB-IoT (NB) version of the MIB and the SIBs. These are denoted MasterInformationBlock-NB, MasterInformationBlock-TDD-NB and SystemInformationBlockTypeX-NB in this specification. All other system information blocks (without NB suffix) are not applicable to NB-IoT; this is not further stated in the corresponding text.

NOTE 1: The physical layer imposes a limit to the maximum size a SIB can take. When DCI format 1C is used the maximum allowed by the physical layer is 1736 bits (217 bytes) while for format 1A the limit is 2216 bits (277 bytes), see TS 36.212 [22] and TS 36.213 [23]. For BL UEs and UEs in CE, the maximum SIB and SI message size is 936 bits, see TS 36.213 [23]. For NB-IoT, the maximum SIB and SI message size is 680 bits, see TS 36.213 [23].

In addition to broadcasting, E-UTRAN may provide SystemInformationBlockType1 and/or SystemInformationBlockType2, including the same parameter values, via dedicated signalling i.e., within an RRCConnectionReconfiguration message.

The UE applies the system information acquisition and change monitoring procedures for the PCell, except when being a BL UE or a UE in CE or a NB-IoT UE in RRC_CONNECTED mode while T311 is not running. For an SCell, E-UTRAN provides, via dedicated signalling, all system information relevant for operation in RRC_CONNECTED when adding the SCell. However, a UE that is configured with DC shall aquire the MasterInformationBlock of the PSCell but use it only to determine the SFN timing of the SCG, which may be different from the MCG. Upon change of the relevant system information of a configured SCell, E-UTRAN releases and subsequently adds the concerned SCell, which may be done with a single RRCConnectionReconfiguration message. If the UE is receiving or interested to receive an MBMS service in a cell, the UE shall apply the system information acquisition and change monitoring procedure to acquire parameters relevant for MBMS operation and apply the parameters acquired from system information only for MBMS operation for this cell.

NOTE 2: E-UTRAN may configure via dedicated signalling different parameter values than the ones broadcast in the concerned SCell.

In MBMS-dedicated cell, non-MBSFN subframes are used for providing MasterInformationBlock-MBMS (MIB-MBMS) and SystemInformationBlockType1-MBMS. SIBs other than SystemInformationBlockType1-MBMS are carried in SystemInformation-MBMS message which is also provided on non-MBSFN subframes.

An RN configured with an RN subframe configuration does not need to apply the system information acquisition and change monitoring procedures. Upon change of any system information relevant to an RN, E-UTRAN provides the system information blocks containing the relevant system information to an RN configured with an RN subframe configuration via dedicated signalling using the RNReconfiguration message. For RNs configured with an RN subframe configuration, the system information contained in this dedicated signalling replaces any corresponding stored system information and takes precedence over any corresponding system information acquired through the system information acquisition procedure. The dedicated system information remains valid until overridden.

NOTE 3: E-UTRAN may configure an RN, via dedicated signalling, with different parameter values than the ones broadcast in the concerned cell.

5.2.1.2 Scheduling

The MIB uses a fixed schedule with a periodicity of 40 ms and repetitions made within 40 ms. The first transmission of the MIB is scheduled in subframe #0 of radio frames for which the SFN mod 4 = 0, and repetitions are scheduled in subframe #0 of all other radio frames. For TDD/FDD system with a bandwidth larger than 1.4 MHz that supports BL UEs or UEs in CE, MIB transmission may additionally be repeated in subframe#0 of the same radio frame, and in subframe#9 of the previous radio frame for FDD and subframe #5 of the same radio frame for TDD.

NOTE: The UE may assume the scheduling of MIB repetitions does not change. E-UTRAN may indicate in MobilityControlInfo whether optional MIB repetitions are enabled or not.

The MIB-MBMS uses a fixed schedule with a periodicity of 160 ms and repetitions made within 160 ms. The first transmission of the MIB-MBMS is scheduled in subframe #0 of radio frames for which the SFN mod 16 = 0, and repetitions are scheduled in subframe #0 of all other radio frames for which the SFN mod 4 = 0.

The SystemInformationBlockType1 uses a fixed schedule with a periodicity of 80 ms and repetitions made within 80 ms. The first transmission of SystemInformationBlockType1 is scheduled in subframe #5 of radio frames for which the SFN mod 8 = 0, and repetitions are scheduled in subframe #5 of all other radio frames for which SFN mod 2 = 0.

For BL UEs or UEs in CE, MIB is applied which may be provided with additional repetitions, while for SIB1 and further SI messages, separate messages are used which are scheduled independently and with content that may differ. The separate instance of SIB1 is named as SystemInformationBlockType1-BR. The SystemInformationBlockType1-BR uses a schedule with a periodicity of 80ms. TBS for SystemInformationBlockType1-BR and the repetitions made within 80ms are indicated via schedulingInfoSIB1-BR in MIB or optionally in the RRCConnectionReconfiguration message including the MobilityControlInfo.

The SystemInformationBlockType1-MBMS uses fixed schedule with a periodicity of 160 ms. The first transmission of SystemInformationBlockType1-MBMS is scheduled in subframe #0 of radio frames for which the SFN mod 16 = 0, and repetitions are scheduled in subframe #0 of all other radio frames for which SFN mod 8 = 0. Additionally, the SystemInformationBlockType1-MBMS and other system informations blocks may be scheduled in additional non-MBSFN subframes indicated in MasterInformationBlock-MBMS.

The SI messages are transmitted within periodically occurring time domain windows (referred to as SI-windows) using dynamic scheduling. Each SI message is associated with a SI-window and the SI-windows of different SI messages do not overlap. That is, within one SI-window only the corresponding SI is transmitted. The length of the SI-window is common for all SI messages, and is configurable. Within the SI-window, the corresponding SI message can be transmitted a number of times in any subframe other than MBSFN subframes, uplink subframes in TDD, and subframe #5 of radio frames for which SFN mod 2 = 0. The UE acquires the detailed time-domain scheduling (and other information, e.g. frequency-domain scheduling, used transport format) from decoding SI-RNTI on PDCCH (see TS 36.321 [6]). For a BL UE or a UE in CE, the detailed time/frequency domain scheduling information for the SI messages is provided in SystemInformationBlockType1-BR.

For UEs other than BL UE or UEs in CE SI-RNTI is used to address SystemInformationBlockType1 as well as all SI messages. On MBMS-dedicated cell and on FeMBMS/Unicast-mixed cell, SI-RNTI with value in accordance with TS 36.321 [6] is used to address all SI messages whereas SI-RNTI with value in accordance with TS 36.321 [6] is used to address SystemInformationBlockType1-MBMS.

SystemInformationBlockType1 configures the SI-window length and the transmission periodicity for the SI messages.

5.2.1.2a Scheduling for NB-IoT

The MasterInformationBlock-NB (MIB-NB) uses a fixed schedule with a periodicity of 640 ms and repetitions made within 640 ms. The first transmission of the MIB-NB is scheduled in subframe #0 of radio frames for which the SFN mod 64 = 0 and repetitions are scheduled in subframe #0 of all other radio frames. The transmissions are arranged in 8 independently decodable blocks of 80 ms duration.

The MasterInformationBlock-TDD-NB (MIB-TDD-NB) uses a fixed schedule with a periodicity of 640 ms and repetitions made within 640 ms. The first transmission of the MIB-TDD-NB is scheduled in subframe #9 of radio frames for which the SFN mod 64 = 0 and repetitions are scheduled in subframe #9 of all other radio frames. The transmissions are arranged in 8 independently decodable blocks of 80 ms duration.

The SystemInformationBlockType1-NB (SIB1-NB) uses a fixed schedule with a periodicity of 2560 ms.

For FDD, SIB1-NB transmission occurs in subframe #4 of every other frame in 16 continuous frames. The starting frame for the first transmission of the SIB1-NB is derived from the cell PCID and the number of repetitions within the 2560 ms period and repetitions are made, equally spaced, within the 2560 ms period (see TS 36.213 [23]). TBS for SystemInformationBlockType1-NB and the repetitions made within the 2560 ms are indicated by schedulingInfoSIB1 field in the MIB-NB. If additionalTransmissionSIB1 is set to TRUE in the MIB-NB, additional SIB1-NB transmission occurs in subframe #3 of the same radio frames where SIB1-NB transmission occurs with the same number of repetitions.

For TDD, SIB1-NB transmission on the anchor carrier occurs in either subframe #0 or subframe #4 of every other frame in 16 continuous frames and SIB1-NB transmission on a non-anchor carrier occurs in subframe #0 and next in subframe #5 of every other frame in 16 continuous frames. The starting frame for the first transmission of the SIB1-NB is derived from the cell PCID and the number of repetitions within the 2560 ms period and repetitions are made, equally spaced, within the 2560 ms period (see TS 36.213 [23]). TBS for SystemInformationBlockType1-NB, the repetitions made within the 2560 ms, and the subframe index (#0 or #4) are indicated by schedulingInfoSIB1 field in the MIB-TDD-NB.

The SI messages are transmitted within periodically occurring time domain windows (referred to as SI-windows) using scheduling information provided in SystemInformationBlockType1-NB. Each SI message is associated with a SI-window and the SI-windows of different SI messages do not overlap. That is, within one SI-window only the corresponding SI is transmitted. The length of the SI-window is common for all SI messages, and is configurable.

Within the SI-window, the corresponding SI message can be transmitted a number of times over 2 or 8 consecutive NB-IoT downlink subframes depending on TBS.The UE acquires the detailed time/frequency domain scheduling information and other information, e.g. used transport format for the SI messages from schedulingInfoList field in SystemInformationBlockType1-NB. The UE is not required to accumulate several SI messages in parallel but may need to accumulate a SI message across multiple SI windows, depending on coverage condition.

SystemInformationBlockType1-NB configures the SI-window length and the transmission periodicity for all SI messages.

5.2.1.3 System information validity and notification of changes

Change of system information (other than for ETWS, CMAS and EAB parameters and other than for AB parameters for NB-IoT) only occurs at specific radio frames, i.e. the concept of a modification period is used. System information may be transmitted a number of times with the same content within a modification period, as defined by its scheduling. The modification period boundaries are defined by SFN values for which SFN mod m= 0, where m is the number of radio frames comprising the modification period. The modification period is configured by system information. If H-SFN is provided in SystemInformationBlockType1-BR, modification period boundaries for BL UEs and UEs in CE are defined by SFN values for which (H-SFN * 1024 + SFN) mod m=0. For NB-IoT, H-SFN is always provided and the modification period boundaries are defined by SFN values for which (H-SFN * 1024 + SFN) mod m=0.

To enable system information update notification for RRC_IDLE UEs configured to use a DRX cycle longer than the modification period, an eDRX acquisition period is defined. The boundaries of the eDRX acquisition period are determined by H-SFN values for which H-SFN mod 256 =0. For NB-IoT, the boundaries of the eDRX acquisition period are determined by H-SFN values for which H-SFN mod 1024 =0.

NOTE 1: If the UE in RRC_IDLE is configured to use extended DRX cycle, e.g., in the order of several minutes or longer, in case the eNB is reset the UE SFN may not be synchronized to the new eNB SFN. The UE is expected to recover, e.g., acquire MIB within a reasonable time, to avoid repeated paging failures.

When the network changes (some of the) system information, it first notifies the UEs about this change, i.e. this may be done throughout a modification period. In the next modification period, the network transmits the updated system information. During a modification period where ETWS or CMAS transmission is started or stopped, the SI messages carrying the SIBs scheduled in schedulingInfoListExt and/or SI messages carrying the posSIBs scheduled in posSchedulingInfoList may change, so the UE might not be able to successfully receive those SIBs and/or posSIBs in the remainder of the current modification period and next modification period according to the scheduling information received prior to the change. These general principles are illustrated in figure 5.2.1.3-1, in which different colours indicate different system information. Upon receiving a change notification, the UE not configured to use a DRX cycle that is longer than the modification period acquires the new system information immediately from the start of the next modification period. Upon receiving a change notification applicable to eDRX, a UE in RRC_IDLE configured to use a DRX cycle that is longer than the modification period acquires the updated system information immediately from the start of the next eDRX acquisition period. The UE applies the previously acquired system information until the UE acquires the new system information. The possible boundaries of modification for SystemInformationBlockType1-BR are defined by SFN values for which SFN mod 512 = 0 except for notification of ETWS/CMAS for which the eNB may change SystemInformationBlockType1-BR content at any time. For NB-IoT, the possible boundaries of modification for SystemInformationBlockType1-NB are defined by SFN values for which (H-SFN * 1024 + SFN) mod 4096 = 0.

Figure 5.2.1.3-1: Change of system Information

The Paging message is used to inform UEs in RRC_IDLE and UEs in RRC_CONNECTED about a system information change. If the UE is in RRC_CONNECTED or is not configured to use a DRX cycle longer than the modification period in RRC_IDLE, and receives a Paging message including the systemInfoModification, it knows that the system information will change at the next modification period boundary. A UE in RRC_IDLE that is configured to use a DRX cycle longer than the modification period, and receives in an eDRX acquisition period at least one Paging message including the systemInfoModification-eDRX, shall acquire the updated system information at the next eDRX acquisition period boundary. Although the UE may be informed about changes in system information, no further details are provided e.g. regarding which system information will change, except if systemInfoValueTagSI is received by BL UEs or UEs in CE.

In RRC_CONNECTED, BL UEs or UEs in CE or NB-IoT UEs are not required to acquire system information except when T311 is running or upon handover where the UE is only required to acquire the MasterInformationBlock in the target PCell. In RRC_IDLE, E-UTRAN may notify BL UEs or UEs in CE or NB-IoT UEs about SI update, and except for NB-IoT, ETWS and CMAS notification and EAB modification, using Direct Indication information, as specified in 6.6 (or 6.7.5 in NB-IoT) and TS 36.212 [22].

NOTE 2: Upon system information change essential for BL UEs, UEs in CE, or NB-IoT UEs in RRC_CONNECTED, E-UTRAN may initiate connection release.

SystemInformationBlockType1 (or MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB in NB-IoT) includes a value tag systemInfoValueTag, that indicates if a change has occurred in the SI messages. UEs may use systemInfoValueTag, e.g. upon return from out of coverage, to verify if the previously stored SI messages are still valid. MasterInformationBlock (using systemInfoUnchanged-BR) and RSS (if transmitted) may indicate that a change has not occurred in the SIB1-BR and SI messages of the current cell at least over the SI validity time, and the BL UEs or UEs in CE may use systemInfoUnchanged-BR or RSS, e.g. upon return from out of coverage, to verify if the previously stored SIB1-BR and SI messages are still valid. Additionally, for other than BL UEs or UEs in CE or NB-IoT UEs, the UE considers stored system information to be invalid after 3 hours from the moment it was successfully confirmed as valid, unless specified otherwise. BL UE or UE in CE considers stored system information to be invalid after 24 hours from the moment it was successfully confirmed as valid, unless the UE is configured by parameter si-ValidityTime to consider stored system information to be invalid 3 hours after validity confirmation. NB-IoT UE considers stored system information to be invalid after 24 hours from the moment it was successfully confirmed as valid. If a BL UE, UE in CE or NB-IoT UE in RRC_CONNECTED state considers the stored system information invalid, the UE shall continue using the stored system information while in RRC_CONNECTED state in the serving cell.

For BL UEs or UEs in CE or NB-IoT UEs, the change of specific SI message can additionally be indicated by a SI message specific value tag systemInfoValueTagSI. If systemInfoValueTag included in the SystemInformationBlockType1-BR (or MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB in NB-IoT) is different from the one of the stored system information and if systemInfoValueTagSI is included in the SystemInformationBlockType1-BR (or SystemInformationBlockType1-NB in NB-IoT) for a specific SI message and is different from the stored one, the UE shall consider this specific SI message to be invalid. If only systemInfoValueTag is included and is different from the stored one, the BL UE or UE in CE should consider any stored system information except SystemInformationBlockType10, SystemInformationBlockType11, SystemInformationBlockType12 and SystemInformationBlockType14 to be invalid; the NB-IoT UE should consider any stored system information except SystemInformationBlockType14-NB to be invalid.

On MBMS-dedicated cell and on FeMBMS/Unicast-mixed cell, the change of system information and ETWS/CMAS notification is indicated by using Direct Indication FeMBMS defined in 6.6a. The modification periodicity follows MCCH modification periodicity as defined in 5.8.1.3.

E-UTRAN may not update systemInfoValueTag upon change of some system information e.g. ETWS information, CMAS information, regularly changing parameters like time information (SystemInformationBlockType8, SystemInformationBlockType16, hyperSFN-MSB in SystemInformationBlockType1-NB), EAB and AB parameters, or positioning system information blocks. Similarly, E-UTRAN may not include the systemInfoModification within the Paging message upon change of some system information.

The UE that is not configured to use a DRX cycle longer than the modification period verifies that stored system information remains valid by either checking systemInfoValueTag in SystemInformationBlockType1 (or MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB in NB-IoT) after the modification period boundary, or attempting to find the systemInfoModification indication at least modificationPeriodCoeff times during the modification period in case no paging is received, in every modification period. If no paging message is received by the UE during a modification period, the UE may assume that no change of system information will occur at the next modification period boundary. If UE in RRC_CONNECTED, during a modification period, receives one paging message, it may deduce from the presence/ absence of systemInfoModification whether a change of system information other than ETWS information, CMAS information and EAB parameters will occur in the next modification period or not.

When the RRC_IDLE UE is configured with a DRX cycle that is longer than the modification period, and at least one modification period boundary has passed since the UE last verified validity of stored system information, the UE verifies that stored system information remains valid by checking the systemInfoValueTag before establishing or resuming an RRC connection.

ETWS and/or CMAS capable UEs in RRC_CONNECTED, other than BL UEs and UEs in CE, shall attempt to read paging at least once every defaultPagingCycle to check whether ETWS and/or CMAS notification is present or not.

5.2.1.4 Indication of ETWS notification

ETWS primary notification and/ or ETWS secondary notification can occur at any point in time. The Paging message is used to inform ETWS capable UEs in RRC_IDLE and UEs in RRC_CONNECTED about presence of an ETWS primary notification and/ or ETWS secondary notification. If the UE receives a Paging message including the etws-Indication, it shall start receiving the ETWS primary notification and/ or ETWS secondary notification according to schedulingInfoList contained in SystemInformationBlockType1. If the UE receives Paging message including the etws-Indication while it is acquiring ETWS notification(s), the UE shall continue acquiring ETWS notification(s) based on the previously acquired schedulingInfoList until it re-acquires schedulingInfoList in SystemInformationBlockType1.

NOTE: The UE is not required to periodically check schedulingInfoList contained in SystemInformationBlockType1, but Paging message including the etws-Indication triggers the UE to re-acquire schedulingInfoList contained in SystemInformationBlockType1 for scheduling changes for SystemInformationBlockType10 and SystemInformationBlockType11. The UE may or may not receive a Paging message including the etws-Indication and/or systemInfoModification when ETWS is no longer scheduled.

ETWS primary notification is contained in SystemInformationBlockType10 and ETWS secondary notification is contained in SystemInformationBlockType11. Segmentation can be applied for the delivery of a secondary notification. The segmentation is fixed for transmission of a given secondary notification within a cell (i.e. the same segment size for a given segment with the same messageIdentifier, serialNumber and warningMessageSegmentNumber). An ETWS secondary notification corresponds to a single CB data IE as defined according to TS 23.041 [37].

5.2.1.5 Indication of CMAS notification

CMAS notification can occur at any point in time. The Paging message is used to inform CMAS capable UEs in RRC_IDLE and UEs in RRC_CONNECTED about presence of one or more CMAS notifications. If the UE receives a Paging message including the cmas-Indication, it shall start receiving the CMAS notifications according to schedulingInfoList contained in SystemInformationBlockType1. If the UE receives Paging message including the cmas-Indication while it is acquiring CMAS notification(s), the UE shall continue acquiring CMAS notification(s) based on the previously acquired schedulingInfoList until it re-acquires schedulingInfoList in SystemInformationBlockType1.

NOTE: The UE is not required to periodically check schedulingInfoList contained in SystemInformationBlockType1, but Paging message including the cmas-Indication triggers the UE to re-acquire schedulingInfoList contained in SystemInformationBlockType1 for scheduling changes for SystemInformationBlockType12. The UE may or may not receive a Paging message including the cmas-Indication and/or systemInfoModification when SystemInformationBlockType12 is no longer scheduled.

CMAS notification is contained in SystemInformationBlockType12. A CMAS notification corresponds to a single CB data IE as defined according to TS 23.041 [37]. A CMAS notification may optionally have associated warning area coordinates. Segmentation can be applied for the delivery of a CMAS notification and, if present, the associated warning area coordinates. The segmentation is fixed for transmission of a given CMAS notification and, if present, any associated warning area coordinates within a cell (i.e. the same segment size for a given segment with the same messageIdentifier, serialNumber and warningMessageSegmentNumber). E-UTRAN does not interleave transmissions of CMAS notifications, i.e. all segments of a given CMAS notification transmission are transmitted prior to those of another CMAS notification.

5.2.1.6 Notification of EAB parameters change

Change of EAB parameters can occur at any point in time. The EAB parameters are contained in SystemInformationBlockType14. The Paging message is used to inform EAB capable UEs in RRC_IDLE about a change of EAB parameters or that SystemInformationBlockType14 is no longer scheduled. If the UE receives a Paging message including the eab-ParamModification, it shall acquire SystemInformationBlockType14 according to schedulingInfoList contained in SystemInformationBlockType1. If the UE receives a Paging message including the eab-ParamModification while it is acquiring SystemInformationBlockType14, the UE shall continue acquiring SystemInformationBlockType14 based on the previously acquired schedulingInfoList until it re-acquires schedulingInfoList in SystemInformationBlockType1.

NOTE: The EAB capable UE is not expected to periodically check schedulingInfoList contained in SystemInformationBlockType1.

5.2.1.7 Access Barring parameters change in NB-IoT

Change of Access Barring (AB) parameters can occur at any point in time. The AB parameters are contained in SystemInformationBlockType14-NB. Update of the AB parameters does not impact the systemInfoValueTag in the MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB or the systemInfoValueTagSI in SystemInformationBlockType1-NB.

If SystemInformationBlockType14-NB is scheduled, a NB-IoT UE is required to acquire MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB before initiating RRC connection establishment / resume for all access causes except mobile terminating calls to check ab-Enabled indication. If access barring is enabled the UE shall not initiate the RRC connection establishment / resume for all access causes except mobile terminating calls until the UE has acquired the SystemInformationBlockType14-NB.

5.2.2 System information acquisition

5.2.2.1 General

Figure 5.2.2.1-1: System information acquisition, normal

The UE applies the system information acquisition procedure to acquire the AS- and NAS- and positioning-system information that is broadcasted by the E-UTRAN. The procedure applies to UEs in RRC_IDLE and UEs in RRC_CONNECTED.

For BL UE, UE in CE and NB-IoT UE, specific conditions apply, as specified below.

5.2.2.2 Initiation

The UE shall apply the system information acquisition procedure upon selecting (e.g. upon power on) and upon re-selecting a cell, after handover completion, after entering E-UTRA from another RAT, upon return from out of coverage, upon receiving a notification that the system information has changed, upon receiving an indication about the presence of an ETWS notification, upon receiving an indication about the presence of a CMAS notification, upon receiving a notification that the EAB parameters have changed, upon receiving a request from CDMA2000 upper layers, upon receiving a request from positioning upper layers and upon exceeding the maximum validity duration. Unless explicitly stated otherwise in the procedural specification, the system information acquisition procedure overwrites any stored system information, i.e. delta configuration is not applicable for system information and the UE discontinues using a field if it is absent in system information unless explicitly specified otherwise.

In RRC_CONNECTED, BL UEs and UEs in CE are required to acquire system information when T311 is running or upon handover where the UE is only required to acquire the MasterInformationBlock in the target PCell.

NOTE: Upon handover, E-UTRAN provides system information required by the UE in RRC_CONNECTED except MIB with RRC signalling, i.e. systemInformationBlockType1Dedicated and mobilityControlInfo.

5.2.2.3 System information required by the UE

The UE shall:

1> ensure having a valid version, as defined below, of (at least) the following system information, also referred to as the ‘required’ system information:

2> if in RRC_IDLE:

3> if the UE is a NB-IoT UE:

4> the MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB and SystemInformationBlockType1-NB as well as SystemInformationBlockType2-NB through SystemInformationBlockType5-NB, SystemInformationBlockType22-NB;

3> else:

4> the MasterInformationBlock and SystemInformationBlockType1 (or SystemInformationBlockType1-BR depending on whether the UE is a BL UE or the UE in CE) as well as SystemInformationBlockType2 through SystemInformationBlockType8 and SystemInformationBlockType24 (depending on support of the concerned RATs), SystemInformationBlockType17 (depending on support of RAN-assisted WLAN interworking when the UE is connected to EPC), SystemInformationBlockType25 (depending on support of E-UTRA/5GC);

2> if in RRC_INACTIVE:

3> the MasterInformationBlock and SystemInformationBlockType1 as well as SystemInformationBlockType2 through SystemInformationBlockType8 (depending on support of the concerned RATs), SystemInformationBlockType25;

2> if in RRC_CONNECTED; and

2> the UE is not a BL UE; and

2> the UE is not in CE; and

2> the UE is not a NB-IoT UE:

3> the MasterInformationBlock, SystemInformationBlockType1 and SystemInformationBlockType2 as well as SystemInformationBlockType8 (depending on support of CDMA2000), SystemInformationBlockType17 (depending on support of RAN-assisted WLAN interworking when the UE is connected to EPC), SystemInformationBlockType25 (depending on support of E-UTRA/5GC);

2> if in RRC_CONNECTED and T311 is running; and

2> the UE is a BL UE or the UE is in CE or the UE is a NB-IoT UE;

3> the MasterInformationBlock (or MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB in NB-IoT), SystemInformationBlockType1-BR (or SystemInformationBlockType1-NB in NB-IoT) and SystemInformationBlockType2 (or SystemInformationBlockType2-NB in NB-IoT), and for NB-IoT SystemInformationBlockType22-NB;

1> delete any stored system information after 3 hours or 24 hours from the moment it was confirmed to be valid as defined in 5.2.1.3, unless specified otherwise;

1> consider any stored system information except SystemInformationBlockType10, SystemInformationBlockType11, systemInformationBlockType12 and systemInformationBlockType14 (systemInformationBlockType14-NB in NB-IoT) to be invalid if systemInfoValueTag included in the SystemInformationBlockType1 (MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB in NB-IoT) is different from the one of the stored system information and in case of NB-IoT UEs, BL UEs and UEs in CE, systemInfoValueTagSI is not broadcasted. Otherwise consider system information validity as defined in 5.2.1.3;

5.2.2.4 System information acquisition by the UE

The UE shall:

1> apply the specified BCCH configuration defined in 9.1.1.1 or BR-BCCH configuration defined in 9.1.1.8;

1> if the procedure is triggered by a system information change notification:

2> if the UE uses an idle DRX cycle longer than the modification period:

3> start acquiring the required system information, as defined in 5.2.2.3, from the next eDRX acquisition period boundary;

2> else

3> start acquiring the required system information, as defined in 5.2.2.3, from the beginning of the modification period following the one in which the change notification was received;

NOTE 1: The UE continues using the previously received system information until the new system information has been acquired.

1> if the UE is in RRC_IDLE and enters a cell for which the UE does not have stored a valid version of the system information required in RRC_IDLE, as defined in 5.2.2.3:

2> acquire, using the system information acquisition procedure as defined in 5.2.3, the system information required in RRC_IDLE, as defined in 5.2.2.3;

1> following successful handover completion to a PCell for which the UE does not have stored a valid version of the system information required in RRC_CONNECTED, as defined in 5.2.2.3:

2> acquire, using the system information acquisition procedure as defined in 5.2.3, the system information required in RRC_CONNECTED, as defined in 5.2.2.3;

2> upon acquiring the concerned system information:

3> discard the corresponding radio resource configuration information included in the radioResourceConfigCommon previously received in a dedicated message, if any;

1> following a request from CDMA2000 upper layers:

2> acquire SystemInformationBlockType8, as defined in 5.2.3;

1> neither initiate the RRC connection establishment/resume procedure nor initiate transmission of the RRCConnectionReestablishmentRequest message until the UE has a valid version of the MasterInformationBlock (MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB in NB-IoT) and SystemInformationBlockType1 (SystemInformationBlockType1-NB in NB-IoT) messages as well as SystemInformationBlockType2 (SystemInformationBlockType2-NB in NB-IoT), and for NB-IoT, SystemInformationBlockType22-NB;

1> not initiate the RRC connection establishment/resume procedure subject to EAB until the UE has a valid version of SystemInformationBlockType14, if broadcast;

1> if the UE is ETWS capable:

2> upon entering a cell during RRC_IDLE, following successful handover or upon connection re-establishment:

3> discard any previously buffered warningMessageSegment;

3> clear, if any, the current values of messageIdentifier and serialNumber for SystemInformationBlockType11;

2> when the UE acquires SystemInformationBlockType1 following ETWS indication, upon entering a cell during RRC_IDLE, following successful handover or upon connection re-establishment:

3> if schedulingInfoList indicates that SystemInformationBlockType10 is present:

4> if the UE is in CE:

5> start acquiring SystemInformationBlockType10;

4> else

5> start acquiring SystemInformationBlockType10 immediately;

3> if schedulingInfoList indicates that SystemInformationBlockType11 is present:

4> start acquiring SystemInformationBlockType11 immediately;

NOTE 2: UEs shall start acquiring SystemInformationBlockType10 and SystemInformationBlockType11 as described above even when systemInfoValueTag in SystemInformationBlockType1 has not changed.

1> if the UE is CMAS capable:

2> upon entering a cell during RRC_IDLE, following successful handover or upon connection re-establishment:

3> discard any previously buffered warningMessageSegment;

3> clear, if any, stored values of messageIdentifier and serialNumber for SystemInformationBlockType12 associated with the discarded warningMessageSegment;

2> when the UE acquires SystemInformationBlockType1 following CMAS indication, upon entering a cell during RRC_IDLE, following successful handover and upon connection re-establishment:

3> if schedulingInfoList indicates that SystemInformationBlockType12 is present:

4> acquire SystemInformationBlockType12;

NOTE 3: UEs shall start acquiring SystemInformationBlockType12 as described above even when systemInfoValueTag in SystemInformationBlockType1 has not changed.

1> if the UE is interested to receive MBMS services:

2> if the UE is capable of MBMS reception as specified in 5.8:

3> if schedulingInfoList indicates that SystemInformationBlockType13 is present and the UE does not have stored a valid version of this system information block:

4> acquire SystemInformationBlockType13;

3> else if SystemInformationBlockType13 is present in SystemInformationBlockType1-MBMS and the UE does not have stored a valid version of this system information block:

4> acquire SystemInformationBlockType13 from SystemInformationBlockType1-MBMS;

2> if the UE is capable of SC-PTM reception as specified in 5.8a:

3> if schedulingInfoList indicates that SystemInformationBlockType20 (SystemInformationBlockType20-NB in NB-IoT) is present and the UE does not have stored a valid version of this system information block:

4> acquire SystemInformationBlockType20 (SystemInformationBlockType20-NB in NB-IoT);

2> if the UE is capable of MBMS Service Continuity:

3> if schedulingInfoList indicates that SystemInformationBlockType15 (SystemInformationBlockType15-NB in NB-IoT) is present and the UE does not have stored a valid version of this system information block:

4> acquire SystemInformationBlockType15 (SystemInformationBlockType15-NB in NB-IoT);

1> if the UE is EAB capable:

2> when the UE does not have stored a valid version of SystemInformationBlockType14 upon entering RRC_IDLE, or when the UE acquires SystemInformationBlockType1 following EAB parameters change notification, or upon entering a cell during RRC_IDLE, or before establishing an RRC connection if using eDRX with DRX cycle longer than the modification period:

3> if schedulingInfoList indicates that SystemInformationBlockType14 is present:

4> start acquiring SystemInformationBlockType14 immediately;

3> else:

4> discard SystemInformationBlockType14, if previously received;

NOTE 4: EAB capable UEs start acquiring SystemInformationBlockType14 as described above even when systemInfoValueTag in SystemInformationBlockType1 has not changed.

NOTE 5: EAB capable UEs maintain an up to date SystemInformationBlockType14 in RRC_IDLE.

1> if the UE is capable of sidelink communication and is configured by upper layers to receive or transmit sidelink communication:

2> if the cell used for sidelink communication meets the S-criteria as defined in TS 36.304 [4]; and

2> if schedulingInfoList indicates that SystemInformationBlockType18 is present and the UE does not have stored a valid version of this system information block:

3> acquire SystemInformationBlockType18;

1> if the UE is capable of sidelink discovery and is configured by upper layers to receive or transmit sidelink discovery announcements on the primary frequency:

2> if schedulingInfoList of the serving cell/ PCell indicates that SystemInformationBlockType19 is present and the UE does not have stored a valid version of this system information block:

3> acquire SystemInformationBlockType19;

1> if the UE is capable of sidelink discovery and, for each of the one or more frequencies included in discInterFreqList, if included in SystemInformationBlockType19 and for which the UE is configured by upper layers to receive sidelink discovery announcements on:

2> if SystemInformationBlockType19 of the serving cell/ PCell does not provide the corresponding reception resources; and

2> if schedulingInfoList of the cell on the concerned frequency indicates that SystemInformationBlockType19 is present and the UE does not have stored a valid version of this system information block:

3> acquire SystemInformationBlockType19;

1> if the UE is capable of sidelink discovery and, for each of the one or more frequencies included in discInterFreqList, if included in SystemInformationBlockType19 and for which the UE is configured by upper layers to transmit sidelink discovery announcements on:

2> if SystemInformationBlockType19 of the serving cell/ PCell includes discTxResourcesInterFreq which is set to acquireSI-FromCarrier; and

2> if schedulingInfoList of the cell on the concerned frequency indicates that SystemInformationBlockType19 is present and the UE does not have stored a valid version of this system information block:

3> acquire SystemInformationBlockType19;

1> if the UE is a NB-IoT UE and if ab-Enabled included in MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB is set to TRUE:

2> not initiate the RRC connection establishment/resume procedure for all access causes except mobile terminating calls until the UE has acquired the SystemInformationBlockType14NB;

1> if the UE is capable of V2X sidelink communication and is configured by upper layers to receive or transmit V2X sidelink communication on a frequency:

2> if schedulingInfoList on the serving cell/PCell indicates that SystemInformationBlockType21 is present and the UE does not have stored valid version of this system information block:

3> acquire SystemInformationBlockType21 from serving cell/PCell;

2> if schedulingInfoList on the serving cell/PCell indicates that SystemInformationBlockType26 is present and the UE does not have stored valid version of this system information block;

3> acquire SystemInformationBlockType26 from serving cell/PCell;

1> if the UE is capable of V2X sidelink communication and is configured by upper layers to receive V2X sidelink communication on a frequency, which is not primary frequency:

2> if neither SystemInformationBlockType21 nor SystemInformationBlockType26 of the serving cell/ PCell provide reception resource pool for V2X sidelink communication for the concerned frequency; and

2> if the cell used for V2X sidelink communication on the concerned frequency meets the S-criteria as defined in TS 36.304 [4]:

3> if schedulingInfoList on the concerned frequency indicates that SystemInformationBlockType21 is present and the UE does not have stored a valid version of this system information block:

4> acquire SystemInformationBlockType21 from the concerned frequency;

3> if schedulingInfoList on the concerned frequency indicates that SystemInformationBlockType26 is present and the UE does not have stored a valid version of this system information block:

4> acquire SystemInformationBlockType26 from the concerned frequency;

1> if the UE is capable of V2X sidelink communication and is configured by upper layers to transmit V2X sidelink communication on a frequency, which is not primary frequency and is not included in v2x-InterFreqInfoList in SystemInformationBlockType21 nor SystemInformationBlockType26 of the serving cell/PCell:

2> if the cell used for V2X sidelink communication on the concerned frequency meets the S-criteria as defined in TS 36.304 [4]:

3> if schedulingInfoList on the concerned frequency indicates that SystemInformationBlockType21 is present and the UE does not have stored a valid version of this system information block:

4> acquire SystemInformationBlockType21 from the concerned frequency;

3> if schedulingInfoList on the concerned frequency indicates that SystemInformationBlockType26 is present and the UE does not have stored a valid version of this system information block:

4> acquire SystemInformationBlockType26 from the concerned frequency;

1> if the NB-IoT UE supports NPRACH resources using preamble format 2:

2> if schedulingInfoList indicates that SystemInformationBlockType23-NB is present and the UE does not have stored a valid version of this system information block:

3> acquire SystemInformationBlockType23-NB;

1> following a request from positioning upper layers:

2> acquire SystemInformationBlockPos, as defined in 5.2.3;

The UE may apply the received SIBs or posSIBs immediately, i.e. the UE does not need to delay using a SIB or posSIB until all SI messages have been received. The UE may delay applying the received SIBs until completing lower layer procedures associated with a received or a UE originated RRC message, e.g. an ongoing random access procedure.

NOTE 6: While attempting to acquire a particular SIB/posSIB, if the UE detects from schedulingInfoList/ posSchedulingInfoList that it is no longer present, the UE should stop trying to acquire the particular SIB/ posSIB.

5.2.2.5 Essential system information missing

The UE shall:

1> if in RRC_IDLE, RRC_INACTIVE or in RRC_CONNECTED while T311 is running:

2> if the UE is unable to acquire the MasterInformationBlock (MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB in NB-IoT); or

2> if the UE is neither a BL UE nor in CE nor in NB-IoT and the UE is unable to acquire the SystemInformationBlockType1; or

2> if the BL UE or UE in CE is unable to acquire SystemInformationBlockType1-BR or SystemInformationBlockType1-BR is not scheduled; or

2> if the NB-IoT UE is unable to acquire the SystemInformationBlockType1-NB:

3> consider the cell as barred in accordance with TS 36.304 [4]; and

3> perform barring as if intraFreqReselection is set to allowed, and as if the csg-Indication is set to FALSE;

2> else:

3> if the UE is unable to acquire the SystemInformationBlockType2 (or SystemInformationBlockType2-NB in NB-IoT) and for NB-IoT, SystemInformationBlockType22-NB if scheduled; or

3> if SystemInformationBlockType25 is broadcast and if the UE is connected to 5GC and is unable to acquire the SystemInformationBlockType25:

4> treat the cell as barred in accordance with TS 36.304 [4];

5.2.2.6 Actions upon reception of the MasterInformationBlock message

Upon receiving the MasterInformationBlock message the UE shall:

1> apply the radio resource configuration included in the phich-Config;

1> if the UE is in RRC_IDLE or if the UE is in RRC_CONNECTED while T311 is running:

2> if the UE has no valid system information stored according to 5.2.2.3 for the concerned cell:

3> apply the received value of dl-Bandwidth to the ul-Bandwidth until SystemInformationBlockType2 is received;

Upon receiving the MasterInformationBlock-NB or MasterInformationBlock-TDD-NB message the UE shall:

1> apply the radio resource configuration included in accordance with the operationModeInfo.

No UE requirements related to the contents of MasterInformationBlock-MBMS apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.7 Actions upon reception of the SystemInformationBlockType1 message

Upon receiving the SystemInformationBlockType1 or SystemInformationBlockType1-BR either via broadcast or via dedicated signalling, the UE shall:

1> if the upper layers indicate the selected core network type as 5GC:

2> if the cellAccessRelatedInfoList-5GC contains an entry with the plmn-Identity or plmn-Index of the selected PLMN:

3> in the remainder of the procedures use plmn-IdentityList, trackingAreaCode, and cellIdentity for the cell as received in the corresponding cellAccessRelatedInfoList-5GC containing the selected PLMN;

1> else if the cellAccessRelatedInfoList contains an entry with the PLMN-Identity of the selected PLMN:

2> in the remainder of the procedures use plmn-IdentityList, trackingAreaCode, and cellIdentity for the cell as received in the corresponding cellAccessRelatedInfoList containing the selected PLMN;

1> if in RRC_IDLE or in RRC_CONNECTED while T311 is running; and

1> if the UE is a category 0 UE according to TS 36.306 [5]; and

1> if category0Allowed is not included in SystemInformationBlockType1:

2> consider the cell as barred in accordance with TS 36.304 [4];

1> if in RRC_CONNECTED while T311 is not running, and the UE supports multi-band cells as defined by bit 31 in featureGroupIndicators:

2> disregard the freqBandIndicator and multiBandInfoList, if received, while in RRC_CONNECTED;

2> forward the cellIdentity to upper layers;

2> forward the trackingAreaCode to upper layers;

1> else:

2> if the frequency band indicated in the freqBandIndicator is part of the frequency bands supported by the UE and it is not a downlink only band; or

2> if the UE supports multiBandInfoList, and if one or more of the frequency bands indicated in the multiBandInfoList are part of the frequency bands supported by the UE and they are not downlink only bands:

3> forward the cellIdentity to upper layers;

3> forward the trackingAreaCode to upper layers;

3> forward the PLMN identity to upper layers;

3> if in RRC_INACTIVE and the forwarded information does not trigger message transmission by upper layers:

4> if the serving cell does not belong to the configured ran-NotificationAreaInfo:

5> initiate an RNA update as specified in 5.3.17.2;

3> forward the ims-EmergencySupport to upper layers, if present;

3> forward the eCallOverIMS-Support to upper layers, if present;

3> if the UE is capable of 5G NAS:

4> forward the ims-EmergencySupport5GC to upper layers, if present;

4> forward the eCallOverIMS-Support5GC to upper layers, if present;

3> if, for the frequency band selected by the UE (from freqBandIndicator or multiBandInfoList), the freqBandInfo or the multiBandInfoList-v10j0 is present and the UE capable of multiNS-Pmax supports at least one additionalSpectrumEmission in the NS-PmaxList within the freqBandInfo or multiBandInfoList-v10j0:

4> apply the first listed additionalSpectrumEmission which it supports among the values included in NS-PmaxList within freqBandInfo or multiBandInfolist-v10j0;

4> if the additionalPmax is present in the same entry of the selected additionalSpectrumEmission within NS-PmaxList:

5> apply the additionalPmax;

4> else:

5> apply the p-Max;

3> else:

4> apply the additionalSpectrumEmission in SystemInformationBlockType2 and the p-Max;

2> else:

3> consider the cell as barred in accordance with TS 36.304 [4]; and

3> perform barring as if intraFreqReselection is set to notAllowed, and as if the csg-Indication is set to FALSE;

Upon receiving the SystemInformationBlockType1-NB, the UE shall:

1> if the frequency band indicated in the freqBandIndicator is part of the frequency bands supported by the UE; or

1> if one or more of the frequency bands indicated in the multiBandInfoList are part of the frequency bands supported by the UE:

2> forward the cellIdentity to upper layers;

2> forward the trackingAreaCode to upper layers;

2> if attachWithoutPDN-Connectivity is received for the selected PLMN:

3> forward the attachWithoutPDN-Connectivity to upper layers;

2> else

3> indicate to upper layers that attachWithoutPDN-Connectivity is not present;

2> if, for the frequency band selected by the UE (from freqBandIndicator or multiBandInfoList), the freqBandInfo is present and the UE capable of multiNS-Pmax supports at least one additionalSpectrumEmission in the NS-PmaxList within the freqBandInfo:

3> apply the first listed additionalSpectrumEmission which it supports among the values included in NS-PmaxList within freqBandInfo;

3> if the additionalPmax is present in the same entry of the selected additionalSpectrumEmission within NS-PmaxList:

4> apply the additionalPmax;

3> else:

4> apply the p-Max;

2> else:

3> apply the additionalSpectrumEmission in SystemInformationBlockType2-NB and the p-Max;

1> else:

2> consider the cell as barred in accordance with TS 36.304 [4]; and

2> perform barring as if intraFreqReselection is set to notAllowed.

No UE requirements related to the contents of SystemInformationBlockType1-MBMS apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.8 Actions upon reception of SystemInformation messages

No UE requirements related to the contents of the SystemInformation messages apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.9 Actions upon reception of SystemInformationBlockType2

Upon receiving SystemInformationBlockType2, the UE shall:

1> apply the configuration included in the radioResourceConfigCommon;

1> if in RRC_INACTIVE:

2> apply the shortest of the ran-PagingCycle (if configured), the (UE specific) paging cycle (if indicated by upper layers), and the defaultPagingCycle included in the radioResourceConfigCommon;

1> else if upper layers indicate that a (UE specific) paging cycle is configured:

2> apply the shortest of the (UE specific) paging cycle and the defaultPagingCycle included in the radioResourceConfigCommon;

1> if the mbsfn-SubframeConfigList is included:

2> consider that DL assignments may occur in the MBSFN subframes indicated in the mbsfn-SubframeConfigList under the conditions specified in TS 36.213 [23], clause 7.1;

1> apply the specified PCCH configuration defined in 9.1.1.3;

1> not apply the timeAlignmentTimerCommon;

1> if in RRC_CONNECTED and UE is configured with RLF timers and constants values received within rlf-TimersAndConstants:

2> not update its values of the timers and constants in ue-TimersAndConstants except for the value of timer T300;

1> if in RRC_CONNECTED while T311 is not running; and the UE supports multi-band cells as defined by bit 31 in featureGroupIndicators or multipleNS-Pmax:

2> disregard the additionalSpectrumEmission and ul-CarrierFreq, if received, while in RRC_CONNECTED;

1> if attachWithoutPDN-Connectivity is received for the selected PLMN:

2> forward attachWithoutPDN-Connectivity to upper layers;

1> else:

2> indicate to upper layers that attachWithoutPDN-Connectivity is not present;

1> if cp-CIoT-EPS-Optimisation is received for the selected PLMN:

2> forward cp-CIoT-EPS-Optimisation to upper layers;

1> else:

2> indicate to upper layers that cp-CIoT-EPS-Optimisation is not present;

1> if up-CIoT-EPS-Optimisation is received for the selected PLMN:

2> forward up-CIoT-EPS-Optimisation to upper layers;

1> else:

2> indicate to upper layers that up-CIoT-EPS-Optimisation is not present;

1> to upper layers either forward upperLayerIndication, if present for the selected PLMN, or otherwise indicate absence of this field;

NOTE: upperLayerIndication is an indication to upper layers that the UE has entered a coverage area that offers 5G capabilities.

Upon receiving SystemInformationBlockType2-NB, the UE shall:

1> apply the configuration included in the radioResourceConfigCommon;

1> apply the defaultPagingCycle included in the radioResourceConfigCommon;

1> if SystemInformationBlockType22-NB is scheduled:

2> read and act on information sent in SystemInformationBlockType22-NB;

1> apply the specified PCCH configuration defined in 9.1.1.3.

1> if in RRC_CONNECTED and UE is configured with RLF timers and constants values received within rlf-TimersAndConstants:

2> not update its values of the timers and constants in ue-TimersAndConstants except for the value of timer T300;

5.2.2.10 Actions upon reception of SystemInformationBlockType3

Upon receiving SystemInformationBlockType3, the UE shall:

1> if in RRC_IDLE, the redistributionServingInfo is included and the UE is redistribution capable:

2> perform E-UTRAN inter-frequency redistribution procedure as specified in TS 36.304 [4], clause 5.2.4.10;

1> if in RRC_IDLE, or in RRC_CONNECTED while T311 is running:

2> if, for the frequency band selected by the UE (from the procedure in clause 5.2.2.7) to represent the serving cell’s carrier frequency, the freqBandInfo or the multiBandInfoList-v10j0 is present in SystemInformationBlockType3 and the UE capable of multiNS-Pmax supports at least one additionalSpectrumEmission in the NS-PmaxList within the freqBandInfo or multiBandInfoList-v10j0:

3> apply the first listed additionalSpectrumEmission which it supports among the values included in NS-PmaxList within freqBandInfo or multiBandInfoList-v10j0;

3> if the additionalPmax is present in the same entry of the selected additionalSpectrumEmission within NS-PmaxList:

4> apply the additionalPmax;

3> else:

4> apply the p-Max;

2> else:

3> apply the p-Max;

Upon receiving SystemInformationBlockType3-NB, the UE shall:

1> if in RRC_IDLE, or in RRC_CONNECTED while T311 is running:

2> if, for the frequency band selected by the UE (from the procedure in clause 5.2.2.7) to represent the serving cell’s carrier frequency, the freqBandInfo or the multiBandInfoList is present in SystemInformationBlockType3-NB and the UE capable of multiNS-Pmax supports at least one additionalSpectrumEmission in the NS-PmaxList within the freqBandInfo or the multiBandInfoList:

3> apply the first listed additionalSpectrumEmission which it supports among the values included in NS-PmaxList within freqBandInfo or multiBandInfoList;

3> if the additionalPmax is present in the same entry of the selected additionalSpectrumEmission within NS-PmaxList:

4> apply the additionalPmax;

3> else:

4> apply the p-Max;

2> else:

3> apply the p-Max;

5.2.2.11 Actions upon reception of SystemInformationBlockType4

No UE requirements related to the contents of this SystemInformationBlock (SystemInformationBlockType4 or SystemInformationBlockType4-NB) apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.12 Actions upon reception of SystemInformationBlockType5

Upon receiving SystemInformationBlockType5, the UE shall:

1> if in RRC_IDLE, the redistributionInterFreqInfo is included and the UE is redistribution capable:

2> perform E-UTRAN inter-frequency redistribution procedure as specified in TS 36.304 [4], clause 5.2.4.10;

1> if in RRC_IDLE, or in RRC_CONNECTED while T311 is running:

2> if the frequency band selected by the UE to represent a non-serving E UTRA carrier frequency is not a downlink only band:

3> if, for the selected frequency band, the freqBandInfo or the multiBandInfoList-v10j0 is present and the UE capable of multiNS-Pmax supports at least one additionalSpectrumEmission in the NS-PmaxList within freqBandInfo or multiBandInfoList-v10j0:

4> apply the first listed additionalSpectrumEmission which it supports among the values included in NS-PmaxList within freqBandInfo or multiBandInfoList-v10j0;

4> if the additionalPmax is present in the same entry of the selected additionalSpectrumEmission within NS-PmaxList:

5> apply the additionalPmax;

4> else:

5> apply the p-Max;

3> else:

4> apply the p-Max;

1> if in RRC_IDLE or RRC_INACTIVE and UE has stored VarMeasIdleConfig and the UE is capable of IDLE mode measurements for CA:

2> if T331 is running and VarMeasIdleConfig does not contain measIdleCarrierListEUTRA received from the RRCConnectionRelease message:

3> if SIB5 includes the measIdleConfigSIB:

4> store or replace the measIdleCarrierListEUTRA of measIdleConfigSIB within VarMeasIdleConfig;

3> else:

4> remove the measIdleCarrierListEUTRA in VarMeasIdleConfig, if stored;

2> perform idle mode measurements as specified in 5.6.20;

Upon receiving SystemInformationBlockType5-NB, the UE shall:

1> if in RRC_IDLE, or in RRC_CONNECTED while T311 is running:

2> if, for the frequency band selected by the UE (from multiBandInfoList) to represent a non-serving NB-IoT carrier frequency, the freqBandInfo is present and the UE capable of multiNS-Pmax supports at least one additionalSpectrumEmission in the NS-PmaxList within the freqBandInfo:

3> apply the first listed additionalSpectrumEmission which it supports among the values included in NS-PmaxList within freqBandInfo;

3> if the additionalPmax is present in the same entry of the selected additionalSpectrumEmission within NS-PmaxList:

4> apply the additionalPmax;

3> else:

4> apply the p-Max;

2> else:

3> apply the p-Max;

5.2.2.13 Actions upon reception of SystemInformationBlockType6

No UE requirements related to the contents of this SystemInformationBlock apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.14 Actions upon reception of SystemInformationBlockType7

No UE requirements related to the contents of this SystemInformationBlock apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.15 Actions upon reception of SystemInformationBlockType8

Upon receiving SystemInformationBlockType8, the UE shall:

1> if sib8-PerPLMN-List is included and the UE is capable of network sharing for CDMA2000:

2> apply the CDMA2000 parameters below corresponding to the RPLMN;

1> if the systemTimeInfo is included:

2> forward the systemTimeInfo to CDMA2000 upper layers;

1> if the UE is in RRC_IDLE and if searchWindowSize is included:

2> forward the searchWindowSize to CDMA2000 upper layers;

1> if parametersHRPD is included:

2> forward the preRegistrationInfoHRPD to CDMA2000 upper layers only if the UE has not received the preRegistrationInfoHRPD within an RRCConnectionReconfiguration message after entering this cell;

2> if the cellReselectionParametersHRPD is included:

3> forward the neighCellList to the CDMA2000 upper layers;

1> if the parameters1XRTT is included:

2> if the csfb-RegistrationParam1XRTT is included:

3> forward the csfb-RegistrationParam1XRTT to the CDMA2000 upper layers which will use this information to determine if a CS registration/re-registration towards CDMA2000 1xRTT in the EUTRA cell is required;

2> else:

3> indicate to CDMA2000 upper layers that CSFB Registration to CDMA2000 1xRTT is not allowed;

2> if the longCodeState1XRTT is included:

3> forward the longCodeState1XRTT to CDMA2000 upper layers;

2> if the cellReselectionParameters1XRTT is included:

3> forward the neighCellList to the CDMA2000 upper layers;

2> if the csfb-SupportForDualRxUEs is included:

3> forward csfb-SupportForDualRxUEs to the CDMA2000 upper layers;

2> else:

3> forward csfb-SupportForDualRxUEs, with its value set to FALSE, to the CDMA2000 upper layers;

2> if ac-BarringConfig1XRTT is included:

3> forward ac-BarringConfig1XRTT to the CDMA2000 upper layers;

2> if the csfb-DualRxTxSupport is included:

3> forward csfb-DualRxTxSupport to the CDMA2000 upper layers;

2> else:

3> forward csfb-DualRxTxSupport, with its value set to FALSE, to the CDMA2000 upper layers;

5.2.2.16 Actions upon reception of SystemInformationBlockType9

Upon receiving SystemInformationBlockType9, the UE shall:

1> if hnb-Name is included, forward the hnb-Name to upper layers;

5.2.2.17 Actions upon reception of SystemInformationBlockType10

Upon receiving SystemInformationBlockType10, the UE shall:

1> forward the received warningType, messageIdentifier and serialNumber to upper layers;

5.2.2.18 Actions upon reception of SystemInformationBlockType11

Upon receiving SystemInformationBlockType11, the UE shall:

1> if there is no current value for messageIdentifier and serialNumber for SystemInformationBlockType11; or

1> if either the received value of messageIdentifier or of serialNumber or of both are different from the current values of messageIdentifier and serialNumber for SystemInformationBlockType11:

2> use the received values of messageIdentifier and serialNumber for SystemInformationBlockType11 as the current values of messageIdentifier and serialNumber for SystemInformationBlockType11;

2> discard any previously buffered warningMessageSegment;

2> if all segments of a warning message have been received:

3> assemble the warning message from the received warningMessageSegment;

3> forward the received warning message, messageIdentifier, serialNumber and dataCodingScheme to upper layers;

3> stop reception of SystemInformationBlockType11;

3> discard the current values of messageIdentifier and serialNumber for SystemInformationBlockType11;

2> else:

3> store the received warningMessageSegment;

3> continue reception of SystemInformationBlockType11;

1> else if all segments of a warning message have been received:

2> assemble the warning message from the received warningMessageSegment;

2> forward the received complete warning message, messageIdentifier, serialNumber and dataCodingScheme to upper layers;

2> stop reception of SystemInformationBlockType11;

2> discard the current values of messageIdentifier and serialNumber for SystemInformationBlockType11;

1> else:

2> store the received warningMessageSegment;

2> continue reception of SystemInformationBlockType11;

The UE should discard any stored warningMessageSegment and the current value of messageIdentifier and serialNumber for SystemInformationBlockType11 if the complete warning message has not been assembled within a period of 3 hours.

5.2.2.19 Actions upon reception of SystemInformationBlockType12

Upon receiving SystemInformationBlockType12, the UE shall:

1> if the SystemInformationBlockType12 contains a complete warning message and the complete geographical area coordinates (if any):

2> forward the received warning message, messageIdentifier, serialNumber, dataCodingScheme and the geographical area coordinates (if any) to upper layers;

2> continue reception of SystemInformationBlockType12;

1> else:

2> if the received values of messageIdentifier and serialNumber are the same (each value is the same) as a pair for which a warning message and the geographical area coordinates (if any) are currently being assembled:

3> store the received warningMessageSegment;

3> store the received warningAreaCoordinatesSegment (if any);

3> if all segments of a warning message and geographical area coordinates (if any) have been received:

4> assemble the warning message from the received warningMessageSegment;

4> assemble the geographical area coordinates from the received warningAreaCoordinatesSegment (if any);

4> forward the received warning message, messageIdentifier, serialNumber, dataCodingScheme and geographical area coordinates (if any) to upper layers;

4> stop assembling a warning message and warning area coordinates (if any) for this messageIdentifier and serialNumber and delete all stored information held for it;

3> continue reception of SystemInformationBlockType12;

2> else if the received values of messageIdentifier and/or serialNumber are not the same as any of the pairs for which a warning message is currently being assembled:

3> start assembling a warning message for this messageIdentifier and serialNumber pair;

3> start assembling the geographical area coordinates (if any) for this messageIdentifier and serialNumber pair;

3> store the received warningMessageSegment;

3> store the received warningAreaCoordinatesSegment (if any);

3> continue reception of SystemInformationBlockType12;

The UE should discard warningMessageSegment and warningAreaCoordinatesSegment (if any) and the associated values of messageIdentifier and serialNumber for SystemInformationBlockType12 if the complete warning message and the warning area coordinates (if any) have not been assembled within a period of 3 hours.

NOTE: The number of warning messages that a UE can re-assemble simultaneously is a function of UE implementation.

5.2.2.20 Actions upon reception of SystemInformationBlockType13

No UE requirements related to the contents of this SystemInformationBlock apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.21 Actions upon reception of SystemInformationBlockType14

No UE requirements related to the contents of this SystemInformationBlock (SystemInformationBlockType14 or SystemInformationBlockType14-NB) apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.22 Actions upon reception of SystemInformationBlockType15

No UE requirements related to the contents of this SystemInformationBlock (SystemInformationBlockType15 or SystemInformationBlockType15-NB) apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.23 Actions upon reception of SystemInformationBlockType16

Upon receiving SystemInformationBlockType16 with timeReferenceInfo, the UE may perform the related actions as specified in clause 5.6.1.3.

5.2.2.24 Actions upon reception of SystemInformationBlockType17

Upon receiving SystemInformationBlockType17, the UE shall:

1> if wlan-OffloadConfigCommon corresponding to the RPLMN is included:

2> if the UE is not configured with rclwi-Configuration with command set to steerToWLAN:

3> apply the wlan-Id-List corresponding to the RPLMN;

2> if not configured with the wlan-OffloadConfigDedicated:

3> apply the wlan-OffloadConfigCommon corresponding to the RPLMN;

5.2.2.25 Actions upon reception of SystemInformationBlockType18

Upon receiving SystemInformationBlockType18, the UE shall:

1> if SystemInformationBlockType18 message includes the commConfig:

2> if configured to receive sidelink communication:

3> from the next SC period, as defined by sc-Period, use the resource pool indicated by commRxPool for sidelink communication monitoring, as specified in 5.10.3;

2> if configured to transmit sidelink communication:

3> from the next SC period, as defined by sc-Period, use the resource pool indicated by commTxPoolNormalCommon, commTxPoolNormalCommonExt or by commTxPoolExceptional for sidelink communication transmission, as specified in 5.10.4;

5.2.2.26 Actions upon reception of SystemInformationBlockType19

Upon receiving SystemInformationBlockType19, the UE shall:

1> if SystemInformationBlockType19 message includes the discConfig or discConfigPS:

2> from the next discovery period, as defined by discPeriod, use the resources indicated by discRxPool, discRxResourcesInterFreq or discRxPoolPS for sidelink discovery monitoring, as specified in 5.10.5;

2> if SystemInformationBlockType19 message includes the discTxPoolCommon or discTxPoolPS-Common; and the UE is in RRC_IDLE:

3> from the next discovery period, as defined by discPeriod, use the resources indicated by discTxPoolCommon or discTxPoolPS-Common for sidelink discovery announcement, as specified in 5.10.6;

2> if the SystemInformationBlockType19 message includes the discTxPowerInfo:

3> use the power information included in discTxPowerInfo for sidelink discovery transmission on the serving frequency, as specified in TS 36.213 [23];

1> if SystemInformationBlockType19 message includes the discConfigRelay:

2> if the SystemInformationBlockType19 message includes the txPowerInfo:

3> use the power information included in txPowerInfo for sidelink discovery transmission on the corresponding non-serving frequency, as specified in TS 36.213 [23];

5.2.2.27 Actions upon reception of SystemInformationBlockType20

No UE requirements related to the contents of this SystemInformationBlock (SystemInformationBlockType20 or SystemInformationBlockType20-NB) apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.28 Actions upon reception of SystemInformationBlockType21

Upon receiving SystemInformationBlockType21, the UE shall:

1> if SystemInformationBlockType21 message includes sl-V2X-ConfigCommon:

2> if configured to receive V2X sidelink communication:

3> use the resource pool indicated by v2x-CommRxPool in sl-V2X-ConfigCommon for V2X sidelink communication monitoring, as specified in 5.10.12;

2> if configured to transmit V2X sidelink communication:

3> use the resource pool indicated by v2x-CommTxPoolNormalCommon, p2x-CommTxPoolNormalCommon, v2x-CommTxPoolNormal, p2x-CommTxPoolNormal or by v2x-CommTxPoolExceptional for V2X sidelink communication transmission, as specified in 5.10.13;

3> perform CBR measurement on the transmission resource pool(s) indicated by v2x-CommTxPoolNormalCommon, v2x-CommTxPoolNormal and v2x-CommTxPoolExceptional for V2X sidelink communication transmission, as specified in 5.5.3;

5.2.2.29 Actions upon reception of SystemInformationBlockType22-NB

No UE requirements related to the contents of this SystemInformationBlock apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.30 Actions upon reception of SystemInformationBlockType23-NB

No UE requirements related to the contents of this SystemInformationBlock apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.31 Actions upon reception of SystemInformationBlockType24

No UE requirements related to the contents of this SystemInformationBlock apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.32 Actions upon reception of SystemInformationBlockType25

No UE requirements related to the contents of this SystemInformationBlock apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

5.2.2.33 Actions upon reception of SystemInformationBlockType26

Upon receiving SystemInformationBlockType26, the UE shall:

1> if configured to receive V2X sidelink communication:

2> use the resource pool indicated by v2x-CommRxPool for V2X sidelink communication monitoring, as specified in 5.10.12;

1> if configured to transmit V2X sidelink communication:

2> use the resource pool indicated by v2x-CommTxPoolNormal, p2x-CommTxPoolNormal or by v2x-CommTxPoolExceptional for V2X sidelink communication transmission, as specified in 5.10.13;

2> perform CBR measurement on the transmission resource pool(s) indicated by v2x-CommTxPoolNormal and v2x-CommTxPoolExceptional for V2X sidelink communication transmission, as specified in 5.5.3;

5.2.2.34 Actions upon reception of SystemInformationBlockPos

No UE requirements related to the contents of the SystemInformationBlockPos apply other than those specified elsewhere e.g. within TS 36.355 [54], and/or within the corresponding field descriptions.

5.2.3 Acquisition of an SI message

When acquiring an SI message, the UE shall:

1> determine the start of the SI-window for the concerned SI message as follows:

2> if the concerned SI message is configured in the schedulingInfoList, schedulingInfoListExt (if present) or if the concerned SI message is configured in the posSchedulingInfoList and si-posOffset is not configured;

3> for the concerned SI message, determine the number n which corresponds to the order of entry in the concatenated list of SI messages configured by schedulingInfoList, schedulingInfoListExt (if present) and posSchedulingInfoList in SystemInformationBlockType1;

3> determine the integer value x = (n – 1)*w, where w is the si-WindowLength;

3> the SI-window starts at the subframe #a, where a = x mod 10, in the radio frame for which SFN mod T = FLOOR(x/10), where T is the si-Periodicity or the posSI-Periodicity of the concerned SI message;

2> else if the concerned SI message is configured by the posSchedulingInfoList and si-posOffset is configured determine the start of the SI-window for the concerned SI message as follows:

3> determine the number m which corresponds to the number of SI messages with an associated si-Periodicity of 8 radio frames (80 ms), configured by schedulingInfoList and schedulingInfoListExt (if present) in SystemInformationBlockType1;

3> for the concerned SI message, determine the number n which corresponds to the order of entry in the list of SI messages configured by posSchedulingInfoList in SystemInformationBlockType1;

3> determine the integer value x = m*w + (n – 1)*w, where w is the si-WindowLength

3> the SI-window starts at the subframe #a, where a = x mod 10, in the radio frame for which SFN mod T = FLOOR(x/10) + 8, where T is the posSI-Periodicity of the concerned SI message;

NOTE: E-UTRAN should configure an SI-window of 1 ms only if all SIs are scheduled before subframe #5 in radio frames for which SFN mod 2 = 0.

1> receive DL-SCH using the SI-RNTI from the start of the SI-window and continue until the end of the SI-window whose absolute length in time is given by si-WindowLength, or until the SI message was received, excluding the following subframes:

2> subframe #5 in radio frames for which SFN mod 2 = 0;

2> any MBSFN subframes;

2> any uplink subframes in TDD;

1> if the SI message was not received by the end of the SI-window, repeat reception at the next SI-window occasion for the concerned SI message;

5.2.3a Acquisition of an SI message by BL UE or UE in CE or a NB-IoT UE

When acquiring an SI message, the BL UE or UE in CE or NB-IoT UE shall:

1> determine the start of the SI-window for the concerned SI message as follows:

2> if the concerned SI message is configured in the schedulingInfoList, schedulingInfoListExt (if present) or if the concerned SI message is configured in the posSchedulingInfoList and si-posOffset is not configured;

3> for the concerned SI message, determine the number n which corresponds to the order of entry in the concatenated list of SI messages configured by schedulingInfoList, schedulingInfoListExt (if present) in SystemInformationBlockType1-BR (or SystemInformationBlockType1-NB in NB-IoT) and posSchedulingInfoList in SystemInformationBlockType1-BR;

3> determine the integer value x = (n – 1)*w, where w is the si-WindowLength-BR (or si-WindowLength in NB-IoT);

3> if the UE is a NB-IoT UE:

4> the SI-window starts at the subframe #0 in the radio frame for which (H-SFN * 1024 + SFN) mod T = FLOOR(x/10) + Offset, where T is the si-Periodicity of the concerned SI message and, Offset is the offset of the start of the SI-Window (si-RadioFrameOffset);

3> else:

4> the SI-window starts at the subframe #0 in the radio frame for which SFN mod T = FLOOR(x/10), where T is the si-Periodicity or the posSI-Periodicity of the concerned SI message;

2> else if the concerned SI message is configured by the posSchedulingInfoList and si-posOffset is configured determine the start of the SI-window for the concerned SI message as follows:

3> determine the number m which corresponds to the number of SI messages with an associated si-Periodicity of 8 radio frames (80 ms), configured by schedulingInfoList and schedulingInfoListExt (if present) in SystemInformationBlockType1-BR;

3> for the concerned SI message, determine the number n which corresponds to the order of entry in the list of SI messages configured by posSchedulingInfoList in SystemInformationBlockType1-BR;

3> determine the integer value x = m*w + (n – 1)*w, where w is the si-WindowLength-BR;

3> the SI-window starts at the subframe #0 in the radio frame for which SFN mod T = FLOOR(x/10) + 8, where T is the posSI-Periodicity of the concerned SI message;

1> if the UE is a NB-IoT UE:

2> receive and accumulate SI message transmissions on DL-SCH from the start of the SI-window and continue until the end of the SI-window whose absolute length in time is given by si-WindowLength, starting from the radio frames as provided in si-RepetitionPattern and in subframes as provided in downlinkBitmap, or until successful decoding of the accumulated SI message transmissions excluding the subframes used for transmission of NPSS, NSSS, MasterInformationBlock-NB/ MasterInformationBlock-TDD-NB and SystemInformationBlockType1-NB. If there are not enough subframes for one SI message transmission in the radio frames as provided in si-RepetitionPattern, the UE shall continue to receive the SI message transmission in the radio frames following the radio frame indicated in si-RepetitionPattern;

1> else:

2> receive and accumulate SI message transmissions on DL-SCH on narrowband provided by si-Narrowband, from the start of the SI-window and continue until the end of the SI-window whose absolute length in time is given by si-WindowLength-BR, only in radio frames as provided in si-RepetitionPattern and subframes as provided in fdd-DownlinkOrTddSubframeBitmapBR in bandwidthReducedAccessRelatedInfo, or until successful decoding of the accumulated SI message transmissions;

1> if the SI message was not possible to decode from the accumulated SI message transmissions by the end of the SI-window, continue reception and accumulation of SI message transmissions on DL-SCH in the next SI-window occasion for the concerned SI message;

5.2.3b Acquisition of an SI message from MBMS-dedicated cell

When acquiring an SI message, the UE shall:

1> determine the start of the SI-window for the concerned SI message as follows:

2> for the concerned SI message, determine the number n which corresponds to the order of entry in the list of SI messages configured by schedulingInfoList in SystemInformationBlockType1-MBMS;

2> determine the integer value x = (n – 1)*w, where w is the si-WindowLength;

2> the SI-window starts always at the subframe #a, where a = x mod 10, in the radio frame for which SFN mod T = FLOOR(x/10), where T is the si-Periodicity of the concerned SI message;

1> receive DL-SCH using SI-RNTI with value in accordance with 36.321 [6] from the start of the SI-window and continue until the end of the SI-window whose absolute length in time is given by si-WindowLength, or until the SI message was received, excluding the following subframes:

2> any MBSFN subframes;

1> if the SI message was not received by the end of the SI-window, repeat reception at the next SI-window occasion for the concerned SI message;