做NR/5G无线网络优化和协议栈开发这一年我几乎天天跟“On demand SI”这个词打交道。很多从LTE转过来的工程师第一次看到SIB配置里的notBroadcast状态都会懵系统信息老老实实周期广播不就行了吗为什么还要搞一个“按需”出来这个疑问非常典型也是理解5G空口设计思路的一把钥匙。这篇内容不是教科书式罗列协议条目而是我从信令分析、邻区配置和现网排障里攒下来的实战经验围绕On demand SI的触发机制、信令流程、参数配置和典型避坑思路展开适合做无线网优、基站研发、终端协议栈调试的朋友参考。1. 按需SI到底解决什么问题1.1 从最小SI到其他SI一张广播表引发的开销问题先说一个基础概念5G NR里的系统信息分两类一类叫最小SIMinimum SI包括MIB和SIB1这是终端接入小区前必须拿到的“入场券”另一类是其他SIOther SI泛指SIB2到SIB14这些业务相关的系统信息比如小区重选参数、邻区列表、地震海啸告警配置、GPS时间同步、V2X/侧行链路配置等。在4G LTE里这些信息基本都由基站不管有没有人需要按照固定周期在天线上广播UE只要盲检调度就能拿到。LTE这么做问题不大因为LTE系统信息总量小、业务场景相对统一广播开销可以接受。但到了5G情况完全变了。NR支持的子载波间隔、带宽、帧结构组合非常多最小SI和其他SI的数量和复杂度都比LTE高不少再加上5G要覆盖增强移动宽带、超可靠低时延通信、海量机器类通信这些差异巨大的业务如果还把几十种SIB全部周期广播空口资源会被大量无效调度占据。我举个例子你就明白了。一个普通的城区宏站如果SIB2、SIB3、SIB4、SIB5这些重选和邻区相关的SI全部采用短周期广播再加上SIB6到SIB10这些极少被读取的告警类、时间类SI也同步广播在轻负载时段系统信息开销能占到下行资源的一定比例。对于一个大带宽的5G小区这部分浪费也许不明显但对专网小站、室内分布系统这种带宽有限的场景影响就很直接了。On demand SI正是为了解决这个“无差别广播导致资源浪费”的问题才被设计出来的。1.2 周期广播、按需广播与专用下发三态机制On demand SI并不是简单地把广播关掉而是引入了三态机制具体状态体现在SIB1的si-SchedulingInfo字段中状态一周期广播periodic broadcast。这是传统方式SIB按配置周期在SI窗口里调发任何UE都能直接解码不需要额外请求。状态二按需广播on-demand broadcast。SIB1里明确把这个SI标记为notBroadcast但配置了对应的请求资源。UE发现需要这个SI时先发起请求gNB收到请求后在下一个可用SI周期里临时广播这个SI或者调整调度策略持续广播一定时间。状态三专用下发dedicated delivery。这部分主要针对连接态UEUE通过专用信令向gNB请求某个SIBgNB不通过公共广播信道下发而是直接在RRC消息里点对点发送给单个终端。很多人会把状态三和状态二混淆实际上应用场景差异很大。状态二适合空闲态、非激活态的UE因为它们还没有建立专用连接用公共请求通道成本最低状态三适合已经进入连接态的UE比如终端需要读取某个特定SIB做测量或配置更新直接走专用信令更高效也避免了大范围广播对自己小区造成额外干扰。这个设计思路用一句话总结就是把“广播资源”从无条件供给改成了“按需分配”。它和云资源的按量付费逻辑很像广播通道是稀缺资源每一条SIB的发送都占用PDCCH/PDSCH资源用多少人请求就发多少没人请求就不发这是5G比4G更精细化的资源管理思想的典型体现。实际测试中如果把全部Other SI都设为按需SIB公共信道的负载下降确实明显但也会带来后面第3、4部分要讲的一系列后遗症。2. 按需SI的请求与调度机制2.1 两条请求通道PRACH前导和RRC消息按需SI的请求不是随便发一个信号就行UE必须知道“去哪里请求、用什么东西请求”。协议规定了两种请求通道具体用哪条要看gNB在SIB1里下发了什么配置。第一种通道是基于PRACH专用前导的请求。gNB在SIB1里通过si-RequestConfig给UE配置一套专用随机接入资源这套资源的细节包括哪些PRACH时机RO可以用来请求SI、使用哪个前导序列、请求窗口多长等等。UE发现自己需要的SIB是notBroadcast状态时就在这些专用RO上发送对应的前导序列。gNB侧物理层检测到这个前导后就知道有终端在请求某个SI。这个方式的好处是UE不需要从空闲态进入连接态发一个前导就能触发基站安排广播开销最小、时延也可控。第二种通道是基于RRC消息的请求。UE在随机接入过程中通过CCCH逻辑信道发送RRCSystemInfoRequest消息消息里携带si-RequestedSIBs信息明确告诉网络“我需要SIB3、SIB5”。为什么在有了PRACH请求之后还需要RRC消息因为PRACH前导的格式和数量是有限的一个小区能配置的前导序列总数有限当SIB种类多、请求量大时纯靠前导映射容易不够用。RRC消息可以携带明确的SIB列表表达能力更强。实际网络里往往两种方式同时配置UE会先判断有没有可用的PRACH请求资源有就用前导请求没有或前导请求失败就回退到RRC消息请求。连接态UE还有一条专属通道通过DedicatedSIBRequest这类专用请求消息向gNB申请SIBgNB收到后可以把SIB内容封装在RRC重配置消息里下发给UE。这个通道在R16之后用得更频繁尤其是在载波聚合、RedCap等新特性引入后很多SIB信息并不适合公共广播专用下发反而更精准。2.2 gNB响应与SI窗口调度请求之后发生了什么UE发出请求之后gNB并不是马上把SIB发出来而是遵循一套调度逻辑。以PRACH前导请求为例gNB检测到前导后会判断这个SI是不是允许按需广播、当前小区负载是否允许临时广播。如果允许gNB会在接下来的SI周期内在对应的SI窗口SI window里调发这个SIB。这里有个容易出问题的点每个SI消息在它自己的周期里被发送而SI窗口的长度由si-WindowLength配置发送的具体位置则根据si-SchedulingInfo和系统帧号计算得出。UE只有在正确的时间窗内监听PDCCH才能在下行共享信道上读到这个SI。如果UE和gNB对窗口起点、窗口长度的理解不一致或者请求成功后的首个发送周期距离请求时刻太长UE可能已经等到超时表现就是“明明请求成功了但就是读不到SIB”。从gNB角度看处理按需请求还有一些隐藏策略。比如有些设备会设置“请求有效窗口”在这个窗口内多次出现SI请求gNB会合并处理只安排一次广播有些设备会根据最近的请求次数动态调整SI的广播状态如果短时间内同一个SIB被大量请求就把临时广播转成长周期广播减少反复响应带来的处理开销。这些策略都是厂商实现细节协议并不强制但直接影响用户体验。2.3 SI窗口与等待时延的取舍按需SI的时延取决于SI周期和请求通道的配合。如果SIB1里配置的某个SI周期比较长比如640ms甚至1280ms那么UE完成一次按需请求到真正读到SIB最坏情况可能要等接近一个完整SI周期。对这个时延敏感的终端来说这是不可接受的。所以现网里对通话建立、紧急业务依赖的SIB一般不敢设置成纯按需而对那些本就是“偶尔用一次”的SI比如某个告警SIB、时间同步SIB可以放心地提高周期或完全按需。我做性能测试时习惯对照检查一张表这里也放出来供参考系统信息主要用途是否适合按需备注MIB读取PBCH获取SFN、SSB子载波偏移等否最小SI必须周期广播SIB1接入核心参数、PLMN、TAC、SI调度信息否最小SI必须周期广播SIB2服务小区重选参数视情况重选相关建议周期广播SIB3同频重选邻区信息视情况邻区变动时影响测量建议周期广播SIB4异频重选邻区信息视情况异频邻区多时建议周期广播SIB5系统间重选信息视情况涉及4G/5G互操作建议周期广播SIB6/7/8ETWS/CMAS告警否紧急消息必须能随时下发SIB9GPS时间同步适合按需可显著降低常发开销SIB10/11其他公共警告视情况取决于地区法规要求SIB12/SIB13V2X/侧行链路配置适合无V2X终端时可完全按需SIB14RedCap相关能力指示适合取决于是否有RedCap终端这张表不是固定的具体哪些SIB周期广播、哪些按需要和业务场景结合。后面第4部分我会讲一些具体的配置原则。3. 实战从小区搜索到按需SI的完整信令流程3.1 PSS/SSS、MIB与SIB1先对齐才能谈请求很多刚接触5G信令分析的人对On demand SI的整个触发链路比较模糊其实链路起点不是SI本身而是最基础的小区搜索。UE开机或重选到一个新频点后第一步是检测PSS主同步信号和SSS辅同步信号这两个信号的作用是让终端拿到物理小区ID、完成时域和频域同步。网上搜“pss/sss在5g nr中是什么意思”答案其实就是它们是NR同步信号块SSB里的固定成分UE先读到它们才能确定PBCH的位置再往下读MIB。MIB承载在PBCH信道上内容不多但包含了关键的pdcch-ConfigSIB1字段。这个字段告诉UE去哪找SIB1对应的PDCCH搜索空间和PDCCH公共搜索空间配置。UE按照这个指引去监听PDCCH再在PDSCH上把SIB1解出来。SIB1是所有SI调度的“总目录”里面既有最小SI自身需要的参数也有其他SI的调度列表、广播状态和请求资源。在这个链条里按需SI的开关信息就藏在SIB1里。UE一旦发现某个SIB的si-BroadcastStatus是notBroadcast就会去查同一条配置里有没有si-RequestConfig有的话就准备发起请求。所以从信令分析角度第一眼要看的不是某一条原子消息而是SIB1里的SI调度表这个习惯会让你少走很多弯路。3.2 一次按需SI请求的信令时间轴我以一个空闲态UE需要读取SIB3同频重选邻区为例把完整流程展开UE完成小区搜索读取PSS/SSS得到PCI和同步信息。UE读取PBCH/MIB根据pdcch-ConfigSIB1配置找到SIB1的PDCCH和PDSCH资源。UE解码SIB1检查si-SchedulingInfo发现SIB3的状态是notBroadcast同时查到si-RequestConfig里配置了专用的PRACH请求资源。UE在配置的PRACH时机上发送专用前导序列请求目标SIB3。gNB物理层检测到前导确认这是SI请求而不是普通随机接入。如果配置允许gNB在随后的SI窗口周期里广播SIB3。UE在SI窗口监听PDCCH找到SIB3的调度完成解码。如果UE在等待SIB3的过程中移出了覆盖区、或gNB始终没有调度SIB3UE会触发定时器超时重新选择小区或发起普通随机接入流程。看起来不复杂实际现网里这一步能玩出很多花样。比如第4步如果PRACH专用资源和普通随机接入的PRACH资源发生冲突或者两个终端选择了同一个RO和同一前导序列就会发生碰撞。gNB物理层检测到的可能是冲突后的结果请求失败后UE会等待超时重试。再比如第5步gNB不是所有SIB都允许按需广播如果UE请求的是一个被网络策略禁止按需的SIBgNB会直接忽略这个请求UE就会一直读不到。另外要注意UE发PRACH前导之后并不一定走完整的随机接入四步流程。SI请求前导可以被特殊处理gNB可能只给一个RAR响应然后单独调发SI而不继续后续的Msg3/Msg4。这也是为什么有些终端日志里能看到“SI请求成功但没有完成RRC连接建立”的现象其实是正常行为不是异常。3.3 RRC释放值513630与T304带来的坑在实际信令日志分析中很多朋友会碰到类似0x513630的RRC释放值。这个值经常出现在UE侧日志的RRCRelease信令里特别是在一个小区上发起按需SI请求后迟迟拿不到SIB时。我的经验是它往往不是协议标准里的独立cause值而是设备厂商在releaseCause为other时附带的自定义内部原因码用来表示“本流程因等待SI超时/随机接入失败等原因被释放”。排查这一类问题不能只盯释放值本身要把前面几步对齐第一步看SIB1里的SI广播状态和请求资源配置确认UE确实发起了请求第二步看MAC层有没有发送PRACH前导、PHY层有没有检测到RAR第三步看T304定时器的运行情况。T304是用来约束随机接入过程的定时器终端发送前导后启动在收到竞争解决消息或判断RAR成功后停止。如果T304超时说明整个随机接入流程失败UE会认为这个小区暂时不可用进而触发小区重选或上报失败。有一类典型的“按需SI T304超时”叠加场景UE在边缘小区请求按需SIPRACH发送功率不足或前导被邻区干扰gNB根本没有检测到请求T304超时后UE释放连接日志里就看到0x513630。这种问题从RRC消息上根本看不出异常必须降到物理层/MAC层联合看。处理办法也简单要么调整请求资源所在RO的功率参数要么把对应SI改回周期广播避免边缘UE陷入请求-超时的死循环。4. 网优工程配置与典型案例4.1 邻区添加与按需SI的关系做5G邻区优化的朋友可能遇到过一种“灵异现象”NR小区邻区关系已经在网管上配置了手里拿着的终端也待在该小区里但从这个小区重选或切换到邻区时就是失败测量报告里一直找不到这个邻区的信号。查了一圈最后发现是邻区对应的SI被设置成了按需模式终端在读取邻区SIB信息时卡住了。原因在于终端要做邻区测量、判断小区是否满足重选或切换条件并不只是测RSRP/RSRQ就够了还需要读取邻区的系统信息来确认PLMN、TAC、小区标识等关键参数。如果邻区的这些SIB是notBroadcast状态而终端又被允许通过按需请求去获取那么在UE读到这些SI之前它对这个邻区的认知是不完整的。尤其在一些异频邻区、跨厂商邻区场景下SIB信息获取链路更长出问题的概率更大。所以现场做NR邻区批量添加时我的建议是新建邻区关系时先确认对端小区的SIB1里SI调度状态和当前现网策略一致不能出现一边小区广播SIB3/SIB5、另一边却把这些SI设为按需的情况。邻区数据核查不要只盯PCI、频点、G-NCC这些常规字段要把SI广播状态也纳入批量核查脚本里。特别是在同一个区域内存在不同版本、不同配置模板的基站混跑时最容易踩到这种隐蔽的不一致。4.2 关键参数配置建议不是所有SIB都适合按需部署On demand SI最忌讳“一刀切”。我在现网里踩过一次很深的坑某个项目刚开通时为了追求“极致的频谱效率”把所有Other SI全部改成按需模式SIB2到SIB5全部notBroadcast。结果终端从小区的覆盖边缘进入小区后迟迟拿不到重选参数导致邻区测量上报延迟切换成功率肉眼可见地往下掉。后来我们总结了一套相对稳妥的参数配置原则与接入、移动性强相关的SIB建议保持周期广播至少SIB2/SIB3/SIB5要广播。它们直接影响UE能否顺利完成小区重选、正确上报邻区一旦按需边缘终端的控制面时延会变差。与特定业务强相关的SIB按业务加载来决定。比如港口5G专网里大量使用无人集卡和视频回传终端这些终端基本不涉及V2XSIB12/SIB13完全可以按需但港口龙门吊区域如果有精准定位需求SIB9GPS时间就得按现场终端能力评估不能盲目按需。告警类SIB永远不要按需。ETWS/CMAS这类公共预警消息必须能随时下发设置成按需等于在关键时刻自断喉咙。对连接态UE经常要查询的SIB建议走专用下发而不是按需广播。专用下发只影响单个终端不影响公共信道而且时延更可控。我见过一份驾考科目三场景的方案测试车辆上用5G路由器做视频回传和远程控制场地范围小、终端数量少、移动路径固定。这种场景下SIB2/SIB3周期广播、其他SI按需是完全没有问题的终端连接时间短按需SI对路由器功耗和设备待机也有好处。但同样一份配置用在城市密集居民区结果就可能完全不同因为终端进出小区的频率高、重选频繁按需SI带来的参数获取时延会被放大很多倍。4.3 从信令日志里快速定位配置问题排查On demand SI问题我习惯按下面几步操作已经形成肌肉记忆了第一步抓UE侧modem log过滤SIB1消息展开si-SchedulingInfo逐个SIB确认广播状态。这里先判断是周期广播、按需广播还是不存在。第二步查看SIB1里有没有配置si-RequestConfig以及si-RequestConfig里的PRACH配置是否合理比如RO周期、频率偏移、前导格式。第三步看MAC层日志里有没有对应的SI请求前导发送记录再对照PHY层检测结果确认gNB有没有收到。第四步如果用了RRCSystemInfoRequest过滤CCCH消息展开si-RequestedSIBs确认请求内容是否和预期一致。第五步也是很多人会漏掉的查看SIB1里每个SI的周期和SI窗口长度计算一下UE从发起请求到下一个SI发送窗口之间要等多久排查是否因为周期过长导致上层协议等待超时。这套操作下来90%的按需SI问题都能定位到具体环节。剩下的10%要么是基站版本和终端版本对按需SI特性的支持不一致要么是PRACH资源规划冲突需要结合网管侧告警和空口环境做更深层的联合分析。5. 常见问题与排查技巧实录5.1 问题现象、原因与解法速查表把我在多个项目里遇到的典型问题整理成一张速查表方便现场排查时对号入座问题现象可能原因排查思路与解法UE不发起按需SI请求SIB1里未配置si-RequestConfig或PRACH资源与其他资源配置冲突检查SIB1配置确认为notBroadcast的SI都关联了请求资源核查PRACH资源配置和普通随机接入资源是否重叠请求发了但一直收不到SISI周期太长、SI窗口位置计算不一致、gNB未响应对比UE侧和gNB侧对si-WindowLength、调度偏移的计算尝试把对应SI周期调短或改为周期广播验证待机场景下频繁T304超时按需SI请求前导在边缘覆盖场景下发送失败查看PRACH发送功率和RO配置检查是否存在邻区干扰必要时将关键SIB改回周期广播日志频繁出现RRC释放值513630等待SI超时导致的RRC连接释放或失败联合查看T300/T304计时器运行情况和随机接入过程确认释放是网络主动还是终端超时邻区添加后无法重选/切换邻区SIB状态不一致目标小区把关键SI设为按需核查源小区和目标小区的SI广播状态确保SIB3/SIB5等邻区信息相关SI可被终端获取突发大量终端同时请求SI按需SI触发窗口集中PRACH请求资源不足增加SI请求专用RO密度或对这些终端配置专用前导池评估是否把高请求量的SIB改为周期广播这张表里的内容我基本都在现网里遇到至少一种。越是看起来“偶发”的问题越要先从SI广播状态入手因为这属于公共配置影响面大且隐蔽。5.2 现场调试中的几条独门心得排查On demand SI问题经验比工具更重要我分享几条比较实用的经验。第一数据分析时不要把“SI请求”和“普通随机接入”混在一起看。很多终端UE在发起按需SI请求时用的PRACH前导和普通接入前导是不同的。如果日志过滤时只看了随机接入全过程会把SI请求前导当成异常接入漏掉。建议把MAC层的前导ID和gNB侧配置的SI请求前导集合做一次映射对比先确认UE用的是不是SI专用前导。第二对齐gNB侧调度日志。按需SI涉及的VoIP、PDCCH调度在大话务场景下是动态变化的单纯的UE侧日志只能看到“我没收到”看不到“基站没发”。如果能抓gNB侧日志哪怕只是调度记录排查效率会翻倍。现场没有基站侧日志权限时至少把UE侧请求时刻和SIB1里的SI周期对齐判断一下UE等待的窗口是不是已经超出了网络配置的容忍范围。第三注意UE实现差异。不同芯片平台对按需SI的支持实现并不完全一样。有的平台在PRACH请求失败后会自动回退到RRCSystemInfoRequest有的平台只会傻等重试。同一款基站配置在A平台终端上表现正常换到B平台上可能就出现“请求后读不到SI”的现象。遇到这类情况不要马上怀疑基站配置先换一台同平台终端复测或者查看终端侧版本说明里对On demand SI特性的支持描述。第四eCall和紧急呼叫场景特别敏感。紧急呼叫流程对系统信息的依赖非常强一旦终端处于一个将大量SIB设为按需的小区紧急呼叫建立过程可能因为等待SI而明显变慢。按照国家规范和运营商要求语音相关、紧急呼叫相关的小区配置必须保证SIB2和SIB5周期可用这个在配置审计阶段就要卡死。5.3 从RRC建立失败反推按需SI配置还有一种常见问题通过“反推”来定位。某小区RRC建立成功率低大量RRCSetupRequest发出后收不到RRCSetup。从终端日志看终端先发起了按需SI请求随后又发起RRC建立请求中间有短暂的时间差。这种情况十有八九是终端在发起RRC建立前必须读取某个SIB而这个SIB是按需状态终端先请求SI又很快发起RRC连接两个流程的前导在PRACH信道上碰撞了。处理思路是给RRC建立和SI请求分配不同的前导或RO从时间和频率上错开两类流程。如果这个小区本身业务量不大直接把那个SIB改成周期广播问题立刻消失。这也是我一直强调“关键SIB不要为了省资源而全部改按需”的原因之一按需SI节省的资源如果因为一个碰撞问题导致RRC建立失败、用户感知变差那省下来的那点资源根本不值当。写在最后实话说On demand SI这个特性被很多刚接触5G的人当成一个可有可无的“高级开关”但真正跑过现网就知道它是一把需要非常小心使用的刀。我在一个港口专网项目里曾经心大把所有SI都改成了按需结果无人集卡在跨小区行驶时频繁出现视频回传卡顿原因就是终端在小区边界反复请求SI、反复超时。后来把SIB2、SIB3改回周期广播只保留SIB9、SIB12这些低频SI按需一切恢复正常。按需SI的正确姿势不是“全部开”或“全部关”而是分类管理跟接入、移动性、紧急业务相关的SI老老实实广播跟特定业务、低频场景相关的SI放心按需。如果你在项目里也正在做类似配置调整我建议先做一轮现网终端兼容性测试再逐步批量调整别图一时省事把后面的坑都埋上。