51学通信

深度解析 3GPP TS 38.410：6.26 MT Communication Handling procedures (MT通信处理流程)

12分钟阅读

好的，我们继续跟随5G基站工程师小雷，深入探索NG接口上那些与网络状态和用户体验息息相关的高级流程。这一次，我们将聚焦于一个在特定场景下，为保障用户体验连续性而设计的关键流程——MT通信处理流程。

深度解析 3GPP TS 38.410：6.26 MT Communication Handling procedures (MT通信处理流程)

本文技术原理深度参考了3GPP TS 38.410 V18.2.0 (2024-06) Release 18规范中，关于“6.26 MT Communication Handling procedures”的核心章节，并结合其在核心网（TS 23.501/502）和NGAP协议（TS 38.413）中的具体实现，为读者完整呈现5G网络中，针对处于RRC_INACTIVE状态的UE，当有下行数据到达时，gNB与AMF之间是如何通过NG接口进行协同，以确保UE能够被成功唤醒并接收数据的。

引言：当“信使”敲响“空房间”的门

我们的主角，基站工程师小雷，对他所负责的gNB中RRC_INACTIVE状态的用户（UE）了如指掌。这种状态，是5G为了在“快速恢复”和“终端省电”之间取得最佳平衡而设计的“浅度睡眠”模式。

在这种模式下：

  • UE的核心网连接（NG-C）保持着，AMF认为UE是CONNECTED的。
  • UE的无线连接（RRC）被释放了，UE进入了省电的睡眠状态。
  • UE的上下文（“临时档案”）被保留在gNB中。

现在，一个经典的难题出现了：当一封“加急信件”（下行数据或信令）到达核心网，需要送给一个正处于INACTIVE“浅度睡眠”中的UE时，会发生什么？

核心网（AMF/UPF）只知道这个UE最后是在小雷的gNB上“睡着”的，于是它会像往常一样，通过NG接口，将这封信发给小雷的gNB。

但小雷的gNB收到了这封信后，却发现收件人的“房间”（RRC连接）是空的！他无法直接将信件递送给UE。此时，gNB必须立刻向AMF“回拨电话”，报告：“收件人不在，请启动寻呼（Paging），把他叫回来！”

第6.26节定义的“MT通信处理流程”，正是为应对这一“信使敲响空房间门”的场景而设计的核心信令交互机制。

1. 流程的“剧本”：MT通信处理的“一推一拉”

6.26 MT Communication Handling procedures

The following procedures are used by the NG-RAN node to request the AMF to activate or deactivate the CN based MT communication handling for UEs in RRC_INACTIVE state…, and by the 5GC to indicate availability of downlink data or downlink signalling to the NG-RAN node.

  • MT Communication Handling procedure;
  • RAN Paging Request procedure;
  • Path Switch Request procedure.

6.26节为我们定义了MT（Mobile Terminated，移动终端终结的，即下行）通信处理的核心流程。我们将重点解读前两个：

  1. MT Communication Handling procedure: 这是核心网（5GC）向gNB**“推（Push）”**下行流量的通用流程。
  2. RAN Paging Request procedure: 这是gNB在发现UE“不在家”后，向核心网（AMF）“拉（Pull）”起寻呼请求的反向触发流程。

这两个流程的一“推”一“拉”，共同构成了一个完整的、针对INACTIVE态UE的下行业务唤醒闭环。

2. “信使上门”：MT Communication Handling Procedure (下行传输)

这个流程在NGAP中，由DOWNLINK RAN TRANSPORT和DOWNLINK UE ASSOCIATED NON-3GPP TRANSPORT等多个具体的下行传输流程来承载。它们的共性是，由AMF发起，向gNB发送需要递送给UE的数据或信令。

实战演练（一）：一封来自核心网的“信件”

  • 触发: 核心网有下行数据（来自UPF）或下行NAS信令（来自AMF自身）要发送给一个处于INACTIVE状态的UE。AMF知道这个UE的上下文还保留在小雷的gNB上。

  • AMF → gNB (DOWNLINK RAN TRANSPORT / DOWNLINK NAS TRANSPORT):

    • 流程启动！ AMF向小雷的gNB发送相应的下行传输消息。例如，如果是NAS信令，就是DOWNLINK NAS TRANSPORT。
    • 消息内容: 包含了要传给UE的NAS-PDU或用户数据，以及UE的RAN UE NGAP ID。

  • gNB的“收信”动作:

    • 小雷的gNB收到了这条下行传输消息。
    • 它首先检查本地的UE上下文，发现这个UE正处于RRC_INACTIVE状态。
    • gNB意识到，它无法立即将这封信送达。
    • 此时，gNB会暂时缓存这封“信件”，并立即启动下一步的“回拨电话”流程。

3. “回拨电话”：RAN Paging Request Procedure (RAN寻呼请求流程)

这是整个INACTIVE态下行唤醒机制中最关键、最独特的一步。

NGAP Procedure: RAN Paging Request (NG-RAN node initiated)

实战演练（二）：gNB请求“总台寻人”

  • 触发: gNB在收到下行数据/信令，但发现目标UE处于INACTIVE状态后，立即启动此流程。

  • gNB → AMF (RAN PAGING REQUEST):

    • 流程启动！ gNB作为发起方，主动向AMF发送RAN PAGING REQUEST消息。
    • 消息内容（“寻人请求”）:
      • AMF UE NGAP ID, RAN UE NGAP ID: 明确要寻呼的是哪个UE。
      • Paging Origin: 指明寻呼原因（例如，因为收到了下行信令）。
      • Paging Priority: 告知AMF这次寻呼的紧急程度。
    • 这条消息的本质是，gNB在向AMF报告：“指挥中心请注意，你发给‘张三’的信我已收到，但他目前不在服务区，请立即启动寻呼，将他找回！”

  • AMF的响应动作:

    • AMF收到这个来自gNB的“反向寻呼请求”后，就明白了情况。
    • AMF会立即启动标准的寻呼流程（6.5节）。但这一次，寻呼的范围被极大地优化了。
    • AMF不会在整个TA内进行“地毯式”寻呼，而是只在之前由gNB为该UE配置的、一个更小的**RAN-based Notification Area (RNA)**内发起寻呼。RNA可能只包含几个或十几个小区。
    • AMF向RNA内的所有gNB（可能不止小雷的gNB）发送PAGING消息。

  • UE的唤醒与恢复:

    • 处于INACTIVE状态的UE被寻呼唤醒。
    • UE向其当前所在的gNB（可能是原来的gNB，也可能是一个新的gNB）发起RRC Resume Request。
    • UE恢复到CONNECTED状态。
    • gNB最终将之前缓存的那封“信件”，成功地递送给UE。

4. 流程的意义：INACTIVE态的“闭环守护者”

这套由DOWNLINK TRANSPORT的“前向试探”和RAN PAGING REQUEST的“反向触发”构成的协同机制，是5G RRC_INACTIVE状态能够真正实用化的关键闭环。

  • 明确了职责划分:

    • AMF是寻呼的发起者和决策者。它掌握着UE的TA级位置，并负责向整个寻呼区下发指令。
    • gNB是INACTIVE状态的感知者和寻呼的触发者。它最先知道下行数据无法送达，并负责将这个“异常”上报给AMF，请求其采取行动。

  • 实现了寻呼的精-准化:

    • 通过gNB的反向触发，AMF得知这是一个针对INACTIVE态UE的寻呼。这使得AMF可以使用范围更小、效率更高的RNA寻呼，而不是低效的TA寻呼，极大地节省了信令资源。

  • 保障了下行业务的可达性:

    • 这套流程，为处于“浅度睡眠”的UE，提供了一条可靠的、由网络驱动的唤醒路径。它确保了即使用户为了省电而关闭了RRC连接，重要的下行通知（如微信电话、App推送）依然能够及时地将他“叫醒”，保障了用户体验的连续性。

总结：于无声处的“推”与“拉”，维系永在线的体验

通过对6.26节核心流程的深度剖析，我们看到了一个精巧的、由RAN和核心网协同完成的“推-拉”模型，它完美地解决了INACTIVE状态下的下行数据送达难题。

  • AMF的“推” (Downlink Transport): 代表了核心网对gNB保留上下文的“信任”，它假定gNB能够处理好后续的递送。
  • gNB的“拉” (RAN Paging Request): 代表了RAN在发现异常时的“责任”，它在无法完成任务时，主动将“皮球”踢回给拥有最终寻呼决策权的AMF。

对于基站工程师小雷来说，RAN PAGING REQUEST是他信令日志中一个非常重要的观测指标。这条上行信令的频繁出现，标志着他所负责的网络中，有大量的INACTIVE态用户正在被成功地唤醒，这说明INACTIVE这个高级功能正在健康、高效地运作。而如果他看到了大量的下行数据，却没有触发相应的RAN PAGING REQUEST或UE恢复，那就可能意味着INACTIVE的流程中，出现了意想不到的“断点”。这套流程，为他深入理解和优化5G的连接态管理和终端功耗，提供了最直接的信令级视图。

关系图谱