51学通信

深度解析 3GPP TS 38.413：8.8 Configuration Transfer Procedures (配置传输流程)

17分钟阅读

本文技术原理深度参考了3GPP TS 38.413 V18.5.0 (2025-03) Release 18规范中，关于“8.8 Configuration Transfer Procedures”的核心章节，旨在为读者提供一个关于NG-RAN节点间如何通过AMF作为“信使”来交换配置信息，特别是支撑自组织网络（SON）功能的深度洞察。

深度解析 3GPP TS 38.413：8.8 Configuration Transfer Procedures (配置传输流程)

大家好，欢迎回到我们的3GPP规范深度解析系列！在前几期文章中，我们已经深入探讨了NG-C接口从建立、维护到异常恢复的全生命周期管理。今天，我们将聚焦一个非常精巧且实用的接口管理流程——配置传输流程 (Configuration Transfer Procedures)。

我们知道，现代移动网络日益复杂，基站（gNB）之间的协同工作至关重要。例如，为了实现无缝切换，相邻的gNB之间需要建立Xn接口。传统方式下，这需要工程师在网管上为每一对邻居手动配置复杂的传输层信息。但在5G时代，我们追求的是网络的自动化和智能化，即自组织网络（Self-Organizing Network, SON）。

SON的一大核心功能就是自动邻区关系（Automatic Neighbor Relation, ANR），让gNB能够自动发现邻居并建立Xn连接。但这里有一个问题：如果两个gNB之间没有预先配置好IP路由，或者出于网络架构设计的考虑，它们无法直接通信，那该如何交换建立Xn接口所需的初始配置信息（如传输层地址）呢？

Configuration Transfer Procedures正是为了解决这一难题而设计的。它巧妙地利用了gNB与AMF之间已经建立的NG-C接口，将AMF作为一个**“配置信息的中央信使”或“透明代理”**。一个gNB可以将想发送给另一个gNB的配置信息“打包”好，交给AMF，并告诉AMF“收件人地址”；AMF则负责将这个“包裹”原封不动地传递给目标gNB。

为了生动地理解这个“借道传书”的过程，让我们再次请出网络监控专家Morpheus和他的徒弟Neo。他们正在负责一个新站点的开通工作。

  • 现有节点：稳定运行的gNB-CBD-01。

  • 新开通节点：刚刚上电并完成NG Setup的gNB-Newbie-01。

Morpheus将向Neo展示，如何利用Configuration Transfer流程，让gNB-CBD-01自动将其Xn接口的配置信息，通过AMF-Alpha中转，发送给gNB-Newbie-01，从而触发自动化的Xn连接建立。这个过程完美诠释了SON功能的魅力，以及NGAP协议设计的灵活性。

这是gNB向AMF发起，请求其代为转发配置信息的第一步，也是整个“借道传书”之旅的起点。

1.1 通用流程 (General)

8.8.1.1 General

The purpose of the Uplink RAN Configuration Transfer procedure is to transfer RAN configuration information from the NG-RAN node to the AMF. The AMF does not interpret the transferred RAN configuration information. This procedure uses non-UE associated signalling.

这段描述揭示了该流程的两个核心本质：

  1. AMF的“信使”角色：明确指出AMF不解析（does not interpret）传输的RAN配置信息。AMF只关心需要将这个信息包发给谁，而不关心包里具体是什么。

  2. 非UE关联：这是一个纯粹的网元间管理流程，与任何用户的业务状态无关，因此对在线用户完全没有影响。

1.2 成功操作 (Successful Operation)

这是一个由源gNB发起的单向消息流程。如下图“Figure 8.8.1.2-1: Uplink RAN configuration transfer”所示，源gNB向AMF发送一条UPLINK RAN CONFIGURATION TRANSFER消息。

场景引入：

新站点gNB-Newbie-01上线后，网络中的ANR功能被触发。作为邻居的gNB-CBD-01需要与gNB-Newbie-01建立Xn连接。为此，gNB-CBD-01需要将自己的Xn传输层地址（Xn TNL Configuration Info）告知对方。它选择通过AMF-Alpha来完成这次信息传递。

8.8.1.2 Successful Operation

The NG-RAN node initiates the procedure by sending the UPLINK RAN CONFIGURATION TRANSFER message to the AMF.

If the AMF receives the SON Configuration Transfer IE, it shall transparently transfer the SON Configuration Transfer IE towards the NG-RAN node indicated in the Target RAN Node ID IE which is included in the SON Configuration Transfer IE.

1.2.1 gNB的“快递包裹” - UPLINK RAN CONFIGURATION TRANSFER消息

gNB-CBD-01精心准备了一个“快递包裹”，其内容如下：

| IE/Group Name | Presence | Range | IE type and reference | Semantics description | Criticality | Assigned Criticality |

| :--- | :--- | :--- | :--- | :--- | :--- | :--- |

| Message Type | M | | 9.3.1.1 | | YES | ignore |

| SON Configuration Transfer | O | | 9.3.3.6 | | YES | ignore |

| EN-DC SON Configuration Transfer | O | | OCTET STRING | Contains the EN-DC SON Configuration Transfer IE as defined in TS 36.413. | YES | ignore |

| Inter-system SON Configuration Transfer | O | | 9.3.3.33 | | YES | ignore |

这个消息的核心是一个名为SON Configuration Transfer的IE，它本身就是一个容器，里面装载了三样东西：

  1. 收件人地址 (Target RAN Node ID): gNB-CBD-01明确指定，这个包裹是给gNB-Newbie-01的。

  2. 发件人地址 (Source RAN Node ID): gNB-CBD-01写上自己的ID，方便对方回信。

  3. 货物 (SON Information): 这才是真正的配置信息。在这个场景中，它是一个SON Information Request，其类型为Xn TNL Configuration Info，内容就是gNB-CBD-01用于建立Xn接口的IP地址和端口号等信息。

场景演绎：

Morpheus向Neo解释道：“看，gNB-CBD-01现在就像在填写一张快递单。它把自己的Xn地址信息（SON Information）放进一个盒子里，然后在盒子上贴上‘收件人：gNB-Newbie-01’（Target RAN Node ID）和‘发件人：gNB-CBD-01’（Source RAN Node ID）。整个这个大盒子，就是SON Configuration Transfer IE。最后，它把这个大盒子装进一个标准的UPLINK RAN CONFIGURATION TRANSFER快递袋里，交给了邮局——AMF-Alpha。”

AMF-Alpha收到这个消息后，它的工作很简单：

  • 不拆包：它不会去解析SON Information里的具体内容。

  • 看地址：它只看Target RAN Node ID，发现收件人是gNB-Newbie-01。

  • 准备转发：它知道自己也连接着gNB-Newbie-01，于是准备启动下一个流程，将这个“包裹”派送出去。

这是AMF将从源gNB收到的“快递包裹”派送给目标gNB的过程，是整个传输链路的后半段。

2.1 通用流程 (General)

8.8.2.1 General

The purpose of the Downlink RAN Configuration Transfer procedure is to transfer RAN configuration information from the AMF to the NG-RAN node. This procedure uses non-UE associated signalling.

这个流程的触发，正是上一个Uplink流程的结果。AMF作为中间人，启动Downlink流程，完成信息的端到端传递。

2.2 成功操作 (Successful Operation)

流程如图“Figure 8.8.2.2-1: Downlink RAN configuration transfer”所示，AMF向目标gNB发送一条DOWNLINK RAN CONFIGURATION TRANSFER消息。

The procedure is initiated with a DOWNLINK RAN CONFIGURATION TRANSFER message sent from the AMF to the NG-RAN node.

这个消息的内容与上行消息非常相似，它同样携带了那个未被解析的SON Configuration Transfer IE。

场景演绎：

AMF-Alpha现在扮演派件员的角色。它将从gNB-CBD-01收到的SON Configuration Transfer IE原封不动地拿出来，放进一个DOWNLINK RAN CONFIGURATION TRANSFER的新快递袋里，然后通过与gNB-Newbie-01连接的NG接口发送过去。

gNB-Newbie-01收到这个消息后，打开一看：

  • 识别发件人：它看到了Source RAN Node ID是gNB-CBD-01。

  • 处理内容：它解析SON Information，发现这是一个Xn TNL配置请求，并从中获取了gNB-CBD-01的Xn传输层地址。

  • 发起后续动作：有了对方的地址，gNB-Newbie-01现在可以主动向gNB-CBD-01发起Xn Setup流程，建立直接的Xn连接。

If the NG-RAN node receives, in the SON Configuration Transfer IE, the Xn TNL Configuration Info IE containing the Xn Extended Transport Layer Addresses IE, it may use it as part of its ACL functionality configuration actions, if such ACL functionality is deployed.

正如规范所暗示的，目标gNB收到这些传输层地址后，可能会更新其访问控制列表（ACL）或防火墙规则，以允许来自源gNB的Xn流量通过，为后续的Xn建立做好准备。

2.3 请求与应答

Configuration Transfer不仅可以单向推送信息，还可以实现“请求-应答”式的交互。

If the NG-RAN node receives… the SON Information IE containing the SON Information Request IE, it may transfer back the requested information… by initiating the Uplink RAN Configuration Transfer procedure.

场景演绎：

在上面的例子中，gNB-CBD-01主动推送了自己的信息。我们也可以设想另一种情况：gNB-Newbie-01上线后，只知道邻居gNB-CBD-01的ID，但不知道其Xn地址。

  1. 请求：gNB-Newbie-01可以先发起一个UPLINK RAN CONFIGURATION TRANSFER，目标是gNB-CBD-01，但SON Information的类型是SON Information Request，请求对方提供Xn TNL信息。

  2. 中转：AMF-Alpha将这个请求通过DOWNLINK RAN CONFIGURATION TRANSFER转发给gNB-CBD-01。

  3. 应答：gNB-CBD-01收到请求后，再发起一个新的UPLINK RAN CONFIGURATION TRANSFER，这次SON Information的类型是SON Information Reply，其中包含了它自己的Xn TNL信息。

  4. 送达：AMF-Alpha再将这个应答转发给gNB-Newbie-01。

通过这样一来一回的两次传输，就完成了一次完整的“远程信息查询”。

FAQ

Q1: 既然gNB之间有Xn接口，为什么还需要通过AMF来传输配置信息？

A1:

这是一个“先有鸡还是先有蛋”的问题。Xn接口的建立，需要双方预先知道彼此的传输层地址（IP地址等）。Configuration Transfer流程主要解决的就是在Xn接口建立之前，或者在两个gNB之间没有直接IP路由的情况下，如何交换这些“引导信息”。AMF作为所有gNB都连接的中心节点，天然成为了一个理想的“信息中转站”。一旦通过AMF交换了初始信息并成功建立了Xn接口，后续大量的切换、双连接等信令就可以通过更高效的Xn接口直接交互了。

Q2: AMF在这个流程中真的完全“透明”吗？它会利用这些信息做什么吗？

A2:

根据38.413规范的定义，AMF的角色是完全透明的。它不解析SON Information的具体内容，只是根据Target RAN Node ID进行路由。这保证了RAN内部的配置逻辑（如SON算法）与核心网解耦。AMF不关心也不参与gNB之间如何进行自配置，它只提供一个可靠的传输通道。这是一种清晰的架构分层设计。

Q3: 这个流程的实时性要求高吗？会不会很慢？

A3:

这个流程的实时性要求不高。它主要用于非实时的网络自配置和自优化任务，如ANR。建立一个Xn接口通常不是一个需要毫秒级完成的动作。相比于用户面的数据传输或切换信令，配置传输的流量非常小，频率也非常低。因此，通过AMF进行几次消息中转所带来的额外时延，对于SON这类后台任务来说是完全可以接受的。

Q4: 除了用于Xn接口建立（ANR），Configuration Transfer还有哪些应用场景？

A4:

它的应用场景非常广泛，几乎涵盖了所有需要gNB之间交换非实时配置信息的SON功能。例如：

  • 负载均衡优化 (Load Balancing)：一个gNB可以将其高负载状况通过此流程通知邻居，请求邻居调整切换门限，将一些用户切换走。

  • 移动性鲁棒性优化 (Mobility Robustness Optimization, MRO)：gNB之间可以交换切换失败、切换过早/过晚等统计信息，用于自动优化切换参数。

  • 跨RAT/系统的信息传递：规范中定义的EN-DC SON Configuration Transfer和Inter-system SON Configuration Transfer IE表明，这个机制甚至可以扩展到5G与4G之间。例如，一个gNB可以通过5GC和EPC的互通，将配置信息发送给一个4G的eNB，用于优化双连接（EN-DC）的邻区关系。

Q5: 如果AMF收到了一个UPLINK RAN CONFIGURATION TRANSFER，但它发现Target RAN Node ID所指向的gNB自己并不认识（例如，该gNB已下线或属于另一个AMF），AMF会怎么处理？

A5:

AMF会简单地丢弃这个消息。因为UPLINK RAN CONFIGURATION TRANSFER是一个单向的Class 2流程，AMF收到后不需要回复ACK。如果AMF无法找到目标gNB，它就没有地方可以转发，只能丢弃。

对于发起请求的源gNB来说，它可能会启动一个定时器等待预期的响应（例如，如果它是在“请求-应答”模式下工作）。如果定时器超时，它就会知道这个流程失败了，可能会记录日志告警，或者在一段时间后重试。这体现了分布式系统中，通过超时机制来处理消息丢失或无法投递的典型做法。

关系图谱