Network Redundancy Design for Remote ATC Facilities

A conventional control tower fails piece by piece: lose the radar feed and the controller still has eyes on the runway, a working radio, and a physical vantage point to fall back on. A remote tower has no such gradient. When its data link goes down, the controller loses all situational awareness simultaneously, not incrementally, because a remote ATC facility has no fallback mode of operation the way a physical tower does. That single fact is why network redundancy sits at the center of trust in digital air traffic control.

The data link as the foundational dependency of remote ATC

The sensor cluster at a remote airfield, cameras, radar, weather instruments, generates a constant stream of data that has to travel, sometimes across long distances, before it ever reaches a controller. Every mile of that path is a place where something can go wrong. High-definition cameras and sensors at the airport feed a separate control center that can sit "hundreds or even thousands of miles away", as this kind of remote-tower architecture is commonly described. It lets one control center cover airports that could never justify a staffed tower of their own, but it also means the controller's entire awareness of the airfield depends on a connection that has to hold, continuously, across that entire span.

The scale this can reach in practice is already visible. A controller in Jeddah sees AlUla only through what the data link delivers. There is no backup pair of eyes at the airport, no local radio operator filling in gaps, no physical presence to default to if the feed drops. The tower, in any functional sense, is the connection. Everything that follows in the design of these systems, every layer of redundancy, every failover mechanism, exists because that one dependency has no substitute.

Remote tower system components and failure points

Understanding where redundancy needs to live requires understanding the architecture it protects. A remote tower system breaks down into five distinct layers, and each one can fail on its own. Redundancy has to be built into all five rather than treated as a single network problem to solve once. Those layers are the sensor cluster at the local airport, the data transmission network connecting the airfield to the remote tower center, data processing servers at the airport, the remote tower center itself with its video walls and controller positions, and the module control and voice communication servers that sit at the center.

Each layer fails in its own way. Cameras can be blocked or lose power. Transmission networks can be severed or overloaded. Processing servers can crash. The remote tower center can lose power or be physically compromised. None of these failure modes is exotic, and none of them is new to engineering generally, but in this context each one has the same consequence: a controller loses the picture.

Newer systems are adding more to that picture, which raises the stakes on the network carrying it. Atrak's MAESTRO platform, unveiled in May 2026, combines high-resolution cameras with optical zoom alongside infrared and thermal imaging for night operations and bad weather. That sensor diversity helps a controller see more, but it also means more data streams that all need reliable transport. MAESTRO's use of AI-based object recognition and radar-optical data fusion adds further to what the network has to carry, and raises the cost of any interruption, because the data isn't just more voluminous, it's more load-bearing for the judgment calls a controller makes in real time. And because the remote tower model often has one center serving several airports at once, a failure at the center can touch every airport the center is responsible for simultaneously.

The specific network requirements that define whether a system is trustworthy

The FAA's request for proposals, issued in April 2026, lays out what it expects: low latency, continuous visual coverage, and consistent operation under varying conditions. These aren't aspirational statements tucked into a vision document; they are procurement criteria that a vendor has to meet to win a contract.

Latency matters in a very concrete way. If a controller is looking at video that lags behind real time, even by a small margin, the clearance that controller issues can be built on where an aircraft used to be rather than where it actually is when the pilot receives the instruction. Continuous visual coverage matters for a related reason: a gap in video, even a brief one, can't be filled in with confidence the way a missing radar return sometimes can, because in a busy traffic pattern a controller needs to see what's happening, not infer it. And "varying conditions" covers a wide range of stress on the system: rain, fog, and ice that degrade camera optics, electromagnetic interference, and the ordinary wear on physical infrastructure. Redundancy has to hold up across all of that, including clear skies with no wind.

There's a parallel requirement that's easy to overlook because it isn't visual: the voice communication servers at the remote tower center. If the video feed is fully redundant but the voice link isn't, a controller can watch an aircraft taxi into position and still have no way to tell the pilot to hold. Redundancy that covers only part of the system functions, in practice, the same as having no redundancy.

How working systems achieve redundancy in practice

The vendors building these systems have converged on a few recurring design principles, and the clearest one is hot failover: backup systems that are already running, already synchronized, and ready to take over the instant something upstream fails, without the controller noticing a gap. REVAL platform combines secure-by-design software, a system architecture with no single point of failure, built-in redundancy, and hot failover capability. Each piece in that list covers a different kind of failure. No single point of failure means every component in the chain has a parallel counterpart ready to carry load if the first one drops out. Hot failover means that counterpart isn't sitting cold and waiting to be switched on, it's already running in parallel, so the handoff happens instantly rather than requiring a restart.

Redundancy at the sensor level matters as much as redundancy in the network. MAESTRO combines optical, infrared, and radar inputs, so if one sensor type is obscured or knocked out, the controller still retains a degraded picture. The picture degrades, but it doesn't disappear. Remote tower center operations extend redundancy beyond hardware into staffing: controllers can back each other up, and centers can run on a 24-hour schedule with the flexibility to open and close on demand. That's a form of redundancy built into personnel and scheduling rather than wiring.

The September 2026 contract covering Stockholm-Västerås changes who is responsible for keeping the system redundant, with the vendor retaining responsibility for the digital infrastructure for the full 15-year term of the contract, which takes effect on January 1, 2028. That shifts the burden of maintaining and verifying redundancy from the airport operator to the vendor, for the life of the agreement. Redundancy, under this model, becomes a standing contractual obligation rather than a one-time engineering checkbox.

There's one more dimension of redundancy that physical towers never had to contend with: cybersecurity. Searidge's documentation lists real-time cyber threat detection and strict remote access controls as features distinct from the resilience features covering hardware failures. The reason for the separate category is straightforward. A cyber intrusion that disrupts the data link produces the same blank screen as a severed cable or a dead server. From the controller's chair, there's no difference.

What happens when redundancy fails: the RTC concentration risk

The efficiency of the remote tower center model comes from centralization, and that same centralization creates a risk that no amount of redundancy at the link level fully erases: if the center itself goes down, every airport it serves can lose ATC coverage at the same time. This is the strongest objection to the model, and it deserves to be taken as a serious engineering and regulatory problem rather than dismissed as a reason to abandon the technology.

The scale involved is already substantial in current deployments. Belgium's Namur remote tower center, planned to manage both Charleroi and Liège airports by 2026, means a single facility outage would remove coverage from two airports at once. The Sundsvall center goes further: it serves Sundsvall-Timrå, Sälen, Örnsköldsvik, and Linköping today, and will add Stockholm-Västerås starting in January 2028, bringing the total to five airports whose ATC coverage converges on one building. No link-level failover, however well engineered, changes the fact that a center-level failure touches every one of those airports simultaneously.

In the United States, there is no FAA-approved playbook for what happens next in that scenario. The procedural response to a remote tower center outage, not just the technical fix, remains undefined in the American system. Controller unions have raised a related concern: centralized digital operations may weaken situational awareness during the highest-workload moments, which are also the moments when the consequences of any failure are most severe. The objection here isn't that redundancy can't be engineered. It can. The objection is that redundancy at the link level doesn't substitute for a tested, approved procedure at the system level for what controllers and pilots do in the minutes after a center goes down, before service is restored or handed off elsewhere. Hot failover and redundant routing keep the connection running. They don't answer the procedural one.

How U.S. regulatory stasis has left redundancy standards undefined

That procedural gap in the United States didn't arise because the underlying technology is unproven. It arose because the certification requirements changed in the middle of a live deployment and were never carried through to completion. The clearest illustration is Leesburg Executive Airport in Virginia, where a remote tower operated for years before withdrawing in 2022, citing no reasonable path forward for approval. The FAA terminated the tower's operations in 2023.

What happened at Leesburg was procedural. In 2021, the FAA introduced new certification requirements for remote tower systems, later formalized in a draft advisory circular titled "Remote Tower (RT) Systems for Non-Federal Applications," dated February 18, 2022. Those requirements arrived after the system had already been built and was already running. A vendor that had designed and deployed a system against one set of expectations found itself being evaluated against a different, newer set it had no opportunity to design toward from the start.

The U.S. has no certified operational example from which to build failure-mode procedures, while Sweden, Belgium, and Ireland each have years of live data to draw on. An analysis by the Reason Foundation found that the FAA's institutional posture toward remote and digital tower technology has been resistant, and the analysis noted it's genuinely unclear whether the delays reflect careful safety caution or simple bureaucratic inertia. The FAA's April 2026 request for proposals, covering up to 50 units over five years, shows procurement is moving again. But a procurement requirement is not an operational certification standard, and the redundancy specifications written into an RFP don't become approved failure-mode procedures until a system has actually been certified and run in live service. The Digital Tower Technology Coalition, whose members span airports, controllers, manufacturers, and federal partners, has said publicly that the primary barrier is the FAA's slow movement on clear standards, not any shortcoming in the technology itself.

What the global operational record establishes about redundancy

Outside the United States, the picture looks different, because other regulators defined their requirements before systems were built rather than after. A remote tower at Örnsköldsvik Airport in Sweden, the first operationally approved remote tower anywhere in the world, has been running continuously since April 21, 2015, approved by the Swedish Transport Agency under existing air traffic control regulations extended to cover a new kind of application. More than a decade of continuous live operation is an operational record.

The Sundsvall center now serves five airports, and that scale of multi-airport operation has been proven through daily live traffic, not simulation. No airport authority commits to a 15-year ATC contract on a technology it doesn't trust. Ireland's aviation authority contracted for a multi-airport remote tower center in Dublin covering Cork and Shannon back in 2015, so cross-border, multi-airport remote ATC has been running in Europe for over a decade. And newer entrants are building their own track record the same way: MAESTRO's validation at Václav Havel Airport in Prague involved more than 18 months of development and testing against real-time operational data, including emergency scenarios, in a live heavy-traffic environment.

What ties these deployments together is that the regulatory framework came first. Redundancy requirements were set before the systems were built.

Redundancy design and the uncontrolled airport safety gap

All of this engineering detail matters only in light of what a failed remote tower actually costs, compared to what existed before it. A remote tower that goes down at a previously uncontrolled airport does not simply return that airport to its baseline condition. It removes a safety service that pilots and operators have, by then, already come to rely on.

The United States has roughly 527 towered airports, set against nearly 20,000 non-towered landing facilities, a category that includes public airports, private airstrips, grass and turf runways, gravel strips, and seaplane bases. The vast majority of U.S. airports where a remote tower might someday be installed currently operate with no ATC coverage at all. That baseline is the real comparison point for the redundancy argument: a remote system that fails occasionally but works most of the time is still a net safety gain over an airport with no tower coverage whatsoever.

The risk of that baseline is not abstract. NASA's Aviation Safety Reporting System has documented recurring near-miss patterns at uncontrolled airports, including an incident reported by a flight instructor and a corporate jet pilot involving a near miss where the jet took off while another aircraft was still in conflict on the same runway environment. That is the condition remote tower technology is built to change. Redundancy design, in this light, is the mechanism that determines whether the safety gain these airports stand to receive is real and durable, or fragile and occasional. The engineering has to be rigorous precisely because the airports on the other end of it have nothing else standing between them and the status quo.