SIB Change Notification

Most UE decodes all the MIB/SIBs during cell selection. However once they decoded all the MIB/SIBs and perform registration, they may not try to decode all the SIBs. So if you change any information in SIB after UE get camped on and stay in idle mode, the UE may not recognize those changes. So there should be some mechanism for Network to explicitely tell UE to update all the SIBs.

3GPP 25.331 8.1.1.5 describes all the possible situations how SIB change should be notified and recognized by UE.

Two mechanisms work together here. The value tag lets the UE recognise that a block has changed, and 25.331 subclause 8.1.1.5 describes that part. The BCCH modification info in a paging or broadcast message tells the UE to look, and subclause 8.1.1.7 describes that part. Let's take them in that order, then walk through a test, and then read the captured messages.

How does the UE recognise a SIB change ?

A UE cannot read every SIB all the time, because that would cost too much battery. So the UE needs a cheap way to decide whether its stored copy is still valid. UMTS solves this with value tags: small counters that the network increases when the content changes.

The most common case of SIB change detection on UE side would be as follows :

If ( he value tag in the master information block

is different from the value tag stored for this cell and this PLMN in the variable VALUE_TAG ) {

store the value tag into the variable VALUE_TAG for the master information block;
read and store scheduling information included in the master information block

}

If ( no IEs for the master information block are stored) {

store the value tag into the variable VALUE_TAG for the master information block;
read and store scheduling information included in the master information block

}

If ( he value tag in the master information block

is same as the value tag stored for this cell and this PLMN in the variable VALUE_TAG ) {

use the stored system information blocks and scheduling blocks using value tag that were stored for this cell and this PLMN as valid system information

}

The pseudo code above follows 25.331 subclause 8.1.1.5. The first two cases make the UE read the scheduling information again. In the third case the value tags are the same, so the UE may keep using the system information blocks and scheduling blocks it stored for this cell and this PLMN. That is the whole saving: a UE that finds an unchanged MIB value tag does not need to read the SIBs again.

The same comparison repeats one level down. The scheduling information in the MIB carries a value tag for each SIB, and the UE compares each of them with its stored copy. A SIB with area scope PLMN, such as SIB1, uses a PLMN-ValueTag from 1 to 256. A SIB with area scope cell uses a CellValueTag from 1 to 4. Some SIBs, such as SIB7, use no value tag at all. For those, the UE rereads the block when its expiration timer runs out, as subclause 8.1.1.7.4 describes.

The MIB value tag is the entry point : if it has not changed, the UE may keep all its stored SIBs.
Each SIB has its own tag : a new MIB value tag only tells the UE to check the per-SIB tags in the scheduling information.
Not every SIB uses a tag : blocks such as SIB7 are refreshed by an expiration timer instead.

How does the network tell the UE to look ?

A UE in idle mode reads the MIB when it selects a cell, but not continuously after that. So a new value tag alone is not enough. The network has to tell camped UEs that the MIB has changed, and it does that with the IE BCCH modification info.

Subclause 8.1.1.7.1 sets where this IE travels, and the answer depends on the UE state. For UEs in idle mode, and in CELL_PCH or URA_PCH, the network puts it in a PAGING TYPE 1 message in all paging occasions in the cell. For UEs in CELL_FACH, the network puts it in a SYSTEM INFORMATION CHANGE INDICATION message on the BCCH mapped on FACH, or on HS-DSCH for a UE with HS-DSCH in CELL_FACH. Because the paging goes out in all paging occasions, every UE sees it within one DRX cycle. A note in subclause 8.1.1.7 therefore warns that the system information should not change more often than UEs with the longest DRX cycle can follow.

The IE carries the new MIB value tag and, optionally, a BCCH modification time. Without the time, the UE acts at once, as subclause 8.1.1.7.3 describes. With the time, the change is synchronised: the UE waits and reads the MIB at the SFN that the IE gives. The network uses this second form when the UE must know exactly when a change happens, for example when a channel is reconfigured.

Following is based on 25.331 v19.0.1 (Release 19)

BCCH-ModificationInfo ::=			SEQUENCE {
	mib-ValueTag						MIB-ValueTag,
	bcch-ModificationTime				BCCH-ModificationTime						OPTIONAL
}

MIB-ValueTag ::=					INTEGER (1..8)

BCCH-ModificationTime ::=			INTEGER (0..511)

MIB-ValueTag runs only from 1 to 8, so it wraps quickly. Subclause 8.1.1.7.3 handles this. If the MIB the UE reads has neither the stored tag nor the tag from the paging, the UE processes the MIB anyway. If (VTCI - VTMIB) mod 8 < 4, it also reads the next MIB again. Here VTCI is the tag in the BCCH modification info, and VTMIB is the tag in the MIB. This rule stops a UE from missing a change when the broadcast MIB is older than the notification.

Paging carries the notification in idle and PCH : PAGING TYPE 1 with bcch-ModificationInfo reaches every UE in all paging occasions.
CELL_FACH uses a separate message : SYSTEM INFORMATION CHANGE INDICATION carries the same IE on the BCCH.
The modification time is optional : without it the UE reads the MIB at once, and with it the UE waits for the given SFN.

How can you test SIB change notification ?

The notification only matters if the UE acts on it, so a test has to change a SIB after the UE has camped and then check the reaction. The sequences below do this in two ways: with a UE logging tool, and without one.

Normally this 'update request' is done by three steps (6,7,8,9) in the following sequence.

1) UE <-- NW : MIB Transmission

2) UE <-- NW : SIB Transmission

3) UE <--> NW : < Registration >

4) UE <--> NW : < Idle >

5) < Make changes in SIB >

6) UE <-- NW : MIB Transmission with changed Valuetag

7) UE <-- NW : SIB Transimssion with changed parameter

8) UE <-- NW : Paging Type 1 with bcch-Modification Info

9) UE : Decode all the SIBs again and update the changes

If you have UE logging tool and check the decoded SIBs on UE side, you can easily confirm the newly decoded SIBs on UE side.

If you do not have any UE logging tool, you can indirectly confirm this behavior in the following way.

1) UE <-- NW : MIB Transmission

2) UE <-- NW : SIB Transmission

3) UE <--> NW : < Registration >

4) UE <--> NW : < Idle >

5) < Make LAC changes in SIB1 : In this test, I changed LAC from 0 to 1>

6) UE <-- NW : MIB Transmission with changed Value tag

7) UE <-- NW : SIB Transimssion with changed parameter

8) UE <-- NW : Paging Type 1 with bcch-Modification Info

9) UE : Decode all the SIBs again and update the changes

10) < UE should go through following process for Location Updating for new LAC >

12) UE <--> NW : < RRC Connection Setup >

13) UE <--> NW : < Perform Location Area Updating >

14) UE <--> NW : < Perform Routing Area Updating >

15) UE <--> NW : < RRC Connection Release >

16) UE <--> NW : < Idle >

The indirect method works because LAC is part of the Location Area Identity. When SIB1 announces a new LAC, the UE is in a new location area, so it has to run a location area update. The same capture shows NMO II, Network Mode of Operation II, in the PS domain information. In NMO II the UE updates the CS domain and the PS domain separately. That is why steps 13 and 14 show a Location Area Updating and a Routing Area Updating. So the LAU in the log proves that the UE decoded the new SIB1, even without a UE logging tool.

Change a parameter the UE must react to : a new LAC forces a location update, which is easy to see on the network side.
Check the order : the UE should read the new MIB and SIB1 before it starts the RRC connection for the update.
NMO decides the number of updates : in NMO II the UE runs a LAU and a RAU. In NMO I it can use one combined update instead.

What do the captured messages show ?

The captures below are the messages behind the linked steps of the test sequence. Each one is labelled with its step number, and the red lines mark the fields that change. Read them in pairs: the MIB before and after, the SIB1 before and after, and finally the paging that announces the change.

1) UE <-- NW : MIB Transmission