深度解析 3GPP TS 38.423：8.2.5 RAN Paging (RAN寻呼)

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.2.5 RAN Paging”的核心章节，旨在为读者提供一个关于5G RRC_INACTIVE态下基站间寻呼协作机制的全景视图。

1. 引言：茫茫人海中，如何找到沉睡的UE？

在之前的章节中，我们见证了工程师小林在他的导师陈工的指导下，逐步揭开了XnAP协议的神秘面纱。他们已经深入探讨了切换准备、SN状态传递和切换取消等一系列围绕着“在线”用户（处于RRC_CONNECTED态）的移动性流程。

这天，小林在复盘李雷的高铁案例时，提出了一个新的疑问：“陈工，我们之前讨论的都是李雷正在通话或下载时的场景。但如果他的会议结束了，手机为了省电，进入了RRC_INACTIVE状态。这时候，他的老板突然打来一个紧急的VoNR电话，网络该如何找到他并唤醒他的手机呢？”

陈工赞许地看了看小林：“问得好！你已经触及到了5G移动性管理中另一个极其重要的场景。RRC_INACTIVE态是5G为了在‘始终在线’的用户体验和‘极致省电’的终端需求之间取得平衡而设计的。但它也带来了一个巨大的挑战：网络只知道UE在一个大致的区域（RAN Notification Area, RNA）内，却不知道它此刻正‘睡’在哪一个基站的‘床’上。”

陈工接着说：“当核心网（AMF）需要联系这个‘沉睡的游牧者’时，它会向整个RNA区域内的所有基站广播一个‘寻人启事’，这就是核心网寻呼（Core Network Paging）。但故事到这里才开始变得有趣。这个RNA区域可能包含数十个基站，而UE的完整上下文（它的‘档案’）只保存在它进入睡眠状态前的那个锚点基站。其他基站虽然收到了‘寻人启事’，但对这个UE一无所知。”

“那么，锚点基站该怎么办？它需要协调RNA内的其他兄弟基站一起帮忙，在各自的空口上广播寻呼信息。这个基站之间的‘寻人委托’，正是通过我们今天要学习的XnAP流程——RAN Paging来完成的。它就像是寻呼体系中的‘最后一公里’，是确保RRC_INACTIVE态UE能够被可靠唤醒的关键。”

2. 8.2.5.1 General (概述) - 基站间的“寻人委托书”

The purpose of the RAN Paging procedure is to enable the NG-RAN node1 to request paging of a UE in the NG-RAN node2. The procedure uses non UE-associated signalling.

陈工为小林解读这段简短而精炼的概述：

• “enable the NG-RAN node1 to request paging … in the NG-RAN node2”：这明确了流程的方向和角色。node1是发起请求的基站，通常是持有UE上下文的锚点基站。node2是接收请求并执行空口寻呼的基站。在一个RNA内，锚点基站会向RNA内的所有其他（或部分）基站发送这个请求。

• “non UE-associated signalling” (非UE关联信令)：这是一个关键的技术点。在发起RAN PAGING时，基站1和基站2之间可能还没有为这个特定的UE建立起任何XnAP信令连接。这个寻呼请求是作为一个“广播式”的通用消息在已建立的Xn接口上传输的，它不依赖于一个已存在的、特定于该UE的信令隧道。这使得寻呼过程非常轻量和高效。

场景代入：李雷的上下文锚定在基站A。核心网向包括A、B、C在内的整个RNA区域发起寻呼。

1. 基站B和C收到核心网的寻呼后，发现自己本地没有这个UE的上下文，于是它们通常会忽略这个寻呼（或根据其他策略处理）。
2. 基站A收到核心网的寻呼后，查询本地上下文，发现“哦，这是我负责的UE！”。但A也知道，李雷可能已经移动到了B或C的覆盖下。
3. 于是，基站A作为node1，分别向基站B和C（它们是node2）发送XnAP的RAN PAGING消息，内容是：“兄弟们，帮我呼叫一下这个I-RNTI为xxx的UE”。

这个过程清晰地将NGAP Paging（核心网 to 基站）和XnAP RAN Paging（基站 to 基站）区分开来，两者构成了完整的RRC_INACTIVE态寻呼链条。

3. 8.2.5.2 Successful operation (成功操作) - “寻人启事”的详细内容

RAN Paging是一个Class 2流程，即单向通知。锚点基站A只负责将“寻人委托”发出去，不等待B和C的回复。这保证了寻呼消息能够以最快的速度在整个RNA内扩散。

The RAN Paging procedure is triggered by the NG-RAN node1 by sending the RAN PAGING message to the NG-RAN node2, in which the necessary information e.g. UE RAN Paging Identity should be provided.

RAN PAGING消息中包含了丰富的信息元素（IE），以确保寻呼的准确性和高效性。让我们逐一解析这些重要的“寻人启事”内容。

3.2.1 核心身份标识：UE RAN Paging Identity

这是寻呼的根本。对于RRC_INACTIVE态的UE，这个身份标识就是I-RNTI。其他基站收到这个消息后，会在自己的空口上，在寻呼信道（PCH）上广播这个I-RNTI。所有处于RRC_INACTIVE态的UE都会监听这个信道，当李雷的手机匹配到自己的I-RNTI时，它就会被唤醒，并发起RRC Resume流程。

3.2.2 寻呼的优先级：Paging Priority IE

If the Paging Priority IE is included in the RAN PAGING message, the NG-RAN node2 may use it to prioritize paging.

陈工的解读：“并非所有的寻呼都是十万火急的。李雷老板打来的VoNR电话，和某个新闻APP推送的一条后台消息，其紧急程度天差地别。Paging Priority IE就是用来区分这种优先级的。当锚点基站A收到来自核心网的寻呼时，寻呼消息中会包含优先级信息。A在向B和C转发RAN寻呼时，就会附上这个优先级。基站B和C的调度器看到高优先级的寻呼，就会插队，优先广播出去，确保李雷的电话能被最快接通。”

3.2.3 寻呼辅助信息：Assistance Data for RAN Paging IE

If the Assistance Data for RAN Paging IE is included in the RAN PAGING message, the NG-RAN node2 may use it according to TS 38.300.

陈工的解读：“这是一份非常智能的‘寻人技巧’。UE在进入RRC_INACTIVE状态前，可能会上报一些辅助信息，比如它期望的驻留小区列表。锚点基站A可以将这些信息通过Assistance Data for RAN Paging IE传递给其他基站。例如，如果李雷的手机曾表示更喜欢驻留在某个特定频点的小区，那么基站B和C在寻呼时，就可以重点在该频点的小区进行广播，从而提高寻呼成功率，或者减少不必要的全网广播，节省空口资源。”

3.2.4 UE能力与寻呼策略：UE Radio Capability for Paging IE

If the UE Radio Capability for Paging IE is included in the RAN PAGING message, the NG-RAN node2 may use it to apply specific paging schemes.

陈工的解读：“不同的UE，能力千差万别。比如，有些是早期的Rel-15手机，有些是支持RedCap（轻量化5G）的物联网终端。它们的接收能力、支持的寻呼特性都不同。锚点基站A保存着UE的完整能力信息，它可以通过这个IE，将UE的关键能力（特别是与寻呼相关的部分）告知其他基站。这样，基站B和C就可以采用UE能够理解和接收的特定寻呼方案，而不是‘一刀切’地用默认方式广播。”

3.2.5 深度睡眠的唤醒术：eDRX与长周期eDRX

为了极致省电，特别是对于物联网（IoT）设备，5G引入了扩展非连续接收（eDRX）和长周期eDRX。UE可以与网络约定，进入长达数分钟甚至数小时的“深度睡眠”，只在特定的、稀疏的寻呼时机（Paging Occasion, PO）醒来监听。

When available, the NG-RAN node1 shall include the E-UTRA Paging eDRX Information IE in the RAN PAGING message… When available, the NG-RAN node1 shall include the NR Paging eDRX Information IE in the RAN PAGING message… If the NR Paging eDRX Information for RRC INACTIVE IE is included… If the NR Paging Long eDRX Information for RRC INACTIVE IE is included…

陈工的解读：“这些IE都是为了支持eDRX。想象一下，一个安装在高铁列车上的环境监测传感器，它处于RRC_INACTIVE态，并配置了10分钟的eDRX周期。这意味着它每10分钟才会醒来几毫秒。如果网络不知道这个‘作息规律’，而在其他时间疯狂寻呼它，不仅浪费了大量的空口资源，也永远不可能成功。

因此，锚点基站A必须将UE的eDRX周期、寻呼时间窗等信息，通过这些IE通知给RNA内的其他基站B和C。这样，B和C就知道，只需要在那个特定的寻呼时机广播寻呼消息即可，其他时间完全不必理会。这对于支持大规模物联网设备至关重要。”

3.2.6 其他关键IE

• UE Specific DRX IE：除了eDRX，常规的DRX周期也会影响UE的监听行为，这个IE用于同步该信息。
• Paging Cause IE：指示寻呼的原因，如voice（语音）、data（数据）等，这有助于UE侧进行相应的处理。
• PEIPS Assistance Information IE：用于支持寻呼早期指示（Paging Early Indication），允许UE在正式的寻呼时机之前，通过一个简短的指示信道提前知道是否有针对自己的寻呼，从而进一步优化功耗。
• MT-SDT Information IE：如果寻呼是为了触发一次移动终端发起的小数据传输（MT-SDT），这个IE会携带相关信息。

4. 8.2.5.3 & 8.2.5.4 (失败与异常) - Class 2流程的哲学

8.2.5.3 Unsuccessful Operation Not applicable.

8.2.5.4 Abnormal Condition Void.

陈工指着这两节对小林说：“你看，和SN Status Transfer一样，规范在这里给出了‘不适用’和‘空’。这再次体现了Class 2流程的本质。RAN PAGING是一个尽力而为（best-effort）的通知过程。”

• 没有“失败”：锚点基站A将寻呼请求发出后，它的任务就完成了。它不关心，也无法知道基站B是否成功广播了寻呼，更无法知道UE是否收到了。因此，从XnAP流程层面，不存在“不成功”的状态。
• 没有“异常”：如果基站B收到了一个它无法处理的RAN PAGING消息（比如格式错误），它通常会直接丢弃。因为没有响应机制，它也无法向A报告异常。流程的健壮性依赖于下层SCTP的可靠传输和协议实现的鲁棒性。如果UE最终没有响应寻呼，那么寻呼失败的超时和重传机制将在核心网（AMF）层面被触发，而不是在XnAP层面。

5. 总结：效率与功耗的精妙平衡

RAN Paging流程是5G RRC_INACTIVE态移动性管理中不可或缺的一环。它构建了一个高效的、分布式的寻呼协作网络，在核心网寻呼的基础上，进一步将寻呼能力扩展到整个RAN通知区域。

• 它是分布式的寻呼放大器：使得持有UE上下文的锚点基站，能够动员整个RNA区域内的其他基站共同寻找UE。
• 它是极致效率的追求者：通过采用非UE关联的Class 2信令，实现了寻呼请求的快速、低开销扩散。
• 它是智能省电的协同者：通过传递DRX/eDRX等关键信息，确保了对深度睡眠设备的精准、高效唤醒，避免了不必要的空口资源浪费。
• 它是面向未来的设计：通过丰富的辅助信息IE，为基于UE能力、移动模式和业务优先级的智能化、差异化寻呼策略提供了坚实的基础。

对小林这样的协议开发者来说，RAN PAGING流程的实现，关键在于正确地从核心网寻呼和本地UE上下文中提取所有必要的IE，并正确地组装和发送消息。对于网络规划和优化工程师，合理地规划RNA的大小、配置eDRX参数，直接关系到寻呼成功率、寻呼时延和整个网络的功耗表现。

FAQ

Q1：RAN通知区域（RNA）是如何定义的？它的大小会影响RAN Paging吗？ A1：RNA是由一组跟踪区（Tracking Area, TA）列表组成的，由运营商在基站上配置。其大小对网络性能有直接影响。RNA太大，每次核心网寻呼涉及的基站就多，信令负荷和空口寻呼开销就大；RNA太小，UE很容易移出RNA，导致频繁的RNA更新（RNAU）流程，同样增加信令负荷。RAN Paging正是在这个权衡中发挥作用：在一个相对较大的RNA内，通过基站间的协同寻呼来找到UE。因此，RNA的规划是网络优化的一个重要课题。

Q2：如果一个RNA内的所有基站都没有成功寻呼到UE，接下来会发生什么？ A2：整个寻呼流程是由核心网（AMF）发起的，AMF会启动一个寻呼定时器。如果在这个定时器超时后，UE仍然没有发起RRC Resume流程来响应，AMF就会认为本次寻呼失败。后续的行为取决于核心网的策略，可能包括重试寻呼，或者如果寻呼是由下行数据触发的，UPF可能会丢弃该数据包，并向上层（如TCP）报告发送失败。

Q3：为什么RAN PAGING消息是非UE关联的，但消息内容又是针对某个特定UE的？ A3：这是一个需要精确理解的概念。“UE关联信令”（UE-associated signalling）在XnAP中特指依赖一个已经为该UE建立的、独占的SCTP流或信令连接。而RAN PAGING消息是在一个公共的、非UE专用的SCTP流上传输的，因此称之为“非UE关联”。但是，消息的内容（payload）通过I-RNTI明确指向了一个特定的UE。这就像通过公共邮政系统（非关联传输）寄送一封写有明确收件人地址（UE特定内容）的信件。

Q4：对于RRC_CONNECTED态的UE，网络如何找到它？也需要寻呼吗？ A4：不需要。对于RRC_CONNECTED态的UE，网络（具体是其服务基站）精确地知道它在哪一个小区，并且与它保持着持续的RRC连接和信令交互。当有下行数据到达时，基站可以直接通过调度，在物理下行共享信道（PDSCH）上将数据发送给UE，无需任何寻呼过程。寻呼机制是专门为“失联”的UE（IDLE或INACTIVE态）设计的。

Q5：RAN Paging与核心网的寻呼相比，传递了更多更详细的信息（如eDRX、UE能力等），这是为什么？ A5：这是因为两者的职责不同。核心网（AMF）的寻呼主要负责在NG接口层面触发接入网的寻呼行为，其信息相对宏观，核心是UE的5G-S-TMSI和寻呼区域。而RAN Paging是基站间的协同，其目的是为了优化空口的寻呼效率和成功率。因此，它需要传递更精细的、与无线特性紧密相关的信息，如UE的省电周期（eDRX）、无线能力、期望驻留的小区特性等，以便接收寻呼请求的基站能够采用最适合该UE的无线策略来执行空口广播。