The Variable Message Format (VMF) Protocol – A Data Protocol for Radios (Part 1)

The VMF protocol is a SDR data protocol created to exchange information between multiple different systems by providing a rich and flexible specification. Yet, the VMF is little known even amongst avionics engineering and its knowledge remains the speciality of few. As such, in this post we explore this protocol in details to better understand its inner workings and its uses


Software-Defined Radio (SDR) is a fast-growing market, expanding in a wide array of industries. Growth in this sector alone is expected to reach $USD27.29 billion by 2020 [1]. When only considering that most smartphones are equipped with SDRs, one can quickly understand the active research conducted in the field. SDRs are also in high usage across militaries and law enforcement given the added flexibility to conduct multiple types of operations using the same hardware, often with reduced maintenance costs. Nowadays, military tactical radios and law enforcement equipment are all software-defined to some degree. Within the industry, 93% of all mobile systems leverage SDR for wireless communications [2]. The added agility introduced by software also comes with additional threats, previously absent from hardware-based radios. Within the military, SDRs form the cornerstone of network-centric warfare as they are used to establish networks between different units in order to exchange data such as position, imagery and target information rapidly between ground, maritime, air and space elements. Radios not only process voice; the internal software also manages various networks and data protocols, further increasing the complexity of the application layer of the communication device. The VMF protocol is one such SDR data protocol created to exchange information between multiple different systems by providing a rich and flexible specification. Yet, the VMF is little known even amongst avionics engineering and its knowledge remains the speciality of few. As such, in this post we explore this protocol in details to better understand its inner workings and its uses

Software-Defined Radios

An overview of the architecture of the SDR is required to better appreciate the threats against them and to eventually understand some of the unique characteristics when looking for vulnerabilities in their software. We do so by describing the general software model used by SDRs which have multiple layers, each of which uses different programs to process waveforms and the data contained in them. The Wireless Innovation Forum (WIF) simply defines a SDR as a radio in which some or all of the physical layers functions are software defined, contrasting with previous radios in which all configurable properties were designed and hardcoded into the hardware. Within the definition of WIF, the physical layers refer to the four lowest layers of the OSI model. This innovation allowed for additional agility into the functionalities of radios, as the integrated general purpose processors (GPP) or Field Programmable Gate Array (FPGA) units and the flexible radio-frequency (RF) modulators – all reconfigurable through software – permit the device to operate on a wider range of the spectrum depending on the current operations. These new components are all software controlled, allowing for fast reconfiguration as needed by the operator (see figure 1).

Simplified schema of the major hardware and software components of modern SDRs.
Figure 1. Simplified schema of the major hardware and software components of modern SDRs.

Within the SDR the Software Communications Architecture (SCA) is the open framework generally used to specify how a radio designer should integrate hardware and software components in order to interact efficiently and maximize software reuse [3]. The SCA was developed by the U.S. military as part of the now defunct Joint Tactical Radio System (JTRS). Despite it’s military roots, the SCA is used in the industrial sector as well. The framework divides the radio into 4 layers, each composed of multiple components. These are layers below the user applications (figure 2) and are responsible for processing the inbound and outbound data:

The Software Communications Architecture (SCA) is an open architecture framework abstracting interactions between hardware and software within a software defined radio.
Figure 2. The Software Communications Architecture (SCA) is an open architecture framework abstracting interactions between hardware and software within a software defined radio.

Programmable Radio Hardware; the Programmable Radio Hardware is the layer which regroups the software-reconfigurable elements of the radios such as the RF modulation units, the modems and the link interfaces.

Operating System and Middleware; the operating system, along with the Common Object Request Broker Architecture (CORBA) middleware play the critical role of managing the communications between the software of the core framework and the hardware. CORBA is a message passing technique that is widely used for cross-platform frameworks. All core interfaces are defined using the Interface Definition Language (IDL) which can be compiled in different languages such as C/C++ and ADA. The operating systems included in SDRs are Real-Time Operating Systems (RTOS) such as uOS, TinyOS or VxWorks. These provide multithread support and are required to be POSIX compliant. The RTOS also interfaces with the underlying network interfaces and serial ports.

Core Framework; the core framework is the abstraction layer between the software developers and the underlying hardware. It contains the interfaces and services required for the applications to use the devices of the radio by describing them using the eXtensible Markup Language (XML);

Waveforms; the software at this layer specifies the required parameters to form the needed waveform to communicate with networked devices. By reviewing the framework above, one quickly realizes that the world of radios is now mainly driven by software development and thus exposes itself to the same issues that plagues programs in the wider computing world. The terms ”operating system”, ”drivers”, ”middleware” and APIs are terms well-known to cyber operators and computer security analysts alike, thus making them a target the same way as any other host on any other network.

Tactical Radios

Software radios have significant advantages for the military as they provide a wide variety of dynamic radio protocols in real time. Since SDRs can be reprogrammed remotely for multiple purposes without any hardware changes, maintenance costs and time have decreased. Because of these characteristics, SDRs are one of the cornerstones of network-centric warfare, the currently predominant Western military doctrine. It is therefore not surprising that all tactical military radios in modern western militaries are SDRs, including most of civil aviation for law enforcement and potentially drones. Modern MTRs are more akin to routers than radios and enable the creation of instant networks and the exchange of operational data between the connected nodes over Tactical Data Links (TDL) such as Link-16. Data protocols such as VMF and the Joint Range Extension Applications Protocol (JREAP) enable the exchange of voice, data and imagery by connecting to a network of various platforms and units, both vertically and horizontally. Amongst the data exchanged are: positions, trajectories, maps, navigation data, mission data and intelligence. This implies the presence of user applications managing the data protocol, and additional applications processing the data received. Other data link protocols include the Type 483D, the Chinese equivalent to Link 4C. This transfer of information between platforms is central to the network-centric warfare doctrine which drives the research and development of network radios and increases the complexity of the software and network protocols. In many aspects, the radio can be considered the gateway device between the internal networks of a platform and external nodes requesting to connect to it. Internally within aircraft and ships many MTRs provide multiple interfaces to communicate with other elements of the platform, such as mission computers, display terminals and external software to display geoposition data for example. On a military aircraft, the interfaces of the radio usually include the MIL-STD-1553 bus (or its civilian counterpart, the ARINC429) to link with the avionics as well as Ethernet and serial ports such as RS-232 or RS-485, often used by Remote Control Units (RCUs) for management purposes via protocols such as the Simple Network Management Protocol (SNMP). Externally the radio networks the platform with external units using different systems by forming Mobile Ad hoc Networks (MANETs) and exchanges tactical data using data protocols over the tactical data links. These networks are wireless, infrastructureless, multi-hop and highly fluid. In military usage these are typically low-bandwidth links and are often managed by devices with little computational power. The Ad hoc On-Demand Distance Vector (AODV) is typically the underlying routing protocol, which manages routing in a peer-to-peer network. Routing information is updated constantly, as nodes within a MANET can also act as proxies for far-away nodes.

The Variable Message Format Protocol

The VMF standard was developed by the U.S. Department of Defense to allow messages of variable lengths to be sent over TDLs. A VMF message is bit-oriented and attempts to minimize the use of TDLs by sending only the required data. The objective is to be flexible enough to be able to communicate with any legacy and new host requiring that additional header fields can be added without modifying the underlying specification. The core of the VMF protocol is the Protocol Data Unit (PDU) which contains the header and the user data (figure 3), much like a typical TCP/IP packet. The PDU is processed at the application layer and is composed of the application header and the user data, which can be multiple format as we will see later on. The size of the former is always a multiple of 8 and is padded with null bits as needed.

Schema of the Application Header of a VMF message
Figure 3. Schema of the Application Header of a VMF message. which is composed of fields and grups.

Structure of the Application Header

The first 4 bits of the header always specify the version of the VMF protocol in used by the PDU. As of 2015, 5 revisions of the protocol have been created (table 1):

Code (binary) Revision
0000 MIL-STD-2045-47001A
0001 MIL-STD-2045-47001B
0010 MIL-STD-2045-47001C
0011 MIL-STD-2045-47001D
0100 MIL-STD-2045-47001D w/ CHANGE1
0101-1110 Undefined
1111 Version Sent Not Implemented
Table 1. Version numbers currently defined in revision D w/ CHANGE1

The “Version Sent Not Implemented” value is used to specify that the current implementation of the VMF protocol in the system is not backward compatible with the incoming VMF messages.  For example, a system using revision D of the protocol sending a message to another system using revision C or earlier will receive an answer with the version field set to “15”, specifying that the source system must use an earlier revision (figure 4). If the version is not implemented, but the destination system is still able to process the message, it will nonetheless.

Usage of the Version Not Implemented value
Figure 4. When a previous version of the VMF receives a message from a latter revision, it returns a message with the version field set to “Version Not Implemented” value.

Fields and Groups

Elements following the version number are either “fields” or “groups” as shown in figure 3. A field can generally be thought as single piece of data along with an overhead of 1 or 2 bits; a Field Presence Indicator (FPI) and a Field Recurrence Indicator (FRI). The FPI is a flag which indicate if a value for the field has been specified or not, e.g. if the FPI is set to zero, the following bit is the start of new field or group. If set to one, the following bits represents the value for the field. Some fields occur more than once. These fields include the FRI flag which is right after the FPI. When set to one, the field is repeated right after until the FRI is set to zero as illustrated in figure 5. Note that the FPI is included only once in the first field.

Example of the Field Recurrence Indicator (FRI) within a VMF message
Figure 5. Example of the Field Recurrence Indicator (FRI) within a VMF message used for the Release Marking field.

Groups, as their name suggest, are sets of related fields or sub-groups. A group have a depth down to 6 levels and possess the same presence and indicator flags as fields, which are known at the Group Presence Indicator (GPI) and Group Recurrence Indicator (GRI). The order of fields and groups of the header is fixed, much like any TCP/IP packet.

While most of the fields contain numeric values, some are 7-bit ASCII coded strings, where the value 127 (the DELETE character) is used as the string terminator, i.e. equivalent to the null byte ‘’ in C/C++ character arrays. The terminator is added to the string only if its bit-length is smaller than the maximum length of the field. For example, the “unitname” field is 448-bit long, i.e. 64 characters. If the unitname contains less than 64 characters, the terminator will be added to the value. A complete list of groups and fields, along with their description and constraints can be found in the specification (and maybe discussed in future parts of this article)

Assembly of a VMF Message

The creation of a VMF message is quite similar to the creation of a HTTP request or a TCP/IP packet: it is done via encapsulation of user data through the multiple layers of the SDR. User data is first entered into the radio, usually by the pilot or crew via a Remote Control Unit (RCU) or a subsystem via the internal MIL-STD-1553 bus or ARINC 629 data bus. The radio receives the MIL-STD-1553 message from the bus controller and extracts its data. It then determine to which units on its MANET to send the data. Note that data can be broadcasted to all units on the network via a broadcast address. The default broadcast address is 16777215. Within the SDR, the data is then transferred to the VMF messaging service of the device. Based on its configuration and properties of the data provided, the VMF layer will construct the proper application header and append the user data to form the application PDU.  The PDU is then send to lower layers, transformed into waveforms and digital data converted to analog radio waves to be sent via the antenna of the aircraft. The receiving unit then do the reverse process and dispatch the received data to the internal subsystems of the destination aircraft. The process is illustrated in figure 6.

Encapsulation process of user data into a VMF message.
Figure 6. Encapsulation process of user data into a VMF message.

User Data

The type of user data that is contained within the application PDU is defined by the User Message Format (UMF) field. This field indicates the format of the message contained in the user data field and is associated with the Functional Area Designator (FAD), the Message Number, the Message Subtype, CANTCO reason and CANTPRO reason fields. More about these fields in part 2 of this article.

Binary Files

VMF can be used to transfer files between systems and this is done by setting the UMF field with the value 1 and using the “Filename” field to specify the name of the file. Furthermore, to indicate that the message is a file transfer the GPI of the VMF Message Identification Group needs to be set to zero.

Redistributed Messages

When the UMF field is set to 0100 (4), the content of the user data is another VMF message, much like a forwarded email. Both the application header and user data sections of the redistributed message are included in the user data portion of the message forwarding it. The “Operation Indicator“, “Security Classification” and “Release Marking” fields are required to be similar in both messages. Both messages are to be processed by the receiving systems.


Nodes (hosts) on the network can be identified using one of the following fields: the URN or the Unit name. Both cannot be used at the same time normally. The URN is, as its name implies, a number given to a specific unit to identify it. It acts as a MAC address would. Each URN is unique and only as one unit bearing the number. Distribution of these URN is made by the U.S. Department of Defense. This URN is the addressing scheme at the application layer. VMF can be carried via TCP/IP (or UDP), MIL-STD-1553 or any other lower layer. Note that other addressing scheme can be used, but these will be explored later on.


This concludes part 1 of the introduction to the VMF protocol. In part 2, we will explore further the fields included in the latest revision of the protocol and include actual example of VMF messages. In the meantime, you’re welcome to play with Vmfcat, which is a Python script I’m working on (still incomplete) to generate VMF messages from the command line or via an interactive shell.

Leave a Reply

Your email address will not be published. Required fields are marked *