Zero-Trust Distributed Airspace Coordination

1. The Airspace Below 400 Feet Will Not Be Controlled

This is not a prediction. It is an arithmetic inevitability. And it is happening now.

The global race is already underway

China is aggressively building the infrastructure for its low-altitude economy — regulatory frameworks, urban air mobility corridors, and massive drone delivery networks are being deployed at national scale. The UAE plans operational urban air mobility by the end of 2026. In the United States, Amazon and Wing are preparing to launch drone delivery at commercial scale. The FAA’s Part 108 NPRM establishes the regulatory framework that will unlock thousands of new commercial BVLOS operators — from enterprise fleet operators to individual Part 107 pilots expanding into autonomous operations.

We are about to move from dozens of aircraft to thousands — without changing the coordination model.

Today, a busy day in the low-altitude airspace might involve a handful of drones, widely separated, under individual Part 107 waivers. Within five years, the same airspace may host hundreds of autonomous platforms from dozens of operators — commercial, government, and military — operating simultaneously in proximity to each other, to manned general aviation, and to the public on the ground.

The security dimension is urgent

This is not purely a commercial coordination problem. The use of small UAS in conflicts overseas — from Ukraine to the Middle East — has demonstrated that drones are now weapons of asymmetric warfare. Recent incursions over U.S. military installations have made the domestic threat tangible. As commercial drone density increases, the ability to distinguish a legitimate delivery drone from a surveillance platform or a weaponized UAS becomes exponentially harder.

This will only get more complicated. The window to establish a framework that lets good actors operate efficiently while identifying bad actors quickly is now — before the airspace becomes so congested that retroactive coordination is impossible.

Centralized control cannot scale

Air traffic control cannot manage this. The ATC system was designed for manned aviation: hundreds of flights per sector, each operated by a human pilot in voice communication with a human controller. That model works at flight levels and in controlled airspace because traffic density is manageable and communication bandwidth exists. It does not scale to the low-altitude economy. The traffic density is too high, the platforms are too numerous, the decisions are too fast, and the platforms are too diverse (from 250g inspection drones to 50kg cargo aircraft) for any centralized authority to manage.

And yet the safety problem is real. Autonomous platforms that cannot see each other, cannot communicate their intentions, and have no mechanism for coordinating their movements will converge on the same airspace at the same time.

There is a third option: a protocol that lets autonomous platforms coordinate with each other, directly, without centralized control — and that identifies the platforms that refuse to cooperate. This paper describes that protocol.

2. Why Existing Approaches Fail

Several systems exist or are being developed for low-altitude airspace management. None of them are sufficient for the scale, speed, and security requirements of the autonomous low-altitude economy.

UTM / USS: the right idea, incomplete execution

The FAA’s UAS Traffic Management (UTM) concept and the UAS Service Supplier (USS) ecosystem represent important progress. UTM establishes the principle that drone operators should share flight intent and that third-party service providers can facilitate deconfliction.

However, UTM as currently conceived has fundamental limitations for the autonomous future:

Remote ID: identification without context

FAA Remote ID provides a mechanism for identifying UAS in flight — similar to a license plate. This is valuable for accountability and law enforcement. But Remote ID provides identification without context. Knowing that a drone is registered to Operator X does not tell you where it plans to go, whether it is following its plan, whether Operator X has a history of safe operations, or whether this particular flight is legitimate.

C-UAS systems: detection without classification

Counter-UAS systems use RF detection, radar, electro-optical sensors, and acoustic sensors to detect drones. These work well against isolated targets in uncongested airspace. They fail in congested environments because they cannot distinguish legitimate commercial drones from threats. When the airspace contains 200 legitimate delivery drones and one hostile platform, a detection-only C-UAS system generates 200 alerts — making the 201st alert operationally useless.

The missing layer across all three systems is the same: a behavioral coordination protocol that generates the data needed for both safety and security.

3. Introducing the Distributed Airspace Coordination Layer

This paper proposes a new class of infrastructure: the Distributed Airspace Coordination Layer (DACL) — a decentralized protocol for autonomous airspace planning, real-time safety verification, and threat identification.

Design principles

Three airspace regimes

The DACL supports three operating regimes that scale with traffic density:

Open airspace — peer-to-peer coordination via intent declaration and the shared protocol. No owner, no central authority. Like uncontrolled airspace in manned aviation. Works at low to medium density.

Managed corridors — a single operator declares and manages a defined airspace volume. Sets capacity, rules, entry scheduling. Grants time-gated access to other operators. Like controlled airspace — centralized within the corridor, decentralized between corridors.

Corridor intersections — two corridor owners negotiate using the same protocol at the corridor level. Agreements include altitude separation, time-slicing, or shared merge points. Rare, pre-planned, and mostly static.

Each regime degrades gracefully to the one below on failure.

4. The Protocol

4.1 Five layers

The protocol is a layered stack. Each layer builds on the one below and degrades gracefully to it on failure.

Layer 1 (Detect) requires no cooperation — the platform is observed via ADS-B, Remote ID, or radar. Position and velocity only. Widest uncertainty.

Layer 2 (Identify + Project) infers aircraft type from ADS-B category or Remote ID, selects the appropriate motion model (fixed-wing, helicopter, sUAS), and projects future position as a 3D Gaussian probability distribution. The Collision Probability Engine (CPE) computes P(collision) at five lookahead intervals (0, 30, 60, 90, 120 seconds). No cooperation needed.

Layer 3 (Intent) requires the platform to declare its planned route, timing, altitude, task volumes, and contingency plans. The CPE switches to a plan-aware projection model with dramatically tighter uncertainty: heading σ drops from 90° (unknown sUAS) to 2° (plan-aware), speed σ from 80% to 5%. Conformance monitoring continuously compares declared intent to observed position.

Layer 4 (Negotiate) handles conflicts between declared intents. The planning coordinator detects overlapping volumes or time windows, generates resolution options (time-slice, altitude separation, re-route), and facilitates negotiation between operators. Agreements are binding. Violations degrade trust.

Layer 5 (Manage) provides structured airspace — corridors with capacity limits, slot-based entry scheduling, speed/spacing enforcement, and merge/diverge management.

4.2 Message format: intent declaration

The intent declaration is the foundational message in the DACL. It describes what a platform plans to do, expressed as a sequence of typed segments.

Key design choices: the intent is a sequence of segments (transit routes + task volumes), not just a single flight plan. Each segment carries its own timing, altitude, and contingency plan. The task_volume type declares a bounded 3D volume rather than a route — other platforms know the drone will be somewhere in this cylinder, doing something, for up to 20 minutes. The trust_token is a cryptographically signed credential from the trust registry.

4.3 Worked example: protocol flow

Two operators — Virabelo (inspection) and PrimeAir (delivery) — have drones that will be in the same area at the same time. Here is the actual message exchange:

Pre-mission: T-30 minutes

Conflict detection: T-29 minutes

Negotiation: T-28 minutes

In-flight: T+0 (missions launch)

This entire negotiation happened autonomously between the two operators’ planning coordinators, resolved in seconds, with zero human intervention. Both RPICs see the resolved plan on their supervisor UI. The in-flight conformance monitor verifies both platforms honor the agreement.

5. The Zero-Trust Model

Zero trust is a security posture: no platform is trusted by default. Trust is earned through observed behavior and verified continuously. A platform that declares intent, follows its plan, and participates in the protocol builds trust over time. A platform that fails any of these tests is treated with progressively wider safety margins — or flagged for investigation.

5.1 Trust scoring — how it works

Every platform carries a composite trust score T ∈ [0, 1] that directly controls the CPE’s uncertainty margins. The score is computed from four weighted signals:

Update mechanics

Trust builds slowly and decays fast — the same asymmetry used in credit scoring. Specifically:

Conformance signal uses an exponential moving average (EMA) over the last 100 flights: C_new = α × C_current_flight + (1-α) × C_previous where α = 0.02 (slow build) for positive conformance and α = 0.15 (fast decay) for violations. A single serious violation drops the conformance signal by ~15%. Recovery takes ~50 clean flights.

Protocol signal is binary for each interaction: did the platform file an intent (yes/no), did it respond to a conflict notification (yes/no), did it honor its negotiated agreement (yes/no). Each interaction adds to or subtracts from a running tally.

Credential signal is relatively static — it reflects the platform’s registration and certification status. A fully certified Part 108 operator starts at credential signal = 0.9. An unregistered platform starts at 0.0.

Behavior signal uses statistical anomaly detection: is this platform’s flight pattern consistent with its declared mission type? A delivery drone that follows delivery routes scores 1.0. A platform that loiters near infrastructure without a declared task volume scores lower.

5.2 Gaming resistance

A trust system invites gaming. Three specific attack vectors and their defenses:

The trust spectrum from hostile to fully trusted:

5.3 Governance: who runs the trust registry?

In a decentralized system, who operates the trust registry? Who has authority to set scores? The answer must be consistent with the protocol’s own philosophy: trust no one for long. Constantly reassess.

The trust registry is not a central database with a single operator. It is a federated, append-only log of observed behaviors — conformance records, protocol interactions, agreement violations — contributed by every participating operator. Each operator maintains their own view of the registry and computes trust scores locally using the same published algorithm. Because the inputs are observable events and the algorithm is deterministic, independent operators computing trust for the same platform should arrive at substantially the same score. Divergences are themselves a signal — if Operator A rates Platform X at 0.85 and Operator B rates it at 0.4, the discrepancy indicates that one operator has observed behavior the other hasn’t, which warrants investigation.

No single entity can unilaterally grant or revoke trust. Trust is earned by the platform’s own behavior as observed by the network. The decentralized approach is harder to implement but fundamentally more resilient — and more honest. Trust is what the network observes, not what any authority declares.

6. A Day in the Life — Scenario Walkthrough

7. From Coordination to Threat Detection

The scenario above illustrates the core insight: every safety mechanism in the DACL produces security data as a byproduct. No additional detection system was required to identify the anomalous platform. The coordination protocol itself surfaced the threat.

Threat classification framework

8. Defense Applications

8.1 Counter-UAS target set reduction

The fundamental problem with C-UAS in congested airspace is false positives. Current systems detect everything and classify nothing. When the airspace contains 200 legitimate drones, a detection-only system generates 200 alerts per scan cycle. Operators cannot process this volume; the system becomes operationally useless.

The DACL reduces the target set to the platforms that matter. Every cooperative, conforming platform in the system is verified in real time — its identity, its intent, and its adherence to that intent. These platforms can be filtered from the C-UAS target set automatically. What remains is the small set of non-cooperative or anomalous platforms.

In the scenario above, two of three platforms were immediately classifiable as non-threats through protocol data alone. At scale, with 200 cooperative platforms and 3 unknowns, the reduction is 98.5%.

8.2 Coordinated attack detection

A coordinated drone swarm attack — multiple platforms converging on a target simultaneously — is statistically anomalous against the background of cooperative traffic. The attacking drones either participate in the protocol (revealing coordinated intent that doesn’t match legitimate mission patterns) or they don’t (creating a cluster of non-cooperative platforms converging on a single point). In both cases, the DACL surfaces the anomaly automatically because the cooperative traffic around it provides the behavioral baseline.

8.3 Installation domain awareness

The trust registry becomes an intelligence product. It aggregates behavioral history across time and geography. An operator with consistently low trust scores across multiple installations may warrant investigation even if no single event is conclusive. The DACL provides not just real-time alerting but longitudinal behavioral profiles — the kind of pattern analysis that is impossible with point-in-time detection systems.

9. Simulation and Validation

All protocol rules, trust scoring parameters, and threat detection thresholds are validated through an open-source, lightweight, faster-than-real-time airspace simulator. The simulator models drone positions, intents, and protocol interactions without physics — a “drone” is position, velocity, intent, trust. Run 10,000 simulated operations days overnight on a single machine.

The scoring engine evaluates outcomes across six dimensions: safety, efficiency, fairness, throughput, resilience, and protocol health. Adversarial agents test the protocol’s security properties: false intent, systematic deviation, identity spoofing, trust farming, priority gaming, and coordinated attack patterns.

The simulator publishes data in the same WebSocket format as the production platform. The same supervisor UI that manages live drone operations renders simulated operations — enabling demonstration at scale, operator onboarding sandboxes, and RPIC fleet management training.

The simulator and scoring engine will be published as open-source tools. Other platform operators can test their planning agents against standard scenarios to prove interoperability and conformance.

Detailed simulation results, parameter sensitivity analysis, and validated thresholds will be added as experimental data becomes available.

10. Implementation Roadmap

11. Why Virabelo

The Distributed Airspace Coordination Layer requires a builder that sits at the intersection of commercial drone operations and defense airspace awareness. That intersection is small. Virabelo occupies it.

The core components exist today and are production-proven. Virabelo’s Collision Probability Engine — the physics-based, continuous P(collision) computation that underpins the DACL’s real-time safety verification — is operational software, not a design document. It runs identical math for training simulations and live operations, with aircraft-type-specific motion models, plan-aware projections, source trustworthiness scaling, and four-tier graduated alerting. The Airspace Service fuses ADS-B, weather, NOTAMs, and geospatial data into a unified operational picture. These are not planned features. They are running code.

The training pipeline creates a data moat. Every pilot who trains on Virabelo’s PX4 SITL simulator generates scored telemetry — labeled state-action pairs that train the Flight Agent’s autonomous emergency behavior. This creates platform-specific autonomy models grounded in real human decisions, not theoretical control algorithms. The data compounds: more pilots → better agents → more operators → more data.

The regulatory knowledge is deep. Twenty years of unmanned systems experience across defense and commercial domains. Deep expertise in Part 107, Part 108, Part 146 (ADSP), and Part 89 (Remote ID). The protocol is designed to work within the regulatory framework, not around it — complementing UTM, leveraging Remote ID, and producing the compliance documentation that Part 108 requires.

The protocol specification and the simulator will be published as open standards and open-source tools. The goal is not to own the coordination layer but to define it — and to be the company whose platform, whose trust registry, and whose simulation environment become the foundation that the industry builds on.

Virabelo, Inc. · Zero-Trust Distributed Airspace Coordination · March 2026