简介这份文档系统讲解5G(NR)网络中系统消息SIB2的构成与主要字段面向5G网络优化工程师、运维人员及通信专业学习者。SIB2属于开放系统信息OSI承载同频、异频和异系统小区重选所需的关键参数其发送分为周期性广播和按需on-Demand两种方式。文档从传输信道DL-SCH、逻辑信道BCCH、物理信道PDSCH及扰码SI-RNTI入手逐层解析SIB2的传送格式随后详细梳理信息单元小区重选公共信息、服务小区频率信息Q-RxLevMin、Q-QualMin等、同频小区重选信息SIntraSearchP/SIntraSearchQ门限、SMTC测量配置、ssb-ToMeasure位图并对照3GPP 38.304标准解释参数含义与缺省行为帮助读者理解UE测量、重选触发及速度控制机制。资源为单份docx文档大小291KB内容精炼便于随时查阅。目前已有393人学习适合需要深入掌握SIB2细节、优化5G网络参数与用户体验的从业者作为参考。1. 5G(NR)网络里的SIB2一份管着重选决策的“冷门”系统消息5G(NR)网络里终端从开机驻留到呼叫结束每一步都离不开系统消息。网优和协议栈开发盯得最多的通常是SIB1——小区接入、RACH配置、上下行带宽都在里面可等到现场出现“终端在覆盖边缘死都不重选”“信号已经到-115dBm了还吊在5G上不回落”这类问题时翻遍SIB1也找不到答案。这时候要打开的就是SIB2NR系统消息里负责小区重选公共参数和服务频点参数的那一份。它字段不多但每一个都直接影响终端在什么信号水平下启动邻区测量、按什么优先级选目标频点、在目标小区上停留多久才算数。这篇笔记写给做开站调测、网络优化、协议栈log分析的工程师按“SIB2在哪→字段怎么读→log怎么核→参数怎么调”把落地路径讲透。2. SIB2在NR系统消息里的位置从MIB到SIB2的调度链路与周期参数2.1 先读SIB1再读SIB2调度信息藏在schedulingInfoList里5G(NR)的系统消息分两批MIB和SIB1属于“最小系统消息”终端只要完成小区搜索和PBCH解调就能拿到SIB2及以后的SIB都归入“Other SI”靠SIB1里的调度信息告诉终端什么时间、在哪个窗口去收。很多刚转NR的同事会问为什么不直接在MIB里把SIB2指出来因为MIB只有32比特连SIB1的完整位置都放不下更别说给后面的SIB排队。完整读取路径是这样的终端先解PBCH上的MIB拿到pdcch-ConfigSIB1也就是CORESET0和SearchSpace0的位置然后在这个公共搜索空间里监听SIB1的调度解出SIB1接着在SIB1的schedulingInfoList里找到sib-MappingInfo中包含sib2的那一条SI message按参数里的si-Periodicity和si-WindowLength去对应窗口监听SI-RNTI固定FFFF加扰的PDSCH才能解出SIB2。这一串动作里SIB1就是整个Other SI的“总目录”。schedulingInfoList里每一条SI message都带这几个关键字段si-BroadcastStatus表示这条SI是周期广播还是按需分发si-Periodicity决定广播周期sib-MappingInfo列出这条SI里装了几个SIB、分别是谁。SIB2在现网里几乎都是周期广播不走按需请求那条路这也是它和SIB3以后某些SIB的区别。现场抓log时如果发现UE始终读不到SIB2第一件事不是去怀疑空口覆盖而是回头查SIB1里schedulingInfoList有没有把sib2映射进一条SI message、si-BroadcastStatus是不是broadcasting。提示NR里的SIB2和LTE的SIB2不是一回事。LTE的SIB2承载RACH公共配置NR的RACH配置在SIB1里SIB2只负责小区重选相关参数。带着LTE经验直接去SIB2里找prach-Config是转NR后最容易踩的第一个坑。2.2 SIB2的广播周期与SI窗口配置权衡与常见取值SIB2的周期不是自己在SIB2里写的而是在SIB1的schedulingInfoList里由si-Periodicity决定的。NR里可选的周期从80ms一直到5120ms常见配置是160ms或320ms。SI窗口长度由SIB1里的si-WindowLength控制可选1ms、2ms、5ms、10ms、15ms、20ms。窗口的意义是在这个周期内的这个窗口区间网络侧会按顺序把该条SI message发一遍UE必须在窗口内一直监听SI-RNTI错过了就等下一个周期。调度参数可选值现场经验si-Periodicity80ms / 160ms / 320ms / 640ms / 1280ms / 2560ms / 5120ms城区默认160ms320ms覆盖边缘或高铁线建议80ms160mssi-WindowLength1ms / 2ms / 5ms / 10ms / 15ms / 20ms常用5ms或10msSI窗口太短弱场UE解调失败率会明显上升sib-MappingInfosib2sib32SIB2可单独一条SI也可和SIB3合并不建议把太多SIB塞进同一条SI周期不是越短越好。周期短UE拿到SIB2更快弱场下重选响应更及时但代价是空口资源被周期性广播占掉一部分。SIB2本身只有几十个字节一条SI message十几到几十字节的开销放在160ms周期里几乎可以忽略真正的开销在和SIB3、SIB4挤在同一个SI窗口时——只要有一个SIB周期短整条SI message都得跟着短周期广播。所以现场调整周期时我会先看这条SI message里还装了哪些SIB而不是只盯着SIB2。另一个容易忽略的点si-WindowLength是“整条SI message”的窗口不是单个SIB的窗口窗口内网络侧按sib-MappingInfo的顺序逐个发UE一帧一帧盲检窗口给太短而SI里SIB又多时最后一两个SIB往往发不完只能等下一个周期。调测阶段我习惯把SIB2周期直接压到160ms甚至80ms等重选参数验证完再放宽到320ms。原因很现实改完网管参数后要确认现场终端真的拿到了新配置周期越短反馈越快。而到了正式网络里SIB2这类公共重选参数不是频繁变化的对象没必要用80ms周期去换那点“看似更快”的响应速度。3. SIB2主要字段逐项拆解重选门限、测量节流与频点优先级3.1 cellReselectionInfoCommon4个字段决定重选要不要触发NR的SIB2在38.331里的主体是三个结构块第一块是cellReselectionInfoCommon携带的是所有小区重选都要用的公共参数。这里面的q-RxLevMin最容易被误读。它的ASN.1类型是Q-RxLevMin取值范围-70到-22单位是2dBm。也就是说协议字段里填的不是真实dBm值真实下限是字段值乘以2。你在网管上把“重选最低接收电平”配成-120dBmSIB2里实际下发的是-60如果直接拿log里的数值去和网管比对就会觉得终端读到的参数“不对”。这一块还有q-QualMin单位1dB是RSRQ维度的最低门限现网很多场景不启用s-ThreshServing是一个CHOICE只能选择threshP或threshQ中的一种下发threshP按RSRP评估、单位2dBmthreshQ按RSRQ评估、单位1dBq-Hyst是重选迟滞枚举值从0dB到24dB作用是给重选准则里的当前服务小区加一个偏置防止信号在门限附近抖动导致频繁重选。t-ReselectionNR是目标小区持续满足条件的秒数枚举覆盖0到70秒现场最常见的是1秒或2秒。这些字段的配合逻辑是服务小区信号变差后终端先看是否低于s-ThreshServing低于才允许启动重选评估评估目标小区时目标信号要持续t-ReselectionNR秒都优于服务小区算上q-Hyst的迟滞才真正执行重选。现场最常见的问题不是单个字段值错了而是q-Hyst给得太大、t-ReselectionNR给得太长导致终端明明已经走到另一个更好小区的覆盖下却迟迟不肯切过去。调这两个字段时要结合实际地貌——隧道出口、高楼阴影区这类信号突变剧烈的位置t-ReselectionNR反而不能给太短否则终端会在两个小区间来回“甩”。3.2 cellReselectionServingFreqInfo控制UE什么时候去看异频邻区第二块是cellReselectionServingFreqInfo名字看着长实际管的是“服务频点上的测量节流”和“服务频点优先级”。这里面最重要的两个参数是s-NonIntraSearchP和s-NonIntraSearchQ。它们的含义是当服务小区RSRP高于s-NonIntraSearchP时终端认为当前频点质量还够用不必启动异频测量一旦低于这个值才开始按SIB4里的异频邻区列表去做异频测量。你可以把它理解成“异频测量开关”的阈值。s-NonIntraSearchP的粒度同样是2dBm。比如想在RSRP低于-100dBm时启动异频测量s-NonIntraSearchP就要填对应-100dBm的协议值-50。需要注意的是它和threshServingLowP是两个不同维度的字段前者控制“要不要测异频”后者控制“测了之后服务小区低到什么程度才允许去更低的频点”。如果s-NonIntraSearchP配得比threshServingLowP还低就会出现一个逻辑黑洞终端一直不启动异频测量即使服务小区已经很差它也根本没机会去评估别的频点。这一块里还有个cellReselectionPriority范围0到70最低7最高表示服务频点在重选体系里的优先级。它决定的是“这个频点和其他频点谁先被考虑”不是具体门限。高优先级频点重选看的是SIB4里threshX-High低优先级频点重选看的是threshServingLowP。现场规划多频组网时我一般是先定优先级表再回头填门限顺序反了参数之间互相打架是家常便饭。3.3 高频点与低频点的重选路径SIB2和SIB3/SIB4怎么配合SIB2不是孤立的。它只给公共规则和服务频点规则同频邻区列表在SIB3异频邻区及每个异频频点的门限在SIB4。重选评估时终端按这套流程走同优先级频点之间直接用R准则谁的RSRP/RSRQ折算后高就选谁q-Hyst和t-ReselectionNR都参与目标频点优先级高于服务频点则只要目标频点高于SIB4里的threshX-High且维持t-ReselectionNR时间就重选过去目标频点优先级低于服务频点则必须先满足服务小区低于SIB2里的threshServingLowP再满足目标频点高于SIB4里的threshX-Low。业务场景SIB2关键参数SIB4对应参数效果5G覆盖好、希望终端尽量驻留5GthreshServingLowP设低如-124dBmthreshX-High设中等如-110dBm低频点更难触发高频点也容易回5G边缘掉话多、希望早点回落threshServingLowP抬高如-112dBmthreshX-High抬高如-100dBm终端更快离开5G但可能早切室内外异频协同s-NonIntraSearchP按室内外信号差分开设threshX-Low/High同频点差异化控制异频测量启动点省电这也是为什么现场只改SIB2不动SIB4问题往往解决不干净。比如把cellReselectionServingFreqInfo里的优先级抬高却没有同步抬高SIB4对应频点的threshX-High终端确实会优先考虑那个频点却因为门限太高永远够不着结果反而拖慢了整体重选。SIB2给方向SIB4给刻度两者必须放在一张表里规划。4. 从信令log里核对SIB2tshark粗筛、参数对照与生效链路4.1 把SystemInformation从pcap里捞出来过滤命令与log来源做NR协议栈或网优的同学手里最常见的材料是路测软件导出的pcapng以及测试终端高通平台用QXDM、展锐平台用抓包工具导出的空口RRC日志。这些log里SIB2是作为BCCH-DL-SCH-Message里的SystemInformation消息出现的wireshark对NR RRC的解析已经比较成熟。先用tshark粗筛出所有系统消息再定向找SIB2。# 从路测log中筛出所有NR RRC系统消息 tshark -r nr_rrc_20240610.pcapng -Y nr-rrc -T fields \ -e frame.number -e frame.time_epoch -e nr-rrc.message_type \ 2/dev/null | head -50 # 进一步限定SystemInformation消息输出为JSON供后续脚本处理 tshark -r nr_rrc_20240610.pcapng -Y nr-rrc.system_information -T json \ nr_si.json这个命令里第一行是把pcapng里所有NR RRC消息列出来确认log里确实有系统消息第二行用display filter只留SystemInformation输出成JSON。不同版本wireshark对NR RRC字段的命名不完全一致比如老版本里SystemInformation可能显示为nr-rrc.sys_info新版才统一成nr-rrc.system_information。如果你用的版本筛不出任何结果先回到第一行的全量输出里看消息类型实际叫什么再改filter条件不要硬套网上的命令。从log里拿到的SIB2通常是BER/PER编码后的比特串wireshark能展开成可读字段但前提是抓包工具没把这条消息做成OCTET STRING透传。遇到透传的情况实测最省事的做法是用wireshark的“打印为文本”把SIB2内容拷出来配合ASN.1工具离线解码想写脚本批量处理就得先把字段名吃透后面第6章会给一个可用的核对脚本。4.2 网管参数、SIB2字段和真实门限的三方对照现场核对SIB2真正要做的是把三套东西对齐网管界面上填的中文参数、38.331里SIB2的ASN.1字段、空口log里实际下发的数值。这三者之间常常有单位换算和命名差异直接对不上是正常的。网管参数常见叫法38.331字段协议范围 / 粒度log数值换算重选最低接收电平q-RxLevMin-70-22每单位2dBmlog值×2 真实dBm重选最低RSRQq-QualMin-34-6R15典型每单位1dBlog值即dB服务小区异频测量启动门限s-NonIntraSearchP与Q-RxLevMin一致每单位2dBmlog值×2 真实dBm服务频点低优先级重选门限threshServingLowP与Q-RxLevMin一致每单位2dBmlog值×2 真实dBm重选迟滞q-Hyst枚举dB0dB24log枚举对应dB值重选定时器t-ReselectionNR枚举s0s70log枚举对应秒对照表里最容易出错的是q-RxLevMin和threshServingLowP因为它们都是2dBm粒度、取值范围又是负数。我在现场的习惯是先把网管配置导出成CSV然后在wireshark里展开一条SIB2把每个关键字段按上表的换算关系算一遍最后再核对优先级和门限的搭配是否自洽。别指望厂商网管导出的XML里写的“-120dBm”能和SIB2里的“-60”直接画等号中间隔着一层协议编码这层编码就是日志分析里最典型的“黑匣子”。还有一个常被忽略的生效链路网管参数下发到CUCU生成SIB2的ASN.1编码后交给DUDU再按调度周期在空口广播。如果抓log发现SIB2内容还是旧值先确认CU侧配置确实提交成功、DU侧没有缓存旧配置再怀疑空口抓包。按照设备安装调测的常规流程开站改完数据后第一件事就是在DU/CU侧抓一条系统消息确认参数落地而不是直接拿路测终端去覆盖区里碰运气。5. SIB2调优避坑5个让终端不重选、乱重选的现场问题5.1 从LTE转NR惯性去SIB2找RACH配置现象NR站点开通后同事按LTE的习惯打开SIB2想核对prach-ConfigRootSequenceIndex结果在SIB2结构里找不到任何PRACH相关字段怀疑终端读取失败或基站配置下发异常。原因这是协议版本差异。LTE里SIB2承载RACH公共配置NR里RACH配置全部在SIB1的rach-ConfigCommon里SIB2被38.331重新定义为小区重选专用。带着LTE的SIB2心智看NR必然找不到。解决核对RACH直接展开SIB1看rach-ConfigCommon。顺手在SIB1里看一眼schedulingInfoList确认SIB2确实被映射进去了再回头做重选参数分析。这个坑算是基础认知门槛但现场确实每个LTE转NR的团队都会翻一次车。5.2 log里SIB2的q-RxLevMin是-60网管配的是-120dBm现象网管上重选最低接收电平配置为-120dBmwireshark展开SIB2看到的q-RxLevMin却是-60误以为基站参数没有生效反复重新下发配置。原因Q-RxLevMin的取值范围是-70到-22单位2dBm。真实门限值等于协议字段值乘以2。所以-120dBm在协议里编码为-60反过来看到字段值-60说明真实门限就是-120dBm。所有基于RSRP且和Q-RxLevMin同类型的字段都有这个换算关系包括threshServingLowP、s-NonIntraSearchP、threshX-HighP后者在SIB4里。解决在做log分析时先确认字段类型再套单位换算。凡是协议里写“单位2dBm”的一律做×2处理。最稳妥的做法是把换算逻辑写进分析脚本不要靠口算特别是批量处理多个站点log时一个符号错位会带偏整个优化结论。5.3 5G频点优先级给了7终端还是死守5G不回落现象某商业区边缘5G信号已经到-118dBm终端还在5G上不发起到LTE的重选偶尔掉到4G又立刻被指挥回5G形成“假5G占用”。原因SIB2里cellReselectionServingFreqInfo的cellReselectionPriority设成了7但threshServingLowP被配到-124dBm。从5G往低优先级LTE重选必须先满足“服务小区低于threshServingLowP”-118dBm高于-124dBm条件不满足所以终端认为还没到必须离开的时候。高优先级频点不是“无脑驻留”低优先级重选的门槛在SIB2里守着。解决把threshServingLowP抬到-112dBm左右让终端在-118dBm时满足“服务小区足够差”的条件同时确认SIB4里LTE对应频点的threshX-Low不要配得过高否则目标频点那条又过不去。调整后用路测终端在边缘往返验证重选时延只看RSRP不看信令的话这类问题最容易漏。5.4 SIB2周期配成5120ms改完参数半小时不生效现象现场调重选参数网管改了threshServingLowP路测终端在原地等了快一分钟log里SIB2还是旧值以为基站没生效。原因SIB2的广播周期被配到了5120ms5.12秒这只是“网络侧把这个SI message发一遍”的周期。终端还有一个系统消息修改响应链路网络侧在寻呼里通知修改UE按修改周期去重新读取。广播周期5120ms加上UE的读取检查间隔实际生效时间被拉到几十秒甚至更久在调测现场非常煎熬。解决调测阶段把SIB2周期临时改成160ms或320ms确认参数生效后放回正式值。如果站点已商用、不想动周期那就用“改完参数立即抓取DU侧空口日志”的方式确认不依赖路测终端自然读取。商用网络里SIB2这类公共参数本来就不该频繁调整周期宁可长一点省空口开销但调测环境里周期就是你的反馈速度。5.5 s-ThreshServing里P和Q同时配了终端只按P走现象网管界面上s-ThreshServing的RSRP门限和RSRQ门限都填了值期望“哪个先触发都行”实际终端在RSRQ已经很差、RSRP还不错时不重选表现和预期不一致。原因协议里s-ThreshServing是CHOICE类型一次只能向UE下发threshP或threshQ中的一种不是两个都发。厂商网管可能把两套值都收了但映射到ASN.1编码时只取一种多数实现取RSRP。终端按收到的threshP评估时RSRQ指标再好再差都不参与s-ThreshServing判断。解决在网管配置里明确只启用一套门限另一套保持默认或留空。启用RSRP作为主评估维度时确认导出配置里threshQ没有被勾选抓log展开SIB2看到s-ThreshServing下只有threshP字段就说明编码正确。不要在配置里同时改两套值那是给自己制造现场排查的困难。6. 用一个核对脚本验证SIB2字段从wireshark JSON到配置比对手动核对SIB2在单站还能应付批量处理十几个站点的log时肉眼比对几千行JSON必然出错。我的习惯是写一个小的核对脚本输入两份文件一份是wireshark导出的SIB2字段JSON一份是网管导出的期望参数CSV脚本自动做单位换算和差值比对输出不一致的项。#!/usr/bin/env python3 # 用法python3 check_sib2.py sib2_wireshark.json cell_params.csv # sib2_wireshark.json 为 tshark -T json 导出后拍平的字段dict形如 # {nr-rrc.sib2.cellReselectionInfoCommon.q_RxLevMin: -60, # nr-rrc.sib2.cellReselectionServingFreqInfo.s_NonIntraSearchP: -50} import json, sys, csv # 需要按2dBm换算的字段 SCALE_2DBM {q_RxLevMin, s_NonIntraSearchP, threshServingLowP} def main(): with open(sys.argv[1], encodingutf-8) as f: sib2 json.load(f) with open(sys.argv[2], encodingutf-8) as f: expected {row[param]: int(row[value]) for row in csv.DictReader(f)} diff [] for proto_field, value in sib2.items(): short_name proto_field.split(.)[-1] if short_name not in expected: continue real int(value) if short_name in SCALE_2DBM: real * 2 if real ! expected[short_name]: diff.append((short_name, expected[short_name], real)) if not diff: print(all key SIB2 fields match cell params) return for name, expect, got in diff: print(fMISMATCH {name}: expect {expect}, got {got}) sys.exit(1) if __name__ __main__: main()这个脚本的核心逻辑分三步先从wireshark导出的JSON里取出字段名和值再从网管CSV里读期望值最后对声明过2dBm粒度的字段做换算后比较。CSV的格式很简单第一行列param,value第二行写q_RxLevMin,-120这种字段名要和wireshark展开后的最后一个分量一致。注意不同版本wireshark的字段名后缀可能有差异比如q_RxLevMin在某些版本里叫q_RxLevMin在另一些版本里可能带SIB2_前缀第一次跑脚本前先手动展开一条SIB2确认字段名再批量执行。脚本跑出来的不一致通常分两类一类是单位换算没对齐的假差异比如CSV里写-120、json里是-60脚本已经自动换算就不会误报另一类是真差异比如s-NonIntraSearchP在网管配了-102dBm空口下发却是-98dBm这时候要去查CU侧配置生效状态而不是怀疑脚本。做这类验证时我会把CSV期望值按场景分组——城区、郊区、室内各存一份配置基线批量核完之后覆盖到哪个站点哪个场景都一目了然。有一次批量核对时发现一个站点群全部站点s-NonIntraSearchP都偏高了4dBm才追查到是参数模板里一个单位换算的旧坑脚本一轮就把问题从几百个站点里筛出来了。这种坑靠人工翻log是翻不出来的脚本值得在项目里长期维护。希望这些SIB2的读法和排错技巧能在你下次面对重选问题时少走一段弯路。本文还有配套的精品资源点击获取