Registration & Authentication (5GMM) in 5G NR

Introduction

Registration is the first NAS procedure a UE runs and the gate every other service passes through. It is a single 5GMM transaction with the AMF that moves the UE from 5GMM-DEREGISTERED to 5GMM-REGISTERED, and along the way it authenticates the subscriber, authenticates the network back to the UE, turns on NAS ciphering and integrity, and hands the UE the identity, slices, and area it will operate in.

It runs at power-on (initial registration), when the UE roams out of its registered area (mobility registration), on a periodic timer to prove it is still reachable (periodic registration), and in a deliberately permissive form for emergency calls. Because the whole thing is a defined sequence of NAS messages — Registration Request, optional Identity Request, Authentication Request/Response, Security Mode Command/Complete, Registration Accept/Complete — a failure almost always lives in exactly one of them.

That is why registration rewards a step-by-step debugging habit: if you know which message broke — no Accept? auth rejected? security-mode rejected? — you have already narrowed a "device won't attach" ticket down to a small, testable set of causes. The rest of this page walks the procedure message by message with that lens.

Why registration is needed

Two trust problems must be solved before the network commits any resources. The network must never trust an unverified UE — handing an unauthenticated device an identity, slices and bearers would be an open door. And the UE must never trust a fake base station — an IMSI-catcher or rogue cell must not be able to lure it. Registration binds both directions of verification, plus the activation of encryption and integrity, into the very first thing the UE does, so nothing that follows stands on unverified ground.

What Registration Achieves

Registration is how a UE moves from 5GMM-DEREGISTERED to 5GMM-REGISTERED. It is a single NAS transaction with the AMF (Access and Mobility Management Function) that bundles four jobs into one exchange: it verifies the subscriber is genuine, it lets the UE verify the network in return, it agrees the ciphering and integrity algorithms that will protect all later signalling, and it hands the UE the parameters it needs to live in the cell — a temporary identity (5G-GUTI), the set of slices it may use (Allowed NSSAI) and the area it is registered in (the TAI list).

Everything the UE does afterwards inherits state from this moment. The keys derived during authentication seed the entire access-stratum security chain; the 5G-GUTI lets the network page the UE without ever re-sending its permanent identity; and the TAI list defines the geographic boundary that later triggers mobility registration. The gNB, it is worth stressing, is only a relay here: every NAS message travels transparently inside RRC and NGAP containers, and the AMF is the true peer of the UE.

Registration Types

Not every registration means the same thing. The 5GS registration type IE inside Registration Request tells the AMF why the UE has come knocking, and the answer changes how much work the network does — a fresh authentication, a light context update, or just a keep-alive. There are four defined types.

The two update types — mobility and periodic — are lightweight precisely because a security context already exists; the UE sends the request already integrity-protected with its stored K_AMF-derived keys, and the AMF often skips authentication entirely. Initial registration is the heavy one and the focus of the rest of this page: it is where SUCI, primary authentication and NAS security setup all happen. Emergency registration is deliberately permissive so that a distress call is never blocked by a missing or unauthenticated credential.

Registration Request and its Key IEs

The UE sends the 5GMM Registration Request as the first NAS message, carried up in the RRC dedicatedNAS-Message (piggybacked on RRCSetupComplete) and delivered to the AMF inside the NGAP INITIAL UE MESSAGE. It is a compact message but every IE in it steers the procedure.

• 5GS registration type: initial / mobility / periodic / emergency — as above. It also carries a Follow-on request flag telling the AMF whether the UE wants the connection kept up for a subsequent procedure (like a PDU session).
• 5GS mobile identity: the UE's identity, and it is one of two forms. On a first-ever contact it is a SUCI — the concealed form of the permanent SUPI, encrypted with the home network's public key so the SUPI never crosses the air in the clear. On any later registration it is the 5G-GUTI previously assigned by the AMF.
• UE security capabilities: the ciphering (5G-EA) and integrity (5G-IA) algorithms the UE supports, so the AMF can select a pair both sides share. These are replayed back later to defeat bidding-down attacks.
• Requested NSSAI: the list of S-NSSAIs (network slices) the UE wants to use. The AMF checks these against subscription and returns an authorised subset as the Allowed NSSAI.
• ngKSI: the key set identifier the UE holds for any existing security context, letting the AMF decide whether it can reuse a context or must authenticate afresh.

If the AMF that receives the request is not the one that holds the UE's context (common after mobility), it fetches the context from the old AMF over the N14 interface using the 5G-GUTI as a pointer. If it still cannot resolve who the UE is — for example the 5G-GUTI is stale or unknown — it falls back to explicit identification, described next.

Reading the Registration Request in the logs

The first NAS message is often the most informative one to decode, because it declares the UE's intent, identity form, and capabilities all at once. On the N2 trace it arrives inside INITIAL UE MESSAGE.

Representative NAS decode (analyser-style) — illustrative, values vary by vendor/build:

Identification: SUCI, SUPI and the 5G-GUTI

Identity in 5G is layered on purpose. The permanent identifier is the SUPI (Subscription Permanent Identifier) — typically an IMSI — and it is treated as a secret that should almost never appear on the radio interface. To protect it, the UE never sends the raw SUPI; it sends the SUCI (Subscription Concealed Identifier), which is the SUPI encrypted with the home network's public key using the ECIES scheme. Only the home network's UDM, holding the matching private key, can de-conceal it back to a SUPI.

When the AMF cannot determine the UE's identity from the 5GS mobile identity it received — no usable 5G-GUTI, no retrievable context — it issues a NAS Identity Request asking for a specific identity type. The UE answers with Identity Response carrying the requested identity, which for a permanent-identity request is a freshly generated SUCI (a fresh ephemeral key each time, so two SUCI values for the same subscriber are unlinkable). The AMF may also request the PEI (Permanent Equipment Identifier, the IMEI) for device-level checks.

The third identifier, the 5G-GUTI (5G Globally Unique Temporary Identity), is the working alias the AMF assigns in Registration Accept. It encodes the serving AMF (via the GUAMI — PLMN + AMF Region/Set/Pointer) plus a 5G-TMSI. From then on the UE is paged and identifies itself by this temporary value, and the AMF re-allocates it periodically so that even the temporary identity cannot be tracked for long.

Primary Authentication with 5G-AKA

The AMF does not authenticate the UE by itself. Acting in its SEAF (Security Anchor Function) role, it delegates to the home network. The trust chain runs AMF/SEAF ↔ AUSF ↔ UDM/ARPF: the AMF asks the AUSF (Authentication Server Function) to authenticate the subscriber; the AUSF asks the UDM/ARPF (the Authentication credential Repository and Processing Function inside the UDM) to generate an authentication vector from the subscriber's long-term key K. 5G defines two methods — 5G-AKA and EAP-AKA' — and this section walks through 5G-AKA, the common case.

The UDM/ARPF de-conceals the SUCI to a SUPI, then derives a 5G Home Environment Authentication Vector (5G HE AV) from K and a sequence number SQN. The AUSF converts this into a 5G AV that hides XRES* as a hash and passes the AMF only what it needs. The parameters flowing through this exchange are the heart of the mechanism.

Armed with the vector, the AMF challenges the UE with a NAS Authentication Request carrying RAND, AUTN, ngKSI and ABBA. The USIM verifies AUTN — checking the MAC and the freshness of SQN — which authenticates the network to the UE. Only if that passes does the USIM compute RES* and the keys, returning RES* in the NAS Authentication Response. The AMF computes HRES* from the received RES* and compares it with the HXRES* it holds; on a match it forwards RES* to the AUSF, which does the authoritative comparison against XRES*. Success releases K_SEAF to the AMF and reveals the SUPI.

From K to the access keys

Every key in 5G descends from the subscriber's permanent key K in a strict one-way chain, so that compromising a lower key never exposes a higher one. The chain is:

The USIM (with K) and the UDM/ARPF both derive CK/IK, from which K_AUSF is formed; the AUSF derives K_SEAF; the AMF derives K_AMF, and from it the NAS-protection keys K_NASenc/K_NASint and the access-stratum root K_gNB handed to the gNB. That full tree, and how horizontal/vertical key derivation works on handover, is the subject of the Security Key Hierarchy page — registration is simply where the chain is first seeded.

Reading authentication in the logs

The authentication exchange is short but the fields are exact, and a single mismatch (a stale SQN, a wrong MAC) aborts the whole registration. The UE-side NAS trace shows the challenge and its verdict.

Representative NAS decode — illustrative, values vary by vendor/build:

NAS Security Mode Control

Authentication produced fresh key material and verified both identities, but it has not yet turned on protection. That is the job of the NAS Security Mode Control exchange, and it is deliberately kept separate from authentication so that key establishment and key activation are distinct, auditable steps.

The AMF sends a NAS Security Mode Command that selects one ciphering algorithm (5G-EA) and one integrity algorithm (5G-IA) from the UE security capabilities the UE reported, names the key set with ngKSI, and — critically — replays the UE's own security capabilities back. This message is integrity-protected (but not yet ciphered) using the newly derived K_NASint. The UE re-checks the replayed capabilities against what it actually sent: if they differ, a man-in-the-middle tried to force weaker algorithms, and the UE rejects — this is the bidding-down defence.

The UE then derives K_NASenc and K_NASint from K_AMF, activates the NAS security context, and replies with a Security Mode Complete that is both ciphered and integrity-protected. From this message onward, every NAS message in both directions is protected. The AMF frequently uses Security Mode Command to also request the UE's full radio and core-network capabilities, which the UE returns (safely, now that the channel is secure) inside Security Mode Complete. With NAS security active, the AMF is finally ready to admit the UE.

Registration Accept and Complete

With the subscriber authenticated and NAS security active, the AMF sends the 5GMM Registration Accept — the message that actually grants the UE its working parameters and completes the state transition. It is the payoff of the whole procedure.

Three IEs in Registration Accept matter most. The 5G-GUTI is the new temporary identity the UE uses from now on instead of its SUCI/SUPI. The Allowed NSSAI is the set of slices the network authorised — a subset of the Requested NSSAI, possibly accompanied by a Rejected NSSAI with per-slice causes. And the TAI list defines the Registration Area: the set of Tracking Areas across which the UE may move freely without sending a mobility registration. As long as the UE's serving cell broadcasts a TAI that appears in this list, it stays put; the moment it enters a cell whose TAI is absent, it triggers a mobility registration. The AMF sizes the list to trade signalling load against paging load — a bigger area means fewer registrations but more cells to page across.

If a new 5G-GUTI was assigned (it almost always is), the UE confirms storage by returning Registration Complete. At that point the UE is 5GMM-REGISTERED and, while the NAS signalling connection is up, 5GMM-CONNECTED. It can now open a data pipe with a PDU Session. Should anything have failed — authentication, an unsupported slice, a network policy block — the AMF would instead send Registration Reject with a 5GMM cause value telling the UE exactly why and how (and often whether) to retry.

Reading Accept / Reject in the logs

The final message tells you whether the whole procedure succeeded, and on failure the 5GMM cause is the single most useful field — it says both why and whether the UE should retry.

Representative NAS decode (both outcomes) — illustrative, values vary by vendor/build:

LTE ↔ NR

Summary

The fastest way to root-cause a registration failure is to walk the messages in order and find the first that broke. Request → (Identity) → Authentication → Security Mode → Accept: if the Registration Request never reaches the AMF, suspect RRC setup / INITIAL UE MESSAGE / N2. If an Identity Request loops, the AMF cannot resolve the identity (bad SUCI/5G-GUTI or N14). If authentication fails, read the cause — MAC failure points at credentials/rogue network, Synch failure at SQN. If Security Mode is rejected, suspect a capability-replay mismatch or no common algorithm. If the Accept never comes, read the 5GMM cause in the Reject.

Isolating the broken step turns a vague "attach failure" into a specific, testable hypothesis: each message points at a small, distinct set of causes. Best used log-in-hand — verify each message's IEs in sequence and the first field that does not line up is your root cause. Everything downstream (keys, paging, mobility, PDU sessions) inherits state from this one procedure, so getting it right is the foundation for the rest.

Interview quickfire