What is Link 22? NILE, STANAG 5522 and how the tactical data link works

Link 22 is NATO's secure HF/UHF tactical data link for beyond-line-of-sight data exchange. Developed by the NILE (NATO Improved Link Eleven) programme to replace Link 11 and complement Link 16, it is standardized in STANAG 5522 (ATDLP-5.22). Ships, aircraft, submarines and shore sites share tracks across a "super network" of up to eight networks and 125 units, with no satellite required.

This guide explains how Link 22 works — the unit architecture, HF and UHF media and data rates, NILE networks and the super network, dynamic TDMA, F- and FJ-series messages, security, forwarding and test tools — and what software teams build when a platform adds it. Figures come from the NILE project's publicly released Link 22 Guidebook (2013) and Customer Information Guide (2020). For the head-to-head comparison, read Link 22 vs Link 16.

Link 22, NILE and STANAG 5522 explained

NILE stands for NATO Improved Link Eleven: the former name of Link 22 and the name of the multinational project that builds its common components. In the late 1980s NATO agreed that Link 11 had to be improved; the NATO Staff Requirement of 9 March 1990 set the operational requirements, and the project specified a new tactical message standard, STANAG 5522 (published as ATDLP-5.22), together with a new layered communications architecture. NATO designated the result Link 22.

The project started in 1987, finished design and development in 2002 and has been in in-service support since. The seven NILE nations are Canada, France, Germany, Italy, Spain, the United Kingdom and the United States (host nation); the Netherlands was an original participant and Spain took its place. A Project Management Office hosted by the US Navy's PMW 150 in San Diego runs the programme and publishes public information at link22.org. The goals are to replace Link 11, improve allied interoperability and complement Link 16. Link 22 was designed primarily as a maritime link for anti-surface and anti-submarine warfare, but it supports every environment — air, surface, subsurface and land.

Who uses Link 22 today

Link 22 is in operational service in several NILE and partner nations; other countries join through a third-party-sales process approved by the NILE nations. Publicly reported milestones:

Link 22 architecture: TDS, DLP, SNC, LLC, SPC and radios

Link 22 uses a layered stack, modelled on the ISO communication layers, with well-defined interfaces so that several suppliers can contribute. Each participant is a NILE Unit (NU), and inside it the chain runs from the combat system to the antenna:

• Tactical Data System (TDS) — the host C2 or combat management system that owns the tactical picture and generates and consumes tactical data under national rules.
• Data Link Processor (DLP) — part of, or attached to, the TDS. It builds and parses STANAG 5522 messages and performs track management, correlation, reporting responsibility, conflict resolution, filtering and data forwarding. It talks to the SNC through the DLP–SNC Interface Design Description (IDD).
• System Network Controller (SNC) — the core, roughly the network and transport layers: end-to-end delivery, routing, automatic relay, TDMA, quality of service and network management. It is a single software implementation owned by the NILE nations, written in Ada 95 and run on an ordinary Windows or Linux computer.
• Link-Level COMSEC (LLC) — the crypto device. The current LLC 7M was developed by the US, certified by the NSA in February 2016 and is sold only through US Foreign Military Sales; one unit handles up to four NILE networks.
• Signal Processing Controller (SPC) — roughly the data-link and physical layers: modulation, error detection and correction (EDAC) and transmission security. A unit needs one SPC per network; SPCs are commercial products.
• Radios — commercial HF and UHF sets. Existing HF Link 11 radios support the original HF fixed-frequency waveforms 1–6; the newer waveforms and the hopping modes need radios verified for them.

The SNC, LLC, SPCs and radios form the NILE Communications Equipment (NCE); the Link 22 system is the NCE plus the Link 22 part of the DLP. The SNC and the interface specifications are joint NILE products and the LLC 7M is US-developed — but the TDS/DLP, SPCs, radios, time source and the integration of all of them are national responsibilities. In the guidebook's reference installation, the DLP–SNC and SNC–LLC interfaces run over TCP/IP on Ethernet, the LLC connects to each SPC over a serial link, and a time-of-day source (STANAG 4430) feeds the DLP, SNC, SPCs and hopping radios. Partner nations receive the SNC as executables only, and while minor SNC versions interoperate, major versions (9.x and 10.x, for example) do not.

Link 22 frequency bands and data rates

Each NILE network uses one medium. Link 22 defines two bands: HF (2–30 MHz), for beyond-line-of-sight coverage by ground wave and sky wave, optimized for (but not limited to) about 300 nautical miles, and UHF (225–400 MHz), line of sight only. Each band can run fixed frequency (FF) or frequency hopping in an Electronic Protection Measures (EPM) mode for jam resistance. Every medium offers several settings that trade throughput for robustness, so a network keeps working in poor propagation, including the high latitudes where Link 11 struggles.

Rates are what remains for tactical data after error-correction and synchronization overhead; packet sizes are from the 2013 guidebook. Capacity adds up across networks: the 2020 guide quotes 44,532 bit/s for two UHF plus two HF networks, and ranges beyond 1,000 nautical miles. The HF gains came from a German enhancement effort in 2007–2009 that made the standard HF settings more robust, extended gapless coverage to 1,000 nautical miles and added high-speed waveforms. For scale, Link 16 delivers 26,880–107,520 bit/s depending on packing: Link 22 trades raw throughput for reach, robustness and automatic relay.

NILE networks and the Link 22 super network

A NILE network is a set of units exchanging STANAG 5522 data on one medium with one set of network parameters. An operational Link 22 system is a super network — from two units on one network up to eight NILE networks and 125 units. Each unit can be on up to four networks at once, and each network can use any medium and mode: say, HF for a dispersed task group, UHF inside the screen and UHF EPM where jamming is expected.

Any unit can address any other unit in the super network, whichever networks they are on. The SNC tracks connectivity and decides, message by message, whether a retransmission is needed to reach the addressees — automatic relay, on the same or another network. That removes Link 11's net control station and Link 16's dedicated airborne relays and relay-slot planning. Relay is automatic by default; a unit can be inhibited from relaying or made a preferred relay, and routing steers around congestion and lost units.

Messages are addressed as Totalcast (all units), Neighborcast (RF neighbours on each of the unit's networks), Mission Area Sub-Network (a predefined group), dynamic list (two to five named units) or point-to-point, with or without acknowledgement. The TDS and DLP identify units by a 15-bit Link 22 address coordinated with Link 16 addressing; the SNC also allocates an internal 7-bit NILE address that the DLP never sees. With no net control station and distributed protocols, losing any single unit does not bring the network down.

TDMA, dynamic TDMA and quality of service

Each NILE network shares capacity by TDMA, but it is nodeless: there is no Network Time Reference unit as in Link 16. The Network Cycle Structure divides time into fixed minislots whose length depends on the medium; timeslots are whole numbers of minislots, each allocated to a unit, and a network cycle can be up to 1,024 minislots long. Optional Priority Injection timeslots belong to nobody: urgent priority-1 messages can go out there early, and are repeated in the sender's own slot in case of collision.

Planners either define the cycle in the OPTASK LINK message or give each unit's capacity need and access delay and let the SNC compute an optimized structure. In operation, Dynamic TDMA (DTDMA) lets congested units obtain spare capacity donated by others, temporarily or permanently, without changing the cycle time. If that is not enough, the network management unit can reconfigure the network with a new cycle structure, or re-initialize it with different media parameters after a brief pause.

Every request from the DLP carries quality of service that the SNC enforces: priority 1–4; reliability — standard (80 % probability of reception), high (90 %) or guaranteed delivery with acknowledgements, with the SNC computing the repeats and spreading them across packets; four levels of perishability, so expired data is never sent; the data originator preserved along any relay route; and a radio-silence override flag.

F-series and FJ-series messages vs J-series

Link 22 sends tactical data in fixed-format messages made of 72-bit Tactical Message Words (TMWs), one to eight words per message. These F-series messages belong to the same J-family as Link 16: they use the same data-element definitions, 15-bit addresses, 19-bit track numbers and WGS-84 positions. There are two kinds:

• Unique F-series messages — compact versions of Link 16 messages, or messages with no Link 16 equivalent. They save bandwidth on slow HF networks.
• FJ-series messages — Link 16 J-series messages packed into 72-bit words, so many Link 16 messages cross Link 22 unchanged.

The shared data dictionary gives Link 22 data the range and granularity that Link 11's M-series lacked, and makes translation to Link 16 far easier than translating Link 11. For the Link 16 side of the family, see the J-series message list and our J-series field guide.

The DLP builds each message (or takes it from the TDS) and hands it to the SNC in a Transmission Service Request (TSR) carrying its QoS; the SNC validates the request and reports success or failure. The NCE handles tactical messages as sealed envelopes and never reads their content. A sketch of what a DLP manages per request (illustrative only; the real encoding is defined by the DLP–SNC IDD):

# Illustrative model of what a DLP manages per Link 22 transmission request.
# Not the DLP-SNC IDD encoding, which the NILE PMO distributes to programmes.
from dataclasses import dataclass, field
from enum import Enum, auto

class Reliability(Enum):
    STANDARD = auto()    # 80 % probability of reception
    HIGH = auto()        # 90 % probability of reception
    GUARANTEED = auto()  # repeat until acknowledged or unreachable

class Addressing(Enum):
    TOTALCAST = auto()       # every unit in the super network
    NEIGHBORCAST = auto()    # RF neighbours on each of my networks
    MASN = auto()            # predefined mission area sub-network
    DYNAMIC_LIST = auto()    # 2 to 5 units named in the request
    POINT_TO_POINT = auto()  # exactly one unit

@dataclass
class TransmissionServiceRequest:
    request_id: int
    words: list[bytes]                # 1-8 tactical message words, 72 bits = 9 bytes each
    priority: int = 3                 # 1 (highest) to 4 (lowest)
    reliability: Reliability = Reliability.STANDARD
    perishability: int = 1            # one of four levels
    data_originator: int = 0          # 15-bit address of the unit that first reported the data
    addressing: Addressing = Addressing.TOTALCAST
    destinations: list[int] = field(default_factory=list)
    acknowledge: bool = False         # machine receipt from the addressees
    priority_injection: bool = False  # priority-1 only: may use unowned PI timeslots
    radio_silence_override: bool = False

    def validate(self) -> None:
        if not 1 <= len(self.words) <= 8 or any(len(w) != 9 for w in self.words):
            raise ValueError("a Link 22 message is 1-8 words of 72 bits")
        if not 1 <= self.priority <= 4:
            raise ValueError("priority must be 1-4")
        if self.priority_injection and self.priority != 1:
            raise ValueError("priority injection is for priority-1 messages only")
        if self.addressing is Addressing.DYNAMIC_LIST and not 2 <= len(self.destinations) <= 5:
            raise ValueError("a dynamic list names 2-5 units")

Link 22 security and network management

Security. The LLC provides communications and network security (COMSEC and NETSEC). The LLC 7M uses integrity protection and time-based encryption, which makes spoofing harder and easier to detect than on Link 11; the earlier KIV-21/LLC shared Link 16's crypto chip and used weekly keys. Frequency-hopping EPM media add transmission security. Because the NCE never reads tactical content, a nation can also encrypt tactical data end to end above the link — something a Link 16 terminal, which must access the data it sends, cannot offer.

Network management is automated by design. Every unit initializes from the same fundamental parameters in the OPTASK LINK message (OLM), which the DLP loads into the SNC's super network directory; a network can carry tactical traffic from its start time without any prior on-air exchange, or probe propagation first. There are two roles: one Super Network Management Unit (SNMU) and a Network Management Unit (NMU) per NILE network, each with a standby that takes over automatically — and the link keeps working even with no role holder. The SNMU can start new networks, shut down units, networks or the whole super network, optimize performance and manage radio silence and crypto key status. Late arrivals use Late Network Entry (LNE) to obtain current parameters, as an active, inactive or silent (listen-only) join; receive-only units can listen without being given transmission capacity.

Forwarding to Link 16 and Link 11 (STANAG 5616)

Link 22 rarely runs alone. Data forwarding — receiving data on one link and re-issuing it, correctly translated, on another — is a DLP function outside the NILE system specifications. It is governed by STANAG 5616 (ATDLP-6.16): Volume II covers Link 22 ↔ Link 16, Volume III Link 22 ↔ Link 11/11B, and every dual- or multi-link DLP that forwards must comply. A unit on both Link 22 and Link 16 that forwards between them is an FJ unit; multi-link operating procedures are in ATDLP-7.33 (formerly ADatP-33).

Thanks to the shared J-family dictionary, Link 22 ↔ Link 16 forwarding is mostly remapping and re-packing, while Link 11 requires translating M-series messages. The NILE guide ranks DLP effort accordingly: dual Link 16/Link 22 is simpler than dual Link 11/Link 22, and a full Link 11/16/22 DLP is the hardest. Track-number allocation, reporting responsibility, duplicate suppression and loop prevention are covered in our Link 16 to Link 22 gateway guide and tactical data link gateway software; retiring the old link is covered in Link 11 migration.

Link 22 vs Link 16 in brief

Link 16 (STANAG 5516) is the high-capacity, jam-resistant link for the air picture: L-band, line of sight, and dependent on airborne or satellite relay for range. Link 22 is the HF/UHF link for dispersed maritime forces: less throughput, but beyond-line-of-sight reach, automatic relay without relay platforms and far simpler network management. They were designed as complements. See the full Link 22 vs Link 16 comparison or Link 11 vs Link 16 vs Link 22, or start with what Link 16 is.

Testing Link 22: NILE Reference System and MLST3

The NILE project funds two test systems. The NILE Reference System (NRS) is the compatibility tester for the SNC — and supports verification of LLCs and SPCs — with scenario generation, data extraction, replay and automated expected-response analysis for regression testing. Its configurations include SNC verification (one SNC under test against up to 124 simulated units), multiple units under test (two to five real SNCs, optionally with real SPCs and radios), full system simulation of 1–125 units, and a Media Simulator mode for testing a national DLP without real SPCs. An LLC simulator and the Media Simulator let integrators work without crypto hardware or radios.

The Multiple Link System Test and Training Tool (MLST3) is the interoperability tester: it checks DLP conformance to the tactical message standards and interoperability with Link 16, Link 11 and JREAP in single- and multi-link setups, and doubles as a training tool. MLST3 is available through US Foreign Military Sales; other vendors offer alternatives. Platform and coalition testing then follow the usual path described in NATO interoperability certification.

What software teams build for Link 22

The NILE guide is blunt: developing and integrating the DLP is "the most significant and costly effort during Link 22 implementation". The SNC is supplied, the LLC is bought and SPCs and radios are commercial, so engineering effort concentrates on national software:

• DLP integration — map the TDS track model to F/FJ-series messages, implement initialization, network control and TSR handling over the DLP–SNC interface, and own reporting responsibility, filtering and correlation. Scope drives cost: receive-only DLPs are simplest, receive plus limited transmit (surveillance, PLI) is still manageable, full C2 needs far more care.
• F- and FJ-series codecs — bit-exact encoders and decoders for 72-bit TMWs, generated from data-element tables rather than hand-coded, with range validation and round-trip tests.
• Multi-link gateways — STANAG 5616 forwarding among Link 22, Link 16 and Link 11 with stable track-number mapping and loop suppression.
• C2 and COP ingestion — Link 22 tracks in the maritime picture, time-aligned and fused with Link 16, AIS and radar; see maritime command and control software and maritime domain awareness C2.
• Simulation and training — scenario generators, synthetic super networks and record/replay tools for operator training and regression testing alongside NRS and MLST3.

Start the non-software path early too. A partner nation needs a sponsoring NILE nation, unanimous approval of the NILE nations and the Netherlands, and a US FMS case for the LLC 7M and the biennial SNC block-cycle releases — paperwork that runs in parallel with development, not after it.