5G NR Radio·RRC Release Retransmission & Cross-Layer pcap Triage

Capture: 69 frames over ~5.5 s. Single UE (RNTI 0x4601) on test PLMN MCC=001/MNC=01. 5G-GUTI 0xc0002333. Ciphering NEA0, integrity NIA2. The capture ends in an RLC poll-retransmission storm on RRC Release — the textbook signature of a lost UE.

Symptom (RRC layer)

Frames 58–69 are 12 identical retransmissions of the same RRC Release (PDCP SN=6, MAC-I 0xeacb8577) at ~46 ms cadence over 456 ms. The UE never acknowledges any of them.

RLC layer — the poll-retx loop

• The SRB1 RLC AM config established in frame 2 sets t-PollRetransmit = ms45 and maxRetx = t8.
• Observed retx cadence is ~46 ms — exactly t-PollRetransmit.
• Count is 1 transmission + 11 retx = 12, consistent with the gNB exhausting maxRetx = t8 before declaring failure.
• Every retx has RLC Poll: Status report is requested set, but no UL STATUS PDU comes back from the UE → UL is dead.

MAC / PHY layer — the real root cause

The UE's uplink was already deteriorating before the Release:

• Power-headroom collapse: frame 27 PHR = −2 dB → frame 35 = −5 dB → frame 51 = −9 dB. UE is at Pcmax = 11 dBm (PowerClass pc2) and progressively path-loss-limited.
• RLC had to segment UL SDUs at fragment offsets 394 and 534 (frames 33, 41, 47, 53) — shrinking TBs under bad SNR.
• BSRs in frames 18, 40, 46, 49, 50 are repeatedly issued but data trickles out slowly.

So by the time the gNB sends RRC Release, the UE has effectively walked out of the cell — no ACK ever comes back.

Cross-layer ripple before the failure

• Frames 11, 12, 13, 16: four identical DL NAS forwards of the same payload 7e02307ec4b18c7e… — DL retransmissions because of poor channel.
• Frames 21 & 22: duplicate UE Capability Enquiry (same Trans ID 2).
• Frames 26 & 29: duplicate RRC Reconfiguration (same Trans ID 3).
• All point to lossy SRB1 even during setup, not just at release.

NAS layer — why the gNB chose to Release

• Registration is to PLMN MCC=001 / MNC=01 ("Test network") with 5G-TMSI 0xc0002333.
• After Authentication / Security Mode Complete, the DL NAS in frame 55 (7e02c253c9158e7e…) is the AMF response that triggers the gNB to immediately RRC-Release the UE — almost certainly a Registration Reject / Deregistration from the test AMF (not a graceful UE-initiated release; the UE never sent a Detach).

Root cause

Two contributing faults, stacked:

• NAS-driven release — the AMF rejected the registration over the test PLMN (001/01), prompting an unsolicited gNB-initiated RRC Release on SRB1.
• Radio link failure on the UL — by the time that Release goes out, the UE is power-limited (PHR ≈ −9 dB at Pcmax) and effectively unreachable. The Release is sent reliably (RLC AM), so the gNB loops through t-PollRetransmit × maxRetx (45 ms × 8) before giving up, producing the 12-frame poll-retx storm at the tail of the trace.

The visible "12× RRC Release" tail isn't a gNB bug — it's RLC AM doing exactly what it was configured to do while the UE was already gone.

All three captures show an initial 5G NR attach against the same test network (RNTI 0x4601, PLMN 001/01), but flows and outcomes diverge sharply.

Quick header

Aspect	pixel_6a	moto_edge_30_pro	simcom-sim8262e-m2
Date	2023-03-23	2023-04-17	2023-03-21
Frames matched	28	69	58
Span	~32.3 s	~5.5 s	~31.0 s
NAS identity	SUCI (fresh)	5G-GUTI 0xc0002333	5G-GUTI 0xfa003e0f
RRC cause	mo-Signalling	mo-Data	mo-Signalling
DRB set up?	no DRB	DRB on LCID 4, PDCP-SN 12-bit	DRB on LCID 4, PDCP-SN 18-bit
Final state	Clean Release	RLC poll-retx storm (12× Release)	Trace ends mid-flow; bearer-4 ACK storm

Setup-phase performance (RRC Setup → Setup Complete)

• pixel_6a: 34 ms (best).
• simcom: 91 ms.
• moto: 103 ms (worst).

Pixel runs against a slightly different gNB profile — t-StatusProhibit=ms10, periodicBSR=sf20, no PHR config in the SRB1 setup. Moto and Simcom share the more aggressive t-StatusProhibit=ms0, periodicBSR=sf10 profile with PHR enabled. The faster Pixel turnaround is partly its modem and partly the lighter signalling load (single PDU, no DRB).

Signalling reliability

Indicator	pixel_6a	moto	simcom
Duplicated DL NAS forwards	none	4× identical (frames 11/12/13/16)	none visible
Duplicated RRC procedures	none	UE Cap Enquiry ×2, RRC Reconfig ×2	none
RLC poll-retx storm	none	12× RRC Release (~46 ms cadence)	22× Bearer-4 STATUS ACK_SN=128 stuck

Pixel's SRB1 is clean. Moto's SRB1 is visibly retransmitting from very early — the gNB is repeatedly forwarding the same DL NAS PDU long before the eventual RLF. Simcom's SRB1 is fine, but its DRB is sick.

Radio quality (UL)

Only moto exposes PHR in this capture's matched frames; it shows uplink degrading:

• moto PHR: −2 dB → −5 dB → −9 dB at Pcmax 11 dBm (pc2). UE becomes power-limited and walks out of the cell.
• pixel and simcom: no PHR samples in matched frames; both UEs continue transmitting consistently throughout — UL stays healthy.

Data-plane (DRB) behaviour

• pixel_6a: never establishes a DRB at all — RRC Reconfiguration carries no DRB add. The UE only does signalling-only registration and then idle-releases. Consistent with mo-Signalling.
• moto: DRB-4 with 12-bit PDCP SN comes up, UE sends real PDCP data (SN 0–15), with RLC segmentation kicking in (SO=394, 534) when TBs shrink under poor channel. About 20 UL PDCP PDUs in flight before the Release.
• simcom: DRB-4 with 18-bit PDCP SN is configured (room for high-throughput data), but no actual PDCP user data is ever sent. Instead the UE emits 22 RLC AM Status PDUs all carrying the same ACK_SN=128 over ~10 s — it's polling/keepalive on a bearer that the gNB never feeds. DRB came up but stayed dry.

End-of-call behaviour

• pixel_6a: one RRC Release at t=54.76 s after long quiet periods (16 s and 15.7 s gaps). Poll requested, but no retx storm captured — looks like the UE accepted it.
• moto: RRC Release at t≈5.05 s followed by 11 identical retx at t-PollRetransmit=45 ms intervals. UL had already collapsed under PHR = −9 dB.
• simcom: no Release captured at all — capture cut off while the bearer-4 STATUS-PDU heartbeat was still running.

Flow comparison

Pixel 6a (clean):
  RACH → Setup → SetupCplt+RegReq (SUCI) → AuthReq → AuthResp →
  SMC → SMCCplt → CapEnq → CapInfo → Reconfig (no DRB) → ReconfigCplt →
  [16 s idle] → keep-alive → RRC Release ✅

Moto Edge 30 Pro (broken):
  RACH → Setup → SetupCplt+RegReq (GUTI) → SMC → SMCCplt →
  DL NAS ×4 retx → CapEnq×2 → Reconfig×2 → DRB-4 data, RLC seg →
  PHR −9 dB → terminal DL NAS → RRC Release×12 ❌

Simcom SIM8262E-M2 (DRB stuck):
  RACH → Setup → SetupCplt+RegReq (GUTI) → SMC → SMCCplt →
  CapEnq → CapInfo (PC2, small) → Reconfig (DRB-4, PDCP 18-bit) →
  RLC STATUS SN=128 storm on bearer 4 (×22 over 10 s) → (cut) ⚠️

Likely root-cause per UE

• Pixel 6a Mo-signalling-only registration over SUCI completed. Long gaps are normal NAS timer activity ending in a clean idle release. No anomalies.
• Moto Edge 30 Pro Mo-data registration into a degrading cell. RLC AM masked the underlying poor channel during setup (DL NAS dupes, duplicate RRC procedures); the AMF eventually issued a NAS reject which the gNB tried to deliver via RRC Release. By that point the UE was power-limited and unreachable → poll-retx storm.
• Simcom Attach signalling and DRB establishment look healthy; UL is healthy. But the configured default DRB never carries user data — UE keeps issuing the same RLC ACK on bearer-4 for ~10 s. Most likely cause: PDU-session activation on the gNB side did not actually open the GTP-U tunnel (or DL traffic was never offered). Symptom is a dead data plane while the control plane stays up.

Headline take

Pixel is the only UE that completes its task cleanly. Moto's failure is radio-driven (PHR collapse → RLF, with the AMF reject the surface trigger). Simcom's failure is data-plane-driven (DRB up but no user traffic, no clean teardown captured). Same gNB, same PLMN, three quite different failure modes — useful as a small regression set.

Short answer: there is no MCS or SINR data in any of the three captures. The traces are Wireshark mac-nr-framed UDP encapsulations — they carry decoded MAC PDUs (logical channels, BSR, PHR, RLC SDUs, RRC/NAS payloads) but not the PHY-layer measurements that would let you quote MCS, SINR, CQI, RSRP, or RSRQ.

Why the PHY metrics are missing

• The mac-nr-framed per-PDU header in this dataset carries radioType, direction, rntiType, rnti, subframe, harqId. It does not carry an MCS index or post-equalizer SINR. The gNB/UE-side scheduler picks the MCS based on CSI feedback, but neither the CSI report nor the resulting MCS is logged in mac-nr framing.
• There are no NR-RRC MeasurementReport messages in any of the three traces. Every RRC procedure captured is on SRB0/SRB1 during attach (Setup, Security, UE-Cap, Reconfiguration, Release) — measurements aren't reported during these. So we also can't read RSRP/RSRQ/SINR per neighbour from RRC.
• There are no DL/UL CSI report PUCCH/PUSCH fields either; in mac-nr framing those are L1 transparent.

What we can infer about link quality without MCS/SINR

The traces do expose a few MAC-level proxies that point indirectly at channel quality:

• PHR (Power Headroom Report) — moto only. Single-Entry PHR samples on moto degrade monotonically: −2 dB → −5 dB → −9 dB at Pcmax = 11 dBm. Negative PH at Pcmax is a textbook power-limited UE; in scheduler terms the gNB would have been forced to drop MCS toward QPSK-low and shrink TBs.
• RLC segmentation events — moto. UL SDUs split at SO=394 and SO=534 on bearer 4 (frames 33, 41, 47, 53). RLC only segments when the grant's TB size is smaller than the SDU — another sign of low effective MCS.
• DL retransmissions of identical NAS PDUs — moto. Frames 11/12/13/16 forward the same DL NAS four times before the UE ACKs at the RLC layer; the DL channel was unreliable enough to need RLC retransmission, again consistent with low effective DL MCS.
• pixel_6a and simcom: no PHR samples appear in the matched frames, and there is no RLC segmentation on SRB1 — no evidence of a stressed channel from MAC-level proxies. That doesn't mean the channel was great; it means the trace doesn't carry the headroom telemetry that would tell us either way.

If you actually need MCS/SINR for these UEs

You'd need a different capture source — none of these can be back-derived from what's on disk:

• A gNB-side scheduler log (per-TTI MCS / iMCS, allocated RBs, HARQ outcomes).
• UE-side modem diag (QXDM / SCAT for Qualcomm; equivalent for SIMCom) for L1 CQI / SINR / RSRP traces.
• RRC MeasurementReport messages — would have to be re-captured with measurement reporting actually configured (the gNB never sent a measConfig here).
• Or a CSI-capable PHY tap (rare).

Bottom line. For these three pcaps the most we can honestly say is: moto shows clear MAC-level signs of a degrading uplink (PHR collapse, RLC segmentation, DL re-tx); pixel and simcom show none of those signs but also no positive evidence of channel quality. MCS and SINR are simply not in this dataset.