Variable Message Format (VMF): tactical air-ground data link messaging for interoperability

Ground forces calling for air support and the aircraft responding to that call share a problem that has defined tactical aviation since the Second World War: the two sides operate different radios, different command languages, and different situational pictures. Variable Message Format (VMF), standardized under MIL-STD-47001, is the US military's answer to that coordination gap on the digital side. VMF defines a binary-encoded message set that runs over conventional tactical radios -- no specialized terminal hardware required -- and carries the structured data that fire support chains need to coordinate close air support, artillery fires, and air interdiction with precision timing and legal accountability. This article examines how VMF messages are constructed, how they traverse constrained radio links, how they connect to C2 systems such as AFATDS and CPOF, and how they compare with Link 16 for air-ground coordination across joint and coalition networks.

What VMF is and where it sits in the tactical data link landscape

VMF is not a radio waveform and it is not a network protocol in the IP sense. It is a message encoding standard: a set of rules that specify how each field of a tactical message is packed into a binary bit stream, how the message is addressed, and what application-layer acknowledgement and retransmission behavior is expected. The radio waveform -- SINCGARS frequency-hopping, HAVEQUICK II, UHF SATCOM, or a software-defined radio running a tactical waveform -- is a separate concern. VMF sits above the waveform as an application layer, making it portable across any radio that can carry digital data.

In the broader data link landscape, VMF occupies a specific niche: digital messaging for ground-to-air and ground-to-ground fire support coordination. It is neither a surveillance link nor a track-sharing link. VMF does not broadcast continuous position tracks the way Link 16 J-series messages do. Instead it carries discrete, transaction-oriented messages -- a call for fire, a target handoff, a clearance to engage, a battle damage assessment -- that correspond to the procedural steps of a fire support coordination chain. This transaction model is well suited to the intermittent, low-duty-cycle nature of HF, VHF, and UHF tactical radios, which cannot sustain the continuous high-throughput transmission that Link 16's TDMA network requires.

The standard has evolved through several revisions, with MIL-STD-47001D (and its predecessor versions under the 2045-47001 designation) defining the current message set. The message catalogue covers free text (K01 series), call for fire (K04 series), digital close air support (K05 series including the digital nine-line), sensor reports, battle damage assessments, and administrative traffic. Each message type is assigned a unique identifier and a fixed field layout, allowing receiving software to parse incoming bit streams without out-of-band signaling about message content.

VMF message structure: header, originator, recipient, and payload fields

Every VMF message begins with a standard application header defined in MIL-STD-47001. The header carries the fields that route and prioritize the message independently of its content: message number (a sequence counter used for acknowledgement matching), originator unit identifier (URN -- Unit Reference Number), recipient unit identifier or broadcast address, message version, classification, precedence level (ROUTINE through FLASH OVERRIDE), and a field acknowledging or negatively acknowledging a previously received message. The header is compact -- typically 40 to 60 bits -- because every bit spent on overhead is a bit not available for payload data on a constrained link.

Following the header, the message carries an originator block that identifies the sending unit in the fire support chain. This block includes the originator's URN, the originating unit's parent organization code, and a timestamp encoded as a time-hack relative to a common reference (typically GPS time). The timestamp is critical for fire support deconfliction: when multiple units are transmitting fire requests simultaneously, the timestamp in the originator block establishes precedence and provides the audit trail that commanders require to reconstruct the sequence of events after a friendly fire incident.

The payload fields vary by message type but follow the same binary packing discipline throughout. Coordinates are encoded as latitude and longitude to 0.0001 arc-minute resolution (approximately 0.19 metres at the equator), packed into the minimum number of bits needed to span the full geographic range. Enumerated fields -- target type, mark type, munition type, effect desired -- are encoded as integer indices into the VMF code table, consuming only as many bits as the table size requires. A mark type field with eight valid values requires only three bits. This systematic minimum-bit encoding is the mechanism that lets VMF messages carry a full nine-line close air support brief in under 400 bits -- a transmission that completes in under one second on a SINCGARS net.

Field encoding: binary compaction and message efficiency in bandwidth-constrained links

The defining technical characteristic of VMF is its approach to field encoding. Where XML-based messaging standards such as XMPP or even the CoT (Cursor on Target) schema use variable-length text representations of numeric values -- a latitude of 49.1234 degrees occupies seven ASCII characters, or 56 bits -- VMF packs the same value into a fixed-width integer field of 22 bits. The savings compound across every field in the message. A complete digital nine-line (K05.4 CAS request) that would occupy roughly 500 bytes as a text message encodes to under 50 bytes in VMF binary form. On a 9.6 kbps SINCGARS radio net carrying multiple simultaneous users, this difference is the margin between a message that fits in a single transmission slot and one that requires multiple slots and introduces contention delays measured in seconds.

VMF also uses conditional field inclusion to avoid transmitting fields whose values are absent or not applicable to a given message instance. The message definition tables in MIL-STD-47001 specify, for each field, whether it is mandatory, optional, or conditionally mandatory depending on the value of another field. Optional fields are preceded by a presence bit: a single bit that indicates whether the field follows. If the presence bit is zero, the field is absent and the parser advances to the next field without reading any bits for the absent value. This mechanism allows the same message type to span a wide range of operational scenarios -- from a minimal fire request that carries only the essential targeting data to a fully populated request with alternate targets, terminal attack geometry, threat data, and aircrew remarks -- without requiring separate message types for each combination.

Error detection in VMF relies on a cyclic redundancy check (CRC) appended to each message. The CRC catches bit errors introduced by radio channel noise, multipath, and jamming. When a VMF terminal detects a CRC failure, it discards the message and either sends a NAK if the message carried a message number (prompting the originator to retransmit) or silently drops it if it was a broadcast without an acknowledgement expectation. The combination of compact binary encoding and CRC-based error detection makes VMF resilient to the imperfect channel conditions typical of tactical VHF and UHF links in mountainous or urban terrain.

Radio transmission modes: UHF SATCOM, VHF/UHF line-of-sight, and PACE planning

VMF messages are agnostic to the radio medium that carries them, but operational planners must account for the very different characteristics of the available transmission modes. The most capable mode for beyond-line-of-sight (BLOS) coverage is UHF SATCOM, operating in the 225-400 MHz band through military constellations (Milstar, AEHF, MUOS) or commercial UHF SATCOM. SATCOM provides global range and is not subject to terrain masking, making it the preferred primary or alternate path when a ground unit cannot achieve LOS with the supporting aircraft. The tradeoff is latency: geostationary SATCOM paths introduce a 240-280 ms one-way propagation delay that is negligible for most CAS coordination timelines but must be accounted for in time-sensitive targeting workflows.

VHF/UHF LOS radios -- including the Harris AN/PRC-117G wideband manpack, the Thales AN/PRC-148 MBITR, and airborne radios in the AM-7/ARC-210 family -- provide direct links when terrain and altitude permit. An aircraft at 10,000 feet AGL has a radio LOS range of approximately 120 nautical miles to a ground terminal at sea level, shrinking to 30-40 nautical miles in mountainous terrain with significant shadowing. LOS links offer lower latency than SATCOM (essentially zero propagation delay at tactical ranges) and higher instantaneous data rates on wideband waveforms, but they require coordination of net membership and frequency plans across all participating units.

PACE planning -- Primary, Alternate, Contingency, Emergency -- is the operational framework that governs how VMF users sequence across these radio modes when a transmission path degrades. A typical PACE plan for a digital CAS coordination element might designate UHF SATCOM as primary for BLOS coordination, VHF LOS as alternate when the aircraft enters range, HF radio with VMF-over-HF as contingency, and voice-only FM radio as the emergency fallback when all digital paths fail. The VMF message standard supports all of these transport modes because it defines only the message encoding, not the transport -- any radio that can carry digital data at or above the minimum bit rate for the waveform can carry VMF.

Integration with C2 systems: AFATDS, CPOF, and other VMF-capable platforms

VMF's operational value is realized through its integration with the software platforms that manage the fire support coordination chain. The Advanced Field Artillery Tactical Data System (AFATDS) is the primary VMF C2 node on the ground side. AFATDS receives digital calls for fire (K04 series messages) from forward observers, performs automated checks against loaded fire support coordination measures, computes firing data for organic artillery, and forwards CAS requests (K05 series) to the appropriate fire support coordination element. When an AFATDS operator approves a digital nine-line, the system transmits the VMF K05.4 message over the connected radio, simultaneously logging the transaction with the originator timestamp, mission number, and operator identity for accountability.

The Command Post of the Future (CPOF) provides the battle command visualization layer above AFATDS. CPOF receives VMF messages forwarded by AFATDS and renders target locations, mission status, and fire support coordination measures on the common operating picture available to the brigade and battalion commander. This gives senior commanders situational awareness of ongoing fires without requiring them to monitor the fire support radio net -- the VMF transaction history is surfaced as a structured log on the CPOF display rather than as voice traffic requiring manual transcription. Gateway software that bridges VMF, Link 16, and CoT can extend this picture to platforms that do not natively speak VMF, allowing ATAK clients and joint C2 nodes to receive fire support status derived from VMF transactions.

On the aviation side, VMF integration varies by platform and avionics configuration. AH-64D/E Apache helicopters carry the Improved Data Modem (IDM) or its successor, which handles VMF message encoding and decoding and interfaces with the aircraft's multifunction displays to present decoded nine-lines to the crew. A-10C aircraft equipped with the Situational Awareness Data Link (SADL) support VMF along with other data link formats. The ROVER terminal used by JTACs and special operations forces supports VMF for digital CAS coordination alongside its primary function of receiving full-motion video from aircraft and UAS. The practical interoperability constraint is that all nodes in a VMF transaction -- originator, relay if any, and recipient -- must be running compatible versions of the MIL-STD-47001 message definitions, or message parsing will fail on version-specific fields added in later standard revisions.

Close air support workflow: how VMF coordinates fires and air requests

A VMF-supported CAS mission follows a structured sequence that begins with the forward observer or JTAC identifying a target and ends with a confirmed battle damage assessment in AFATDS. The JTAC or FSO uses a VMF-capable terminal -- a ruggedized handheld, a vehicle-mounted radio system, or a laptop running a fire support application connected to a tactical radio -- to compose a digital nine-line (K05.4 message). The terminal's software pre-populates fields from loaded data: the JTAC's URN, the current time-hack from GPS, and any pre-planned target reference points. The operator enters or confirms the variable fields: IP or offset aimpoint coordinates, target elevation, target description code, mark type and laser code, desired terminal attack geometry, known threats, and egress direction. The completed message is transmitted over the primary radio path defined in the PACE plan.

When the attacking aircraft receives the VMF nine-line, the avionics system decodes the message and pre-populates the fire control computer with the target coordinates and terminal attack geometry. The pilot or weapons officer reviews the decoded data on the multifunction display, confirms the laser code is set on the targeting pod or designator, and sends a VMF acknowledgement (K05.4 ACK) indicating receipt and readiness. This digital read-back replaces -- or supplements -- the verbal read-back in the traditional voice CAS procedure, reducing the voice communication load on congested radio nets and providing a machine-readable confirmation record. The JTAC monitors the attack run, verifies the mark is acquired, and when all abort criteria are clear, either transmits a VMF clearance message or issues a verbal "cleared hot" over the voice net, depending on the unit's standing operating procedure for digital-voice integration.

Battle damage assessment closes the transaction. After weapons impact, the JTAC or aircrew transmits a VMF BDA message (K05.7 or equivalent) carrying the assessment of effect, the confirming sensor type, and the time of assessment. AFATDS records the BDA against the mission number, updates the fire support execution matrix, and makes the BDA available on CPOF. The complete VMF transaction record -- request, acknowledgement, clearance, and BDA -- provides the accountability chain that rules of engagement and post-engagement review require. In high-tempo operations where dozens of CAS missions may execute within hours, this automated record-keeping is qualitatively different from the manual logs that voice-only procedures produce.

VMF vs Link 16: choosing the right data link for air-ground coordination

VMF and Link 16 are complementary rather than competing standards, but understanding where each excels is essential for data link planning. Link 16 is a high-capacity TDMA network that distributes surveillance tracks, identification friend-or-foe (IFF) data, and picture information continuously across all network members. A Link 16-equipped aircraft can see every other Link 16 participant's position on its tactical display without any individual transaction -- the network broadcasts position updates on a fixed schedule. This makes Link 16 powerful for air-air coordination, airspace management, and composite air operations where situational awareness across the entire force is the primary requirement. Link 16 and Link 22 gateway translation extends this picture to coalition partners and platforms on adjacent networks.

VMF's advantage is accessibility and specificity. A JTAC with a Harris AN/PRC-117G can originate a digital nine-line VMF message without JTIDS terminal hardware, without network membership enrollment, and without the frequency management overhead that a Link 16 TDMA net requires. VMF is designed for the transaction-oriented fire support workflow: a discrete request, a discrete response, a discrete outcome. It does not attempt to distribute a continuous surveillance picture -- it transmits the specific targeting data that a specific fire mission requires, addressed to a specific recipient, with acknowledgement and retransmission built in. This makes VMF the more practical choice for direct ground-to-aircraft digital CAS coordination, particularly in environments where Link 16 terminal availability on the ground side is limited.

The selection framework is straightforward in most cases. Use Link 16 where JTIDS terminals are available on both sides and continuous picture sharing is the primary value. Use VMF where the ground element has conventional tactical radios, where the mission is fire support coordination rather than surveillance sharing, and where the transaction-oriented nine-line workflow maps naturally to the operational procedure. In joint and combined operations, the two data links often run simultaneously: Link 16 provides the air picture and track data while VMF handles the fire support transactions, with message format library standards ensuring that gateways between the two domains translate correctly and without data loss. Operators working across both systems need visibility into message delivery status and link health across all active data link types -- a requirement that grows more complex as the number of participating platforms and data link types increases.