简介5G(NR)网络中的SIB2系统信息块2是UE进行同频、异频和异系统小区重选的核心依据属于OSI消息类型根据SIB1调度进行广播。这份文档面向5G网络优化与运维工程师系统梳理了SIB2的主要功能、传输流程及关键信息单元帮助读者理解小区重选机制并据此调整网络参数。文档内容涵盖SIB2在BCCH/DL-SCH/PDSCH信道上的传输细节、SI-RNTI扰码方式以及小区重选公共信息、服务小区频率信息、同频测量门限如SIntraSearchP/SIntraSearchQ、SMTC配置和t-ReselectionNR-SF等参数结合3GPP TS 38.304说明其应用场景。同时介绍了小区级或区域级广播特性以及按需发送与周期发送两种SIB消息类型。资料为docx格式共1个文件压缩包约291KB已有393人学习适合作为5G网络优化、参数配置和故障排查的参考笔记。1. 5G(NR) 系统消息 SIB2接入失败先翻它别只盯 SIB1新站开通那天UE 在路边显示满格信号也能读到 SIB1可一发起呼叫就掉回空闲。这种现场很常见很多人第一反应是查小区选择参数其实真正该翻的是 5G(NR) 系统消息里的 SIB2。SIB2 承载的是 UE 发起随机接入要用到的公共配置PRACH 时频资源在哪、前导码序列怎么选、Msg1 目标功率设多少、RAR 窗口和竞争解决定时器多长。UE 读不到 SIB2或者参数与帧结构、覆盖不匹配Msg1 根本发不出去空口上连 RRCSetupRequest 都见不到。这篇按“调度链路 → 字段拆解 → 解码验证 → 踩坑 → 诊断”把 SIB2 讲透适合 5G 基站协议测试、网优和终端日志分析的人。2. 系统消息调度骨架SIB2 在 5G 协议栈里从哪里来什么时候下发2.1 SIB1 是目录SI message 是正文SIB2 的调度链路5G NR 的系统消息不再是 LTE 那种“MIB 一堆 SIB 各自广播”的散装结构。协议栈把系统消息分了两层MIB 走 PBCHSIB1 走 PDCCH/PDSCH 调度其余 SIB包括 SIB2打包进 SI message 里再由 PDCCH 用 SI-RNTI 加扰调度。UE 要拿到 SIB2得先走完一整条链路从 PBCH 读 MIB拿到 pdcch-ConfigSIB1定位 Type0-PDCCH 公共搜索空间。在这个搜索空间里监听 SI-RNTI 调度的 PDSCH收 SIB1。解析 SIB1 里的 schedulingInfoList找到 SIB2 被映射到哪个 SI message。在对应 SI message 的 SI 窗口内用 SI-RNTI 盲检 DCI再收 PDSCH最后从 systemInformation 容器里把 SIB2 抽出来。到这里你就会发现一个关键点SIB2 自己没有独立的广播周期。它的发送节奏完全由所在 SI message 的 si-Periodicity 决定常见的配置范围在 rf8 到 rf512 之间也就是 80ms 到 5120ms。SIB1 里还有一个 si-BroadcastStatus 字段如果某个 SI message 被配成 notBroadcasting那 UE 只有通过按需系统消息请求才能拿到对应的 SIB。这也是后面排查“SIB2 明明配了却收不到”时最容易忽略的地方。2.2 UE 何时读 SIB2驻留、重选、连接态和系统消息变更从 UE 侧看读 SIB2 的时机比很多人想的要窄。开机入网时UE 在驻留流程里会按 SIB1 的目录把需要广播的 SIB 都读一遍但真正用到 SIB2 字段是发起 RRC 连接之前那一下。也就是说SIB2 是给“准备发 Msg1”的 UE 用的不是给“已经连接”的 UE 用的。小区重选后情况不一样。UE 换了小区必须重新读 SIB1并按新的 schedulingInfoList 刷新 SIB2。这点很坑重选后的新小区和你原小区的 PRACH 配置几乎不可能一样如果终端实现里有“沿用旧小区 RACH 参数”的优化很容易导致重选后第一次接入失败。连接态和非活动态要分开看。连接态下RACH 参数由 RRCReconfiguration 里的专用配置下发UE 不再监听 SIB2非活动态发起小包传输时如果网络把 SIB2 配成了按需广播UE 还得先通过 SI request 把 SIB2 要回来。另外系统消息变更通知走的是 paging 里的 systemInfoModification 字段位置在 SIB1 关联的寻呼配置里和 SIB2 本身无关但变更生效只在系统消息修改周期边界调试时改了参数想立刻看效果得等下一个周期。2.3 和 LTE SIB2 差很多NR 把上行配置拆开了从 4G/5G 通讯切过来的人最容易犯的错是拿 LTE SIB2 的字段清单去套 NR。LTE 的 SIB2 是一个“radioResourceConfigCommon”大杂烩里面除了 RACH 配置还有 PUCCH、PUSCH 的公共配置、上行功率控制公共参数、频率信息等一堆东西。NR 把这一大包拆了上行公共信道的配置被放到了 SIB1 的 initialUplinkBWP 和后续的专用信令里SIB2 只剩三块职责——randomAccessChannelConfig、rach-ConfigCommon以及 uac-BarringInfo。寻呼配置也上移到了 SIB1不再像 LTE 那样放在 SIB2。所以排查 NR 随机接入问题注意力应该集中在 SIB2 的两个 RACH 配置块上而不是像 LTE 那样还要查 SIB2 里的 PUCCH 资源。NR 的做法更干净理解成本也低但前提是你已经知道“SIB2 只负责接入那一跳”。3. 拆开 SIB2 主要字段RACH 配置的前台与后台参数3.1 randomAccessChannelConfigPRACH 时频资源与前导码序列SIB2 里第一个大块是 randomAccessChannelConfig它决定了 Msg1 在物理信道上怎么发。这块字段不多但每个都是牵一发动全身。prach-ConfigurationIndex 是网优调得最多的一个取值范围 0 到 255查 38.331 里的表格才知道具体含义。它同时决定了前导码格式、PRACH 在时域上的起始位置、持续时间和周期。TDD 帧结构下这个字段尤其要命PRACH 时域位置一旦落到下行时隙UE 发了 Msg1基站侧在下行时隙根本不开 PRACH 接收窗结果就是“UE 认为发了基站认为没收到”。msg1-FDM 取值 one/two/four/eight表示把 PRACH occasion 在频域上复制几份。FDM 从 2 提到 4PRACH 容量直接翻倍但占用的 RB 也翻倍。initial UL BWP 不宽的小区加 FDM 前要先算够不够放。msg1-FrequencyStart 是第一个 PRACH occasion 相对初始上行 BWP 起始位置的频域偏移配合 msg1-FDM 一起看能确认 PRACH 资源有没有超出 BWP 边界。msg1-SubcarrierSpacing 是 PRACH 的子载波间隔。FR1 常见 15 或 30kHzFR2 常见 60 或 120kHz。这个字段和 SCS 配错的话终端和基站对 PRACH 符号长度的理解直接对不上。restrictedSetConfig 取 unrestrictedSet、restrictedSetTypeA、restrictedSetTypeB。高铁、高速场景下要用受限集用不受限集的话高速移动带来的多普勒频移会把前导码相关峰拉平检测概率掉得很难看。prach-RootSequenceIndex 是根序列索引二选一l839 是长序列偏向覆盖增强l139 是短序列NR 常规建网的主力。根序列规划不好相邻小区之间的 PRACH 会互相干扰这个干扰还不是平均分布的往往集中在两个小区的交界处。3.2 rach-ConfigCommon目标功率、窗口与竞争解决的平衡rach-ConfigCommon 是 SIB2 里另一个大块它管的是 Msg1 到 Msg3 这一整段的行为参数也是随机接入成功率最敏感的地方。pra-PreambleReceivedTargetPower 是网络希望收到的 Msg1 功率取值跨度很大典型目标功率在 -90dBm 上下。这个值调高等于让 UE 开更大的功率发前导码远点用户接入概率能上来但全网的干扰也变大调太低近点没感觉远点直接变成“有信号发不出去”。ra-ResponseWindow 是 Msg1 发出去之后 UE 等 RAR 的时间窗口枚举从 sl1 到 sl80。配太短基站 RAR 还没调度出来UE 就放弃这次尝试开始回退重试配太长接入时延变大用户体验变差。ra-ContentionResolutionTimer 是竞争解决定时器枚举 sf8 到 sf64。这个值在实际调网里经常被忽略但竞争模式下 Msg3 发出去之后UE 要靠这个窗口等网络回竞争解决消息。窗口太短本来能解决的竞争被提前判定失败后续就是无谓的 Msg3 重传。还有一组字段是配套用的numberOFRA-PreamblesGroupA 和 messagePowerOffsetGroupB。NR 把 64 个前导码分成 GroupA 和 GroupB小包 UE 走 GroupA大包 UE 走 GroupB。GroupA 前导码数量太少小包业务全挤在一起撞messagePowerOffsetGroupB 设太大UE 很难被分到 GroupB大包用户也往 GroupA 挤。这俩是容量和时延之间的平衡杆。rsrp-ThresholdSSB 做的是 SSB 与 PRACH occasion 的关联选择。UE 测量到某个 SSB 的 RSRP 高于这个门限才会选对应的 PRACH occasion 发 Msg1。这个值如果落到边界附近基本等于不做 SSB 差异化所有 UE 均匀地挑 PRACH 资源。3.3 网管参数与 ASN.1 字段映射给一份可对照的表很多人的问题是网管告警单上写的参数名和 38.331 里的字段名对不上。下面这张表是我平时对照用的基本覆盖了现网最常见的映射关系。网管/脚本常见名SIB2 ASN.1 字段取值要点PRACH 配置索引prach-ConfigurationIndex0~255查 38.331 表格Msg1 频分复用数msg1-FDMone/two/four/eightMsg1 起始 RBmsg1-FrequencyStart相对初始上行 BWP 起始PRACH 子载波间隔msg1-SubcarrierSpacingFR1 常用 15/30kHzPRACH 根序列索引prach-RootSequenceIndexl839 或 l139前导码初始接收目标功率pra-PreambleReceivedTargetPower典型 -90dBm 附近RAR 接收窗口ra-ResponseWindowsl1~sl80竞争解决定时器ra-ContentionResolutionTimersf8~sf64组 B 功率偏置messagePowerOffsetGroupBminusinfinity/dB0/dB3/dB6/dB9组 A 前导码数量numberOFRA-PreamblesGroupAn4~n64SSB 关联 RSRP 门限rsrp-ThresholdSSB边界 0 约等于不设门限字段拆完顺手可以用一小段脚本估算 PRACH 容量避免把 FDM 开过头。下面这个脚本做的事很简单根据来自 prach-ConfigurationIndex 查表得到的时域 occasion 数量算每秒钟可用的 PRACH occasion 数。# 根据 SIB2 里的 PRACH 配置估算每秒可用 occasion 数 prach_period_ms 20 # 由 prach-ConfigurationIndex 查表得到单位 ms occasion_per_period 10 # 查表得到每个周期内的时域 occasion 数 fdm 4 # SIB2 里的 msg1-FDM 配置取 1/2/4/8 occasions_per_s occasion_per_period * (1000 / prach_period_ms) * fdm print(f每秒钟 PRACH occasion 数: {occasions_per_s:.0f}) # 结论FDM 从 2 提到 4occasion 数直接翻倍但占用 RB 也翻倍这里几个量都是查表或读 SIB2 字段拿到的。prach_period_ms 和 occasion_per_period 不是 SIB2 里的直接字段而是由 prach-ConfigurationIndex 对应到 38.331 表格后的结果fdm 直接来自 msg1-FDM。实际规划时先看 initial UL BWP 的带宽能不能吃下“msg1-FrequencyStart msg1-FDM × 每 occasion 占用的 RB”再考虑要不要靠 FDM 扩容量。4. 把 SIB2 从配置变成字节流解码验证与日志采集4.1 用 pycrate 按 38.331 解码一条 SIB2配置参数只是纸面内容真正能证明基站发的是想发的东西还得靠解码。我常用的办法是用 pycrate 直接编译 38.331 的 ASN.1 文件然后把从 Uu 口日志里剥离出的 SIB2 净荷喂进去。pycrate 是开源库接口稳定适合做 RRC 消息的离线解码验证。# 用 pycrate 解码一条已剥离出来的 SIB2 净荷 from pycrate_asn1rt.utils import compile_asn1files # 准备 38.331 及依赖的 ASN.1 文件后一次性编译 # 如果只有一个主文件可以改用 compile_asn1file效果等同 rrc compile_asn1files([ TS_38.331_RRC-ASN.1.asn, TS_38.321_MAC-ASN.1.asn, ]) SIB2 rrc[SIB2] # 实际抓包后从 systemInformation 容器里提取出的 SIB2 octet 串 # 这里只是示意真实码流长度一般在几十到几百字节 raw bytes.fromhex(... 替换成你抓到的 SIB2 负荷 ...) sib2_obj SIB2() sib2_obj.from_aper(raw) print(sib2_obj.to_asn1())这段脚本里compile_asn1files 会把 ASN.1 文件里的所有消息类型编译进来rrc[SIB2] 拿到的是 SIB2 的类型定义from_aper 把 APER 字节流填进这个 ASN.1 对象to_asn1 把解码结果打印成可读的字段树。注意空口上 SIB2 是先嵌在 BCCH-DL-SCH 的 systemInformation 消息里的上面这个脚本只负责解“已经剥离出来的 SIB2 净荷”提取容器那一步需要靠抓包工具或协议分析仪先完成。如果要在脚本里改字段再重编码pycrate 对应的方法是 set_val 和 to_aper。比如把竞争解决定时器改成 sf64sib2_obj[rach-ConfigCommon][ra-ContentionResolutionTimer].set_val(sf64) reencoded sib2_obj.to_aper()这种改字段再重编码的方式适合做“如果基站把某字段配成 XUE 收到的字节流应该长什么样”的回归验证。改完后把 reencoded 和现网抓到的码流对比能快速确认是不是有字段被网管下发了、但 SIB1 的调度里没带出来。4.2 采集 SIB2 日志的三个入口与前置条件解码的前提是先把 SIB2 抓到。实际工作里我见过三种入口成本从高到低第一种是 Uu 口探针或协议分析仪直接在空口解调 PDCCH/PDSCH拿到的 SIB2 最干净也最容易定位是基站发的问题还是终端读的问题但设备价格摆在那不是每个项目都配。第二种是 UE 工程模式日志很多终端在工程模式下会打印 BCCH-DL-SCH 上的系统消息能直接看到 SIB2 的完整 ASN.1 解码。便宜但对终端型号和固件版本有要求有些终端会把系统消息过滤掉只留连接态消息。第三种是基站侧的 Uu 抓包这种方式需要基站有调试通道一般是研发环境或集采测试环境才有。好处是能和基站的发射配置做时间对齐坏处是抓到的包是基站内部编码后的结果不一定能直接对上 UE 视角的调度。不管走哪条路前置条件有三个抓包点必须在小区广播覆盖范围内抓包时 UE 必须在空闲态或非活动态连接态下 UE 根本不读 SIB2想抓变更后的 SIB2得先触发系统消息更新比如在网管上改一个 SIB2 参数然后用 paging 里的 systemInfoModification 指示配合抓包。4.3 三个字段反推基站意图解码完成之后不要急着抄字段先看几个关键值能不能对上网络规划意图。pra-PreambleReceivedTargetPower 落在 -90dBm 附近说明这是常规覆盖配置如果网管把它压到 -100dBm 以下多半是覆盖补强策略网络期望 UE 用更高的功率发 Msg1代价是干扰上升如果冲到 -80dBm 以上大概率是容量优先近点用户接入稳但远点用户会很难受。prach-ConfigurationIndex 值得多做一步查表确认 PRACH 的时域周期和起始位置再和 tdd-UL-DL-ConfigurationCommon 的帧结构对照。这一步能提前发现“PRACH 被配到了下行时隙”这种致命问题不用等现网指标出来。rsrp-ThresholdSSB 如果落在边界值附近基本可以确定网络没有做 SSB 级差异化接入如果它是一个中间值比如对应 -100dBm 左右说明网络想把弱波束的 UE 引导到更强的 SSB 上再发前导码。这个字段在多层波束场景里很有价值单波束宏站里反而容易被人忽略。5. SIB2 配置避坑记录PRACH 索引、根序列与解码版本的五条教训5.1 配置层面帧结构、GroupB 门限与根序列干扰第一条坑是 PRACH 配置索引与 TDD 帧结构打架。现象是 TDD 站点开通后近点 UE 的 Msg1 检测率也不高统计里 PRACH 接收次数少得可怜。原因是 prach-ConfigurationIndex 对应的时域位置落在了下行时隙或者 msg1-FrequencyStart 把 PRACH 顶到了 BWP 边缘。解决方法是先按 38.331 的 PRACH 配置表核对索引和 tdd-UL-DL-ConfigurationCommon 的时隙方向再检查 msg1-FrequencyStart 加 msg1-FDM 占用的总 RB 有没有超出初始上行 BWP。这个顺序不能反先查时域再查频域因为时域错了的话频域算得再准也没用。第二条坑是 GroupA/GroupB 配置失衡导致小包竞争失败。现象是微信、心跳类小包业务的 UE 频繁出现 Msg3 重传竞争解决成功率低。原因是 numberOFRA-PreamblesGroupA 配得太小小包 UE 全挤在 GroupA 的十几个前导码里或者 messagePowerOffsetGroupB 设成了过大值导致本该走 GroupB 的大包 UE 也往 GroupA 挤。解决方法是把 GroupA 前导码数量调到 32 以上并把 messagePowerOffsetGroupB 按规划收敛到 dB3 左右然后继续观察碰撞统计。调完别只看平均指标要分段看近点和远点。第三条坑是相邻基站根序列规划不到位。现象是两个相邻宏站的交界区域随机接入成功率周期性掉坑而且都集中在同一侧。原因是相邻小区的 prach-RootSequenceIndex 在 139 长度下选得过近ZC 序列的互相关抬升了虚检。解决方法是做 PRACH 根序列规划同覆盖重叠区留足序列间隔高速场景还要把 restrictedSetConfig 切换成受限集一起考虑。根序列规划不太可能靠参数调整救回来必须在频率规划阶段就做好。5.2 空口与版本层面SIB2 没广播、终端解码校验失败第四条坑是 SIB2 根本没被广播但网管侧看起来一切正常。现象是全网终端驻留都正常唯独某小区 UE 不发起 Msg1该小区 PRACH 接收次数长期为 0。原因是 SIB1 的 sib-MappingInfo 里没有把 sib2 映射进任何 SI message或者某个 SI message 的 si-BroadcastStatus 被配成了 notBroadcasting。UE 读完 SIB1 找不到 SIB2按协议就不会触发随机接入。解决方法是检查 SIB1 里 schedulingInfoList确认 sib2 被挂到至少一个 SI message 上并且该 message 的广播状态是 broadcasting。改完这个配置以后系统消息变更要等修改周期边界生效不要指望立刻看到 UE 行为变化。第五条坑是 38.331 版本差异导致解码失败。现象是旧版终端的测试卡能正常解码 SIB2新版本终端反而失败或者反过来。原因是不同版本的 38.331 对 SIB2 的字段 optional 属性和取值集合有增删尤其像 mbs-FDM、msg1-TransmissionPower 这类扩展字段基站按新版本编码出来的 SIB2在旧版协议栈上可能校验不过。解决方法是做版本兼容矩阵商用前用最老和最新两端的协议栈版本分别抓 SIB2 对比字节流网管里尽量不开启非必需的扩展字段避免把老终端挡在门外。6. 用 SIB2 字段诊断随机接入一份组合定位表6.1 从失败特征反查 SIB2 字段组合定位表单独看一个字段很难定问题但把失败特征和几个字段组合起来看命中率会明显提高。下面这张表是我在现网排查时常用的组合定位表。失败特征先查字段重点核对近点 Msg1 都检测不到prach-ConfigurationIndex、msg1-FrequencyStartPRACH 时域位置是否撞下行时隙频域是否超出初始 UL BWP远点 Msg1 检测率低pra-PreambleReceivedTargetPower、prach-RootSequenceIndex目标功率是否偏低根序列是否有相邻小区干扰Msg3 竞争老是失败ra-ContentionResolutionTimer、numberOFRA-PreamblesGroupA竞争解决窗口是否太短GroupA 前导码是否太少能读 SIB1 但发不起 Msg1SIB1 的 sib-MappingInfo、SIB2 的 uac-BarringInfoSIB2 是否被广播是否被 UAC barring 挡住表格里第一行最常见它是开站时的“一票否决项”第二行在处理远点投诉时很有用先看目标功率再看根序列别一上来就动功率把序列干扰误判成覆盖问题会越调越偏第三行多发生在高话务小区调完还要观察一段时间竞争问题往往和用户模型强相关。6.2 建立“参数-日志-环境”三点对照习惯我个人的习惯是把 SIB2 参数分成三类覆盖类pra-PreambleReceivedTargetPower、rsrp-ThresholdSSB、prach-RootSequenceIndex、容量类msg1-FDM、numberOFRA-PreamblesGroupA、时延类ra-ResponseWindow、ra-ContentionResolutionTimer。每次调完参数让 UE 侧打点 RSRP按 RSRP 分段看 Msg1 检测率和竞争失败率再决定是功率问题、序列干扰还是帧结构问题。有一回我只盯着小区平均 RACH 成功率调参压了几个版本不见好后来把 RSRP 分段一拉远点 Msg1 检测率低得离谱根本不是竞争问题就是前导码目标功率配置太低。从那以后我每动 SIB2 的参数都要求 UE 侧同时出 RSRP 分桶统计参数、日志、环境三点对齐以后再下结论。希望帮到你。本文还有配套的精品资源点击获取