Your first server-mode flow

By the end of this tutorial you will have run two dflux Runner processes against each other on localhost: one acting as an AMF (server-mode registration_amf flow), the other as a gNB (client-mode registration flow). Server-mode flows wait for the first inbound message and auto-spawn — no Start event, no -repetitions setting on the AMF side. Use server-mode flows for vendor-side wiring tests and conformance harnesses against a real gNB.

Prerequisites

You completed the Quickstart and Your first YAML flow.
Two terminals on your host.
The shipped flows on disk. They live in your clone of d3x-templates, which these commands reference with -templates ./d3x-templates.

Step 1 — Author an AMF-side env

The shipped lab.yaml declares one gNB. We need a sibling env with one AMF binding. Create config/lab-amf-server.yaml:

YAML

mode: server flips the NGAP transport into AMF-mode: bind local_sctp and accept inbound gNB associations.

Step 2 — Point the gNB at localhost

Copy config/lab.yaml to config/lab-localhost.yaml and point the gNB at the AMF you'll run in the next step. The shipped lab.yaml dials a real peer (192.168.1.139:38412), so you are overriding that address with localhost here — Step 4 runs against the copy:

YAML

Step 3 — Start the AMF-side flow

Terminal 1:

Bash

Server-mode flows exit on context cancel — the -duration 60s gives you a minute to drive a client at it. Capture the result with -output if you want a machine-readable report:

Code

Step 4 — Drive a registration from the gNB side

Terminal 2:

Bash

Watch terminal 1 — you'll see the AMF flow auto-spawn on inbound InitialUEMessage, send a UEContextReleaseCommand, and land in released. The shipped registration_amf flow is intentionally minimal (wiring-validation only); it doesn't drive the full registration handshake. The gNB-side registration flow will time out waiting for AuthenticationRequest because the AMF stub never sends one.

Step 5 — Stop the AMF flow

Either wait for -duration 60s to elapse, or hit Ctrl+C in terminal 1. The flow exits cleanly.

Step 6 — Inspect the reports

There is no local report database. Open the JSON you wrote with -output-file. If both sides ran as console agents, reports live in the control plane — see Agent mode.

What you built

You ran dflux Runner as an AMF, accepted an inbound gNB association, and traced a full InitialUEMessage → UEContextReleaseCommand exchange. Server-mode is the same FSM model as client-mode — only the trigger differs (first inbound vs Start event). The shipped registration_amf flow is wiring-validation only: no auth, no security mode, no real registration accept.

Where to go next

Architecture — how server-mode admission, auto-spawn, and FSM dispatch fit together.
Multi-protocol flows — drive more than one wire protocol from a single run.
Flow schema reference — the full field set for authoring your own flows.