AirTrafficGen: Configurable ATC Scenarios

• AirTrafficGen is a framework that uses large language models to automatically generate configurable air traffic control scenarios, ensuring sector-aware and plausible simulations.
• It employs a graph representation of sector topology with nodes spaced at 20 nautical miles to maintain operational realism and effective deconfliction of aircraft.
• The system offers prompt-driven control over parameters like aircraft count, interaction type, timing, and altitude, enabling iterative refinement and simulator-ready outputs.

AirTrafficGen is an end-to-end framework for automatically generating configurable air traffic control (ATC) scenarios with LLMs. Introduced in “AirTrafficGen: Configurable Air Traffic Scenario Generation with LLMs,” it targets the scenario-design bottleneck in ATC training and validation, where realistic situations are usually handcrafted by experts for specific sector geometries, routes, and controller skills. Its defining features are a purpose-built graph representation of sector topology, prompt-driven control over interaction structure, and simulator-ready structured outputs that can be loaded into BluebirdDT for execution and verification (Gould et al., 4 Aug 2025).

1. Definition, scope, and operational setting

AirTrafficGen is designed for ATC training and validation simulations, not for direct deployment in live control operations. Its central problem is the automated construction of scenarios that remain sector-aware and operationally plausible while still obeying explicit user specifications. In this framework, “configurable” means that the scenario designer can specify parameters such as the number of aircraft, scenario duration, whether aircraft interact or remain non-interacting, the number of interactions, the interaction type, the interaction location and time, vertical profiles, and modifications to an existing scenario (Gould et al., 4 Aug 2025).

The system is therefore neither a pure text generator nor a generic flight-trajectory model. Its operational object is a scenario: a set of aircraft instantiated on sector routes with timed entry, speed class, and, in the full setting, initial and exit flight levels. A plausible implication is that AirTrafficGen should be understood as a structured planning system whose output happens to be elicited through prompting, rather than as an unconstrained natural-language synthesis model.

The operational motivation is specific. Handcrafted ATC scenarios are labor-intensive, slow to produce, expensive, and dependent on scarce domain expertise. Sector-specific geometry and route structure make reuse difficult, so the volume and diversity of available simulations remain limited. AirTrafficGen addresses that limitation by allowing the scenario designer to describe desired traffic properties while delegating placement, timing, and interaction planning to an LLM constrained by explicit movement and interaction rules (Gould et al., 4 Aug 2025).

2. Graph representation, aircraft model, and scenario pipeline

The key representational move in AirTrafficGen is the conversion of continuous airspace into a graph aligned with ATC relevance scales. Routes are discretized so that graph nodes are separated by 20 nautical miles, and route legs are interpolated with nodes at that spacing. The motivation is operational rather than geometric: aircraft are treated as non-interacting if no pair with overlapping flight-level ranges comes within 20 nautical miles of one another. The representation therefore preserves route lengths, intersections, and shared segments while deliberately discarding “unimportant kinks” in the geometry (Gould et al., 4 Aug 2025).

Routes are presented to the model as explicit coordinate sequences rather than latent embeddings. In the supplementary examples, route data are serialized as Python-style dictionaries whose values are ordered node sequences. Aircraft are represented, in the simplest benchmark setting, by route_name, spawn_time, and grid_time_step; in the full controllable setting, initial_flight_level and exit_flight_level are added. The system uses two discrete speed classes: grid_time_step = 1 for fast aircraft and grid_time_step = 2 for slow aircraft. The paper states that slow approximates turboprops and fast approximates jets when mapped to the simulator (Gould et al., 4 Aug 2025).

The end-to-end pipeline consists of sector-topology input, graph conversion, prompt construction, LLM reasoning, structured scenario generation, and simulator loading. The prompt includes the graph-encoded routes, movement rules, interaction definitions, scenario constraints, and a decomposition strategy. The LLM is instructed to analyze topology, devise a placement strategy, and internally verify the scenario before returning fixed-format JSON. That JSON is then parsed into BluebirdDT, a probabilistic digital twin of en-route airspace, where interactions can also be counted automatically from the graph rollout (Gould et al., 4 Aug 2025).

A useful technical detail is the system’s aircraft-dynamics abstraction. In the lateral benchmark setting, all aircraft are constrained to a common flight level,

$h_i \equiv e_i \equiv H,\ \forall i,$

so the task isolates lateral planning. In the full model, each aircraft also carries a flight-level range

$(\min(h_i, e_i), \max(h_i, e_i)),$

and interactions require range overlap in addition to spatial-temporal coincidence (Gould et al., 4 Aug 2025).

3. Interaction model, prompting decomposition, and controllability

AirTrafficGen formalizes interaction on the graph by two conditions. An interaction occurs when two aircraft either occupy the same node simultaneously or swap nodes in one time-step. Because graph edges do not cross except at nodes, those two conditions capture all events corresponding to coming within the 20 nmi threshold. With vertical structure enabled, an interaction additionally requires overlap of the two flight-level ranges (Gould et al., 4 Aug 2025).

The prompting strategy follows a fixed three-phase decomposition. In Phase 1, the model analyzes sector topology by parsing route definitions, identifying isolated routes, and finding intersections and shared segments. In Phase 2, it assigns routes, spawn times, and speeds, deciding where interactions should or should not occur; for interactive scenarios it is instructed to work backward from desired conflict points, while for safe scenarios it uses isolated routes or large temporal separations. In Phase 3, it internally constructs trajectories as ((x,y), time) tuples, builds a global occupancy structure,

$$\texttt{grid\_occupancy[time\_step][(x\_coord, y\_coord)] = [list\_of\_aircraft\_ids]},$$

checks same-cell and swap interactions, and iteratively refines the scenario if unintended interactions are found (Gould et al., 4 Aug 2025).

The control surface exposed to the user is unusually broad for an ATC scenario generator. The paper demonstrates control over interaction presence, interaction count, interaction type, location and time, vertical interaction structure, and post hoc scenario adaptation. The three pairwise interaction classes used in the paper are cross-path, head-on, and catch-up. In the full controllability prompt, additional realism rules are imposed: allowed flight levels are multiples of 10 from FL200 to FL310 inclusive; aircraft with slow speed (grid_time_step = 2) must fly at FL250 or below; and scenarios should include a mix of climbers, descenders, and level flights (Gould et al., 4 Aug 2025).

A common misconception is that AirTrafficGen merely “asks an LLM for a scenario.” The prompt design contradicts that interpretation. The model is required to reason over explicit route topology, to roll out time-indexed occupancy, and to satisfy machine-checkable same-cell and swap constraints. This suggests that its effectiveness depends at least as much on representation engineering and internal verification structure as on general language-model fluency.

4. Benchmarks, metrics, and empirical performance

The evaluation protocol uses 10 synthetic sectors per parameter setting and four benchmark families: traffic volume, scenario length, sector complexity, and controllability. The traffic-volume benchmark fixes $T=12$, $N_{\text{routes}}=7$, and $N_{\text{intersections}}=7$, while varying

$N \in \{2,3,4,5,6,7,8,9,10,15,20,25,30\}.$

The scenario-length benchmark fixes $N=8$ and varies

$T \in \{12,15,18,21,24\}.$

The sector-complexity benchmark fixes $N=8$, $(\min(h_i, e_i), \max(h_i, e_i)),$0, $(\min(h_i, e_i), \max(h_i, e_i)),$1, and varies

$(\min(h_i, e_i), \max(h_i, e_i)),$2

The controllability benchmark fixes $(\min(h_i, e_i), \max(h_i, e_i)),$3, $(\min(h_i, e_i), \max(h_i, e_i)),$4, $(\min(h_i, e_i), \max(h_i, e_i)),$5, $(\min(h_i, e_i), \max(h_i, e_i)),$6, and requests target unique interacting pairs in $(\min(h_i, e_i), \max(h_i, e_i)),$7 (Gould et al., 4 Aug 2025).

The first three benchmarks are scored by MUIP, the mean number of unique interacting aircraft pairs; ideal performance is $(\min(h_i, e_i), \max(h_i, e_i)),$8. Interaction-count control is scored by MADIP, the mean absolute difference between actual and requested numbers of unique interacting pairs. The paper also defines normalized capability scores

$(\min(h_i, e_i), \max(h_i, e_i)),$9

with $$\texttt{grid\_occupancy[time\_step][(x\_coord, y\_coord)] = [list\_of\_aircraft\_ids]},$$0, so that $$\texttt{grid\_occupancy[time\_step][(x\_coord, y\_coord)] = [list\_of\_aircraft\_ids]},$$1 denotes random-baseline performance or worse and $$\texttt{grid\_occupancy[time\_step][(x\_coord, y\_coord)] = [list\_of\_aircraft\_ids]},$$2 denotes perfect performance (Gould et al., 4 Aug 2025).

The main empirical result is that top reasoning models can produce dense, non-interacting traffic. For 30 aircraft, the random baseline yields 28.4 interacting pairs, Gemini 2.5 Pro yields 0.9, and o3 yields 0.0. For 25 aircraft, the corresponding values are 19.3, 0.3, and 0.2; for 20 aircraft, 12.2, 0.3, and 0.2. In the scenario-length benchmark, o3 is perfect at all tested lengths $$\texttt{grid\_occupancy[time\_step][(x\_coord, y\_coord)] = [list\_of\_aircraft\_ids]},$$3, while Gemini 2.5 Pro is perfect except at $$\texttt{grid\_occupancy[time\_step][(x\_coord, y\_coord)] = [list\_of\_aircraft\_ids]},$$4, where it records 0.1 MUIP. In the sector-complexity benchmark, o3 remains perfect across intersection counts 4 through 14, while Gemini 2.5 Pro is near-perfect at the hardest settings (Gould et al., 4 Aug 2025).

Exact controllability is harder. For requested interaction counts 1–5, o3 records 0.0, 0.0, 0.0, 0.4, 0.3 MADIP, whereas Gemini 2.5 Pro records 0.0, 0.1, 0.6, 1.5, 1.7. The paper therefore treats high-traffic non-interacting generation as largely solved by the strongest models in this setup, while exact higher-count interaction control remains materially more difficult (Gould et al., 4 Aug 2025).

5. Implementation details, verification, and iterative refinement

AirTrafficGen evaluates a wide model set, including qwen-3-8b-it, mistral-small-3.2-24b-instruct-2506, llama-3.3-70b-it, gemma-3-12b-it, gemini-2.5-flash-lite-preview-06-17, llama-3.1-405b-it, kimi-k2, gpt-4.1-2025-04-14, o3, and gemini-2.5-pro; the paper also mentions deepseek-r1-0528 in result tables, though it is omitted from the appendix model table. All experiments were run through OpenRouter with temperature 1.0, top_p = 1.0, top_k = 0.0, and an initial maximum token budget of 35,000, raised in increments of 10,000 up to 50,000 if needed. The selection policy is deliberately strict: the system uses the first scenario generated that satisfies the required format, rather than sampling multiple candidates and selecting the best. Total experiment cost is reported as under $100 USD (Gould et al., 4 Aug 2025).

Verification is central to the framework. A valid scenario must satisfy at least three layers: format validity, graph-dynamic validity, and operational validity. Operationally, a non-interacting scenario must ensure that no pair with overlapping flight-level ranges comes within 20 nmi; interactions should not occur at sector entry or spawn time; and, in the full prompt, an aircraft should not be relevant traffic for at least 2 minutes after entering the sector. These constraints are not merely descriptive; they are embedded into prompt logic and post-generation checking (Gould et al., 4 Aug 2025).

A notable property of the system is iterative refinement. The paper describes a loop in which a scenario is generated, automatically evaluated, and then returned to the model with textual feedback about violating aircraft pairs. Gemini 2.5 Pro and o3 are reported to correct flawed scenarios after such feedback. The main documented case is an $$\texttt{grid\_occupancy[time\_step][(x\_coord, y\_coord)] = [list\_of\_aircraft\_ids]},$$5 scenario that initially contained 3 interactions; after feedback specifying the failure mode, the revised scenario passed. The paper does not provide a quantitative refinement-success table or iteration statistics, so refinement is demonstrated qualitatively rather than comprehensively benchmarked (Gould et al., 4 Aug 2025).

The same mechanism also supports editing. The paper shows examples in which the LLM adds a new aircraft, changes flight levels, or makes an interaction harder to solve. A representative example inserts AC5 so that it overlaps in flight level with AC2 and AC4, removing an obvious climb-based resolution option. This indicates that AirTrafficGen functions not only as a generator but also as a structured scenario-modification tool (Gould et al., 4 Aug 2025).

6. Relation to adjacent research, limitations, and significance

AirTrafficGen occupies a different niche from several neighboring strands of ATM generation and optimization research. “Synthetic Aircraft Trajectory Generation Using Time-Based VQ-VAE” addresses synthetic end-to-end aircraft trajectories at the single-trajectory level, emphasizing time-frequency latent modeling and flyability assessment rather than multi-aircraft scenario planning (Murad et al., 12 Apr 2025). “Context-Aware Generative Models for Prediction of Aircraft Ground Tracks” develops a sector-specific probabilistic generator for lateral aircraft trajectories, conditioned on entry context and filed route, but not on explicit inter-aircraft scenario constraints (Pepper et al., 2023). “Inferring Traffic Models in Terminal Airspace from Flight Tracks and Procedures” models procedure-conditioned terminal arrivals as deviations from procedures, including a pairwise extension to correlated traffic, but again without AirTrafficGen’s instruction-following scenario-planning interface (Jung et al., 2023).

On the control and post-processing side, AirTrafficGen is also distinct from deconfliction and tactical-simulation frameworks. “Quantum Annealing Applied to De-Conflicting Optimal Trajectories for Air Traffic Management” is most naturally read as a post-generation deconfliction layer over precomputed wind-optimal routes (Stollenwerk et al., 2017). “An empirically grounded agent based model for modeling directs, conflict detection and resolution operations in Air Traffic Management” models tactical en-route controller interventions such as conflict resolution and directs on top of planned traffic (Bongiorno et al., 2016). “An Empirically grounded Agent Based simulator for the Air Traffic Management in the SESAR scenario” provides a broader policy-experimentation simulator with strategic planning, rectification, pre-tactical deconfliction, and tactical control modules (Gurtner et al., 2016). A different neighboring use case is “Aircraft Conflict Resolution: A Benchmark Generator,” which generates tunable 2D and 3D conflict-resolution benchmarks rather than configurable ATC training scenarios (Pelegrin et al., 2024).

These comparisons clarify what AirTrafficGen is not. It is not a single-trajectory generative model, not a full 4D aircraft-performance simulator, and not a tactical controller-policy model. Its simplifying assumptions are explicit: two speed classes, coarse 20 nmi graph discretization, route-following movement on graph nodes, prompt dependence, and benchmark evaluation on synthetic sectors with up to 30 aircraft. The paper also notes the absence of formal human-in-the-loop evaluation by air traffic controllers and the lack of scaling studies for much larger sectors, richer route networks, airport procedures, or more complex event structures (Gould et al., 4 Aug 2025).

Its significance lies in showing that LLMs can act as structured planners in a safety-critical, spatio-temporal domain when paired with a representation that exposes topology, movement rules, and machine-checkable validity constraints. A plausible implication is that AirTrafficGen’s long-term importance may depend less on raw language-model capability than on how effectively future systems integrate sector topology, verifiable interaction semantics, simulator feedback, and expert editing workflows into a unified scenario-design loop.