Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
LTE RRCLTEeNodeB -> UE3GPP TS 36.331
LTE RRC MIB - Master Information Block
Broadcast LTE RRC message on BCH that gives the UE the first essential cell-wide radio context needed to continue system-information acquisition toward SIB1 and later access behavior.
Message Fact Sheet
Protocol
lte-rrc
Network
lte
Spec
3GPP TS 36.331
Spec Section
5.2.2.3, 5.2.2.5, 5.2.2.6, 6.2.2
Direction
eNodeB -> UE
Message Type
Broadcast System Information
Full message name
LTE RRC MIB - Master Information Block
Protocol
LTE-RRC
Technology
LTE
Direction
eNodeB -> UE
Interface
Uu
Signaling bearer / channel
Broadcast system information transport / BCH
Typical trigger
The UE reads MasterInformationBlock after selecting or reselecting an LTE cell, after returning to coverage, and in some connected-mode cases such as target-cell reading during handover recovery contexts.
Main purpose
Provides the minimal broadcast anchor for LTE cell entry by exposing downlink bandwidth, PHICH configuration, and system-frame timing information before the UE can move into the wider system-information set.
Main specification
3GPP TS 36.331, 5.2.2.3, 5.2.2.5, 5.2.2.6, 6.2.2
Release added
Release 8
Procedures where used
System Information Acquisition, Initial Access, Idle-mode Cell Selection, Idle-mode Cell Reselection, Paging Return Preparation
What is Master Information Block in simple terms?
Broadcast LTE RRC message on BCH that gives the UE the first essential cell-wide radio context needed to continue system-information acquisition toward SIB1 and later access behavior.
Provides the minimal broadcast anchor for LTE cell entry by exposing downlink bandwidth, PHICH configuration, and system-frame timing information before the UE can move into the wider system-information set.
Why this message matters
MasterInformationBlock is the first LTE broadcast message the UE needs. If the UE cannot read it, normal LTE access cannot really get started.
Where this message appears in the call flow
LTE system information acquisition
Call flow position: First essential broadcast RRC block read after PBCH decoding and before SIB1 acquisition.
Typical state: UE is not yet in dedicated LTE RRC signaling and is building the minimum cell context needed for access and idle behavior.
Preconditions:
The UE has selected or reselected an LTE cell.
Synchronization and PBCH decoding are working well enough to recover BCH content.
Next likely message: SystemInformationBlockType1
LTE initial access
In LTE initial access, MasterInformationBlock is the first broadcast anchor after PBCH decode, before the UE can move to SIB1, SIB2, and later RRCConnectionRequest.
Call flow position: Broadcast entry point that must be available before the UE can complete the wider system-information path needed for connection establishment.
Typical state: UE is in cell-selection or idle-side preparation and has not yet moved into dedicated connection-control signaling.
Preconditions:
The serving cell is detectable.
The UE can decode PBCH.
The UE still needs SIB1 and SIB2 before normal access can continue.
Next likely message: SystemInformationBlockType1 then RRCConnectionRequest
Connected-mode target-cell reading
Call flow position: Special broadcast check where the UE may still need the target-cell MIB even though other system information is provided or already known through procedure context.
Typical state: UE is handling mobility or recovery-related cell context and needs the target cell's basic broadcast anchor.
Preconditions:
The UE has moved into a context where target-cell system information matters.
The UE can decode the target cell PBCH.
Next likely message: Target-cell continuation using the required later system information or dedicated signaling context
Call flow position
Previous message(s): Cell search and PBCH detection, Physical synchronization and radio frame timing acquisition
Domain: Access-side radio control for initial cell reading and basic system-information acquisition
Signaling bearer: Broadcast system information transport
Logical channel: BCH
Transport / encapsulation: MasterInformationBlock carried on BCH and decoded from PBCH timing
Security context: Broadcast message with no dedicated SRB or AS security. It is part of the common cell information every UE must read before normal LTE access can continue.
Message Structure Overview
MasterInformationBlock is the first essential LTE RRC broadcast block and the first practical checkpoint after PBCH decode.
For normal LTE trace reading, the highest-value fields are dl-Bandwidth, phich-Config, and systemFrameNumber because they anchor the common cell interpretation before SIB1 and SIB2 are acquired.
In current Release 18 ASN.1, later-release fields for BL/CE and NTN are also present, but many classic LTE traces are still mainly interpreted through the original bandwidth, PHICH, and SFN meaning.
This page uses the current Release 18 ASN.1 shape from TS 36.331 V18.3.1. In day-to-day LTE troubleshooting, the usual starting point is still dl-Bandwidth, phich-Config, and systemFrameNumber before BL/CE or NTN-related additions.
LTE RRC MIB - Master Information Block - Example Dump
The practical check is whether the UE can decode the MIB consistently at all. If not, later LTE RRC analysis is usually premature.
systemFrameNumber provides only the eight most significant bits. The remaining two bits come from PBCH timing inside the 40 ms PBCH TTI.
Value 0 for schedulingInfoSIB1-BR-r13 means SIB1-BR is not scheduled, which is normal for many classic LTE contexts.
Important Information Elements
IE
Required
Description
dl-Bandwidth
Yes
Downlink transmission bandwidth configuration expressed as the LTE NRB size used by the cell.
phich-Config
Yes
PHICH duration and resource configuration that the UE applies as part of the common radio setup.
systemFrameNumber
Yes
Eight most significant bits of the SFN, with the two least significant bits derived implicitly from PBCH timing.
schedulingInfoSIB1-BR-r13
Yes
Release 13 field indicating the index for SIB1-BR scheduling tables; value 0 means SIB1-BR is not scheduled.
systemInfoUnchanged-BR-r15
Yes
Release 15 indicator showing whether SIB1-BR and SI messages remained unchanged over the SI validity period.
partEARFCN-r17
Yes
Release 17 field carrying the two least significant EARFCN bits for NTN bands that use 100 kHz raster.
spare
Yes
Reserved spare bit field in the ASN.1 structure.
Detailed field explanation
dl-Bandwidth
Downlink transmission bandwidth configuration expressed as the LTE NRB size used by the cell.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
phich-Config
PHICH duration and resource configuration that the UE applies as part of the common radio setup.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
systemFrameNumber
Eight most significant bits of the SFN, with the two least significant bits derived implicitly from PBCH timing.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
schedulingInfoSIB1-BR-r13
Release 13 field indicating the index for SIB1-BR scheduling tables; value 0 means SIB1-BR is not scheduled.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
systemInfoUnchanged-BR-r15
Release 15 indicator showing whether SIB1-BR and SI messages remained unchanged over the SI validity period.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
partEARFCN-r17
Release 17 field carrying the two least significant EARFCN bits for NTN bands that use 100 kHz raster.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
spare
Reserved spare bit field in the ASN.1 structure.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
What to check in logs and traces
Confirm the UE can decode PBCH and recover MasterInformationBlock reliably.
Check dl-Bandwidth against the expected LTE carrier bandwidth.
Verify phich-Config before assuming uplink HARQ-related common-cell behavior.
Confirm systemFrameNumber continuity and timing alignment with the rest of the trace.
Move immediately to SIB1 and SIB2 if the goal is normal LTE access troubleshooting.
Common Issues and Troubleshooting
The UE never reaches SIB1 or later LTE access messages.
Likely cause: MasterInformationBlock may be missing or unstable, so the UE never gets a valid broadcast anchor for later system-information acquisition.
What to inspect: Check PBCH decode quality, synchronization stability, radio conditions, and whether MasterInformationBlock can be read consistently.
Next step: Fix physical-layer or coverage issues first, then retry the system-information path.
The UE reads the cell but later access assumptions look wrong.
Likely cause: dl-Bandwidth, PHICH context, or the transition from MIB into SIB1 and SIB2 may not match the intended cell interpretation.
What to inspect: Compare MIB values with the serving-cell configuration and then verify SIB1 and SIB2 acquisition.
Next step: Treat MIB as the common-cell anchor and walk forward through the rest of the broadcast set.
One LTE cell works and another fails before access starts.
Likely cause: The failing cell may have weaker PBCH conditions, inconsistent broadcast delivery, or a mismatch in common broadcast assumptions.
What to inspect: Compare MasterInformationBlock decode stability, SFN timing, and follow-on SIB acquisition between the working and failing cells.
Next step: Determine whether the break happens at PBCH/MIB, at SIB1, or only later during access.
LTE / 5G / Variant Comparison
Compared with SystemInformationBlockType1
MasterInformationBlock is the first minimal BCH anchor. SystemInformationBlockType1 carries the broader access identity, scheduling, and cell-selection information that lets the UE move deeper into the LTE broadcast model.
Compared with Paging
MasterInformationBlock is always about baseline broadcast cell interpretation. Paging is a later idle-mode reachability message that depends on the UE already having valid broadcast context.
Compared with RRCConnectionRequest
MasterInformationBlock is still broadcast reading before dedicated signaling exists. RRCConnectionRequest appears later, after the UE has acquired the required system information for connection establishment.
FAQ
What is MasterInformationBlock in LTE?
It is the first essential LTE RRC broadcast block on BCH, giving the UE basic cell-wide information such as bandwidth, PHICH configuration, and system-frame timing.
What comes after MasterInformationBlock in LTE?
The UE continues into SystemInformationBlockType1 and later required SIBs such as SIB2 before normal LTE access can proceed.
Why is LTE MIB important in troubleshooting?
Because failure to read MIB means the UE never gets the common broadcast anchor it needs for later system-information acquisition and access behavior.
Does LTE MasterInformationBlock carry the full SFN?
No. It carries the eight most significant SFN bits, while the two least significant bits are derived from PBCH timing.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.
