November 2014


This whitepaper describes Icon 5066, an Isode server product, currently in development, that implements the NATO STANAG 5066 link level protocols which sit between HF modem and Applications. Applications access Icon 5066 using the STANAG 5066 SIS protocol over TCP.

This paper shows how Icon 5066 fits with Isode's strategy of supporting applications running over HF Radio.

Creative Commons License


STANAG 5066 provides a link layer optimized for HF Radio and described in [STANAG 5066: The Standard for Data Applications over HF Radio]. Key capabilities provided by STANAG 5066 to the applications include:

  • Multiplexing multiple applications over a single modem link, providing application access using the STANAG 5066 SIS protocol.
  • Optimizing for the unusual characteristics of an HF Radio link.
  • Supporting two or more HF nodes.
  • Data checksum to ensure reliability.
  • ARQ mode for reliable point to point data transfer and non-ARQ for EMCON and Broadcast.

Isode sees STANAG 5066 as the best way to provide application services over HF Radio, and offers STANAG 5066 SIS support in a number of its applications.

Why an Isode Product?

STANAG 5066 SIS provides a natural separation between "application" and "HF". As most HF modem vendors provide STANAG 5066 capability, a straightforward approach which Isode has been following until now is to make use of modem vendor provided STANAG 5066 servers. Isode has chosen to write Icon 5066 because modem vendor provided STANAG 5066 servers do not provide a number of desirable capabilities. Icon 5066 will enable optimized application deployment over any HF Modem. Key capabilities:

Capability Current Products Icon 5066
Support for a wide range of applications and latency optimization. Often optimized for CFTP (Battle Force Email) and have poor performance when used by some applications that have no awareness of the issues around latencies Designed for high performance with a wide range of applications and designed to work with both "bulk" applications that needing tuning for high throughput and with applications that need optimization for latency
Platform support Often limited to Windows Icon 5066 will run on all of the supported Isode platforms
Wideband HF (WBHF) Often not supported A key target, important for future HF deployment
STANAG 5066 Annex L. Rarely supported Annex L is vital for interoperable multi-node deployment and is a key Isode target
Web Management Typical products have PC GUI management only Web management is key to flexible deployment in complex configurations and beneficial for simple setups

Icon 5066 Architecture

The Icon 5066 architecture is shown in the below diagram, and is described in the sections below that describe various aspects of Icon 5066

Icon 5066 Core

The core of Icon 5066 implements the central protocols of STANAG 5066 to provide a link layer service over the HF Modem layer. In particular:

  • Annex A: This provides the SIS service and protocol for client access and in particular the Unit Data service with confirmed (ARQ) and not-confirmed (non-ARQ) variants.
  • Annex B: "Channel Access Sublayer". This provides management of "soft links" which are established between two systems to provide ARQ service.
  • Annex C: "Data Transfer Sublayer". This is the core link layer protocol of STANAG 5066.

When data has been (fully and correctly) received it is immediately sent to the appropriate application (SIS client). This is noted first as it is the easy part.

For outbound data, Icon 5066 needs to marshal data from multiple SIS clients and handle connections to multiple peers, establishing and breaking soft links for reliable (ARQ) data. Approached taken are discussed later under "Application Tuning and QoS".

Modem Interface

Interface to the modem is provided by an independent layer in Icon 5066 with a clearly defined API between the layers. This separation reflects that the core implements a clearly specified protocol, whereas there is need for significant flexibility and adaptation in the layer below.

Modem Drivers & Lua

The layers below the Modem Interface (Modem Driver, Rate Change, Annex L) are coded in Lua which is a high performance embedded scripting language. The reason for this is to enable straightforward Isode and Isode customer modification of these components independent of the Icon 5066 core. The core capability of the modem layer is to drive the HF Modem associated with an Icon 5066 instance.

A key target for Icon 5066 is to be modem independent. The choice of Lua as the implementation language means that drivers can be easily developed, modified and maintained. Isode provides documentation for modem driver writers and modem driver test tools (described below).

While we wish to support a wide range of modems, a key target is modern high end modems that provide leading edge HF capability. These will typically connect over TCP with a high functionality interface developed by the modem vendor. Isode is demonstrating flexible support in this area by supporting two families of modems:

  1. RapidM RM6/RM8 family using the RAP1 protocol.
  2. Rockwell Collins VHSM 2500 family of modems.

We believe it will be straightforward to add support for more modem families, and this flexibility has shown the benefits of using Lua.

Data Rate Change

It is usually desirable to adapt data rate and other parameters such as Interleaver and DPDU size to optimize performance. Isode has been investigating the best approach here with information discussed in [Optimizing STANAG 5066 Parameter Settings for HF & WBHF] and "Analysis of OTA Measurements".

This research is clearly indicating that there is significant potential for improvement on algorithms in current use and that this is an area where it is likely that deployment experience and further work will lead to algorithm tuning and changes. The Data Rate Change module is implemented in Lua, and this will facilitate Isode and customer/partner work on the algorithms.

The following is a short summary of our current "best view" from the analysis in the papers above. This is for Skywave. We do not yet have sufficient data on Groundwave to take a clear view:

  • Speed choice will be based on SNR measurements, over a period of at least 10 minutes where possible, and historical performance data. Speed choice based primarily on behaviour of the last transmission (often 2 minutes max length) will be avoided, as it is clear that this is sub-optimal.
  • DPDU size will be set to 1024 for speeds of 9600 and above. For slower speeds, DPDU size will be set according to speed, with smaller values at lower speeds. For mid-range speeds this will be the STANAG 5066 recommended size of 2-300 bytes.

Annex L: Multi-Node (Wireless Ring)

Annex L was added to Edition 3 of STANAG 5066 to support multi-node operation. Prior to Annex L, STANAG 5066 (without proprietary extensions) can only be used in two modes:

  1. Between two nodes, using a soft link to control which end is sending.
  2. In a multi-node system where nodes are usually silent. Collision on starting to send will be unlikely and “listen before send” prevents collision after a node has started to send.

Busy multi-node systems need a mechanism to control which node sends. Annex L provides this by a Wireless Ring Token Protocol (WRTP). Although the protocol looks complex, the basic approach is simple. Nodes communicate using the built in Engineering Order Wire (EOW) messages to exchange a single token and additional management information.

The core Icon 5066 passes EOW messages to the modem interface layer. EOW messages are used for data rate change as well as Annex L. A Lua module in Icon 5066 implements the message exchange and token control, which enables it to provide control information to Icon 5066 core as to when to send.

Separation of Annex L in a module that is easy to adapt is important. There is very little experience with Annex L (only one known implementation) and we expect it will need to evolve based on experience. Two areas that may need addressing:

  1. Data Rate Change. Currently Annex L can only be used fixed speed, which seems an unfortunate restriction.
  2. Annex L experience suggests that there are undue delays caused by "ring formation" after errors. It would be useful to investigate approaches to address this.

Isode anticipates research and adaptation of Annex L, and it may also be helpful for partners to do this too.


The primary Icon 5066 configuration is held in an XML file. This holds:

  • Core Icon 5066 Parameters.
  • Modem Driver Parameters. These are held in a generic manner that is transparent to the core server and they are passed to the modem driver on initialization. This allows modem drivers to define independent configuration options.

The XML file may be edited directly, although it will usually be configured with the Web management described later.

WBHF Support

A key target for Icon 5066 is support of Wide Band HF, which uses a channel of up to 24 kHz (rather than the current standard 3 kHz) to provide speeds up to 120 kbits/sec (increasing from the current Narrow Band top speed of 9600 bits/sec). This improvement of speed is very interesting to deploy new applications.

The waveforms to provide WBHF are defined in US MIL-STD-188-141C Appendix D "Data Waveform Suite".

Although the bulk of technology needed to make WBHF work is at modem level and below, there are some necessary changes that directly impact Icon 5066:

  1. The current STANAG 5066 protocol has performance problems at WBHF speeds. The problem, and a proposed solution implemented by Icon 5066 is described in [Extending STANAG 5066 to improve ARQ Performance over Wideband HF Radio].
  2. Data rate change needs to be handled. This is discussed in [Optimizing STANAG 5066 Parameter Settings for HF & WBHF]. Icon 5066 will support a WBHF data rate change mechanism. Isode is currently researching the best approach.
  3. There will need to be an interaction between Icon 5066 and ALE (Automatic Link Establishment) to ensure correct configuration of bandwidth. Initial WBHF deployment is likely to be without ALE. Isode will work with ongoing (US) standardization of 4G ALE and with vendor implementations

Application Tuning & QoS

Typical STANAG 5066 servers and the literature on STANAG 5066 have focused on optimizing throughput. This is important for some applications, but not for all. For example XMPP traffic is typically small messages, where throughput (even at HF speeds) is not a big issue but minimizing latency is. For HF, minimizing errors is key to low latency and this means transmitting at a slower speed. Another technique that can be used is to transmit data twice. This can often be done without any performance overhead by utilizing "spare" space in the final interleaver block.

The key point is that application QoS requirements along with priority of specific traffic needs to be a factor in the choice of detailed HF transmission parameters. Icon 5066 has the model that "sender decides" based on local requirements, historical data, and information from the receiving system (which is the best place to measure SNR and error rates). We anticipate tuning and changing these algorithms and enabling customer modification. This capability is part of the Lua data rate change module.

A generic strategy in Icon 5066 is to hold a very short queue. Icon 5066 will aim to only accept data from applications (clients) that it anticipates being able to transmit quickly. It will need to manage this data until it is acknowledged, including any retransmissions. However, it will not build up a large queue of pending data. The short queue strategy means that applications will generally hold queued data. While this may entail additional application logic, it has the following benefits:

  • In the event of Icon 5066 failure or restart, very little data will be lost. This means that Icon 5066 does not need to hold disk copies of queues (i.e., queues do not get recovered after restart). This is a useful simplification.
  • Applications have the option to send data by alternate paths. This is much easier to manage when data is held by the application (rather than longer queues in Icon 5066).
  • By sending data late, it allows the application to be responsive to change of conditions. For example an operator may delete a pending message or a higher priority message may arrive. Short Icon 5066 queues enable the application to handle this sort of change.


Icon 5066 stores history of data transfer, including error information and associated information such as SNR. This is stored by the Icon 5066 core, with storage requests coming from the modem driver. The history database is embedded in Icon 5066 (Sqlite) and can hold extensive history if needed. There are a number of uses of history:

  1. Data rate change needs access to historical data to give best choices.
  2. Provision of information to the operator. The Web UI will allow the operator to view history, which can help analyse and understand current or recent conditions.
  3. Data for retrospective analysis. The history can record operational information showing conditions and how Icon 5066 reacted to them. This can be used to understand what went on, and provide analysis to help tune and optimize future performance.

Crypto Devices & Modem Control

The Icon 5066 system diagram above shows a simple connection from Icon 5066 modem driver to a HF Modem or Crypto device. Icon 5066 offers a number of configuration options which are shown and described below.

Where a modern HF modem is connected directly to Icon 5066 it will use TCP, as seen below. Some modems use a single TCP connection and others use separate connections for control and data. This will use protocols proprietary to the modem vendor.

The below diagram shows the configuration that could be used with an older modem for a fixed speed setup. Icon 5066 connects to the modem with a single serial connection for data transfer. Modem control is done independently.

A modified version of the previous configuration for older modems is to use a second serial line to provide modem control. This will typically use a simple text protocol to provide basic control (such as speed and waveform) and to report SNR. It may follow STANAG 5066 Annex E. This is essential if data rate change is to be used. It is also preferable for fixed speed, as it enables configuration through the Icon 5066 Web interface.

When a Crypto box is used for link encryption, which is normal for military deployments, there will be a data connection from Icon 5066 to the Crypto box. Many Crypto boxes will only provide serial interfaces, although newer ones also offer TCP. Control goes from Icon 5066 to the HF modem. This is likely to be a TCP link for a modern modem. This control gives a "crypto bypass" which may need security accreditation, shown in the below diagram.

Serial Lines

Driving serial lines is a critical part of the Icon 5066 modem driver, as there are clear requirements to drive devices over serial lines. Some devices, in particular Crypto boxes, will require synchronous interfaces, which will typically require specialist hardware drivers and associated software.

The Icon 5066 serial interface is abstracted from the modem driver which may run a serial driver within the interface or in a separate process with an optimized RPC interface. Isode will provide processes to interface with standard asynchronous Windows (COM ports) and Linux interfaces. This abstraction will enable support of future interfaces, in particular:

  • Specialist synchronous drivers with non-standard APIs.
  • Serial Hubs, which enable connection to multiple serial devices over a network connection. This gives a flexible way to connect serial devices from multiple servers

The model will also allow third parties to provide built in Lua serial drivers or external processes.

Dual Site

Icon 5066 can be configured to drive two modems, one for transmit and one for receive. These will usually be located at separate sites (usually at least a few miles apart) so that the receiver can operate at the same time as the transmitter, which is not possible if they are close together. The two modems are controlled independently.

It is possible to use TCP or Serial links and to use Crypto devices with the modems. There are two distinct modes of operation.

  1. Half duplex. This will typically be used with a remote system in simplex mode with just a single modem and antenna (e.g., split site on a shore system and single system on a ship). Benefits of this operation:
    • The Tx and Rx antennae can be optimized for transmission and reception respectively.
    • Because the Rx system can listen the whole time, this setup helps avoid scenarios where both systems are transmitting (which cannot be detected between a pair of Simplex systems).
  2. Duplex. This will be used between a pair of dual site systems. Duplex operation of STANAG 5066 can significantly improve performance as the very long turnaround times can be eliminated

Web Management

Icon 5066 management uses an HTTP interface with a protocol using information encoded using JSON (JavaScript Object Notation) following the JSON-WSP (JSON Web Service Protocol) approach.

The first goal of this architecture is to enable human users to configure and monitor Icon 5066 using a standard Web Browser. This will use JavaScript to run in the browser (supporting the JSON-WSP protocol) to provide a GUI interface.

Web browser access enables configuration and monitoring of Icon 5066 from any location. This is important for:

  • Complex configurations that make use of multiple Icon 5066 servers to support multiple modem and radio subsystems. Flexible client/server management is key to this type of deployment.
  • Simple systems to enable remote configuration where local staff do not have the skills to make changes.

The second goal is to enable access from other applications and the Web Services interface to Icon 5066 allows for this. Some examples as to how this might be used:

  • A complex HF deployment needs to control multiple modems, radios, and Icon 5066 servers. This protocol access allows a single management tool to control all of these components – it can use the web services interface to control Icon 5066.
  • Isode’s MConsole product monitors message queues in Isode’s M-Switch and in "Message Transfer View" shows progress of individual messages with ACP 142. This works well for transfers of Satcom, but with HF radio the long turnaround times make accurate reporting difficult. By having MConsole query Icon 5066, we plan to achieve improved reporting.

Core Configuration

Icon 5066 maintains its configuration in an XML file. This includes modem driver and serial line interface configuration which will be held in the core configuration, although will only be interpreted by the modem drivers and not by the core.

The web browser interface will display the configuration and allow modification of the configuration by an authorized user. This will be done so that it is easy to modify Icon 5066 configuration in a Web browser from any location.


The plan for Icon 5066 is to provide comprehensive monitoring with a Web GUI. With application level monitoring of applications running over HF Radio, it can be hard to distinguish between normal operations when things work slowly and when things are not working or are working sub-optimally. Our approach is to provide comprehensive monitoring to include:

  • Modem status information, showing transmit/receive/idle/voice status and basic parameters such as speed and waveform.
  • Currently connected SIS clients, identifying application by SAP and showing which are flow-controlled.
  • Summary of data queued for send and waiting for acknowledgement.
  • Length of current send/transmit, with status bar showing progress.
  • Composition of current and recent send/receive sessions showing data split by client (SAP).
  • History of receive quality showing SNR (Signal to Noise Ratio) history and FER (Frame Error Rate) pattern.

Associated Tools

Isode provides a number of tools to facilitate deployment of applications with Icon 5066.

STANAG 5066 Console

STANAG 5066 Console is a management GUI tool that can connect to Icon 5066 or any STANAG 5066 server. It is used for:

  • Connection setup and service discovery.
  • Performance Testing (shown above)
  • HF Operator Chat.


A system including applications and Icon 5066 operating over HF Radio needs a range of testing. Over The Air (OTA) testing is an important element, but it is generally impractical to conduct all testing this way.

Use of HF modems connected by hardware channel simulators is a useful way to test, but has limitations:

  • It needs quite a bit of HF Hardware.
  • It is impractical for regular regression tests.
  • It is impractical for testing with more than two nodes.
  • Some aspects of a real system, in particular Intermediate Term Variation are not covered.

So this has led Isode to develop MoRaSky which simulates (HF) Modems Radio and Sky (Ionosphere). MoRaSky is used by Isode for testing and measurements and is made available to Isode customers and partners for testing.

The above diagram shows a test configuration with multiple instances of Icon 5066 connected to MoRaSky. Here, Icon 5066 is driven by Isode’s SISTest tool that specifically tests STANAG 5066 using the STANAG 5066 SIS protocol interface. It could also be used with applications operating over Icon 5066. Icon 5066 connects to MoRaSky using a modem driver, and MoRaSky behaves like a standard modem to Icon 5066.

MoRaSky was built and calibrated using measurements from real modems operating over channel simulators. This covers:

  • Emulation of commonly used HF waveforms: STANAG 4539; STANAG 4285; STANAG 4415; MIL-STD-188-110C Appendix D (WBHF)
  • Timings reflecting block sizes/interleavers selected for the waveforms
  • A variant of channel conditions, in particular the CCIR values which are suitable for simulating Skywave and Additive White Gaussian Noise (AWGN) which is an appropriate model for Groundwave.
  • Characteristics reflecting modem timings and propagation delays

MoRaSky characteristics are derived from measurements of real modems operating over channel simulators.

MoRaSky has an underlying Ionosphere model which allows emulation of long term trends based on SNR. It is also possible to configure operation with a specified Bit Error Rate (BER) with configurable levels of error clustering (to reflect that errors will tend to be grouped with modern modems using convolutional codes).

Intermediate Term Variation (ITV) is an important HF Radio characteristic that will impact application performance. ITV and measurements of ITV are discussed in "Analysis of OTA Measurements".

MoRaSky emulates ITV based on the Walnut Street Model. We plan to update MoRaSky to use the ITV measurements described in the OTA Measurements paper referenced above.

HF Tool

HF Tool is an Isode test tool that directly operates the Icon 5066 Lua Modem Drivers. The first goal of HF Tool is to enable lab testing of the modem drivers. A typical configuration for this is shown below:

In this configuration one instance of HF Tool is used to drive two HF Modems connected by a channel simulator. HF Tool control of the channel simulator allows a sequence of tests to modify channel conditions. HF Tool will drive test patterns to measure modem/driver performance, error rates and timing. This will exercise the driver and modems in a wide range of conditions which will enable systematic checking of performance and correct operation of modem and driver.

A simpler configuration is used to perform OTA measurements. Typically one instance of HF Tool will send data and the other will receive data and record the results in text log files. These log files can then be processed to analyse system performance. The OTA tests referenced in the previous section were performed using HF Tool in this configuration.

HF Tool is available to Isode partners for OTA measurements and modem driver testing.

Partner Strategy

Icon 5066 will generally be sold as part of a larger solution and so Isode’s primary strategy is to sell through partners of two types.

Modem Vendors

Isode is looking to provide Icon 5066 as an OEM product to HF Modem vendors, so that they can include Icon 5066 as a part of the HF Modem offering for use with any STANAG 5066 application. This will provide all the functional benefits of Icon 5066 and save the modem vendor the costs of developing and maintaining a STANAG 5066 server.

System Integrators

Isode generally sells its Messaging, XMPP and Directory server products through Systems Integrators who provide complete solutions incorporating the Isode server products. For systems operating over HF Radio, Isode will encourage its application partners to include Icon 5066 as a part of the solution and to use this as the integration point with HF Modems.


Icon 5066 follows "STANAG 5066 - Edition 3 PROFILE FOR HF RADIO DATA COMMUNICATIONS" (December 2010). Annexes A-I are the same as Edition 2.

Product Availability

Icon 5066 is being actively developed by Isode. It was shown for the first time at the HFIA meeting in Portsmouth which showed Icon 5066 operation over Narrow Band and Wide Band HF with the long frame sequence number extensions proposed by Isode to enhanced Wide Band performance.

We plan to make a preview of Icon 5066 available to Isode partners in Q1 2018 with first product release no later than Q3 2018. This product is expected to contain all of the capabilities described in this paper, with the exception of the following functionality to be provided in future releases:

  • Annex L (Wireless Token Ring)
  • Dual Site full duplex mode.
  • Modem control over serial line.


STANAG 5066 provides a link layer optimized for HF Radio and is the best way to provide application services over HF Radio. Isode offers STANAG 5066 SIS support in a number of its applications.

Whilst many modem vendors provide their own STANAG 5066 servers, Isode has chosen to develop Icon 5066 in order to provide a number of desirable capabilities, such as multi-platform and wideband HF support, not commonly available.

Icon 5066 has been designed to be modem independent (with drivers written in the Lua scripting language by Isode or Isode partners), easy to configure (via and XML file) and easy to manage (with a web based interface).