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)
联系客服