NAS stands for Non-Access Stratum. NAS message is a type of signaling communication exchanged between a mobile device, like a smartphone, and the core network of a mobile operator (e.g., Verizon, T-Mobile). These messages are fundamental for managing the device's state and its services, independent of the specific radio technology (like 4G LTE or 5G NR) used to connect.

Think of it like sending a sealed letter. The radio access network (the cell towers) acts as the postal service; it transports the envelope but doesn't know or care about the contents. The NAS message is the letter inside, read only by the sender (your phone) and the final recipient (the core network). This separation allows a single core network to manage devices connected through various radio technologies.

Putting it in a little bit formal way, a NAS message refers to a signaling message exchanged between the UE and the core network (especially AMF or SMF) to manage mobility, session, and security procedures. These messages operate at the NAS layer, which is above the radio access layers, and facilitate functions such as registration, authentication, security mode control, and session establishment, ensuring secure and reliable communication without directly involving the radio access network. NAS messages carry critical IEs(Information Element) like UE security capabilities, key set identifiers, and authentication parameters, which may relate across multiple messages to maintain context, integrity, and protection against attacks.

Followings are the list of the topics on this note.

• Core Functions of NAS Messages
• How a NAS Message is Structured
• Interdependancies Among Messages
• Reference

Core Functions of NAS Messages

There are two main categories of NAS messages in terms of core functionality, and together they enable a mobile device to remain connected, exchange data, and do so securely. The first is mobility management, which ensures the network always knows the device’s operational state and general location. This includes procedures such as attaching when the device powers on, detaching when it powers off, updating the network as the device moves, and responding to paging when the network needs to deliver calls or data. The second is session management, which establishes, modifies, and terminates the data connections—known as PDU sessions in 5G -- that form the user’s link to internet and application services. Alongside these two pillars, NAS messages also underpin the network’s security framework by authenticating the device and subscriber, and by generating the encryption keys that protect all subsequent signaling and user traffic.

• Mobility Management (EMM/5GMM): This involves managing the device's connection to the network as it moves. It includes procedures like attaching to the network when the phone is turned on, detaching when it's turned off, tracking area updates to inform the network of the device's general location, and paging when the network needs to find the device to deliver an incoming call or data.
• Session Management (ESM/5GSM): This function deals with the user's data connections. When you open a web browser or an app, NAS messages are used to establish, modify, and terminate the data bearers (or PDU sessions in 5G) that provide your internet pipeline.

These messages also play a crucial role in security, handling the authentication of the device and user, and establishing the security keys used to encrypt all subsequent communication, ensuring your calls and data remain private.

The split between the two categories is not only a way of describing what NAS does. 5GMM and 5GSM are two separate protocols with two separate extended protocol discriminator values, and 24.501 specifies them in separate clauses. They also have separate state machines. A UE can be registered with no PDU session at all, and that is a normal state rather than a failure.

The relationship between the two is not symmetric, and this is the part that decides what a trace looks like. A 5GSM message never travels on its own. It is piggybacked inside a 5GMM transport message, which means UL NAS TRANSPORT in the uplink and DL NAS TRANSPORT in the downlink. Integrity protection is never applied to a 5GSM message directly. It is applied to the 5GMM message carrying it, so session management inherits its security from mobility management rather than negotiating its own.

One consequence follows immediately, and 24.501 states it plainly. The two procedures run in parallel, and the success of the 5GMM procedure does not depend on the success of the piggybacked 5GSM procedure. A PDU session establishment can therefore be rejected while the transport that carried it succeeded. In a log this looks like one message and two independent outcomes, and reading it as a single result is a common mistake.

Security is the third item mentioned above, and it is worth being precise about where it sits. It is not a third category alongside mobility management and session management. Authentication, security mode control and key derivation are all 5GMM procedures. That is why the security material later in this note is drawn entirely from the registration flow.

• 5GMM and 5GSM are separate protocols : they carry different extended protocol discriminator values and run separate state machines, so a registered UE with no PDU session is a normal state.
• 5GSM messages never travel alone : they are piggybacked in UL NAS TRANSPORT and DL NAS TRANSPORT, and they inherit integrity protection from the 5GMM message around them.
• The two procedures succeed or fail independently : a piggybacked session request can be rejected while the mobility transport that carried it completed normally.
• Security is not a third category : authentication, security mode control and key derivation are 5GMM procedures, which is why they all appear inside the registration flow.

How a NAS Message is Structured

The rest of this note talks about information elements travelling between messages. Before that is readable, one question has to be settled: what does a NAS message actually look like on the wire? The answer is short, and it explains why a capture sometimes shows a NAS message in full and sometimes shows four bytes of header and nothing else.

Every 5GS NAS message is a standard L3 message, and 24.501 defines it in two forms. A plain message carries its fields in the clear. A security protected message carries a short header of its own, and the complete plain message sits inside it. The two layouts are drawn together below, because one of them is carried inside the other.

Figure 1. The security header is not a wrapper around the payload alone. It replaces the first two octets and pushes the entire plain message, its own protocol discriminator included, into the ciphered part.

Four fields do the work in the plain form, and each answers a different question.

• Extended protocol discriminator : one octet, and it decides which core network entity the message belongs to. 24.007 Table 11.2.3.1.1A.1 gives 0111 1110 for 5GS mobility management messages and 0010 1110 for 5GS session management messages. This is the field that separates 5GMM from 5GSM.
• Security header type : four bits in octet 2, and it states how the message is protected. A 5GSM message uses this octet for the PDU session identity instead.
• Procedure transaction identity : present in 5GSM messages only. It ties a request to its response when several session procedures run at once.
• Message type : one octet naming the message, such as REGISTRATION REQUEST or SECURITY MODE COMMAND.

The security header type is worth reading closely, because five of its sixteen values are defined and two of them exist for a single message each. 24.501 Table 9.3.1 lists them.

• 0000, plain 5GS NAS message : not security protected. A message received with this value is treated as plain, whatever the security context says.
• 0001, integrity protected : a message authentication code is present and the payload is readable.
• 0010, integrity protected and ciphered : the normal state once security is running. This is the value that makes a capture unreadable without the keys.
• 0011, integrity protected with new 5G NAS security context : reserved for SECURITY MODE COMMAND, and for nothing else.
• 0100, integrity protected and ciphered with new 5G NAS security context : reserved for SECURITY MODE COMPLETE, and for nothing else.

Those last two codepoints are the switch from clear text to ciphered text, and they explain the shape of every registration capture. A REGISTRATION REQUEST arrives as 0000 because no security context exists yet. The SECURITY MODE COMMAND arrives as 0011, so the UE can still read it and check it while the new context is only proposed. The SECURITY MODE COMPLETE goes back as 0100, and it is the first message protected with the new context in both directions. Everything after it is 0010.

One consequence surprises readers looking at a trace for the first time. Once the security header type reaches 0010, a capture taken without the NAS keys shows the outer seven octets and an opaque block after them. The message type is inside the ciphered part, so even the name of the message is not visible. That is why an analyser that decodes registration perfectly can decode nothing after SECURITY MODE COMPLETE.

• The security header replaces the header, it does not prepend to it : the plain message keeps its own extended protocol discriminator, and that copy travels inside the ciphered part.
• Two codepoints are single-purpose : 0011 belongs to SECURITY MODE COMMAND and 0100 belongs to SECURITY MODE COMPLETE. Either one locates the security mode control procedure in a trace immediately.
• The message type is inside the ciphered block : after security is activated, a capture without keys cannot even name the messages it is carrying.
• The extended protocol discriminator sorts 5GMM from 5GSM : it also decides whether octet 2 holds a security header type or a PDU session identity.

Interdependancies Among Messages

NAS messages are not isolated exchanges but are often interdependent, with specific Information Elements introduced in one message being replayed, referenced, or confirmed in subsequent messages to maintain integrity, consistency, and security throughout the signaling flow. This design ensures that critical parameters such as security capabilities, mobility identities, and network slice requests remain unaltered between different procedural steps, even as messages traverse untrusted access networks. For example, values sent during the initial registration are later echoed in security and acceptance messages, binding earlier declarations to later network decisions and preventing attacks such as capability downgrades, identity spoofing, or mismatched security contexts. These cross-message linkages create a coherent chain of trust from the UE’s first contact with the network to the establishment of secure sessions and ongoing service management.

NOTE : To understand the details of these interdependancies are important because many cases of test failures comes from the broken interdendancies among messages

Examples of typical message dependancies and related information elements that interrelates multiple NAS messages are illustrated below

Figure 2 runs an initial registration down the page as seven messages between the UE and the AMF, with the information elements that matter listed under each one. Read it from the top. The UE declares its identity and its capabilities, the network authenticates it, the network replays part of the declaration back, and the network then answers the requests the UE made. The dashed arrow at the bottom is not a message. It stands for every NAS message that follows, and it carries the one element that never stops being used.

Figure 2. The registration flow is a declaration followed by a confirmation. Every element the UE offers in the first message is either replayed back for verification or answered with the network's decision.

• Registration Request carries the declaration : 5GS Mobile Identity (SUCI or old 5G-GUTI), UE Security Capability, 5GMM Capability, Requested NSSAI, and ngKSI if a context is being reused. The drawing also lists UE Security Parameters from NR, which 24.501 does not define under that name.
• Authentication Request carries ABBA : this is the only element drawn on that arrow, and it is what later binds the security mode control step to this particular authentication.
• Registration Accept carries the answers : a new 5G-GUTI, the Allowed NSSAI, and the UE Radio Capability ID where one was requested.
• The dashed arrow is the lasting dependency : ngKSI appears in every NAS message after registration, so it is the one element in this drawing with no end point.

NOTE : The box drawn under Security Mode Command in Figure 2 repeats all six elements from Registration Request. That is wider than what 24.501 specifies. A SECURITY MODE COMMAND replays the UE security capability and nothing else from that list, as Table 8.2.25.1.1 sets out. The 5GS Mobile Identity and the Requested NSSAI are not present in it at all.

The brief descriptions of the signaling flow in terms of NAS message dependancies are as follows

UE Security Capability ↔ Replayed UE Security Capability

The UE offers its supported ciphering and integrity algorithms before any security is running. That message is unprotected. An attacker between the UE and the AMF could therefore remove the strong algorithms from the list, and the network would select the weakest one remaining. This pair is the defence against that downgrade. It is also the only replay on this page that the UE verifies itself.

• First appears in: Registration Request
• Replayed in: Security Mode Command
• Purpose: Lets the AMF verify that the UE security algorithms agreed in the SMC are exactly those initially offered by the UE.
• On mismatch: 24.501 clause 5.4.2.3 makes this the one replay the UE actively checks. If the received Replayed UE security capabilities IE differs from what the UE last sent, the UE answers with SECURITY MODE REJECT and 5GMM cause #23 "UE security capabilities mismatch".

5GMM Capability ↔ Retransmitted Registration Request

The 5GMM capability tells the AMF which NAS features the UE supports, and the network configures the UE from it. It travels in the same unprotected Registration Request as the security capability, so it has the same tampering problem. The answer 3GPP chose here is different. Rather than echo the single element back, the network asks for the whole message again.

• First appears in: Registration Request
• Confirmed in: Security Mode Complete, inside the NAS message container IE
• Purpose: Confirms the UE’s NAS feature support (e.g., PDU session type, NSSAI support) has not been altered by an attacker before security is activated.
• How: 24.501 Table 8.2.25.1.1 has no Replayed 5GMM capability IE, so this element is not echoed in the Security Mode Command. The AMF instead sets the RINMR bit in the Additional 5G security information IE. The UE then returns the whole original Registration Request in the NAS message container IE of the Security Mode Complete. That copy is integrity protected with the new context, and the AMF compares it against what it first received.

S1 UE Network Capability ↔ Replayed S1 UE Security Capabilities

A UE that supports both 5GS and EPS carries two sets of security algorithms. The 5GS set is negotiated on this interface. The EPS set has to be settled in advance. An interworking move to S1 mode over N26 leaves no time to negotiate it. This pair carries the EPS set, which is why a 5G registration can contain EPS algorithm names.

• First appears in: Registration Request (optional, as the S1 UE network capability IE)
• Replayed in: Security Mode Command (optional, as the Replayed S1 UE security capabilities IE)
• Purpose: Carries the EPS security algorithms the UE supports, so an AMF with an N26 interface can select EPS algorithms in advance of an interworking move to S1 mode.
• Note: 24.501 has no UE security parameters from NR IE, and no replayed form of one. The IE replayed here is the S1 one. It is present only when the Selected EPS NAS security algorithms IE is present, and clause 5.4.2.3 tells the UE to ignore it on receipt. The verification the UE actually performs is on the Replayed UE security capabilities IE above.

5GS Registration Type / Requested NSSAI ↔ Allowed NSSAI

The Registration Request answers two questions at once. The 5GS registration type says why the UE is registering, and 24.501 Table 9.11.3.7.1 gives it seven values, from initial registration through periodic registration updating to disaster roaming. The Requested NSSAI says which slices the UE wants. Neither is granted automatically, because subscription data and local policy both apply.

• First appears in: Registration Request (Requested NSSAI)
• Reflected in: Registration Accept (Allowed NSSAI)
• Purpose: The network responds with the allowed S-NSSAIs based on the UE’s request and subscription.

Requested PDU Session Establishment Parameters ↔ PDU Session Accept

This pair is a negotiation rather than a replay, and the presence rules show it. In the PDU SESSION ESTABLISHMENT REQUEST, the PDU session type and the SSC mode are both optional. The UE states a preference, or omits both. In the accept, the selected PDU session type, the selected SSC mode and the authorized QoS rules are all mandatory. The network answers whether or not the UE asked.

• First appears in: PDU Session Establishment Request
• Reflected in: PDU Session Establishment Accept
• Purpose: Negotiates session parameters such as SSC mode, QoS rules, and QoS flow descriptions.

UE Radio Capability ID ↔ UE Radio Capability ID Confirmation

A full UE radio capability container is large, and sending it on every registration wastes radio resources. RACS replaces the container with a short identifier that represents one set of capabilities. The identifier is either manufacturer-assigned or network-assigned. Both sides then have to agree on what the identifier means. That agreement is what this pair carries.

• First appears in: UE Capability Information (sent in NAS or RRC, depending on scenario)
• Confirmed in: Subsequent Registration Accept or via RRC signaling
• Purpose: Confirms the network has the correct UE capability reference.

5GS Mobile Identity (SUCI/GUTI) ↔ Assigned 5G-GUTI

A permanent subscriber identity sent in the clear is trackable, so 5GS never sends one. The UE presents a SUCI, which is the concealed form of the SUPI. It may present an old 5G-GUTI from a previous registration instead. The network then issues a fresh 5G-GUTI in the Registration Accept. Rotating that temporary identity is what stops an observer following one subscriber across registrations.

• First appears in: Registration Request (SUCI or old GUTI)
• Reflected in: Registration Accept (new GUTI assigned by the network)
• Purpose: Used for mobility and to replace temporary identifiers for privacy.

ABBA (Authentication and key Binding with Binding Authorization)

Authentication produces a key, and the key has to be tied to the context it was produced for. Without that binding, a key derived for one purpose could be replayed into another. ABBA is the parameter that carries the binding. It is mandatory in the Authentication Request, and it is an input to the key derivation rather than a value that gets compared.

• First appears in:
• Authentication Request (sent by AMF after Authentication Vector from AUSF)
• Referenced/Replayed in:
• Security Mode Command, but optionally rather than always. 24.501 clause 8.2.25.7 includes ABBA in the SMC only when that message also carries an EAP message IE holding an EAP-success.
• Purpose:
• Prevents certain inter-protocol or cross-domain binding attacks.
• Ensures the Security Mode Command is cryptographically bound to the specific authentication context.
• ABBA is an input to the K_AMF derivation, so a changed value produces a different key. The UE therefore fails the integrity check on the Security Mode Command rather than comparing the two ABBA values field by field.

ngKSI (NAS key Set Identifier for 5GS)

Both sides can hold more than one NAS security context at a time. A message therefore has to say which context protects it. That label is ngKSI. The network allocates it, and it occupies half an octet, so it is small enough to carry in every message. A TSC bit alongside it separates a native context from a mapped one. The value 111 is the exception, and from the UE it means that no key is available.

• First appears in:
• Registration Request (when UE has a valid NAS security context, e.g., mobility registration update)
• Or assigned in Security Mode Command after successful authentication (for initial registration).
• Referenced/Replayed in:
• All subsequent NAS messages sent under that NAS security context (e.g., Registration Complete, Service Request, PDU Session Establishment, etc.).
• Purpose:
• Identifies which NAS security context (keys) the message is protected with.
• Used to select the correct integrity and ciphering keys for uplink and downlink NAS messages.

Summarizing all of these in tabular format in terms of key IE (information elements) flows is following table

Reference

The message contents, the security header type values and the replay rules on this page were taken from the versions linked here, and checked field by field against them.

• 24.501 : Non-Access-Stratum (NAS) protocol for 5G System (5GS). Source for every message content table, the security header type values in Table 9.3.1, and the security mode control rules in clause 5.4.2. The version read was v20.0.0 (Release 20).
• 24.007 : Mobile radio interface signalling layer 3 - General aspects. Source for the extended protocol discriminator values in Table 11.2.3.1.1A.1. The version read was v20.0.0 (Release 20).
• 33.501 : Security architecture and procedures for 5G System. Named by 24.501 as the source of the initial NAS message protection scheme and the ABBA key binding. Not read directly for this note.