企业官网建设流程全解析

简介：这份围绕5G新空口系统消息SIB2的专题文档《5G(NR)网络中系统消息SIB2及主要字段》以Word格式提供，面向5G网络优化与运维人员，重点解读NR系统消息中SIB2的调度机制、信息单元和重选参数，解决工程师对同频、异频及异系统小区重选规则理解不深的问题。资源包内为1个docx文件，压缩包体积约291KB，内容密度高，适合随身查阅。文档除说明SIB2属于OSI消息、按SIB1调度并可周期或按需发送外，还完整拆分了小区重选公共信息、服务小区频率信息和系统间重选信息三类信息单元，对Q-RxLevMin、Q-QualMin、SIntraSearchP/Q、SMTC、ssb-ToMeasure及t-ReselectionNR-SF等字段逐一给出含义与应用场景，并说明了同频测量是否触发的门限判断逻辑；同时整理了BCCH、DL-SCH、PDSCH的信道映射以及SI-RNTI扰码细节，便于理解gNB到UE的下行广播路径。目前已有393人学习，适合具备4G基础、正在向5G优化转型的工程师用作速查手册和参数调优参考，尤其适合需要快速掌握广播消息结构、制定重选策略的网优人员。

1. 从“终端开不了口”说起：5G(NR)网络 系统消息SIB2及主要字段到底在讲什么

某次外场测试，测试终端一直注册不上，空口日志里MSG1发了四五次都没有MSG2回来。几个人围着参数表查了半天，最后发现终端解码到的SIB2里ra-ResponseWindow和基站侧配置对不上——终端在等RAR的窗口已经关掉了，消息才从基站出来。这个场景基本代表了5G(NR)网络里SIB2及主要字段的真实分量：它管着终端进入小区后第一次“开口说话”的规矩，也就是随机接入。它不像SIB1那样负责准入和调度，但接入过程里几乎每个关键参数：前导、功率、时序、波束映射，全部装在这条系统消息里。这篇文章写给做网优、协议测试和基站研发的从业者，目标是让你拿到一条SIB2解码日志后，能逐字段看懂它在说什么，排障时不至于靠猜。

2. 系统消息的接力赛：SIB2是怎么“递”到终端手里的

要读懂SIB2，先得知道它在空口上是怎么被终端找到的。很多新手拿着信令日志，过滤了SIB2但半天抓不到包，不是因为消息没发，而是因为SIB2根本不像MIB那样固定周期广播。它被装在某条SI消息里，什么时候发、发多久，全由另一条系统消息说了算。

2.1 MIB到SIB1再到SIB2：谁在告诉UE“去哪收消息”

NR的系统消息分了好几个接力棒。终端先盲扫SSB，从PBCH上拿到MIB。MIB非常短，真正有用的核心信息就是pdcch-ConfigSIB1，它指向调度SIB1的控制资源集和搜索空间。终端靠这个信息解到SIB1，SIB1里有一张关键的调度表叫si-SchedulingInfo，这张表列出了所有SI消息的调度周期、窗口长度和窗口起点偏置，SIB2就挂在其中一条SI消息下。换句话说，UE拿到MIB只看得到SIB1，拿到SIB1才知道SIB2在哪，SIB2没有一个独立的“全球固定周期”。

从排障角度理解：SIB2的接收窗口是SIB1给的，所以排查抓不到SIB2时，第一步要解SIB1里的si-SchedulingInfo，看目标SIB2被分配在哪个SI里、周期多长。常见做法是直接看基站的系统消息调度配置表，确认SIB2所在SI的global period和si-WindowLength，然后把信令软件的过滤条件对准这个时间窗。抓包时最好让终端触发一次RRC_IDLE到RRC_CONNECTED的完整流程，因为空闲态发起业务前，终端会老老实实把需要的SIB收齐，这正是SIB2出现的集中时段。

2.2 SIB1管“能不能进”，SIB2管“怎么开口”？

SIB1和SIB2的分工，用一句话概括：SIB1是门口的保安，SIB2是屋里的前台。SIB1负责小区选择准入，手里拿着PLMN列表、小区选择的最低RSRP门限、统一接入控制参数，还顺带把其它所有SIB的调度信息捎上。终端读完SIB1，才能判断这个小区让不让进、接入控制放不放开。而SIB2管的是终端决定进来之后，怎么发起随机接入：用什么前导格式、在哪个时频位置发MSG1、以多大功率发射、发完等多久收RAR、波束和RACH occasion怎么对应。

这两个角色不要混。实际排查时经常有人把接入失败一概归到“SIB1的门限设太高”，其实终端明明已经过了小区选择、进入了随机接入流程，那问题大概率在SIB2携带的RACH参数上。我一般遇到“接入起不来”的案例，先看SIB1的cellSelectionInfo，确定终端是不是连门都没进；如果终端已经发出MSG1，立刻转去分析SIB2里的RACH-ConfigCommon块。这样一分，排障范围当场缩小一半。

另外有个优先级关系必须讲清楚：SIB2里的RACH参数是公共配置，只对没有专用RACH配置的UE生效。终端一旦进入RRC_CONNECTED，又通过RRC重配置拿到了rach-ConfigDedicated，那后续的切换、波束失败恢复等随机接入一律按专用配置走，SIB2就不起主导作用了。很多协议工程师会忽略这一层，拿着SIB2的参数去解释一个正处于连接态的UE的接入行为，就会得出完全相反的结论。

2.3 从LTE的SIB2到NR的SIB2：番号没变，表全换了

如果你是从LTE转过来的，对SIB2会很有亲切感，但这份亲切感在NR现场容易害人。LTE里SIB2包含RACH配置、BCCH配置、PCCH配置，是一个“公共无线资源配置大杂烩”。NR的SIB2结构上收敛了许多，核心就是RACH-ConfigCommon，附带一些上行公共配置相关的内容，职责更聚焦。这算好事，但也埋了一个坑：两边有些字段名一模一样，查表方式和取值范围完全不同。

最典型的就是prach-ConfigurationIndex。LTE时代这个字段只有0到63共64个配置，查一张表就行，前导格式就那几种；NR里面按前导长度、FR1还是FR2、成对还是不成对频谱，协议准备了好几套PRACH配置表，短序列格式下索引可以到255。如果用LTE的脑子和LTE的表格去校验NR的参数，看到64以上的索引第一反应就是“配置非法”，然后开始翻基站侧日志，折腾半天最后才发现是自己拿错了表。所以本文后面所有关于字段的讨论，都以NR的协议基础为准，别把LTE习惯带过来。

3. 拆开SIB2的主干：RACH-ConfigCommon关键字段与现场含义

SIB2里你可以记不住其它所有IE，但必须把rach-ConfigCommon里这块RACH-ConfigGeneric吃透。它就是整个随机接入MSG1的“发射规格书”。下面先把字段全貌拉一张表，再逐个讲现场怎么理解。

这张表里的每一个字段，终端和基站必须完全一致，差一个字节，接入就可能有玄学问题。下面挑最容易被用错的几组展开讲。

3.1 MSG1发射许可三件套：prach-ConfigurationIndex、msg1-FDM、msg1-FrequencyStart

prach-ConfigurationIndex是整个RACH配置里第一个要核对的字段。它不是“随便给一个数字就行”，而是要到38.211的PRACH配置表里查对应的前导格式、时域起始位置和每时隙重复次数。现场核定这个参数时，我一般先确认小区是FR1还是FR2、成对频谱还是不成对频谱，再按对应的表查配置。FR1的TDD小区尤其要小心：PRACH时域位置不能落在纯下行时隙里，最好也不要和SSB burst抢资源，否则MSG1和下行信号互相干扰，终端发得出去但基站收不稳。

msg1-FDM是PRACH在频域的复用度，语义是“同一个时刻并排安排了几个PRACH频域位置”。这个参数直接关系接入容量，但很多人只当它是一个数字。典型宏站配2或4，高容量或大话务场景配8，覆盖边缘或低频段有时候配1。它的代价是频域资源占得多，会把PUSCH能用的RB挤掉一块。排障时看见随机接入冲突率长期偏高，优先确认这里是不是配小了；但如果配了8还冲突，那问题就不在复用度上，多半在根序列或SSB映射那一层。

msg1-FrequencyStart指PRACH相对上行BWP起始RB的偏移位置。这个字段本身很少出问题，出问题往往是因为改了上行BWP的起始RB和大小，忘了同步调整PRACH的频域起点，结果PRACH或者超出BWP边界，或者和PUSCH的起始位置重叠。所以每次BWP参数调整完，回头看一眼这个字段是很好的习惯。频率域的这三个参数在信令日志里是一组出现的，我判断MSG1“能不能发、发在哪”就看它们三个，一个不对就停下来，不去动其它地方。

3.2 功率与等待窗口：preambleReceivedTargetPower、powerRampingStep、ra-ResponseWindow怎么配

preambleReceivedTargetPower决定终端第一次发MSG1的目标接收功率。UE侧的实际发射功率大致按“路径损耗估计＋该目标功率”来算，再被终端最大发射功率限制。很多人理解成“这个值越大接入越稳”，实际翻车常出在这：目标功率抬高了，近点UE被逼着用更大的功率发前导，整个小区的上行干扰底噪一下子被拉起来；边缘UE则更快碰触到最大功率上限，后续没有爬坡空间。覆盖一般的宏站配-100 dBm附近比较常见，要结合站间距和边缘RSRP水平来权衡。看到接入成功率低就盲目调这个值，不如先看一眼边缘UE的前导接收功率分布。

powerRampingStep是MSG1失败后的功率爬坡步长，可选dB0/2/4/6。步长太小，边缘UE要尝试很多次才能爬到目标功率，接入时延拉长；步长太大，功率猛增，容易从“检测不到”跳到“干扰一片”。常见的习惯是覆盖场景用2 dB，极差覆盖场景偶尔用到4 dB，但一旦用了4 dB，要同步确认前导最大尝试次数是否撑得住，别爬两三次就把次数用光。这个参数在基站侧往往和maxNumPreambleAttempt这类上限参数配套出现，改的时候两个要一起看。

ra-ResponseWindow是MSG1发出后等待RAR的时间窗口，最容易踩坑的地方在于：它的单位是slot，不是毫秒。同样配sl20，在15 kHz子载波间隔下是20毫秒，在30 kHz下变成10毫秒，在60 kHz下只有5毫秒。现场如果拿LTE的思维看这个参数，会觉得数值没问题，但配合NR高频段的numerology一换算，实际等待时间短了一半。FR1常见配置在sl10到sl40之间，具体要看基站调度RAR所需的时间余量。如果终端侧频繁报MSG1发了没响应，先别怀疑覆盖，把ra-ResponseWindow按当前SCS换算成毫秒，和基站实际回RAR的时间戳放在一张图里比一下，往往真相就在几毫秒的差距里。

3.3 波束与容量博弈：ssb-perRACH-OccasionAndCB-PreamblesPerSSB、根序列与冲突率

这个字段是NR比LTE复杂得多的核心差异点，名字很长，实际上同时表达了两层含义：周期内每个RACH occasion上有多少个SSB关联，以及每个SSB对应多少个基于竞争的preamble。比如常见的oneEighth + n8，含义是8个SSB共享一个RACH occasion，每个SSB分到8个前导；配one + n64则是每个SSB独占一个RACH occasion，且给满64个前导。

这里的核心约束是一个RACH occasion里可用的基于竞争前导数总量有限，通常就是64个。如果用SSB数乘上每SSB前导数，结果明显超过这个上限，配置就要重新想。宏站8波束如果配one + n64，每个RO只服务一个波束，8个波束就要8组RO资源，时域频域开销很大；配oneEighth + n8，8个波束挤在一个RO里，资源省了，但每个波束只有8个前导，高峰期冲突率必然抬头。这是一笔典型的容量换资源的博弈，现场没有绝对正确的值，只有“够不够用”。

prach-RootSequenceIndex负责生成前导的根序列，取值范围按前导长度走，长序列和短序列各查各的区间。这个字段的现场意义主要在邻区规划：相邻小区如果根序列索引太近，前导之间的互相关峰容易误检，UE在A小区发的MSG1被B小区“听到”，随即引发乱响应。改这个字段时我会顺手把周边三圈的PCI和根序列拉一张表，确认没有同索引或近索引冲突。顺带说一句，如果随机接入冲突率高但上面所有映射参数都合理，根序列冲突是非常值得怀疑的下一站。

3.4 空口抓SIB2：从日志过滤到参数比对的六个步骤

知道字段之后，下一步是把它从空口日志里挖出来。完整的排查步骤我习惯这样走：

1. 准备支持NR的测试终端，接入目标小区，触发一次完整的空闲态到连接态流程，比如发起一次数据业务。
2. 在通用信令跟踪软件里按系统消息过滤，先落MIB和SIB1，确认终端已成功解到这两条。
3. 从SIB1的si-SchedulingInfo里找到SIB2所属的SI消息，确认SI窗口长度和周期，把日志过滤窗口对准这一段。
4. 导出SIB2的RRC container原始十六进制数据，用本地维护的38.331 ASN.1定义文件做一次离线解码，得到完整的RACH-ConfigCommon树。
5. 将解码结果与基站侧配置台账逐字段比对，重点关注第3.1到3.3节提过的八个字段。
6. 如果空口解码和台账完全一致，但MSG1仍然失败，把排查重心从参数层移到物理层：天线通道、馈线、射频校准，SIB2参数不是黑匣子，但射频链路经常是。

最后一步是很多协议测试的人容易忽略的。我接过不止一个案例，基站后台配置是好的，信令跟踪里解码出的SIB2字段却是旧值，最后定位在配置生效链路没走完；也有参数全对但MSG1就是没信号的情况，查半天发现射频通道故障。所以SIB2的参数解读，一定要和“基站实际发出来的是什么”对照，只看配置表不看空口解码，等于没查。

4. 避坑指南：SIB2/RACH配置现场最常踩的五个坑

这一章是把前面那些“注意”集中起来，按现场最真实的踩坑记录写。每一条我都尽量按现象、原因、解决三步说透，希望能帮你少走弯路。

4.1 ra-ResponseWindow是slot不是毫秒：RAR总超时的元凶

现象：终端MSG1已经发出去了，基站侧也看到MSG1收到了，甚至RAR已经调度下发，但终端侧就是认为没有收到MSG2，一直重发MSG1。排查日志里MSG1重传次数明显增加，且每次都伴随RAR超时。

原因：ra-ResponseWindow配的是slot数，不是毫秒数。现场有人拿LTE时代的数值惯性直接填，或者在30 kHz子载波间隔下依然按15 kHz去理解，实际等待时长缩了一半甚至更多。还有一种情况是窗口起点计算时没把MSG1结束后的处理时延算进去，留给基站的调度时间不够。

解决：先确认当前小区的上行子载波间隔，把ra-ResponseWindow的slot值换算成毫秒，用基站侧RAR调度时间戳和终端侧窗口结束时间戳做一张对比图。窗口结束时间必须晚于RAR实际下发时间，留出至少几毫秒余量。调整时优先考虑加sl数，而不是去动MSG1的时域位置。

4.2 功率爬坡被“前置目标”卡死：preambleReceivedTargetPower不是越大越好

现象：边缘UE接入成功率长期偏低，但近点UE几乎正常。有人把preambleReceivedTargetPower往上调，期望UE发更大功率的前导，结果边缘没变好，整网底噪反而抬升，部分小区的上行干扰指标恶化。

原因：目标接收功率调高，终端按“路损估计＋目标功率”发射，整体发射功率都被推高。近点UE发射功率提升对解调没帮助，只是白白增加干扰；边缘UE则更快触到最大发射功率上限，爬坡空间被压缩。

解决：回到覆盖本身看问题，先确认边缘UE测到的SSB RSRP和路损估计是否正常。如果确实需要调目标功率，建议一次只调2 dB，观察边缘接入成功率的同时盯住底噪和干扰余量。升级思路是把powerRampingStep和maxNumPreambleAttempt一起微调，而不是单点放大目标功率。

4.3 SSB与RACH occasion映射乘积溢出：冲突率升高的隐蔽原因

现象：小区随机接入冲突率居高不下，但MSG1发射功率、接收功率、RAR窗口都看着正常。冲突率曲线有周期性，且和SSB波束扫描周期隐隐对得上。

原因：ssb-perRACH-OccasionAndCB-PreamblesPerSSB配置时只看了单SSB的前导数，没算“一个RACH occasion上绑定的SSB数乘每SSB前导数”是否超过可用总前导数。当8个SSB压进一个RO，每SSB只能分到少量前导，业务一忙，不同UE抢同一前导的概率迅速上升。

解决：把该RO的SSB数量和每SSB前导数乘起来，对比一个RO的总可用前导数。容量敏感的小区建议把ssb-perRACH-Occasion从oneEighth改成one或two，给每个波束更多的独立RO资源；资源受限的小区则要接受容量上限，并用msg1-FDM适当扩展频域复用度来补容量。

4.4 拿LTE的prach-ConfigIndex惯性套NR：一个常见翻车现场

现象：协议测试人员拿到NR的SIB2解码日志，看到prach-ConfigurationIndex等于某个超过64的值，立刻判定基站配置非法，然后拉着基站工程师反复核对，几个小时过去才发现问题出在自己的判断标准上。

原因：LTE的PRACH配置表只有64条，NR则按前导格式、FR1/FR2、成对不成对频谱准备了多张表，短前导格式下索引范围更宽。用LTE的取值区间去卡NR的配置，本来合法合理的参数会被误判成“越界”。

解决：团队里所有参与RACH参数核对的人，手里都放一份当前版本对应的38.211 PRACH配置表，而不是靠记忆。核对时把“索引—前导格式—起始时隙—重复次数”四项一起查，不要只看索引数字。这个习惯能避免大量无谓的跨部门扯皮。

4.5 SIB2不是“一直广播”的：抓不到包先查调度窗口

现象：信令跟踪软件里注册了SIB2解码事件，结果等了很长时间一条SIB2都抓不到，有人开始怀疑终端解码问题或者基站没配SIB2。

原因：SIB2不是像MIB那样固定80毫秒滚动的消息，它挂在SI消息里，而SI消息的调度窗口和周期由SIB1的si-SchedulingInfo控制。如果SIB2所在SI的周期较长（比如几百毫秒甚至更长），抓包窗口没对准，或者终端一直处于连接态不需要重新系统消息，自然看不到SIB2。

解决：先解出SIB1，把si-SchedulingInfo里的SI周期和窗口长度读出来，据此设置信令跟踪的过滤时间窗；再强制终端回一次空闲态再注册，让终端重新走“收SIB→接入”流程。想更省事，可以在测试终端里开启工程模式的系统消息日志，直接记录每次收到的SIB报文及接收时间，对比一下就清楚是不是调度窗口没对准。

5. 把SIB2做成日常工具：一张体检表加两个排查习惯

SIB2的字段一个一个讲很容易，真正难的是日常排查时能快速定位。我最后分享一个自己长期使用的“SIB2体检表”和两个排查习惯，希望能帮你把前面的内容落成可执行的日常动作。

5.1 一页纸体检表：七个字段的参考区间

这七个字段我每次处理接入问题都会在十分钟内过一遍。没有异常就先别动SIB2，转去查物理层和射频链路，效率比盲目调参高得多。

5.2 两个排查习惯：先看底牌，再看表象

第一个习惯：任何一次接入类问题，先导出一条SIB2解码结果贴进工单，再谈其它指标。SIB2是接入过程的“底牌”，底牌没确认，后面讨论路测RSRP、干扰余量都是空中楼阁。我吃过亏，有一次在覆盖和干扰上折腾了一天，最后回头看SIB2解码，发现终端收到的根序列索引和基站台账根本不是同一套，配置生效链路的问题十分钟就定位了。

第二个习惯：改任何一项物理层参数前，都把SIB2对应字段的旧值、新值和解码结果三个一起存档。RACH参数之间耦合度高，改了一个字段往往牵动另一组表现，不存档很难回溯到底哪一步把问题改出来的。现在每次外场交接，我的工单里都固定附上SIB2解码截屏和一张字段对比表。这个习惯已经帮我避开了好几次“改来改去最后忘了初始状态”的尴尬，算是多年排障攒下的血泪经验吧。希望帮到你。

本文还有配套的精品资源，点击获取