1.為什么需要加入系統(tǒng)信息變更機制

從《LTE系統(tǒng)信息（2）-SIB的周期調度》里我們已經知道，UE所需的系統(tǒng)信息絕大多數(shù)都包含在不同的SIB塊里，分別由SIB1消息和SI消息廣播到UE。攜帶的這些參數(shù)信息一般情況下都不會發(fā)生變化，但世事無絕對，考慮到網(wǎng)側某些特定情況下可能需要對一些參數(shù)進行修改，比如修改SIB1中的RACH參數(shù)，或者修改SIB2中的ac-BarringInfo參數(shù)，因而需要增加一種機制，可以讓SIB參數(shù)有變更的時候，UE能及時的獲取到更新之后的系統(tǒng)信息。這種機制也就是本文將要描述的“系統(tǒng)信息變更過程”（change of system information）。

可能有的同學會問了，UE難道不會在每個系統(tǒng)信息的周期時刻都去解碼嗎？UE顯然是知道所有每個系統(tǒng)信息的發(fā)送時刻的，eNB也是周期廣播的，所以只要UE愿意去讀，是能及時獲取到最新的系統(tǒng)信息的，那為什么UE不去這么做呢？因為在很多情況下系統(tǒng)信息是不會變化的，如果讓UE在已經獲取了系統(tǒng)信息的情況下，仍然每隔幾十ms不間斷的去讀系統(tǒng)信息，那是比較費電的。功耗問題是影響UE整體性能的一個非常關鍵的問題，其它諸如尋呼、CDRX機制也是基于類似的出發(fā)點考慮的。

既然UE不會在每個系統(tǒng)信息的發(fā)送時刻都去讀，那什么時候UE需要去讀呢？當發(fā)生下面場景中的其中一種時，UE就需要去獲取或重新獲取系統(tǒng)信息：

2.系統(tǒng)信息變更過程

系統(tǒng)信息的變更只能發(fā)生在特定的無線幀中，這些特定的無線幀也被稱作“變更周期”（modification period，簡稱MP）。變更周期的邊界或者說起始的幀位置要符合條件（SFN mod m = 0）。其中，m表示變更周期，由SIB2塊中的modificationPeriodCoeff參數(shù)和defaultPagingCycle參數(shù)共同決定，如圖1所示。比如，modificationPeriodCoeff=n2，defaultPagingCycle=rf32，那么變更周期m=2×32=64，單位是無線幀的個數(shù)。

（圖1 SIB2中與變更周期相關的參數(shù)）

當網(wǎng)絡需要修改系統(tǒng)信息時，將執(zhí)行下面的2個過程：

（1）發(fā)送系統(tǒng)信息變更指示。eNB會給UE發(fā)送一個系統(tǒng)信息變更指示，告知UE在接下來的系統(tǒng)變更周期中需要重新讀取系統(tǒng)信息。UE一旦收到系統(tǒng)信息變更指示，就會在下個變更周期的起始位置開始獲取新的系統(tǒng)信息。UE在解碼到新的系統(tǒng)信息之前，需要繼續(xù)使用舊的系統(tǒng)信息參數(shù)。

（2）在接下來的一個變更周期里，網(wǎng)側廣播修改后的系統(tǒng)信息。

如圖2所示，不同的顏色塊代表不同的系統(tǒng)信息。在系統(tǒng)變更周期n里，UE收到了系統(tǒng)變更指示，但此時的系統(tǒng)信息仍然是舊的系統(tǒng)信息，即圖中的紅色標識塊，在接下來系統(tǒng)變更周期（n+1）里，網(wǎng)側開始廣播新的系統(tǒng)信息塊，即圖中的粉色內容。黃色的系統(tǒng)信息塊在此過程中沒有改變。

（圖2 系統(tǒng)信息變更過程）

根據(jù)待修改的系統(tǒng)信息參數(shù)的不同，這個變更指示參數(shù)被分成了2個部分：尋呼消息里的systemInfoModification字段和SIB1中的systemInfoValueTag字段。如果是修改除SIB10/11/12三種之外的系統(tǒng)信息，則需要在尋呼消息里增加systemInfoModification字段；而如果是修改除MIB/SIB1/SIB10/SIB11/SIB12之外的系統(tǒng)信息，則需要修改SIB1中的systemInfoValueTag字段。

博文《DRX不連續(xù)接收（2）-尋呼Paging》里已經說過，在尋呼消息結構體里有個可選字段systemInfoModification，這個字段表示除SIB10/SIB11/SIB12之外的系統(tǒng)信息是否有改變，如下面的圖3所示。如果UE解碼尋呼信息時發(fā)現(xiàn)包含了該字段，則認為網(wǎng)側會在下一個系統(tǒng)變更周期內修改系統(tǒng)信息，UE需要執(zhí)行系統(tǒng)信息變更過程，無論當前UE處于RRC-IDLE態(tài)還是處于CONNECTED態(tài)。尋呼消息中攜帶的系統(tǒng)信息變更指示只是一個標記位，只能告訴UE“系統(tǒng)信息有修改”這個簡單的信息，無法告訴UE具體是哪些系統(tǒng)信息要修改。

（圖3 尋呼消息中的系統(tǒng)信息變更指示）

SIB1里包含了一個systemInfoValueTag字段，可以通過這個字段，來判斷當前除MIB/SIB1/SIB10/SIB11/SIB12之外的系統(tǒng)信息是否仍然有效，如下面的圖4所示。systemInfoValueTag字段的取值范圍是0～31，網(wǎng)絡每執(zhí)行1次系統(tǒng)信息變更過程，就將該字段遞增1，UE側通過該值是否發(fā)生變化來判斷是否需要執(zhí)行系統(tǒng)信息變更過程。

（圖4 SIB1中與消息變更相關的參數(shù)）

如果在一個變更周期內UE沒有收到尋呼消息，UE可能會認為在接下來的一個變更周期里不會發(fā)生系統(tǒng)信息變更。所以，如果網(wǎng)側要修改系統(tǒng)信息參數(shù)（除ETWS和CMAS），應該要發(fā)送尋呼消息，且在尋呼消息里增加systemInfoModification字段。

從上面的描述中可以看到，無論是尋呼消息中的systemInfoModification字段還是SIB1中的systemInfoValueTag字段，都不能表示ETWS或CMAS消息是否發(fā)生了變化。SIB10/11/12所攜帶的ETWS和CMAS消息，需要通過尋呼消息是否包含etws-Indication和cmas-Indication字段來決定。

3.系統(tǒng)信息變更方案的演進

如何讓UE及時的獲知系統(tǒng)信息的變化，最開始是由Motorola在2007年韓國的一次3GPP會議中提出來的。Moto提出：首先可以在MIB中增加一個mib_value_tag字段，用來表示SIB1或其它SIB塊是否發(fā)生了改變；同時，在SIB1中為每個其它的SIB塊綁定一個sib_value_tag字段，這些字段用來表示某個具體的SIB塊是否發(fā)生了變化。這樣設計之后，eNB就可以通過修改MIB中的mib_value_tag字段和SIB1中的sib_value_tag集字段，來控制UE讀取系統(tǒng)信息的行為。熟悉GSM-RR/RRC協(xié)議的同學會發(fā)現(xiàn)，這個原始的方案類似于GSM中SI-type13消息的BCCH_CHANGE_MARK和SI_CHANGE_FIELD字段的設計，感興趣的同學可以看看44018和44060這兩篇協(xié)議。

仔細研究一下會發(fā)現(xiàn)，僅僅這樣實現(xiàn)系統(tǒng)信息的變更過程是不行的，為什么呢？因為UE不會一直去讀取系統(tǒng)信息（MIB和SIB），UE無法準確的知道網(wǎng)側什么時候修改系統(tǒng)信息參數(shù)，所以這里就需要給UE再綁定一個定時器（比如GSM中使用30s定時器）。當定時器超時之后，每個UE就主動的重新讀取MIB消息，檢測其中的mib_value_tag字段，一旦mib_value_tag字段發(fā)生了改變就去重新讀取SIB1消息，檢測其中的sib_value_tag值，從而確定其它的SIB塊是否發(fā)生了變化。

到了這里是不是就可以了呢？同樣的有問題。因為什么時候開啟這個定時器是有講究的。服務小區(qū)廣播的系統(tǒng)參數(shù)一旦改變，那么這個小區(qū)內所有的UE都應該同時去獲取更新后的系統(tǒng)信息，如果不同UE的定時器開啟時間不一致，就會導致有的UE已經收到了新的系統(tǒng)信息參數(shù)，而有的UE卻還是舊的系統(tǒng)信息參數(shù)。所以規(guī)定：一旦UE解碼到MIB之后就開啟該定時器。這樣，同一個小區(qū)里所有的UE就可以保持系統(tǒng)信息更新過程的同步。

后來英飛凌對此進行了優(yōu)化：MIB中攜帶的是最基本的信息，不應該將系統(tǒng)信息的修改字段value_tag放在MIB中，我們可以把value_tag字段轉移放在尋呼消息中。因為同一個服務小區(qū)里所有的UE都能解碼到P-RNTI加擾的尋呼消息，這樣可以保證每個UE都能收到同樣的value_tag。為方便區(qū)別，這里把放在尋呼消息里的value_tag暫記為paging_value_tag。通過paging_value_tag字段來表示MIB/SIB1/SIB2/../SIB9/SIB13是否有修改，而SIB1中的sib1_value_tag字段用來表示SIB2/SIB3/../SIB9/SIB13是否有修改。

《DRX不連續(xù)接收（2）-尋呼Paging》里已經分析過，對于同一個服務小區(qū)里的不同UE來說，尋呼消息的發(fā)送時刻是與IMSI相關的，不同的UE對應的尋呼時刻并不相同。為了保證所有UE能同時讀取到更新后的系統(tǒng)信息，所有UE只能從統(tǒng)一的“指定時刻”去讀取系統(tǒng)信息。.不同的UE在接收到value_tag之后不要急著去讀新的系統(tǒng)信息，而只在到了“指定時刻”才去讀系統(tǒng)信息。這個“指定時刻”就是通過前文所述的“系統(tǒng)變更周期”來區(qū)分。

經過這樣的優(yōu)化之后，UE就可以通過讀取尋呼消息中的paging_value_tag字段和SIB1中的sib_value_tag字段，來判斷是否需要重新讀取系統(tǒng)信息了。

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