Scalable Multi-Airport Remote Tower Hub Design
One hub's controllers manage multiple small airports that can't afford towers alone.
Most U.S. airports have no control tower at all, and the gap isn't an oversight. It happens because the staffing and funding model was built for busy fields, and it was never designed to reach small ones. This article traces how a different architecture, the multi-airport remote tower hub, closes that gap by centralizing the technology, staffing, and data infrastructure a single small airport could never justify on its own.
Why small airports remain uncontrolled
At a non-towered airport, order depends entirely on pilots agreeing, by radio and by habit, to do the same thing in the same way. Everyone talks on the same frequency, everyone flies the same pattern, and everyone has to trust that the plane ahead is playing by the same rules. That system works until someone breaks it. A single pilot who cuts the base-to-final turn short, who rolls onto the runway without calling it out, or who simply assumes the pattern is empty when it isn't, can turn an orderly sequence into a scramble with no referee. On a high-traffic day at a busy non-towered field, the common traffic advisory frequency fills with overlapping calls, and no one, not a controller, not a supervisor, not any single authority, is sequencing arrivals or catching a developing conflict before it becomes one.
The underlying risk is a matter of geometry. Pilots can only avoid what they see, and a wing, a fuselage, or a shadow outside the cockpit's field of scan might as well not exist until it's too close to matter. NASA's Aviation Safety Reporting System has logged a steady stream of runway incursions, opposite-direction takeoffs, and near mid-air collisions at fields with no tower, and that record almost certainly understates the true count, since many such events never reach an official reporting channel.
The traditional fix is a staffed control tower, where a person watches the runway around the clock, with trained eyes above the traffic and a radio in hand, and solves the geometry problem that way. It also costs money few small airports have: a physical structure, continuous staffing, and capital outlay that doesn't pencil out against the traffic volumes most of these fields see. The tower model isn't failing small airports through bad planning. It simply doesn't scale down to them, and no amount of incremental funding changes that arithmetic. Solving the problem requires a different architecture.
Digital towers and the end of the physical window
A digital tower system does the same job a traditional tower does, sequencing and separating traffic, issuing clearances, watching the runway, but it does that job through cameras, sensors, and displays instead of a pane of glass. The FAA defines a Digital Tower (DT) system as one that provides Airport Traffic Control Tower (ATCT) services using cameras, sensors, displays, and supporting equipment installed at the airport, with controllers working entirely from dedicated digital screens rather than looking out at the airfield directly.
The FAA's own terminology shift signals how much this matters: the agency moved from calling these systems "Remote Towers" to calling them "Digital Towers," a change that puts the emphasis on the underlying technology rather than on where the controller happens to sit. That's not a cosmetic adjustment. It tells the industry that what defines the system is the digital sensor and display stack, not the distance between the controller and the runway, and that distinction is what opens the door to flexible siting later in this argument.
The camera and sensor suite can also do things a human eye in a tower cab never could. Infrared and high-definition cameras extend a controller's situational awareness through fog, rain, and darkness. Zoom capability can pick out wildlife on a runway surface from a distance that would leave it invisible to the naked eye from a standard tower cab. If an airport's visual and sensor picture becomes a transmissible data stream instead of a sightline out a window, the controller watching it doesn't need to be anywhere near the airport. The controller position can sit at the airport, or it can sit at a Remote Tower Centre hundreds of kilometres away, with no difference in the service delivered. Location stops mattering once the view is digital, and that is what makes everything that follows possible.
Centralizing infrastructure at a hub turns a per-airport cost problem into a shared platform
When a Remote Tower Centre (RTC) hosts controller positions for several airports at once, it takes the capital and staffing costs that make a standalone tower unaffordable at any one small field and spreads them across a network, where they become sustainable. This is where the argument shifts from what digital towers can do technically to why they make economic sense at scale.
A single RTC can host dozens of remote controller positions, each one assigned to a different airport, while the physical facility, the sensor-processing systems, the display infrastructure, and the supervisory staff behind them are shared across every site the hub serves. Small airports live under constant funding pressure: limited revenue, rising capital needs, and no realistic path toward staffing a dedicated tower year-round. The hub model flips that math. A network spreads an airport's fixed costs, so it no longer has to justify them alone, and what decides if the investment pays off is total traffic across the network, not any one airport's traffic. Infrastructure that would sit idle most of the day at one small field stays busy across every site an RTC serves, so the lower an airport's traffic is, the bigger its cost advantage. Staffing follows the same pattern: controllers at an RTC can rotate across positions and schedules in ways no single-airport tower could support, which makes extended-hours coverage and schedule continuity achievable without the unsustainable headcount a standalone tower would need.
U.S. policy has already caught up to this logic. The FAA Reauthorization Act of 2024 added remote towers as eligible under the Contract Tower Program, so small airports can now get a path to tower service and lower their per-airport expense. It's a legislative acknowledgment that shared infrastructure is the workable route forward.
The obvious objection is that centralizing service into one hub creates one point of failure: if the RTC goes down, every airport it serves loses coverage at once. But if a hub has backup systems, geographically distributed facilities, and failover protocols, it carries more redundancy than the status quo at most small towered airports, where one staffing shortfall can close the tower. Concentrating infrastructure doesn't concentrate fragility if the hub is engineered for it; it replaces a fragile single point of staffing with a system built to absorb failure.
Sensor integration and the data infrastructure that makes a hub feed multiple airports simultaneously
Serving several airports from one hub depends on a sensor and data architecture that can gather, process, and present live conditions from each site without losing the detail a controller needs at any one of them. Every airport on the network feeds the hub through its own sensor suite: camera arrays covering the runway, the approach paths, and the ramp; infrared sensors for night operations and low visibility; radar or ADS-B feeds carrying aircraft position; and surface sensors reporting runway state. None of that data is useful to a controller unless it arrives intact and current, reconstructed on a display with the same spatial and temporal coherence that a physical tower window delivers automatically, just by virtue of being a window.
The camera and sensor stack isn't simply a stand-in for a controller's eyes; it extends them. Infrared and high-definition imagery let a controller watch traffic through conditions, and from angles, a fixed tower cab never offered, and the same zoom that spots wildlife at a distance can also catch debris or other runway hazards a human eye would miss.
None of that works without a network connection built to the standard of the job it supports. Latency, bandwidth, and redundancy in the link between an airport's sensors and the hub must keep a controller's display showing the runway as it is right now, not as it was a few seconds ago, because in this line of work that gap is the entire safety margin. Hub designers treat that data link as safety-critical infrastructure in its own right, because it is not a commodity internet connection. Each airport's sensor footprint is also built to stand alone operationally: a camera outage or maintenance event at one field stays contained to that field and doesn't touch service at any other airport on the hub, which keeps a local problem from becoming a network-wide one.
Controller workstation design and the cognitive demands of multi-site awareness
The workstation is where hub architecture is tested most directly, because it has to give a controller watching one or more airports the same working awareness a controller physically present in a tower cab would have. In place of the tower cab's panoramic window, the workstation presents an array of high-resolution displays carrying camera feeds, the radar picture, flight data, and communications for whichever airport or airports that controller is assigned.
How that information is laid out isn't a cosmetic choice. A controller has to be able to tell, instantly, which airport, which runway, and which aircraft a given display is showing, without the physical orientation a real environment provides without effort. Tools built into the interface, automated conflict alerts, aircraft tags overlaid on the camera picture, surface movement tracking, exist to replace the peripheral cues a controller in a physical tower absorbs passively just by being there.
Moving a controller from managing one airport to managing several from a single workstation changes the nature of the job's workload, not just its intensity. IFATCA's position is direct on this point: remote towers have to deliver a level of service at least as safe as the tower service already in place, and workstation design is the main lever for meeting that standard. Hub designers have to build in clear boundaries around what a controller is actively managing at any moment, clear signals when attention shifts from one airport to another, and a defined way to redistribute workload when traffic at more than one site peaks at the same time. There's a secondary payoff: well-designed digital work environments also tend to draw stronger interest from prospective controllers, which matters to air navigation service providers watching a tightening pipeline of new recruits.
Traffic sequencing across sites and simultaneous operations at multiple airports
A hub controller doesn't have to run every assigned airport at full intensity at the same time. The model works because hub operators use traffic-condition tiers, staggered timing, and defined workload rules to keep any one controller's real-time demand within safe limits. The core insight behind the whole approach is simple: most small airports spend most of their operating hours with light, well-spaced traffic, so a controller can hold safe awareness of several such fields at once precisely because the moment-to-moment sequencing demand at any one of them stays low and predictable.
Traffic-condition tiers set the operating limits directly: a controller might hold several airports under normal low-traffic conditions, with built-in rules that reduce the number of active airports as traffic density climbs at any single site. Scheduling is a second lever. If a hub's planners stagger known peak periods across its airports, using local traffic patterns, scheduled flights, and predictable surges, the odds of two airports peaking on the same controller at the same time drop sharply.
What remains open is how many airports one controller can safely hold at once and under what conditions, and every operating RTC has to answer that question for itself, through real traffic data, tested procedure, and regulatory sign-off, before it can add another airport to its portfolio. Sweden's LFV offers the clearest answer so far: having pioneered the concept at Örnsköldsvik in 2015, LFV now runs RTC Stockholm managing four airports from one center. Norway's Avinor shows the scaling path, running its RTC out of Bodø and adding seven more airports under a July 2024 agreement with Kongsberg Defence & Aerospace. Belgium's Skeyes is testing the model under active development: its Digital Tower Test Center in Steenokkerzeel, launched in April 2024, is the prototype for a new RTC in Namur set to manage both Charleroi and Liege by the end of 2026.
Tiered staffing models and the workforce flexibility hubs enable
A standalone small airport's tower staffing is a binary condition: either a controller is on position, or the airport has no tower service at all, with no middle ground and no way to add capacity for a busy afternoon or pull it back for a quiet one. A hub breaks that binary. Controllers at an RTC work as a shared pool, so if a controller isn't actively sequencing traffic at one airport, they can hold monitoring awareness at another, and scheduling can track predicted traffic across the whole network instead of guessing at one airport's needs in isolation.
That pooling makes extended hours realistic in a way no single airport could manage on its own. An airport that could never pay a controller to sit through a quiet overnight shift can still get that coverage, because an RTC controller's daytime workload is already spread across several sites. Digital towers can also back up airports that already have a staffed Class D tower, covering nighttime hours when the physical tower is closed or stepping in during an outage, which addresses one of the most common service gaps at part-time towered fields directly.
The staffing model carries a workforce dimension too. Younger prospective controllers seem to want hub environments more than isolated single-airport postings, and that matters because the national airspace system is working through a controller pipeline shortage. Basing controllers at a shared central facility rather than assigning them to remote single-airport posts also gives them more room to move between roles and build a career, which should reduce attrition among controllers already trained and on the job. None of this displaces the controller's job; it makes the job more sustainable to staff and more attractive to stay in.
The U.S. regulatory environment and the path to hub deployment
A legislative step toward this model has already been taken. The FAA Reauthorization Act of 2024 made remote towers eligible under the Contract Tower Program, opening a funding path for small airports to gain tower service through lower-cost remote systems rather than a conventional staffed tower. That's a real policy commitment, but it is a starting point, not a finished framework. Europe's operators, Sweden's LFV, Norway's Avinor, and Belgium's Skeyes among them, have multiple years of operational data behind their multi-airport hub deployments, built under their own national regulators. The FAA's path to approving a true multi-airport hub in U.S. airspace still has to establish its own standards for sensor performance, data link reliability, and controller workload limits, each validated against the same safety-equivalence bar that governing bodies have already set for remote tower service generally. The technology, the economics, and the staffing logic all point toward the hub model as the realistic way to bring tower service to airports that have gone without it for decades. What's left is the regulatory work of proving it, airport by airport, under U.S. rules, with the same rigor that other operators have already applied to their own systems.
