In the 5G Core control plane, the AMF is responsible for key functions such as UE access management, mobility management and NAS signaling. The reliability of the AMF architecture therefore has a direct impact on overall service continuity. In a traditional deployment, a gNB may be statically associated with a particular AMF. This approach is relatively simple when the network is small, but its limitations become increasingly apparent as subscriber volumes grow, traffic patterns become more dynamic and cloud-based deployment becomes more common. An AMF serving a busy business district may remain heavily loaded during peak hours while neighboring resources are underutilized. If a single AMF encounters a software or hardware failure, users within its service area may be affected. Routine operations such as software upgrades and configuration changes may also require carefully planned maintenance windows.

AMF Pool, represented in 3GPP architecture by the concept of an AMF Set, addresses these issues through a shared multi-AMF deployment model. Multiple AMFs form one logical service group, while gNBs can establish N2 connectivity with the AMFs in the pool. Combined with the hierarchical GUAMI identity structure, weighted AMF selection and UE context continuity, the architecture supports load distribution, failure resilience, reduced signaling during mobility and more flexible maintenance. The idea of pooling control-plane nodes is not unique to 5G. Similar concepts appeared in the SGSN Pool of GPRS and the MME Pool of 4G, all following the same principle: replace rigid node binding with shared network resources. In 5G, AMF pooling further complements cloud-native deployment and elastic resource management.

Why AMF Pooling Matters

One of the primary reasons for deploying an AMF Pool is to address the mismatch between changing subscriber distribution and fixed node capacity. Mobile traffic is inherently dynamic. During working hours, large numbers of subscribers may gather in commercial districts, while traffic shifts toward residential areas in the evening. Concerts, sporting events and holiday travel can also create sudden temporary traffic peaks. If a geographical area depends on only a small number of statically assigned AMFs, some nodes may become heavily loaded while others remain underutilized.

When multiple AMFs operate within the same pool, gNBs can maintain connectivity with all relevant AMF instances, and newly arriving UEs can be distributed according to configured AMF weights. For example, if three AMFs with equal processing capacity serve the same area, equivalent weight settings can distribute new UE registrations and mobility contexts relatively evenly among them, improving overall resource utilization.

The second major benefit is resilience. If one AMF experiences a software fault or hardware failure, other AMFs in the pool remain available to handle subsequent access and mobility requests. For the 5G Core control plane, this multi-node model avoids excessive dependence on a single AMF and provides a stronger foundation for high-availability operation.

Pooling also improves operational flexibility. Before upgrading software, changing configuration or expanding an AMF instance, operators can first reduce or migrate the active workload associated with that node and allow other AMFs in the pool to take over new or redistributed traffic. Once the AMF no longer carries active users, maintenance can be performed with less impact on live services and with greater freedom in selecting a maintenance window.

Mobility Optimization Across the Pool

The value of an AMF Pool extends beyond multi-node redundancy. An important advantage is the ability to reduce signaling as a UE moves across the network. A pool can cover multiple Tracking Areas, while gNBs within that service domain maintain N2 connectivity with the AMFs belonging to the same AMF Set.

Suppose a UE initially registers in TA1 and AMF1 creates the UE context. If the UE later moves to TA2 within the same pool, the new gNB can continue selecting AMF1 to handle that UE's NAS signaling. As long as the UE remains inside the service area of the same AMF Pool, the network can try to preserve the original AMF association.

This design reduces unnecessary mobility signaling. Without such pooling, movement between service areas could require a change of serving AMF, resulting in additional context transfer and registration-related procedures. Pooling decouples radio-side location changes from mandatory control-plane node changes, allowing a UE to move between gNBs and Tracking Areas without automatically changing its serving AMF.

From an engineering perspective, the pool effectively enlarges the geographical area over which an AMF context can remain stable. A UE may move across multiple gNBs and TAs while retaining the same AMF anchor, provided it stays inside the applicable AMF Set service area. This reduces control-plane interactions and improves continuity of mobility management.

In the 3GPP architecture, this logic is represented through a hierarchical structure. An AMF Set contains multiple AMFs that serve a defined area and support the same Network Slice or slices. Multiple AMF Sets can exist within a single AMF Region, allowing larger networks to divide the control plane into manageable service domains.

How GUAMI Identifies an AMF

Once the control plane moves from a single node to a pooled architecture, the network needs a structured way to identify regions, sets and individual AMF instances. GUAMI, the Globally Unique AMF Identifier, provides that hierarchy.

A GUAMI consists of the MCC, MNC, AMF Region ID, AMF Set ID and AMF Pointer. Together, these fields form a hierarchical addressing model across the PLMN, AMF Region, AMF Set and individual AMF instance. The AMF Region ID identifies the broader AMF Region, the AMF Set ID identifies a particular AMF Set within that region, and the AMF Pointer distinguishes an individual AMF within the set.

The same hierarchy also appears in temporary UE identities. A 5G-GUTI consists of the GUAMI and the 5G-TMSI. As a result, information associated with the UE's temporary identity can indicate the AMF that previously served the UE. The 5G-S-TMSI contains the AMF Set ID, AMF Pointer and 5G-TMSI, providing information used in procedures such as paging.

This is why GUAMI directly influences AMF selection. If a UE provides information during RRC establishment that identifies the previously serving AMF, the gNB does not necessarily need to perform a completely new load-based selection. It can instead attempt to select the original AMF and preserve the existing service relationship.

In addition to binary identifiers, AMF discovery can also use FQDN and DNS mechanisms. A gNB can construct an AMF Set-FQDN and query DNS to obtain information about the AMFs belonging to a particular set, providing input for subsequent N2 association establishment. An AMF Instance-FQDN identifies an individual AMF instance and can help locate a previously serving AMF in applicable mobility or interworking scenarios.

How the gNB Selects an AMF

Once an AMF Pool is operational, the gNB has to deal with two fundamentally different UE situations. One is a newly arriving UE with no usable information about a previously serving AMF. The other is a UE that carries information identifying its previous AMF. These cases require different selection priorities.

If the UE does not provide GUAMI or other information that can identify its previous AMF during RRC establishment, the gNB selects an AMF from the AMF Set using the configured weight values. Each AMF can be assigned a weight in the range from 0 to 255, typically according to its processing capability. A higher-capacity AMF can be assigned a higher weight and receive more new users, while a lower-capacity instance can be assigned a lower weight.

For example, if three AMFs are configured with weights of 100, 50 and 50, the first AMF can receive approximately half of the newly allocated users when other conditions are comparable. These weights do not have to remain static. If an AMF is expanded, reduced or otherwise changes capacity, updated weight information can be delivered to connected gNBs through an N2 configuration update procedure, allowing subsequent UE allocations to reflect the new capacity distribution.

If the UE provides a valid GUAMI, however, the selection objective changes. Rather than immediately rebalancing the UE toward another AMF, the gNB attempts to identify and select the previously serving AMF. Preserving the original AMF helps retain context continuity and avoids unnecessary control-plane changes.

AMF selection within a pool can therefore be summarized by two principles: when no historical AMF association is available, prioritize load distribution; when a previous AMF association is known, prioritize service continuity. The first improves resource utilization, while the second reduces mobility signaling. An efficient AMF Pool is therefore not designed to move every UE to whichever AMF is currently the least loaded. It balances resource distribution with context stability.

From Initial Deployment to Elastic Scaling

Bringing an AMF Set into service involves several stages. First, multiple AMF instances are created through a MANO orchestration system or network management platform, and the SCTP association addresses required for N2 connectivity are configured.

The gNB then establishes SCTP associations with the AMFs in the pool and performs the N2 Setup procedure with each relevant AMF. N2 Setup does more than establish connectivity. It also allows the gNB to obtain parameters associated with AMF operation and selection, including information such as relative capacity or weight, supported slices and service-area information. Once these relationships are established, the AMF Set is ready to serve UEs.

When a new UE arrives, the gNB determines whether to preserve a previous AMF association or select an AMF according to the available pool information and configured weights. If all AMFs have similar processing capabilities and identical weights, their subscriber loads should tend toward a relatively balanced distribution over time.

Architecturally, an AMF Pool should not be viewed as a conventional active-standby solution. In an active-standby design, a backup node may remain largely idle until a failure occurs. In an AMF Pool, multiple AMFs can actively serve users at the same time. Resilience is one outcome of pooling, but the broader objective is to make several AMF instances operate as one logical service group.

This characteristic also makes AMF Pooling an important foundation for cloud-based 5GC deployments. In a cloud-native environment, AMF instances can be scaled through orchestration. Instance count, processing capacity and selection weights may change over time, while the logical AMF Set presented to gNBs and UEs remains stable. Pooling therefore provides a consistent service boundary on top of dynamically changing core-network resources and supports the elastic behavior expected from a cloud-oriented 5G Core.

FAQ

Can an AMF Region contain more than one AMF Set?

Yes. A single AMF Region can contain multiple AMF Sets. Different sets can serve different areas, while the AMFs within a given set support the same Network Slice or slices required by that set.

Does one Tracking Area correspond to only one gNB?

No. There is no one-to-one relationship between a Tracking Area and a gNB. A TA can contain multiple cells, while a gNB can contain multiple cells that may belong to one or more Tracking Areas.

What is the difference between an AMF Pointer and an AMF Set ID?

The AMF Set ID identifies an AMF Set, while the AMF Pointer distinguishes a particular AMF instance within that set. Together with the AMF Region ID, they form important parts of the hierarchical addressing information contained in the GUAMI.

Does changing an AMF weight require all N2 connections to be re-established?

No. When AMF capacity changes, updated weight or relative-capacity information can be communicated to already connected gNBs through the relevant N2 configuration update procedure. The revised value can then influence the allocation of subsequent new UEs without requiring existing N2 connectivity to be rebuilt.