好的，我们继续跟随5G基站工程师小雷，深入探索NG接口上那些保障网络基础运作的关键功能。这一次，我们将聚焦于一个确保网络能够随时找到“失联”用户的核心流程——寻呼流程。

深度解析 3GPP TS 38.410：6.5 Paging procedure (寻呼流程)

本文技术原理深度参考了3GPP TS 38.410 V18.2.0 (2024-06) Release 18规范中，关于“6.5 Paging procedure”的核心章节，并结合其在核心网（TS 23.501/502）和NGAP协议（TS 38.413）中的具体实现，为读者完整呈现5G网络中，寻呼指令从核心网下发到基站执行的端到端信令视图。

引言：从“功能描述”到“指令执行”的最后一公里

在之前的5.2节解读中，我们已经从“功能”的视角，理解了寻呼“是什么”——它如同一个“寻人广播”系统，用于唤醒处于IDLE或INACTIVE状态的UE，并学习了其背后的智能优化机制，如分层寻呼区域和子组寻呼。

现在，我们将进入6.5节，从“流程”的视角，深入探索寻呼“怎么做”。6.5节不再是高层的概念描述，而是将5.2节的功能，落地为NG接口上一个具体的、可执行的NGAP信令流程。它就像是“广播控制中心”（AMF）发给“地方广播站”（gNB）的那张唯一的、明确的“播音任务单”。

本篇文章，我们将聚焦于Paging这一个核心流程，详细拆解AMF下发的“任务单”上都写了些什么，以及小雷的gNB在收到这张“任务单”后，是如何将其转化为真正的空口“寻人广播”的。

---

1. 流程的“剧本”：Paging Procedure 的唯一使命

6.5 Paging procedure

The following paging procedure is used to send paging requests to the NG-RAN nodes involved in the paging area:

• Paging.

6.5节的描述极其简洁，它只定义了一个流程——Paging。这与之前的上下文管理、移动性管理等拥有“流程全家桶”的功能形成了鲜明对比。

为什么如此简洁？

因为寻呼是一个单向的、命令式的流程。它不像切换或上下文建立那样，需要RAN和核心网之间进行复杂的“你来我往”的协商。寻呼的逻辑非常纯粹：AMF下达指令，gNB负责执行。gNB在执行后，无需向AMF回复一个“寻呼成功”或“寻呼失败”的响应。

流程的成败判断，是间接的：

• 如果寻呼成功，被唤醒的UE会主动发起SERVICE REQUEST流程。AMF收到了这个请求，就间接地知道了之前的寻呼起作用了。
• 如果寻呼失败，AMF在等待超时后，仍然没有收到UE的任何响应，就间接地判断寻呼失败了。

这种“只管下令，不问结果”的设计，极大地简化了NG接口的信令交互，提升了寻呼的效率，特别是在需要向数十个甚至上百个gNB同时发起寻呼的大TA场景下。

---

2. “播音任务单”的详细解读：PAGING 消息

NGAP Procedure: Paging (AMF Initiated) NGAP PDU: PAGING (AMF → gNB)

当AMF需要唤醒一个UE时，它会向该UE所在寻呼区域内的所有相关gNB，发送一条PAGING消息。这条消息，就是我们所说的“播音任务单”。让我们详细解读这张“任务单”上的每一个关键字段。

场景设定： 用户“张三”的手机处于IDLE态，一个VoNR（5G高清语音）电话呼入。AMF需要立即将他唤醒。

2.1 核心指令：要找谁？

• UE Paging Identity:
  • 内容: 5G-S-TMSI。这是UE在当前AMF下的一个临时的、为了隐私保护而设计的身份标识。
  • 作用: 这是“任务单”上最核心的信息——“寻人启事”的主角是谁。gNB会在空口广播的寻呼消息中，包含这个5G-S-TMSI。

2.2 执行细则：该怎么找？

• Paging DRX:

  • 内容: 一个枚举值，如v32, v64, v128, v256… 代表了UE的DRX周期长度（单位是无线帧）。
  • 作用: 这是“行动时间表”。AMF通过这个参数，精确地告知gNB：“‘张三’的手机，每隔v128个无线帧（1.28秒），才会醒来听一次广播。” 小雷的gNB必须根据这个信息，以及UE的ID计算出的偏移，精确地在**正确的寻呼时机（Paging Occasion - PO）**上，广播寻呼消息。早了或晚了，UE都处于“睡眠”中，听不到。

• Paging Priority:

  • 内容: 一个优先级数值（0-255，数值越小优先级越高）。
  • 作用: 这是“任务紧急程度”。对于VoNR呼入这种高优先级业务，AMF会设置一个很高的优先级。当gNB的寻呼信道资源紧张，有多个寻呼任务在排队时，gNB会优先处理高优先级的寻呼请求。

• Paging Origin:

  • 内容: 一个枚举值，non-3gpp或5gc。
  • 作用: 指明这次寻呼是来自5G核心网内部（如数据到达UPF），还是来自与5GC互通的非3GPP网络（如Wi-Fi）。这可以用于一些特殊的策略处理。

2.3 优化工具：如何找得更“聪明”？

• TAI List for Paging / Paging Area:

  • 内容: 一个或多个TAI（跟踪区标识）或预定义的Paging Area ID。
  • 作用: 明确了本次寻呼的“广播范围”。AMF会告诉gNB：“这次寻呼，只需要在你那些属于TAI-1和TAI-2的小区里广播即可。” gNB会根据这个列表，精确地控制广播的小区范围，避免不必要的资源浪费。

• Assistance Data for Paging:

  • 内容: 一个包含多种辅助信息的结构体，其中最重要的就是UE Paging Subgroup ID。
  • 作用: 这正是我们在5.2节学过的“子组寻呼”的实现载体。如果AMF支持并启用了子组寻呼，它就会在这里填上UE所属的子组ID。小雷的gNB看到这个ID后，就会在广播时，先喊出“第X组的同学请注意！”，从而让其他组的UE可以“提前下课”，节省电量。

---

3. gNB的“播音”工作：从NGAP到空口

小雷的gNB收到了AMF发来的这张详尽的PAGING“任务单”后，它的RRC协议栈就会开始忙碌起来。

1. 解析任务单: gNB解析PAGING消息，提取出5G-S-TMSI、Paging DRX、Subgroup ID等所有关键参数。
2. 计算播音时间: gNB根据Paging DRX和UE的ID，精确地计算出下一次可以寻呼到这个UE的无线帧号，即PO（Paging Occasion）。
3. 生成“广播稿”: gNB的RRC层，生成一条或多条空口Paging消息。这些消息的格式，由**TS 38.331（RRC规范）**定义。它会将5G-S-TMSI等信息，填入“广播稿”中。
4. 按时播音: 在计算好的PO时刻，gNB的MAC层和PHY层，会将这条Paging消息，在所有指定小区的物理下行控制信道（PDCCH）上进行调度，并通过物理下行共享信道（PDSCH），广播出去。

至此，一次由核心网发起的、跨越NG接口的寻呼任务，最终在无线空中，化作了一次精准的“寻人广播”，成功地将“沉睡”的UE唤醒。

---

总结：简单流程承载精巧设计，维系网络的可达性

通过对6.5节“寻呼流程”的深度剖析，我们看到了一个极其简洁的NGAP流程背后，所蕴含的极其丰富的控制信息和极其精巧的设计思想。

• 单向命令，间接确认: Paging流程的单向性，保证了其在需要向海量gNB广播时，核心网的信令开销被降至最低。
• 信息完备的“任务单”: PAGING消息的设计，将一次寻呼所需的所有控制参数（找谁、何时找、在哪找、多紧急、如何节能）“一次性”地、结构化地告知了gNB，使得gNB可以完全自主地、精确地执行空口广播。
• 高级优化的承载者: Paging Priority和Subgroup ID等字段，使得优先级调度和子组寻呼这些5G的高级节能和优化机制，得以在NG接口上顺利落地。

对于基站工程师小雷来说，PAGING消息是他日常监控中最常见的下行信令之一。虽然这个流程本身很少会出问题，但通过观察Paging消息的数量、频率和其中的参数，他可以间接地洞察到网络的许多“秘密”：例如，某个区域的Paging速率突然飙升，可能意味着有大量的IDLE态用户正在被唤醒，预示着一次业务高峰的到来；或者，大量Paging消息都没有后续的Service Request，可能意味着该区域的空口覆盖存在问题，导致UE“听不到”广播。这条简单的信令，如同一面镜子，映照出整个网络的“可达性”和“活性”。