简介针对5G(NR)网络优化需求这份资料系统讲解终端小区搜索与SIB1探测全流程面向网络优化工程师及通信技术学习者。内容依据3GPP TS 38.300规范从频率调谐、PSS/SSS检测、PBCH解码到MIB解析再到基于pdcch-ConfigSIB1定位CORESET0与搜索空间、盲解DCI 1_0、按SI RNTI解析时频资源最终完成SIB1及其他SIB的解码逐层拆解每一步的关联与失败回退机制并重点说明SSB探测将同步检测与PBCH解码合二为一的优化价值。文档同时梳理了小区搜索中“获取时间与频率同步、识别小区ID”的核心目标以及SIB1所承载的小区接入参数、频率规划等关键运营信息对高移动速度或弱信号场景下的同步效率优化有直接参考意义。资源包为单个docx文档约15KB结构清晰配有分步流程梳理适合网优培训、日常自学及信令排障参考。已有375人学习下载对希望理清5G初始接入信令路径、提升小区搜索优化能力的读者很有帮助。1. 小区搜索和SIB1探测是什么终端在5G NR里的第一步手机从按下开机键到状态栏出现信号格中间隔着一连串毫秒级的空口动作先搜小区、再读系统消息、然后发起随机接入。5G NR里这套流程的起点就是小区搜索和SIB1探测。很多人容易误以为只要解到SSB、拿到MIB就算“找到网了”但实际上终端在读到SIB1之前连这个小区是否允许接入、TAC是什么、有没有IMS紧急呼叫支持都不知道。换句话说SSB和MIB只是给了终端一把钥匙SIB1才是那扇门。这篇文章把这两件事拆开讲先讲SSB上承载的PSS/SSS和PBCH/MIB如何被终端解出来再讲怎么靠MIB里的pdcch-ConfigSIB1字段找到CORESET#0和SearchSpace#0并在这套资源上监听SIB1的调度。中间穿插协议参数表、解析代码、空口日志切片以及现场排障和全网排障时怎么用这套知识快速定位问题。适合基站侧工程师、终端协议栈开发、网优和路测分析人员。2. 从SSB到MIBNR小区搜索的时频资源与测量路径2.1 SSB的时频结构与子载波间隔NR的SSBSS/PBCH block在时域上占4个OFDM符号在频域上占20个RB也就是240个子载波。PSS固定落在第1个符号SSS落在第3个符号第2和第4个符号留给PBCH。SSB的子载波间隔不是固定的它和频段、小区部署方式绑定具体关系见下表。频段子载波间隔kHzCaseSSB周期默认值msLmaxSSB最大波束数FR115Case A2046GHz下常用8FR130Case A208FR130Case B108FR115 / 30Case C108FR2120Case D2064FR2240Case E2064Lmax决定终端在小区搜索时对SSB index的盲检范围。FR1场景下SSB可能位于频带的任意位置终端先以100kHz栅格去扫频搜索找到SSB后还要靠PBCH里的kSSB字段来确认SSB与整个BWP的相对位置。这个设计是NR区别于LTE小区搜索的关键LTE只要找PSS/SSS就行NR则要求终端同时锁定SSB与整体载波栅格的关系。调测时如果发现“SSB能扫到但同步后无法读MIB”先检查SSB的子载波间隔配置是否和gNB侧实际发射一致。尤其注意Case C15/30kHz共用终端会按先验尝试两种SCS导致同步时间变长但不会失败而在纯30kHz部署下直接用15kHz去检测则会出现弱场丢同步的现象。2.2 PSS/SSS检测与PCI获取PSS在NR里有3种序列SSS有336种序列两者组合后得到物理小区ID公式很简单PCI 3 * NID1 NID2其中NID2取自PSSNID1取自SSS。# 模拟PCI解算过程给出PSS和SSS的物理层索引 pss_index 1 # NID2取值范围0~2 sss_index 233 # NID1取值范围0~335 pci 3 * sss_index pss_index print(fPhysical Cell ID {pci}) # 如果已知PCI反推PSS/SSS索引 nid2 pci % 3 nid1 pci // 3 print(fPSS index (NID2) {nid2}, SSS index (NID1) {nid1})这段代码只是复现协议里的映射公式实际终端里还要做相关检测而不是直接读索引。相关峰值的能量会折算成RSRP同时终端在检测SSB时会按符号位置记录SSB index也就是波束ID。SSB index是非常关键的测量量后面SIB1调度时PDCCH/PDSCH会按与SSB的准共址QCL关系发送波束ID对不上时SIB1的重传就会失败。5G网络开通调测时经常遇到一种现象RSRP显示信号很强但终端始终不发起随机接入。多数情况下问题出在邻区配置里PCI与SSB index对应关系填错终端读到的SSB index在邻区表里不存在于是上报测量报告会被网络忽略。所以不要只看RSRPSSB index和PCI必须放在一起看。2.3 MIB/PBCH解析pdcch-ConfigSIB1与ssb-SubcarrierOffsetPBCH上承载MIBMIB一共32比特。除了systemFrameNumber、dmrs-TypeA-Position还有两个字段对SIB1接收起决定作用ssb-SubcarrierOffset4bit和pdcch-ConfigSIB18bit。前者告诉终端SSB相对CRB栅格的频域偏移后者告诉终端SIB1的PDCCH搜哪套配置。MIB里并没有直接给出SIB1的周期或者调制编码方式SIB1的调度信息完全靠pdcch-ConfigSIB1这8个比特去查表。高4比特映射到CORESET#0的频域带宽和时域符号数低4比特映射到SearchSpace#0的聚合等级、监听周期和时隙偏移。下面这段Python代码把这个映射做成了可查表的形式# 解析MIB中的pdcch-ConfigSIB1输出CORESET#0和SearchSpace#0的参数组合 def decode_pdcch_config_sib1(value): if not (0 value 255): raise ValueError(pdcch-ConfigSIB1需为8bit范围0~255) high value 4 # 高4位对应CORESET#0配置索引 low value 0x0F # 低4位对应SearchSpace#0配置索引 return high, low for mib_val in [0, 8, 16, 32, 64, 128]: h, l decode_pdcch_config_sib1(mib_val) print(fMIB pdcch-ConfigSIB1{mib_val}: CORESET0 idx{h}, SearchSpace0 idx{l})注意高4位和低4位并不是在所有场景下都能独立取值。38.213里有一张组合表当CORESET#0带宽超过某个阈值时SearchSpace#0的候选索引会被限制在小范围内。实际开发中我习惯把这张组合表直接做成静态数组避免每次都跑完整查表逻辑。协议的意图是让终端在盲检SIB1前就缩小PDCCH的搜索范围从而降低功耗。3. 用PDCCH/PDSCH接收SIB1CORESET0与SearchSpace0参数对照3.1 从pdcch-ConfigSIB1查CORESET#0参数SIB1的调度依赖CORESET#0这里不是指RRC配置的普通CORESET而是专门用于承载SIB1相关PDCCH的公共控制资源集。CORESET#0有两个频率资源相关的关键参数frequencyDomainResources用6个比特表示20个RB分成6组后的位图duration表示时域符号数可以是1、2或3个符号。下面这张表是我整理的在FR1 15kHz下最常用的几个配置索引。pdcch-ConfigSIB1高4位CORESET#0 带宽RBduration符号数适用SCS024215kHz124315kHz248315kHz396315kHz424230kHz548230kHz终端拿到MIB里的pdcch-ConfigSIB1后先定位到这条行再结合该行指定的偏移量算出CORESET#0在频域的位置。现场排障时如果gNB侧配置的CORESET#0的持续时间是3个符号而终端按表解出来却是2个符号那SIB1的PDCCH盲检一定失败。这类问题在异厂商对接时容易遇到因为每个厂商对协议表的实现细节不完全一致。3.2 用SI-RNTI监听DCI 1_0SIB1在物理信道上并没有固定的时频位置gNB通过PDCCH上的DCI 1_0来调度。终端在SearchSpace#0里用SI-RNTI固定为FFFF去监控DCI 1_0。DCI里包含频域资源分配、时域资源分配、MCS、HARQ信息、TPC等。SIB1使用QPSK调制MCS按QPSK那一套表去解如果按16QAM以上的表去解CRC能过但数据必然解错。一个常见误区是认为SIB1周期固定为160ms。实际上SIB1在时域上被映射到一个周期为16ms或20ms的窗口里窗口内每个时隙都可能有调度这个周期由MIB之前的SearchSpace#0配置决定。所谓“5G全网排障”里有一半的SIB1接收失败问题都出在SearchSpace#0的监听时机和实际调度错位上——一个是时隙偏移配错一个是监听周期配错。# 查看SIB1是否被调度抓取PDCCH DCI 1_0并进行SI-RNTI解扰 # 这里以pcap中的dci字段为例实际数据来自modem log或路测软件导出 awk /DCI format 1_0/ /RNTI: 65535/ { split($0, fields, ,); for (i in fields) { if (fields[i] ~ /Frequency domain resource/) print SIB1 DCI found:, fields[i]; if (fields[i] ~ /Time domain resource/) print SIB1 time assign:, fields[i]; } } sib1_pdcch.log这段awk的意图是从PDCCH日志中筛出所有SI-RNTI调度的DCI 1_0记录并打印频域、时域资源分配字段。注意RNTI十进制65535就是FFFF日志里也可能打印十六进制ffffgrep的时候要同时匹配。实际项目中如果一条SI-RNTI的DCI都抓不到问题大概率在PDCCH配置本身而不是PDSCH解调。3.3 SIB1内容与小区驻留的判定SIB1成功解出来后终端才会真正知道这个小区能不能驻留。SIB1里的关键IE包括plmn-IdentityList、trackingAreaCode、cellIdentity、cellSelectionInfo含q-RxLevMin、servingCellConfigCommon、ims-EmergencySupport。终端先匹配PLMN再判断小区是否被barred然后根据RSRP是否超过q-RxLevMin做小区选择。SIB1 IE作用驻留判断中的位置plmn-IdentityList广播允许接入的PLMN列表与USIM中PLMN匹配cellBarred小区是否禁止接入禁止则该小区不可驻留intraFreqReselection同频重选是否允许与barred状态联动q-RxLevMin最低接收电平低于此值驻留失败trackingAreaCodeTAC标识决定是否触发TAUcellIdentity小区唯一标识用于邻区匹配与切换注意cellBarred和intraFreqReselection的取值会影响终端后续行为如果小区被barred但intraFreqReselection为allowed终端仍可重选到同频其他小区如果此时全网同频邻区也没配好终端就会直接脱网。5G邻区添加案例里经常出现这种情况新站SSB正常MIB正常SIB1也解出来了但终端显示“无服务”最后发现是cellBarred置1且全网同频邻区表为空。所以SIB1探测不能只看“能不能收到”还要把SIB1里的字段和网管配置对起来看。4. 现场排障终端收不到SIB1时的定位方法与常用工具4.1 分层定位SSB、MIB、SIB1逐段切开终端收不到SIB1不代表小区搜索失败。很多场景是SSB解出来、MIB也解出来唯独SIB1的PDCCH/PDSCH接收失败。定位顺序建议固定为三段先确认SSB同步成功RSRP、SNR、SSB index是否正常再确认MIB是否正确解出pdcch-ConfigSIB1最后才看PDCCH的SI-RNTI相关事件。# 三段排查的日志过滤命令通用路径按实际抓包文件调整 echo 1. SSB同步 grep -E PSS correlation|SSS correlation|SSB index|SSB RSRP log_phy.txt | head -20 echo 2. MIB解码 grep -E MasterInformationBlock|pdcch-ConfigSIB1|ssb-SubcarrierOffset|subCarrierSpacingCommon log_rrc.txt | head -20 echo 3. SIB1接收 grep -E SystemInformationBlockType1|SI-RNTI|DCI format 1_0 log_dci.txt | head -40这里把日志分为物理层、RRC层、DCI三层去过滤。第一层看SSB的同步信息和波束级RSRP第二层看MIB里的pdcch-ConfigSIB1原始值第三层看DCI有没有调SIB1。如果第一步就失败方向转到射频和同步如果到第三步失败方向转到CORESET#0配置和波束管理。这是我做5G网络开通调测与车联网场景时一直沿用的排查顺序。4.2 用AT指令与modem日志做横向确认终端侧可以直接用AT指令查询当前服务小区信息配合modem日志交叉验证。不过AT指令查到的往往是L3层聚合后的结果看不到物理层细节所以AT指令先做粗筛粗筛异常再回头抓物理层log。# 通用5G模组AT指令示例查询服务小区和邻区测量 ATCEREG? # 查询注册状态 AT5GCELLINFO? # 查询当前5G小区PCI、频点、RSRP AT5GNEIGHCELL? # 查询邻区列表部分模组支持AT5GCELLINFO?返回的RSRP是终端做过层3滤波后的测量值不能用来判断单次SIB1接收时的信道条件。如果要看SIB1接收瞬间的信道质量得回到物理层log里的每个SSB的SINR。另外AT5GNEIGHCELL?能看到的邻区取决于SIB4/SIB5里广播的配置如果SIB1都没收到那邻区表大概率也是空的这个现象本身就是一条排障线索。4.3 全网排障视角的SIB1失败原因清单从全网排障的角度看SIB1接收失败可以归类到三个维度覆盖、干扰、配置。下面的表格整理了我常用的判断方法和对应参数检查项。失败现象可能原因检查方法SIB1完全无响应SI-RNTI候选集与gNB调度不匹配核对SearchSpace#0聚合等级和监听时机SIB1 DCI收到但PDSCH解调失败SSB与SIB1的QCL关系错误检查PDCCH TCI状态和SSB index映射SIB1周期性丢失干扰或覆盖过差看SIB1的PER和信道SINRSIB1解码成功但驻留失败cellBarred或PLMN不匹配解析SIB1里的plmn-IdentityListSIB1能收到但TAU不触发TAC与邻区表一致性问题核对SIB1中的tac与核心网配置注意“参数怎么设”才是这类排障的落脚点。SearchSpace#0的聚合等级第一个候选值由pdcch-ConfigSIB1低4位查表得到常见值为2或4。如果gNB实际调度用的是聚合等级4但终端按表只能盲检等级2那SIB1的DCI会直接被终端漏掉。看到“RRC连接建立成功率低、接入时延大”这类全网KPI异常先查SIB1的接收周期和成功率比直接动随机接入参数更稳妥。5. 把SIB1探测用于5G全网排障和邻区配置核对最后一个直接能落地的技巧用SIB1的调度参数反推SSB周期和SearchSpace#0配置把网管配置与空口广播逐项核对。这里给出一个Python小脚本读取MIB里的pdcch-ConfigSIB1原始值输出CORESET#0和SearchSpace#0的关键参数再输出SIB1可能出现的监听时隙位置。# 从MIB值推导SIB1监听配置和时隙位置FR1 15kHz简版 def calc_sib1_monitoring(mib_pdcch_cfg, ssb_scs_khz15, ssb_period_ms20): coreset_idx mib_pdcch_cfg 4 ss_idx mib_pdcch_cfg 0x0F coreset_cfg { 0: {rb: 24, duration: 2, offset: 0}, 1: {rb: 24, duration: 3, offset: 0}, 2: {rb: 48, duration: 3, offset: 0}, 3: {rb: 96, duration: 3, offset: 0}, 4: {rb: 24, duration: 2, offset: 4}, 5: {rb: 48, duration: 2, offset: 8}, }.get(coreset_idx) searchspace_cfg { 0: {monitor_slot_period: 2, offset: 0}, 1: {monitor_slot_period: 1, offset: 1}, 2: {monitor_slot_period: 2, offset: 2}, }.get(ss_idx) slot_duration_ms 1 * 1000 / ssb_scs_khz * 2 sib1_window_ms 16 if ssb_period_ms 20 else 20 print(fCORESET#0: {coreset_cfg[rb]}RB, {coreset_cfg[duration]}符号, 频域offset{coreset_cfg[offset]}) print(fSearchSpace#0: 周期{searchspace_cfg[monitor_slot_period] * slot_duration_ms}ms, 时隙偏移{searchspace_cfg[offset]}) print(fSIB1监测窗口: {sib1_window_ms}ms, 默认最大重传次数≥8次) return coreset_cfg, searchspace_cfg calc_sib1_monitoring(32) # 高4位2, 低4位0对应48RB CORESET#0脚本输出的是SIB1接收时必须锁定的时频位置。SIB1窗口内如果有重传SIB1的RV版本会交替变化脚本里没有列RV因为终端在盲检时会尝试所有RV序列。实际核对邻区配置时SIB1里最关键的两个字段是tac和cellIdentity我会先把路测数据里的“PCI→TAC→cellId”三元组拉出来再和网管侧邻区表做一次diff凡是tac对不上的行无论RSRP多好都建议直接标红因为会导致跨TAC重选后TAU风暴。把空口SIB1探测数据当作衡量网管配置的一把尺子这是全网排障里最经济且有效的验证方式。本文还有配套的精品资源点击获取