VisualEther Session — Open5GS 5GC + UERANSIM Control Plane Analysis

Please generate explore.fxt.xml and sessions.fxt.xml for @cp_0804_02.pcap

Ran analyze_capture against the PCAP. Detected 7 protocols: NGAP, HTTP/2, MongoDB, SCTP, PFCP, NAS-5GS, TCP.

Recommended template: 5g-attach/explore.fxt.xml (57% coverage). Better fit found in 5g-core-free5gc which covers HTTP/2 SBA + NGAP + NAS-5GS + PFCP + GTP-U.

Action: Copied 5g-core-free5gc/explore.fxt.xml and 5g-core-free5gc/sessions.fxt.xml from the bundled samples into the PCAP directory.

Validated both against the PCAP:

All conflicts reported by the validator were "expected first-match-wins" — no errors.

please generate hosts.txt as well

Ran extract_endpoints (axis=port) and identified all unique IP:port pairs.

Used HTTP/2 :authority headers (extracted via extract_fields) to confirm 127.0.0.10 and 127.0.1.10 map to NRF (paths under /nnrf-nfm/...).

Mapped remaining IPs using Open5GS default loopback conventions:

127.0.0.4    SMF        127.0.0.13   PCF        192.168.0.111  AMF (N2 38412)
127.0.0.5    AMF        127.0.0.15   BSF        192.168.0.112  UPF/SMF (N4 8805)
127.0.0.9    HSS.PCRF   127.0.0.20   UDR        192.168.0.113  UPF/SMF (N4 8805)
127.0.0.10   NRF        127.0.0.24   NSSF       192.168.0.114  UPF/SMF (N4 8805)
127.0.0.11   AUSF       127.0.1.10   NRF.alt    192.168.0.115  UPF/SMF (N4 8805)
127.0.0.12   UDM        127.0.0.1    MongoDB    192.168.0.131  gNB (UERANSIM)

Saved as hosts.txt (tab-separated IP[:port]<TAB>Name).

Before that let us add emojis to message, parameter and host names

Audited both FXT files for opcodes/params lacking emoji prefixes. Applied edits via Edit tool with replace_all.

Params updated (both files)

• Type:$1 → 📄 Type: $1
• Location:$1 → 🔗 Location: $1
• MCC:$1 MNC:$2 → 🌍 MCC: $1 MNC: $2
• Node:$1 → 🖥️ Node: $1
• SEID:$1 / F-SEID:$1 → 🔑 SEID/F-SEID: $1
• UE-IP: $1 → 🌐 UE-IP: $1
• AMF-Capacity: $1 / AMBR-DL/UL → 📊 …: $1
• Len:$1 → 📏 Len: $1
• PDU-Sess:$1 → 🎬 PDU-Sess: $1
• SSC:$1 → 🎯 SSC: $1
• KSI/ABBA/FOR:$1 → 🔐 KSI/ABBA/FOR: $1

Opcodes updated (sessions.fxt.xml only)

• UEContextReleaseCommand → 🛑 UEContextReleaseCommand
• UEContextReleaseComplete → ✅ UEContextReleaseComplete
• GTP-U … → 🔗 GTP-U …

hosts.txt — NF-typed emojis

📋 NRF      📍 AMF      🌐 SMF      🔐 AUSF/UDM    💰 PCF
💼 BSF      🗄️ UDR      🧩 NSSF     📡 gNB.RAN     🔀 UPF1-4
🏛️ HSS.PCRF              🗃️ MongoDB

Re-validated — both FXT files still valid (72 / 76 templates, 0 errors).

let us run explore first

Ran explore with the FXT and hosts file:

input:      cp_0804_02.pcap
fxt_file:   explore.fxt.xml
hosts_file: hosts.txt
output_dir: explore_output/

Result: 681 / 2272 frames matched. Viewer opened at: explore_output/cp_0804_02/cp_0804_02_viewer.html

yes

Ran extract_sessions with the same hosts file.

Navigator opened at sessions_output/cp_0804_02/index.html.

Please analyze the 5g-sba-session sessions. Do you see any differences in the flows?

Walked the 34 SBA NDJSON files (6 failure + 28 incomplete) and aggregated message labels per session.

Failure (6 sessions) — all identical

All 6 are TCP SYN → RST,ACK to 🏛️ HSS.PCRF on 127.0.0.9:3868 (Diameter). Different ephemeral source ports, all from 127.0.0.1, rejected within microseconds. A 4G Diameter peer is down/unconfigured and a client (likely PCF or SMF probing for legacy interworking) keeps retrying. Harmless for 5G call flow but noisy.

Incomplete (28 sessions) — different shapes per role

Key flow differences

1. Two NRF endpoints behave differently — 127.0.0.10 is the management hub (heartbeats, discovery), 127.0.1.10 receives per-NF registration PUTs. Same NRF, two service interfaces.
2. Session 29 is an outlier — 522 messages, 25× the median. The persistent NF-management bus.
3. Sessions 20–22, 24 carry non-NRF service paths (UDR/AUSF/UDM) inside an NRF.alt connection — open5gs's SCP-less indirect routing.
4. All "incomplete" sessions are healthy — long-lived persistent HTTP/2 SBI connections that simply outlive the capture; not broken flows.
5. Per-procedure traceability is excellent for one UE (imsi-001010000000000): session 36 (AKA), 41 (UDM auth+registration), 38 (UDR data), 37 (SM-context lifecycle), 35 (PCF policy), 42 (BSF binding). Together these constitute one complete 5G registration + PDU session establishment + release.
6. Session 39 (NSSF) is suspicious — SMF-pattern paths arriving at the NSSF address. Either the host mapping for 127.0.0.24 is wrong or NSSF is co-located with an SMF in this open5gs config.

What is the difference between successful and incomplete sessions for 5g-pfcp-session sessions?

Dumped all 3 PFCP session NDJSON files. There is 1 success and 2 incomplete.

Common skeleton (all PFCP associations)

1. Association Setup Request (retried up to 3× at ~2.5s — open5gs default before peer responds)
2. Association Setup Response
3. Bidirectional Heartbeat Request/Response every ~11s
4. Session Establishment Request/Response (SEID 0x1) — when a UE PDU session is created
5. Session Modification Request/Response — gNB-side F-TEID is installed after NGAP PDU Session Resource Setup Response
6. More heartbeats
7. Session Deletion Request/Response ← only present in success

Per-session differences

What actually distinguishes them

1. Successful = saw the Deletion handshake. Session 7 ends with Session Deletion Request → Response (Cause: success). That single exchange is what flips the outcome to success::session-deleted.
2. Incomplete 14 is functionally identical to success 7 through Modification — both go Assoc → Heartbeat → Establish → Modify. The capture window simply ended before the corresponding NAS PDU Session Release reached this UPF, so no Deletion was observed.
3. Incomplete 13 is a different shape entirely — 4 heartbeat-only frames. The Association and any PDU session for this pair happened before the capture started; auto-start created a "session" from the first Heartbeat.

Pair-level observation

The capture has two parallel SMF↔UPF associations: (.112↔.114) and (.113↔.115). Only the first carried a PDU session through to release within the capture; the second was still active when the trace ended.

Note on host naming: Based on the Node-IDs inside the PFCP messages, .112/.113 look like SMF instances and .114/.115 look like UPF instances (open5gs typically deploys redundant SMF↔UPF pairs). The current hosts.txt labels all four as UPF — worth correcting if the diagrams will be shared.