A 5G NR Attach on the Air Interface, Layer by Layer

Reading a real, NEA2-ciphered 5G NR radio capture — from the first random-access response to two mobile-terminated returns at the end. The encrypted trace was decoded and annotated with VisualEther after applying the UE keys included in the Wireshark issue. The keys decipher the radio stack all the way down to the SDAP user plane.

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

Overview

The flow is 151 frames over about 49 seconds, captured at the MAC layer of a single 5G NR cell. One full connection that attaches, secures itself, opens a data bearer, moves user-plane traffic, and is released — followed by two shorter connections where the network reaches back for the UE.

Two facts shape everything you will read:

• The capture is genuinely encrypted. Access-Stratum (radio) security here uses NEA2 (AES) ciphering with NIA2 (AES-CMAC) integrity — a real cipher, not the NEA0 "null" placeholder you often see in lab traces. Nothing below the PDCP layer is readable until you feed Wireshark the UE keys. Those keys are published in Wireshark work-item 19757, and applying them is what lets us read the RRC Reconfiguration and the entire user plane.
• There are two independent security layers. The core network (NAS) and the radio network (AS) each run their own Security Mode procedure with their own keys. The published keys are the AS/PDCP keys — so the radio layers open up, but the NAS message bodies, ciphered separately, stay sealed.

Every step is visible in the packets. In the interactive viewer or the HTML sequence diagram above, click any message to open its parameter details and the complete Wireshark field tree for that frame.

A primer on the 5G radio stack

Before the walkthrough, here is the layer cake every frame rides on. Reading top to bottom is reading a message from application intent down to radio symbols.

The same layers run on both ends of the link, and each one talks to its peer on the other side — MAC to MAC, RLC to RLC, and so on up the stack. The control plane and the user plane share the whole PHY / MAC / RLC / PDCP foundation and differ only at the top: RRC and NAS for signaling, SDAP for data. Each plane also reaches a different endpoint in the core — the NAS signaling terminates at the AMF (tunneled transparently through the gNB), while the user data continues past the gNB to the UPF:

Key ideas from this stack:

Signaling bearers vs. data bearers. Control messages travel on a Signaling Radio Bearer (SRB) — here SRB1, which the trace calls "Bearer 1," and later SRB2. User data travels on a Data Radio Bearer (DRB) — here DRB 1 on LCID 4, which does not exist at the start; watch it get built when the data session opens.

RLC Acknowledged Mode (RLC-AM). Both SRBs and the DRB run RLC-AM, a reliable-delivery protocol with its own ARQ (Automatic Repeat reQuest). The sender numbers each PDU with a Sequence Number (SN); the receiver periodically returns a Status PDU carrying a cumulative ACK_SN ("I have everything below this number"). A sender can set a poll bit to demand an immediate Status PDU, and if a polled PDU is not acknowledged before the t-PollRetransmit timer fires, RLC resends it.

SDAP and the QoS Flow Identifier. SDAP (Service Data Adaptation Protocol, TS 37.324) is the thin layer new to 5G that sits above PDCP on a data bearer. Its one-byte header tags each user packet with a QFI — the QoS Flow Identifier — so the network can hold a packet to the right quality-of-service treatment. In this trace, the uplink SDAP header is present, and every user packet is stamped QFI 2.

Two security contexts. 5G separates core security (NAS, negotiated with the AMF) from radio security (AS, negotiated with the gNB). Each has its own Security Mode Command / Complete handshake, its own algorithms, and its own keys. This is the single most important idea in this capture, so it gets its own primer below.

Follow one protocol at a time

You have just met six layers. The interactive diagram stacks them all on one timeline — true to how the connection really happens, but a lot to absorb at once. Six companion walkthroughs slice the same capture the other way — one protocol, from the first frame to the last — each built from a session VisualEther extracted when it split the trace by protocol and bearer. They are laid out below from the bottom of the stack upward, so you can climb them in order or take the one layer you came for.

The three security contexts

All of this depends on the capture being readable, and it very nearly isn't. Three independent security contexts wrap this traffic: NAS, negotiated between the UE and the AMF; AS, negotiated between the UE and the gNB; and the IPsec that protects IMS signaling inside the user plane. The keys published with the Wireshark issue are Access-Stratum keys, so they open the AS context at PDCP and nothing else. The ciphered NAS bodies stay opaque, and so does anything behind ESP. A seventh companion works through all three, and through what the AS keys do expose once PDCP gives up its payload: an IPv6 user plane with a SIP registration running over it.

The flow at a glance

The capture unfolds in six phases. Each is a section below; the interactive diagram shows every arrow.

1. Onto the cell (frames 1–4) — Random Access Response, RRC Setup Request → Setup + Contention Resolution → Setup Complete, carrying the first NAS Registration Request.
2. Authenticate and secure (frames 5–18) — Authentication, then two security bring-ups: the NAS (core) Security Mode procedure, run twice, and the AS (radio) Security Mode Command that turns on NEA2/NIA2.
3. Open a data session (frames 19–39) — UE Capability exchange and an RRC Reconfiguration that builds the SDAP data bearer (DRB 1, QFI 2).
4. User-plane data (frames 40–127) — deciphered SDAP traffic on the DRB with a climbing ACK_SN and clean RLC-AM segmentation.
5. Release (frames 128–129) — one RRC Release, retransmitted once when the UE does not answer.
6. Mobile-terminated returns (frames 130–151) — two fresh connections triggered by mt-Access, each carrying a NAS Service Request.

The one long connection drives the radio state machine from idle to connected and back:

On the core-network side, the first connection starts a registration, but we never see it finish — not because it failed, but because the messages that would confirm it are ciphered at the NAS layer:

Now the same story, frame by frame.

Phase 1 — Onto the cell (frames 1–4)

A 5G connection begins with the four-step random-access handshake. Step 1 (the UE's PRACH preamble) is a physical-layer event and is not in this MAC-level capture; our story opens at Msg2.

Frame 1 — Random Access Response (Msg2). The gNB answers a preamble with a Temporary C-RNTI (0x1001), a Timing Advance, and the uplink grant the UE will use for Msg3. It is addressed by RA-RNTI 0x0500 — the identity derived from when the preamble arrived, since the gNB does not yet know who sent it.

Frame 2 — RRC Setup Request (Msg3). The UE asks to open an RRC connection. Having no dedicated identity yet, it speaks on the Common Control Channel (CCCH, uplink LCID 52) and includes a random value for contention resolution. Its establishment cause is mo-Signalling — mobile-originated signaling, meaning "a UE wants to talk to the core," as opposed to mo-Data for bulk traffic.

Frame 3 — RRC Setup + Contention Resolution (Msg4). The gNB answers on the CCCH and does two jobs in one frame. A MAC UE Contention Resolution Identity control element (LCID 62) echoes the UE's Msg3 back, so the UE — seeing its own bytes reflected — knows it won the random-access contest rather than a different UE that picked the same preamble. The RRC payload then installs SRB1 and the master cell-group configuration (the buffer-status and power-headroom reporting rules the UE follows from now on). On receipt, the UE enters RRC_CONNECTED.

Frame 4 — RRC Setup Complete (Msg5). The UE confirms on SRB1 (LCID 1) and piggybacks its first NAS message — a Registration Request — to the core inside the RRC container. This is the hinge of the whole trace: from here the radio conversation (RRC) and the core-network conversation (NAS) proceed in parallel, every NAS message tunneled inside an RRC envelope. One detail worth noting: the Registration Request arrives integrity-protected (NAS security-header type 1), which means the UE already holds a NAS security context from an earlier visit — this is a returning UE, not a first-ever power-on.

Phase 2 — Authenticate and secure (frames 5–18)

This phase is the heart of the capture, and the place where the two-security-layer idea becomes concrete.

Frames 7 and 9 — Authentication. The AMF challenges the UE (Authentication Request, carried as an RRC DL Information Transfer) and the UE answers (Authentication Response). Both are NAS plaintext — the fresh authentication run has not yet switched on NAS ciphering. A correct response lets the network trust the UE and derive fresh keys.

Frames 11–16 — NAS (core) security, run twice. The AMF sends a NAS Security Mode Command (frame 11), and the UE replies with a Security Mode Complete (frame 12). Then it happens again — a second Security Mode Command (frame 14) and Complete (frame 15). The command messages carry NAS security-header type 3 ("integrity-protected with a new NAS security context"); the completes come back as type 4 ("integrity-protected and ciphered"). That type-4 marking is the moment NAS ciphering switches on: from frame 12 onward, the NAS message bodies are encrypted with keys we do not have, so they read as sealed envelopes. Running the procedure twice re-keys the NAS context — on a lab rig the likely reason is a deliberate re-establishment rather than a fault, and the ordering (a Complete arrives before the second Command) confirms these are two genuine procedures, not a retransmission.

Frames 17–18 — AS (radio) security. Now the other Security Mode procedure. The gNB's RRC Security Mode Command selects ciphering NEA2 (AES) and integrity NIA2 (AES-CMAC), and the UE confirms. From here, PDCP on every bearer is ciphered and integrity-protected. These are precisely the keys published in the Wireshark issue — the ones that, fed into Wireshark, decipher the RRC Reconfiguration and the whole user plane you are about to see. Note the symmetry: two Security Mode Commands, two Completes, two contexts — one for the core, one for the radio.

Threaded through this phase are RLC-AM Status PDUs on SRB1 (frames 5, 8, 10, 13, 16), each reporting a cumulative ACK_SN that increases 1 → 2 → 3 → 4 in lockstep with the conversation. They confirm delivery over the air to the gNB.

Phase 3 — Opening a data session (frames 19–39)

Everything so far was signaling. Now the UE and gNB build a path for user data.

Frames 20–23 — UE Capability exchange. The gNB asks what the UE supports (UE Capability Enquiry) and the UE answers (UE Capability Information) with its bands, MIMO layers, modulation, and ROHC profiles. Among the R16 features it advertises is loggedMeasurements-r16 support — the UE can perform logged Minimization-of-Drive-Tests measurements — though the network never configures an actual MDT session in this trace. The capability report is large enough to be segmented across RLC-AM PDUs (frame 22 is a middle segment), then reassembled.

Frame 38 — RRC Reconfiguration: the data bearer is born. The pivotal frame of the phase. Inside one RRC message, the gNB adds SRB2 and a data radio bearer, DRB 1 on LCID 4, and maps a PDU session's QoS flow onto it:

• an sdap-Config with the downlink SDAP header absent and the uplink SDAP header present, default DRB, QFI 2,
• PDCP with an 18-bit sequence number in both directions, ROHC off,
• RLC-AM with t-PollRetransmit = 80 ms, pollPDU = 32768, pollByte = 750 kB.

This frame is the one Wireshark work-item 19757 was filed about: without the UE keys, the reconfiguration is an opaque PDCP blob; with them, it decodes cleanly. It also carries a piggybacked NAS message — but that NAS PDU is ciphered at the NAS layer (header type 2), so its contents stay sealed even though the RRC around it is now perfectly readable. That contrast, in a single frame, is the two-security-layer story in miniature.

Here is that frame's complete decoded field tree. Expand any node to open it:

Frame 38, gNB → UE. The RRC layer opens because the UE keys deciphered PDCP; the NAS payload near the bottom stays encrypted because its keys are a separate context.

Frame 39 — RRC Reconfiguration Complete. The UE applies the new configuration. DRB 1 is live.

Phase 4 — Moving user data (frames 40–127)

With DRB 1 up, user traffic flows as SDAP Data PDUs on the bearer. Because the AS keys deciphered PDCP, each uplink PDU shows its SDAP header stamped QFI 2 — and everything beneath it is now in the clear too. Two RLC fields carry the delivery story:

• SI (Segmentation Info) — is this PDU a whole SDU, or a first/middle/last segment? Larger packets are split and reassembled using a Segment Offset (SO). Frames 109–111 show this cleanly: two SDUs each arrive in two fragments and are reassembled.
• The poll bit — when set, it demands an immediate Status PDU from the receiver.

The transfer runs cleanly. The DRB's ACK_SN climbs steadily to 18, and — importantly — not a single NACK appears anywhere. Between bursts you will see MAC Timing Advance Commands and Short Buffer Status Reports: routine link and scheduling upkeep while the user-plane queue ebbs and flows.

What is actually inside that QFI-2 user plane — IPv6 bring-up, and the beginnings of an IMS session protected by IPsec — is a story of its own, told in the companion decryption walkthrough. Here it is enough to see the shape of healthy user-plane delivery on a deciphered bearer.

Phase 5 — Releasing the connection (frames 128–129)

Frame 128 — RRC Release. The gNB sends the UE back to RRC_IDLE (there is no suspendConfig, so it is a full release, not the suspended RRC_INACTIVE state). It travels on SRB1 as PDCP SN 7, COUNT 7, with integrity tag MAC-I = 0xa48652fc, and the RLC poll bit set — so the gNB expects a Status PDU confirming delivery.

Frame 129 — the same release again. Wireshark flags this as a duplicate: identical PDCP SN 7, identical MAC-I. It is not a second release — it is one retransmission of frame 128, fired because t-PollRetransmit expired with no acknowledgment. With no NACK anywhere in the capture, this is a plain poll-retransmit resend. The identical SN and MAC-I are the signature that it is one message resent, not a new command — the same reasoning you would use to tell a harmless retransmission tail from a real downlink problem.

Phase 6 — Mobile-terminated returns (frames 130–151)

After the release, the capture shows the network reaching back for the UE — twice.

Frames 130–146 — connection 2. A fresh random-access handshake opens a new RRC connection, but this time the RRC Setup Request carries establishment cause mt-Access — mobile-terminated access. Something in the network (an incoming call, an SMS, downlink data) is trying to reach the UE. The UE responds by piggybacking a NAS Service Request (frame 133) — the procedure a UE in idle mode uses to re-enter connected mode and resume its sessions. AS security is then re-established from scratch (frame 136, NEA2/NIA2 again): every RRC connection negotiates its own radio keys. A brief signaling exchange follows, ending in another single poll-retransmit (frame 146).

Frames 147–151 — connection 3. After a ~32-second gap, the pattern repeats: random access, an mt-Access RRC Setup, and a NAS Service Request (frame 150). The capture ends here, mid-setup, before this third connection re-establishes security.

Takeaways

1. A connection has a sequence. Random access → RRC setup → authenticate → secure → open a bearer → move data → release.
2. 5G secures the core and the radio separately. NAS and AS each run their own Security Mode handshake with their own keys. The published keys here are the AS/PDCP keys — which is exactly why the radio layers and the SDAP user plane open up while the NAS bodies stay encrypted.
3. The keys are what make the trace legible. With NEA2 ciphering, the RRC Reconfiguration and everything on the DRB are opaque until the UE keys are applied.
4. SDAP tags every user packet with a QFI. On a data bearer, the SDAP header carries the QoS Flow Identifier (QFI 2 here) that ties the packet to its QoS treatment — the 5G-new layer that sits just above PDCP.
5. RLC-AM reliability is normal, and context decides the diagnosis. Cumulative ACK_SN, poll bits, and timer-driven retransmissions are healthy behavior. A duplicate SN with an identical MAC-I means retransmission, not a new message.
6. Establishment cause tells you who started it. mo-Signalling opened the first connection; mt-Access opened the last two — the difference between the UE reaching out and the network reaching in.

Try it on your own capture

Every arrow in this walkthrough was decoded and captioned by VisualEther from a raw Wireshark PCAP — including the decryption step that turned an opaque NEA2 trace into a readable one. Point it at your own 5G, LTE, or IMS capture and read it the same way.