在 5G 核心网中，AMF 池通常用于提高可用性并实现负载分担，但仅仅部署多个 AMF 实例并不足够。当 gNB 连接到 AMF 池时，它不仅需要知道哪些 AMF 在线，还需要了解每个 AMF 服务的 GUAMI、支持的 PLMN 与网络切片、相对容量，以及某个 AMF 因维护退出服务时流量应如何重新定向。
N2 接口为这些信息交换提供控制面通道。它承载于 SCTP 之上，并使用 NGAP 信令在 gNB 与 AMF 之间交换能力信息和同步状态。网络初始建立时，首先建立 SCTP 关联，随后执行 NG Setup 过程。运行期间，如果 AMF 的容量、GUAMI 信息或 SCTP 端点发生变化，需要通过配置更新过程通知 gNB。在计划维护之前，AMF 还可以指示哪些 GUAMI 即将不可用，并提供备用 AMF 的相关信息。
因此，AMF 池中的 N2 接口应被理解为一种持续维护的控制关系，而不是一次配置后长期不变的连接。按照这一视角，就更容易把建立、更新和重选过程理解为一个完整的管理流程。
为什么 AMF 池仅有连接建立还不够
从基本连通性的角度看，一旦 gNB 与 AMF 之间建立 SCTP 关联，两个节点就可以交换 NGAP 消息。但对于 AMF 池而言，仅仅连通并不足够。
一个服务区域内可能包含 AMF1、AMF2、AMF3 等多个 AMF 实例。gNB 不仅要知道这些 AMF 是否可达，还要知道它们支持哪些 GUAMI、PLMN 和切片，以及当前各 AMF 适合承担多大的相对负载。否则，即使所有 SCTP 关联都处于 UP 状态，gNB 仍可能缺少为新 UE 选择合适 AMF 所需的信息。
N2 接口管理可以分为三个主要阶段：
| 过程 | 典型触发条件 | 主要目的 |
|---|---|---|
| N2 建立 | 站点首次启用、网络启动，或首次与某个 AMF 建立关联 | 建立 SCTP 关联，并通过 NG Setup 交换 gNB 与 AMF 参数 |
| AMF Configuration Update | 相对容量、GUAMI 信息或 SCTP 端点发生变化 | 使 gNB 与最新 AMF 配置保持同步，并支持后续 UE 分配 |
| AMF Status Indication | 软件升级、计划维护，或其他导致 AMF 部分能力暂时不可用的情况 | 通知 gNB 特定 GUAMI 已不可用，并在需要时支持 AMF 重选 |
这三个过程分别对应 AMF 关系生命周期中的三个阶段：初始发现、能力或配置变化，以及暂时退出服务。把它们放在一起理解，可以更清楚地看出 AMF 池如何在多个核心网节点之间实现负载分担和计划维护。
SCTP 与 NG Setup 在 N2 建立过程中分别做什么？
在工程讨论中，这一整个阶段通常被统称为“N2 建立”。但从协议层面看，它实际上由两个连续步骤组成：先建立 SCTP 关联，再执行 NGAP 的 NG Setup 过程。
gNB 首先需要获得 AMF 侧 N2 接口的 SCTP 端点地址。该地址可以静态配置，也可以通过适当的地址解析机制获取。随后，gNB 与 AMF 建立 SCTP 关联。
典型的 SCTP 关联建立包含四次交互：INIT、INIT ACK、COOKIE ECHO 和 COOKIE ACK。完成这些交互后，传输层即可承载 NGAP 信令。不过此时 gNB 仍未获得所需的全部 AMF 服务信息，因此还要继续执行 NG Setup。
gNB 发送 NG Setup Request，其中可能包含 Global gNB ID、Supported TA List、RAN Node Name 和 Default Paging DRX 等信息。从实际作用看，这条消息用于告知 AMF：哪个 RAN 节点正在接入、该节点支持哪些跟踪区，以及其基本运行参数。
AMF 收到请求后返回 NG Setup Response。响应中包含关键的 AMF 侧信息，包括 AMF Name、Served GUAMI List、支持的 PLMN 信息以及 RelativeAMFCapacity。
RelativeAMFCapacity 在 AMF 池中尤其重要。它不能简单理解为某个 AMF 能支持的最大用户数，而是一个相对容量参考值，gNB 可以据此比较多个 AMF，并为后续 UE 的 AMF 选择和负载分担作出决策。
如果池中包含 AMF1、AMF2 和 AMF3，gNB 可以通过相同流程与相关 AMF 建立 N2 关联，并获取各节点返回的服务信息和相对容量信息。正是这些信息，使多个 AMF 能够作为协调工作的资源池运行，而不是彼此孤立的控制面节点。
抓包也能清楚看到这一顺序：先出现 SCTP 握手，随后是 NG Setup Request 和 NG Setup Response 消息。基础 N2 关联准备就绪后，与 UE 相关的注册和移动性信令即可使用这条已建立的控制面路径。
为什么 AMF 能力变化时必须更新 gNB？
AMF 池的运行状态并非静态不变。在云化 5G 核心网中，随着用户需求增加，AMF 可能进行扩容；其 GUAMI 信息、服务区域、端点地址或处理能力也可能发生变化。
如果 gNB 始终使用网络初始启动时获得的参数，RAN 侧的 AMF 选择逻辑可能无法反映核心网的实际能力。这正是 AMF Configuration Update 过程发挥作用的场景。
该过程并不针对某个特定 UE，而是用于让 AMF 向 NG-RAN 通知自身配置的变化。例如，AMF 扩容后，其相对处理能力可能提高，此时可以向 gNB 上报新的 RelativeAMFCapacity。GUAMI 信息变化也可以通过同一过程同步，SCTP 端点地址的新增或删除同样如此。
例如，编排或管理系统检测到 AMF1 承载的用户数量显著增加，并自动扩展其处理资源。扩容后，AMF1 能够承担更高比例的控制面负载，因此相应调整其容量值。
随后，AMF1 向 gNB 发送 AMF CONFIGURATION UPDATE。消息中可以包含更新后的 GUAMI 信息、新的 RelativeAMFCapacity 值以及 SCTP 端点变化。gNB 应用更新后，返回 AMF CONFIGURATION UPDATE ACKNOWLEDGE。
此后，当有新的 UE 接入，或 gNB 需要重新执行 AMF 选择时，就可以使用更新后的信息，而不是继续依赖网络初始启动时学习到的旧值。
这体现了 AMF 池运行中的一个重要原则：负载分担并不是在网络启动时只计算一次，而是可以随着核心网资源变化持续调整。
这一点在云原生 5G 核心网中尤其重要。计算资源可以动态扩缩容，但计算能力增加并不会自动改变 RAN 侧的 AMF 选择行为。更新后的控制面参数还必须传递给 gNB。AMF Configuration Update 正是把核心网资源变化与 RAN 侧选择行为变化连接起来的信令机制。
维护前，gNB 如何为 AMF 重选做好准备？
扩容意味着增加能力，而维护则相反：由于软件升级、计划维护或其他运维任务，某个 AMF 可能需要暂时不可用。
如果 AMF 未通知 NG-RAN 就直接下线，gNB 可能仍根据之前保存的信息继续选择该 AMF，直到出现失败。在 AMF 池中，更合理的做法是在 AMF 真正退出服务前，提前告知 gNB 哪些 AMF 标识即将不可用。
NGAP 中的 AMF Status Indication 过程用于处理这类 AMF 管理场景。
假设 AMF1 需要进行软件升级。在维护开始前，AMF1 可以向 gNB 发送 AMF STATUS INDICATION，并标识即将不可用的 GUAMI。如果消息中还包含 Backup AMF Name，例如 AMF2，并且相关能力得到支持，gNB 就可以在后续重选时将该 AMF 纳入考虑。
gNB 收到状态指示后，会将所指示的 GUAMI 视为不可用，并据此调整后续的 AMF 选择和重选。
这并不意味着所有现有 UE 上下文都会在同一时刻被机械地从 AMF1 迁移到 AMF2。其目的在于：当后续需要执行 AMF 选择或重选时，避免 NG-RAN 继续选择一个正在退出服务的 AMF。
例如，当某个 UE 之后发起移动性注册更新时，gNB 可以将相关信令路由到另一个 AMF。新的 AMF 随后可以继续提供移动性管理功能，并在过程要求时为 UE 分配新的 5G-GUTI。
从运维角度看，AMF Status Indication 本质上是一种计划退出服务机制。它把“AMF1 即将进入维护”这样的运维事件转换为 NG-RAN 能够理解并在 AMF 真正不可用前使用的协议级状态信息。
AMF 池通过这三个过程究竟在管理什么？
如果分别学习 NG Setup、AMF Configuration Update 和 AMF Status Indication，它们很容易看起来像三个彼此无关的 NGAP 过程。但从 AMF 池整个生命周期来看，三者之间的关系就会清晰得多。
NG Setup 用于建立初始关系。 当 gNB 首次连接某个 AMF 时，需要知道正在与哪个 AMF 通信、该 AMF 提供哪些服务，以及它在池中的相对处理能力。
AMF Configuration Update 用于处理能力和配置变化。 此时 AMF 仍然可用，但其 GUAMI 信息、相对容量或传输端点发生变化，因此 NG-RAN 需要刷新已保存的信息。
AMF Status Indication 用于处理可用性变化。 当某个 AMF 准备维护或暂时退出服务时，gNB 需要把相关 GUAMI 视为不可用，并为后续 AMF 重选做好准备。
这三个过程共同维护 gNB 所需的一项关键运行视图：哪些 AMF 可用、它们提供哪些服务、适合承担多大的相对负载，以及哪些 AMF 正在退出服务。
因此，仅部署多个 AMF 实例并不能让 AMF 池自动获得高可用能力。gNB 必须持续维护最新的 AMF 能力与状态视图，并在执行选择决策时使用这些信息。只有这样，多 AMF 部署才能真正支持负载分担、弹性扩缩容和计划维护。
同样的逻辑也适用于故障排查。首先确认 SCTP 关联是否正常，再检查 NG Setup 是否成功完成。如果连接仍处于活动状态但负载分配异常，应检查 AMF Configuration Update 信令和 RelativeAMFCapacity；如果流量仍被导向正在退出服务的 AMF，则需要检查 AMF Status Indication、GUAMI 可用性信息以及 AMF 重选行为。
常见问题
抓包时如何快速区分 SCTP 故障与 NGAP 故障？
首先检查 SCTP 关联是否成功建立。如果 INIT、INIT ACK、COOKIE ECHO 和 COOKIE ACK 交互未完成，问题仍位于传输层。如果 SCTP 已建立，但没有收到 NG Setup Response，或者返回了 NGAP 层错误，则应继续检查 NGAP 参数、TA 配置、PLMN 信息和 AMF 侧设置。
RelativeAMFCapacity 是否表示 AMF 能支持的最大 UE 数量？
不是。RelativeAMFCapacity 更适合理解为 AMF 池内使用的相对容量指标。它帮助 NG-RAN 在选择时比较不同 AMF 的相对处理能力，不能直接把它解释为绝对的用户数量上限。
GUAMI 信息变化后，只修改 AMF 本地配置为什么不够？
gNB 已经保存了通过 N2 接口获得的 AMF 服务信息。如果 AMF 修改 GUAMI 配置却没有通知 NG-RAN，双方对 AMF 标识和服务可用性的认知可能出现不一致。因此，需要通过相应的 NGAP 管理过程同步更新后的信息。
AMF Status Indication 是否必须始终包含 Backup AMF Name？
不是。Backup AMF Name 是可选信息。即使消息中不包含它，NG-RAN 仍需处理被标识为不可用的 GUAMI，并执行相应的 AMF 管理和重选行为。如果包含 Backup AMF Name，且 NG-RAN 支持对应过程，则可以在重选时考虑指定的备用 AMF。
