51学通信

深度解析 3GPP TS 38.423：8.2.6 XN-U Address Indication (Xn-U地址指示)

20分钟阅读

深度解析 3GPP TS 38.423：8.2.6 XN-U Address Indication (Xn-U地址指示)

本文技术原理深度参考了3GPP TS 38.423 V18.5.0 (2025-03) Release 18规范中，关于“8.2.6 Xn-U Address Indication”的核心章节，旨在为读者深入剖析在移动性场景下，用户平面数据转发路径是如何通过XnAP信令建立的。

1. 引言：为“在途”数据包指明新方向

在上一篇文章中，我们的工程师小林已经见证了新基站B如何通过Retrieve UE Context流程，从旧基站A那里成功获取了RRC_INACTIVE态用户“李雷”的完整档案。李雷的手机即将在新基站B的指挥下苏醒，恢复RRC_CONNECTED态。

“陈工，”小林看着流程图，兴奋地说，“既然上下文已经成功转移，新基站B现在拥有了李雷的所有信息，是不是就可以直接为他提供服务了？”

“理论上是的，”导师陈工回答道，“B现在可以和UE建立安全连接，为他的业务重建无线承载。但是，有一个非常现实的问题需要解决。就在李雷的手机向B发起Resume请求的那一刻，甚至在那之前的几百毫秒，核心网可能仍然在向旧基站A发送属于李雷的数据包。这些数据包已经‘在路上’了，它们不知道李雷已经‘搬家’到了B。如果我们不处理这些‘在途’的数据，它们就会丢失，对于用户来说，可能就是微信消息延迟，或者正在加载的网页图片卡住。”

“那该怎么办？”小林追问。

“这就需要一个‘快递转运’机制，我们称之为数据转发（Data Forwarding），”陈工解释道，“旧基站A需要把这些收到的、但还没来得及发给UE的数据包，转发给新基站B，再由B发送给UE。但A怎么知道要转寄到哪里去呢？B必须主动给A提供一个精确的‘收货地址’。这个提供‘收货地址’的信令流程，就是我们今天要学习的Xn-U Address Indication。”

这个流程的使命在规范的8.2.6.1节“General”中得到了清晰的定义：

For the retrieval of a UE context, the Xn-U Address Indication procedure is used to provide forwarding addresses from the new NG-RAN node to the old NG-RAN node for all PDU session resources successfully established at the new NG-RAN node for which forwarding was requested… For MR-DC with 5GC, the Xn-U Address Indication procedure is used to provide data forwarding related information, and Xn-U bearer address information for completion of setup of SN terminated bearers from the M-NG-RAN node to the S-NG-RAN node as specified in TS 37.340.

这段话揭示了该流程的两个主要应用场景：

  1. UE上下文检索后：新基站向旧基站提供下行数据转发地址。
  2. 双连接（MR-DC）场景中：用于在主（M-NG-RAN）从（S-NG-RAN）节点间传递用户平面承载的地址信息，以完成建立或进行数据转发。

今天，我们将聚焦于这两个场景，看看这个简洁而关键的Class 2流程，是如何为用户平面的数据流搭建起临时“桥梁”的。

2. Xn-U的本质：控制面为用户面铺路

在深入流程之前，陈工强调了一个基础概念：“小林，你必须时刻牢记控制面（C-Plane）和用户面（U-Plane）的分离。XnAP协议，包括我们今天要讲的XN-U ADDRESS INDICATION消息，都运行在Xn-C接口上。它的任务是‘发号施令’。而它所指挥建立的‘数据转发通道’，则是运行在Xn-U接口上，通常是一个GTP-U隧道。”

  • Xn-C (控制平面)：基站间的信令交互，使用XnAP协议，承载在SCTP/IP之上。
  • Xn-U (用户平面)：基站间的用户数据传输，使用GTP-U协议，承载在UDP/IP之上。

XN-U ADDRESS INDICATION消息的核心作用，就是在Xn-C上传递一个信令，告诉对端：“对于某个用户的某个业务，请把数据发到我这个位于Xn-U接口上的IP地址和GTP隧道端点ID（GTP-TEID）上。”

这就像你打电话（控制面）告诉快递公司（源基站）：“我搬家了，请把我的包裹（用户数据）转寄到xx路xx号的新地址（用户面地址）。”电话本身不运送包裹，但它决定了包裹的最终去向。

3. 场景一：上下文检索后的“收货地址”通知

这是Xn-U Address Indication最经典的应用场景，紧密衔接在我们上一章学习的Retrieve UE Context之后。

3.1 8.2.6.2 Successful Operation (UE Context Retrieval)

The Xn-U Address Indication procedure is initiated by the new NG-RAN node. Sending the XN-U ADDRESS INDICATION message, the new NG-RAN node informs the old NG-RAN node of successfully established PDU Session Resource contexts… to which user data pending at the old NG-RAN node can be forwarded.

我们来看规范中的Figure 8.2.6.2-1: Xn-U Address Indication, successful operation for UE context retrieval，它清晰地展示了这一流程：

场景再现： 李雷的手机在基站B下被唤醒，基站B从基站A成功检索到UE上下文。

  1. 新基站B分配转发资源：在成功为李雷的各个PDU会话（视频、下载等）在本地建立好无线承载和到核心网的用户面路径后，如果基站A在之前的交互中提议了数据转发，基站B就会为这些会话分配用于接收转发数据的GTP-U隧道资源。这包括一个IP地址和一个GTP-TEID。

  2. 新基站B发送XN-U ADDRESS INDICATION：基站B（new NG-RAN node）向基站A（old NG-RAN node）发送XN-U ADDRESS INDICATION消息。这个消息是一个Class 2流程，即单向通知，B发出去后就认为任务完成，无需等待A的回复。

  3. 旧基站A启动数据转发：

    Upon reception of the XN-U ADDRESS INDICATION message, the old NG-RAN node should forward pending user data to the indicated TNL addresses.

    基站A收到消息后，解析出其中的IP地址和GTP-TEID，然后立即将本地缓存的、尚未成功发送给李雷的下行数据包，通过Xn-U接口上的这个GTP-U隧道，转发给基站B。

XN-U ADDRESS INDICATION消息的核心内容解析：

  • Xn-U Address Information per PDU Session Resources List: 这是一个列表，因为一个UE可能有多个PDU会话，每个会话都需要独立的转发路径。
    • PDU Session ID: 明确指示这个转发地址是用于哪个PDU会话的。
    • Data Forwarding Info from target NG-RAN node: 这个IE是关键，它包含了真正的“收货地址”。
      • UP Transport Layer Information: 包含了IP地址。
      • GTP-TEID: 包含了隧道端点ID。

陈工打了个比方：“UP Transport Layer Information就像是告诉A‘包裹请送到xx物流中心（B的IP地址）’，而GTP-TEID则是‘送到后，请交给38号月台（隧道ID）’。两者结合，才能确保数据包被精确地送到B为这个特定业务准备的处理进程中。”

4. 场景二：双连接中的用户面路径协调

Xn-U Address Indication在双连接（MR-DC）中也扮演着重要角色，但场景更为多样和复杂。

4.1 8.2.6.2 Successful Operation (MR-DC with 5GC)

规范中的Figure 8.2.6.2-2展示了其中一种场景，消息从M-NG-RAN node发往S-NG-RAN node。

The Xn-U Address Indication procedure is initiated by the M-NG-RAN node. Upon reception of the XN-U ADDRESS INDICATION message, in case of data forwarding, the S-NG-RAN node should forward pending DL user data to the indicated TNL addresses…

陈工的解读：“小林，这里的场景比上下文检索要复杂一些，我们来分析一下。在双连接中，主节点（MN）是‘总指挥’。虽然SN的初始用户面地址通常是在S-NODE ADDITION REQUEST ACKNOWLEDGE消息中就告诉了MN，但XN-U ADDRESS INDICATION作为一个更灵活的工具，用于后续的各种动态调整。”

一个典型的场景是SN变更（SN Change）：

  1. 李雷的手机正处于双连接状态，主站是MN，次站是SN1。
  2. 由于移动，MN决定将次站从SN1变更为SN2。
  3. MN会与SN2进行S-NODE ADDITION流程，建立资源。
  4. 为了保证数据连续性，MN需要安排SN1将“在途”数据转发给SN2。但SN1并不知道SN2的地址。
  5. 此时，作为“总指挥”的MN，在从SN2的ADDITION ACK中获取其转发地址后，就可以通过XN-U ADDRESS INDICATION消息，将SN2的地址告知给SN1。消息的方向就是 MN -> SN1。
  6. SN1收到这个地址后，就开始向SN2转发数据。

“所以，这个流程在双连接中，更多体现的是主节点作为中央协调者，在各个节点间传递和同步用户面路径信息的作用。”

双连接场景下的特殊IE：

  • DRB IDs taken into use IE：在DC场景下，业务是按数据无线承载（DRB）来划分的，这个IE明确了地址是用于哪些DRB的。
  • CHO MR-DC Indicator IE 或 CPC Data Forwarding indicator IE：这些IE用于条件切换（CHO）或条件PSCell变更（CPC）的特殊场景，指示本次地址交换是用于条件切换的数据转发协调，S-NG-RAN节点需要根据37.340规范执行特殊的转发逻辑（如早期数据转发或停止早期数据转发）。

5. 流程的终结：为何没有失败？

5.1 8.2.6.3 Unsuccessful Operation & 8.2.6.4 Abnormal Conditions

Not applicable. Void.

陈工指着这两节说：“和我们之前学过的所有Class 2流程一样，XN-U Address Indication也没有‘失败’和‘异常’的流程定义。你要深刻理解这背后的设计哲学。”

“这是一个单向的、尽力而为的通知。发起方（比如新基站B）发送地址，是希望接收方（旧基站A）能配合进行数据转发。如果A因为某些原因（比如已经删除了上下文）没有执行转发，B是不知道的，XnAP层面也没有机制让A去报告这个失败。”

“那数据丢失了怎么办？”小林问。

“这就是分层协议栈的魅力所在，”陈工答道，“数据转发本身是一种优化机制，是为了减少高层协议（如TCP）的重传。如果转发失败，最坏的情况就是数据包丢失。最终，位于终端和服务器上的TCP协议会因为收不到ACK而超时重传，保证数据的最终可靠性。也就是说，XnAP尽力去优化，但把最终的可靠性保证交给了更上层的协议。这是一种典型的‘乐观设计’，在绝大多数情况下都能工作得很好，并且极大地简化了协议设计，提升了效率。”

6. 总结：控制与承载的握手

XN-U ADDRESS INDICATION流程虽然在整个XnAP规范中只是一个小节，但它扮演的角色却至关重要。它是在控制面完成资源准备之后，打通用户面数据路径的“最后一环”，是实现无损移动性的具体执行者之一。

  • 它是数据转发的“导航信”：为旧基站或源节点指明了数据转发的目标地址，是构建临时数据“桥梁”的信令基础。
  • 它是场景适应的“多面手”：既能服务于RRC_INACTIVE态恢复后的数据转发，也能在复杂的双连接移动性场景（如SN变更）中扮演关键的协调角色。
  • 它是协议效率的“典范”：采用Class 2单向通知模式，流程简洁，交互开销小，完美契合了移动性管理对时延的苛刻要求。

对于协议开发者小林来说，这个流程的挑战在于正确地管理GTP-U隧道资源，并在正确的时机（如资源建立成功后）触发该消息的发送。对于网络测试和优化工程师，当分析切换或双连接过程中的丢包问题时，通过抓包检查XN-U ADDRESS INDICATION消息是否被正确发送，以及其中携带的地址是否正确，是定位问题的重要手段。

FAQ

Q1：在HANDOVER REQUEST ACKNOWLEDGE消息中不是已经有目标基站的用户面地址了吗？为什么还需要一个单独的XN-U ADDRESS INDICATION消息？ A1：这是一个非常好的问题，涉及到两种不同目的的用户面路径。在HANDOVER REQUEST ACKNOWLEDGE中，目标基站提供的是UE切换成功后，用于与核心网（UPF）通信的用户面隧道地址（PDU Session Resource Admitted List中的UP TNL Information）。而XN-U ADDRESS INDICATION提供的是用于在源基站和目标基站之间进行数据转发的临时用户面隧道地址。前者是“正式”的数据路径，后者是“临时”的转运路径，两者目的不同，地址也可能不同。

Q2：XN-U ADDRESS INDICATION消息中可以包含多个PDU会话的转发地址，它们是使用同一个GTP-U隧道吗？ A2：不一定。规范允许为不同的PDU会话，甚至一个PDU会话内的不同QoS流，建立不同的转发隧道。XN-U ADDRESS INDICATION消息的设计非常灵活，可以在PDU Session Resources ... List中为每个PDU会话指定独立的Data Forwarding Info。此外，Secondary Data Forwarding Info IE甚至允许为一个PDU会话建立多个转发隧道，以支持如冗余传输等高级特性。

Q3：如果新基站B不希望旧基站A进行数据转发，会怎么样？ A3：新基站B有权决定是否接收转发数据。在切换准备阶段，源基站A在HANDOVER REQUEST中会“提议”进行数据转发。如果新基站B不希望接收，或者没有能力处理转发数据，它可以在回复的HANDOVER REQUEST ACKNOWLEDGE中不提供用于数据转发的UP TNL Information。这样，B就不会发送XN-U ADDRESS INDICATION，A也就不会启动数据转发流程。

Q4：在双连接场景下，XN-U ADDRESS INDICATION和S-NODE MODIFICATION等流程是什么关系？ A4：它们是协同工作的关系。例如，当MN需要修改SN上的承载时，它会发起S-NODE MODIFICATION流程（Class 1，有问有答），协商承载的QoS、RLC模式等控制面参数。如果这次修改涉及到用户面路径的变化（比如需要为新添加的DRB建立转发隧道），那么XN-U ADDRESS INDICATION（Class 2）就可能被用来单向地、快速地通知对端新的用户面隧道地址。简而言之，MODIFICATION等流程负责“协商决策”，而ADDRESS INDICATION负责“通知执行”用户面地址的更新。

Q5：UE Context Release流程和XN-U Address Indication流程的先后顺序是怎样的？ A5：XN-U Address Indication通常发生在UE Context Release之前。典型的顺序是：

  1. 新基站B检索到上下文。
  2. 新基站B为数据转发分配资源，并通过XN-U ADDRESS INDICATION将地址发给旧基站A。
  3. 旧基站A开始向B转发数据。
  4. UE成功在新基站B上完成接入。
  5. 新基站B向旧基站A发送UE Context Release，通知A可以彻底删除该UE的所有信息。
  6. A收到UE Context Release后，停止数据转发，并释放所有与该UE相关的资源。

关系图谱