News

Standardized HF waveforms are important, but not sufficient

6th May 2026 HF Radio Icon-5066 Steve Kille Blog

About the author

Steve Kille has worked over many years on open standards for Messaging, XMPP, Directory, Security, and HF Radio. He has worked on CCITT, IETF, XSF, and NATO standards (currently editing STANAG 5066), which have been implemented by Isode.

He is also Isode’s CEO.

This blog post is intended as the first of an intended regular series that will cover a broad range of topics across the various industries and product sets that we work with. I intend to share information that might be of interest, but is not appropriate for the more technical white papers or other Isode website material.

This post arose from a recent enquiry about whether Isode could support application interoperability between a widely deployed army modem (PRC-150) and a widely deployed airborne modem (ARC-220). We’ve handled many similar queries and expect to see this situation arise more frequently as allied militaries look at updating their legacy HF deployments.

The issue at hand.

As allied militaries look at implementing new applications and functionality into their deployments, they are going to run into compatibility issues with the support of waveforms and standards across their radio networks.

HF vendors have been good about following waveform standards. Historically, MIL-STD-188-110B and STANAG 4285, moving onto newer ones, in particular STANAG 4539 and STANAG 5069 (equivalent to MIL-STD-188-110C/D). The issue comes from older radios not supporting the newer waveforms and is likely going to disproportionately affect Army and Airborne systems rather than Naval systems. This is due to the differences in standard network requirements.

Naval systems have widely deployed STANAG 5066, which is the standard HF link layer over the modem. This is used in conjunction with stream crypto boxes. Initially, this was to support ACP 127 military messaging, but it gives a clean migration to the new NATO BRE1TA applications and all the things Isode supports. You can read more about this here.

Once you have STANAG 5066, you are open to a wide range of applications.

Many army and airborne systems have not tracked 5066, which means that they are either voice only or do data applications with proprietary stacks. This prevents application interoperability and is the root cause of the problem we’re running into.

How do we solve it?

The solution is for vendors to adopt NATO standards at all layers. In particular, to support STANAG 5066 and NATO-style crypto. Once STANAG 5066 is in place, you can run Isode applications (or equivalent apps from other vendors) to provide application interoperability.

Isode is very keen to see this addressed and to work with end users and modem vendors. The key requirement is for HF suppliers to support STANAG 5066, which can be from any supplier. Once STANAG 5066 is supported, applications using STANAG 5066 can be easily deployed above this layer.

Icon-5066 (Isode’s STANAG 5066 product) is designed to be modem independent, and it provides support for several vendors; you can view that list here.

We are keen to work with modem and radio vendors to extend this list.

This solution needs to be end-user driven in two ways. Primarily to provide the incentive for radio vendors to develop their legacy systems so that they can support the newer waveforms. And secondly, when distributing requirements for new systems, be clear about the specifics; the more detail included in these requests, the better.

If the specifications are “waveform only” and generic applications specification (e.g., “Chat”), the result will be proprietary applications that do not interoperate. It is critical to specify the use of STANAG 5066 and any crypto needs. It is also important to specify application protocols (e.g., for Chat, suggest specifying XMPP with HF support following XEP-0365). This specificity will ensure that radio manufacturers are focused on developing hardware and systems that can interoperate with other manufacturers, rather than continuing to develop proprietary hardware that can only interact with systems from their own lineup.

There is a clear route forward to resolving this issue; however, it needs to be led by end users rather than companies like Isode. Until that happens, we expect to have more conversations on this topic and will continue to guide end users as best as we can.