The Life of a 5G Connection, One Packet at a Time

Reading a real 5G NR air-interface capture from a Motorola Edge 30 Pro — from the first random-access message to a textbook retransmission storm at the very end. The trace was decoded and annotated with VisualEther, which turns a Wireshark 5G-NR PCAP into a sequence diagram.

💡 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 based on 69 frames over about 5.5 seconds, taken on the UE side of a Motorola Edge 30 Pro modem — it contains the entire life of a single radio connection.

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 couple of facts that hold for the whole capture:

• There is exactly one UE, identified by its cell radio identity C-RNTI 0x4601, on an FDD carrier.
• Access-Stratum (radio) security negotiated the NEA0 "null" cipher with NIA2 integrity — nothing is encrypted over the air, but messages are genuinely integrity-protected. Separately, the NAS layer (a different security context) also used null ciphering here, and that — with Wireshark told to decipher null-NAS — is why we can read the core-network message bodies. Both are test-rig choices; a commercial network would use NEA1/2/3, and those bodies would be opaque.

A primer on the 5G radio stack

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

Two ideas from this stack do all the heavy lifting in this capture:

Signaling bearers vs. data bearers. Control messages travel on a Signaling Radio Bearer (SRB) — here SRB1, which the trace calls "Bearer 1." User data travels on a Data Radio Bearer (DRB) — here "Bearer 4 / LCID 4," which doesn't exist yet at the start; watch it get built in Phase 3.

RLC Acknowledged Mode (RLC-AM). Both bearers run RLC-AM, a reliable-delivery protocol with its own ARQ. 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 isn't acknowledged before the t-PollRetransmit timer fires, RLC resends it. Hold onto that last sentence — it's the entire explanation for the drama at the end.

Follow one protocol at a time

You've just met the five layers. The interactive diagram stacks them all on a single timeline — true to how the connections really happen, but a lot to absorb at once. These per-session views slice the same capture the other way — one protocol, one bearer, from the first frame to the last — each one a session VisualEther extracted when it split the trace by protocol and bearer.

The flow at a glance

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

1. RRC connection setup (frames 1–3) — RRC Setup Request → Setup + Contention Resolution → Setup Complete, carrying the first NAS Registration Request.
2. Security + registration (frames 4–18) — Security Mode Command/Complete, then Registration Accept/Complete and a Configuration Update Command.
3. Open a data session (frames 19–31) — PDU Session Establishment Request, UE Capability exchange, and an RRC Reconfiguration that builds the DRB.
4. User-plane data (frames 32–52) — ciphered RLC-AM data on the DRB with increasing ACK_SN.
5. Teardown + detach (frames 53–57) — PDU Session Release and a UE-originating Deregistration Request.
6. Release + retransmission storm (frames 58–69) — one RRC Release, retransmitted 11 more times because the UE has already gone.

This one connection advances three state machines in parallel — the radio link (RRC) and the two NAS layers, 5GMM (mobility) and 5GSM (session):

Now the same story, frame by frame.

Phase 1 — Getting onto the cell (frames 1–3)

A 5G connection begins with the four-step random-access handshake. The first two steps — Msg1 (the UE's PRACH preamble) and Msg2 (the gNB's Random Access Response) — happen on the physical layer and aren't in this MAC-level capture. Our story opens at Msg3.

Frame 1 — RRC Setup Request (Msg3). The UE has no RRC identity on this cell yet, so it speaks on the Common Control Channel (CCCH, uplink LCID 52). It carries a 39-bit random value, 46c66e3536, for contention resolution and an establishment cause of mo-Data — mobile-originated data, i.e., "a user wants to get online." (The C-RNTI 0x4601 you see tagged on every frame is the temporary identity the gNB already handed out in the Random Access Response — the UE doesn't pick it here.)

Frame 2 — RRC Setup + Contention Resolution (Msg4). The gNB answers on the CCCH (LCID 0) and does two things in one frame:

1. A MAC UE Contention Resolution Identity control element echoes back the first 48 bits of the UE's Msg3 (its CCCH SDU). Seeing its own bytes reflected, the UE knows it won the random-access contest — rather than a different UE that picked the same preamble — and the temporary 0x4601 granted in the RAR becomes its C-RNTI.
2. The RRC payload installs SRB1 and the master cell-group configuration: SRB1 runs RLC-AM with t-PollRetransmit = 45 ms, along with the buffer-status and power-headroom reporting rules the UE will follow from now on.

On receiving this, the UE enters RRC_CONNECTED.

Frame 3 — RRC Setup Complete (Msg5). The UE confirms, now speaking on SRB1 (LCID 1, RLC-AM SN 0). Crucially, it piggybacks its first NAS message to the core inside the RRC container: a Registration Request. This is the hinge of the whole trace — from here, the radio conversation (RRC) and the core-network conversation (NAS) proceed in parallel, with every NAS message tunneled inside an RRC envelope.

Phase 2 — Security and registration (frames 4–18)

Frame 5 — Security Mode Command. The gNB switches on Access-Stratum security: cipher NEA0 (null) and integrity NIA2 (AES-CMAC). From the next uplink message onward, traffic is integrity-protected.

Frame 6 — Security Mode Complete. The UE confirms under the new keys. Security is now mutually active.

Frames 8–9 — Registration Accept / Complete. These arrive as DL/UL Information Transfer — RRC messages whose only job is to carry a NAS payload. The Registration Accept (frame 8) is the AMF's acknowledgment of UE's admission to the network; the Registration Complete (frame 9) is the UE's acknowledgment. The 5GMM registration procedure is now finished.

Frames 11–16 — Configuration Update Command (and a first taste of ARQ). The core pushes a Configuration Update Command (updated UE configuration — allowed network slices, network name, time, etc.). Here's a subtle point worth internalizing: frames 11, 12, 13, and 16 carry identical NAS bytes. They are not four different commands — they are RLC retransmissions of a single PDU whose acknowledgment the gNB hasn't yet seen. Frame 14 is likewise a retransmission of the UE's Registration Complete. This is RLC-AM doing exactly what it's built to do, and it's a gentle rehearsal for the much larger retransmission event in Phase 6.

The ARQ heartbeat. Threaded through this phase are RLC Status PDUs (frames 4, 7, 10, 15, 17). Each reports a cumulative ACK_SN on Bearer 1 (SRB1), and you can watch it increase in lockstep with the conversation:

Note frame 17 flows the other way: ARQ runs independently in each direction on the same bearer. One caveat these ACKs share: they confirm radio-link delivery to the gNB, not that the core has processed the message — that's a separate, invisible hop we can't see from a UE-side radio trace.

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

Everything so far was signaling. Now the UE asks for an actual data path.

Frame 19 — PDU Session Establishment Request. A NAS 5GSM message (wrapped in UL NAS Transport) asking, via the AMF, for the SMF to set up an IP session. This request is what will cause a Data Radio Bearer to be built — watch for its Accept in frame 26.

Frames 21–24 — UE Capability exchange. Before configuring the DRB, the gNB asks what the UE supports (UE Capability Enquiry, frame 21) and the UE answers (UE Capability Information, frame 24) with its bands, MIMO layers, modulation, and — notably — Power Class 2 (pc2) on the applicable bands (nominally 26 dBm in FR1, per band/band-combination — not a blanket device rating). File that away for the next frame.

Frame 26 — RRC Reconfiguration: the session is accepted, and the DRB is born. The pivotal frame of the phase, doing double duty. Tucked inside the RRC message is a NAS PDU Session Establishment Accept — the SMF's "yes" to the frame-19 request — and the radio config that maps PDU Session 1's default QoS flow (QFI 1) onto a brand-new DRB (drb-Identity 1, carried on LCID 4 — the dissector's "Bearer 4"):

• default DRB, no SDAP header,
• PDCP 12-bit SN in both directions, ROHC off,
• RLC-AM with t-PollRetransmit = 50 ms, pollPDU = 16, pollByte = 6500 kB,
• p-NR-FR1 = 10 dBm — the configured maximum uplink power on FR1 (the same cap was already present back in the frame-2 cell-group config).

That last value is worth a raised eyebrow: 10 dBm is well below the UE's advertised PC2 capability — a lot of uplink headroom the network is choosing not to use. The trace doesn't say why (a lab rig is the likely reason), but on a real network it's exactly the setting to check first if you were chasing an uplink-coverage or throughput complaint.

Frame 30 — RRC Reconfiguration Complete. The UE applies the new config. The data radio bearer is now live.

Phase 4 — Moving user data (frames 32–52)

With the DRB up, user traffic flows as RLC-AM Data PDUs on Bearer 4. The PDCP payloads are ciphered (opaque to us), but the RLC framing tells the whole delivery story. Two fields carry the plot:

• SI (Segmentation Info) — is this PDU a whole SDU, or a first/middle/last segment? Large packets get split and reassembled using a Segment Offset (SO).
• The poll bit — when set, it demands an immediate Status PDU from the receiver.

The transfer runs cleanly: SNs 0 through 15, several of them segmented (e.g. SN 2 reassembled from 2 fragments at SO = 394; SN 9 and SN 12 similar), each poll promptly answered by a gNB Status PDU. The DRB's ACK_SN increases 3 → 6 → 9 → 10 → 12 → 14 → 16, and — importantly — not a single NACK appears anywhere. This is what healthy user-plane delivery looks like.

You'll also spot ~1–2 second gaps between some bursts: the traffic is bursty, not a saturating stream, and in the quiet moments the UE reports empty buffers via Long BSR (all Logical Channel Groups "Not Present").

Frame 52 — the last data ACK. ACK_SN = 16 acknowledges everything through SN 15. The DRB has done its job; the conversation now returns to SRB1 to shut everything down.

Phase 5 — Tearing it down (frames 53–57)

A graceful teardown, in three NAS messages:

1. Frame 53 — PDU Session Release Request (UE → core), cause Regular deactivation. The UE asks to close the data session it opened in Phase 3.
2. Frame 55 — PDU Session Release Command (core → UE), same cause. The network confirms; the DRB from frame 26 is gone.
3. Frame 56 — Deregistration Request (UE-originating). The UE detaches from the network entirely.

This is the most important frame to remember. Frame 56 is the last message the UE ever sends. Frame 57 is the gNB's own RLC Status PDU (ACK_SN = 8), sent down to acknowledge that the Deregistration Request arrived over the air. It's the last exchange with a UE that's about to go silent — everything after this point is the network talking to a device that has already left.

Phase 6 — The release, and the retransmission storm (frames 58–69)

Frame 58 — RRC Release (the real one). The gNB sends a command to return the UE to RRC_IDLE (there's no suspendConfig, so it's IDLE, not INACTIVE). It travels on SRB1 as PDCP SN = 6, COUNT = 6, with integrity tag MAC-I = 0xeacb8577, and — critically — the RLC poll bit is set, so the gNB expects a Status PDU confirming delivery.

That Status PDU will never come. The UE deregistered in frame 56 and is no longer listening on 0x4601.

Frames 59–69 — the same release, eleven more times. Wireshark flags each of these as RLC retx (dup PDCP SN 6). They are not new releases — they are byte-for-byte retransmissions of frame 58's PDU (identical PDCP SN 6, identical MAC-I 0xeacb8577), fired because t-PollRetransmit keeps expiring with no ACK. Check the timestamps, and you'll see them spaced ~46 ms apart — precisely the poll-retransmit timer from the bearer configuration.

Frame 58   RRC Release            PDCP SN=6   <- genuine
Frame 59   RRC Release (retx 1)   PDCP SN=6   dup
Frame 60   RRC Release (retx 2)   PDCP SN=6   dup
   ...          ...                  ...
Frame 69   RRC Release (retx 11)  PDCP SN=6   dup   <- capture ends

How to read it: almost certainly harmless. The UE sent a switch-off deregistration in frame 56, so it has gone — and RLC-AM did exactly what it's designed to do: retransmit a polled, unacknowledged PDU until the ACK arrives or maxRetxThreshold (here t8) is reached. Strictly, a gNB-side radio trace can't prove the UE received nothing — only an NGAP or UE-side trace could — but the switch-off makes an absent UE the obvious cause. The signature that it's one message, not twelve, is that every copy carries the same PDCP SN and the same MAC-I.

The diagnostic lesson is about context. Twelve identical RRC Releases right after a deregistration are the expected tail of a normal shutdown. The very same pattern appearing mid-session on a UE you believe is still connected means something quite different — a UE that has dropped off the radio or a broken downlink — and is worth investigating.

Takeaways

1. A connection has a sequence. Setup → security → registration → session → data → teardown → release.
2. Signaling and data live on separate bearers. SRB1 ("Bearer 1") carried every control message; the DRB ("Bearer 4") carried user data and didn't even exist until frame 26.
3. NAS rides inside RRC. Registration, PDU sessions, and deregistration are core-network procedures that are tunneled transparently via RRC DL/UL Information Transfer.
4. RLC-AM is the reliability workhorse. Cumulative ACK_SN, poll bits, and timer-driven retransmissions are normal. Duplicate SNs mean retransmission, not new messages.
5. Context decides the diagnosis. The final retransmission storm is almost certainly harmless because it follows a switch-off deregistration. The same packets in a different place would be a red flag.

Try it on your own capture

Every arrow in this walkthrough was decoded and captioned by VisualEther from a raw Wireshark PCAP — no manual diagramming. Point it at your own 5G, LTE, or IMS trace and read it the same way.