Glossary

Terms

Flow : A finite-state machine encoding one protocol procedure. Defined as YAML (kind: flow) with states, transitions, actions, and final_states. The unit dflux Runner executes — run-flow -flow registration runs one flow against one or more UEs. See flows.

Path : One traversal of a flow from initial_state to a final state. A flow with multiple final_states (e.g. registered and failed) has multiple paths; on a given execution a UE follows exactly one.

Step : One state transition inside a flow. Single-UE CLI reports list steps with timestamps and TX/RX message types. The term also names one entry inside a suite — context disambiguates.

Suite : An ordered collection of flows defined as YAML (kind: suite) with steps. Each step independently draws its own subscribers, runs its referenced flow with its own workload, and either continues or aborts the cycle based on stop_on_failure. Cleanup steps marked always_run execute even after an abort. See suites.

Environment : A YAML file (e.g. config/lab.yaml) declaring the NFs in scope and the transports they use to reach the wire. Loaded with -c <file> for CLI runs, or supplied on a job by the control plane in agent mode. See environments.

Execution / report : One run of a flow or suite. On the CLI, capture it with -output json|junit (and optional -output-file) — nothing is written to a local database. Historical catalogs live in the control plane when agents are attached.

NF role : The kind of network function a flow simulates or talks to: gnb, amf, smf, ausf, udm, pcf, nrf, upf, mme, pgw, af, pcrf, or external. Validated against the environment at engine startup so a gNB-side flow cannot run against an AMF-only environment.

Client-mode flow : A flow that initiates the procedure. The engine fires a Start event into the initial state, which dispatches the first send. Most NGAP gNB flows are client-mode.

Server-mode flow : A flow that waits for a peer to send the first message. There is no Start event; the flow spawns when an inbound message matches (e.g. InitialUEMessage for the registration_amf flow). Used for AMF, UDM, AUSF, and UPF server-mode flows.

Server : An overloaded word in these docs. It means the d3x-run server subcommand (the user-plane receiver), a server-mode flow that waits for the peer, or a service producer in SBI. Context disambiguates.

Agent mode : Running d3x-run daemon -console host:port … so the binary attaches to the control plane as a stateless worker. The agent dials out, executes jobs in memory, streams reports back, and holds nothing between jobs. See Agent mode.

Enricher : A built-in that fills protocol-specific fields on an outbound message before it is encoded onto the wire — e.g. InitialUEMessage populates NGAP IDs and the NAS payload from UE state. Flow authors reference enrichers by name in send actions; they don't write them. Dump the live list with d3x-run vocab.

Check : A type: check action that asserts a field on the most recent inbound message (or UE context). Operators include equals, not_equals, not_empty, greater_than, less_than, greater_or_equal, less_or_equal, contains, not_contains, exists, regex, in / oneof, length, and ie_present. A failed check fails the flow. See check operators.

Action : One operation inside a transition. Types: send, parallel_send, check, extract, uplane_start, ngap_realloc, ngap_handover_swap, and cmd (off unless -allow-cmd-actions). See action types.

Verdict : The runner's single answer to whether a flow ran correctly, printed first in the report. pass, fail, or unsupported (the core does not implement the scenario). run-flow maps those to exit codes 0, 1, and 3. all_passed still means “no check failed” — a narrower fact than the verdict.

Workload : How the engine spawns UEs over the lifetime of a run. Knobs: repetitions (UE count), rate (UEs per second; 0 = burst), duration (stop after wall-clock), timeout (per-UE).

Subscriber : One UE identity used by NGAP/NAS authentication. Carries SUPI, key, OPC, SQN, SNN, and the ciphering and integrity algorithms. On the CLI: loaded in-memory via -s or synthesized via -gen-subscriber. Durable inventory for fleets lives in the control plane. See subscribers.

Subscriber set (CLI) : The process-local slice of subscribers for a one-shot run. Entries are handed out in order; exhausting the set fails further UEs rather than blocking on a wait queue. Not a shared multi-process pool and not backed by local SQLite.

Lab : The conventional name for the canonical single-gNB environment in config/lab.yaml. Documentation examples derive from this lab unless a page is explicitly about an advanced case.

Where to go next

• Overview — what ships and how it is used.
• Architecture — CLI vs agent, what the binary contains.
• CLI reference — every subcommand and flag.