NAS stands for Non-Access. 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.

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.

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

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

UE Security Capability ↔ Replayed UE Security Capability

• 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.

5GMM Capability ↔ Replayed 5GMM Capability

• First appears in: Registration Request
• Replayed in: Security Mode Command
• 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.

UESecurityParametersFromNR ↔ ReplayedUESecurityParametersFromNR

• First appears in: Registration Request (optional, used for NR capability binding)
• Replayed in: Security Mode Command
• Purpose: Ensures that NR-side security parameters are not tampered with during initial attach.

5GS Registration Type / Requested NSSAI ↔ Allowed NSSAI

• 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

• 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

• 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

• 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)

• First appears in:
• Authentication Request (sent by AMF after Authentication Vector from AUSF)
• Referenced/Replayed in:
• Security Mode Command (copied exactly from Authentication Request)
• Purpose:
• Prevents certain inter-protocol or cross-domain binding attacks.
• Ensures the Security Mode Command is cryptographically bound to the specific authentication context.
• If ABBA in SMC doesn’t match ABBA in Auth Request, the UE rejects SMC.

ngKSI (NAS key Set Identifier for 5GS)

• 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