5G NR R16 MDT MAC pcap Analysis: PDCP Decryption, Scheduling Cadence, HARQ & IPsec ESP | VisualEther
5G NR MDT MAC·Decryption, Scheduling & IPsec ESP
One R16 MDT NR-MAC pcap (MAC-NR over Ethernet/UDP) carrying one UE reconnecting on a shared C-RNTI . We author explore.fxt.xml / sessions.fxt.xml from the Wireshark issue's decode parameters, decrypt the PDCP user plane (NEA2 ) down to SDAP / IPv6 / SIP REGISTER , read SFN/slot timing, derive the BSR→grant→SDAP scheduling cadence and the DL HARQ round-robin , decode the all-null timing advance , root-cause session-level anomalies across layers, and verify the IMS IPsec ESP security associations by SPI/sequence — all over 151 frames.
1 pcap · 1 UE · 151 frames
01UserAuthor the FXTs from issue #19757
Please generate explore.fxt.xml and sessions.fxt.xml for r16_mdt_nr_mac.pcap. The capture parameters for decoding the file can be found in the original source of this pcap — Wireshark issue #19757.
02ClaudeDecode setup & key verification
The first scan saw only an undissected UDP payload; the L2-over-UDP heuristics then revealed a full 5G NR radio stack — mac-nr, rlc-nr, pdcp-nr, nr-rrc, nas-5gs — carried as MAC-NR over UDP . The outer link type here is plain Ethernet/IPv4/UDP (the wrapper rides 127.0.0.1), so no DLT_USER mapping is needed — the heuristics alone unwrap the fake-UDP payload. VisualEther's bundled 5g-nr-radio sample is a 100%-coverage match, so I authored both FXTs from it and wrote them into the pcap directory.
The issue's decode recipe went into visualether.toml via materialize_config, which also runs a decryption verification pass:
ParameterValue (from issue #19757)<br>Framing heuristicsmac_nr_udp, rlc_nr_udp, pdcp_nr_udp<br>PDCP-NR keys (UEId 1)RRC cipher 95F2…FDDD, user-plane cipher 4CB1…BC5B<br>Decipherpdcp-nr.decipher_signalling + decipher_userplane<br>MAC LCID→DRBFrom configuration protocol<br>RLC→PDCP DRB call18-bit SN (UL & DL)
Verification result: the capture negotiated cipher algorithm 2 (NEA2/AES), and 30 user-plane frames decrypted to SDAP / inner IP with UEId 1's keys. The probe also flagged that UEId 2 and UEId 3 are present but no keys were supplied for them — the issue only published one key set.
03UserSame C-RNTI → reuse keys
UEId 2 and UEId 3 share the same C-RNTI, so the same keys should apply to them.
04ClaudeKeys applied to all three contexts
Good call — mac-nr.ueid is a per-connection context index, not a device id, so the same C-RNTI (0x8000) across all three is one UE reconnecting. I added pdcp_nr_ue_keys rows for UEId 2 and 3 with the same RRC/UP cipher keys and re-materialized; the “no key for UEId 2/3” warnings are gone.
The user-plane decrypt count held at 30 frames , unchanged. That tells us the UEId 2 and 3 episodes carry no additional decryptable DRB user plane — they are signalling-only re-access episodes (Service Requests that never reach a data bearer in the capture). All the SDAP/IP/SIP traffic belongs to the first connection context. The keys are nonetheless in place for every context now, and there are no unkeyed UEs left flagged.
05UserGenerate the diagrams
Generate the diagrams.
06ClaudeExplore & per-session render
Rendered both views from the same recipe via the VisualEther MCP tools. The explore pass matched 151/151 frames ; extract_sessions produced eight per-layer session types . Both used axis=port — the loopback wrapper shares one source/destination IP, so port-level grouping keeps the endpoints distinct. The decryption boundary shows up cleanly in the session counts — the upper-layer lanes exist only where the keys applied:
Session typeCountMeaning<br>rrc-connection / mac-ue2RRC + MAC per connection context<br>rlc-bearer / pdcp-bearer2radio-stack envelopes<br>nas-5gs2NAS signalling<br>sdap-bearer 1deciphered DRB QoS flow<br>ip-flow 3inner end-user IPv6<br>sip 1IMS signalling inside the user plane
The first context decodes all the way up to SDAP → IPv6 → SIP; the re-access episodes decode through MAC/RLC/PDCP but carry no user plane. Live-reload is on, so subsequent FXT edits refresh the open browser tab automatically.
From the source. Issue #19757 flags two known decode problems that reproduce here: packet 38 (an RRC Reconfiguration) and packet 72 (an uplink IPv6 payload-length misalignment). If those frames look off in the diagram, that is the documented capture issue, not the FXT.
07UserWalk me through the flow
Walk me through the complete flow in the pcap file.
08ClaudeEnd-to-end, RACH to IMS
One UE (C-RNTI 0x8000, FDD), three connection episodes, ~49 s. The first episode runs the full attach and an IMS registration; the other two are short re-accesses.
PhaseFramesWhat happens<br>RACH + RRC setup1–4RAR (Msg2, Temp C-RNTI 0x1001, TA 0) → RRC Setup Request (Msg3, mo-Signalling) → RRC Setup (Msg4) + Contention Resolution → RRC Setup Complete + NAS Registration Request<br>NAS auth & security7–18Authentication Request/Response...