Software gateways for tactical data link translation: Link 16, VMF, CoT, and NFFI

A coalition joint task force operates across a landscape of incompatible data languages. The air component speaks Link 16 — J-series messages in MIL-STD-6016 over a JTIDS/MIDS waveform. Ground forces exchange positions and orders in VMF (Variable Message Format) over tactical radios, or in NFFI (NATO Friendly Force Information) over IP between brigade-level C2 systems. Dismounted soldiers and joint terminal attack controllers push CoT (Cursor-on-Target) events over IP from ATAK tablets. Intelligence systems publish tracks in proprietary XML or in MIP's Information Exchange Standard. None of these formats speak natively to each other. The software gateway is what makes them interoperable — ingesting each format, translating the semantic content into another format, managing the resulting track identities, applying filtering rules, and delivering the translated data within a latency budget that keeps the common operating picture tactically useful. This article examines how tactical data link (TDL) gateways work and where they routinely fall short.

The data link landscape

Understanding the translation problem requires understanding what each data link format is designed to do, because each was designed for a different environment with different constraints.

Link 16 — defined in MIL-STD-6016 — is a time-division multiple-access waveform designed for air warfare. Its J-series messages carry surveillance tracks, PPLI (Precise Participant Location and Identification) data, mission management messages, and weapons coordination content. Link 16 is compact, encrypted, low-latency, and anti-jam by design. Its bandwidth is shared among all terminals in the network via TDMA time slots, which imposes a hard ceiling on how many tracks can be shared at what update rate. A Link 16 network is not a general-purpose IP network; it is a purpose-built message bus with fixed capacity and a rigid message schema. For more detail on the Link 16 architecture, see our analysis of Link 16 tactical data links.

VMF (Variable Message Format, MIL-STD-2045-47001) is the US Army and joint standard for tactical digital messages. VMF messages are binary-encoded and optimized for narrowband radio bearers — a design choice that enables them to be carried on HF or VHF radio channels with kilobits-per-second throughput. VMF covers a wide range of message types: situational awareness reports, digital orders, fire support requests, logistics messages, and more. The binary encoding makes VMF compact but inflexible; adding a new message type requires a formal specification change.

CoT (Cursor-on-Target) is an XML event schema designed for the TAK (Team Awareness Kit) ecosystem. A CoT event is a minimal, extensible structure: a unique identifier (UID), a geographic position, an event type drawn from a taxonomy (including military MIL-STD-2525 symbol codes), a time-to-live, and optional detail elements. CoT was designed to be simple and IP-native, readable by humans and machines alike, extensible without breaking parsers, and small enough to transit a tactical radio link. It has become the de facto common language of the dismounted soldier and the joint terminal attack controller community, and increasingly of UAS operators and special operations forces.

NFFI (NATO Friendly Force Information, STANAG 5527) is the alliance's standard for sharing friendly-force position and identity data between ground C2 systems over IP. It defines a message set for track reporting, track management, and authority transfer. NFFI is the data link of choice for brigade and above C2 systems that need to exchange ground-force tracks with allied systems — it provides a common language for the ground picture at the operational level in a way that Link 16 (designed for the air picture) does not.

What a TDL gateway actually does

A software TDL gateway is not a simple protocol converter. If the only challenge were reformatting bytes from one encoding to another, the engineering would be trivial. The hard problems are semantic: the data models underlying these formats are different, the track identity schemes are different, the update rates are different, and the attributes available in one format may have no equivalent in another. A gateway must solve all of these problems simultaneously and do so in real time with a latency budget measured in hundreds of milliseconds.

Message parsing and normalization

The first function of a gateway is to parse each incoming format and normalize it to an internal representation. That internal representation must be rich enough to capture all the attributes any source format can carry, without losing information that a target format can express. A common choice is a canonical track object that holds identity attributes (call sign, track number, national track identity, ICAO transponder code), position and kinematics (geodetic position, altitude, velocity, heading), classification (air/surface/subsurface/land, friend/neutral/unknown/hostile, specific platform type), data quality indicators, and provenance metadata (which data link reported this, at what time, with what update rate).

Normalization is where the first semantic losses occur. Link 16's J3.0 surveillance track message carries a track quality number on a defined scale; CoT has no equivalent field. A CoT event's detail section may carry military symbol codes, but the same platform may be described differently in a Link 16 track. The gateway must document what it preserves and what it loses in each translation direction — and operators must be briefed on those limitations.

Track management and message correlation

Track management is the function that maintains the collection of active tracks — one per real-world entity — across all data sources. When a new report arrives, the tracker must decide: is this a new entity, or is it an update to an existing track? If it is an update, which existing track does it belong to? This is the message correlation problem.

Correlation algorithms typically work in two stages. The first stage is kinematic gating: if the reported position and velocity are geometrically consistent with an existing track — the new report falls within the track's predicted position uncertainty ellipse — the report is a candidate for that track. The second stage applies identity attributes: if the candidate has a matching call sign, ICAO code, or track number, correlation confidence rises sharply. When both stages agree, the track is updated. When they disagree — position consistent but identity mismatched, or identity matched but position inconsistent — the algorithm must choose between declaring a new track and forcing a potentially incorrect correlation. This edge case is where operator reports of "ghost tracks" and "duplicate symbols" originate.

Correlation becomes particularly challenging when Link 16 tracks — which update every two to twelve seconds and carry high-precision geodetic positions — are correlated with CoT tracks from TAK devices, which may update less frequently and carry positions that reflect GPS accuracy rather than the sensor-fused accuracy of a radar track. A ground sensor reporting a moving vehicle in CoT and a Link 16 surveillance track for the same vehicle may be separated by tens of meters at the time of comparison, even if both reports are accurate. Correlation thresholds must be set loose enough to catch these cases without generating false correlations between nearby but distinct entities.

Filtering and releasability rules

A TDL gateway sits at a data boundary. Not all tracks from one domain should flow into another: some tracks are classified at a level not releasable to the receiving party, some are geographically irrelevant to the consumer, some are below a data quality threshold that would produce misleading displays, and some are duplicates of tracks already present in the destination network. Filtering rules encode these decisions.

Releasability filtering is the most sensitive. In a coalition of nations with different security clearances and different data sharing agreements, the gateway must enforce that nation A's tracks are releasable to nation B before forwarding them. The enforcement mechanism relies on attributes in the track record — classification marking, releasability caveat, originating nation — being carried faithfully through the normalization step. A gateway that normalizes away releasability markings is a security risk, not a feature.

Geographic filtering reduces clutter and bandwidth consumption. A consumer interested in the air picture over a specific area of operations does not need tracks from half a continent away. The gateway can apply a geographic boundary filter — a bounding polygon or a range-from-point limit — and suppress tracks that fall outside it. This is particularly important on bandwidth-constrained links where every track update consumes capacity that could carry higher-priority traffic.

Latency budget

The latency budget for a TDL gateway is the maximum additional delay the gateway may introduce on top of the native reporting latency of each data link. For Link 16 air tracks used in intercept or time-critical fire control, the native reporting cycle is already two to twelve seconds; adding several seconds of gateway latency on top produces a track that is operationally useless for time-sensitive decisions. For situational awareness displays at brigade and above, several seconds of additional latency is generally acceptable.

Latency in a gateway accumulates from several sources: input queue depth when message arrival rate exceeds processing rate, correlation processing time for complex many-to-many correlation scenarios, output serialization time for large batches, and network transit time to the consumer. The worst case — a burst of Link 16 updates during a high-intensity air engagement, all requiring correlation against a large existing track database — is precisely when latency matters most. Gateway designers must stress-test under realistic peak load scenarios, not just average-load benchmarks, and specify the 99th-percentile latency rather than the mean.

Open standards and the gateway ecosystem

The TDL gateway market includes both proprietary military systems and implementations built on open or published specifications. On the open side, the CoT schema is published and widely implemented; the TAK ecosystem has produced open reference implementations that form the basis of many government-developed gateways. NFFI (STANAG 5527) is a NATO standard available to member nations. MIL-STD-6016 and MIL-STD-2045-47001 are US standards with controlled distribution, but their message formats are sufficiently documented that independent implementations exist within the defense industrial base.

XMPP (Extensible Messaging and Presence Protocol) has emerged as a transport layer of choice for CoT distribution in the TAK ecosystem and in FMN, both because it provides reliable messaging semantics over IP and because its federated architecture scales to coalition use without a single central broker. Several national implementations of FMN messaging services are built on XMPP with CoT as the payload, creating a de facto coalition track distribution layer beneath the more formal NFFI architecture. Gateways that support XMPP as both input and output can serve both the TAK-centric ground forces community and the FMN-oriented coalition C2 community from a single integration point. The broader role of CoT in NATO interoperability is covered in our article on CoT and TAK in NATO interoperability.

The API gateway pattern — exposing TDL translation as a service over a REST or gRPC API rather than as a proprietary binary interface — is gaining traction as coalition architectures move toward service-oriented designs. An API-based TDL gateway can be integrated with coalition data sharing platforms, including the API gateway patterns for coalition data sharing described in our related analysis, without requiring bespoke low-level integration for each consumer system. The trade-off is that HTTP/REST adds latency relative to a direct binary connection — which may or may not be within the latency budget depending on the use case.

The MIP4 and IES standard — the NATO ground forces data model — defines the semantic layer that ground C2 systems should use when exchanging force information. A complete coalition gateway must be able to map to and from MIP's canonical entities and relationships, not just to NFFI's message format. For detail on MIP4 and IES, see our analysis of MIP4 and IES: the NATO ground forces data standard.