Link 16 is the NATO tactical data link that runs almost every air-picture exchange in the alliance today. Link 22 is the standard meant to replace Link 11 — and to extend Link-16-class capability beyond line-of-sight. The two are complementary on paper and competitive in practice. For any new C2 program crossing a NATO threshold, choosing one, both, or neither has consequences that last twenty years. This is an engineering comparison: waveforms, message formats, gateways, terminals, releasability, and the architectural bets that follow.
1. The Two Standards Today
Link 16 is operational across every major NATO air force, on AWACS and E-7 platforms, on every fourth- and fifth-generation fighter (F-15, F-16, F-18, F-35, Typhoon, Rafale, Gripen), on every modern AEGIS and Type 45 combatant, and on most ground-based air defense fire units. The standard is governed by STANAG 5516 and MIL-STD-6016. It is, by volume and by combat history, the dominant tactical data link in the world.
Link 22 — formally NILE, NATO Improved Link Eleven — is the deliberate Link 11 replacement. Link 11 is HF/UHF, slow, and Cold-War-era brittle; the alliance committed in the 1990s to building its successor. STANAG 5522 defines Link 22. Deployment has been gradual: the German, French, Italian, UK, and US navies are the lead adopters, with NIU (Network Interface Unit) installations on FREMM-class frigates, Type 26, and selected US Navy combatants. Link 22 is not a Link 16 replacement. It is a Link 11 replacement that borrowed enough of Link 16's data model to be useful in mixed networks.
The shorthand in the community is: Link 16 owns the air picture, Link 22 picks up where the line-of-sight UHF horizon ends.
2. Waveform Differences
Link 16 operates in the L-band (960–1215 MHz), uses TDMA with fixed time slots, and depends on line-of-sight UHF propagation. The waveform is jam-resistant by design — Joint Tactical Information Distribution System (JTIDS) and its successor Multifunctional Information Distribution System (MIDS) use frequency hopping across 51 channels, with pseudo-random hop sequences keyed by a Crypto Variable. The cost of this resilience is range: about 300 nautical miles between aircraft at altitude, less for surface combatants, almost nothing for ground units behind terrain.
Link 22 takes a different bet. It supports HF (2–30 MHz) and UHF (225–400 MHz) waveforms simultaneously. HF gives over-the-horizon range — hundreds to thousands of nautical miles via skywave propagation. UHF gives a Link-16-comparable line-of-sight bearer with higher data rate. The Link 22 Network Controller can route messages across either bearer dynamically, which is the headline architectural feature: one logical network on top of two very different physical layers.
The trade-off is bandwidth. Link 16's L-band waveform sustains roughly 28.8 to 238 kbps depending on packing mode. Link 22's HF waveform is closer to a few kbps; UHF gets to tens of kbps. For air picture density, Link 16 still wins by a wide margin. For beyond-line-of-sight naval coordination — where Link 11 once carried a few hundred tracks across an ocean — Link 22 is comfortably sufficient and dramatically more robust.
3. Message Format — J-series vs F-series
Link 16 uses J-series messages, defined in MIL-STD-6016. The J-series is a fixed-format binary message catalog: J2 (precise participant location and identification), J3 (surveillance tracks), J7 (mission management), J10 (weapons coordination), J12 (control), J13 (platform and system status), and so on through dozens of subcategories. Each message is bit-packed into a 70-bit word structure that maps onto the TDMA slot capacity.
Link 22 uses F-series messages, defined in STANAG 5522. The F-series was designed deliberately as a superset compatible with J-series semantics: F2 mirrors J2, F3 mirrors J3, and so on. The intent was to allow gateway translation without lossy semantic compromise. The reality is more nuanced.
F-series messages are variable-length where J-series are fixed. F-series carries additional fields for over-the-horizon routing metadata that has no J-series counterpart. Some F-series messages encode track quality and Identification, Friend or Foe (IFF) information with higher resolution than the equivalent J-series fields. When you translate F to J at a gateway, those extra bits get dropped. When you translate J to F, the additional F-series fields get null-padded. Round-trip is not lossless.
For most operational uses the loss is acceptable — a track is still a track, a hostile identification still flows. For weapons-quality coordination across a Multi-Link network, the loss is operationally relevant and has to be analyzed mission by mission.
4. Multi-Link Gateways
The Multi-Link gateway is the practical answer to a heterogeneous NATO data link environment. A Maritime Operations Centre (MOC) or AWACS may need to fuse Link 11, Link 16, Link 22, and Variable Message Format (VMF) tracks into one tactical picture. The Data Distribution System (DDS) and its modern equivalents — typically running on shipboard combat management systems like SSCS, CMS-330, or 9LV — perform this translation.
JREAP — the Joint Range Extension Application Protocol — is the standard for tunneling Link 16 J-series messages over non-Link-16 bearers. JREAP-A runs over satellite, JREAP-B runs over point-to-point serial (typically HF or UHF SATCOM with low jitter), and JREAP-C runs over IP networks (TCP or UDP). JREAP-C is the most widely deployed because IP transport is universal; it is also the one that introduces the most latency.
The latency penalty matters. A Link 16 track update is broadcast in the assigned time slot, typically within 12 seconds of the report time. A JREAP-C tunneled update across a satellite hop adds 500–800 ms of network latency on top of the slot scheduling delay. For an air-defense engagement timeline that is bounded by seconds, this is the difference between an engagement decision based on current truth and one based on stale truth.
Gateways are a necessary fact of NATO C2, but they are not free. The engineering rule of thumb: every link translation costs you semantic fidelity, latency, and one more box that can fail.
Key insight: A Multi-Link gateway is not a router. It is a translator with opinions. The choice of which Link 16 J-message maps to which Link 22 F-message — and what gets dropped — is hard-coded by the gateway vendor. Two gateways from different vendors will produce different tactical pictures from the same input. This is a real NATO interoperability problem, not a theoretical one.
5. MIDS-LVT vs MIDS-JTRS vs Link 22 NIU
The terminal hardware story is where program managers get blindsided. Link 16 is carried by MIDS terminals. MIDS-LVT (Low Volume Terminal) is the legacy hardware — analog backplane, fixed waveform, in service since the late 1990s. MIDS-JTRS (Joint Tactical Radio System) is the modern software-defined replacement, capable of hosting Link 16 alongside other waveforms (TTNT, SRW, WNW) on the same box. MIDS-JTRS is what new aircraft programs specify.
Production capacity is the constraint. Certified MIDS-JTRS terminals come from a small number of US-cleared suppliers (Data Link Solutions, ViaSat, Collins Aerospace). Lead times for new orders run 18–36 months. For a NATO ally building a new platform, a MIDS-JTRS terminal order placed in 2026 may not deliver hardware before 2029. This is not a procurement-process complaint; it is a physical-supply reality.
Link 22 NIUs are even scarcer. The standard NIU implementations come from Rockwell Collins, Thales, and Leonardo. Production volume is in the hundreds, not thousands. A program that needs Link 22 on twenty ships will see the same 24–36 month lead time and possibly longer, depending on national qualification status.
The procurement-math lesson: terminal hardware is the long pole. The software talking to that terminal — your combat management system, your C2 workstation — can be developed and tested in months. The radio cannot.
6. National Variants and Releasability
Link 16 has two practical variants. US Link 16 includes message implementations and Crypto Variables that are NOFORN — not releasable to foreign nationals. NATO Link 16 is the releasable subset, governed by STANAG 5516. The same MIDS terminal can be loaded with either crypto variable; what differs is the message library and the security accreditation.
For a NATO ally, this means: Link 16 interoperability with US assets requires a US-cleared crypto load, which requires a US National Security Agency release decision, which requires the program to be on a Foreign Military Sales (FMS) case with the right release authority. The SHARES — Special High-Frequency Receiver-Transmitter — constraint is the parallel HF problem: certain HF crypto modes are not released to all NATO members, which complicates Link 22 HF operation in mixed coalitions.
Releasability is the impedance mismatch that turns a clean technical interoperability story into a six-month diplomatic negotiation. Build for it from the start.
7. When to Bet on Link 22
Link 22 is the right primary choice when the operational geometry exceeds Link 16's line-of-sight horizon. The clearest cases:
Naval task groups operating dispersed. Frigates 200+ nautical miles from the command ship will fall off a Link 16 net repeatedly. Link 22 HF holds the network together. This is the original Link 11 use case, modernized.
Expeditionary HF relay scenarios. A maritime patrol aircraft over the North Atlantic, a forward-deployed combatant in the Arctic, an island-chain defense scheme in the Pacific — anywhere the air picture has to traverse hundreds of nautical miles of ocean to reach a C2 node. Link 22's dual-bearer design is built for this.
C2 architectures that need bearer redundancy. When a SATCOM bearer is jammed or degraded, HF still works. Link 22's ability to fall back from UHF SATCOM to HF — within the same logical network — is a survivability property Link 16 does not have.
Link 22 is the wrong primary choice for: fighter-to-fighter air engagement (line-of-sight UHF is fine), short-range fire control, and any environment where Link 16 already saturates the operational need.
8. Migration Path for New Programs
For a new NATO C2 program — a combat management system, a ground-based air defense C2 node, a tactical operations centre — the architecture choice is rarely "Link 16 or Link 22." It is "how do I build a tactical data link layer that does not have to be torn out in five years?"
The pattern that works: dual-stack with a canonical internal message bus. The combat system maintains its tactical picture in an internal data model (typically JC3IEDM or an equivalent — see our MIP4-IES analysis for the ground-domain equivalent). A protocol-adapter layer translates the internal model to and from J-series, F-series, VMF, and any other required protocol. The adapters are versioned, hot-swappable, and testable in isolation.
This is the same pattern we recommend across the broader C2 systems stack: never let a protocol leak into the core domain model. When Link 16 Block Upgrade 2 ships a new J-message or Link 22 Increment 3 deprecates an F-message, you swap an adapter, not the combat system.
The corollary on the radio side: specify MIDS-JTRS where you can afford it, MIDS-LVT only where the platform cannot host JTRS. Specify Link 22 NIU as a future-fit option on every maritime platform, even if Day-1 operations are Link 11 or Link 16 only. The hardware decisions made in the program-of-record phase set the ceiling for what the software can do for the next two decades.
For the full implementation playbook across NATO tactical data links, see Part 2 of our implementation series: NATO Interoperability Implementation, Part 2: Tactical Data Links.