3 NAS messages are enough to build a complete picture of a 5G SA network

It’s 10:06 AM. You’re standing on a freshly deployed 5G SA site in a dense urban area. The handset shows “5G”. Signal bars are at full. But has the network actually allocated an eMBB slice? Will voice go through VoNR or fall back to VoLTE?

Nobody on the team can answer these questions without accessing NAS signaling.

And that’s exactly what 3 NAS messages captured in real time reveal.

What the handset doesn’t tell you

When a UE attaches to a 5G Standalone network, a series of NAS (Non-Access Stratum) messages is exchanged between the terminal and the core network over the N1 interface. These messages are defined in 3GPP TS 24.501 and contain critical information that the phone’s user interface never displays.

A field engineer relying solely on the “5G” icon and signal bars is working blind. The NAS layer is the only place where you can confirm what the network has actually decided for this terminal.

Registration Accept: the network’s verdict

The Registration Accept (message type 66, defined in 3GPP TS 24.501 section 8.2.7) is the network’s response to the terminal’s registration request. It is the most information-rich message about the network-terminal relationship.

Here’s what a live capture reveals:

Allowed NSSAI: this field lists the slices the network authorizes for this terminal. In our capture, sst: 1 confirms the allocation of an eMBB (enhanced Mobile Broadband) slice, the standard profile defined in 3GPP TS 23.501 section 5.15.2.

imsVoPS3gpp: when this flag equals 1, the network indicates it supports IMS voice services on this PLMN via 3GPP access. This means voice can go through native VoNR (Voice over New Radio), without needing to fall back via EPS Fallback to 4G.

TAC (Tracking Area Code): confirms the tracking area in which the terminal is registered.

Active sessions: the list of PDU sessions already established (here sessions 1 and 2).

Why this matters: without this message, there’s no way to know whether the network actually allocated the requested slice or substituted a default one. On a multi-slice site (eMBB + URLLC), this verification is essential.

PDU Session Establishment Accept: the data connection confirmed

The PDU Session Establishment Accept (message type 194, 3GPP TS 24.501 section 8.3.2) confirms the data session parameters between terminal and network.

Key captured fields:

PDU Type = 2 (IPv6): the network allocated an IPv6 address for this session. In 5G SA, IPv6 is the default type recommended by 3GPP, unlike the dual-stack often seen in 4G.

SSC Mode = 1: Session and Service Continuity mode 1 (defined in 3GPP TS 23.501 section 5.6.9) guarantees that the UPF anchor remains the same throughout the session’s lifetime. This is the most common mode, providing IP address continuity during mobility.

QoS Rules: a QoS rule is automatically created with ruleOpCode: 1 (Create new QoS rule) and a bidirectional packet filter (dir: 3). The dqr: yes flag confirms this is the Default QoS Rule, applied to all traffic that doesn’t match any specific filter.

DL NAS Transport: the second session revealed

The DL NAS Transport (message type 104, 3GPP TS 24.501 section 8.2.11) is a container message used by the AMF to carry SM (Session Management) messages to the terminal through the MM (Mobility Management) layer.

In our capture, this message encapsulates a second PDU Session Establishment Accept (pduSessionId: 2, pti: 5, msgType: 194), revealing that a second data session is established simultaneously.

The ctnType: 1 field indicates the transported content is of type N1 SM information, meaning a session management message destined for the UE. This second session is also IPv6 with PDU type 2.

Why 2 sessions? In 5G SA, a terminal can maintain multiple simultaneous PDU sessions to different DNNs or the same DNN with distinct QoS parameters. This is a fundamental change from 4G where bearers were tied to a single APN.

What automated analysis reveals

By cross-referencing these 3 messages, a coherent picture of the network context emerges:

This level of visibility was historically reserved for core network probes positioned on the N11 interface (between AMF and SMF) or N4 (between SMF and UPF). Being able to read this same information from the terminal side, in real time, via the Qualcomm chipset’s DIAG interface, is a paradigm shift for field diagnostics.

Implications for 5G SA drive testing

Access to NAS signaling from the terminal opens concrete possibilities for field teams:

Slice verification: confirm that the requested slice (eMBB, URLLC, MIoT) is the one actually allocated by the network, not a fallback to a default slice.

VoNR diagnostics: identify whether voice calls use native VoNR or fall back via EPS Fallback before even placing the first call.

Session audit: see how many PDU sessions are simultaneously active, their IP types and respective QoS parameters.

SSC validation: verify that the session continuity mode matches the deployed architecture (SSC 1 for standard mobility, SSC 2/3 for edge computing).

All of this without deploying a probe, without accessing the core network, and without an operator licence. A single Android terminal with DIAG access is enough.

What this changes for field engineers

5G NAS signaling is no longer a domain reserved for core network teams. With the right DIAG reading tooling, every field engineer can access the same level of information as a network probe, directly from the terminal they already use for their measurements.

The question is no longer “does the site show 5G?” but “has the network actually configured this site as intended?”

3 NAS messages are enough to answer.

References: 3GPP TS 24.501 (NAS protocol for 5GS), 3GPP TS 23.501 (System architecture for 5GS), 3GPP TS 23.502 (Procedures for 5GS)