5G系统信息广播：基站的公告栏与按需获取

从小区门口的公告栏说起

你搬进一个新小区，第一件事是什么？去门口看公告栏。公告栏上写着物业电话、快递柜位置、小区WiFi密码、周边学校信息……你不需要挨家挨户敲门问，所有"公共信息"都在公告栏上一览无余。

5G基站（gNB）也在做同样的事。每当手机开机或进入一个新小区，它需要知道"这个小区欢迎我吗？""怎么呼叫基站？""邻居小区在哪里？"这些公共问题的答案，全部写在基站的"公告栏"里——系统信息（System Information, SI）。

但5G做了一个聪明的改进：不是所有公告都一直贴着。那些很少有人看的公告，改成"你有需要就来拿"——这就是5G独有的按需系统信息（On-demand SI）机制。相比之下，4G基站不管有没有人看，所有公告都24小时不停地广播，白白浪费了不少"电费"。

这篇文章，我们就来拆解5G系统信息广播的完整设计原理。

一、系统信息的整体架构：两道菜菜单

5G把系统信息分成两大类，就像餐厅的"必点菜单"和"隐藏菜单"：

为什么这样分？ 手机刚到一个陌生小区，至少要知道"我是谁、怎么联系你"这些最基本信息才能工作。Minimum SI就是这份最低保障。而像邻区列表、地震预警、定位辅助这些信息，并非每个手机每时每刻都需要，所以可以灵活处理。

graph TD
    A[5G系统信息 SI] --> B[Minimum SI<br/>最小系统信息]
    A --> C[Other SI<br/>其他系统信息]

    B --> D[MIB<br/>主信息块]
    B --> E[SIB1<br/>系统信息块1]

    C --> F[SI消息1<br/>含SIB2+SIB3]
    C --> G[SI消息2<br/>含SIB4+SIB5]
    C --> H[SI消息N<br/>含SIBx...]

    D --> I[始终广播<br/>PBCH承载]
    E --> J[始终广播<br/>PDSCH承载]

    F --> K{广播状态?}
    G --> L{广播状态?}
    H --> M{广播状态?}

    K --> N[周期广播]
    K --> O[按需获取]
    L --> P[周期广播]
    L --> Q[按需获取]
    M --> R[周期广播]
    M --> S[按需获取]

    style B fill:#4CAF50,color:white
    style C fill:#2196F3,color:white
    style D fill:#FF9800,color:white
    style E fill:#FF9800,color:white

二、MIB：基站的第一张名片

手机开机后搜索到的第一个系统信息就是MIB（Master Information Block），它通过PBCH物理信道承载。

MIB为什么特殊？

MIB必须在手机还没跟基站建立任何连接的时候就"裸收"——没有调度信令、没有HARQ重传、没有确认反馈。所以MIB的内容必须极度精简，信令开销尽量小。

MIB包含什么？

关键设计洞察：MIB最重要的信息其实是pdcch-ConfigSIB1——它只有4个bit的高位+4个bit的低位，却编码了CORESET#0的配置和SearchSpace#0的配置。相当于基站递给手机一张"藏宝图"，告诉它"按这个坐标去找SIB1"。

MIB的发送周期

$$T_{\text{MIB}} = 80\text{ms}$$

在80ms周期内，MIB会在每个SSB波束中重复发送。假设一个周期发送了4个SSB（波束扫描），那每个SSB里都携带了一份完整的MIB。

三、SIB1：系统信息的"总目录"

如果MIB是基站的第一张名片，那SIB1就是一本百科全书的目录页。

SIB1通过PDCCH调度（用SI-RNTI = 0xFFFF加扰），在PDSCH上传输。它的周期为160ms，在160ms内可以重复发送。

SIB1包含的核心内容

SIB1的"总目录"功能

SIB1最独特的设计是它的调度信息字段（si-SchedulingInfo）——它告诉手机"其他SIB怎么获取"。这是5G系统信息架构的精髓所在：

si-SchedulingInfo {
    si-SchedulingInfoSIB1 { ... }     // 其他SIB的总调度
    si-MessageList {                   // SI消息列表
        SI-Message-1 {
            sib-TypeList: [SIB2, SIB3] // 这个SI消息包含哪些SIB
            si-Periodicity: 160ms      // 广播周期
        }
        SI-Message-2 {
            sib-TypeList: [SIB4, SIB5] 
            si-Periodicity: 320ms
        }
    }
    si-WindowLength: 20ms             // 所有SI消息共享的窗口长度
    si-BroadcastStatus: [             // 每个SI消息是否在广播
        Broadcasting,                  // SI-1正在广播
        NotBroadcasting                // SI-2没有广播
    ]
    si-RequestConfig { ... }          // 按需请求的配置
}

设计哲学：把调度信息放在SIB1而不是单独的消息里，是因为手机只要读完SIB1，就拿到了所有"导航信息"，不需要再额外接收别的消息就知道下一步该怎么做。

四、SIB到SI消息的映射：打包发货

5G不直接广播单个SIB，而是把多个SIB打包成一个SI消息（SI Message）。这就像快递打包——不需要每个商品单独发一个包裹，相关的商品装一箱更省事。

graph LR
    subgraph "SIB → SI消息映射"
        SIB2[SIB2<br/>小区重选通用参数]
        SIB3[SIB3<br/>同频邻区信息]
        SIB4[SIB4<br/>异频邻区信息]
        SIB5[SIB5<br/>异系统邻区信息]
        SIB6[SIB6<br/>地震预警]
        SIB9[SIB9<br/>时间信息]
    end

    SIB2 --> SI1[SI消息1]
    SIB3 --> SI1
    SIB4 --> SI2[SI消息2]
    SIB5 --> SI2
    SIB6 --> SI3[SI消息3]
    SIB9 --> SI4[SI消息4]

    SI1 --> |"周期 160ms"| W1[SI窗口1]
    SI2 --> |"周期 320ms"| W2[SI窗口2]
    SI3 --> |"周期 640ms"| W3[SI窗口3]
    SI4 --> |"周期 1280ms"| W4[SI窗口4]

映射原则

运营商在网络规划时决定如何打包，一般遵循以下原则：

为什么要打包？ 因为每个SI消息都需要PDCCH调度，打包可以减少调度开销。假设有8个SIB，如果不打包需要8次PDCCH调度；打包成3个SI消息，只需3次调度。

五、SI窗口机制：定时开张的窗口

每个SI消息在一个周期性的时间窗口（SI-window）内发送。理解SI窗口的工作方式，是掌握系统信息调度机制的关键。

SI窗口的计算

所有SI消息共享一个窗口长度（si-WindowLength，在SIB1中配置），但每个SI消息的窗口起始位置不同。计算公式如下：

$$\text{SI-Window起点} = (\text{SI消息编号} - 1) \times \text{SI-WindowLength}$$

更精确地说，对于SI消息 $n$（$n$ 从1开始编号），在一个SI周期内：

$$\text{起始帧} = \text{floor}(N \times (\text{periodicity} / \text{windowLength})) \mod 1024$$

其中 $N$ 是SI消息在si-MessageList中的顺序编号。

SI窗口内的工作方式

sequenceDiagram
    participant UE as 手机(UE)
    participant PDCCH as PDCCH(SI-RNTI)
    participant PDSCH as PDSCH(SI数据)

    Note over UE: SI窗口开始
    loop SI窗口内每个时隙
        UE->>PDCCH: 监听SI-RNTI加扰的DCI
        alt 找到调度信息
            PDCCH-->>UE: DCI 1_0(指示PDSCH位置)
            UE->>PDSCH: 接收SI消息数据
            PDSCH-->>UE: SI消息内容(SIBx+...)
            Note over UE: ✅ 成功接收，退出窗口
        else 未找到调度
            Note over UE: 继续下一个时隙
        end
    end
    Note over UE: SI窗口结束
    Note over UE: ❌ 未收到，等下一个周期

SI窗口的关键参数

窗口设计的关键洞察：SI窗口不能太长（浪费手机监听功耗），也不能太短（可能因为信道不好错过）。20ms是一个好的平衡点——足够让手机在多个时隙中尝试接收，又不至于等太久。

六、On-demand SI：5G的"按需取件"创新

这是5G相比4G在系统信息方面最革命性的改进。

4G的问题

在4G LTE中，所有SIB（SIB1~SIB20+）不管有没有人需要，都24小时不停地广播。想象一下，一个基站覆盖下只有3个用户，但基站不停地广播地震预警信息（SIB10/SIB11）、MBMS信息（SIB13~SIB15）——绝大多数时间这些广播完全是浪费。

5G的解决方案

5G允许基站把某些SI消息标记为"Not Broadcasting"（未广播），手机需要时再请求：

sequenceDiagram
    participant UE as 手机
    participant gNB as 基站

    Note over UE: ① 读取SIB1<br/>发现SI-2未广播
    UE->>UE: 检查si-BroadcastStatus<br/>SI-2 = NotBroadcasting
    UE->>UE: 读取si-RequestConfig<br/>获取请求方式

    alt 方式A: 基于Msg1的请求
        UE->>gNB: PRACH Preamble<br/>(专用SI请求前导码)
        gNB-->>UE: RAR(无需Msg3/Msg4)
        Note over gNB: ② 开始广播SI-2
        gNB->>UE: SI-2消息(SI-RNTI调度)
    else 方式B: 基于Msg3的请求
        UE->>gNB: PRACH Preamble(通用)
        gNB-->>UE: RAR
        UE->>gNB: Msg3: RRCSystemInfoRequest
        gNB-->>UE: Msg4(确认)
        Note over gNB: ② 开始广播SI-2
        gNB->>UE: SI-2消息(SI-RNTI调度)
    end

    Note over UE: ③ 接收目标SIB

On-demand的两种请求方式

设计选择背后的逻辑：Msg1方式更快但资源受限，适合只有少量SI消息需要按需获取的场景；Msg3方式更灵活，适合SI消息较多的场景。运营商可以在SIB1中配置使用哪种方式。

On-demand的省电效果

考虑一个实际场景：一个基站覆盖下有10个手机，其中只有2个需要SIB4（异频邻区信息）来做异频测量。

七、SI修改机制：公告更新了怎么办？

基站广播的系统信息不是一成不变的——运营商可能修改邻区配置、调整接入参数等。那手机怎么知道"公告栏更新了"？

修改指示的两种方式

方式1：Value Tag机制

SIB1中有一个si-ValueTag字段（5个bit，取值0~31），每次SI内容变更时，基站递增这个值。手机保存上次读取时的Value Tag，下次醒来时只需对比：

$$\text{Tag}{\text{stored}} \stackrel{?}{=} \text{Tag}$$}

如果不等，说明SI内容变了，需要重新读取所有Other SI。这个值每modificationPeriod（默认640ms）最多变一次。

方式2：Paging短消息

基站通过Paging消息中的短消息指示（Short Message）通知SI变更。短消息中有一个si-Modification标志位：

graph TD
    A[SI内容需要修改] --> B[基站更新si-ValueTag]
    B --> C[在下一个修改周期边界<br/>通过Paging通知]
    C --> D{手机收到Paging}
    D -->|si-Modification = 1| E[重新读取SIB1<br/>检查Value Tag]
    D -->|未收到Paging| F[继续使用缓存的SI]
    E --> G{Tag变化?}
    G -->|是| H[重新接收所有Other SI]
    G -->|否| I[SI未变，保持缓存]

    style A fill:#f44336,color:white
    style H fill:#4CAF50,color:white
    style I fill:#9E9E9E,color:white

修改周期的约束

SI修改不是"想改就改"的，它受到修改周期（Modification Period）的约束：

• 在一个修改周期内，SI内容保持不变
• 修改只能发生在修改周期边界
• 手机在修改周期内必须至少收到一次Paging才不会错过变更

$$\text{Modification Period} = \text{defaultPagingCycle} \times nB$$

典型值为640ms或1280ms。

为什么要这么设计？ 这是一个典型的可靠性与效率的权衡。如果允许随时修改，手机可能读到"半个旧版半个新版"的不一致信息。修改周期确保了所有手机在同一时间点切换到新版本。

八、各SIB类型速查表

下表总结了5G NR主要SIB的用途，帮助工程师在实际工作中快速定位需要关注的SIB：

实战提示：排查驻留问题时，重点关注SIB1和SIB2；排查重选问题时，关注SIB3/SIB4/SIB5；排查紧急告警时，关注SIB6/SIB7/SIB8。

九、波束扫描下的SI广播

5G在高频段（FR2，毫米波）使用波束赋形，基站不是全向广播，而是用窄波束"扫射"。这给系统信息广播带来了新的挑战。

SSB波束扫描与MIB

一个SSB（SS/PBCH Block）在一个波束方向上发送。基站在一个周期内（典型20ms）发送多个SSB（最多64个，FR1最多8个），每个SSB携带相同的MIB内容，但通过不同的波束方向发送给不同位置的用户。

SIB1的多波束重复

SIB1也需要在多个波束方向上重复发送，确保任何方向上的手机都能收到。SIB1与SSB的关联通过MIB中的pdcch-ConfigSIB1字段建立：

这就是为什么5G在高频段广播开销更大的根本原因——波束越窄、数量越多，每个广播消息需要的重复次数就越多。这也是On-demand SI在高频段更有价值的原因——减少不必要的广播能节省大量空口资源。

十、4G与5G系统信息对比

5G做了哪些关键改进？

1. 按需获取：最大的改进，节省空口广播资源
2. MIB/SIB1周期延长：从40/80ms延长到80/160ms，减少广播开销
3. SI消息分组更灵活：运营商可以更自由地打包SIB
4. Short Message机制：PDCCH可以直接携带短消息通知SI变更，不需要完整解码Paging消息

十一、手机读取SI的完整流程

把以上所有内容串起来，看一部手机从开机到成功驻留的"公告栏阅读之旅"：

flowchart TD
    A[手机开机] --> B[搜索SSB<br/>PSS/SSS同步]
    B --> C[解调PBCH<br/>读取MIB]
    C --> D{MIB中cellBarred?}
    D -->|barred| E[排除该小区<br/>搜索其他SSB]
    D -->|notBarred| F[根据pdcch-ConfigSIB1<br/>找Type0-PDCCH搜索空间]
    F --> G[监听SI-RNTI<br/>接收SIB1]
    G --> H{SIB1中cellBarred?}
    H -->|barred| E
    H -->|notBarred| I[检查PLMN是否匹配<br/>信号是否满足q-RxLevMin]
    I -->|不满足| E
    I -->|满足| J{检查需要的Other SI<br/>是否在广播?}
    J -->|正在广播| K[在SI窗口中<br/>监听SI-RNTI接收]
    J -->|未广播| L[触发On-demand请求<br/>Msg1或Msg3方式]
    L --> M[基站开始广播]
    M --> K
    K --> N[获取完整系统信息<br/>成功驻留小区]

    style N fill:#4CAF50,color:white
    style E fill:#f44336,color:white
    style A fill:#2196F3,color:white

实战调试要点：

• 手机"不能驻留"问题：抓MIB → 看cellBarred → 抓SIB1 → 检查PLMN和信号强度
• 手机"不能重选"问题：抓SIB2/SIB3 → 检查重选参数和邻区配置
• 手机"耗电快"问题：检查SI窗口长度是否过长，导致手机监听时间太长
• On-demand请求失败：检查PRACH资源和SIB1中的si-RequestConfig

十二、SI-Area：系统信息的区域概念

5G引入了SI-Area的概念：同一组系统信息可以在多个小区之间共享。

为什么需要SI-Area？

在密集城区，相邻小区的很多系统信息其实是相同的（比如地震预警、时间信息、异系统邻区配置）。如果每个小区都独立广播，就是巨大的浪费。

SI-Area的运作

• SIB1中的si-AreaInfo字段定义了该SIB所属的SI-Area标识
• 手机移动到同一SI-Area内的另一个小区时，可以直接复用之前收到的区域级SIB
• 只有跨SI-Area移动时，才需要重新接收

设计精妙之处：这本质上是"广播"与"缓存"的平衡——区域级信息可以缓存复用，减少重复接收的开销；小区级信息每次都必须读最新版本，确保准确性。

十三、工程实践中的常见陷阱

陷阱1：Value Tag误解

手机存的Value Tag是一个5位无符号整数（0~31），溢出时会回绕到0。如果手机长时间关机，醒来后可能Value Tag已经回绕了好几圈，导致误判"SI没变"。实际处理中，手机开机或重选到新小区时，应该忽略缓存的Value Tag，重新读取所有SI。

陷阱2：SI窗口内没收到怎么办

SI窗口是有限长度的。如果手机在整个窗口内都没有检测到SI-RNTI调度的PDCCH，不一定是基站没发——可能是信道条件差。手机应该等到下一个SI周期再尝试，而不是认为"该SI不存在"。

陷阱3：On-demand请求的时序

手机发出On-demand请求后，基站不会立即广播——它会在下一个修改周期或SI窗口开始时才广播。这意味着On-demand获取有延迟，对时延敏感的信息（如紧急预警）不应该配置为按需获取。

陷阱4：SSB索引与SIB1调度

在FR2（毫米波）中，基站用64个波束扫描SSB。手机通过PBCH中的SSB索引知道自己在哪个波束上。但SIB1的PDCCH搜索空间是所有SSB共享的，手机需要正确解析MIB中的pdcch-ConfigSIB1才能找到正确的搜索空间。调试时如果发现SIB1解调失败，先检查MIB的PDCCH配置解析是否正确。

常见问题

Q: MIB和SIB1为什么必须始终广播，不能也改成On-demand？ A: 因为手机没有任何先验信息时，必须先获得MIB才能知道怎么找SIB1，获得SIB1才能知道其他SI怎么获取。如果把MIB或SIB1改成按需，手机就连"怎么请求"都不知道——这是一个"鸡生蛋蛋生鸡"的问题。所以Minimum SI是广播链的基础，不可替代。

Q: 为什么不把所有信息都放进MIB或SIB1里？ A: 两方面考虑。一是信令大小限制：MIB只有几十个bit（PBCH载荷有限），SIB1也不能太大（受PDSCH传输块限制）。二是更新效率：如果把不常变更的信息（如时间信息）放进SIB1，每次时间更新就要重发整个SIB1，反而增加开销。分层设计让"经常变的信息小而快，不常变的信息大而慢"。

Q: 4G手机和5G手机在系统信息获取上有什么体验差异？ A: 对用户来说几乎无感知差异。但5G手机在空闲态通常更省电——因为不需要监听所有SIB的广播窗口。4G手机不管需不需要，每个SI周期都要醒来监听；5G手机只在需要特定SIB时才请求，其他时间可以安心"睡觉"。

Q: 基站怎么决定哪些SIB广播、哪些On-demand？ A: 由运营商通过OAM配置。通常的策略是：SIB2/SIB3（重选参数）设置为广播（因为所有手机都需要），SIB6/SIB7（紧急预警）设置为广播（时延敏感），而SIB8（CMAS）、SIB17（定位辅助）等不常用的设置为On-demand。不同运营商的策略可能不同。

Q: SI消息中的SIB可以跨SI消息吗？ A: 不可以。一个SIB只能完整地映射到一个SI消息中，不能拆分到多个SI消息。但一个SI消息可以包含多个完整的SIB。这是一种"一对多"的映射关系，不是"多对多"。

参考来源

1. 5G NR System Information: MIB, SIB1, and the SIB Catalog — 3glteinfo提供的5G NR系统信息完整参考
2. ShareTechnote: 5G MIB/SIB详解 — ShareTechnote的5G MIB和SIB技术详解
3. Ericsson: SI Scheduling Enhancement — 爱立信技术博客关于SI调度增强的深度分析
4. 5G On-Demand SI Acquisition Framework and Performance Evaluation — IEEE论文，分析On-demand SI的性能
5. On-Demand SIBs in 5G - LinkedIn — 5G按需SIB机制的技术解读

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。