LTE系统信息（3）-系统信息变更

1.为什么需要加入系统信息变更机制

从《LTE系统信息（2）-SIB的周期调度》里我们已经知道，UE所需的系统信息绝大多数都包含在不同的SIB块里，分别由SIB1消息和SI消息广播到UE。携带的这些参数信息一般情况下都不会发生变化，但世事无绝对，考虑到网侧某些特定情况下可能需要对一些参数进行修改，比如修改SIB1中的RACH参数，或者修改SIB2中的ac-BarringInfo参数，因而需要增加一种机制，可以让SIB参数有变更的时候，UE能及时的获取到更新之后的系统信息。这种机制也就是本文将要描述的“系统信息变更过程”（change of system information）。

可能有的同学会问了，UE难道不会在每个系统信息的周期时刻都去解码吗？UE显然是知道所有每个系统信息的发送时刻的，eNB也是周期广播的，所以只要UE愿意去读，是能及时获取到最新的系统信息的，那为什么UE不去这么做呢？因为在很多情况下系统信息是不会变化的，如果让UE在已经获取了系统信息的情况下，仍然每隔几十ms不间断的去读系统信息，那是比较费电的。功耗问题是影响UE整体性能的一个非常关键的问题，其它诸如寻呼、CDRX机制也是基于类似的出发点考虑的。

既然UE不会在每个系统信息的发送时刻都去读，那什么时候UE需要去读呢？当发生下面场景中的其中一种时，UE就需要去获取或重新获取系统信息：

（1）开机后的小区选择过程。 （2）准备重选到另一个小区时。 （3）切换过程完成之后。 （4）从其他制式进入到LTE制式之后。 （5）从丢失覆盖返回。 上面这5种场景可以归纳为当UE进入一个新的服务小区之后，需要获取该小区的系统信息。 （6）收到系统信息变更指示。 （7）收到ETWS消息指示。由寻呼消息中是否出现etws-Indication字段决定。 （8）收到CMAS消息指示。寻呼消息中是否出现cmas-Indication字段决定。 上面这3种场景可以归纳为服务小区中的广播参数发生了变化，需要UE重新获取。 （9）收到CDMA2000上层指示。此时UE需要重新获取携带CDMA2000参数的SIB8。 （10）超过系统信息的最大有效期。如果UE已经读过系统信息，那么UE存储的系统信息只有3个小时的有效期，超过3个小时就需要重新获取系统信息。

2.系统信息变更过程

系统信息的变更只能发生在特定的无线帧中，这些特定的无线帧也被称作“变更周期”（modification period，简称MP）。变更周期的边界或者说起始的帧位置要符合条件（SFN mod m = 0）。其中，m表示变更周期，由SIB2块中的modificationPeriodCoeff参数和defaultPagingCycle参数共同决定，如图1所示。比如，modificationPeriodCoeff=n2，defaultPagingCycle=rf32，那么变更周期m=2×32=64，单位是无线帧的个数。

（图1 SIB2中与变更周期相关的参数）

当网络需要修改系统信息时，将执行下面的2个过程：

（1）发送系统信息变更指示。eNB会给UE发送一个系统信息变更指示，告知UE在接下来的系统变更周期中需要重新读取系统信息。UE一旦收到系统信息变更指示，就会在下个变更周期的起始位置开始获取新的系统信息。UE在解码到新的系统信息之前，需要继续使用旧的系统信息参数。

（2）在接下来的一个变更周期里，网侧广播修改后的系统信息。

如图2所示，不同的颜色块代表不同的系统信息。在系统变更周期n里，UE收到了系统变更指示，但此时的系统信息仍然是旧的系统信息，即图中的红色标识块，在接下来系统变更周期（n+1）里，网侧开始广播新的系统信息块，即图中的粉色内容。黄色的系统信息块在此过程中没有改变。

（图2 系统信息变更过程）

根据待修改的系统信息参数的不同，这个变更指示参数被分成了2个部分：寻呼消息里的systemInfoModification字段和SIB1中的systemInfoValueTag字段。如果是修改除SIB10/11/12三种之外的系统信息，则需要在寻呼消息里增加systemInfoModification字段；而如果是修改除MIB/SIB1/SIB10/SIB11/SIB12之外的系统信息，则需要修改SIB1中的systemInfoValueTag字段。

博文《DRX不连续接收（2）-寻呼Paging》里已经说过，在寻呼消息结构体里有个可选字段systemInfoModification，这个字段表示除SIB10/SIB11/SIB12之外的系统信息是否有改变，如下面的图3所示。如果UE解码寻呼信息时发现包含了该字段，则认为网侧会在下一个系统变更周期内修改系统信息，UE需要执行系统信息变更过程，无论当前UE处于RRC-IDLE态还是处于CONNECTED态。寻呼消息中携带的系统信息变更指示只是一个标记位，只能告诉UE“系统信息有修改”这个简单的信息，无法告诉UE具体是哪些系统信息要修改。

（图3 寻呼消息中的系统信息变更指示）

SIB1里包含了一个systemInfoValueTag字段，可以通过这个字段，来判断当前除MIB/SIB1/SIB10/SIB11/SIB12之外的系统信息是否仍然有效，如下面的图4所示。systemInfoValueTag字段的取值范围是0～31，网络每执行1次系统信息变更过程，就将该字段递增1，UE侧通过该值是否发生变化来判断是否需要执行系统信息变更过程。

（图4 SIB1中与消息变更相关的参数）

如果在一个变更周期内UE没有收到寻呼消息，UE可能会认为在接下来的一个变更周期里不会发生系统信息变更。所以，如果网侧要修改系统信息参数（除ETWS和CMAS），应该要发送寻呼消息，且在寻呼消息里增加systemInfoModification字段。

从上面的描述中可以看到，无论是寻呼消息中的systemInfoModification字段还是SIB1中的systemInfoValueTag字段，都不能表示ETWS或CMAS消息是否发生了变化。SIB10/11/12所携带的ETWS和CMAS消息，需要通过寻呼消息是否包含etws-Indication和cmas-Indication字段来决定。

3.系统信息变更方案的演进

如何让UE及时的获知系统信息的变化，最开始是由Motorola在2007年韩国的一次3GPP会议中提出来的。Moto提出：首先可以在MIB中增加一个mib_value_tag字段，用来表示SIB1或其它SIB块是否发生了改变；同时，在SIB1中为每个其它的SIB块绑定一个sib_value_tag字段，这些字段用来表示某个具体的SIB块是否发生了变化。这样设计之后，eNB就可以通过修改MIB中的mib_value_tag字段和SIB1中的sib_value_tag集字段，来控制UE读取系统信息的行为。熟悉GSM-RR/RRC协议的同学会发现，这个原始的方案类似于GSM中SI-type13消息的BCCH_CHANGE_MARK和SI_CHANGE_FIELD字段的设计，感兴趣的同学可以看看44018和44060这两篇协议。

仔细研究一下会发现，仅仅这样实现系统信息的变更过程是不行的，为什么呢？因为UE不会一直去读取系统信息（MIB和SIB），UE无法准确的知道网侧什么时候修改系统信息参数，所以这里就需要给UE再绑定一个定时器（比如GSM中使用30s定时器）。当定时器超时之后，每个UE就主动的重新读取MIB消息，检测其中的mib_value_tag字段，一旦mib_value_tag字段发生了改变就去重新读取SIB1消息，检测其中的sib_value_tag值，从而确定其它的SIB块是否发生了变化。

到了这里是不是就可以了呢？同样的有问题。因为什么时候开启这个定时器是有讲究的。服务小区广播的系统参数一旦改变，那么这个小区内所有的UE都应该同时去获取更新后的系统信息，如果不同UE的定时器开启时间不一致，就会导致有的UE已经收到了新的系统信息参数，而有的UE却还是旧的系统信息参数。所以规定：一旦UE解码到MIB之后就开启该定时器。这样，同一个小区里所有的UE就可以保持系统信息更新过程的同步。

后来英飞凌对此进行了优化：MIB中携带的是最基本的信息，不应该将系统信息的修改字段value_tag放在MIB中，我们可以把value_tag字段转移放在寻呼消息中。因为同一个服务小区里所有的UE都能解码到P-RNTI加扰的寻呼消息，这样可以保证每个UE都能收到同样的value_tag。为方便区别，这里把放在寻呼消息里的value_tag暂记为paging_value_tag。通过paging_value_tag字段来表示MIB/SIB1/SIB2/../SIB9/SIB13是否有修改，而SIB1中的sib1_value_tag字段用来表示SIB2/SIB3/../SIB9/SIB13是否有修改。

《DRX不连续接收（2）-寻呼Paging》里已经分析过，对于同一个服务小区里的不同UE来说，寻呼消息的发送时刻是与IMSI相关的，不同的UE对应的寻呼时刻并不相同。为了保证所有UE能同时读取到更新后的系统信息，所有UE只能从统一的“指定时刻”去读取系统信息。.不同的UE在接收到value_tag之后不要急着去读新的系统信息，而只在到了“指定时刻”才去读系统信息。这个“指定时刻”就是通过前文所述的“系统变更周期”来区分。

经过这样的优化之后，UE就可以通过读取寻呼消息中的paging_value_tag字段和SIB1中的sib_value_tag字段，来判断是否需要重新读取系统信息了。

参考资料：
（1）3GPP TS 36.331 V9.18.0 (2014-06) Radio Resource Control (RRC)