System Information (MIB / SIB1–SIBn) in LTE 4G

Introduction

System Information is the first thing an LTE UE reads from a cell and the foundation everything else depends on. It is the cell's broadcast rulebook: the bandwidth needed to decode anything at all, the identity that tells the UE where it is, the access rules that decide whether it may camp, and the random-access configuration it needs to send its very first uplink message. All of it is transmitted to every UE at once, with no dedicated connection, so a UE can read it while still in RRC_IDLE with no identity of its own.

The design is strictly layered, and the layering dictates the acquisition order. The MIB on the PBCH is just enough to bootstrap the receiver; SIB1 on the PDSCH gates camping and schedules everything else; the remaining SIBs, bundled into SI messages, fill in access and mobility detail. Nothing in a lower tier can be found until the tier above it has been decoded, which is why "System Information acquisition" is really a sequence of unlocks rather than one download.

Because acquisition is ordered and schedule-driven, a camping or access failure almost always localises to one tier: a UE that cannot decode MIB never reaches SIB1; a UE that misreads schedulingInfoList never finds SIB2; a UE that reads cellBarred or q-RxLevMin wrongly rejects a perfectly good cell. Knowing which SIB tier broke narrows the root cause immediately.

Why System Information is needed

Concretely, System Information exists because a UE arriving cold knows nothing: not the bandwidth (so it cannot even size the resource grid to decode a normal PDSCH allocation), not the operator or cell identity (so it cannot know if it is allowed here or whether it must do a Tracking Area Update), and not the random-access parameters (so it cannot send its first uplink preamble). Broadcasting this once serves every UE in the cell without any per-UE signalling, and doing it in tiers lets the tiny bootstrap message live in a fixed, always-decodable location while the richer, larger content rides the efficient shared data channel. The ordering is not bureaucracy — each tier literally supplies the information needed to locate and decode the next.

What System Information Is

System Information is the cell's public noticeboard. It is broadcast to everyone, not addressed to one UE, and it carries exactly the parameters a UE needs to find the cell, decide whether it may camp there, and know how to send its first message. Because it is broadcast, no dedicated connection is needed — a UE reads it while still in RRC_IDLE, before it has any identity of its own.

It helps to separate the three tiers by how they are carried, because that dictates the acquisition order. The MIB is a fixed-format transport block on the PBCH occupying the central six resource blocks. SIB1 is an RRC message (SystemInformationBlockType1) sent on DL-SCH with its own fixed periodicity. All remaining SIBs are packaged into SystemInformation messages — the "SI messages" — and scheduled by information found inside SIB1. Nothing in the second or third tier can be found until the tier above it has been decoded.

MIB — the bootstrap on PBCH

The MasterInformationBlock is deliberately tiny — a payload of just 24 bits carried on the Physical Broadcast Channel (PBCH) in the centre six resource blocks of the cell, so a UE can read it without yet knowing the full bandwidth. It is transmitted with a 40 ms period, but the same content is repeated every 10 ms — four times per 40 ms window, once per radio frame — each repetition with different scrambling. A UE can soft-combine the repetitions to decode the MIB faster in poor conditions, and the position within the four repetitions carries hidden timing information.

The economy of the MIB is the whole point. It has to be decodable by a receiver that knows nothing yet, so it lives in a spectral location fixed by the synchronisation signals (the centre six RBs, found from PSS/SSS), and it carries the bare minimum: enough to size the grid (dl-Bandwidth), enough to parse the control region (phich-Config), and enough to establish frame timing (systemFrameNumber). Everything richer waits for SIB1.

SIB1 — the gatekeeper and the schedule

SystemInformationBlockType1 is special: it is not bundled with the other SIBs and it has its own fixed schedule — an 80 ms period, repeated at 20 ms intervals (in subframe #5 of every even-SFN radio frame, with retransmissions in between). It is carried on the PDSCH, and the UE finds it by monitoring the common search space of the PDCCH for a DCI whose CRC is scrambled with the SI-RNTI (a fixed value, hex FFFF, common to all UEs). SIB1 does two jobs: it decides whether you may camp, and it tells you how to reach every other SIB.

The schedulingInfoList is the heart of the acquisition process. Each entry is a SchedulingInfo describing one SI message: its si-Periodicity (from rf8 = 80 ms up to rf512 = 5120 ms) and its sib-MappingInfo, the list of SIB types packed into that SI message. Combined with the single si-WindowLength, this tells the UE exactly when to wake up and where to look for the SIB it wants. There is one subtlety worth memorising: SIB2 is always the first entry mapped in the first SI message, and it is never listed explicitly in sib-MappingInfo — its presence is implied.

SIB2 and beyond — access and mobility in SI messages

Everything after SIB1 is bundled into SI messages (SystemInformation RRC messages), carried on DL-SCH and scheduled by schedulingInfoList. Each SI message's PDCCH is again scrambled by SI-RNTI. The most important is SIB2, which carries the common radio configuration a UE needs to actually access and use the cell; the rest deal mostly with cell reselection to neighbours on the same frequency, on other LTE frequencies, or on other radio access technologies, plus a family of public-warning and multicast SIBs.

Later releases extend the family without changing the pattern: SIB14 carries extended access barring (EAB), SIB15 carries MBMS service-area / carrier information, SIB16 carries GPS/UTC time, and further SIBs cover sidelink and other features. In every case the principle holds — each SIB is a self-contained topic, and SIB1's schedulingInfoList is the single authority on which SI message carries it and how often. Only SIB2 through the highest scheduled SIB the UE cares about need to be read; a UE that never does MBMS simply ignores the SI message carrying SIB13.

How a UE acquires System Information

Acquisition is strictly ordered because each step unlocks the next. The MIB gives the bandwidth and framing needed to decode the PDCCH; the PDCCH (via SI-RNTI) points to SIB1 on PDSCH; and SIB1 then tells the UE how and when to read every other SIB. Miss any tier and the ones below it are unreachable.

Walk the diagram once more with the timing in mind. After synchronising with PSS/SSS, the UE reads the MIB and now knows the bandwidth, so it can decode the full control region. It then hunts the common search space for a SI-RNTI DCI; that DCI schedules the SIB1 transport block on PDSCH, which the UE decodes and soft-combines across its 20 ms retransmissions if needed. With SIB1 in hand it reads cellBarred and q-RxLevMin to decide whether camping is even possible, then consults schedulingInfoList and si-WindowLength to schedule its reads of the SI messages. At a minimum it needs SIB1 and SIB2 before it can attempt access; the reselection SIBs are read lazily, as mobility demands.

Reading SI acquisition in the logs

A UE-side SI acquisition trace reads top-down through the tiers, each line unlocking the next. The useful debugging signal is which tier the trace stops at.

Representative UE log (SI acquisition at camp-on) — illustrative, values vary by vendor/build:

SI windows, periodicity and timing

An SI message is not transmitted continuously — it appears inside a periodic SI-window. All SI windows in a cell share the same length, si-WindowLength (one of 1, 2, 5, 10, 15, 20 or 40 ms), signalled once in SIB1. Each SI message repeats at its own si-Periodicity, and the windows of successive SI messages are placed back-to-back so they never overlap. Inside its window, the UE watches the PDCCH for the SI-RNTI; when it finds a matching DCI it decodes that SI message from PDSCH. Outside the window, the message is simply not there.

The position of the n-th SI message's window is computed deterministically from its si-Periodicity, the common si-WindowLength, and its index in schedulingInfoList. Concretely, the window for the SI message at index x starts at subframe number a = x × w measured from the start of the SI-message's periodicity boundary, where w is si-WindowLength in subframes. This is why the ordering of entries in schedulingInfoList matters: the index fixes the slot in the timeline where that SI message will appear.

The practical upshot: a UE wanting SIB3 looks up which SI message carries it, computes that message's window position from its index and periodicity, sleeps until the next such window, and only then powers up its receiver to hunt the SI-RNTI. This lets an idle UE keep its receiver off almost all the time, waking only for the specific windows carrying the SIBs it still needs.

SI validity, value tag and change notification

System Information is not static — an operator may retune RACH parameters, change neighbour lists, or issue an emergency warning. To avoid every UE re-reading everything constantly, LTE uses modification periods and a paging-based change notification.

SI is considered valid for the duration of a modification period, whose boundaries the network defines (as a multiple of the default paging cycle). When the network wants to change SI, it does not change it mid-period; it waits for the next modification-period boundary and, during the current period, notifies UEs that a change is coming. That notification is a Paging message carrying the systemInfoModification flag. On seeing it, a UE knows the SI will change at the next boundary and re-acquires SIB1 (and any SIBs it uses) from that boundary onward. Between the notification and the boundary, the old SI remains valid.

Each SIB1 also carries a systemInfoValueTag (0–31). A UE returning from out-of-coverage or waking from a long sleep compares the tag it stored against the freshly read one: if they match, its stored SI is still valid and it can skip re-reading the other SIBs; if they differ, it re-acquires. The value tag is also treated as stale after a maximum age (3 hours), forcing a periodic refresh regardless. Note that the value tag does not track the emergency SIBs — ETWS, CMAS and EAB changes are signalled separately and are exempt from the modification-period discipline.

LTE ↔ NR

NR keeps the three-tier idea but modernises delivery and adds on-demand SI so a cell need not broadcast everything all the time.

Summary

System Information is a strictly ordered set of unlocks, and the fastest way to root-cause a camp-on or access failure is to find the first tier that broke. The MIB on PBCH is the 24-bit bootstrap (dl-Bandwidth, phich-Config, SFN) that lets the UE size the grid and decode PDCCH. SIB1 on PDSCH — located via a SI-RNTI (FFFF) DCI in the common search space — is the gatekeeper (cellBarred, q-RxLevMin, PLMN) and the schedule (schedulingInfoList, si-WindowLength). The SI messages then deliver SIB2 (the access config the UE must have before RACH) and the reselection/warning SIBs inside their computed SI windows.

Because each tier supplies what is needed to find the next, a trace that stalls tells you where to look: stuck at MIB is sync/coverage; stuck at SIB1 is the SI-RNTI DCI or control-region sizing; stuck at SIB2 is SI-window timing from schedulingInfoList. And once camped, the modification-period + systemInfoValueTag machinery keeps the UE's stored SI fresh without constant re-reading — with emergency SIBs exempt so warnings arrive immediately.