1 of 20

Decentralized Autonomous Traffic Management through Corridor Networks

Jasmine Jerry Aloor¹, Aadarsh Govada², Hamsa Balakrishnan¹

¹MIT, ²University of Maryland

Second US-Europe Air Transportation Research & Development Symposium 2026

2 of 20

Joby New York Video

Introduction | Methods | Results | Discussion

(27 April 2026)¹

¹ https://www.jobyaviation.com/news/joby-brings-electric-air-taxis-to-new-york-city-in-week-long-flight-campaign

3 of 20

Is Advanced Air Mobility (AAM) Imminent?

Introduction | Methods | Results | Discussion

Source: Wisk

New class of aircraft and operations for short-range urban and regional flight

Starting now, scaling fast

8 eIPP projects across 26 states, summer 2026

U.S. AAM market: projected over $90B by 2035¹

1. futuremarketinsights.com

Increasing autonomy

Joby: Piloted today, increasing autonomy

Wisk: Autonomous from initial deployment

eVTOL Integration Pilot Program (eIPP)

Adapted from USDOT

This is one example of Advanced Air Mobility (AAM) a new class of aircraft and operations designed for short-range urban and regional flight. As of three months ago, the FAA's eVTOL Integration Pilot Program selected eight projects across twenty-six states, with operations starting this summer.

The U.S. AAM market is projected to be over 90 billion dollars by 2035.

Further, the scale AAM is being designed for is different from today's regional aviation. We're talking about sustained operations at densities that today's air traffic system was not built around.

And lastly, even though Joby's operation we see here are piloted today, the design trajectory is toward increasing autonomy. Wisk is designing for autonomous operations from day one. Beta and Archer have optionally piloted and autonomous variants in their eIPP projects. �The next slide describes how AAM differs from what today's system was designed around.�

4 of 20

AAM Operating Regime

Introduction | Methods | Results | Discussion

Onboard tactical separation

Sustained high-density operations

Increasing autonomous operations

On-demand services

Heterogeneous fleet and ranges

Source: FAA AAM Implementation Plan

Source: NASA

Today's air traffic system was designed for a particular operating regime — and it works extremely well within that regime. Controlled airspaces have centralized, human-in-the-loop coordination, with controllers managing each sector

But the AAM operating regime is different in the following ways, and these are what motivate the research community's interest in new coordination architectures.

First, density. AAM concepts are designed for sustained operations at much higher density per metropolitan area.

AAM concepts span the full autonomy spectrum, with the trajectory clearly toward greater autonomy. Initially, we'll see a mix of piloted, remote-piloted, and autonomous; mature operations will lean heavily toward autonomous.

Third, fleet heterogeneity. Today's aircraft within a class are relatively homogeneous in performance. AAM brings a heterogeneous fleet mix and ranges.

Fourth, on-demand. Today's commercial aviation plans routes and schedules weeks to months ahead. AAM is designed for on-demand services.

On separation, today is controller-provided with TCAS providing advisories for imminent collisions. But AAM will require onboard tactical separation such as sense and avoid or other sophisticated methods

In fact, today’s system is operating near the limits of what it can sustain. The question we want to answer is what coordination looks like in an operating regime that's outside what the current system was scaled to handle."

5 of 20

Coordination Architectures: From Centralized To Decentralized

Introduction | Methods | Results | Discussion

Centralized traffic flow management
Full information
Efficient coordination

Can aircraft coordinate using only local observations?

Centralized

Single service provider

Federated

Multiple service providers

Fully Decentralized

Local information coordination

Common rules and information services
FAA UAM ConOps v2.0
SESAR U-Space (EASA Reg. 2021/664)

Onboard decision making
Rule-based^1,3 and learning-based^2,4 approaches

1. Z. Liu et al. 2. S. Deniz et al. 3. M. Doole et al. 4. L. Yu et al.

As autonomy and AAM operational density increases, the natural question is what coordination architecture supports it. And that question doesn't have a single answer — there's a spectrum.

On the left, fully centralized coordination: a single service provider within an airspace operating with system-wide information, supported by centralized scheduling and traffic flow management with full information visibility enabling efficient coordination.

In the middle, federated coordination: responsibilities distributed across multiple providers operating under common rules and through shared information services. The FAA's UAM ConOps version 2.0 and SESAR's U-Space, formalized in EASA Regulation 2021/664, both adopt federated architectures. Today's operations, in fact, lie between the centralized and federated architectures, where multiple Air Navigation Service Providers coordinate across borders, but most coordination authority still sits at the centralized end.

On the right, fully decentralized coordination: each aircraft makes decisions based on local information onboard There are rule-based approaches and learning-based approaches.

Our work explores the decentralized end of this spectrum. We want to understand can aircraft coordinate using only on locally observed states of their neighbors? What does the performance look like? Understanding what's achievable at that end of the spectrum tells us something about where the floor is and that's useful regardless of whether real systems end up there or somewhere in between.

6 of 20

Coordination Decisions Across Timescales

Introduction | Methods | Results | Discussion

Long-horizon scheduling

We shape sustained traffic flows using turn-rate and acceleration commands derived from local observations

Strategic

Flow shaping

Tactical

Continuous guidance from local observations

Imminent conflict resolution

1. S. Deniz et al. 2. M. Doole et al. 3 A. Jain, et al.

Demand-capacity balancing
Strategic deconfliction

Merge/sequencing policies^1,2
Self-organizing flow³
Learning-based guidance

TCAS / ACAS
Runtime safety filters

minutes to hours

seconds to minutes

sub-second to seconds

There's a second design dimension that's just as important. Coordination decisions in air traffic management happen across a range of timescales. The previous slide asked who decides. This slide asks when.

At the top, strategic operations — on the order of minutes to hours. This is where flight planning, ground delay programs, slot allocation, and demand-capacity balancing live. Strategic deconfliction also sits here.

At the bottom, tactical operations — on the order of sub-seconds to seconds. This is where TCAS and ACAS live, and where recent research on runtime safety filters operates. These are mechanisms operating at the timescale of an imminent loss of separation.

The work I'm presenting today is positioned between these two. We're not scheduling departures upstream, and we're not resolving last-second conflicts. We're continually guiding the aircraft, providing turn rate and acceleration commands derived from each aircraft's local observations — that shapes how aircraft traverse over a timescale of seconds to minutes. we call this the flow-shaping layer.

Decentralized learned guidance can shape sustained traffic flows effectively. and at the end of the talk, I'll show you the work we and others are doing to add a tactical safety layer underneath this kind of flow-shaping policy

7 of 20

AAM ConOps: Corridor-based Operations

Introduction | Methods | Results | Discussion

Defined volumes of airspace: structured, predictable flow

Reduce coordination complexity using designated routes

Within corridors, aircraft still need to maintain separation and flow efficiently

Within corridor networks, can autonomous aircraft coordinate in a decentralized manner using only locally observed information and still produce efficient traffic flows at scale?

Video Credit: FAA

FAA UAM ConOps v2.0, SESAR U-Space (EASA 2021/664)

I just described the design space at a general level: who decides, and on what timescale. The specific operational context this work studies is corridor-based operations, which both U.S. and European regulators have adopted as a structural element for AAM. Corridors are defined volumes of airspace with structured, predictable flow paths. We've been organizing high-density traffic with structured routes for decades, through oceanic tracks and standard arrival and departure routes. Corridors apply the same principle to AAM.

What corridors do is reduce coordination complexity. By constraining aircraft motion to designated routes, the geometric problem any coordination scheme has to solve becomes much simpler than free flight. But corridors don't eliminate coordination. Inside a corridor network, aircraft still need to maintain separation and do all of this efficiently at AAM densities.

The question we ask is: within corridor networks, can autonomous aircraft coordinate in a decentralized manner using only locally observed information — without shared intent, without negotiated schedules — and still produce efficient, corridor-conformant traffic flows at scale? The rest of the talk addresses this question.

8 of 20

Key Operational and Technological Assumptions

Introduction | Methods | Results | Discussion

Environment

Airspace structure and aircraft model

Known, static corridor network structure

Planar fixed-wing kinematics of aircraft

Sensing and information sharing

Each aircraft sees

Own state: position, speed, heading
Relative states of nearby aircraft within sensing neighborhood
Current or next corridor’s relative position and orientation

Communications

Synchronous and accurate relative-state observations
Delays, dropouts, and uncertainty are not modeled

Operating conditions

Nominal conditions only — no wind or other disturbances

Before describing the approach, I want outline the key operational and technological assumptions in this study. First, airspace structure. We assume corridors exist as a known, static structural element: We're not designing the corridors network; we're studying coordination within them. We also model all aircraft with Planar fixed-wing kinematics.

Second, sensing and information sharing. Each aircraft observes its own state plus the relative states of nearby aircraft within a sensing neighborhood. the current or next Corridor's relative, and orientation are available to aircraft. notice that the aircraft's view of the airspace is limited to its current corridor.

Third, communication. The observation model requires synchronous and accurate relative-state observations. In practice this cooperative broadcast could be through ADS-B or onboard sensing, at an update rate compatible with the control loop. We don't model communication delays, dropouts, or uncertainty in this study. Characterizing how the policy degrades under those conditions is a prerequisite for deployment and is part of future work.

Fourth, operating conditions. We train and evaluate under nominal conditions — no wind��With these assumptions in mind, here's the methodology.

9 of 20

Methodology: Decentralized Coordination using Multi-Agent Reinforcement Learning

Introduction | Methods | Results | Discussion

All quantities expressed in the agent’s heading frame → policy is invariant to corridor orientation

Training setup

Single corridor with length: 1.2–2 km
5 aircraft per episode with speed range 60–175 kts
All aircraft have same performance envelope
Randomized corridor orientations, aircraft initial states

Policy output

Turn rate and acceleration (within performance limits)

Sample initial conditions

Within those assumptions, our approach for decentralized coordination uses multi-agent reinforcement learning — MARL — as a tool to study what coordination is achievable under strongly decentralized operations. The methodology has two stages. In training, the system learns a policy by running many simulated episodes in a simple environment with

one corridor, five aircraft with all of them having the same speed range

The geometry and starting positions are randomized every episode. The three thumbnails show sample initial conditions.

Every quantity in the observation--position, speed, heading-- is expressed in the aircraft's own heading frame. This means a policy trained in a single corridor at a fixed orientation should, in principle, work identically in a corridor at any other orientation. This is the property that lets us train in one corridor and then deploy in networks of many corridors at varied orientations without retraining.

What the aircraft does with those observations is command a turn rate and an acceleration within fixed-wing performance limits. That's the action space. The policy converts observations into these two control commands.

Training itself takes a few hours of gpu compute. The output is one policy. Every aircraft in evaluation uses the same one — there's no per-aircraft customization.

10 of 20

Evaluation Approach

Same policy, deployed without re-training

Trained on a single corridor → evaluated on varied corridor networks

Introduction | Methods | Results | Discussion

1) Conformance to corridor boundaries

2) Task completion rate

4) Tactical intervention when needed for deconfliction

3) Average speed

Evaluation uses the same trained policy with no additional training. The training environment was a single corridor with five aircraft and a fixed maximum length. The evaluation environments scale all of those — up to varied corridor networks, up to forty simultaneous aircraft, longer corridors, in networks the policy has never seen. One thing worth noting about how this generalization is possible. The policy never sees the global network structure. At any moment, each aircraft has access to its current corridor's geometry or the next corridor's entry point, orientation, and exit. Operationally, this means the information required is modest. A vertiport or service provider only needs to communicate local corridor information to aircraft entering its airspace,

We measure four things in each scenario. Corridor boundary conformance — what fraction of the time aircraft stay within the corridor walls while traversing. Task completion rate — what fraction of aircraft reach their assigned exit before the episode ends. Average speed across each aircraft's traversal. And need for tactical intervention — the number of times aircraft would require an external safety mechanism to maintain minimum separation. That last one is the closest analog to a TCAS-style resolution advisory.

The evaluation varies three things together: topology, density, and fleet composition. The next set of slides walks through each.

11 of 20

Policy Evaluation Scenarios: Increasingly Complex Topologies

2. Split merge

Merge

Policy trained in a single corridor — deployed without re-training across all topologies

3. Double merge

Introduction | Methods | Results | Discussion

12 of 20

Policy Evaluation Scenarios: Increasingly Complex Topologies

Merge

Policy trained in a single corridor — deployed without re-training across all topologies

3. Double merge

2. Split merge

Introduction | Methods | Results | Discussion

Here's what those policy executions look like in practice.

The merge — two upstream flows converging into one. Three corridors total. The coordination demand here is sequencing through the merge point.

The split-merge — aircraft diverge into parallel lanes and reconverge downstream. Six corridors total. This adds a route-divergence element and tests whether aircraft can reconverge after taking different paths.

The double merge — two sequential merge points. Five corridors total. Interaction density compounds because aircraft that just merged are immediately approaching a second merge with new aircraft entrants.

Across all three topologies, corridor conformance stays at 98% or above Completion rates stay high The tactical intervention rate — the fraction of time aircraft would require an external safety mechanism to maintain minimum separation — stays within 5.8%.

Three to six corridors is, of course, still relatively simple. The real question is what happens when you scale up.

13 of 20

Decentralized Coordination at Scale

Introduction | Methods | Results | Discussion

Fast

Slow

Here's the network we built to test the policy at scale. Eighteen corridors total, three entry points, two exit points, eight possible routes through the network. We designed this by combining every interaction type we'd tested in the simple topologies — merges, splits, and sequential chains — into a single network at high density.

The gif on the right shows what happens with 10 aircraft simultaneously.

I want to re-emphasize one critical thing. The policy on the aircraft in this network is the same policy trained on a single corridor. And the aircraft themselves never see this map. Each aircraft knows only its current corridor's geometry and the next corridor's location and orientation, and where to enter. From the aircraft's perspective, traversing an eighteen-corridor network feels identical to traversing a single corridor, with the next-corridor handoff happening one corridor at a time.

So what we're testing here is whether a local policy can produce coherent global flows in a network it has no map of.

14 of 20

Navigation Performance in the Combined Corridor Scenario

Average speeds across segments stay high

Introduction | Methods | Results | Discussion

Fast

Slow

Here's what the traffic pattern of ten aircraft flying through the eighteen-corridor network simultaneously looks like. Each line is an aircraft trajectory colored by instantaneous speed — blue is fast, around 175 knots, yellow is slow. What you immediately notice is that aircraft maintain high cruise speeds inside corridors — the blue dominates.

The heatmap on the right confirms this — average speeds across corridor segments stay high throughout the network, with only modest reductions at the merge points.

Speed reductions appear at two places: One is at merge junctions and the other is just before the final corridor, which tends to be the most congested. As aircraft approach a merge point, interaction density spikes. The policy responds by slowing aircraft down to create spacing before they reach the merge.

15 of 20

Navigation Performance in the Combined Corridor Scenario

Introduction | Methods | Results | Discussion

Fast

Slow

Now let us look at the throughput plot which measures the instantaneous outflow rate of the aircraft through the corridor network. This is the throughput plot for the most demanding scenario — forty aircraft simultaneously in the eighteen-corridor network. The solid black line is what our policy actually achieves. The dashed blue is an upper bound — computed assuming every aircraft flies at maximum unimpeded speed along a conflict-free trajectory. We reach a maximum of 14 aircraft per minute against this upper bound of 15 aircraft per minute. with centralized coordination and more information, we could get a throughput that lies between the upper bound and the current decentralized policy output. Across all traffic levels, conformance stays between 96 and 98%, completion between 97 and 99%, and tactical intervention stays below 5%.

16 of 20

Emergent Coordination with Heterogeneous Aircraft

Introduction | Methods | Results | Discussion

Emergent behavior with heterogeneity: faster agents overtake in inter-corridor gaps

3 aircraft at 140 kt max speed; remaining 7 aircraft at 175 kt max speed

Fast

Slow

Now let us look at a heterogeneous fleet. Real AAM operations will not have identical aircraft. Different platforms have different cruise speeds. So we tested how the policy behaves with mixed-performance fleets.

We took the same eighteen-corridor network and assigned three of the ten aircraft a maximum speed of 140 knots — roughly twenty percent slower than the other seven, which retain their 175-knot maximum. Same trained policy. No re-training. No change to the reward structure. We just run it.

Watch what happens at the inter-corridor gaps. Faster aircraft slow down behind the slower ones inside corridors — they can't safely pass without leaving the corridor. But the moment they reach an open gap between corridors, they extend their path and overtake.

We didn't program this. There's no overtaking reward. The behavior emerged from two things the policy learned: stay in the lane, and make forward progress. When those two objectives interact with a slower aircraft blocking the path, overtaking in gaps is the natural solution.

The black squares mark where the slower aircraft start. look at what happens between corridors.

Here, in the inter-corridor gap, the faster aircraft extends its trajectory slightly outside the immediate corridor lane and overtakes the slower one. As soon as the next corridor's entry approaches, it re-enters the lane and resumes corridor-conformant flight.

The throughput plot shows the peak throughput of the policy drops by a little as expected — slower aircraft act as moving constraints in high-density segments — and I'll show you that in the next slide."

17 of 20

Spatial Comparison of Average Speeds: �Homogeneous vs. Heterogeneous Max Speeds

Heterogeneity reduces throughput in a spatially localized way

Introduction | Methods | Results | Discussion

18 of 20

Conclusions

Introduction | Methods | Results | Discussion

Multi-agent reinforcement learning based approach to decentralized traffic flow management for autonomous AAM operations in corridor networks

Single policy trained on one corridor with five aircraft deploys without re-training in complex corridor networks

This work characterizes what is achievable when coordination is pushed to a strongly decentralized end of the design space
Real system performance will lie between this and that of centralized coordination

To summarize: we presented a multi-agent reinforcement learning–based approach to decentralized traffic flow management for autonomous AAM operations in corridor networks. A single policy, trained on one corridor with five aircraft, deploys without re-training across progressively complex networks — up to eighteen corridors and forty aircraft — and across heterogeneous fleets with mixed performance envelopes.

This work provides us a reference point. It tells us what's achievable when coordination is pushed to a strongly decentralized end of the design space — aircraft acting only on locally observed states. The real AAM systems performance will lie somewhere between this extreme and that of centralized coordination. Knowing what each end of the design space offers — and what it costs — is what makes choosing intelligently between them possible. That's the contribution this work tries to make.

19 of 20

Ongoing and Future Work

Introduction | Methods | Results | Discussion

3. Dynamic corridor networks

Integrating dynamic corridor structures from self-organizing traffic flows research³

1 M. Low, JJA, et al 2 J. J. Choi, JJA, J. Li, et al. 3 A. Jain, et al.

Tactical safety layer underneath the learned policy

Pushing the framework from air traffic management toward air traffic control
Adding runtime safety filter that guarantees collision avoidance¹

2. Hard safety constraints in the MARL framework

Integrating control barrier function based safety filters² into the corridor framework

The work I showed you today characterizes what's achievable at one end of the design space. But there is room to do better, and three threads of ongoing work address that.

First, a tactical safety layer. The work I've shown is in the regime of air traffic management with flow shaping above the level of imminent conflict resolution. The natural extension is to push the framework toward air traffic control, adding a runtime safety filter that guarantees collision avoidance. Our group's collaboration develops a time-to-reach-based safety filter specifically for the corridor merging case. By adding more information about neighboring aircraft, we can produce more efficient and safe paths in highly congested regimes.

Second, integrating hard safety constraints into the MARL framework itself. Our prior work on Layered Safe MARL for merge scenarios in free-flight settings without corridors — showed how policies can learn to slow down earlier and make proactive decisions to manage congestion, when paired with a safety filter during training. We're now integrating control barrier function safety filters into the corridor framework. This is in progress.

Third, dynamic corridor networks. The corridors in this work are static — the network topology doesn't change during execution. Real airspace will have corridors opening and closing dynamically based on weather, demand, traffic conditions. We haven't tested what our policy does when the topology changes at runtime. My colleague Anahita Jain is presenting her work on self-organizing traffic flows at tomorrow morning's session, and we're integrating the structures she's developing as the corridors our policy can test conformance to. I'd encourage anyone interested in this direction to attend her session.

Each of these threads addresses a specific limitation of the work I showed. together they trace the path from the characterization of the decentralized end of the design space toward systems that could actually deploy.

20 of 20

Introduction | Methods | Results | Discussion

Acknowledgments

Thank you!

Hamsa Balakrishnan

(MIT)

Aadarsh Govada (University of Maryland)