NAS-5GS in a Real 5G Capture

One layer of the 5G NR attach walkthrough, followed on its own: 12 messages over frames 4 to 133, the conversation between the UE and the core network rather than between the UE and the cell. Half of those messages have a readable body. The other half do not, and the subject of this page is where the line falls and why.

💡 Read the walkthrough and the diagram side by side. Open the interactive diagram (or PDF) in a split-screen window so the captions stay in view as you read. In Edge, Chrome, or Firefox, right-click the link and pick your browser's split-screen option (Edge labels it "Open link in split screen window"). On macOS, prefer Chrome or Firefox — Safari has no in-browser split screen. Otherwise, open the diagram in a new tab and snap the two windows side by side.

Where NAS sits

Look at how much wider that top box is than the ones below it, because the whole page follows from it. Every other layer in this stack terminates at the gNB: the cell decodes the message, acts on it, and answers. NAS does not stop there. Its peer is the AMF — the Access and Mobility Management Function, a core-network node that may be in another building or another country. The gNB relays NAS messages without reading them.

Two consequences follow immediately. The first is that NAS timings on this page are not radio timings; a NAS round trip includes a walk into the core and back. The second is the one this article is really about: NAS protects itself. It does not borrow the radio's security, because the radio's security stops at a node NAS does not trust with its contents. So two ciphers run over the same bytes, with two different key sets — and this capture publishes only one of them.

What NAS does

NAS — the Non-Access Stratum — is everything the UE says to the core network rather than to the cell. The "Access Stratum" is the radio: RRC, PDCP, RLC, MAC, PHY. Everything that is not about getting bits across the air is Non-Access Stratum, and in 5G that protocol is specified in TS 24.501, which Wireshark dissects as nas-5gs — NAS for the 5G System.

NAS is not one protocol but two sublayers, and keeping them apart matters more than any other piece of vocabulary here:

• 5GMM — 5GS Mobility Management. Registration, authentication, security mode control, service requests, paging responses, deregistration. It answers "is this subscriber allowed on this network, and where is it?"
• 5GSM — 5GS Session Management. PDU session establishment, modification, and release, QoS rules. It answers "what data pipes does this subscriber have, and with what treatment?"

They are genuinely separate. They carry different extended protocol discriminator values, different message-type spaces, and — the trap that catches people reading traces — different cause-code spaces. A 5GMM cause value and a 5GSM cause value with the same number mean unrelated things, so a cause code is meaningless until you know which sublayer produced it. A 5GSM message never travels on its own either: it is carried inside a 5GMM transport message.

For this capture, one fact settles the question early. No 5GSM message is readable anywhere in the trace — Wireshark reports no session-management message type on any of the 151 frames. Every message on this page is 5GMM, and the extended protocol discriminator reads 5G mobility management messages (126) on all twelve.

Key terms to understand before we begin the walkthrough:

The five security header types

TS 24.501 §9.3 defines exactly five values for the security header type, and this session exercises all of them:

The conversation we're following

💡 Where this diagram comes from. The diagram on this page is one session that VisualEther — the tool that decoded this capture and generated the diagrams here — lifted out of the full six-layer trace. VisualEther names each session it extracts; this is the one it labels nas-5gs/timeout/00003, keyed on nas-5gs::0x8000, 12 messages over frames 4 to 133.

The key is the C-RNTI — the Cell Radio Network Temporary Identifier, the short handle the cell uses to address one connected UE — and the capture reuses 0x8000, so this timeline spans more than one radio connection. It is what lets you watch a NAS context outlive the radio context beneath it.

Three things to keep in mind before we start the walkthrough:

No NAS keys. This trace ships encrypted, and it was opened up with the UE keys published in Wireshark work-item 19757. Those are the Access Stratum keys: they unlock PDCP, and through PDCP the RRC signaling and the user plane. The NAS layer runs a separate security context with separate keys that were not published. So on this page the radio around each message reads perfectly, but the NAS message itself sometimes does not. The decryption companion covers the key hierarchy and the recipe; here it is enough to know which half of it we hold.

No forced deciphering. Wireshark has a nas-5gs.null_decipher setting that tells the dissector to parse a NAS body as if it were unciphered. On a genuinely ciphered message, it decrypts nothing — the dissector parses ciphertext as information elements and invents 5GMM and 5GSM fields that were never sent. The flow behind this page leaves the setting off for this reason.

Six readable and six encrypted. Frames 4, 7, 9, 11, 14, and 133 have a readable 5GMM body. Frames 12, 15, 30, 31, 36, and 38 have Encrypted data where the body should be. Even the readable ones are only partly readable, as the first frame is about to show.

The flow at a glance

Before the frame-by-frame walk, here is the whole NAS conversation on one timeline — all twelve messages between the UE and the AMF, in the order the capture shows them. Six read; six are sealed, and the diagram marks which. Every frame number matches a step in the walk below.

The walk

Here is the whole session on one screen. The last column is the length of the dedicatedNAS-Message octet string the RRC layer handed to NAS — the only measure of a sealed message's size we get:

Frame 4 — the first NAS message, already half sealed

The Registration Request rides inside the RRC Setup Complete, and its envelope reads Security header type: Integrity protected (1), message authentication code 0x97a0a3f4, Sequence number: 6.

Stop on that sequence number. It is 6, not 0. An initial registration that arrives already integrity protected, under NAS key set identifier: 1 with Type of security context flag (TSC): Native security context, is not a first-ever power-on: the UE is reusing a NAS security context it held before the capture began.

The readable body is short:

• 5GS registration type: initial registration (1), with the Follow-On Request bit (FOR) set to Follow-on request pending — the UE announcing it has more to send once registration completes.
• 5GS mobile identity, length 11, Type of identity: 5G-GUTI (2): MCC: Test network (001), MNC: Test network (01), AMF Region ID: 254, AMF Set ID: 1, AMF Pointer: 1, 5G-TMSI: 0xc2345678. Remember that TMSI; it comes back at frame 133.
• UE security capability, element ID 0x2e, length 2. Supported: 5G-EA0, 128-5G-EA1, 128-5G-EA2, 128-5G-EA3, 128-5G-IA1, 128-5G-IA2, 128-5G-IA3. Not supported: 5G-EA4 through 5G-EA7, 5G-IA0, and 5G-IA4 through 5G-IA7.

And then the last information element, which sets the tone for the page. It is a NAS message container, element ID 0x71, Length: 61, and its entire contents are dissected as Encrypted data. Of the 92 octets RRC handed down, 61 are unreadable inside a message whose envelope reads in full.

That is TS 24.501 §4.4.6 working exactly as written. When a UE sends an initial NAS message, and it already has a security context, it sends the message twice over: a cleartext skeleton carrying only the handful of IEs the AMF needs before it can decipher anything — registration type, ngKSI, mobile identity, UE security capability — and the complete message, ciphered, in the container. Everything else the UE wants to say is in those 61 sealed octets.

The nesting is worth walking by hand. The tree below opens mac-nr one level; from there you expand one node at a time down through rlc-nr, pdcp-nr and nr-rrc — all of which decode completely because the published keys are the Access-Stratum keys — and into the nas-5gs node, where the decode gets four IEs deep and then stops at a length and the words Encrypted data:

Frame 4's full field tree, with the mac-nr node opened one level. Follow mac-nr -> rlc-nr -> pdcp-nr -> nr-rrc -> UL-DCCH-Message -> rrcSetupComplete -> dedicatedNAS-Message into the NAS node. The radio layers open all the way down because the published keys are the Access-Stratum keys. Inside NAS, -> Security protected NAS 5GS message -> Plain NAS 5GS Message holds the cleartext IEs — registration type, ngKSI, mobile identity, and UE security capability — and the NAS message container after them reads only as far as its length.

Frames 7 and 9 — the authentication exchange

Frame 7 — the AMF challenges, in the clear. 128.772 ms after the Registration Request, and Security header type: Plain NAS message, not security protected (0). It is the only message in the session with no security protection at all, and there is a good reason: the AMF has decided to authenticate afresh, and the context that would protect this message does not exist yet.

• NAS key set identifier - ngKSI: Native security context, value 2. Frame 4 arrived under ngKSI 1; this message mints ngKSI 2. From the Security Mode Command onward, every NAS message in the capture that names a key set names that one — frames 11, 14, 133, and 150.
• ABBA, length 2, contents 0000. The Anti-Bidding down Between Architectures parameter, bound into the key derivation so an attacker cannot force a fallback to a weaker generation's security.
• Authentication Parameter RAND, element ID 0x21: a3de0c6d363e30c364a4078f1bf8d577.
• Authentication Parameter AUTN, element ID 0x20, length 16: 6e323b36c46c8000a3df0e6e323bb6c4, which Wireshark splits into SQN xor AK: 6e323b36c46c, AMF: 8000, and MAC: a3df0e6e323bb6c4.

Sending a challenge in plain text is not a lapse. RAND and AUTN are public by design — they are useless without the long-term key K held in the USIM and in the subscriber's home network. One acronym collision is worth flagging: the AMF field Wireshark shows inside AUTN — 8000 here — is the Authentication Management Field of TS 33.102, a 16-bit field the home network sets when it builds the authentication token. It is not the AMF node this whole article is about. 5G reuses the same three letters for two unrelated things.

Frame 9 — the UE answers, under the old context. 40.223 ms later. Security header type: Integrity protected (1), message authentication code 0x891cabb4, Sequence number: 7 — the next uplink number after frame 4's 6. The new keys have been derived by now but are not yet in force; switching them on is the Security Mode procedure's job, not authentication's.

The body is a single IE: Authentication response parameter, element ID 0x2d, length 16, RES: d7c360c5a57c8f4f03bd1e406604eec2. That 16-octet value is RES*, which TS 33.501 has the UE compute from RAND, K, and the serving network's name; the network compares it against the expected XRES*. Binding the serving-network name into the response is what stops a valid answer being replayed at a different operator.

Frame 11 — the Security Mode Command, and one bit that matters

76.777 ms later. Security header type: Integrity protected with new 5GS security context (3), message authentication code 0x41bf0b2b, Sequence number: 0.

The counter restarted at zero. That is the tell for header type 3: this is the first message of a brand-new NAS security context, so the COUNT it is integrity-protected with starts from scratch.

• NAS security algorithms: Type of ciphering algorithm: 128-5G-EA2 (2), Type of integrity protection algorithm: 128-5G-IA2 (2). A vocabulary note, because both spellings appear in 5G documents: TS 24.501 writes these as 5G-EA and 5G-IA; TS 33.501 writes the same two algorithms as NEA2 and NIA2. They are AES in counter mode and AES-CMAC.
• NAS key set identifier - ngKSI: native, 2 — the context frame 7 announced.
• UE security capability - Replayed UE security capabilities, length 2. Bit-for-bit what the UE sent in the clear at frame 4. Replaying them is a bidding-down defense: the UE checks the echo against what it sent, and tampering in transit shows up as a mismatch.
• Additional 5G security information, element ID 0x36, length 1: Retransmission of initial NAS message request (RINMR): Requested, Horizontal derivation parameter (HDP): Not required.

That RINMR bit is the one to watch, and frame 11 is the only frame in the capture that sets it. It instructs the UE to put the entire initial NAS message — the complete Registration Request, not the cleartext skeleton — into the NAS message container of its Security Mode Complete. Hold that thought until the last section of this page.

Frame 12 — where the conversation goes dark

14.229 ms later. Security header type: Integrity protected and ciphered with new 5GS security context (4), message authentication code 0x97f62856, Sequence number: 0 — the uplink counter's own restart under the new context — and then one line where the body should be: Encrypted data.

This is the Security Mode Complete, and it is the first message in the capture whose NAS body cannot be read. Seventy-four octets, and none of them dissect.

The seal is worth drawing, because the mechanism is the same NEA2 block the radio layers run one level down, with a single input we do not have:

Four of the five inputs are within reach. The COUNT's low byte is the Sequence number printed in the envelope, the DIRECTION is just uplink or downlink, and BEARER and LENGTH are fixed by the message. The fifth — K_NASenc, the NAS encryption key derived in the core from K_AMF — is the one this capture never published. It is the identical block the radio runs on PDCP, where the published keys make the same operation reversible.

Frame 14 — a second Security Mode Command, and it is not a retransmission

88.769 ms later. Security header type: Integrity protected with new 5GS security context (3) again, message authentication code 0x7acf026e, Sequence number: 1. The downlink counter advanced from 0 to 1, so the AMF genuinely sent a second command rather than repeating the first.

Three things are identical to frame 11: 128-5G-EA2 / 128-5G-IA2, ngKSI native 2, and the same replayed 5G UE security capabilities. One thing is gone: there is no Additional 5G security information IE, so RINMR is no longer being requested. And two IEs are new:

• NAS security algorithms - Selected EPS NAS security algorithms, element ID 0x57: EPS encryption algorithm 128-EEA1 (1), EPS integrity algorithm 128-EIA1 (1).
• UE security capability - Replayed S1 UE security capabilities, element ID 0x19, length 4. Supported: EEA0, 128-EEA1, 128-EEA2, 128-EEA3, 128-EIA1, 128-EIA2, 128-EIA3, UEA0, UEA1, UIA1. Not supported: EEA4 to EEA7, EIA0, EIA4 to EIA6, EPS-UPIP, UEA2 to UEA7, and UIA2 to UIA7.

Both are about 4G. They pre-agree which EPS algorithms apply if this UE ever moves to S1 mode, so that an inter-system change does not have to renegotiate security mid-handover.

That is why the capture holds two Security Mode Commands and not one. Frame 11 had to go out before the AMF knew this UE's 4G capabilities: frame 4's cleartext UE security capability was length 2 — only 5G algorithm bits, no EPS or UMTS. So frame 11 could turn on 5G NAS security and select the 5G algorithms, but it had nothing to say about EPS, because it did not yet know what the UE supported there. Getting the full initial message back is exactly what its RINMR bit was for: frame 12 returned the complete Registration Request, and only then did the AMF hold the UE's S1 capabilities. Frame 14 is the AMF acting on them — a second command that selects the EPS algorithms and replays the S1 capabilities the first one could not. Which also makes these two IEs, as the last section argues, the closest this capture comes to reading a ciphered message.

Frame 15 — the second Security Mode Complete, also sealed. 11.229 ms later. Header type 4, message authentication code 0x104cf5ef, Sequence number: 1, Encrypted data. Ten octets against frame 12's seventy-four — consistent with a Security Mode Complete that has no initial NAS message to carry this time, because frame 14 did not ask for one.

From here to the end of this radio connection, no NAS body reads at all.

Frames 30 to 38 — steady state, and what an envelope still tells you

243.782 ms after frame 15, the security header type settles at Integrity protected and ciphered (2) and stays there for the rest of the connection. Type 2 rather than type 4 is itself information: the "new 5GS security context" marker belongs only to the messages that activate a context — the two command-and-complete pairs at frames 11/12 and 14/15 — so its disappearance says that context is now simply in use.

Four observations, none of which needed a key.

Counters are maintained per direction. Frames 30 and 31 both carry Sequence number: 2, and they are unrelated messages. NAS keeps a separate COUNT per direction, exactly as PDCP does on the radio side: downlink runs 0 (frame 11), 1 (frame 14), 2 (frame 30); uplink runs 0 (frame 12), 1 (frame 15), 2 (frame 31).

No gaps. Both chains advance by exactly one, with no reuse and no jump. A missing NAS message would show as a hole in one of those two sequences, and you would find it without decrypting anything.

Silence is not idleness. The 1.368993 s before frame 36 is the longest quiet stretch of the session so far, and the radio layers were busy through it: frames 33, 34, and 35 are Timing Advance commands, the cell keeping the UE's uplink aligned while NAS had nothing to say.

Frame 38 deserves one extra note. Its 122 sealed octets ride inside the RRC Reconfiguration that builds the data bearer — the frame Wireshark work-item 19757 was filed about. The RRC around it decodes completely, down to the RLC timers and the SDAP header switches. The NAS inside it does not decode at all. One frame, two security contexts, one key set published and one not. It is also the last NAS message of this radio connection.

The following packet tree shows the content of frame 38. It opens mac-nr one level; expand down, and the radio decode runs clean to the bottom — the pdcp-nr node even spells out the Access-Stratum cipher it just undid — and then the NAS list seals at Encrypted data:

Frame 38's full field tree — an RRC Reconfiguration that builds the data bearer while carrying 122 sealed NAS octets, with the mac-nr node opened one level. Follow mac-nr -> rlc-nr -> pdcp-nr -> nr-rrc -> DL-DCCH-Message -> rrcReconfiguration; the RRC opens all the way down, to the SDAP and PDCP settings under radioBearerConfig and the nested RLC and MAC config under nonCriticalExtension -> masterCellGroup, because the Access-Stratum keys deciphered PDCP — the pdcp-nr node even names that cipher, NEA2 / NIA2. But -> dedicatedNAS-MessageList -> Non-Access-Stratum 5GS -> Security protected NAS 5GS message stops at Encrypted data.

The later connections

Frame 133 — a new radio connection, the same NAS context. 13.629329 s after frame 38. In between, the radio side released the connection at frame 128 and set up a fresh one at frames 131 and 132 — and then re-ran the Access-Stratum Security Mode procedure from scratch immediately after this message, at frames 136 and 137.

Frame 133 is the new connection's RRC Setup Complete, and the Service Request rides inside it. The NAS message goes out before the new Access-Stratum context exists. It is integrity protected the moment it leaves the UE — by NAS keys that predate the radio connection carrying it — and the radio only gets around to securing itself afterward, at frames 136 and 137.

None of that touched NAS. This Service Request reads Security header type: Integrity protected (1), message authentication code 0xb98305d2, Sequence number: 4 — continuing straight on from frame 36's uplink 3 — under NAS key set identifier: 2, Type of security context flag (TSC): Native security context. Still, the context frames 7 to 14 were built.

The Access Stratum tore its context down and rebuilt it; the Non-Access Stratum did not notice, because its context has nothing to do with any particular radio connection. Radio keys are per-connection. NAS keys are per-registration.

The body reads in full:

• Service type: Mobile terminated services (2). The network reached for the UE; the UE is answering.
• 5GS mobile identity, length 7, Type of identity: 5G-S-TMSI (4): AMF Set ID: 1, AMF Pointer: 1, 5G-TMSI: 0xc2345678 — the same TMSI frame 4's 5G-GUTI carried.
• NAS message container, element ID 0x71, Length: 17, Encrypted data.

Header type 1 with a sealed container: frame 4's pattern exactly, on a different message. A Service Request is an initial NAS message too, so TS 24.501 has it sent integrity protected but not ciphered, with only the up-front IEs in the clear and everything else in the container. That is why this page can read its last message after six sealed ones — not because anything was decrypted, but because 3GPP requires the opening move of a NAS connection to be legible to a network that does not yet know which context to use.

One NAS message of the capture is not on this timeline at all. Frame 150 is another Service Request, 33.279932 s after frame 133 and therefore past the session extractor's 30-second idle timer, so it lands in a session of its own. It carries Sequence number: 5 under the same ngKSI 2 — the uplink NAS count still marching on, on the capture's third radio connection.

What frame 12 must have contained

Frame 15's ten octets already showed that a sealed message's size says something (a Security Mode Complete with nothing to carry is small).

Line up four facts, each read directly off the wire:

1. Frame 4's cleartext does not include the UE's 4G security capabilities. Its UE security capability IE is length 2, and those two octets hold 5G-EA and 5G-IA bits only — no EPS bits, no UMTS bits. Whatever the UE told the network about its S1 capabilities, it did not tell it there.
2. Frame 11 asks for the full message back. RINMR: Requested tells the UE to place the complete Registration Request into the NAS message container of its Security Mode Complete. It is the only frame in the capture that sets the bit.
3. Frame 12 is the Security Mode Complete, and it is sealed. Seventy-four octets of Encrypted data.
4. Frame 14 replays the UE's S1 capabilities and selects EPS algorithms. 128-EEA1, 128-EIA1, and a four-octet Replayed S1 UE security capabilities IE listing EEA, EIA, UEA, and UIA support. Searching the whole capture for EPS and UMTS algorithm bits finds them on exactly one frame — this one, where the AMF is echoing them back.

Now put them together. TS 33.501 §6.7.2 requires the capabilities an AMF replays to be the ones it received from the UE; that is the entire point of replaying them. So at frame 14 the AMF is quoting capability bits that never crossed this capture in the clear — one message after asking for the complete initial NAS message, and one message after receiving seventy-four ciphered octets it had specifically requested. Frame 4's sealed 61 octets and frame 12's sealed 74 are the only places in this trace those bits can have come from.

We cannot open frame 12. We can bound what was inside it, and we can watch the AMF act on it.

A takeaway from this analysis: a ciphered message still has observable consequences. Its direction, its length, its sequence number, and — most of all — what the next readable message assumes, all constrain what it can have been. Trace analysis on an encrypted control plane is mostly this: not decryption, but inference from the messages on either side.

💡 Want to see the bodies this page could only infer? A companion capture — a Motorola Edge 30 Pro, walked through frame by frame in The Life of a 5G Connection — runs with NAS ciphering off, so its whole core-network conversation reads end to end: Registration, PDU session establishment, and deregistration, including the Security Mode Complete and the steady-state exchanges that stay sealed here. Its per-session NAS-5GS diagram shows every message with a readable body. It is a different device and session, so the frame numbers do not line up with this one — read it for the shape of a complete, unciphered NAS conversation, not as a decryption of this trace.

Takeaways

1. NAS is the one box in that stack diagram whose peer is not the gNB. It runs UE to AMF, and the cell in between relays without reading. That is why NAS has its own security context, and why the published Access-Stratum keys do not open it.
2. The security header type tells you, before anything else, whether a body will read. Types 0, 1, and 3 are readable; types 2 and 4 are not. All five values TS 24.501 defines appear in this one session.
3. Ciphering is per message, not per connection. Frame 12 goes dark; frame 14 reads in full; frame 133 reads in full after six sealed messages. Initial NAS messages stay legible by design, because a network that does not yet know which context to use has to be able to read the opening move.
4. Even a readable NAS message can be half sealed. Frames 4 and 133 both carry a NAS message container — 61 octets and 17 octets of ciphertext — holding everything the cleartext-IE rule of TS 24.501 §4.4.6 keeps out of the clear.
5. Keep 5GMM and 5GSM apart. They are separate sublayers with separate message types and separate cause-code spaces. Every readable message in this capture is 5GMM; no 5GSM message is readable anywhere in it.
6. The NAS context outlives the radio context. Frame 133's uplink sequence number 4 follows frame 36's 3, under the same ngKSI, across a release, a fresh RRC setup, and a whole new Access-Stratum security activation.
7. A sealed message is not an opaque one. Direction, length, sequence continuity, and the behavior of the next readable message together said what frame 12 carried.

Where this sits in the stack

This page follows one layer of a much larger trace. The layers around it tell different parts of the same story:

• A 5G NR Attach on the Air Interface, Layer by Layer — the full walkthrough this article is a slice of: random access through to two mobile-terminated returns, all six layers on one timeline.
• NR-RRC: setup, security, reconfiguration, and release — the layer directly below, and the courier for every message on this page. Each NAS message here traveled as a dedicatedNAS-Message octet string that RRC carried and never read.
• PDCP-NR: sequence numbers, COUNT, and where ciphering happens — the other cipher. PDCP applies the Access-Stratum keys to the very same bytes NAS has already protected, which is why some frames on this page are encrypted twice.
• Decrypting a 5G NR radio capture — the key hierarchy behind both contexts, the recipe that opened the radio half of this trace, and why the core half stays shut.

Try it on your own capture

Every arrow in this diagram was decoded and captioned by VisualEther from a raw Wireshark PCAP — including the session split that lifted one protocol's conversation off a six-layer timeline. Point it at your own 5G, LTE, or IMS trace and read it the same way.