第2章系统信息（System Information）

小区搜索过程之后，UE已经与小区取得下行同步，得到小区的PCI（Physical Cell ID）以及检测到系统帧的timing（即10ms timing）。接着，UE需要获取到小区的系统信息（System Information），这样才能知道该小区是如何配置的，以便接入该小区并在该小区内正确地工作。小区会不断地广播这些系统信息。

系统信息是小区级别的信息，即对接入该小区的所有UE生效。系统信息可分为MasterInformationBlock（MIB）和多个SystemInformationBlock（SIB），每个系统信息包含了与某个功能相关的一系列参数集合。系统信息类型包括：

表2.1：系统信息类型

并不是所有的SIB都必须存在。例如对于运营商部署的基站而言，就不需要SIB9；如果某小区不提供MBMS，就不需要SIB13。

有3种类型的RRC消息用于传输系统信息：MIB消息、SIB1消息、一个或多个SI消息。

图2.1：3类用于发送系统信息的RRC消息

小区是通过逻辑信道BCCH向该小区内的所有UE发送系统信息的。

从图2.2、图2.3、图2.4可以看出，逻辑信道BCCH会映射到传输信道BCH和DL-SCH。其中，BCH只用于传输MIB信息，并映射到物理信道PBCH；DL-SCH用于传输各种SIB信息，并映射到物理信道PDSCH。

图2.2：下行信道匹配

图2.3：从RRC信令中可以看出：MIB在BCH上传输

图2.4：从RRC信令中可以看出：SIB在DL-SCH上传输

2.1 MIB

对于MIB而言，除了RRC消息（MasterInformationBlock）里所带的信息外，它还有额外一些信息要告诉UE。本节所要介绍的，就是小区会通过MIB告诉UE哪些信息，以及UE是如何检测到这些信息的。

UE通过检测PBCH，能得到以下信息：

（1）通过接收到的MasterInformationBlock可以知道小区的下行系统带宽、PHICH配置（详见《LTE：PHICH（一）》）、系统帧号（System Frame Number，SFN。更确切地说，获取到的是SFN的高8位，最低2位需要在PBCH盲检时得到，这会在后面介绍）。

（2）小区特定的天线端口（cell-specific antenna port）的数目：1或2或4。

（3）用于L1/L2 control signal（包括PCFICH、PHICH、PDCCH）的传输分集模式（transmit-diversity scheme）：PBCH和L1/L2 control signal都只能使用单天线传输或传输分集，如果使用传输分集， PBCH和L1/L2 control signal会使用相同的多天线传输分集模式。

从图2.2可以看出，MIB会在物理信道PBCH上传输。PBCH时域上位于每个系统帧的子帧0的第2个slot的前4个OFDM symbol上，并在频域上占据72个中心子载波（不含DC）。对应RE不能用于发送DL-SCH数据。如图2.5所示。

图2.5：BCH传输信道的资源映射

把BCH传输限制在72个中心的子载波，而不考虑小区的下行系统带宽的原因在于：UE在接收BCH时并不知道小区的下行系统带宽。因此UE在第一次接收BCH时，可以假定小区的下行系统带宽等于可能的最小下行系统带宽（6个RB，对应72个子载波）。在解码了MIB后，UE就能从MIB中得到实际的下行系统带宽。

MIB在40ms周期内重复4次，每一次发送的PBCH都携带相同的coded bit，也就是说，每一次都是可以独自解码的。因此，在信道质量（SIR）足够好的情况下，UE可能只接收这40ms内的其中一个，就能够成功解码出PBCH的内容；如果不行，就与下一个10ms发送的PBCH的内容进行软合并，再进行解码，直到成功解码出PBCH。

图2.6：MIB在时域上的调度

前面已经说过，通过MIB，UE只能获取到SFN的高8位，最低2位（也就是40ms timing）是通过盲检PBCH得到的。40ms内每次发送的PBCH会使用不同scrambling and bit position（即共有4个不同的phase of the PBCH scrambling code），并且每40ms会重置一次。

UE可以通过使用4个可能的phase of the PBCH scrambling code中的每一个去尝试解码PBCH，如果解码成功，也就知道了小区是在40ms内的第几个系统帧发送MIB，即知道了SFN的最低2位。（[2]和[6]中介绍了检测SFN最低2位的几种策略，有兴趣的可以了解一下）

PBCH的多天线传输只能使用传输分集，而且在2天线端口传输时，只能使用SFBC；4天线端口传输时，只能使用combined SFBC/FSTD。UE使用3种不同的CRC mask（见36.212的Table 5.3.1.1-1）来盲检PBCH，可得到天线端口数目，而天线端口数目与传输分集模式一一对应（1天线端口 <-> 单天线端口传输；2天线端口 <-> SFBC；4天线端口 <-> combined SFBC/FSTD），因此当UE成功解码PBCH时，就知道了小区特定的天线端口数以及用于L1/L2 control signal的传输分集模式。（关于SFBC、FSTD的说明，详见[1]的5.4.1.4节和10.3.1.2节）

Table 5.3.1.1-1: CRC mask for PBCH.

Number of transmit antenna ports at eNodeB	PBCH CRC mask
1	<0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0>
2	<1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1>
4	<0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1>

PBCH有3种天线端口组合（1/2/4）和4种不同扰码（phase）组合，所以做盲检PBCH最多有12种可能组合。

图2.7给出了MIB在物理层的编码处理和映射流程。

图2.7：PBCH结构

2.2 SIB

在BCH中传输的MIB只包含非常有限的系统信息。而更多的系统信息是通过在DL-SCH中传输的SIB来告诉UE的。

对于各类SIB而言，RRC消息里所带的信息就是其要告诉UE的所有信息。各类SIB的内容可以参见36.331中对应的RRC消息。

与MIB所在的时频位置固定不同，SIB1和SI消息都在PDSCH上传输，且SIB1和SI消息所占的RB（频域上的位置）及其传输格式等是动态调度的，并由SI-RNTI加扰的PDCCH来指示。也就是说，UE需要先在子帧上盲检使用SI-RNTI加扰的PDCCH，才能知道该子帧是否存在SI消息（SIB1在时域上的位置固定）。小区可以根据具体情况灵活地改变SIB1和SI所占的带宽、使用的RB集合以及传输格式等。

SIB1的周期为80ms，且在该周期内SFN % 2 = 0的系统帧的子帧5上重复发送同一SIB1。SIB1在时域上的位置是固定的，但在频域上的位置可能发生变化，并由对应的PDCCH来指示。

图2.8：SIB1在时域上的调度

每个SI消息包含了一个或多个除SIB1外的拥有相同调度需求的SIB（这些SIB有相同的传输周期）。例如：2个传输周期都是160ms的SIB（如图2.10中的SIB2和SIB3）可以放在同一个SI消息中，但传输周期为320ms的其它SIB（如图2.10中的SIB4和SIB5）必须放在不同的SI消息中。

单个SI消息中包含的信息比特不能超过一个TB块所能传输的最大比特数。

物理层限制了1个SIB（个人觉得更好的描述是SI和SIB1）的最大size。如果使用DCI format 1C，则最大size为1736 bit（217 byte）；如果使用DCI format 1A，则最大size为2216 bit（277 byte）。

一个SI消息包含哪些SIB是通过SIB1中的schedulingInfoList指定的。每个SIB只能包含在一个SI消息中，且SIB2总是放在schedulingInfoList指定的SI列表的第一个SI消息项中，所以schedulingInfoList中并不指定SIB2所在的SI。

图2.9：SIB1信息（包含了SI的调度信息）

每个SI消息只在一个SI窗口（SI-windows）中传输：1）一个SI消息跟一个SI窗口相关联，该SI窗口内只能发这个SI消息且可以重复发送多次（发多少次，在哪些子帧上发送等，取决于eNodeB的实现），但不能发送其它SI消息；2）SI窗口之间是紧挨着的（如果相邻的话），既不重叠，也不会有空隙；3）所有SI消息的SI窗口长度都相同；4）不同SI消息的周期是相互独立的。

前面我们已经介绍过MIB和SIB1的时域调度，接下来我们会详细介绍SI消息的时域调度。

首先需要确认每个SI消息对应的SI窗口的起始位置以及SI窗口的长度。

SI窗口的长度由SystemInformationBlockType1的si-WindowLength字段指定，其以ms为单位。

SystemInformationBlockType1的schedulingInfoList指定了SI消息的列表，每个SI消息在该列表中的顺序以n表示（从1开始）。假如schedulingInfoList中指定了4个SI消息，则会有4个连续的SI窗口用于发送这4个SI消息，而n表明了SI消息在第几个SI窗口。

此时每个SI消息有一个x = (n - 1) * w，其中w为si-WindowLength。可以看出，x是以ms为单位的。

则SI窗口的起始帧满足SFN % T = FLOOR(x / 10)，其中T为对应SI消息的周期，由si-Periodicity指定。SFN % T保证了SI的周期，FLOOR(x / 10)确定SI窗口在周期内的起始系统帧（一个系统帧为10ms，所以有x / 10）。

SI窗口的起始子帧为#a，其中a = x % 10。

从公式可以看出，x决定了SI窗口在该SI周期内的起始帧和起始子帧； SFN % T保证了SI窗口在SI周期内只出现一次；而x = (n - 1) * w保证了SI窗口之间紧挨（如果相邻的话），不重叠，没有空隙。(SI窗口起始帧和起始子帧的的计算，详见36.331的5.2.3节)

SI窗口确定了以后，eNodeB会决定在该窗口内调度多少次同一SI，不同厂商的实现可能不同。但某些子帧不能用于调度SI消息：

SFN % 2 = 0的系统帧内的子帧5
任一MBSFN子帧
TDD中的上行子帧

下图是一个关于SI调度的例子。

图2.10：SI调度的一个例子

可以看出，SI不需要在时间窗内的连续子帧上传输。并且某个子帧上是否存在SI消息，是通过SI-RNTI加扰的PDCCH来指示的。

这里计算的是SI窗口的起始帧和起始子帧，并不是计算SI消息具体所在的系统帧和子帧。SI消息是在SI窗口内发送的，UE需要在SI窗口内盲检使用SI-RNTI加扰的PDCCH，才能知道对应子帧上是否有SI消息。

在SI较小而系统带宽较大的情况下，一个子帧可能足以发送该SI，但在其它情况下，可能需要使用多个子帧来发送一个SI消息。在后一种情况，会将整个SI消息进行信道编码后分成多份，然后放在多个子帧（不要求是连续子帧）上传输。而不是先分割成多份，然后独立地信道编码后传输。

注意：对于SIB1和SI消息，其调制阶数固定为2。（见36.213的7.1.7.1节）

小结：MIB和SIB1在时域上的位置和周期是固定的，而SI消息在时域上的位置和周期是由SIB1指定的。eNodeB 只会通过SystemInformationBlockType1告诉UE有哪些SI，每个SI包含了哪些SIB，这些SI会在哪个SI窗口发送以及SI窗口的时域位置和长度，但不会告诉UE在 SI窗口的哪些子帧调度了该SI。当UE需要某个SIB时，它就会在该SIB对应的SI消息对应的SI窗口的每个子帧（从SI窗口的起始子帧开始，共持续si-WindowLength个子帧，但不包含那些不能调度SI的子帧），使用SI-RNTI去尝试解码，直到成功接收到SI消息为止。

2.3系统信息有效性和变更通知

系统信息（除了ETWS和CMAS，对应SIB10、SIB11和SIB12）的变更只发生在某些特定的系统帧，这里用到了变更周期的概念。

变更周期（modification period）的起始系统帧必须满足SFN mod m = 0，其中m是组成一个变更周期的系统帧数。一个变更周期包含m = modificationPeriodCoeff * defaultPagingCycle个系统帧。这是通过SIB2来设置的。

系统信息可能会在一个变更周期内传输多次，但在同一变更周期内，系统信息的内容不会发生变化。

当小区修改了某些系统信息时，它会先在一个变更周期内通知UE系统信息将发生变化（但并不发送更新后的内容），然后在紧接着的下一个变更周期，小区才会发送更新后的系统信息。如36.331的Figure 5.2.1.3-1所示（不同的颜色表示不同的系统信息）。

UE收到了一个系统信息变更通知（change notification）后，会从下一个变更周期的开始处就去接收新的系统信息。UE在收到新的系统信息之前，会继续使用旧的系统信息。如果一个重要的参数发生改变，可能会对通信造成严重影响，但由于任何服务的中断都很短且不会频繁发生，所以认为结果是可以接受的。

小区有2种方式通知UE系统信息发生了变化：

Paging消息包含了一个systemInfoModification字段，用于指示SI是否发生了变化；
SIB1中包含了一个systemInfoValueTag字段，每当SI消息发生变化时，systemInfoValueTag的值会加1。

小区可以使用Paging消息来通知处于RRC_IDLE态和RRC_CONNECTED态的UE系统信息发生了变化。Paging消息中包含了一个systemInfoModification字段，如果UE接收到的Paging消息包含该字段，则表示系统信息（除SIB10、SIB11和SIB12外）将在下一个变更周期发生变化。

SIB1（SystemInformationBlockType1）中包含了一个字段systemInfoValueTag（取值范围0~31），用于指示SI消息是否发生了变化。UE可以使用这个字段来检验之前保存的SI消息是否依然有效（例如从小区覆盖之外回到小区覆盖的范围内）。如果该字段发生了变化，则UE认为所保存的系统信息是无效的，需要重新读取；否则认为保存的系统信息依然有效。另外，UE会认为从接收到SI消息那一刻算起的3个小时之内，如果systemInfoValueTag未变化，则所保存的系统信息是有效的。即保存的SI消息的有效期为3个小时。

systemInfoValueTag是除MIB，SIB1，SIB10，SIB11和SIB12之外的所有SIB所共用的。MIB和SIB1的改变是通过UE获取这些消息来检测的。

某些系统信息，如ETWS信息、CMAS信息以及类似CDMA2000系统时间的参数等发生变化时，小区是不会更新SIB1中的systemInfoValueTag值的，Paging消息中也不会包含systemInfoModification字段。

UE可以通过以下2种方式来确定保存的系统信息是否依然有效：

校验SIB1中的systemInfoValueTag字段是否发生变化；或
在每个变更周期，如果UE在变更周期内没有收到Paging，则会尝试寻找systemInfoModification至少modificationPeriodCoeff次。如果UE在一个变更周期内没有收到Paging消息，则UE认为在接下来的一个变更周期范围不会发生系统信息的改变。如果处于RRC_CONNECTED态的UE在一个变更周期内收到了一个Paging消息，则UE会通过是否存在systemInfoModification来推断接下来的一个变更周期内，系统信息（除了ETWS和CMAS信息）是否会发生变化。

小区只会通知UE系统信息发生了变化，并不会告诉UE哪些系统信息发生了变化。所以UE收到了系统信息发生变化的指示后，会根据SIB1中的调度信息去重新接收所有SI消息（除SIB10、SIB11、SIB12外）。

对于处于RRC_CONNECTED态且支持ETWS和/或CMAS的UE而言，应该在每defaultPagingCycle个系统帧的时间内至少读取paging消息一次，以确定是否存在ETWS和/或CMAS通知。

Paging消息的etws-Indication字段用于通知UE开始接收ETWS primary通知（对应SIB10）和/或ETWS secondary通知（对应SIB11）。

Paging消息的cmas-Indication字段用于通知UE开始接收CMAS通知（对应SIB12）。

2.4载波聚合对系统信息的影响

UE只会在PCell上从广播消息中获取系统信息。对于SCell而言，其系统信息是在添加SCell时，通过RRCConnectionReconfiguration的SCellToAddMod-r10下发给UE的。如果某个SCell的系统信息发生改变，eNodeB会让UE先释放该SCell，然后重新添加该SCell以通知UE系统信息的变化。这从36.331中的5.3.10.3b中可以看出，在添加SCell（SCell addition）时，是应用radioResourceConfigCommonSCell的配置的，但在修改SCell（SCell modification）的信息时，是不应用radioResourceConfigCommonSCell的配置的，所以需要先删除再添加SCell以通知UE该SCell系统信息的变化。

注意：eNodeB在RRCConnectionReconfiguration配置的系统信息可以与该SCell广播的系统信息不同。

【参考资料】

[1] 《4G LTE/LTE-Advanced for Mobile Broadband》的14.2节

[2] 《LTE - The UMTS Long Term Evolution, 2nd Edition》的3.2.2节、9.2.1节

[3] TS 36.211的6.6节

[4] TS 36.212的5.3.1节

[5] TS 36.331 – 5.2 System Information

[6] 《PBCH: How quickly can a UE read the MIB?》

[7] 《PBCH: Does the MIB tell the UE how many antennas are used in the cell?》

[8] 《SI的调度》

[9] 《LTE系统中UE接收系统消息解析》