What is in a 5G NR gNB-side mac-nr pcap that a UE-side capture does not show?

A gNB-side mac-nr capture sees every UE on the cell, every C-RNTI assignment, both directions of the air interface, the gNB's RLC AM state for each bearer, and the exact gNB-driven RRC Release pattern (including the RLC poll-retransmit storm when a UE has vanished). A UE-side capture only sees its own RNTI and only the half of the conversation that survived the radio link, so UE-side RLF is invisible as silence rather than as the gNB's retransmit ladder.

Why does Wireshark fail to dissect gnb_mac.pcap by default?

The pcap is recorded as DLT_USER (linktype 147–252) — typically DLT=149 for srsRAN-style captures that wrap MAC-NR PDUs inside a synthetic UDP header (src=0xbeef, dst=0xdead). Without a user_dlts mapping, tshark can only see the fake UDP and stops there. The fix is to map DLT=149 to udp and enable the mac_nr_udp / rlc_nr_udp / pdcp_nr_udp heuristic dissectors so they pick up the magic in the UDP payload.

Are six RRC Release frames in a row a bug?

No — in this capture they are two distinct release events (one per UE) each retransmitted three times because the UE has already moved to RRC_IDLE and stops responding to the RLC poll bit. This is RLC AM doing exactly what TS 38.322 §5.3.3 says it must do until maxRetxThreshold. The diagnostic question is not 'is the retransmit storm a bug' but 'why is the UE gone?' — that needs a cross-layer walk through RRC, PDCP sequence numbers and the time gap between the last UE uplink and the gNB's Release.

How do you tell an abnormal RRC Release from a normal switch-off deregistration?

Three signals visible at MAC/RLC/RRC: (1) the time gap between the last UE uplink and the gNB-issued Release — milliseconds for a graceful release driven by NGAP UE Context Release Command, seconds for an inactivity / RLF cleanup; (2) whether the previous DL PDU was acknowledged — a clean ACK chain points to a normal release, a stranded SN points to a lost UE; (3) the presence of a NAS Deregistration Request in the seconds before the Release. In this capture UE-2 shows all three normal-release signals; UE-1 shows none and is therefore abnormal.

What scheduler-side state survives across two UEs on the same gNB cell?

Per-UE PDCP and RLC state is keyed on the C-RNTI and the (UE, bearer) tuple, so UE-2's PDCP SNs start at 0 on its own SRB1 even while UE-1's stale Release retransmissions are still on air on a different C-RNTI. The MAC scheduler reuses the same TDD/FDD framing, periodicBSR=sf10 cadence, and CORESET / TAG identity values from RRC Setup — both UEs see an identical SRB1 template. That is also why UE-1's third Release retransmission lands inside UE-2's session timeline without confusing PDCP-level analysis.

Where does the gnb_mac.pcap sample used in this case study come from?

The sample is from a Wireshark merge request that proposed a new mac-nr test pcap. We use it here as a realistic gNB-side capture covering two consecutive UE sessions — initial registration of one UE and a service-request / PDU-session-establishment / switch-off-deregistration cycle of another — on a single 5G NR Standalone cell. Direct link to the Wireshark merge request is provided at the end of this page.

5G NR gNB MAC pcap Analysis: Two UEs, Registration vs Service Request, Cross-Layer RRC Release Triage

01UserInitial request

Please generate explore and sessions level diagrams from gnb_mac.pcap.

02ClaudeCapture detection & rendering

analyze_capture initially failed to detect any protocol — the pcap is recorded as DLT_USER 149 (srsRAN-style synthetic UDP wrapper, src=0xbeef, dst=0xdead) and tshark needs a user_dlts mapping plus the mac_nr_udp / rlc_nr_udp / pdcp_nr_udp heuristic dissectors enabled before it can see anything above the fake UDP header.

Re-ran with the right flags. Detected NAS-5GS, NR-RRC, MAC-NR, RLC-NR, PDCP-NR — full 5G NR radio stack. Used the bundled 5g-nr-radio/explore.fxt.xml and 5g-nr-radio/sessions.fxt.xml templates.

Results

Explore diagram: 68 frames matched, one combined viewer per pcap.
Sessions: 12 sessions across five session types — mac-ue×2, rrc-connection×2, pdcp-bearer×3, rlc-bearer×3, nas-5gs×2. All marked incomplete::mid-capture: the radio side has no SCTP / IP teardown markers, so the FXT auto-starts sessions.
Two UEs on a single 5G NR Standalone cell, test PLMN MCC=001 / MNC=01, AS security NEA0 / NIA2 (lab profile):
- UE-1 — C-RNTI 0x4601 — initial Registration, then released.
- UE-2 — C-RNTI 0x4602 — returning UE (5G-S-TMSI 0xe9003dcc), Service Request, PDU Session, deregistration.

Started visualether serve — explore viewer at /explore/gnb_mac/gnb_mac_viewer.html, per-session navigator at /sessions/gnb_mac/index.html, Capture Atlas at /.

03UserDocument the flow

Please generate a markdown document that describes the complete flow.

04ClaudeFull per-UE walkthrough

Walked the NDJSON. Two UEs play out one after the other on the same cell, ~10 s apart; their RRC Release retransmissions interleave at the boundary.

UE-1 (RNTI 0x4601) — Initial Registration

12 protocol PDUs starting at t = 27.945 s:

Msg3 RRC Setup Request (mo-Signalling) on CCCH/LCID 52 → Msg4 RRC Setup (SRB1 added, AM, t-PollRetx=ms45, maxRetxThreshold=t8).
RRC Setup Complete + piggyback NAS Registration Request (initial, 5G-GUTI 0xc5003bc1).
NAS dialogue: Authentication Request / Response → NAS SMC / SMC Complete (with replayed Registration Request inside, per TS 24.501 §4.4.6).
AS Security Mode Command (nea0 / nia2) / Complete.
Registration Accept / Complete → Configuration Update Command.
Then silence. No Configuration Update Complete from UE-1.

UE-2 (RNTI 0x4602) — Service Request + PDU Session

Starts at t = 38.237 s, 10 s after UE-1's last activity:

RRC Setup Request (mo-Data) → RRC Setup → RRC Setup Complete + NAS Service Request (5G-S-TMSI 0xe9003dcc).
AS SMC / Complete → DL Service Accept.
UL PDU Session Establishment Request (wrapped in UL NAS Transport).
UE Capability Enquiry / Information (PowerClass pc2).
RRC Reconfiguration adds SRB2 (LCID 2) and DRB1 on LCID 4, 18-bit PDCP SN, AM RLC with t-PollRetx=ms20, pollPDU=16 → RRC Reconfiguration Complete.
UL DRB burst on LCID 4: ~15 PDCP PDUs, every 2nd one polling for status, steady PHR ~22 dB.
UL NAS Deregistration Request (UE-originating) on SRB2 → 7 ms later, gNB issues RRC Release.

The two RRC Release storms (preview)

Event	UE	Frames	PDCP SN	MAC-I
Release UE-1	RNTI 0x4601	24, 31, 32	5	`0x3cabf79f`
Release UE-2	RNTI 0x4602	66, 67, 68	4	`0x21c437d8`

Each is one Release PDU retransmitted three times because the UE has already moved to RRC_IDLE and is no longer answering the RLC poll bit. They look identical at the diagram level — but the layers below tell different stories. Full per-UE protocol trace, sessions index and FXT template references are in the companion analysis page: 5G NR gNB MAC — Complete Flow.

05UserCompliance review

Please point out the issues you see with the flow. Are the UE and gNB completely compliant with the 3GPP 5G-NR specification?

06ClaudeCompliance audit — artefacts vs real issues

Nothing on the wire proves an outright spec violation, but the trace has both dissector artefacts (mistakable for bugs) and genuine anomalies worth chasing. Split below.

Capture / dissector artefacts

Duplex flip-flop FDD/TDD on every frame. One C-RNTI, one cell — cannot be both. The mac-nr.phy-context.duplex field is set per-direction by the gNB trace hook; not a real OTA event.
DRB1 PDCP plane labeled "Signalling". Without an explicit drb-pcap binding, the heuristic dissector can't map LCID 4 to a DRB. Cosmetic.
PDCP SN size 12-bit on DRB1 despite RRC configuring len18bits. Same dissector-default root cause as above.

Genuine anomalies

PDCP COUNT increments of 256. UE-side DRB COUNTs are 128, 384, 640, 896… (Δ=256). Per TS 38.323 §5.3, TX_NEXT increments by 1 per PDU. Either the dissector is mis-reading the SN field (likely, given the 12-vs-18-bit ambiguity) or the UE is skipping SNs, which would break gNB reordering state. Re-decode with the correct DRB SN size before concluding.
No PDU Session Establishment Accept observed. UE-2 sends the Request, then the gNB adds the DRB via RRC Reconfiguration, then UE-2 transmits UL DRB data — but no DL NAS Transport with Establishment Accept is visible. AS-layer the DRB is usable as soon as Reconfiguration completes, but the NAS session is technically not ACTIVE until Accept reaches the UE. Either the Accept was lost in capture or the test UE pre-empts NAS confirmation.
No Configuration Update Complete from UE-1. Per TS 24.501 §5.4.4.3, only required if the Command sets the ACK-requested bit. Conditional non-compliance.
RLC max-retx vs gNB-issued Release timing. SRB1 config gives maxRetxThreshold=t8 × t-PollRetx=ms45 ≈ 360 ms, but UE-1's Release fires 10 s after the last UL activity. The gNB is releasing on an inactivity timer, not on max-retx escalation.

Test-profile concerns (compliant but not production)

NEA0 NULL ciphering. Mandatory-to-support per TS 33.501 but forbidden in commercial deployments.
NAS null_decipher:TRUE required to decode post-SMC NAS — confirms the NAS bundle is also NEA0.
PHR + Short BSR on every UL grant. Matches the configured periodicBSR=sf10, just a notable steady-state grant tax.

The two items most worth chasing are PDCP COUNT stride 256 and UL DRB before PDU Session Establishment Accept. Both are probably explainable by the missing DRB↔PDCP binding, but they should be re-verified with a drb-pcap mapping or an NGAP-side capture before declaring the pair fully compliant.

07UserCross-layer release investigation

UEs with RNTI 0x4601 and 0x4602 show retransmissions of RRC Release. Let us go across layers to investigate what is going on. Is this an abnormal release?

08ClaudeUE-1 abnormal · UE-2 normal

Six RRC Release frames, two distinct events. The retransmit storms look alike on the surface but the cross-layer evidence points to very different root causes.

UE-1 (0x4601) — abnormal release

RRC. Last RRC procedure is Configuration Update Command at F18 (t = 28.249 s). No Configuration Update Complete ever arrives. ~10 s of silence until Release at F24 (t = 38.269 s).
PDCP. DL SRB1 PDU ordering is sequential: SN 0 = Auth Request, SN 1 = NAS SMC, SN 2 = AS SMC, SN 3 = Registration Accept, SN 4 = Config Update Command, SN 5 = RRC Release. The Release reuses the next sequential SN — F18 went on the wire and was never confirmed end-to-end.
RLC. UE-1's last UL Status PDU (F19, t = 28.265 s, ~16 ms after F18) reports ACK_SN=5 — i.e. it had not acknowledged the Configuration Update Command. UE-1 went radio-silent immediately afterwards.
MAC / timers. t-PollRetx=ms45 × maxRetx=t8 ≈ 360 ms, but the Release is 10 s later — the trigger is not RLC max-retx alone.

Two consistent interpretations for the 10-second gap:

UE-1 declared upper-layer RLF on its own side (TS 38.331 §5.3.10.3, N310 → T310 expiry) and moved to RRC_IDLE autonomously within the silent window.
The gNB held UE-1 in context against an inactivity timer (~10 s default in many srsRAN configs) and released by inactivity rather than by max-retx.

Verdict: no graceful NAS Deregistration, no Configuration Update Complete, no MAC CE indicating reattach. This is an inactivity / RLF-driven release of a UE that had silently dropped off the air. Confirmation would come from an NGAP capture showing UE Context Release Request with cause radio-connection-with-UE-lost (TS 38.413 §9.3.1.2), or a UE-side trace showing T310 expiry.

UE-2 (0x4602) — normal release

RRC. Last UE-2 procedure is Deregistration Request (UE-originating) at F64 (t = 43.788 s). 7 ms later the gNB issues Release at F66.
PDCP. Clean sequential SN chain on UE-2's SRB1: SN 0 AS SMC, SN 1 Service Accept, SN 2 UE Cap Enquiry, SN 3 RRC Reconfiguration, SN 4 RRC Release. Every prior PDU was acked.
NAS. 7 ms gap matches the NGAP round-trip: AMF receives Deregistration → sends UE Context Release Command → gNB issues RRC Release. Per TS 24.501 §5.5.2.2.5, on switch-off the UE enters 5GMM-DEREGISTERED and moves to RRC_IDLE immediately after sending the Deregistration Request — without waiting for Accept.
RLC. UE-2 is already in RRC_IDLE when the Release lands. Poll bit never gets an answer; RLC-AM dutifully retransmits twice more (F67, F68). Same PDCP SN=4, same MAC-I 0x21c437d8.

Verdict: textbook switch-off deregistration. The retx storm is a benign side-effect of the spec-compliant interaction between "UE goes silent on switch-off" and "RLC-AM polls until max-retx".

Side-by-side

	UE-1 (0x4601)	UE-2 (0x4602)
Last UE→gNB activity	F19 RLC Status (`t=28.265 s`)	F64 Deregistration Request (`t=43.788 s`)
Gap before Release	~10 s of silence	7 ms (NGAP round-trip)
Triggering DL PDU	Config Update Command (SN=4) un-ACKed	clean ack-chain through Reconfiguration, then Release
RLC max-retx fired?	Should have at ~360 ms but Release is 10 s later — gNB inactivity / RLF cleanup	N/A — UE moved to IDLE by NAS switch-off
UE state at Release	Already in IDLE due to UE-side RLF (N310/T310 expiry probable)	Already in IDLE due to NAS switch-off
Cause class	Abnormal — radio-link loss / inactivity cleanup	Normal — graceful deregistration

What would close the loop

For UE-1: an NGAP trace showing UE Context Release Request with cause radio-connection-with-UE-lost, or a UE-side log capturing N310/T310 expiry between t=28.3 s and t=38.3 s.
For UE-2: an NGAP trace showing UE Context Release Command from the AMF with the switch-off indicator surfaced in the deregistration cause — no further investigation needed.

Method. One pcap rendered with VisualEther via its MCP integration with Claude — analyze_capture for protocol detection, explore with 5g-nr-radio/explore.fxt.xml for the combined sequence diagram, extract_sessions with 5g-nr-radio/sessions.fxt.xml for the per-UE / per-bearer view. Cross-layer release diagnosis cross-checked frame-by-frame against the rendered NDJSON, ACK_SN progression on UE-1's UL Status PDUs and PDCP SN ordering on each UE's SRB1. Full per-UE flow and FXT template references are on the companion analysis page: 5G NR gNB MAC — Complete Flow. The gnb_mac.pcap sample is from the Wireshark merge request wireshark/wireshark!12834.