---
title: 'AirTrafficGen: Configurable ATC Scenarios'
url: https://www.emergentmind.com/topics/airtrafficgen
type: topic
---

# AirTrafficGen: Configurable ATC Scenarios

AirTrafficGen is an end-to-end framework for automatically generating configurable air traffic control (ATC) scenarios with large language models (LLMs). Introduced in “AirTrafficGen: Configurable Air Traffic Scenario Generation with Large Language Models,” 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 [2508.02269].

## 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 [2508.02269].

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 [2508.02269].

## 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 [2508.02269].

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 [2508.02269].

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 [2508.02269].

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 [2508.02269].

## 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 [2508.02269].

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 [2508.02269].

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 [2508.02269].

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\), \(T=12\), \(N_{\text{routes}}=7\), and varies
$$
N_{\text{intersections}} \in [4,14].
$$
The controllability benchmark fixes \(T=12\), \(N=10\), \(N_{\text{routes}}=7\), \(N_{\text{intersections}}=7\), and requests target unique interacting pairs in \(\{1,2,3,4,5\}\) [2508.02269].

The first three benchmarks are scored by **MUIP**, the mean number of unique interacting aircraft pairs; ideal performance is \(0\). 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
$$
\mu_{1,2,3} = \Big[1-\frac{\text{MUIP}}{\text{MUIP}_{\text{rand}}}\Big]_+,\qquad
\mu_4 = \Big[1-\frac{\text{MADIP}}{\text{MADIP}_{\text{rand}}}\Big]_+,
$$
with \([x]_+ = \max(0,x)\), so that \(0\) denotes random-baseline performance or worse and \(1\) denotes perfect performance [2508.02269].

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 \(T=12,15,18,21,24\), while **Gemini 2.5 Pro** is perfect except at \(T=24\), 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 [2508.02269].

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 [2508.02269].

## 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** [2508.02269].

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 [2508.02269].

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 \(N=30\) 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 [2508.02269].

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 [2508.02269].

## 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 [2504.09101]. “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 [2309.14957]. “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 [2303.09981].

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 [1711.04889]. “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 [1609.08030]. “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 [1606.04241]. 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 [2405.12836].

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 [2508.02269].

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.

Source: https://www.emergentmind.com/topics/airtrafficgen