VisualEther Session — 5G-NR Radio Session Analysis

Please analyze the sessions.fxt.xml runs and explain how each session progressed. Do you [see] something unusual in any of the 5G-NR protocol interactions?

Ran extract_sessions against all three PCAPs in one batch with the existing sessions.fxt.xml and hosts.txt. Five session types are defined (rrc-connection, pdcp-bearer, rlc-bearer, mac-ue, nas-5gs) — all keyed by C-RNTI or bearer-id, all auto-start, all terminating as incomplete::mid-capture because the FXT intentionally has no session-stop on RRC Release (the inline comment explains why: Release gets RLC-retransmitted many times, which would create spurious session boundaries under multi-match).

Walked the three rrc-connection NDJSON files; each is one full RRC procedure from Setup Request through Release (or capture end).

Per-session progression

moto_edge_30_pro (frames 1–69, ~5.5 s). Msg3/4/5 with mo-Data and a NAS Registration Request carrying a 5G-GUTI (0xc0002333) — UE had prior context. AS Security Mode Cmd/Complete at frames 5–6 (NEA0 / NIA2). Several DL/UL Information Transfer NAS round-trips. UE Capability Enquiry → Information (PowerClass pc2 reported six times — multiple band combos). RRC Reconfiguration adds DRB1 (PDCP-SN 12-bit, ROHC off, default DRB, QFI 1, PDU session 1) → Reconfiguration Complete. ~4 s idle, two more NAS round-trips, then RRC Release.

pixel_6a (frames 1–28, ~32 s). Msg3/4/5 with mo-Signalling and a NAS Registration Request carrying a SUCI (concealed IMSI — true first attach). Two NAS round-trips (Identity / Authentication) before AS security activates. AS Security Mode Cmd/Complete at frames 12–13 (NEA0 / NIA2). UE Capability Enquiry → Information. RRC Reconfiguration → Complete (Reconfiguration Complete and a piggybacked NAS UL InfoTransfer share frame 18). Three further UL/DL NAS exchanges spread over ~32 s, then RRC Release.

simcom-sim8262e-m2 (frames 1–57, ~32 s). Msg3/4/5 with mo-Signalling and a NAS Registration Request carrying a 5G-GUTI (0xfa003e0f). AS Security Mode Cmd/Complete immediately at frames 5–6 (NEA0 / NIA2) — no auth round-trip first. Six NAS DL/UL Information Transfers with two long pauses (~16 s and ~3 s). UE Capability Enquiry → Information (PowerClass pc2, just one entry — a much simpler IoT module). RRC Reconfiguration adds DRB1 with PDCP-SN 18-bit for PDU Session 2 → Reconfiguration Complete. Capture ends mid-NAS exchange — no RRC Release was seen.

Things that stand out as unusual

1. NEA0 (null ciphering) on every capture. All three AS Security Mode Commands negotiate Cipher: nea0 with Integrity: nia2. AS traffic is integrity-protected but not encrypted. Fine for a test network (the Test network 001/01 PLMN gives this away — open5gs / srsRAN lab), but it would be a serious red flag in production.
2. Authentication ordering differs by UE. Pixel 6a follows the textbook SUCI flow: NAS Authentication round-trips happen before AS Security Mode (frame 12). Moto and SIMCom both presented a 5G-GUTI, so the AMF skipped Authentication and the gNB activated AS security immediately at frame 5. Worth noting because the resulting key derivation reuses cached K_AMF — a network that didn't expect that would behave oddly.
3. Moto: NAS DL retransmissions. Frames 11, 12, 13, 16 all carry the same ciphered DL NAS payload (7e02307ec4b18c7e…) over ~290 ms, while the UE only acks twice. That's the AMF re-firing the same NAS message — likely a T35xx timer expiry waiting for the UE response. Either the UE was slow to respond or RLC was dropping uplink.
4. Moto: RRC Reconfiguration sent twice (frames 26 and 29, same Trans ID 3) before the UE replied with Reconfiguration Complete. Same pattern as #3 — gNB resending an unacked downlink procedure.
5. Moto: RRC Release transmitted 12 times (frames 58–69, ~46 ms apart, all Trans ID 0). The FXT comment already flags this as RLC retransmissions of the Release PDU — but 12 retries is a lot, suggesting the UE never acknowledged the Release at the RLC layer (probably already off-air or in deep sleep).
6. Different PDCP SN sizes for the same DRB. The moto's DRB1 uses 12-bit PDCP SN; the SIMCom's uses 18-bit. Both are valid, but 18-bit is the high-throughput choice — odd for an IoT module, suggests the test gNB applies a one-size-fits-all DRB profile rather than reading UE capability.
7. Pixel: UE Capability Enquiry Trans ID = 0, the same value as the initial Setup. Legal (only 2 bits available) but most gNBs increment; minor implementation quirk.
8. All three captures show long inactivity gaps (4–16 s) between the last NAS exchange and the Release — the gNB inactivity timer isn't aggressive on this lab setup.

Are all RLC sessions in AM mode? What is the frequency of RLC Status PDUs? Did we see any RLC retransmissions?

Cross-checked the NDJSON sessions against the raw PCAPs (tshark with mac_nr_udp heuristic enabled per visualether.toml).

1. RLC mode

Every RLC entity in all three captures is Acknowledged Mode, on SRB1 (always) and on the DRB at LCID 4 (where one was configured — moto and simcom). No UM or TM bearers appear anywhere. Mildly unusual: many real networks use UM for low-latency user-plane DRBs (voice/IMS), but this lab gNB runs everything over AM.

2. Status PDU frequency

Per RLC entity, computed from session start to last seen frame:

The simcom DRB row is the odd one — 28 status PDUs all advertising the same ACK_SN=128 with no NACKs and zero data PDUs in the session window. That's the receiver polling/keepaliving an idle bearer (the 128 SDUs were delivered earlier; nothing new is flowing, but t-StatusProhibit / Poll bits keep firing status reports).

Bursty when data flows (~2–3 /s during signaling exchanges), drops to ~0.5 /s when the bearer is idle — consistent with the configured t-StatusProhibit (ms0–ms10) and the Poll-bit-on-every-data-PDU pattern visible in the FXT params.

3. RLC retransmissions

Yes — but none were NACK-driven. Every Status PDU across all five sessions reports zero NACKs (no NACK SN field present anywhere). The retransmissions that did happen are poll-timer-driven re-sends (sender resending the same SN because no Status arrived before t-PollRetransmit expired):

Headline numbers: moto's downlink SRB1 retransmits a lot (and DL SN=6 sent 12 times is the RRC Release storm noted in Turn 1). Pixel has zero RLC retransmissions in either direction — cleanest radio of the three. Simcom has a handful of DL retransmissions on SRB1, no UL retx visible.

Net: AM is doing its job — no NACKs because the receiver never had to ask for anything; whatever was lost (or whose Status PDU was late) was repaired silently by t-PollRetransmit.

check the PDCP sessions next

Walked the four pdcp-bearer NDJSON files.

Observations

1. Every PDCP PDU the dissector saw is tagged Plane: Signalling. Even moto bearer 4 (= DRB1, LCID 4) is labeled Signalling. The PCAPs don't carry an explicit DRB-PDCP binding for the dissector, so it defaults to the SRB plane — which means the MAC-I and SN-size we see for bearer 4 should not be trusted as DRB ground truth.
2. moto bearer 4 is 16 UL / 0 DL over 3 s. Right after RRC Reconfiguration adds DRB1, the UE bursts 16 uplink PDCP PDUs (likely an initial NAS / SM message or DNS query on the new bearer) but the gNB never responds on that bearer in the captured window. One-sided.
3. PDCP duplicates on moto SRB1 mirror the RLC retransmissions exactly — DL SN=2 ×4, SN=3 ×2, SN=4 ×2, SN=6 ×12 (the RRC Release storm), UL SN=2 ×2. On an SRB each PDCP PDU is one RLC SDU, so PDCP SN tracks RLC SN one-to-one and the same retransmission pattern surfaces at both layers.
4. Pixel and SIMCom SRB1: zero PDCP-SN duplicates. Clean strictly-monotonic SN sequence in both directions.
5. MAC-I values on moto bearer 4 look wrong — repeating 0x22020101 and outright 0x00000000 on different SNs. With the dissector treating these as Signalling but the real bearer being a DRB (which under this config has no integrity protection), the four bytes the FXT prints as "MAC-I" are actually trailing payload bytes, not a real authentication code. Diagnostic noise rather than a security issue.
6. Real PDCP retransmissions only appear as same-(direction, SN) duplicates in successive frames — the ↪️ Prev frame: $1 annotation is just Wireshark's back-pointer for bearer-level navigation and shows up on nearly every PDU, so it should not be confused with a retransmission marker.

check the MAC-UE sessions next

One mac-ue session per UE (keyed by C-RNTI 0x4601). Tallied LCID distributions, control-element cadence, and pulled raw Power Headroom values from tshark to interpret the link quality.

LCID inventory (key entries)

Observations

1. One Msg4 Contention Resolution per capture, no RACH retries. Clean random-access on every UE.
2. Pixel never used DRB1. RRC Reconfiguration added DRB1 but zero MAC PDUs flowed on LCID 4 in either direction during the 32 s capture window. Either no PDU-session traffic was offered, or the capture stopped before the user-plane warmed up.
3. simcom's 5.4× UL:DL ratio is striking. The UE talks much more than the gNB at the MAC layer — but the talk is mostly control: 37 PHRs + 37 Short-BSRs + 38 padding frames out of 231 UL PDUs. The IoT module is bursting MAC CEs at the configured periodic cadence even when no payload is queued.
4. PHR / BSR cadence varies with periodicBSR-Timer from RRC Setup: moto (sf10) → ~4 PHR/s and ~3.8 BSR/s; pixel (sf20) → ~0.37 of each per second; simcom (sf10) → ~1.15 of each per second. Cadence tracks the configured periodicity.
5. All BSR reports are buffer-size index 0 — UE telling gNB "I'm empty". These are post-transmission keepalive BSRs, not "I have data, please grant" requests.
6. Power Headroom tells a clear link-quality story (raw mac-nr.control.se-phr.ph index, where 32 ≈ 0 dB and 63 ≈ +38 dB):

   UE	PH index range	Translated PH
   moto_edge_30_pro	24–31	−8 to −1 dB (power-limited)
   pixel_6a	42 / 62 / 63	+10 to +31 dB (excellent)
   simcom-sim8262e-m2	44 / 49 / 50	+12 to +18 dB (good)

   Moto's negative headroom means it's transmitting at or beyond Pcmax — the UE has no room to boost UL coding when the gNB asks for retransmissions. This explains the RLC retransmission storm in Turn 2: weak/saturated UL is dropping UL Status PDUs, the gNB doesn't get acknowledgements, t-PollRetransmit fires, DL SN=6 ends up sent 12 times.
7. Heavy padding on the DL, especially moto (39 frames) and pixel (15) — scheduler over-grants the transport block size relative to the queued PDCP data.
8. Most PHR frames also carry a Short BSR in the same MAC PDU — confirmed via tshark on simcom frame 3, which shows (Short BSR LCG ID=0 BS=0) (PHR PH=44 PCMAX_f_c=40) in one UL-SCH PDU. The session view collapses both control elements onto a single line, which is why PHR and BSR counts come out identical for each UE.

Trace the moto RRC Release storm across all five session types — show how the same incident surfaces at MAC, RLC, PDCP, RRC, and how the radio context (PHR) explains it.

Pulled frames 58–69 from every */moto_edge_30_pro/*/incomplete/*.ndjson and joined them on frame.number. The result is the same single PDU (the gNB's RRC Release for C-RNTI 0x4601) re-transmitted 12 times in 414 ms, visible at every layer:

Reading top to bottom

• RRC sees one Release that "won't go away."
• PDCP sees one SDU sent 12 times on SRB1 — same SN=6 because PDCP never advances; the same SDU is being re-handed-down by RLC.
• RLC AM is the active retransmitter: every PDU has the Polling Bit set, asking the receiver for an immediate Status PDU. None of the polls is answered (no UL Status PDU appears between frames 58–69 at all).
• MAC rotates through HARQ processes 0, 1, and 2 — the gNB cycles HARQ IDs because previous transmissions never received a HARQ ACK either.
• The retransmission cadence is a clean ~46 ms — the configured t-PollRetransmit: ms45 from RRC Setup, plus one slot of scheduling jitter.

Why this happened (cross-referencing Turn 4)

The MAC-layer Power Headroom for this UE was index 24–31 (−8 to −1 dB) — the moto was transmitting at or beyond Pcmax with no margin to boost UL coding. When the gNB sent the Release and polled for Status, the UE's UL response either never made it onto the air or arrived corrupted. The gNB's t-PollRetransmit fired, RLC re-handed-down the same SDU, MAC picked a free HARQ process and resent — and the loop ran 12 times in 414 ms before the capture ended.

Five session types, one root cause: a power-limited UE losing its uplink at exactly the moment the gNB needed an acknowledgement. That's a story you'd ordinarily reconstruct from four separate Wireshark windows; here it falls out of joining five extract_sessions outputs on frame.number.

Walk the NAS-5GS sessions next.

Each capture produces one nas-5gs session (keyed by C-RNTI). The interesting axis isn't message count — it's how many messages the dissector can actually read in cleartext before NAS-layer ciphering kicks in. That depends entirely on whether the UE presented a SUCI or a 5G-GUTI in the initial Registration Request.

Pixel (SUCI-first attach) — the privacy-correct flow, fully visible

fr 3   16:24:22.478  📱 UE  → 🌐 AMF   📡 NAS Registration Request   (SUCI)
fr 5   16:24:22.482  🌐 AMF → 📱 UE    🔐 NAS Authentication Request
fr 7   16:24:22.558  📱 UE  → 🌐 AMF   🔐 NAS Authentication Response
fr 9   16:24:22.562  🌐 AMF → 📱 UE    🔐 NAS Security Mode Command
fr 10+ ────────────  ciphered NAS from here on (Reg Accept, PDU Session, etc.)

The whole pre-security NAS exchange — challenge, response, algorithm negotiation — happens in 84 ms (frames 5–9). Only after the AMF's Security Mode Command does the inner mm.message_type become unreadable; the lavender Ciphered-NAS template kicks in and surfaces just the security envelope (sequence number + MAC-I).

Moto and SIMCom (5G-GUTI attach) — privacy-OK, observability-poor

Both UEs present a 5G-GUTI (cached identity from a prior attach), so the AMF skips Authentication entirely and resumes the existing security context. Result: the very first message after Registration Request is already integrity-protected and ciphered, so we see exactly one dissectable NAS message per capture and then a wall of 🔒 DL/UL Ciphered NAS rows. The lavender template surfaces the security header type, MAC-I, and sequence number — enough to confirm that NAS security is on, but nothing about the payload type.

Cadence and pauses

• Pixel: dense burst frames 3–22 in 600 ms (the entire registration), then sparse keepalives at 39 s and 55 s.
• Moto: dense frames 3–29 in 617 ms (registration + reconfig), then a ~4 s gap before frames 53–56 (likely a Configuration Update / Registration Complete round-trip), then RRC Release.
• SIMCom: dense frames 3–14 in 165 ms — then a striking 16 s gap to frame 17, another 3 s to frame 21, and a final 12 s gap to frame 53. The IoT module's NAS state machine is clearly running on a much slower clock than the smartphones, possibly waiting on PSM/eDRX-style timers or simply pacing transactions to its host MCU.

What this tells the operator

• Privacy-vs-observability tradeoff is real and visible from the wire. First-attach UEs (SUCI) leak nothing about subscriber identity, but their NAS ladder is fully readable for diagnostics. Repeat-attach UEs (5G-GUTI) gain re-attach speed and skip an air-interface round-trip, at the cost of opaque NAS.
• Without the NAS keys, the dissector has nothing useful to say about ciphered frames beyond "still flowing" — so for diagnosing post-SMC behavior on moto/simcom you'd need the K_NAS_enc from the test network or to correlate with AMF-side logs.
• The Ciphered-NAS template's MAC-I and SEQ fields are still useful: a missing or non-incrementing sequence number would indicate replay/gap, and a constant MAC-I across distinct frames would indicate a broken cipher state. None of those red flags appears in any of the three captures.