In a 5G Core network, an AMF pool is often associated with higher availability and load sharing, but simply deploying multiple AMF instances is not enough. When a gNB connects to an AMF pool, it needs to know more than which AMFs are online. It also needs information about the GUAMIs served by each AMF, supported PLMNs and slices, relative capacity, and how traffic should be redirected when an AMF is taken out of service for maintenance.

The N2 interface provides the control-plane path for this information exchange. It runs over SCTP and uses NGAP signaling to exchange capabilities and synchronize status between the gNB and AMF. During initial network setup, the SCTP association is established first, followed by the NG Setup procedure. During operation, changes to AMF capacity, GUAMI information, or SCTP endpoints need to be reported to the gNB through configuration update procedures. Before planned maintenance, the AMF can also indicate which GUAMIs will become unavailable and provide information about a backup AMF.

The N2 interface in an AMF pool should therefore be viewed as a continuously maintained control relationship rather than a connection that is configured once and left unchanged. This perspective makes the setup, update, and reselection procedures much easier to understand as one complete management process.

Why an AMF Pool Requires More Than an Established Connection

From a basic connectivity perspective, once an SCTP association between a gNB and an AMF is established, the two nodes can exchange NGAP messages. For an AMF pool, however, connectivity alone is not sufficient.

A single service area may contain AMF1, AMF2, AMF3, and other AMF instances. The gNB not only needs to know whether these AMFs are reachable, but also which GUAMIs, PLMNs, and slices they support and how much relative load each AMF is currently suited to handle. Without this information, all SCTP associations could be in an UP state while the gNB still lacks the information required to make an appropriate AMF selection for new UEs.

N2 interface management can be divided into three main stages:

These three procedures address three different stages in the lifecycle of an AMF relationship: initial discovery, capability or configuration changes, and temporary withdrawal from service. Looking at them together makes it easier to understand how an AMF pool supports load distribution and planned maintenance across multiple core network nodes.

What Do SCTP and NG Setup Each Do During N2 Establishment?

In engineering discussions, this entire stage is often referred to simply as “N2 setup.” At the protocol level, however, it consists of two consecutive steps: establishing the SCTP association first, followed by the NGAP NG Setup procedure.

The gNB first needs to obtain the SCTP endpoint address of the AMF-side N2 interface. The address may be statically configured or obtained through an appropriate address resolution mechanism. The gNB then establishes an SCTP association with the AMF.

A typical SCTP association setup consists of four exchanges: INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK. Once these exchanges are complete, the transport layer is ready to carry NGAP signaling. The gNB, however, still does not have all of the AMF service information it needs, so the NG Setup procedure follows.

The gNB sends an NG Setup Request, which may contain information such as the Global gNB ID, Supported TA List, RAN Node Name, and Default Paging DRX. In practical terms, this message tells the AMF which RAN node is connecting, which tracking areas it supports, and its basic operating parameters.

After receiving the request, the AMF returns an NG Setup Response. The response provides key AMF-side information, including the AMF Name, Served GUAMI List, supported PLMN information, and RelativeAMFCapacity.

RelativeAMFCapacity is particularly important in an AMF pool. It should not be interpreted simply as the maximum number of subscribers an AMF can support. Instead, it provides a relative capacity reference that the gNB can use when comparing multiple AMFs and making AMF selection and load-sharing decisions for subsequent UEs.

If the pool contains AMF1, AMF2, and AMF3, the gNB can establish N2 associations with the relevant AMFs using the same process and obtain the service and relative capacity information returned by each node. This is what allows multiple AMFs to operate as a coordinated pool rather than as isolated control-plane nodes.

A packet capture also shows this sequence clearly: the SCTP handshake appears first, followed by NG Setup Request and NG Setup Response messages. Once the basic N2 association is ready, UE-related registration and mobility signaling can use the established control-plane path.

Why Must the gNB Be Updated When AMF Capabilities Change?

The operating state of an AMF pool is not static. In a cloud-based 5G Core, an AMF may be scaled when subscriber demand increases, or its GUAMI information, service area, endpoint addresses, or processing capacity may be changed.

If the gNB continues using the parameters obtained during initial startup, the AMF selection logic on the RAN side may no longer reflect the actual capabilities of the core network. This is where the AMF Configuration Update procedure becomes important.

This procedure is not related to a specific UE. Instead, it allows the AMF to notify the NG-RAN about changes to its own configuration. For example, after an AMF is scaled up, its relative processing capacity may increase, and a new RelativeAMFCapacity value can be reported to the gNB. Changes to GUAMI information can also be synchronized through the same procedure, as can additions or removals of SCTP endpoint addresses.

Consider a case where an orchestration or management system detects a significant increase in the number of users handled by AMF1 and automatically expands its processing resources. After the expansion, AMF1 can handle a larger relative share of the control-plane load, so its capacity value is adjusted accordingly.

AMF1 then sends an AMF CONFIGURATION UPDATE to the gNB. The message can contain updated GUAMI information, a new RelativeAMFCapacity value, and SCTP endpoint changes. After applying the update, the gNB responds with an AMF CONFIGURATION UPDATE ACKNOWLEDGE.

From that point onward, when new UEs arrive or the gNB needs to perform a new AMF selection, it can use the updated information rather than the values learned during initial network startup.

This illustrates an important principle of AMF pool operation: load sharing is not calculated only once when the network starts. It can be adjusted as core network resources change.

This is particularly relevant in a cloud-native 5G Core. Compute resources can be scaled dynamically, but an increase in computing capacity does not automatically change RAN-side AMF selection behavior. The updated control-plane parameters must also be communicated to the gNB. AMF Configuration Update provides the signaling mechanism that connects changes in core network resources with changes in RAN-side selection behavior.

How Does the gNB Prepare for AMF Reselection Before Maintenance?

Scaling adds capacity. Maintenance creates the opposite situation: an AMF may need to become temporarily unavailable because of a software upgrade, planned maintenance, or another operational task.

If an AMF simply goes offline without notifying the NG-RAN, the gNB may continue selecting it based on previously stored information until failures occur. In an AMF pool, a better approach is to tell the gNB in advance that certain AMF identities will no longer be available.

The AMF Status Indication procedure in NGAP is used for this type of AMF management scenario.

Suppose AMF1 needs to undergo a software upgrade. Before maintenance begins, AMF1 can send an AMF STATUS INDICATION to the gNB and identify the GUAMIs that will become unavailable. If the message also includes a Backup AMF Name, such as AMF2, the gNB can take that AMF into account during subsequent reselection, provided the relevant capability is supported.

Once the gNB receives the status indication, it treats the indicated GUAMIs as unavailable and adjusts subsequent AMF selection and reselection accordingly.

This does not mean that all existing UE contexts are mechanically moved from AMF1 to AMF2 at exactly the same moment. Instead, the purpose is to prevent the NG-RAN from continuing to select an AMF that is being taken out of service when a later AMF selection or reselection is required.

For example, when a UE later initiates a mobility registration update, the gNB can route the relevant signaling toward another AMF. The new AMF can then continue providing mobility management functions and, where required by the procedure, assign a new 5G-GUTI to the UE.

From an operations perspective, AMF Status Indication is essentially a mechanism for planned withdrawal from service. It translates an operational event such as “AMF1 is going into maintenance” into protocol-level status information that the NG-RAN can understand and use before the AMF actually becomes unavailable.

What Is the AMF Pool Really Managing Through These Three Procedures?

When NG Setup, AMF Configuration Update, and AMF Status Indication are studied separately, they can easily look like three unrelated NGAP procedures. Viewed across the lifecycle of an AMF pool, their relationship becomes much clearer.

NG Setup establishes the initial relationship. When the gNB first connects to an AMF, it needs to know which AMF it is communicating with, which services it provides, and its relative processing capability within the pool.

AMF Configuration Update handles capability and configuration changes. The AMF remains available, but its GUAMI information, relative capacity, or transport endpoints have changed, so the NG-RAN needs to refresh its stored information.

AMF Status Indication handles availability changes. When an AMF is preparing for maintenance or temporary withdrawal, the gNB needs to treat the relevant GUAMIs as unavailable and prepare for subsequent AMF reselection.

Together, these procedures maintain one important operational view for the gNB: which AMFs are available, what services they provide, how much relative load they are suitable to handle, and which AMFs are in the process of leaving service.

An AMF pool therefore does not achieve high availability simply by deploying several AMF instances. The gNB must continuously maintain an up-to-date view of AMF capabilities and status and use that information when making selection decisions. Only then can a multi-AMF deployment effectively support load sharing, elastic scaling, and planned maintenance.

The same logic is useful during troubleshooting. Start by confirming whether the SCTP association is healthy, then verify that NG Setup has completed successfully. If the connection remains active but load distribution is abnormal, check AMF Configuration Update signaling and RelativeAMFCapacity. If traffic continues to be directed toward an AMF that is being taken out of service, review the AMF Status Indication, GUAMI availability information, and AMF reselection behavior.

FAQ

How can SCTP failures and NGAP failures be distinguished quickly in a packet capture?

Start by checking whether the SCTP association was established successfully. If the INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK exchange does not complete, the issue is still at the transport layer. If SCTP is established but no NG Setup Response is received, or an NGAP-level error is returned, troubleshooting should continue with NGAP parameters, TA configuration, PLMN information, and AMF-side settings.

Does RelativeAMFCapacity represent the maximum number of UEs an AMF can support?

No. RelativeAMFCapacity is better understood as a relative capacity indicator used within an AMF pool. It helps the NG-RAN compare the relative processing capability of different AMFs for selection purposes. It should not be directly interpreted as an absolute subscriber limit.

Why is changing the local AMF configuration not enough when GUAMI information changes?

The gNB has already stored AMF service information obtained through the N2 interface. If the AMF changes its GUAMI configuration without notifying the NG-RAN, the two sides may have inconsistent views of AMF identity and service availability. The updated information therefore needs to be synchronized through the relevant NGAP management procedure.

Does AMF Status Indication always need to include a Backup AMF Name?

No. Backup AMF Name is optional. Even when it is not included, the NG-RAN still needs to process the GUAMIs identified as unavailable and perform the appropriate AMF management and reselection behavior. If Backup AMF Name is included and the NG-RAN supports the corresponding procedure, the specified backup AMF can be taken into account during reselection.