DEV Community: Sandeep Ahluwalia

The Xn procedure that fetches a sleeping UE from another gNB

Sandeep Ahluwalia — Thu, 30 Jul 2026 15:08:46 +0000

5G gave the RRC state machine a third state. Between IDLE and CONNECTED sits RRC_INACTIVE: a UE with no traffic gets suspended rather than released, the gNB keeps its access-stratum context, and the UE walks away with an I-RNTI — a token naming that stored context.

Then mobility happens. The UE wakes up with data to send, but at a cell served by a different gNB. The new node has no idea who this UE is. Resolving that is a small, tidy Xn procedure called Retrieve UE Context, and a five-frame XnAP-over-SCTP capture holds all of it.

What the capture shows

The interface comes up first (frames 1-2). Xn Setup Request and Response, non-UE-associated, each gNB advertising its served-cell configuration — PLMN, gNB ID, NR-PCI, TAC, slice. Nothing UE-specific can travel until this is done.

The I-RNTI is a pointer; the shortResumeMAC-I is a signature (frame 3). The UE's RRCResumeRequest carried both. The I-RNTI tells the target gNB which node holds the context and which context it is. The UE computes shortResumeMAC-I from its stored keys, so the anchor can verify the resume request is genuine before releasing anything.

Resuming forward-secures the keys (frame 4). The context comes back with a NextHopChainingCount (NCC = 2) and a 32-byte K_NG-RAN* next-hop key. The target derives fresh AS keys from those — vertical key derivation — so the new cell cannot read traffic the UE exchanged before the resume. Riding along: UE-AMBR, and one PDU session with its QoS flow.

Both ends get cross-referenced (frame 5). The Confirm quotes both UE XnAP IDs, binding the two nodes' identifiers to the same UE-associated Xn connection.

And the distinction that trips people up: this is not Handover Preparation. Handover is source-driven — the serving gNB decides to move a connected UE and pushes the context to a target it chose. Retrieve UE Context is target-driven — the UE arrives, asks to resume, and the new gNB pulls. Same outcome, opposite trigger.

One caveat the write-up states plainly: it's a single-machine loopback capture with some trivial field values, so read it for the shape of the procedure rather than for realistic numbers.

Full walk-through, frame by frame: https://www.eventhelix.com/5G/xn-ue-context-retrieval/ — every field value, the decoded packet trees, and where the Xn leg sits in the end-to-end resume across Uu and NG.

The sequence diagrams were generated from the PCAP with VisualEther, which turns a Wireshark capture into an annotated sequence diagram; there's a free Community edition, and the interactive diagram for this capture opens each message's full Wireshark field tree on click.

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

Sandeep Ahluwalia — Wed, 22 Jul 2026 23:02:32 +0000

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.

Explore the annotated diagram — click any message to open its complete Wireshark field tree:

Interactive viewer (best on Chrome, Edge, or Firefox)
HTML sequence diagram (works in every browser)
Printable PDF

Tip: open one of the diagrams in a second window and read it side by side with this walkthrough, so the captions stay in view.

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.

Layer	Job in one line	What you'll see in the trace
NAS / 5GMM & 5GSM	UE ↔ core-network signaling (registration, sessions)	Registration Request, PDU Session Establishment, Deregistration
RRC	UE ↔ gNB radio-connection control	RRC Setup, Security Mode Command, Reconfiguration, Release
PDCP	Ciphering, integrity, sequence numbering	PDCP SN / COUNT, MAC-I integrity tag
RLC	Reliable delivery (ARQ), segmentation	RLC-AM Data & Status PDUs, ACK_SN, poll bit
MAC	Scheduling, multiplexing, control elements	LCID, Contention Resolution, BSR, PHR

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.

NAS-5GS — the core-network conversation end-to-end: Registration → PDU session → deregistration.
RRC — every message on the signaling radio connection, from Setup through Release.
PDCP · SRB1 (Bearer 1) — PDCP SN / COUNT on the signaling bearer.
PDCP · DRB (Bearer 4) — PDCP SN / COUNT on the data bearer.
RLC-AM · SRB1 (Bearer 1) — ACK_SN, poll bit, and the Phase-2 / Phase-6 retransmissions.
RLC-AM · DRB (Bearer 4) — segmentation and Phase 4's clean data transfer.
MAC (C-RNTI 0x4601) — contention resolution, LCID multiplexing, BSR, and PHR.

The flow at a glance

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

RRC connection setup (frames 1–3) — RRC Setup Request → Setup + Contention Resolution → Setup Complete, carrying the first NAS Registration Request.
Security + registration (frames 4–18) — Security Mode Command/Complete, then Registration Accept/Complete and a Configuration Update Command.
Open a data session (frames 19–31) — PDU Session Establishment Request, UE Capability exchange, and an RRC Reconfiguration that builds the DRB.
User-plane data (frames 32–52) — ciphered RLC-AM data on the DRB with increasing ACK_SN.
Teardown + detach (frames 53–57) — PDU Session Release and a UE-originating Deregistration Request.
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):

The RRC state journey: IDLE to CONNECTED and back to IDLE.

5GMM (mobility) state journey, UE side: Registration Request rides frame 3 and Registration Accept frame 8; the switch-off Deregistration Request is frame 56, for which no Accept is awaited.

5GSM (session) state journey for the single PDU session, UE side: Establishment Request/Accept are frames 19/26; the UE-requested release runs across frames 53–55.

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:

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

Frame	Direction	`ACK_SN`	Confirms
4	gNB → UE	1	RRC Setup Complete (SN 0) received
7	gNB → UE	2	Security Mode Complete (SN 1) received
10	gNB → UE	3	Registration Complete (SN 2) received
17	UE → gNB	3	UE confirming the gNB's downlink

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:

Frame 53 — PDU Session Release Request (UE → core), cause Regular deactivation. The UE asks to close the data session it opened in Phase 3.
Frame 55 — PDU Session Release Command (core → UE), same cause. The network confirms; the DRB from frame 26 is gone.
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

A connection has a sequence. Setup → security → registration → session → data → teardown → release.
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.
NAS rides inside RRC. Registration, PDU sessions, and deregistration are core-network procedures that are tunneled transparently via RRC DL/UL Information Transfer.
RLC-AM is the reliability workhorse. Cumulative ACK_SN, poll bits, and timer-driven retransmissions are normal. Duplicate SNs mean retransmission, not new messages.
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. The full interactive walkthrough is on eventhelix.com.

Turn Wireshark PCAPs into sequence diagrams — and let an AI read them

Sandeep Ahluwalia — Tue, 14 Jul 2026 13:40:00 +0000

For years I built satellite networks with an LTE air interface. Every time I opened a capture in Wireshark, I did the same thing: scroll thousands of packets across MAC, RLC, PDCP, RRC, and S1AP — then redraw the call flow on a whiteboard so the rest of the team could follow it.

Wireshark is unbeatable at showing you every packet. But it shows you a flat list, not the conversation — who said what to whom, in what order. That sequence diagram lives in your head, and you rebuild it by hand every time.

So I built VisualEther to draw the conversation straight from the capture.

What it does

VisualEther reads a PCAP/PCAPNG and renders it as a readable sequence diagram. It's built on tshark, so anything Wireshark can dissect, it can diagram — 5G, LTE, IMS, SIP, BGP, and dozens of other protocols out of the box. Extraction is driven by an XML "field extraction template" (FXT) that maps protocol fields to messages and sessions.

The AI part: the context-budget problem

Here's the wall I hit when I tried feeding captures to an LLM directly: a PCAP blows the context window before you finish pasting. Thousands of packets, dozens of fields per layer — megabytes of noise, and the model drowns.

So VisualEther ships an MCP server. Instead of raw packets, it extracts only the messages and fields that matter, so the agent reads kilobytes of structured data, not megabytes of logs. It then runs an author → debug → verify loop and cites frame numbers as evidence.

A concrete example

One worked case: an R16 gNB capture with the 5G user plane encrypted. With Claude Code driving the MCP server, VisualEther decrypted the PDCP (NEA2) down to the SIP REGISTER, then rebuilt the uplink BSR→grant→SDAP scheduling loop from PUSCH occupancy alone — because the grants were never in the capture. Every claim is anchored to a specific frame number. Full walk-through.

Triage and CI

Beyond a single diagram, the browser-based Session Navigator groups every session in a capture by outcome — pass, fail, late, timeout — so broken flows surface first. And because it emits machine-readable output (NDJSON / Markdown / HTML), you can wire it into CI to generate a diagram for every capture, unattended.

Try it

VisualEther is a commercial tool with a free tier:

Community (free, no license): PDF sequence diagrams, up to 10 pages / 10 entities.
Professional / Server (45-day trial): MCP/AI analysis, session triage, larger diagrams.

Runs on Windows, Linux, and macOS (Apple Silicon), installable via winget / Homebrew / apt / dnf. Needs tshark 4.6+.

Free download: https://www.eventhelix.com/visualether/download
Live, interactive output (no install): https://diagrams.eventhelix.com/visualether/5g-nr-radio/

I'd love feedback from anyone who lives in Wireshark — especially on the FXT format and the MCP tool design. Ask me anything.