5G NR DRB Uplink·A Stall Frozen at ACK_SN=0

analyze_capture detected the full 5G NR radio stack — NAS-5GS, NR-RRC, MAC-NR, RLC-NR, PDCP-NR — behind a DLT_USER 149 wrapper (auto-mapped to udp with the mac_nr_udp / rlc_nr_udp / pdcp_nr_udp heuristics). Rendered with the bundled 5g-nr-radio FXT templates: 68 frames, one UE talking to one gNB across two RRC connections.

Connection	C-RNTI	Window	Purpose
Session 1	0x4601	27.9–28.2 s	Initial Registration
Session 2	0x4602	38.2–43.9 s	Service Request → PDU session → stall → Deregistration

Session 1 is a clean registration (RRC Setup → Auth → NAS SMC → AS Security Mode nea0/nia2 → Registration Accept/Complete), every SRB1 PDU RLC-ACKed, then 10 s of silence. Session 2's control plane also looks healthy — up to the point where user data should flow.

Cross-layer issues

• Issue 1 DRB uplink permanently stuck (frames 40–63). The UE sends RLC AM Data SN=0 on the DRB and the gNB answers STATUS ACK_SN=0 ~12 times — SN=0 never acknowledged, RX never advances.
• Issue 2 UE gives up and deregisters (F64) once the bearer won't drain.
• Issue 3 Stale-context RRC Release storm on the old connection 0x4601 (F24, 31, 32) — same PDCP SN 5 retransmitted, never ACKed.
• Issue 4 Final RRC Release storm on 0x4602 (F66, 67, 68) after the UE has already left.

Headline: control plane fine, user plane never carries a byte. Initial root-cause hypothesis (revised later): possibly no PDU Session Establishment Accept / user-plane bring-up — flagged for verification against the NAS containers.

Generated both views and opened them via the auto-spawned visualether serve.

• Explore: all 68 frames as one UE↔gNB sequence — both RRC connections, the NAS containers, and the failure tail.
• Sessions: 14 sessions across five trackers — mac-ue×2, rrc-connection×2, nas-5gs×2, pdcp-bearer×4, rlc-bearer×4.

Every session is incomplete::mid-capture — no session has a clean open+close bracket inside the capture, which matches the analysis: connection 1 is never cleanly released before going idle, and connection 2 ends in the unacknowledged RRC-Release retransmission storm rather than a confirmed release. The rlc-bearer entry for DRB LCID 4 is the one that visually shows the SN=0 poll/retransmit storm.

Queried mac-nr.sfn and mac-nr.slot across all 68 frames rather than assuming. Both columns are empty on every frame; mac-nr.direction and mac-nr.rnti are populated.

The writer included the mandatory MAC-NR framing tags (RNTI, direction, HARQ id, duplex) but omitted the optional subframe/slot timing tag, so Wireshark has no radio-frame timing to dissect.

• Cannot do slot-accurate work here: HARQ RTT in slots, k1/k2 offsets, scheduling-occasion alignment, SFN-wrap.
• Can still order and time-correlate everything via the microsecond pcap capture timestamps — which is exactly what drives the Issue-1 timeline.

To get SFN/slot the capture would have to be re-generated by the gNB/L2 trace with the slot tag enabled, or sourced from a PHY-layer trace.

A detailed field extraction overturned part of my earlier guess, and I led with the correction.

Correction. I previously said “no PDU Session Establishment Accept in DL.” That was wrong. The NAS extraction shows it is present: F29 (UL) carries 5GSM 0xc1 = Establishment Request; F37 (DL NAS Transport 0x68) carries 5GSM 0xc2 = Establishment Accept, piggybacked on the RRC Reconfiguration that adds the DRB. So the session opened and the DRB was configured correctly — Issue 1 is a pure radio-side RLC-AM stall, not a session-setup failure.

t=0 = frame 1 @ 06:29:27.945. Bearer map from the F37 config: bearer 1 = SRB1, bearer 2 = SRB2, bearer 4 = DRB1 (LCID 4, AM, t-PollRetransmit=ms20).

The stall (frames 40–63, ~4.1 s)

Every UE uplink PDU on bearer 4 is SN=0, SI=complete, P=1; every gNB reply is STATUS, ACK_SN=0, no NACK.

Frame	t_rel (s)	Dir	RLC on bearer 4
40	11.143	UL	DATA SN=0, P=1
41	11.144	DL	STATUS ACK_SN=0
44	12.143	UL	DATA SN=0, P=1
48	13.143	UL	DATA SN=0 ×2
52	14.143	UL	DATA SN=0
58	15.143	UL	DATA SN=0
63	15.225	DL	STATUS ACK_SN=0 (12th & last)

Two interleaved timers: a ~1.000 s cadence (the upper layer re-offering the same single SDU — the SN never leaves 0, proving exactly one packet) and ~20–40 ms bursts within each second (RLC t-PollRetransmit).

Why ACK_SN=0 is the smoking gun

Per TS 38.322, ACK_SN is the next not-received SN; everything below is acknowledged. Had the gNB accepted SN=0, the first STATUS (F41) would read ACK_SN=1. All 12 read ACK_SN=0 — the gNB RLC-AM RX entity reports its initial state on every poll and never advances RX_Next.

Cross-layer reconciliation

Because this is a gNB-side trace, a logged UL PDU is one the gNB MAC already decoded post-HARQ:

• PHY/MAC: ok delivered — SN=0 demuxed on LCID 4 every time, no HARQ failure.
• RLC-AM (gNB RX): stuck — receives SN=0 but never delivers it up / never advances ACK_SN. This is the defect.
• PDCP/SDAP: never receives the SDU → no IP packet reaches N3.
• Downlink DRB: zero DATA PDUs — every DL bearer-4 frame is a STATUS.

Termination & verdict

At F64 (t=15.843 s) the UE sends a Deregistration Request (UE-originating) on SRB2 — abandoning the call 4.70 s after its first DRB packet. The gNB then triple-sends RRC Release (F66/67/68) which the departed UE never acknowledges.

Item	Finding
Symptom	Single SDU SN=0 retransmitted ~18× (F40–62)
gNB response	12× STATUS ACK_SN=0 (F41–63)
Ruled out	Session setup (Accept present F37), HARQ/MAC, ciphering (nea0 null)
Root cause	gNB RLC-AM receive entity for DRB1/LCID 4 fails to deliver/ACK SN=0

Derived explore-drb-stall.fxt.xml from the 5g-nr-radio sample and injected two firebrick highlighter templates so the stalled DRB frames stop rendering in the same neutral lavender as healthy ARQ.

The clean-filter insight: in this capture ACK_SN=0 is unique to the stalled DRB (every SRB status PDU reports ACK_SN ≥ 1), so a template anchored on rlc-nr.am.ack-sn == 0 catches exactly the 12 stall STATUS PDUs with no false positives.

• STATUS template (priority 355, anchored on am.ack-sn): fired on exactly the 12 DRB status PDUs, zero SRB status PDUs.
• DATA template (priority 348, UL, anchored on am.sn): fired on exactly the bearer-4 SN=0 (re)transmissions; SRB RLC data stayed with the higher-priority NR-RRC templates.

validate_fxt: valid, 100% frame coverage, no template conflicts. Regenerated the diagram; verified against the NDJSON that frames 40–62 carry 🛑📤 DRB UL Data SN=0 (never ACKed) and 41–63 carry 🛑📥 DRB STATUS — ACK_SN=0 (no progress), bracketed by the two firebrick RRC-Release storms.

Each data PDU shows SN+Poll and each STATUS shows ACK_SN, with frame.number in every remark — so the SN=0 / ACK_SN=0 loop can be counted directly off the diagram.

Method. One pcap driven through VisualEther via its MCP integration with Claude — analyze_capture for protocol detection, explore + extract_sessions with the 5g-nr-radio templates for the sequence and per-session views, and query_fields for the frame-indexed RLC/NAS matrices that pinned the stall and corrected the root cause. The custom explore-drb-stall.fxt.xml was checked with validate_fxt (100% coverage) before rendering. Capture: gnb_mac_nr_dlt149.pcap — 5G NR mac-nr over DLT_USER 149, from Wireshark MR !12834 (srsRAN, R. Falkenberg).