AMF — Access & Mobility Management Function in 5G NR
The control-plane anchor for the UE — registration, connection and mobility management, NAS termination, paging and the security anchor (SEAF).
Every 5G device has exactly one function in the core that "owns" it — one box that knows whether the device is switched on, where it is, whether it can be reached, and whether it is allowed in at all. That box is the AMF. It is the UE's control-plane anchor: the far end of every NAS message the device sends, the security gatekeeper that decides who gets on the network, and the mobility brain that keeps the device reachable as it roams. This page is the AMF in full detail — its states, its interfaces, its security role, and exactly which of the old LTE MME's jobs it kept and which it gave away.
Introduction
The AMF (Access and Mobility Management Function) is the control-plane heart of the 5G core for anything to do with the device itself — as opposed to its data sessions. It is a Network Function in the 5G service-based architecture, and it is the one function a UE is permanently attached to from the moment it registers until the moment it deregisters. It never carries user data; it manages who the device is, where it is, whether it is reachable, and whether it is allowed on the network.
In the UE/network lifecycle the AMF is the very first core function a device talks to: registration (the 5G equivalent of "attach") is a conversation with the AMF, and every later mobility, paging, service-request and security event flows through it too. While a single UE may have many PDU sessions spread across several SMFs and UPFs, it always has exactly one serving AMF at a time.
It matters because the AMF is where three critical jobs converge: it terminates the NAS-MM signalling from the UE and the NGAP signalling from the RAN, it is the security termination and anchor point for the whole access, and it is the mobility engine that keeps the network's picture of "where is this device and can I reach it" continuously correct. Understand the AMF and you understand the spine of the 5G control plane.
On this page
Why the AMF is needed
In plain words: the AMF is the network's receptionist-plus-security-desk for your phone. It checks your ID at the door (authentication and access control), it keeps the building's directory of where you are and how to page you (registration and reachability), and when a delivery arrives for you it knows which floor to send it to (it steers session requests to the right SMF). It never handles the parcels themselves — that is the loading dock, the UPF — but nothing reaches you without going through the front desk first.
The concrete problem the AMF solves is that a mobile device needs a single, stable point of contact in the core no matter how much it moves or how many data sessions it opens. Something has to remember the device's identity and security keys, track whether it is currently reachable, wake it up when data arrives, and admit or reject it based on subscription and policy. If that responsibility were scattered across many functions, every one of them would have to track the device's radio state and location — a coordination nightmare.
By concentrating registration, connection state, reachability, paging, mobility and NAS security in one per-UE function, 5G lets the rest of the core (the SMF, UPF, PCF) ignore the device's radio state entirely — they simply ask the AMF. And by deliberately not giving the AMF any session-management duties, 5G lets device-mobility and data-session logic scale on separate axes, which is the recurring design theme of the whole 5G core.
The AMF as the UE's control-plane anchor
When a 5G device powers on and attaches to the network, the very first end-to-end conversation it has with the core is with the AMF. From that moment until the device deregisters, the AMF is the single control-plane function responsible for it. It does not touch a single byte of user data — that is the UPF's job — but it holds the complete control-plane picture of the device: its identity, its security context, its registration state, its connection state, its location, and the set of network slices it is allowed to use.
The AMF (Access and Mobility Management Function) terminates the NAS-MM (Non-Access-Stratum Mobility Management) protocol from the UE and the NGAP protocol from the gNB. It handles registration, connection management, reachability, paging, mobility, access control and NAS security.
Someone has to be the device's stable point of contact regardless of how many data sessions it opens or how it moves. Concentrating registration, security and mobility in one function means the rest of the core (the SMF, UPF, PCF) never has to track the device's radio state — they just ask the AMF.
One AMF serves a UE at a time, even when the UE has several PDU sessions anchored on different SMFs and UPFs. The AMF relays session-related messages to the right SMF but never manages the sessions itself.
Two things follow from being "the anchor." First, the AMF is where the two halves of the device's signalling meet: the NAS-MM dialogue with the UE (carried logically over N1) and the NGAP dialogue with the radio node (carried over N2). The AMF is the only function that speaks both. Second, because it is the security termination point for NAS, the AMF is where the network decides whether this device is authenticated, integrity-protected and permitted — the subject of a whole section below. Get this framing right and everything else about the AMF is detail hanging off it: it is the device's identity, security and mobility custodian in the core.
One device, one AMF: The AMF is per-UE, not per-session. It terminates N1 (NAS-MM from the UE) and N2 (NGAP from the RAN), owns the device's security context, and steers session signalling to the SMF without ever managing the session itself.
Registration and Connection Management states
The AMF tracks a device along two independent axes, and keeping them separate is the single most important thing to understand about mobility in 5G. One axis is Registration Management (RM) — is the device known to the network at all? The other is Connection Management (CM) — does the device have a live signalling connection right now? A device can be registered but have no active connection; those are two different questions with two different state machines, both maintained by the AMF and mirrored in the UE.
Registration Management has two states. In RM-DEREGISTERED the network holds no valid location or routing information for the UE and cannot reach it; the UE is effectively unknown. In RM-REGISTERED the UE has completed a Registration procedure, the AMF holds a registration context (including the selected slices and a registration area of tracking areas), and the network can page it. The UE moves from deregistered to registered by sending a Registration Request over N1; it returns to deregistered on explicit or implicit deregistration.
Connection Management also has two states, and this is the axis that changes constantly as a device is used. In CM-IDLE there is no NAS signalling connection and no N2 context for the UE in the AMF — the radio has released the device to save power and spectrum, and the network can only reach it by paging. In CM-CONNECTED there is an active N1/N2 signalling connection: the UE has an RRC connection to the gNB and the gNB has an NGAP UE-association to the AMF. A registered device flips between CM-IDLE and CM-CONNECTED many times a day; it stays RM-REGISTERED throughout.
| Axis | State | What it means | How the AMF reaches the UE |
|---|---|---|---|
| RM | RM-DEREGISTERED | No valid registration/location context; UE unknown to the network. | Cannot — UE must register first. |
| RM | RM-REGISTERED | Registration complete; AMF holds context, slices and a registration area. | Via paging (if idle) or direct signalling (if connected). |
| CM | CM-IDLE | No N1/N2 signalling connection; no N2 context in the AMF. | Paging across the registration area. |
| CM | CM-CONNECTED | Active N1/N2 connection; RRC up and NGAP UE-association present. | Direct NAS signalling over the live connection. |
Do not conflate the two axes. A phone in your pocket is almost always RM-REGISTERED but CM-IDLE — known to the network, but with no live connection until it has something to send or is paged. Registration is "does the network know you"; connection is "are we talking right now."
Reachability, paging and mobility management
Because a registered device spends most of its life in CM-IDLE, the AMF needs a way to wake it up when downlink data or signalling arrives. That mechanism is paging, and it is one of the AMF's defining responsibilities. When the UE registers, the AMF assigns it a registration area — a set of tracking areas (identified by TAIs) large enough that the UE rarely crosses its edge, but small enough that paging does not flood the whole network. As long as the UE stays inside that area while idle, it need not tell the network where it is.
The AMF knows, for every registered UE, whether it is currently reachable and how. It maintains paging and reachability parameters, and for power-saving devices it tracks negotiated timers so it knows when a UE will next listen.
To reach an idle UE, the AMF sends an NGAP Paging message to every gNB in the UE's registration area; those cells broadcast the page, and the UE responds by establishing a connection (a Service Request), returning to CM-CONNECTED.
When the UE does move, the AMF processes the resulting Mobility Registration Update or handover signalling, updates the registration area and location, and — during inter-AMF handover — transfers the UE context to the new serving AMF over N14.
Mobility management is the flip side of reachability. While the UE is in CM-CONNECTED, mobility is handled by handovers coordinated between the RAN and, when the serving AMF must change, the core: the AMF is involved in N2-based handovers and in the AMF-to-AMF context transfer that keeps the device's security and registration context intact across the move. While the UE is in CM-IDLE, mobility is UE-driven: the device performs cell reselection on its own and only signals the network — with a Mobility Registration Update — when it leaves its registration area or a periodic timer fires. Either way, the AMF is the function that keeps the network's picture of "where is this device and can I reach it" continuously correct.
Registration area = the paging trade-off. A larger area means fewer location updates from idle UEs but more cells to page; a smaller area means the reverse. The AMF tunes this per UE, which is why reachability, paging and mobility are really one intertwined job.
Terminating NAS-MM (N1) and NGAP (N2)
The AMF sits at the meeting point of two protocols, and understanding how they relate is the key to understanding the whole radio-to-core control plane. NAS-MM is the conversation between the device and the core; NGAP is the conversation between the radio node and the core. The AMF terminates both.
N1 is the reference point between the UE and the AMF, and it carries NAS signalling — split into NAS-MM (mobility management: registration, service requests, security) and NAS-SM (session management, destined for the SMF). Crucially, N1 is a logical interface: there is no direct pipe from the device to the core. The UE's NAS messages are carried transparently inside RRC over the air and then inside NGAP across N2. The gNB does not read the NAS content — it is a relay. That is why NAS can be integrity-protected and ciphered end-to-end between the UE and the AMF even though it physically transits the radio node.
N2 is the reference point between the NG-RAN and the AMF, and it runs the NGAP (NG Application Protocol) over SCTP. NGAP carries everything the radio and core need to say to each other about a UE: UE-context setup and release, handover signalling, paging, and — as opaque payloads — the NAS messages travelling to and from the device. When the AMF needs a bearer set up for a PDU session, it sends the gNB the necessary radio instructions over N2; when the gNB has something for the core, it sends NGAP up the same link.
Container relaying. A single message can nest all three: an NGAP message over N2 carries a NAS container, which itself carries an N1 SM container the AMF must forward to the SMF. The AMF peels the outer layers, acts on the NAS-MM part, and relays the rest — it is a protocol translator as much as a state machine.
Spec anchor: the AMF and its services are defined in TS 23.501 (architecture) and TS 23.502 (procedures); NGAP on N2 is TS 38.413, and the 5G NAS protocol (both NAS-MM and NAS-SM) is TS 24.501. NGAP runs over SCTP on N2 (SCTP port 38412, PPID 60).
NAS security and the SEAF anchor role
Terminating NAS makes the AMF the network's security gatekeeper for the control plane. Two distinct responsibilities live here: protecting the NAS signalling itself, and acting as the security anchor for the whole access.
NAS security means integrity protection and ciphering of the NAS-MM messages between the UE and the AMF. After authentication, the AMF and UE run a NAS Security Mode Command / Security Mode Complete exchange to activate the agreed algorithms (the 5G-EA ciphering and 5G-IA integrity algorithms, negotiated from the UE's advertised security capabilities). Integrity protection is mandatory for NAS (so messages cannot be tampered with or forged); ciphering protects confidentiality. Each NAS message carries a NAS COUNT — a counter combining a sequence number and an overflow counter — that feeds the integrity and ciphering algorithms and provides replay protection, so a captured message cannot simply be replayed. The active security context is identified by the ngKSI (a key set identifier), which lets the UE and AMF refer to a specific set of keys without transmitting them, and enables fast re-use of an existing context (for example after an idle period) instead of re-authenticating every time.
The SEAF role. In 5G the AMF co-locates the SEAF (Security Anchor Function). During authentication, the AUSF and UDM in the home network verify the UE and derive an anchor key, KSEAF, which is delivered to the SEAF in the serving AMF. From that anchor key the SEAF/AMF derives KAMF and, in turn, the NAS integrity and ciphering keys and the KgNB handed to the gNB for access-stratum protection. Placing the anchor in the serving network means the visited AMF can manage keys and perform re-keying (including at handover and idle-to-active transitions) without going back to the home network every time. The device, meanwhile, holds the mirror of this context and identifies it with the same ngKSI.
Alongside security, the AMF enforces access control: it decides whether to admit a registering UE at all, applying subscription checks (fetched from the UDM over N8), mobility restrictions, and slice-admission rules. A device that is barred, roaming where it is not allowed, or requesting a slice it is not entitled to is rejected by the AMF before any session can be created.
ngKSI + NAS COUNT + KSEAF: the ngKSI names the security context, the NAS COUNT makes each protected message unique and replay-safe, and KSEAF (held by the SEAF in the AMF) is the root from which the serving network derives all NAS and AS keys.
The AMF's interfaces and slice-aware selection
The AMF is one of the most heavily connected functions in the core, precisely because it is the device's single point of contact. It talks to the UE and the RAN over classic reference points, and to the other control-plane NFs over the service bus. In service-based terms, everything the AMF offers is exposed as the Namf service-based interface (with concrete services such as Namf_Communication, Namf_EventExposure, Namf_MT and Namf_Location); the N-numbered reference points below are the corresponding end-to-end views.
| Interface | Peer | Purpose / protocol |
|---|---|---|
N1 | UE | NAS-MM signalling (logical; relayed by the RAN inside N2). |
N2 | NG-RAN (gNB) | Control plane to the radio: NGAP over SCTP. UE-context, handover, paging, NAS transport. |
N8 | UDM | Fetch subscription and access/mobility data; register the serving AMF for the UE. |
N11 | SMF | Trigger and relay PDU session management; carries N1 SM/N2 SM containers. |
N12 | AUSF | Authentication: the AMF/SEAF runs 5G-AKA/EAP-AKA' with the AUSF. |
N14 | AMF | Inter-AMF context transfer during mobility and AMF relocation. |
N15 | PCF | Access and mobility policy (e.g. service-area and RAT/frequency restrictions). |
N22 | NSSF | Slice selection: resolve the allowed S-NSSAIs and the serving AMF set. |
Namf | SBA bus | The service-based interface exposing the AMF's services (communication, event exposure, location) to other NFs. |
Two of the AMF's selection jobs are worth spelling out. First, SMF selection: when a UE requests a PDU session (via a NAS-SM message riding inside NAS-MM), the AMF chooses an appropriate SMF — using the requested DNN and S-NSSAI, discovering candidates through the NRF — and forwards the request to it over N11. The AMF then relays the N1 SM container (the session part of the UE's NAS message) down to the SMF, and the N2 SM container (the resource instructions from the SMF) out to the gNB. It shuttles session signalling without ever managing the session.
Second, slice-based AMF selection and relocation. Not every AMF instance supports every slice. At registration the UE presents a Requested NSSAI; the initial AMF (chosen by the RAN) may consult the NSSF over N22 to resolve the Allowed NSSAI and determine which AMF set can serve those slices. If the current AMF cannot, the procedure relocates the UE to a suitable AMF, transferring context over N14. This is how the same physical core presents many logical slices while still giving each UE a single, slice-appropriate anchor.
AMF as control-plane hub: N1 to the UE, N2 to the gNB, N11 to the SMF, and N8/N12/N15/N22 to the UDM/AUSF/PCF/NSSF, with N14 to a peer AMF.Contrast with LTE's MME: what moved to the SMF
If you know 4G, the cleanest mental model is this: the AMF is the LTE MME with its session-management responsibilities amputated and handed to the SMF. In the EPC, one function — the MME — did both mobility and session control: it managed attach and tracking-area updates, paging and mobility, and it drove bearer setup by signalling the S-GW and P-GW. 5G deliberately splits that in two. The AMF keeps everything about the device (registration, connection, reachability, paging, mobility, NAS security), while everything about a session (establishing PDU sessions, allocating the UE's IP address, selecting and programming the UPF over N4) moves to the SMF.
LTE ↔ NR: LTE's MME was a monolith — mobility and session/bearer control in one box, terminating S1AP from the eNB and fetching subscriber data from the HSS over S6a. NR splits it: the AMF keeps the device-facing half (registration, CM/RM states, paging, mobility, NAS security, now terminating NGAP/N2), the SMF takes the session half, subscriber data comes from the UDM over N8, and the security anchor is formalised as the SEAF co-located in the AMF. Even the states rename cleanly: LTE's EMM-REGISTERED/ECM-CONNECTED become RM-REGISTERED/CM-CONNECTED.
| Responsibility | LTE MME | 5G owner |
|---|---|---|
| NAS mobility management (registration/attach, TAU) | MME | AMF |
| Connection management, paging, reachability | MME | AMF |
| NAS security / security anchor | MME | AMF (with SEAF) |
| Termination of RAN control interface | MME (S1-AP) | AMF (NGAP/N2) |
| Session/bearer management, IP allocation | MME + S-GW/P-GW control | SMF |
| User-plane selection and programming | MME chose S-GW/P-GW | SMF selects & programs UPF over N4 |
| Subscriber data source | HSS (over S6a) | UDM (over N8) |
The payoff of the split is the same theme that runs through the whole 5G core: mobility and sessions scale on different axes. Mobility events (paging, idle-active transitions, handovers) are frequent and touch every device; session events are less frequent and can be numerous per device. By giving the AMF a pure device role and the SMF a pure session role, each can be scaled, upgraded and even sourced from different vendors independently — something the monolithic MME could never do. The AMF still relays the session signalling (the N1 SM and N2 SM containers) between the UE, the gNB and the SMF, but it is a courier for those messages, not their owner.
Summary
The AMF is the per-UE control-plane anchor of the 5G core: one function per device, from registration to deregistration, that owns the device's identity, security context, location and reachability but never touches user data. It terminates two protocols — NAS-MM from the UE over the logical N1, and NGAP from the RAN over N2 (SCTP) — and tracks the device on two independent axes: Registration Management (RM-DEREGISTERED/RM-REGISTERED, "does the network know you") and Connection Management (CM-IDLE/CM-CONNECTED, "are we talking right now"). It reaches idle devices by NGAP Paging across a tuned registration area, and keeps location correct through handovers and Mobility Registration Updates, relocating context over N14 when the serving AMF must change.
As security gatekeeper it co-locates the SEAF, receives KSEAF after authentication, and derives the NAS and AS keys, using the ngKSI to name the context and the NAS COUNT for replay protection; it also enforces access control and slice admission. Around it radiate the interfaces — N8/UDM, N11/SMF, N12/AUSF, N15/PCF, N22/NSSF, plus the Namf SBI — through which it selects an SMF and relays session containers without ever managing the session. The clean way to remember it: the AMF is the LTE MME's mobility, connection, paging and security half, with session/bearer control carved out to the SMF so the two can scale independently.
Quick Q&A
The questions that separate reciting the acronym from understanding what the AMF actually does.
Q. What is the difference between the RM and CM state machines?
A. Registration Management (RM-DEREGISTERED/RM-REGISTERED) is about whether the network knows the device and holds a registration context. Connection Management (CM-IDLE/CM-CONNECTED) is about whether a live N1/N2 signalling connection exists right now. A device is normally RM-REGISTERED while cycling repeatedly between CM-IDLE and CM-CONNECTED.
Q. How does the AMF reach an idle UE?
A. By paging. The AMF sends NGAP Paging to every gNB in the UE's registration area; the cells broadcast the page and the UE answers with a Service Request, moving to CM-CONNECTED. The registration area sizing is the trade-off between paging load and idle-mode location updates.
Q. What does it mean that N1 is a "logical" interface?
A. There is no direct radio-independent link from the UE to the AMF. NAS messages ride inside RRC over the air and inside NGAP across N2; the gNB relays them without reading their content. That is what lets NAS be integrity-protected and ciphered end-to-end between UE and AMF.
Q. What is the SEAF, and what is ngKSI for?
A. The SEAF (Security Anchor Function) is co-located in the AMF; it receives the anchor key KSEAF from the AUSF after authentication and derives the NAS and AS keys in the serving network. The ngKSI identifies the resulting security context so UE and AMF can reference and reuse it without re-authenticating; the NAS COUNT gives each protected message replay protection.
Q. Does the AMF manage PDU sessions?
A. No. It selects an appropriate SMF (using DNN/S-NSSAI and NRF discovery) and relays the session signalling — the N1 SM container down to the SMF over N11 and the N2 SM container out to the gNB. The SMF owns the session, IP allocation and UPF programming.
Q. Which LTE node is the AMF closest to, and what changed?
A. The MME. The AMF inherited the MME's mobility, connection, paging and NAS-security roles, but the MME's session/bearer control was carved out into the SMF (with the user plane going to the UPF). This lets mobility and session functions scale independently.
Quick LTE 4G / 5G NR Interview Questions
Q. How does the AMF decide whether an incoming Registration Request needs full authentication vs. can reuse an existing security context?
A. It checks whether the request carries a valid, current 5G-GUTI mapping to a context it (or a peer AMF, via context transfer) already holds with an unexpired security context. If so, it may skip a full AKA run and just verify integrity with the existing keys; if the UE is unknown, or the context is invalid/expired, or it's a new PLMN, full authentication is triggered.
Q. What happens if the AMF has no keys for a UE it needs to authenticate (e.g., UE roaming into it for the first time)?
A. The AMF cannot authenticate on its own — it has no key material — so it forwards the SUCI to the UE's HPLMN via AUSF, which resolves SUCI to SUPI (via UDM/SIDF) and runs the AKA vectors calculation, returning authentication vectors for the visited AMF to complete the challenge with the UE.
Q. Why is there exactly one AMF per UE even if the UE has multiple simultaneous PDU sessions on different SMFs?
A. The AMF's job is purely control-plane/mobility — a single stable anchor for the UE's registration and connection state simplifies mobility handling (only one function needs to track "where is this UE") while session-specific logic (QoS, UPF selection) is delegated per-session to whichever SMF owns that session, avoiding the AMF needing to understand session internals.
Where to go next
You now know the device's control-plane anchor — its states, its security role, and the interfaces radiating from it. Follow those interfaces outward: down N2 into the radio-to-core signalling protocol, across N11 into how sessions are actually built, or into the authentication exchange the AMF/SEAF runs at registration.