Time-sensitive networking (TSN) solutions moving from labs to military platforms

• Share on X
• Share on LinkedIn

Story

August 10, 2026

Military networks have a timing problem – and solving it is about to change how de­fense platforms are built. Ethernet is the default communication medium across today’s defense and aerospace systems, driven by open-architecture mandates, commercial availability, and bandwidth demands that legacy buses like MIL-STD-1553 were never designed to meet. Standard Ethernet offers no guarantee, however, that a critical message will arrive when it needs to, and in a weapons system, a radar system, or an autonomous platform, “probably on time” is not good enough.

Time-sensitive networking (TSN), a suite of IEEE standards that adds mathematical timing guarantees to standard Ethernet, is the industry’s answer. It is moving from test labs into program specifications, fielded hardware, and the digital backbones of next-generation military platforms.

For years the defense industry worked around that timing problem with dedicated buses – MIL-STD-1553, ARINC 429, and discrete wires, one connection for each critical link. While that approach works, it doesn’t scale. As platforms add more sensors, more radios, more artificial intelligence (AI) compute, and more autonomous functions, the number of dedicated connections required becomes unmanageable.

“TSN adds time awareness and bounded time determinism to Ethernet,” says Aaron Frank, senior director of C5ISR product management at Curtiss-Wright Defense Solutions (Leesburg, Virginia). “Five years from now, I expect TSN to be a well-entrenched technology that is replacing a lot of the individual buses that we see in communication mechanisms today.”

What TSN does

Standard Ethernet is, as Frank puts it, a best-effort mechanism. Messages are very likely to get from one place to another, but there is no guarantee on when. Quality-of-service features can move high-priority messages to the front of the queue, but that still doesn’t make the timing predictable – congestion can slow things down regardless of priority.

Frank uses an analogy: “It’s like emergency personnel going to a fire. You can give them all the green lights, but you can’t guarantee the firefighters will be there in 22 seconds from the call. That’s what time-sensitive networking will do – it will bring time criticality to Ethernet.”

According to the IEEE Standards Organization, TSN handles the time issue through a set of IEEE 802.1 standards that work together: IEEE 802.1AS handles clock synchronization across the network, keeping all nodes within sub-microsecond accuracy; IEEE 802.1Qbv introduces a time-aware shaper that divides time into cycles and reserved windows, so that high-priority streams transmit only when their slot opens; and IEEE 802.1CB provides seamless redundancy by replicating critical frames across independent paths. The result is a network where the delivery time of a message is not just fast but bounded, which means that the message is mathematically guaranteed to arrive every time within a defined interval.

“TSN can set up and guarantee mathematically that a message will get from A to B in exactly one microsecond, not 1.01 microseconds,” Frank says. “You can put time latency, determinism, and jitter characteristics on critical messaging.” (Figure 1.)

[Figure 1 | Curtiss-Wright’s DuraCOR 313 is an ultra-small-form-factor mission computer featuring dual Gigabit Ethernet ports with TSN support, a four-core CPU, and an integrated 18-core Intel GPU. Image via Curtiss-Wright.]

Dr. Justin Pearson, senior director of architecture and business growth for A&D at Wind River (Alameda, California), says that TSN “dramatically outclasses MIL-STD-1553 in bandwidth,” offering up to 1 Gb/sec to 10 Gb/sec compared to the latter’s rigid 1 Mb/sec limit. The practical implication for platforms that currently depend on 1553 for critical data is meaningful – TSN doesn’t just replace the timing guarantee, but rather replaces it with a pipe that is orders of magnitude wider.

The drivers of TSN adoption

TSN has been in development for years. What has changed recently is the convergence of two forces: a policy push and a standards milestone.

On the policy side, Pearson points to the Army’s Future Vertical Lift Architecture Framework and its Architecture Collaboration Working Group as the initial catalyst for TSN in the military. The key concept developed there was the “digital backbone” – a TSN-based Ethernet architecture capable of hosting flight-critical, mission, and logistics data on a single deterministic network.

That concept is now being realized in hardware: GE Aerospace is building a TSN digital backbone for the Army’s Future Long Range Assault Aircraft, the MV-75, implementing the IEEE 802.1DP aerospace profile and using TSN switches and gateways to integrate legacy buses including 1553 and ARINC-429 onto the new network.

A digital backbone’s appeal is that it “serves as the platform’s central nervous system, connecting major subsystems and enabling the movement of information throughout the vehicle or mission system," says Keith Menezes, business development specialist at Abaco Systems (Huntsville, Alabama).

“Rather than maintaining multiple specialized networks, TSN can help reduce network fragmentation by enabling a greater degree of Ethernet convergence – supporting reduced SWaP-C, simplifying system integration, and creating a more flexible foundation for future technology insertion,” he adds.

On the standards side, the aerospace TSN profile – IEEE 802.1DP, also known as SAE AS6675 – was finalized and released in September 2025. That approval matters because TSN is not a single switch you flip; it is a coordinated set of capabilities that must be modeled, configured, and profiled for a specific operating environment.

“The aerospace profile is specifically taking into consideration the type of networks used in airborne platforms,” Frank says. “They’re much different than a public cellular backhaul environment. There are different parameters and different use cases.”

Frank also notes that TSN is now appearing in military and aerospace programspecifications as a flow-down requirement – customers are writing it into their requirements documents. “There’s a known problem: You put data on Ethernet and you lose that determinism without something like TSN,” he says. “TSN solves that, and we’re seeing customers use it as a requirement to solve this problem.”

The integration challenge

Unfortunately, Frank notes, it is hard to implement TSN in a fielded system: “TSN is not for the faint of heart,” he says.

The core challenge is that a TSN network has to be modeled before it is deployed, with every critical message flow in the system identified and characterized. That modeling then produces a set of configurations for the network switches and endpoints that, once loaded, guarantee the timing. The user cannot simply turn TSN on and expect it to work.

“You have to understand all of the network traffic, all of the message flows that are time-critical, and the system has to be configured to ensure those messages can get from their sources to their destinations at the time expected,” he continues. “It’s a two-step process: modeling before the deployment environment. You can’t simply turn TSN on and expect everybody who wants that bandwidth can get it.”

Wind River’s Pearson points to legacy platforms as the integration challenge. Most military vehicles and aircraft were not designed for deterministic Ethernet, and wholesale replacement of existing buses is neither practical nor affordable. Wind River and DornerWorks have demonstrated one approach: Introduce a TSN-aware layer – FPGA [field-programmable gate array] logic combined with RTOS [real-time operating systems] and hypervisor support – that time-slices and prioritizes traffic classes, lending deterministic latency and jitter to critical messages without requiring changes to existing transport protocol application interfaces.

“One of the lowest-risk and simplest approaches is to start with an enclave or high-priority endpoint that would benefit from the bandwidth TSN introduces,” Pearson says. (Figure 2.)

[Figure 2 | A diagram illustrating the DornerWorks and Wind River joint TSN solution, in which DornerWorks TSN FPGA IP is integrated with Wind River’s VxWorks RTOS and Helix Virtualization Platform. Image via DornerWorks.]

The commercial world’s experience with TSN also only goes so far. “Commercial TSN typically assumes controlled environments, moderate node counts, and limited cyber and [electromagnetic] contestation,” Pearson notes. “Military platforms must operate under jamming, physical damage, and classified threat models that stress timing and redundancy far beyond industrial use cases.”

In other words, a commercial TSN implementation designed for a factory floor or a vehicle-assembly line has not been tested against an adversary actively trying to falsify timing messages or degrade the network under electromagnetic attack.

Menezes cautions against treating TSN as a clean-break replacement. “For many legacy platforms, a complete network replacement may not deliver sufficient return on investment,” he says. “A prac­tical modernization strategy often focuses on introducing Ethernet and TSN capabilities where new mission functionality is being added, while preserving legacy systems that continue to meet reliability and mission requirements.”

TSN and the standards ecosystem

TSN’s relationship to the Department of Defense’s (DoD’s) modular open systems approach (MOSA) and open-architecture mandates is straightforward in principle: It is an IEEE standard, open to any implementer, and it meets the non-proprietary requirement at the heart of MOSA. Frank points out that Curtiss-Wright’s TSN-enabled switch and its single-board computers are aligned with the Sensor Open Systems Architecture, or SOSA, Technical Standard, and are designed to work together within that framework.

The relationship to the SOSA approach and the Future Airborne Capability Envi­ronments, or FACE, Technical Standard, is more nuanced. Pearson notes that neither the FACE nor the SOSA approach currently specifies a preferred digital backbone implementation, but that there is an expectation to standardize the backbone itself through IEEE P802.1DP and SAE AS6675 – the same aerospace profile that was finalized in 2025. That standard selects and restricts TSN features, protocols, and security mechanisms specifically for aircraft and defense applications, which is the mechanism by which TSN will eventually become a standard part of the MOSA tool kit rather than a separately negotiated requirement on each program.

Menezes also warns that TSN doesn’t exist in isolation from other networking approaches. DDS, or Data Distribution Service, middleware remains important across many MOSA, SOSA, CMOSS [C5ISR/EW Modular Open Suite of Standards], and MORA [Modular Open Radio Frequency Architecture] ecosystems because it addresses data distribution and software interoperability at a higher layer than TSN can handle. “TSN and DDS are not competing technologies,” Menezes says. “In many architectures they are complementary, with DDS providing middleware services while TSN provides deterministic transport capabilities within the network infrastructure.” (Figure 3.)

[Figure 3 | The Abaco Systems SBC3513L is a 3U VPX single-board computer designed for mission processing applications requiring real-time computing, sensor fusion, networking, and artificial intelligence (AI) acceleration. Image via Abaco Systems.]

Safety certification remains thorny: Frank draws a direct comparison to the multicore processing certification hurdle that took years to resolve with authorities. Flight-critical systems must be certified to Design Assurance Level A (DAL-A) – meaning a failure of the system could cause the loss of the aircraft. GE Aero­space is working toward certifying its Future Long Range Assault Aircraft (FLRAA) TSN backbone to DAL-A, but Frank says it may take several years until the certification authorities “understand how to implement that and accept it in a true airborne survival system.”

In the near term, mission-critical systems – radar, sensor fusion, autonomy, weapons coordination – are the areas in which TSN will gain its first operational footholds, because the certification bar, while still demanding, is more easily managed than DAL-A flight controls.

What’s coming next

The trajectory Frank describes is a familiar one in defense technology: labs first, then system-integration labs, then fielded systems.

“In the last couple of years we have worked with customers setting up TSN test labs, just laboratory environments, to understand what TSN does,” he says. “Now that the aerospace profile has been released, we’re going to see more and more adoption. It’s going to go from the labs to the [lists] to deployed.”

The applications that stand to benefit most are exactly the ones where the defense industry is investing most heavily: sensor fusion, where data from multiple sources has to be correlated and processed with timing precision; autonomy and swarming systems, where coordinated behavior depends on synchronized communication; and weapons coordination, where the latency of a missed time window can mean a failed intercept. “A radar system that does not detect an incoming threat in time may fail to deploy countermeasures,” Frank says. “That time criticality is a mission system – maybe not flight-critical, but mission- or safety-critical. It’s those types of systems where you must ensure that time criticality is respected.”

The promise, once TSN is entrenched, is a simplification of platform network architecture. The proliferating dedicated buses that today’s engineers spend so much time managing – 1553, ARINC, discrete wires, one for each critical connection – can be consolidated onto a single deterministic Ethernet backbone that handles mixed-­criticality traffic with guaranteed timing, at bandwidths those legacy buses could never approach.

“We will see TSN being used to move things to not only a net-centric environment, but to a time-aware, net-centric environment,” Frank says. “I think that has huge positive implications.”

Time-sensitive networking (TSN) technology will be leveraged for the U.S. Army’s Future Long Range Assault Aircraft (FLRAA). Pictured is the Bell V-280 Valor developed for the Army's Joint Multi-Role Technical Demonstrator program as a precursor to the FLRAA. The U.S. Army chose Bell to develop the MV-75 FLRAA. Photo courtesy of Bell and U.S. Army.