5G NAS Message Structure and Security Header
NAS decoding should start with the outer message structure, not with individual information elements. First identify which NAS family the message belongs to, whether it is plain or security-protected, what the security header indicates, and whether the message carries nested NAS content.
A common practical question is: how should a 5G NAS message be read and decoded correctly? This page answers that question through the framing logic behind 5G NAS messages: protocol discriminator reading, security header type, plain versus protected NAS, message containers, and the top-down decode habits that help avoid common trace-reading mistakes.
Quick facts
| Technology | 5G |
|---|---|
| Area / Protocol | NAS message framing and security header |
| Main fields | Extended protocol discriminator, security header type, message type, message body |
| Main split | Plain NAS message versus security-protected NAS message |
| Primary use | Top-down decode of NAS framing before procedure or IE interpretation |
| Related topics | N1, NAS Mobility Management, NAS Session Management, authentication, Security Mode Command, registration, PDU session procedures |
Contents
Overview
NAS message structure is one of the most important foundations for practical decode work. Before you ask what a message means in procedure context, you first need to know what kind of NAS message you are looking at and whether the outer message form is plain or protected.
Many reading mistakes begin at this level. A trace can look confusing not because the message is complicated, but because the message family, security state, or embedded content was identified incorrectly at the start.
Why framing matters
NAS framing is the layer that tells you how to enter the message. If the framing is read incorrectly, later interpretation of message type, information elements, and procedure role is likely to be wrong as well.
| Decode question | Why it matters | Typical mistake |
|---|---|---|
| Which NAS family is this? | Separates mobility-side and session-side reading early. | Treating session-management content as if it were mobility-management signaling. |
| Is the message plain or protected? | Determines whether an outer protected form must be interpreted first. | Jumping straight into the inner message meaning without reading the security framing. |
| Is there embedded content? | Prevents misreading nested transport or container content as top-level fields. | Reading a carried NAS payload as though it were the outer message itself. |
Basic NAS framing
A good way to approach a NAS message is from outside to inside. Start with the outer header fields that tell you the NAS family and protection state. Then identify the message type. Only after that should you move into the message body and its information elements.
1. Identify the NAS family
2. Check the security header type
3. Identify the message type
4. Read the outer message structure
5. Interpret the body or carried container content
Protocol discriminator
The protocol discriminator is one of the first fields that should be checked in a NAS decode. It tells you which NAS family the message belongs to and therefore which message-type space and interpretation path should be used next.
In practical reading, this is where the first major split happens between mobility-management meaning and session-management meaning.
| NAS family type | Main meaning | Typical reading context | Procedure direction |
|---|---|---|---|
| 5G Mobility Management (5GMM) | Mobility-side NAS control. | Registration, identity, authentication, security, service continuity, deregistration, and status handling. | Move into mobility-side procedures such as registration, service request, identity, or deregistration. |
| 5G Session Management (5GSM) | Session-side NAS control. | PDU session establishment, modification, release, transport, and session status handling. | Move into session-side procedures such as PDU session establishment, modification, release, or session transport. |
| Reading role | What to decide | Why it matters |
|---|---|---|
| NAS family selection | Whether the message should be read in a mobility-management or session-management context. | Prevents message-type confusion early in the decode path. |
| Procedure direction | Which broader control family to open next. | Guides the reader toward registration-side or session-side procedure context. |
NAS Architecture and N1 Context
Use this when the protocol-family question is really about where mobility-side and session-side NAS fit in the 5G control plane.
5GSM Overview and Session State Model
Continue here when the discriminator points to session-management content and the next step is 5GSM procedure context.
Security header type
The security header type tells you how the outer NAS message should be interpreted. It is one of the most important practical fields in NAS trace reading because it changes how the rest of the message is entered and what should already be true about the security state.
| Question | Interpretation value | Reading consequence |
|---|---|---|
| Is the message plain? | The outer message can be read directly as NAS content. | You can move straight from message framing into message type and body. |
| Is the message protected? | The outer form is security-related and must be interpreted before the inner message meaning. | You must read the protected outer structure first and then understand the inner content in that context. |
| Should protection already exist? | Helps determine whether the message appears at the correct stage of security progression. | Very useful when procedures stop around authentication or security mode steps. |
Plain and protected NAS
One of the most important practical splits in NAS decoding is the difference between plain NAS and security-protected NAS. Plain NAS is entered directly through the message framing. Protected NAS adds an outer security-related form that must be understood before the inner message body is interpreted.
This distinction matters because the same reader habit does not work for both forms. With plain NAS, the outer frame usually leads directly into the message type and body. With protected NAS, the outer frame first tells you about the protection state, and only after that should the inner NAS message be interpreted in procedure context.
| Form | What you see first | How to read it | Typical use or reading context |
|---|---|---|---|
| Plain NAS | The outer NAS frame leads directly to the message type and body. | Read the message type, then move into the body and information elements directly. | Common in early-stage control reading, especially before protection becomes the main question. |
| Security-protected NAS | An outer protected form appears before the inner NAS message content. | Read the protection-related outer frame first, then interpret the inner message meaning in that context. | Important once security is established and later NAS control depends on the existing security state. |
If a message looks unfamiliar, first ask whether you are looking at a plain NAS frame or at an outer protected frame that carries an inner NAS message. That one check often explains why a decode initially looks inconsistent.
Containers and embedded content
NAS decoding also becomes easier when you expect nested content. Some NAS messages carry container-style content that should be treated as embedded information rather than read as though it were the outer message itself.
This is especially important around transport procedures, carried session-management content, and cases where a decode tool shows inner NAS content after the outer message type is already identified.
Decode workflow
A reliable NAS decode workflow starts at the outer frame and moves inward. That approach separates message family, protection state, and nested content before the reader commits to a procedure interpretation.
| Step | What to inspect | Result |
|---|---|---|
| 1 | Protocol discriminator | Identify whether the message belongs to mobility-management or session-management context. |
| 2 | Security header type | Decide whether the message is plain or protected and how the outer frame should be read. |
| 3 | Message type | Identify the exact NAS message family member. |
| 4 | Body and containers | Read the message body or any embedded content in the correct context. |
| 5 | Procedure placement | Only now move into registration, security, service, or session procedure interpretation. |
Example
Consider a trace where the decoder shows a Registration Request. A good read path is: first confirm that the message belongs to 5G Mobility Management (5GMM), then check whether the outer form is plain or security-protected, then confirm the message type, and only after that move into the body fields such as registration type, identity, or capability-related content.
5GMM message
Extended protocol discriminator: 5G Mobility Management
Security header type: Plain 5G NAS message
Message type: Registration Request
Registration type: Initial registration
ngKSI: No key available
5GS mobile identity: SUCI
UE security capability: present
Requested NSSAI: present1. NAS family: 5GMM
2. Security header: plain NAS message
3. Message type: Registration Request
4. Body reading: registration intent, UE identity context, requested behavior
5. Procedure meaning: registration entry on the mobility-management side
The same top-down method also helps with a PDU Session Establishment Request. In that case, the discriminator should place the message in 5G Session Management (5GSM), which immediately tells you that the next procedure question is session-side rather than mobility-side.
Common reading mistakes
Most NAS structure mistakes are simple but costly. They usually come from skipping the outer framing questions and moving too quickly into procedure assumptions.
- Treating mobility-management content and session-management content as if they shared one message-type space.
- Ignoring the security header type and misreading a protected outer form as direct message body content.
- Missing embedded NAS or container-style content and decoding the wrong layer first.
- Assuming message meaning from procedure position before the message family and framing are confirmed.
References
- 3GPP TS 24.501, Non-Access-Stratum (NAS) protocol for the 5G System
- 3GPP TS 23.501, System architecture for the 5G System
- 3GPP TS 23.502, Procedures for the 5G System
FAQ
What is the first thing to check in a NAS message?
Start with the outer framing: identify the NAS family, check the security header type, then identify the message type before reading the body.
What is the role of the protocol discriminator in 5G NAS?
It identifies the NAS message family and therefore tells you whether the message belongs to a mobility-management or session-management reading path.
Why is the security header type important?
It tells you whether the message is plain or protected and therefore how the outer message frame should be entered before the inner content is interpreted.
Why do decode mistakes often start at the header?
Because wrong assumptions about NAS family, protection state, or embedded content usually cause every later interpretation step to drift away from the actual message meaning.