All projects

Protocol validation · 2026

5G core, from setup to fault diagnosis

Following a 5G Standalone service from registration to user traffic, then using controlled faults to find the exact boundary that breaks.

My role
Lab integration, validation tooling, and protocol analysis
Environment
Single-host Open5GS / UERANSIM lab
Tools
Linux, Python, Bash, Wireshark, and tshark

Finding where a 5G service breaks

When a UE cannot reach an endpoint, the failure could sit in admission, authentication, session setup, routing, or the return path. I built a local 5G Standalone lab to follow that service chain and identify the boundary responsible for a failure.

My implementation

I integrated Open5GS and UERANSIM, configured subscribers and network settings, and established the Linux routing, namespaces, tunnels, and NAT needed for UE-originated traffic. I wrote the Python validator, Bash workflows, packet analysis, and fault documentation around those upstream implementations.

The baseline checks SCTP association and NG Setup, 5G-AKA authentication, NAS security, UE registration, IPv4 PDU-session establishment, and bidirectional user-plane traffic. Packet captures, component logs, and host networking state provide complementary views of the same exchange.

A fault worth following

In the missing-N6-NAT experiment, the UE remained registered and its PDU session stayed established. Uplink GTP-U packets reached the UPF, but traffic left the host with the private UE source address and no external reply returned.

Restoring the scoped masquerade rule brought replies back without restarting the 5G components or rebuilding the session. That isolated the failure to the external return path.

The remaining cases cover PLMN, TAC, authentication-key, and DNN mismatches. Each records the last successful stage, the first failed or absent procedure, and recovery after restoring the baseline.

Engineering choices

  • Keep the stages separate. Registration, session establishment, and working user traffic each have their own validation outcome.
  • Change one condition at a time. Dedicated fault configurations preserve a known working baseline.
  • Explain the diagnosis. Packet frame maps, implementation logs, and Linux state connect the observed symptom to its cause.

The outcome

The repository contains a reproducible service chain, a read-only validation workflow, and five fault investigations with recovery evidence. It gives a reviewer a concrete path from configuration to protocol exchange to diagnosis.

Lab scope

The baseline uses one synthetic UE, one gNB, one DNN, and one IPv4 session on a single host. UERANSIM abstracts the over-the-air NR PHY. The observations establish protocol and host-network behavior within those conditions.

A closer look

Single-host lab architecture showing the UE, gNB, 5G core functions, and Linux user-plane path.
Single-host lab architecture showing the protocol interfaces and Linux user-plane path used in the validation workflow. View source.
Five controlled faults arranged by the last successful and first failed stage of the service chain.
A summary of the fault campaign. The packet maps and recovery captures linked below provide the underlying observations. View source.

Related links