本文技术原理深度参考了3GPP TS 38.413 V18.5.0 (2025-03) Release 18规范中，关于“8.7 Interface Management Procedures”的核心章节，旨在为读者提供一个关于NG-C接口从建立、维护到异常处理全生命周期管理的深度洞察。
深度解析 3GPP TS 38.413：8.7.1 NG Setup (NG接口建立)
大家好，欢迎回到我们的3GPP规范深度解析系列。在之前的文章中，我们已经深入探讨了UE上下文管理、移动性管理以及NAS消息传输等与单个用户紧密相关的流程。今天，我们将把视角从“用户”拉回到“网络”本身，探讨一个更为基础但至关重要的议题——接口管理流程（Interface Management Procedures）。
如果说之前我们讨论的流程是网络如何为“客户”（UE）提供服务，那么今天的内容就是网络设备之间如何“入职报道”和“建立工作关系”。具体来说，我们将聚焦于NG-C接口（gNB与AMF之间的信令接口）生命周期的第一个动作：NG Setup (NG接口建立)。
这个流程是gNB和AMF之间一切信令交互的基石。当一个全新的gNB被部署、开机并接入传输网络后，它如何向核心网的AMF“自我介绍”？它需要告诉AMF自己是谁、能覆盖哪些区域、能提供哪些服务（切片）？而AMF又如何回应，告诉gNB自己的身份、服务范围以及当前的负载情况？所有这些初始信息的交换，都由NG Setup流程来完成。
为了形象地理解这个过程，我们将构建一个网络部署的场景：
- 主角：一个新安装在城市CBD区域的gNB，我们称之为“gNB-CBD-01”。
- 协作方：位于城市核心机房的一台AMF，我们称之为“AMF-Alpha”。
我们将通过模拟“gNB-CBD-01”首次上电，与“AMF-Alpha”建立工作联系的全过程，来深度剖析8.7.1 NG Setup的每一个细节。这就像一位新员工（gNB）向公司总部（AMF）报到，交换彼此的“名片”和“职责范围”，为后续服务成千上万的用户打下坚实基础。
1. NG Setup 流程概述 (General)
NG Setup是NG-C接口上电后的“开场白”，是两个网元实体间建立互信和互操作性的第一个正式步骤。
1.1 流程的目标与时机
规范对NG Setup流程的定义明确指出了其核心目标和触发时机。
8.7.1.1 General The purpose of the NG Setup procedure is to exchange application level data needed for the NG-RAN node and the AMF to correctly interoperate on the NG-C interface. This procedure shall be the first NGAP procedure triggered after the TNL association has become operational.
这段话包含三个关键信息：
- 目的：交换应用层配置数据。这不同于底层的IP地址或端口号，而是更高层次的、与5G业务功能相关的信息，如gNB的全局ID、支持的服务区域、支持的网络切片等。
- 时机：在TNL（传输网络层）关联可用后触发的第一个NGAP流程。TNL关联可以理解为gNB和AMF之间的物理或逻辑网络通路已经打通（例如，SCTP连接已成功建立）。路通了，才能开始跑应用层的“车”。
- 特性：这是一个“清零并重建”的过程。
This procedure erases any existing application level configuration data in the two nodes, replaces it by the one received and clears AMF overload state information at the NG-RAN node.
这意味着每次执行NG Setup，都会清除gNB和AMF之间关于彼此的所有旧的应用层配置，并用本次流程中收到的新信息完全替代。这确保了接口状态的同步和一致性，特别是在gNB重启或配置变更后。
场景引入： 现场工程师完成了“gNB-CBD-01”的安装和上电。gNB-CBD-01的传输网络配置（IP地址、到AMF-Alpha的路由等）已经生效，它成功与AMF-Alpha之间建立了一个SCTP连接。此时，这条通信管道已经就绪，但双方还不知道对方的“身份”和“业务能力”。gNB-CBD-01现在要做的第一件事，就是发起NG Setup流程。
2. 成功的NG Setup流程 (Successful Operation)
一个成功的NG Setup流程是一个简单的“请求-响应”交互，由gNB发起，AMF确认。
规范原文中的“Figure 8.7.1.2-1: NG setup: successful operation”清晰地描绘了这一交互过程：
- NG-RAN node → AMF:
NG SETUP REQUEST - AMF → NG-RAN node:
NG SETUP RESPONSE
让我们深入这两条消息的内部，看看gNB和AMF是如何交换“名片”的。
2.1 第一步：gNB的“自我介绍” - NG SETUP REQUEST
作为新加入网络的成员，gNB-CBD-01首先需要向核心网的AMF进行全面的自我介绍。
8.7.1.2 Successful Operation The NG-RAN node initiates the procedure by sending an NG SETUP REQUEST message including the appropriate data to the AMF.
这个NG SETUP REQUEST消息中包含了gNB的核心配置信息，我们可以将其比作一张内容详尽的“gNB名片”。
表格 9.2.6.1-1: NG SETUP REQUEST 消息内容
| IE/Group Name | Presence | Range | IE type and reference | Semantics description | Criticality | Assigned Criticality |
|---|---|---|---|---|---|---|
| Message Type | M | 9.3.1.1 | YES | reject | ||
| Global RAN Node ID | M | 9.3.1.5 | YES | reject | ||
| RAN Node Name | O | PrintableString (SIZE(1..150, …)) | YES | ignore | ||
| Supported TA List | 1 | Supported TAs in the NG-RAN node. | YES | reject | ||
| >Supported TA Item | 1.. | - | ||||
| >>TAC | M | 9.3.3.10 | Broadcast TAC | - | ||
| >>Broadcast PLMN List | 1 | - | ||||
| >>>Broadcast PLMN Item | 1.. | - | ||||
| >>>>PLMN Identity | M | 9.3.3.5 | Broadcast PLMN | - | ||
| >>>>TAI Slice Support List | M | Slice Support List 9.3.1.17 | Supported S-NSSAIs per TAC, per PLMN or per SNPN. | - | ||
| >>>>NPN Support | O | 9.3.3.44 | If the NID IE is included, it identifies a SNPN together with the PLMN Identity IE. | YES | reject | |
| >>>>Extended TAI Slice Support List | O | Extended Slice Support List 9.3.1.191 | Additional Supported S-NSSAIs per TAC, per PLMN or per SNPN. | YES | reject | |
| >>>>TAI NSAG Support List | O | 9.3.1.238 | NSAG information associated with the slices per TAC, per PLMN or per SNPN. | YES | ignore | |
| >>Configured TAC Indication | O | 9.3.3.50 | YES | ignore | ||
| >>RAT Information | O | 9.3.1.125 | RAT information associated with the TAC of the indicated PLMN(s). | YES | reject | |
| Default Paging DRX | M | Paging DRX 9.3.1.90 | YES | ignore | ||
| UE Retention Information | O | 9.3.1.117 | YES | ignore | ||
| NB-IoT Default Paging DRX | O | 9.3.1.137 | YES | ignore | ||
| Extended RAN Node Name | O | 9.3.1.193 | YES | ignore |
核心IE解读：
- Global RAN Node ID (全局RAN节点ID)：这是gNB在全球范围内的唯一标识，是它的“身份证号”，用于网络中所有节点对其进行唯一识别。
- Supported TA List (支持的TA列表)：这是gNB汇报其“管辖范围”的核心部分。它会列出自己覆盖的所有跟踪区（TA），每个TA由一个跟踪区码（TAC）和其所属的PLMN（运营商网络）列表组成。
- TAI Slice Support List (TAI切片支持列表)：在每个TA内，gNB还会明确声明自己支持哪些网络切片（通过S-NSSAI标识）。这至关重要，AMF可以据此判断该gNB是否能满足特定用户的切片服务需求。
- Default Paging DRX (默认寻呼DRX周期)：gNB向AMF声明，如果没有特殊指示，它将使用这个默认的DRX周期去寻呼UE。
- UE Retention Information (UE保留信息)：gNB可以通过此IE向AMF提议，在接口发生短暂故障恢复后，是否尝试保留（retain）UE上下文，以实现快速恢复。
场景演绎：
gNB-CBD-01向AMF-Alpha发送的NG SETUP REQUEST消息，内容可以通俗地理解为：
“你好，我是新来的gNB-CBD-01，我的全球ID是[…]。我覆盖了CBD区域的两个跟踪区（TAC=1001, TAC=1002）。在这两个区域，我支持‘超高速下载’（eMBB切片）和‘低时延高清直播’（URLLC切片）两种服务。我的默认寻呼周期是1.28秒。我建议我们在接口故障后保留UE上下文，以便快速恢复服务。”
2.2 第二步：AMF的“欢迎与告知” - NG SETUP RESPONSE
AMF-Alpha在收到gNB-CBD-01的“报到请求”后，会进行审核。如果接受，它将回复NG SETUP RESPONSE消息，这相当于AMF向gNB递出的“回执名片”和“工作手册”。
The AMF responds with an NG SETUP RESPONSE message including the appropriate data.
表格 9.2.6.2-1: NG SETUP RESPONSE 消息内容
| IE/Group Name | Presence | Range | IE type and reference | Semantics description | Criticality | Assigned Criticality |
|---|---|---|---|---|---|---|
| Message Type | M | 9.3.1.1 | YES | reject | ||
| AMF Name | M | 9.3.3.21 | This IE is ignored if the Extended AMF Name IE is present. | YES | reject | |
| Served GUAMI List | 1 | YES | reject | |||
| >Served GUAMI Item | 1.. | - | ||||
| >>GUAMI | M | 9.3.3.3 | - | |||
| >>Backup AMF Name | O | AMF Name 9.3.3.21 | - | |||
| >>GUAMI Type | O | ENUMERATED (native, mapped, …) | YES | ignore | ||
| Relative AMF Capacity | M | 9.3.1.32 | YES | ignore | ||
| PLMN Support List | 1 | YES | reject | |||
| >PLMN Support Item | 1.. | - | ||||
| >>PLMN Identity | M | 9.3.3.5 | - | |||
| >>Slice Support List | M | 9.3.1.17 | Supported S-NSSAIs per PLMN or per SNPN. | - | ||
| … | ||||||
| Criticality Diagnostics | O | 9.3.1.3 | YES | ignore | ||
| UE Retention Information | O | 9.3.1.117 | YES | ignore | ||
| … |
核心IE解读：
- AMF Name：AMF的名称，便于网络管理员识别。
- Served GUAMI List (服务的GUAMI列表)：这是AMF向gNB声明自己的“服务人群”的核心信息。GUAMI（Globally Unique AMF Identifier）是AMF的唯一标识。AMF告诉gNB，以后凡是携带着这些GUAMI的UE发来请求，都应该路由给我来处理。
- Backup AMF Name：AMF还可以为每个GUAMI指定一个备用AMF。当该AMF自身发生故障时，gNB可以根据这个信息，将UE的请求重定向到备用AMF，提高了网络的可靠性。
- Relative AMF Capacity (相对AMF容量)：AMF向gNB报告自己当前的负载水平，这是一个0到255的数值，数值越大表示越空闲。gNB在为新UE选择AMF时，会优先选择容量值较大的AMF，从而实现AMF间的负载均衡。
- PLMN Support List (PLMN支持列表)：AMF确认自己支持的PLMN和相应的切片列表，gNB可以此来验证双方的能力是否匹配。
- UE Retention Information：AMF在此确认是否同意gNB的提议，即在接口故障恢复后保留UE上下文。
场景演绎：
AMF-Alpha回复给gNB-CBD-01的NG SETUP RESPONSE消息，可以解读为：
“欢迎你，gNB-CBD-01！我是AMF-Alpha。我的服务范围由GUAMI列表[…]定义，以后这些用户都归我管。我目前的负载很轻，容量值是200（满值255）。我确认支持你上报的PLMN和切片。另外，我同意你在接口故障后保留UE上下文的方案。”
至此，一次成功的NG Setup流程完成。gNB-CBD-01和AMF-Alpha正式建立了工作关系，gNB-CBD-01可以开始接受用户接入，并将信令消息路由给AMF-Alpha了。
3. 不成功的NG Setup流程 (Unsuccessful Operation)
当然，并非所有“入职报道”都能一帆风顺。如果AMF由于种种原因无法接受gNB的建立请求，它会明确地拒绝。
8.7.1.3 Unsuccessful Operation If the AMF cannot accept the setup, it should respond with an NG SETUP FAILURE message and appropriate cause value.
这个流程非常简单，如“Figure 8.7.1.3-1: NG setup: unsuccessful operation”所示，AMF直接回复NG SETUP FAILURE消息。
表格 9.2.6.3-1: NG SETUP FAILURE 消息内容
| IE/Group Name | Presence | Range | IE type and reference | Semantics description | Criticality | Assigned Criticality |
|---|---|---|---|---|---|---|
| Message Type | M | 9.3.1.1 | YES | reject | ||
| Cause | M | 9.3.1.2 | YES | ignore | ||
| Time to Wait | O | 9.3.1.56 | YES | ignore | ||
| Criticality Diagnostics | O | 9.3.1.3 | YES | ignore |
关键IE解读：
-
Cause (原因)：明确告知gNB建立失败的原因。规范在“Abnormal Conditions”一节中给出了具体的例子：
8.7.1.4 Abnormal Conditions If the AMF does not identify any of the PLMNs/SNPNs indicated in the NG SETUP REQUEST message, it shall reject the NG Setup procedure with an appropriate cause value. If none of the RATs indicated by the NG-RAN node in the NG SETUP REQUEST message is supported by the AMF, then the AMF shall fail the NG Setup procedure with an appropriate cause value. 例如，原因可能是“Unknown PLMN”（AMF不认识gNB上报的某个运营商网络），或者是配置不匹配，比如gNB只支持NR而AMF的配置中没有为这个gNB开启NR RAT的支持。
-
Time to Wait (等待时间)：这是一个“退避”定时器。AMF通过这个IE，指示gNB在重新发起NG Setup请求前，至少要等待多长时间。这可以有效防止gNB在配置错误的情况下，不断地、高频地向AMF发起无效请求，从而避免信令风暴。
场景演绎：
假设gNB-CBD-01在配置时不小心写错了一个PLMN ID。当AMF-Alpha收到NG SETUP REQUEST后，发现这个PLMN ID不在自己的服务列表中。于是，AMF-Alpha回复NG SETUP FAILURE，其中Cause为“Unknown PLMN”，并设置Time to Wait为10秒。gNB-CBD-01收到后，便会记录失败日志，并等待10秒后才会再次尝试。
FAQ
Q1: NG Setup和底层的SCTP连接是什么关系？谁先建立？
A1: SCTP连接是传输网络层（TNL）的通道，而NG Setup是应用层（NGAP）的流程。必须先建立底层的SCTP连接，这条“物理道路”通了之后，才能在上面跑应用层的“车辆”——NGAP消息。因此，SCTP连接的建立是NG Setup流程的前提。
Q2: 如果一个gNB需要同时连接到两个AMF（例如，为了负载均衡或冗余），它需要执行几次NG Setup？
A2:
需要执行两次。NG Setup流程是针对一个gNB和一个AMF之间的单一NG-C接口实例的。如果一个gNB需要与两个不同的AMF（AMF-Alpha和AMF-Beta）建立连接，它需要分别与这两个AMF各自建立SCTP连接，并在这两条连接上分别独立地发起NG Setup流程。完成后，gNB会维护两套独立的接口上下文，并根据AMF-Alpha和AMF-Beta各自返回的Served GUAMI List和Relative AMF Capacity等信息，来决定将新接入的UE的信令路由到哪个AMF。
Q3: UE Retention Information这个IE的具体作用是什么？为什么是可选的？
A3: 它的核心作用是提升网络在短暂链路中断后的恢复效率和业务连续性。假设gNB和AMF之间的SCTP连接因为网络抖动中断了，但很快又恢复了。
- 如果不支持UE Retention：双方会清空所有与该接口相关的UE上下文。所有在该gNB下的RRC_CONNECTED和RRC_INACTIVE用户都会掉线，需要重新发起注册流程，造成较大范围的业务中断。
- 如果双方在NG Setup时都同意了UE Retention：在SCTP连接恢复后，它们会再次执行NG Setup流程并再次确认保留UE上下文。这样，之前已经建立的UE上下文（包括
AMF UE NGAP ID和RAN UE NGAP ID的对应关系）就可能被保留下来，UE无需重新注册就能恢复业务，大大缩短了中断时间。 它之所以是可选的，是因为实现这个功能需要网元具备额外的存储和状态管理能力，规范允许厂商根据产品定位来决定是否支持这一高级特性。
Q4: 为什么NG Setup流程总是由gNB发起，而不是由AMF发起？
A4: 这符合网络设备“即插即用”和“自动发现”的设计逻辑。在网络架构中，AMF是核心、集中的控制节点，而gNB是分布式的、数量庞大的接入节点。当一个新的gNB被部署到网络中时，它需要主动向核心网“报到”，告知自己的存在和能力。让AMF去轮询探测网络中是否有新的gNB上线，在可扩展性和效率上都是不现实的。因此，由gNB主动发起NG Setup是一种更合理、更具扩展性的架构设计。
Q5: AMF在NG SETUP RESPONSE中返回的Relative AMF Capacity是如何帮助gNB做决策的？
A5:
Relative AMF Capacity是实现AMF间负载均衡的关键。一个区域通常会部署多个AMF组成一个AMF Set，以实现冗余和容量扩展。一个gNB可能会同时与这个AMF Set中的多个AMF建立NG接口。
当一个新的UE接入时，如果该UE没有携带有效的GUAMI（例如开机注册），gNB就需要为它选择一个AMF。此时，gNB会查看所有已连接的AMF返回的Relative AMF Capacity值。这个值越高，代表该AMF越空闲。gNB会根据一定的负载均衡算法（例如，简单地选择容量值最高的那个），将UE的INITIAL UE MESSAGE发送给最空闲的AMF。这样可以避免所有新用户都涌向同一个AMF，导致其过载，而其他AMF却处于空闲状态。