Docs / dflux Runner
ContactGet started

Overview

dflux Runner is a 5G/4G protocol load and conformance tester — one Go binary that simulates network elements such as gNB, AMF, MME, UDM, AUSF, and SMF/UPF. It drives deterministic procedures over NGAP, Diameter, SBI, REST, and PFCP, plus GTP-U user-plane traffic on N3, against real or simulated cores.

It is for the test/integration engineer who needs to gate a build with a registration smoke run, lean on an AMF for an hour with a hundred concurrent UEs, exercise a vendor's policy plane via Diameter Gx and Rx, or terminate user-plane traffic on a clean receiver and read the throughput back.

What ships

  • Five wire protocols — NGAP/SCTP (3GPP TS 38.413), Diameter S6a/Gx/Rx (RFC 6733; 3GPP TS 29.272/29.212/29.214), SBI HTTP/2 (3GPP TS 29.500-series), REST HTTP/2, PFCP (3GPP TS 29.244)
  • {flows} ready-to-run flows and {suites} suites across NGAP, SBI, REST, PFCP, and Diameter — browse the flow catalog, or read the source YAML in the templates repository
  • A declarative YAML schema for authoring custom flows as state machines — action types including send, check, extract, uplane_start, ngap_realloc, ngap_handover_swap, parallel_send, and cmd (the last is off unless you pass -allow-cmd-actions); check operators; {{...}} template expressions
  • Suite runner with per-step workload, stop_on_failure gating, always_run cleanup steps, and JSON reports for CI gating
  • NF roles for gNB, AMF, SMF, AUSF, UDM, PCF, NRF, UPF, MME, PGW, AF, plus external for non-3GPP peers
  • Server-mode flows — auto-spawn on first inbound message; ship for AMF, UDM, AUSF, UPF, Edge-admin
  • GTP-U user-plane via embedded DPDK or kernel-socket userspace receiver
  • Single static binary — no runtime dependencies

How it's used

Two front-ends, same engine underneath:

  • CLI one-shot — d3x-run run-flow -flow registration -c lab.yaml. File-driven, deterministic. run-flow exits 0 on verdict pass, 1 on fail, 3 on unsupported. The mode CI gates plug into. No control plane required.
  • Agent mode — d3x-run daemon -console <addr>. The runner registers with the control plane, executes jobs in memory, streams events and the report back, and holds nothing between jobs. Use this for a continuous test plane.

Both share the same flow catalog, the same protocol stacks, the same FSM dispatcher, and the same JSON report shape.

What it's not

dflux Runner is intentionally not a 3GPP simulator. It does not implement the full state machine of any NF. It implements the FSM model the test author declares — which is exactly what a tester wants for conformance and load work and exactly what a simulator wants to avoid.

If you need a working AMF, run an AMF; the shipped registration_amf flow is a wiring stub, not a replacement.

The runner itself is a stateless execution engine. Durable state — catalogs, report history, schedules, subscriber pools — lives in the control plane when you run agents continuously. The CLI path never needs that.

Where to go next