企业官网建设流程全解析

简介：面向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 的 DRX（Discontinuous Reception）思路：UE 只在特定的无线帧、特定的监听时机醒来。在 38.304 里，这个“特定的无线帧”叫 PF（Paging Frame），帧里的 PDCCH 监听时机叫 PO（Paging 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 推出来的。这几个变量之间的关系如下表：

这里要特别提醒：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_ms=1280, npo_enum='oneFourthT', ns_per_ssb=1): # 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_ssb=2) print(f"T={T}帧 N={N}帧 Ns={Ns} UE_ID={ue_id} " f"PF起始SFN={pf} i_s={i_s}")

这段代码的逻辑分三步：先把 defaultPagingCycle 从毫秒转成帧（10ms 一帧），再把 nAndPagingFrameOffset 从协议枚举映射成真正的帧数，最后按公式算 PF 和 i_s。参数说明里最需要注意的是ns_per_ssb=2对应协议里的 nrofPDCCH-MonitoringOccasionPerSSBInPO，它直接影响 UE 在 PO 内要监听的时机数量，配 2 意味着 UE 每个 PO 要检查 2 个 PDCCH 候选，寻呼机会翻倍，但待机功耗也会上升。跑完你会看到：同一个 UE，T 从 128 帧变成 256 帧后 PF 的起始 SFN 会变，这就是为什么网管改完周期后，老终端要重新读 SIB1 才会按新周期醒来。

2.4 参数怎么定：寻呼时延和 UE 功耗的天平

PF/PO 公式本身没有“最佳答案”，参数选择永远在做时延和功耗的权衡。defaultPagingCycle 配 320ms 时，UE 平均 320ms 醒一次，被叫响应最快能控制在几百毫秒内，但射频唤醒频率高，待机耗电明显；配 2560ms 时省电，可被叫时延会拉长到 2 秒级别，VoNR 主叫听到的“嘟”声可能延迟明显。我的经验是：纯 eMBB 业务为主的宏站直接用 rf128 或 rf256；VoNR 话务量高的区域用 rf64；车联网、遥控类业务用 rf32，但这属于极端场景，要和核心网侧确认它们下发的 Paging DRX 不会把小周期又盖回去。这里有个协议细节：UE 实际使用的 T 是 SIB1 里的 defaultPagingCycle 和核心网通过 NAS 下发的 Paging DRX 中较小的那个，所以只改基站侧周期、不改核心网，效果可能被“截胡”。

3. 空口寻呼下发：P-RNTI 加扰、PDCCH 监听与 SSB/PO 映射

3.1 UE 怎么知道这一帧是“自己的闹钟”：P-RNTI 与 DCI 1_0

PF 计算解决的是“什么时候醒”，醒来看什么则是另一套机制。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：寻呼消息下发的完整链路

寻呼消息在空口上的下发链路是一条“四步走”流程，每一步都是排查被叫问题的检查点：

1. gNB 在算好的 PO 对应的 PDCCH 监听时机上，下发 P-RNTI 加扰的 DCI format 1_0，里面带调度信息。
2. UE 用 P-RNTI 解出 DCI，确认 Short Message 指示有寻呼调度，再按 DCI 指示去 PDSCH 对应的资源位置读寻呼数据。
3. UE 解析 Paging 消息里的 pagingRecordList，逐条比较 ue-Identity（ng-5G-S-TMSI）和自己的 5G-S-TMSI 是否一致。
4. 匹配成功，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-Config，SIB1 通过 pagingConfiguration 携带。你需要核对的有四个参数：defaultPagingCycle 决定 T，它枚举 rf32、rf64、rf128、rf256；nAndPagingFrameOffset 决定 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 协议栈上叫 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 Area（RNA）的概念，UE 在 RNA 范围内移动不需要通知网络，只在离开 RNA 时通过 T380 定时器触发 RNAU（RNA Update）。如果此时有下行数据或语音呼叫到达，最后服务 gNB 会先在本地小区的寻呼时机放寻呼，同时通过 Xn 接口向 RNA 覆盖范围内的相邻 gNB 发 XnAP 的 RAN PAGING 消息，让邻居也帮忙一起找 UE。RAN 寻呼里带的不是 5G-S-TMSI，而是 I-RNTI，这个标识是基站分配的，核心网根本不知道，也不参与，这是 RAN 寻呼最大的特点。

PK 一下两种寻呼：

RAN 寻呼的设计初衷是省掉核心网信令，实际部署里最大的坑在 RNA 配置。如果 RNA 划得太小，UE 频繁触发 RNAU，T380 定时器反复重启，基站侧可能因为 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-TMSI（48bit 十进制大整数），用第二章的脚本重算 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 或 oneFourthT，N 只有 T/8 或 T/4，PF 只能落在周期内很少的帧上，大量 UE 被散列到同一帧的同一 PO，寻呼 DCI 和后续的随机接入前导在瞬间形成尖峰。解决：把 nAndPagingFrameOffset 调大，让 N 逼近 T，PF 在整个周期内摊开。这个改动对单个 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 协议栈测试里最想分享的一条实战习惯。希望帮到你。

本文还有配套的精品资源，点击获取