Link 16 to link 22 gateway: message translation and forwarding

A coalition air-and-maritime picture is rarely carried on a single link. Fast-jet and air-defense participants share their tracks over Link 16; maritime task groups and over-the-horizon participants increasingly share theirs over Link 22. The moment both communities have to see one another, something has to sit between the two networks and move tracks across – receiving a J-series message on one link, re-expressing it for the other, and retransmitting it so a contact reported on either side appears, correctly, on both. That something is a Link 16/Link 22 gateway, and getting its translation and forwarding logic right is one of the more exacting problems in tactical data link integration. This article walks through how the gateway joins both networks, how it translates between the two J-series environments, and how it forwards tracks without duplicating, looping, or quietly losing them.

Why a gateway is needed at all

Link 16 and Link 22 are not competing standards so much as complementary ones, and the comparison between them is covered in detail in the article on Link 22 versus Link 16. Link 16 is the high-tempo, line-of-sight workhorse for the air picture: a precisely timed TDMA structure on JTIDS/MIDS terminals in the 960–1215 MHz band, delivering track updates every few seconds to fast-moving participants. Link 22 was designed as the modern beyond-line-of-sight successor to the older Link 11, organizing terminals into a Super Network across HF and UHF media with dynamic media access, well suited to dispersed maritime forces and over-the-horizon reach.

Because the two links serve different ranges, media, and platform populations, real operations frequently run both at once. An air-defense ship on the Link 16 air picture and a frigate reporting over Link 22 belong to the same force, and their commanders need a single coherent picture. The gateway is the node that makes that possible: it is a unit on both networks simultaneously, and its sole job is to keep the two pictures consistent by translating and forwarding the tracks each side cannot otherwise hear.

The shared foundation: J-series messages

The reason cross-link translation is tractable at all is that both Link 16 and Link 22 carry the same family of messages – the J-series catalog defined across the MIL-STD-6016 family of standards. A J2-series air track on Link 16 and a J2-series air track on Link 22 describe the same conceptual entity with the same conceptual fields: position, velocity, altitude, identity, IFF, and track number. The translation is therefore largely a remap rather than a wholesale reformat, which is a meaningful simplification compared to bridging two genuinely different message families.

"Largely a remap" is not "trivially identical", though. The two link environments differ in three layers that the gateway must reconcile. First, the framing and media-access layer is completely different – fixed TDMA time slots on Link 16 versus dynamic Super Network media access on Link 22 – so the gateway physically re-transmits, never just relays bits. Second, some field encodings, resolutions, or unit conventions differ between the Link 16 and Link 22 definitions of otherwise equivalent messages, and those fields must be re-packed, not copied. Third, the network-management messaging – the messages that govern participation, timing, and reporting responsibility – is link-specific, so the gateway must speak each side's management dialect natively.

What carries across, and what must be re-packed

The high-value payload fields – latitude, longitude, altitude, course, speed, identity, and IFF data – map across cleanly in the common case, because they describe physical reality that does not change with the link carrying it. The fields that demand attention are the link-relative ones: track number (assigned per network, in a network-specific number space), reporting responsibility (which unit "owns" the track on this net), and track quality or confidence indicators (which downstream fusion uses to weight the track). These cannot be copied verbatim; they must be re-derived for the destination network, which is exactly where most forwarding bugs originate.

Joining both networks and aligning time

Before a single track can be forwarded, the gateway has to be a healthy participant on both networks. On the Link 16 side that means a MIDS-class terminal, an assigned set of TDMA time slots for transmission, correct crypto keying, and tight synchronization to the net time reference. On the Link 22 side it means an accredited Link 22 terminal joined to the Super Network, with its own keying and its own network timing.

Time alignment is not a formality. Every J-series track is meaningful only with respect to a time of measurement, and a fused picture correlates tracks from multiple sources by comparing their time-tagged states. If the gateway is loosely synchronized on either side, the tracks it injects will be time-tagged incorrectly relative to native tracks on the receiving net, and the receiving fusion layer will either reject them as stale or, worse, mis-correlate them. The gateway must discipline its clock to the Link 16 net time reference and align to the Link 22 network timing, and it must time-tag every track it forwards with a time consistent with the destination net's reference rather than its own free-running clock.

The translation pipeline

Inside the gateway, each forwarded track passes through a short, well-defined pipeline. Decode: the received J-series message is decoded using field tables generated programmatically from the MIL-STD-6016 specification – the same discipline that applies to any J-series consumer, because hand-coded bit-field arithmetic and quantization steps produce subtle offset errors that surface months later as displaced tracks. Validate: every decoded field is checked against its physical range; a position outside the earth, a negative slant range, or an impossible velocity indicates a malformed source message that must be logged and dropped, not forwarded. Map: the validated entity state is translated into the destination link's J-series message, copying the fields that map directly and re-packing the fields whose encoding differs. Stamp and enqueue: the message is given a destination-net track number and the gateway's reporting responsibility, then queued for transmission in the next available media-access opportunity.

On modern hardware the decode-map-encode work costs only single-digit milliseconds per message; the gateway is not compute-bound. The real latency lives in the queue-to-transmit gap, which is governed entirely by the destination link's media access – the wait for the gateway's TDMA slots on Link 16 or its media-access opportunity on Link 22.

Forwarding without duplication or loops

The hardest correctness problem in any forwarding gateway is preventing a track from being duplicated, multiplied, or fed back into an infinite loop. Three mechanisms work together to prevent this.

The forwarding table. The gateway maintains a table keyed by the originating unit and source track number, mapping each source track to the destination track number it was assigned. When the same source track updates, the gateway reuses the same destination track number so the receiving picture sees one continuous track rather than a new track per update. This stable mapping is the backbone of clean forwarding.

Reporting-responsibility rewriting. Every track the gateway injects onto a network is stamped with the gateway as the reporting unit, not the original reporter. This is what lets the gateway recognize its own output: when a track it forwarded onto Link 22 is later heard echoing back toward Link 16, the gateway sees its own reporting responsibility on the inbound message and suppresses re-forwarding it. Without this rule, two gateways – or even one gateway on a reflective topology – will multiply tracks without bound.

Identity and kinematic correlation. A single physical aircraft or ship can appear independently on both links if it is heard natively by participants on each. If the gateway naively forwarded both, the fused picture would show two markers for one entity. Correlation by Mode 5/Mode S identity, where available, folds these into a single track immediately; where no shared identity key exists, kinematic correlation tests whether two tracks could be the same entity based on consistent position and velocity. This correlation is the same fusion discipline used whenever multiple sources feed one picture, and is treated more broadly in the article on NATO interoperability standards.

Track-number management across number spaces

Link 16 identifies tracks by a 5-digit octal track number assigned by the reporting unit, and Link 22 has its own track-numbering scheme. The gateway therefore straddles two distinct number spaces and must allocate destination track numbers from its own assigned block on each net while preserving a stable internal track identity that survives across both. The recommended pattern is the same one used in any multi-network common operating picture: keep a stable internal track UUID for fusion, present the operationally meaningful per-net track number for display, and never let a track-number collision on one net drop or merge two distinct entities. Bridging two previously separate networks is the classic collision trigger, and the gateway must resolve it without losing tracks from either picture.

Classification, keying, and what a software team owns

A gateway crosses cryptographic and classification boundaries by design. Each link carries classified traffic keyed by accredited crypto, and the gateway holds keying material for both. The translation software does not weaken this – it operates on already-decrypted J-series content inside the accredited boundary – but the program must ensure the gateway host, its storage, and any cross-domain element are accredited to the data's classification. Spillage across a tactical data link gateway is a recurrent cross-domain incident cause, and the engineering team owns making the data path auditable.

The division of labor is worth stating plainly. The translation, forwarding, correlation, and track-management logic is ordinary software engineering, demanding but buildable by a capable team. The constrained pieces are the accredited terminals (MIDS-class for Link 16, accredited Link 22 terminals for Link 22), the national crypto keying, and the network design that allocates the gateway its slots and number blocks. Those are program and national-authority matters, interfaced through a tactical data link processor and standard host interfaces – the same accreditation pattern that governs ground-side standards such as MIP4-IES.

Done well, the gateway is invisible: a maritime contact on Link 22 simply appears on the Link 16 air picture, and a fast-jet track on Link 16 simply appears for the over-the-horizon maritime force, each with the right identity, the right time tag, and exactly one marker.