5G NR寻呼机制详解：PF/PO计算、P-RNTI与排障实践

简介面向5G网络优化工程师与协议分析人员文档系统梳理了5G NR寻呼机制及其与4G LTE的差异。内容不仅覆盖RRC建立触发、系统消息更新、PWS/ETWS通知等传统寻呼原因还重点说明DCI 1_0携带P_RNTI的PWS/ETWS通知、PDSCH应答流程并对PagingRecordList、PagingRecord、PagingUE-Identity、accessType等消息结构字段逐一拆解配合ASN.1代码展示方便对照理解。全文按触发原因、消息内容、字段含义展开适合网优培训、日常排障或协议学习时快速查阅。资源为单个docx文件压缩包仅15KB轻量易读便于按需检索与反复研读。已有988人学习下载可作为快速建立5G寻呼知识框架、梳理信令流程的实用参考。1. 5G(NR)寻呼是什么终端凭什么在凌晨三点被你叫醒做 5G(NR) 网络优化的兄弟十有八九都遇到过这种场景测试终端明明显示信号满格VoNR 被叫却怎么都叫不醒最后发现问题出在最不起眼的寻呼Paging配置上。寻呼是 5G(NR) 网络里连接态之外最核心的“叫醒机制”——终端不可能一直睁着眼睛监听基站它按 DRX 周期睡一阵醒一阵网络必须把寻呼消息精准地塞进 UE 醒来的那个时间窗口。这个“精准”背后是一整套公式、参数和空口流程UE_ID 怎么取模、PF/PO 怎么算、P-RNTI 怎么加扰、SSB 和寻呼时机怎么对表。掌握了这套逻辑你排查被叫失败、寻呼拥塞、RRC 建立成功率低这类问题就有了抓手。这篇文章就做一件事把 5G(NR) 寻呼从“黑匣子”拆成能手算、能配置、能排查的落地笔记。2. 寻呼时机怎么算PF/PO 公式、参数映射与 Python 验证脚本2.1 为什么寻呼不能做成持续广播如果基站把寻呼像广播电台一样一直发UE 就得一直保持接收机在工作待机功耗直接崩掉。所以 5G(NR) 沿用并强化了 LTE 的 DRXDiscontinuous Reception思路UE 只在特定的无线帧、特定的监听时机醒来。在 38.304 里这个“特定的无线帧”叫 PFPaging Frame帧里的 PDCCH 监听时机叫 POPaging Occasion。网络侧要做的就是根据 UE 的 5G-S-TMSI 算出一个确定的 PF/PO让基站和 UE 在同一时刻对上暗号。你不需要发明新公式38.304 已经把这套映射写成了两个非常简洁的取模式子下面我会把每个符号掰开讲然后给一个可以直接跑通的 Python 脚本方便你在现网数据上验证。2.2 PF/PO 公式两个式子把 UE“闹钟”定下来先看核心公式SFN mod T (T div N) * (UE_ID mod N) i_s floor(UE_ID / N) mod Ns第一个式子定“在哪一帧”第二个式子定“在帧里第几个监听时机”。这里的 UE_ID 不是完整的 TMSI而是 5G-S-TMSI 对 1024 取模注意 5G-S-TMSI 是 AMF Set ID、AMF Pointer 和 5G-TMSI 拼起来的一个十进制大整数。最容易翻车的就是这一步有人拿完整 GUTI 甚至 IMSI 去取模算出来的 PF 当然和基站侧对不上。T 是寻呼周期单位是帧N 和 Ns 都是从 SIB1 里的 PCCH-Config 推出来的。这几个变量之间的关系如下表符号名称来源与典型取值作用T寻呼周期SIB1 的 defaultPagingCyclerf32、rf64、rf128、rf256对应 320、640、1280、2560 毫秒决定 UE 多久醒一次也决定 PF 的模数范围nAndPagingFrameOffset寻呼帧密度参数PCCH-Config 里枚举 oneEighthT、oneFourthT、halfT、one、two、four、eight、sixteen、thirtytwo参与计算 N控制 PF 在整个周期里的“摊开程度”N实际参与均匀分布的帧数N min(T, nAndPagingFrameOffset)N 越大 PF 分布越均匀寻呼碰撞概率越低Ns每个 PO 内的监听时机数nrofPDCCH-MonitoringOccasionPerSSBInPO取值 1、2、4、8决定一个 PO 里有多少个可用的 PDCCH 监听时机UE_ID寻呼用户标识5G-S-TMSI mod 1024把用户散列到不同的帧和时机上让寻呼负载均匀这里要特别提醒nAndPagingFrameOffset 这个名字容易让人以为是“偏移”实际上它直接参与 N 的计算。当它配成 oneFourthT 时N 就是 T/4配成 one 或更大的枚举值时N 会被 min 函数截到 T此时 PF 在周期内分布得最散。后面排障章节我会再讲这个参数配小了的后果。2.3 用 Python 把 PF/PO 算出来最小验证脚本公式不难难的是每次动手都翻协议。我习惯把这段逻辑写成一个十几行的 Python 函数现网拿到 TMSI直接算出该 UE 的 PF 和 i_s再去和基站 log 对表。下面这段代码可以直接复制跑输入 5G-S-TMSI 的十进制值和 SIB1 里的寻呼参数输出 PF 起始帧号和 PO 序号# 5G NR 寻呼帧(PF)与寻呼时机(PO)计算复现 38.304 7.1 节 from math import floor def paging_calc(s_tmsi, default_paging_cycle_ms1280, npo_enumoneFourthT, ns_per_ssb1): # defaultPagingCycle 枚举是 rf32/rf64/rf128/rf256单位毫秒 T default_paging_cycle_ms // 10 # 无线帧长 10ms转成“帧”为单位 # nAndPagingFrameOffset 的枚举名按 T 的倍数映射 ratio { oneEighthT: 1/8, oneFourthT: 1/4, halfT: 1/2, one: 1, two: 2, four: 4, eight: 8, sixteen: 16, thirtytwo: 32 }[npo_enum] n_and_paging_frame_offset int(T * ratio) N min(T, n_and_paging_frame_offset) # 38.304: N min(T, nAndPagingFrameOffset) Ns max(1, ns_per_ssb) # 每个 SSB 在 PO 内的 PDCCH 监听时机数 ue_id s_tmsi % 1024 # UE_ID 5G-S-TMSI mod 1024 pf (T // N) * (ue_id % N) # SFN mod T (T div N) * (UE_ID mod N) i_s floor(ue_id / N) % Ns # PO 序号对应第几个监听时机 return T, N, Ns, ue_id, pf, i_s # 从现网信令里拿到的十进制 5G-S-TMSI s_tmsi 1523492671 for cycle_ms, npo in [(1280, oneFourthT), (1280, one), (2560, one)]: T, N, Ns, ue_id, pf, i_s paging_calc( s_tmsi, cycle_ms, npo, ns_per_ssb2) print(fT{T}帧 N{N}帧 Ns{Ns} UE_ID{ue_id} fPF起始SFN{pf} i_s{i_s})这段代码的逻辑分三步先把 defaultPagingCycle 从毫秒转成帧10ms 一帧再把 nAndPagingFrameOffset 从协议枚举映射成真正的帧数最后按公式算 PF 和 i_s。参数说明里最需要注意的是ns_per_ssb2对应协议里的 nrofPDCCH-MonitoringOccasionPerSSBInPO它直接影响 UE 在 PO 内要监听的时机数量配 2 意味着 UE 每个 PO 要检查 2 个 PDCCH 候选寻呼机会翻倍但待机功耗也会上升。跑完你会看到同一个 UET 从 128 帧变成 256 帧后 PF 的起始 SFN 会变这就是为什么网管改完周期后老终端要重新读 SIB1 才会按新周期醒来。2.4 参数怎么定寻呼时延和 UE 功耗的天平PF/PO 公式本身没有“最佳答案”参数选择永远在做时延和功耗的权衡。defaultPagingCycle 配 320ms 时UE 平均 320ms 醒一次被叫响应最快能控制在几百毫秒内但射频唤醒频率高待机耗电明显配 2560ms 时省电可被叫时延会拉长到 2 秒级别VoNR 主叫听到的“嘟”声可能延迟明显。我的经验是纯 eMBB 业务为主的宏站直接用 rf128 或 rf256VoNR 话务量高的区域用 rf64车联网、遥控类业务用 rf32但这属于极端场景要和核心网侧确认它们下发的 Paging DRX 不会把小周期又盖回去。这里有个协议细节UE 实际使用的 T 是 SIB1 里的 defaultPagingCycle 和核心网通过 NAS 下发的 Paging DRX 中较小的那个所以只改基站侧周期、不改核心网效果可能被“截胡”。3. 空口寻呼下发P-RNTI 加扰、PDCCH 监听与 SSB/PO 映射3.1 UE 怎么知道这一帧是“自己的闹钟”P-RNTI 与 DCI 1_0PF 计算解决的是“什么时候醒”醒来看什么则是另一套机制。UE 在 PO 醒来后先监听 PDCCH而不是直接读 PDSCH。寻呼调度使用的 RNTI 是 P-RNTI固定值 0xFFFE也就是 65534。gNB 在 PO 对应的 PDCCH 监听时机上发送 DCI format 1_0这个 DCI 的 CRC 由 P-RNTI 加扰。UE 用 P-RNTI 去解 PDCCH 的 CRC解开了说明这一帧可能有寻呼消息然后解析 DCI 里的 Short Message 字段和频域资源分配信息。要理解“加扰”不是加密它是让 UE 可以通过已知的 RNTI 值快速过滤掉不属于自己的 PDCCH 候选从而省掉大量盲解 PDSCH 的计算量。实际抓 log 时你会在 UE 侧看到 P-RNTI 加扰的 DCI 1_0 后面跟着一个 PDSCH 传输块那个传输块里装的才是真正的 RRC Paging 消息。3.2 从 PDCCH 到 PDSCH寻呼消息下发的完整链路寻呼消息在空口上的下发链路是一条“四步走”流程每一步都是排查被叫问题的检查点gNB 在算好的 PO 对应的 PDCCH 监听时机上下发 P-RNTI 加扰的 DCI format 1_0里面带调度信息。UE 用 P-RNTI 解出 DCI确认 Short Message 指示有寻呼调度再按 DCI 指示去 PDSCH 对应的资源位置读寻呼数据。UE 解析 Paging 消息里的 pagingRecordList逐条比较 ue-Identityng-5G-S-TMSI和自己的 5G-S-TMSI 是否一致。匹配成功UE 进入 RRC 连接建立IDLE 态或 RRC 连接恢复INACTIVE 态不匹配就继续睡等下一个 PO。这四步里最容易出问题的不是第 1 步而是第 3 步的“逐条比较”。寻呼消息里可以同时带多个 UE 的记录每个记录里除了 ue-Identity还有 accessType、pagingCause、voiceSupport、uac-AccessCategory1、uac-AccessCategory2 这些可选字段。其中 uac-AccessCategory 字段跟 UAC统一接入控制强相关如果网络配了接入限制UE 在寻呼响应前还要先做接入类别检查检查不通过就直接放弃响应这在现场表现就是“寻呼下发成功但 UE 没反应”。3.3 SSB 与 PO 的绑定波束扫描下的监听时机对表5G(NR) 不同于 LTE 的“全向喊话”在 FR1 尤其是 FR2 场景里gNB 是按波束扫描的方式发 SSB 的PO 里的 PDCCH 监听时机也必须跟 SSB 的波束索引绑定。38.213 里有明确规则PO 的起始位置和当前激活的 SSB 对应UE 要根据自己做下行同步时锁定的 SSB index找到该 SSB 关联的 PDCCH 监听时机再去监听 P-RNTI 加扰的 DCI。这中间的关键参数就是 nrofPDCCH-MonitoringOccasionPerSSBInPO。这个参数配 1意味着每个 SSB 在一个 PO 内只对应 1 个监听时机UE 醒来的窗口最短最省电配 2 或 4每个 SSB 对应多个监听时机寻呼机会更多但 UE 在 PO 内停留时间拉长同时 gNB 在同一个 PO 内要填的 PDCCH 候选变多。FR2 场景下如果发现寻呼成功率随波束衰减优先检查这个参数和 SSB 周期的匹配关系而不是盲目加大寻呼重发次数。注意一个细节UE 计算 PO 用的 i_s 映射到的实际监听时机需要协议表 13-1 和 SSB 索引联合起来看这也是 5G 协议栈里最容易写错的一段代码——我之前在一个自研协议栈实现里就看到有人直接把 i_s 当成了物理监听时机序号结果 UE 在 PO 里监听窗口和基站下发窗口错开了一个符号被叫完全失败。3.4 SIB1 里的 PCCH-Config基站侧最直接的配置入口对网优或者协议测试人员来说前面说的公式和协议规则最终都落在 SIB1 的一个配置结构里。这个结构叫 PCCH-ConfigSIB1 通过 pagingConfiguration 携带。你需要核对的有四个参数defaultPagingCycle 决定 T它枚举 rf32、rf64、rf128、rf256nAndPagingFrameOffset 决定 N 的取值上限nrofPDCCH-MonitoringOccasionPerSSBInPO 决定 Ns还有 pagingOffset用来把 PO 在帧内进一步搬移避开和其他下行信道冲突日常排查中这个参数很少动但遇到 PO 和 SSB 周期交叠时可以调整。提示改完寻呼相关参数后基站侧通常不需要重启但 UE 必须重新读取 SIB1 才会用新参数。现场最常见的问题就是网管已经改了测试终端还按旧 PCCH-Config 计算 PF/PO被叫测试怎么打都不通。换个角度说就是排查被叫问题时第一步永远是确认 UE 当前驻留小区读到的 PCCH-Config 和你以为的配置一致这一步能干掉一半“寻呼玄学”。4. AMF 与 gNB 如何配合寻呼NGAP 消息、RRC INACTIVE 与 RAN 寻呼4.1 AMF 怎么“点名”NGAP Paging 消息里挂着什么被叫流程的源头不在基站而在核心网。当 AMF 收到对某个 UE 的终呼请求时它要先把 UE 找出来AMF 根据 UE 注册的 TA 列表通过 NGAP 接口向这些 TA 覆盖范围内的一组 gNB 发送 Paging 消息。这条 NGAP Paging 消息里携带的信息直接决定了 gNB 在空口上怎么发。我一般会重点看这几项NGAP IE作用排查关注点UE Identity Index value核心网分配给该 UE 的寻呼索引用于 gNB 侧负载分配长度要和 gNB 侧配置对上否则消息被拒UE Paging Identity里面是真正的 5G-S-TMSI空口 PagingRecord 里的 ue-Identity 就来自这里Paging DRX核心网建议的寻呼周期与 SIB1 的 defaultPagingCycle 取小生效Paging Priority寻呼优先级语音业务通常高优先级优先级高的寻呼可以抢占普通寻呼的调度资源TAI list for Paging本次寻呼涉及的跟踪区列表跨 TA 寻呼时 gNB 会对每个 TA 内小区分别下发Assistance Data for Paging给 RRC_INACTIVE UE 用的辅助数据含重发次数建议网优调的寻呼重发次数常在这里被覆盖这条消息在 NGAP 协议栈上叫 Paging抓 NGAP 接口时可以直接看到。实际处理中我发现很多“空口寻呼失败”其实是 NGAP 层就出了问题比如 UE Identity Index value 和 gNB 配置的寻呼索引长度不一致gNB 直接回绝或者 TAI list 里配了多个 TA但某个 TA 对应的小区寻呼参数没配好。所以排查被叫失败不要光看空口先抓 NGAP 看 AMF 有没有把 Paging 发出来再往下一层看。4.2 gNB 侧寻呼的组装与调度不是“广播复读机”gNB 收到 NGAP Paging 后不是简单地把消息往所有小区广播一遍而是要按每个小区自己的 PF/PO 公式把寻呼记录填到对应的调度时机里。这个过程分三部分第一步gNB 从 UE Paging Identity 里取出 5G-S-TMSI计算 UE_ID 和相关参数第二步根据 UE 所在的跟踪区找到对应小区把 RRC Paging 消息组装好第三步在寻呼 PO 对应的 PDCCH 监听时机上用 P-RNTI 加扰调度 PDSCH。如果消息里带了 Paging Priority调度器还会把高优先级寻呼插队。这里有个容易误判的点有的网管系统里有“寻呼重发次数”这个参数常见配 1 到 2 次它的作用是同一个寻呼消息在连续几个寻呼周期里重复下发不是为了补偿第一次下发失败而是为了让处于小区边缘、波束质量差的 UE 多一次机会。重发次数不是越多越好超过 3 次会导致寻呼 PDSCH 资源被占满反过来拖垮普通上下行调度。4.3 RRC_INACTIVE 与 RAN 寻呼和核心网寻呼不是一回事很多人把 RRC_INACTIVE 态下的寻呼和普通寻呼混为一谈实际上有一套独立流程叫 RAN Paging。当 UE 在 RRC_INACTIVE 态移动时它在基站侧有一个 RAN Notification AreaRNA的概念UE 在 RNA 范围内移动不需要通知网络只在离开 RNA 时通过 T380 定时器触发 RNAURNA Update。如果此时有下行数据或语音呼叫到达最后服务 gNB 会先在本地小区的寻呼时机放寻呼同时通过 Xn 接口向 RNA 覆盖范围内的相邻 gNB 发 XnAP 的 RAN PAGING 消息让邻居也帮忙一起找 UE。RAN 寻呼里带的不是 5G-S-TMSI而是 I-RNTI这个标识是基站分配的核心网根本不知道也不参与这是 RAN 寻呼最大的特点。PK 一下两种寻呼对比维度核心网寻呼CN PagingRAN 寻呼RAN Paging触发源AMF接到终呼请求时触发Last Serving gNB检测到下行数据或语音时触发UE 标识5G-S-TMSII-RNTI寻呼范围注册的 TA 列表RAN Notification Area 内的小区空口动作发 Paging 消息UE 响 RRCSetupRequest发 Paging 消息INACTIVE UE 响 RRCResumeRequest对核心网的消耗每次终呼都走 NGAP只在 RNA 边缘/失败时回退到 CN 寻呼RAN 寻呼的设计初衷是省掉核心网信令实际部署里最大的坑在 RNA 配置。如果 RNA 划得太小UE 频繁触发 RNAUT380 定时器反复重启基站侧可能因为 UE 状态不一致而寻呼不到人如果 RNA 划得太大一个 RAN 寻呼要打给几十个 gNB空口寻呼开销暴涨。调试时先看 UE 在 INACTIVE 态的位置更新频率如果过快多半是 RNA 边界切分不合理。5. 寻呼排查与避坑5 条从现场带回来的排障笔记5.1 UE 侧 log 显示 PO 上没有任何 P-RNTI但核心网说寻呼已经发了现象被叫失败抓 UE 空口 log 发现 UE 确实在算出来的 PO 上监听了 PDCCH但整个监听窗口内没有任何 P-RNTI 加扰的 DCI。原因分两层要么是 UE 侧的 PF/PO 算错要么是 gNB 没在这个 PO 下发。实际工作中 UE 侧算错的情况占大头而且往往是拿 5G-S-TMSI 的十进制值取模时出了错——比如从 GUTI 里把 AMF Set ID 和 AMF Pointer 也一起算进去。解决从 NAS 消息里解析出真正的 5G-S-TMSI48bit 十进制大整数用第二章的脚本重算 PF/PO再和基站侧调度日志对一下发时刻确认双端是否落在同一个 PO。5.2 寻呼 DCI 频繁下发但 UE 解 PDSCH 失败率很高现象P-RNTI 的 DCI 能看到不少但 UE 在 PO 内解带回的 PDSCH 总是 CRC 错误寻呼成功率波动明显。原因PO 内的 PDCCH 监听时机和 SSB 的映射关系对不上。常见于 FR2 或带波束扫描的场景gNB 给每个 SSB 配置的 nrofPDCCH-MonitoringOccasionPerSSBInPO 和 UE 实际锁定的 SSB index 不匹配UE 去 DCI 指向的 PDSCH 资源位置读数据读到的却是上一轮波束的残留调度。解决核对 SSB 周期、PO 起始位置和每个 SSB 的监听时机映射表把 nrofPDCCH-MonitoringOccasionPerSSBInPO 配成和波束数量匹配的值再复测。5.3 寻呼成功但 RRC 建立瞬时拥塞接通率掉点现象基站指标显示寻呼下发量和寻呼成功量都正常但 RRCSetupRequest 在某一瞬间大量涌入导致 RRC 建立成功率掉点。原因寻呼负载在时间上太集中了。默认 nAndPagingFrameOffset 如果配的是 oneEighthT 或 oneFourthTN 只有 T/8 或 T/4PF 只能落在周期内很少的帧上大量 UE 被散列到同一帧的同一 PO寻呼 DCI 和后续的随机接入前导在瞬间形成尖峰。解决把 nAndPagingFrameOffset 调大让 N 逼近 TPF 在整个周期内摊开。这个改动对单个 UE 的寻呼时延基本无影响但能显著平滑 RRC 建立请求的分布。5.4 边界弱覆盖区“振铃但接不通”重发次数不够现象小区边界或室内浅层覆盖区域主叫听振铃但被叫侧始终没有响应UE 侧 log 偶尔能看到 P-RNTI 但解码质量差。原因寻呼 DCI 和 PDSCH 在小区边缘的覆盖余量不足。寻呼消息不管服务质量用的是广播信道类似的调度方式没有 HARQ 重传一次解调失败就是整包丢失。常见做法是在 gNB 开启寻呼重发配 1 到 2 次重发或通过 NGAP 里的 Assistance Data for Paging 带上建议重发次数。注意重发是跨寻呼周期的所以开了重发之后被叫响应时延会略微增加这是换覆盖余量的代价。5.5 改了 defaultPagingCycle 后老终端死活不按新周期醒现象网管把 defaultPagingCycle 从 rf128 改成 rf64测试终端的被叫时延毫无变化甚至寻呼更不稳定。原因UE 还在用旧 SIB1 里的寻呼参数。UE 读取系统消息后有缓存不会因为基站侧改动立刻生效需要在测试中让 UE 重新驻留一次或者手动飞行模式复位。解决每次改完寻呼参数先让测试手机切飞行模式再切回来确认 UE 读到的 SIB1 里 PCCH-Config 已经更新再开始打被叫。这条算不上协议难题但确实是排障时最容易被忽略的一步——我在现场见过兄弟改完参数测了半小时没结果最后发现测试机一直用的还是老的系统消息缓存。6. 寻呼时延优化的一个实用技巧先算后改用 log 对表最后讲一个我常用的寻呼时延优化手法用“核心网到空口的全流程时间戳”来判断问题出在寻呼周期的哪一段。具体做法是在被叫测试时同时抓 NGAP 和 UE 侧 log从 NGAP Paging 消息进 gNB 开始到空口 Paging 下发再到 UE 发出 RRCSetupRequest分别记录时间戳。如果 NGAP 到空口下发这段耗时长说明 gNB 内部组装和调度慢多半是寻呼周期刚好错过UE 要多等一个 PO如果空口下发到 RRCSetupRequest 耗时长问题在覆盖或随机接入参数。然后根据耗时差决定改不改 defaultPagingCycle。我自己的习惯是时延敏感的小区先把 defaultPagingCycle 压到 rf64同时把 nAndPagingFrameOffset 配成 one 以上让 PF 分布足够散窄带或低功耗物联网终端所在的小区反向操作用 rf256 保待机。改完后不急着看 KPI先抓一轮 log 验证 UE 实际醒来的 PO 和基站下发点对齐。这套“先算后改用 log 对表”的流程帮我解决过多次“寻呼丢失”的假故障也算是我在 5G 协议栈测试里最想分享的一条实战习惯。希望帮到你。本文还有配套的精品资源点击获取