NAS Overview (5GMM & 5GSM) in 5G NR

Introduction

NAS is the control-plane protocol suite (TS 24.501) that manages a UE as a subscriber rather than as a radio occupant of a cell. It runs end-to-end between the UE and the 5G core — the AMF for mobility and the SMF for sessions — and it is the layer that decides whether a UE is even allowed onto the network, what identity it carries, which keys protect its signalling, and which data pipes it may open.

NAS is in play across the whole UE lifecycle. It runs the moment a UE powers on (Registration), whenever it needs to resume from idle (Service Request), whenever the core wants to update it (Configuration Update), and every time an application asks for connectivity (PDU Session procedures). Below NAS sits the Access Stratum (RRC/PDCP/RLC/MAC/PHY) that actually moves the bytes; NAS simply hands sealed messages to the AS to carry.

Because NAS is a small number of distinct procedures — registration, authentication, security-mode, service request, session management — and each carries a small, well-defined set of IEs, a NAS problem almost always localises to one message and one field. That is why reading NAS message by message, header field by header field, turns a vague "device won't attach / won't get data" complaint into a specific, testable fault.

Why NAS is needed

Subscriber-level functions — identity, authentication, mobility state, reachability, and data sessions — must be owned by the core and stay independent of which cell the UE happens to be camped on. If those functions lived in the RAN, every handover would risk dropping the security context or the sessions. Keeping them in NAS decouples the subscriber relationship from the radio: the cell can change underneath the UE hundreds of times, and its identity, keys, and PDU sessions ride through untouched.

What NAS Is, and What the gNB Sees

Everything the UE and RAN exchange to set up and steer the radio link — RRCReconfiguration, measurement reports, scheduling grants, HARQ — is the Access Stratum (AS). NAS is the layer above that: the signalling that manages the UE as a subscriber of the network rather than as an occupant of a particular cell. Registering to the network, being authenticated, being handed a temporary identity, being paged, and opening a data pipe are all NAS jobs. The gNB never terminates NAS; it only relays it as an opaque blob of bytes.

The clean separation is deliberate. Because NAS security keys live only at the UE and the AMF, the gNB physically cannot decrypt or forge NAS content even if it wanted to. That is what "transparent" means here: the RAN is a trusted courier for a sealed envelope, and the envelope is opened only at the two endpoints. This is also why the same NAS context survives as the UE moves between gNBs — the radio changes underneath, but the subscriber-to-core relationship does not.

Two Protocols: 5GMM and 5GSM

TS 24.501 splits NAS into two sub-protocols, and every NAS message announces which one it belongs to through the Extended protocol discriminator in its header. The two never compete; one carries the other.

5GMM — 5GS Mobility Management. This is the UE-to-AMF protocol. It handles the UE as a mobile subscriber: the Registration procedure (initial, mobility, periodic), Deregistration, the Service Request procedure, primary authentication, NAS security establishment, paging response, and the Configuration Update procedure the AMF uses to push new parameters — a fresh 5G-GUTI, an updated allowed NSSAI, a new TAI list. 5GMM owns the UE's reachability, its location tracking, and its security state. Everything a UE must do before it can move any user data at all is a 5GMM job.

5GSM — 5GS Session Management. This is the UE-to-SMF protocol, and it manages data connectivity end to end: PDU Session Establishment, PDU Session Modification, and PDU Session Release. The subtlety is that the SMF is not directly reachable by the UE. Every 5GSM message is placed inside a NAS container and carried by a 5GMM transport message — typically the UL NAS TRANSPORT / DL NAS TRANSPORT pair — which the AMF receives on the N1 interface and relays to the correct SMF over the service-based core. So 5GSM never talks to the network on its own; it always rides on 5GMM, and the AMF acts as the router that maps a PDU session ID and S-NSSAI to an SMF.

The NAS Message Header

Every NAS message begins with a small, fixed preamble that tells the receiver three things: which sub-protocol it is, whether and how it is security-protected, and what the message actually is. Getting these first bytes right is what lets the same parser handle a plaintext Registration Request and a fully ciphered PDU Session Establishment Accept.

The first field is the Extended Protocol Discriminator (EPD). In 5G this is a full octet (extended from the 4-bit protocol discriminator of LTE), and its value selects 5GMM or 5GSM. The second field is the Security Header Type, a 4-bit value that says whether the message is a plain NAS message, integrity-protected only, or integrity-protected and ciphered — and whether it is a special "security mode" message. When the security header indicates a protected message, the message is actually a security-protected NAS message: an outer wrapper carrying the Message authentication code (MAC) and a Sequence number, inside which the real plaintext NAS message (with its own EPD and message type) is nested and possibly ciphered.

After the security header comes the Message type octet, which names the procedure — Registration request, Authentication request, Service request, and so on — followed by the message's information elements. 5GSM messages additionally carry a PDU session identity and a Procedure transaction identity up front, because a UE can juggle several PDU sessions and several in-flight session procedures at once.

The Security Header Type enumeration is small and worth memorising, because it is what a decoder uses to decide whether to attempt integrity/decipher:

Reading a NAS header in the logs

Most 5G protocol analysers decode the NAS PDU straight out of the RRC or NGAP container. The header fields above are the first thing to eyeball: they tell you which sub-protocol, whether protection is on, and where in the COUNT stream this message sits.

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

NAS Has Its Own Security

NAS protection is entirely separate from AS (PDCP) protection, and it comes first. Once primary authentication succeeds it yields the anchor key K_AMF, from which the UE and AMF each derive a dedicated NAS security context: an integrity key K_NASint and a ciphering key K_NASenc. These protect NAS signalling end-to-end between the UE and the AMF. The gNB, which only relays bytes, holds none of them.

Two properties matter. Integrity protection is mandatory for NAS once a security context is active — every protected NAS message carries a 32-bit Message authentication code, and a message that fails the integrity check is discarded. Ciphering is optional in the sense that a "null" ciphering algorithm exists, but confidentiality is normally applied. The chosen algorithms come from the operator-configured priority list and are one integrity algorithm (NIA0/1/2/3) and one ciphering algorithm (NEA0/1/2/3).

Which security context is in use is identified by the ngKSI (Key Set Identifier), a small value the UE and AMF exchange so they can point at the same K_AMF without re-running authentication on every connection. If the UE presents an ngKSI the AMF still recognises, they can reactivate the existing native context; otherwise a fresh authentication is triggered.

Replay and freshness are handled by the NAS COUNT, a 24-bit counter kept separately for uplink and downlink. It is built from a Sequence number (the low 8 bits, carried in the header) plus a NAS overflow counter (the high 16 bits, kept locally and incremented when the sequence number wraps). The full COUNT feeds both the integrity and ciphering algorithms as an input, so every message is cryptographically bound to its position in the stream and a replayed message computes the wrong MAC.

The context is switched on by the NAS Security Mode Command procedure: the AMF sends an integrity-protected Security Mode Command carrying the selected algorithms, the ngKSI, the UE security capabilities it received (echoed back so the UE can detect tampering), and the ABBA parameter; the UE replies with a Security Mode Complete that is both integrity-protected and ciphered with the new keys. The ABBA (Anti-Bidding-down Between Architectures) parameter binds the derived key to a specific set of security features, which — together with the AMF echoing the UE's advertised capabilities — is precisely the anti-bidding-down defence: an attacker cannot silently strip the UE down to weaker algorithms, because any alteration of the capabilities makes the integrity check fail.

5GMM and 5GSM States

The UE's 5GMM state has two independent dimensions, and it pays to keep them apart. Registration status tells you whether the network holds a mobility context for the UE. In 5GMM-DEREGISTERED the AMF has no valid registration — the UE must run the Registration procedure before it can use any service. In 5GMM-REGISTERED the UE has a valid registration, a 5G-GUTI, an allowed NSSAI, and a registration area (a TAI list), and can request services.

Connection status tells you whether a NAS signalling connection currently exists over N1. In 5GMM-IDLE (which maps to RRC_IDLE or RRC_INACTIVE on the radio) there is no active N1 NAS connection and the UE is reachable only via paging. In 5GMM-CONNECTED (mapping to RRC_CONNECTED) an N1 connection is up and NAS messages flow immediately. A registered UE toggles between these substates across its stay: a Service Request moves an idle registered UE back to CONNECTED to resume data or answer a page, and network inactivity releases it back to IDLE.

5GSM has its own, per-session state machine that lives inside the SMF and the UE in parallel: PDU SESSION INACTIVE when no session exists, transitioning through PDU SESSION ACTIVE PENDING during establishment to PDU SESSION ACTIVE once the user-plane is up, and back through PDU SESSION INACTIVE PENDING on release. Because 5GSM rides on 5GMM, a session can be ACTIVE while the 5GMM connection is IDLE — the pipe is provisioned but suspended until a Service Request reconnects it.

Several NAS timers police these transitions, and they show up constantly in traces: T3510 guards Registration Request (waiting for Accept/Reject), T3550 guards Registration Complete, T3512 is the periodic-registration timer whose expiry drives periodic registration, and T3502/T3511 govern retry back-off after a registration attempt fails. A stuck state is almost always a timer that expired without the expected peer message.

How NAS Rides the Radio and N2

Because NAS terminates at the UE and the AMF, the gNB in between must pass it along without interpreting it — and it does so through two different carriers depending on which leg of the path the message is on.

On the radio (Uu): the UE and gNB use RRC (TS 38.331). A NAS message travels inside the RRC IE dedicatedNAS-Message, carried on a Signalling Radio Bearer — SRB1/SRB2 once the connection is up. In the uplink it rides in ULInformationTransfer; in the downlink in DLInformationTransfer; and during connection setup it is piggybacked on RRCSetupComplete, where the initial Registration Request or Service Request travels alongside the RRC completion.

Between gNB and AMF (N2): the two use NGAP (TS 38.413). The gNB lifts the NAS bytes out of the RRC container and drops them into the NGAP NAS-PDU IE, carried in INITIAL UE MESSAGE for the first message of a connection and thereafter in UPLINK NAS TRANSPORT and DOWNLINK NAS TRANSPORT. A 5GSM message rides this whole path folded inside its 5GMM transport wrapper, and only once the AMF unwraps it does the payload continue to the SMF over the service-based interface.

Reading NAS transport in the logs

On the RAN–core boundary, the same NAS PDU appears twice: once inside RRC on the air trace and once inside NGAP on the N2 trace. Confirming the bytes are identical on both sides is the fastest way to prove the gNB relayed faithfully.

Representative gNB N2 trace — illustrative, values vary by vendor/build:

LTE ↔ NR

Summary

NAS is the UE↔core control plane, and it decomposes cleanly: 5GMM owns mobility, identity, security, and reachability with the AMF; 5GSM owns data pipes with the SMF and always rides inside 5GMM transport. Read any NAS problem in this order — header (EPD, Security Header Type, COUNT) tells you which protocol and whether protection is on; the message type tells you the procedure; the IEs carry the decision.

The two things that trip people up most are the transport indirection (a session failure is often a 5GMM-transport or SMF-selection failure, not a 5GSM one) and the orthogonal states (registered vs connected; a session can be ACTIVE while the UE is IDLE). Keep those two facts in mind and most "won't attach / won't get data" tickets resolve to a specific message and field.

Interview quickfire