51学通信

深度解析 3GPP TS 38.410：5.2 Paging function (寻呼功能)

17分钟阅读

好的，我们继续跟随5G基站工程师小雷，深入探索NG接口上那些为优化网络资源、提升用户体验而生的关键功能。这一次，我们将聚焦于一个“古老”而又在5G时代被赋予全新内涵的话题——寻呼（Paging）。

深度解析 3GPP TS 38.410：5.2 Paging function (寻呼功能)

本文技术原理深度参考了3GPP TS 38.410 V18.2.0 (2024-06) Release 18规范中，关于“5.2 Paging function”的核心章节，并结合其在核心网（TS 23.501/502）和NGAP协议（TS 38.413）中的具体实现，为读者完整呈现5G网络中寻呼机制的运作原理、优化特性及其在NG接口上的实现。

引言：在茫茫人海中，如何精准地找到“你”？

我们的主角，基站工程师小雷，每天都要面对他所负责的gNB覆盖下，成千上万个“时隐时现”的手机（UE）。这些手机为了节省宝贵的电池电量，在没有数据传输时，会进入一种“深度睡眠”的状态——CM-IDLE（连接管理-空闲态）。

此时，一个经典的难题出现了：当有一个微信电话或者一条App推送消息，要发送给一个正处于“睡眠”中的手机时，网络该如何高效、低成本地将它从“睡梦”中唤醒？

这个唤醒的过程，就是寻呼（Paging）。它就像是在一个巨大的、寂静的候车大厅里，通过广播寻找某位旅客：“请旅客张三注意，您的电话来了！”

第5.2节“Paging function”，正是NG接口为支撑这一古老而核心的功能，所定义的“广播寻呼系统”。我们将通过本篇文章，深入探索5G的寻呼机制相比于4G有哪些进化，以及小雷的gNB是如何在AMF的指挥下，完成一次精准的“寻人广播”的。

1. 寻呼的使命：唤醒沉睡的UE

5.2 Paging function

The paging function supports the sending of paging requests to the NG-RAN nodes involved in the paging area e.g. the NG-RAN nodes of the TA(s) the UE is registered.

深度解读：

  • 核心使命: 当核心网（主要是AMF）有下行数据或信令要发给一个处于CM-IDLE状态的UE时，由AMF发起，通过NG-C接口，向该UE可能在的gNB发送寻呼请求，由这些gNB在空口上广播寻呼消息，以触发UE恢复到连接状态。

  • Paging Area (寻呼区): 这是理解寻呼效率的关键。网络并不知道一个IDLE态的UE具体在哪个小区的覆盖下，但它知道这个UE最后一次上报位置时，所在的跟踪区（Tracking Area - TA）。一个TA通常由多个gNB（或小区）组成。当需要寻呼时，AMF会将寻呼请求，发送给这个TA内的所有gNB。

场景演绎：一次微信电话呼入

  1. 用户“张三”的手机处于IDLE态，他最后一次向网络“报备”的位置是在“海淀区TA-1”。

  2. 此时，一个微信电话呼入。下行数据包到达核心网的UPF。

  3. UPF发现自己没有通往“张三”手机的下行隧道（因为UE处于IDLE态），于是它向SMF上报“下行数据通知”。

  4. SMF通知AMF：“张三有数据要接收，请把他叫醒。”

  5. AMF查询自己的数据库，得知“张三”最后的位置在“海淀区TA-1”。

  6. AMF立即向“海淀区TA-1”内所有的小雷的gNB们，通过NG-C接口发送一个PAGING消息。

  7. 所有收到指令的gNB，都会在自己的空口寻呼信道（Paging Channel）上，广播寻呼“张三”的消息。

  8. “张三”的手机虽然在“睡觉”，但它的接收机每隔一段时间（DRX周期）就会短暂“醒来”，监听寻呼信道。它听到了自己的名字（临时ID），于是立即被唤醒，并发起服务请求（Service Request）流程，恢复到连接状态，最终接听到微信电话。

2. 5G寻呼的进化：更智能，更节能

传统的寻呼方式，是在整个TA内进行“地毯式”广播，当TA范围很大时，会造成不必要的信令开销和空口资源浪费。5G为寻呼机制带来了两项重要的优化。

2.1 “缩小范围”：基于UE RRC INACTIVE态的寻呼

5G引入了一个介于IDLE和CONNECTED之间的RRC_INACTIVE状态。处于此状态的UE，其上下文被保留在最后为它服务的那个gNB上。

  • 寻呼流程的变化:

    1. 当AMF需要寻呼一个处于INACTIVE状态的UE时，它不再向整个TA广播，而是只向那个保留了UE上下文的gNB，发送PAGING消息。

    2. 这个gNB收到后，会在一个被称为**RAN-based Notification Area (RNA)**的、比TA小得多的区域内进行寻呼。

  • 优势: 极大地缩小了寻呼的地理范围，从“全城寻人”变成了“小区内找人”，显著降低了信令开销。

2.2 “分组叫醒”：CN控制的子组寻呼

The function also supports CN controlled subgrouping paging for UE Power Saving.

深度解读：

这是5.2节中特别强调的一项5G增强功能，旨在进一步优化UE的功耗。

  • 传统寻呼的问题: 在一个寻呼周期内（Paging Occasion - PO），UE必须醒来，监听是否有自己的寻呼消息。如果这个TA内有很多UE，寻呼消息可能会很长，UE需要监听很久，造成不必要的耗电。

  • 子组寻呼 (Subgrouping Paging) 的思想:

    1. 核心网（CN，即AMF）在给UE分配临时ID（GUTI）时，会巧妙地设计这个ID，使得ID中包含了子组信息。

    2. AMF和gNB约定好，将一个TA内的所有UE，根据它们的子组ID，分成几个寻呼子组（例如，分成4个子组）。

    3. 当AMF需要寻呼时，它会在PAGING消息中，明确告诉gNB：“这次寻呼，只针对子组2的成员。”

    4. gNB在广播寻呼消息时，会先广播一个子组ID（Subgroup ID）。

场景演绎：智能的“分组点名”

  1. “张三”的手机被分到了“子组2”。

  2. 现在又到了手机需要醒来监听寻呼的时刻。

  3. 它首先去监听广播中的“子组ID”。它听到了这次广播的是“子组3”。

  4. “张三”的手机心想：“没我事儿！”于是，它无需再继续监听后面长长的寻呼UE列表，可以立即返回睡眠状态。

  5. 只有那些属于“子组3”的手机，才需要继续“竖起耳朵”，听听看点名册里有没有自己的名字。

通过这种“先喊组号，再点人名”的方式，大部分UE都可以在监听到组号后，就提前返回睡眠，极大地缩短了接收机的“唤醒-监听”时间，从而实现了显著的功耗节省。这对于那些需要长续航的物联网设备尤为重要。

3. NG接口上的实现：PAGING消息

寻呼功能在NG接口上，主要是通过NGAP协议中的PAGING消息来实现的。

NGAP PDU: PAGING (AMF → gNB)

小雷的gNB会从AMF收到的这条消息中，获取到一次寻呼任务所需的全部信息。

PAGING消息的核心内容：

  • UE Paging Identity: 要寻呼的UE的身份标识。这通常是5G-S-TMSI。

  • Paging DRX: UE的DRX周期。AMF会告诉gNB，这个UE的“睡眠周期”是多长，以便gNB能够在正确的寻呼时机（PO）广播寻呼消息。

  • Paging Priority (可选): 寻呼的优先级。例如，对于一个IMS语音呼叫的寻呼，其优先级就要高于一个普通的App推送。

  • Paging Origin: 寻呼的来源（是来自核心网用户面，还是控制面）。

  • Assistance Data for Paging (可选): 用于辅助寻呼的数据，这里面就可能包含我们上面提到的UE Paging Subgroup ID。

小雷的gNB在收到这条结构化的PAGING消息后，其RRC层就会根据这些参数，生成一个或多个标准的空口Paging消息，并在正确的时间、正确的子组上，将其广播出去，完成一次精准的“唤醒”任务。

总结：于无声处，维系万千连接

通过对5.2节“寻呼功能”的深度剖析，我们看到了一个看似简单，实则在5G时代被深度优化的核心网络功能。它不再是4G时代那种“大水漫灌”式的粗放广播，而是一个更加精准、节能、智能的唤醒系统。

  • 分层的寻呼区域: 通过**TA（跟踪区）和RNA（RAN通知区）**的结合，实现了对IDLE和INACTIVE两种状态UE的差异化、分层级的寻呼，在覆盖范围和信令开销之间取得了平衡。

  • 精巧的节能机制: 通过CN控制的子组寻呼，极大地缩短了UE的监听时间，显著优化了终端功耗，为万物互联时代的海量物联网设备的长续航提供了可能。

  • 清晰的接口定义: 通过NGAP PAGING消息，在AMF和gNB之间，建立了一条信息完备、参数清晰的“寻呼指令通道”，确保了核心网的寻呼策略能够被无线侧精确地执行。

对于基站工程师小雷来说，寻呼功能是他日常工作中“看不见”但又无处不在的一部分。他知道，在他基站天线每一次看似平静的广播中，都可能蕴含着一次次精准的“点名”，维系着他覆盖下成千上万个“沉睡”终端与数字世界的连接。这于无声处的“惊雷”，正是5G网络高效运作的脉搏。

FAQ

Q1：如果一个UE在TA-1注册后，偷偷移动到了TA-2，网络还能寻呼到它吗？

A1：不能立即寻呼到。UE有责任在跨越TA边界时，主动向网络发起一次**跟踪区更新（Tracking Area Update - TAU）**流程，告知网络自己的新位置。如果UE因为某些原因（如信号丢失、软件故障）没有及时上报TAU，那么当AMF在旧的TA-1内发起寻呼时，将找不到这个UE。AMF在寻呼超时后，会认为UE“失联”。直到UE下一次自己发起业务请求或TAU时，网络才能重新获知其位置。

Q2：RRC_INACTIVE状态和CM-IDLE状态，对用户来说有什么区别？

A2：对用户来说，最直观的区别是恢复连接的速度。从INACTIVE恢复到CONNECTED，是一个RRC层的快速恢复过程，通常只需要几十毫秒，因为UE的“档案”（上下文）还保留在基站里，无需核心网的介入。而从IDLE恢复到CONNECTED，则需要走一个**完整的服务请求（Service Request）**流程，涉及到UE与AMF之间的NAS信令交互，过程更长，通常需要上百毫秒。INACTIVE状态，是在“连接保持”和“终端功耗”之间取得的一个更优的折中。

Q3：子组寻呼（Subgrouping Paging）这个功能，需要UE和网络都支持吗？

A3：是的，必须端到端都支持。1. **核心网（AMF）**需要支持生成包含子组信息的GUTI。2. **基站（gNB）**的NGAP和RRC协议栈，需要支持解析和生成带有子组ID的寻呼消息。3. UE的NAS和RRC协议栈，需要支持解析子组ID，并根据子组ID执行“提前睡眠”的逻辑。这是一个需要整个通信链路协同工作的端到端优化功能。

Q4：AMF是如何知道一个UE的DRX周期的？

A4：UE的DRX周期，是在注册（Registration）过程中，由UE上报给AMF的。UE会告知AMF自己偏好的DRX周期值（例如，1.28秒、2.56秒等）。AMF会记录下这个值，并在后续发起寻呼时，通过PAGING消息告知gNB，以便gNB能够在正确的时刻广播寻呼。

Q5：寻呼失败了会怎么样？

A5：如果AMF在TA/RNA内发起了寻呼，但在规定的时间内，没有收到UE的任何响应（如Service Request），AMF就会认为寻呼失败。对于这次由下行数据触发的寻呼，AMF会通知SMF/UPF，UPF可能会暂时缓存一小段时间的数据，然后丢弃。对于电话呼入，主叫方可能会听到“您拨打的用户暂时无法接通”的提示。AMF会将该UE标记为不可达（Unreachable），直到该UE下一次主动联系网络。

关系图谱