STANAG 5066 Update Plan

The contents of this whitepaper have been superceeded by the updates made in STANAG 5066 Edition 4, which can be viewed here. This paper is being kept live for prosperity and so that the clear pathway to changes can be seen.

Link Level Focus

This document looks only at STANAG 5066 as a link level protocol and does not cover the applications and services set out in Annex F. This document does not consider IP support.

Isode recommends that NATO produce an update to STANAG 5066 that focusses only on HF link level. Applications, IP support and interfaces should be specified in separate STANAGs.

Future Role of STANAG 5066 in HF

There is a requirement for a link level service to operate over the standard HF modem protocols, to provide services such as ARQ, segmentation, data checksum, segmentation and application multiplexing. STANAG 5066 is the only open standard that addresses this in a reasonable manner to provide appropriate flexibility.

It would be possible to specify a new protocol to do this. Isode strongly recommends against this option.

STANAG 5066 is broadly satisfactory. A number of changes are needed, which are set out in this document. These can be addressed in a straightforward incremental manner to provide an HF link layer service that can be used long term.

Changes with Interoperability Impact

This document starts with a set of explicit proposals for incremental changes that have been set out in the STANAG 5066 Extension Protocol (S5066-EP) series. These proposals modify the protocol exchanged between STANAG 5066 servers. These have been designed so that they can be introduced incrementally.

Large Window Support

STANAG 5066 has a maximum window size of 128. This limits ARQ performance at the higher speeds of narrow band HF and leads to unacceptable performance for WBHF/HFXL. The paper [STANAG 5066 Large Window Support] addresses this.

Data Rate Selection

Current Data Rate Change (DRC) process in STANAG 5066 has a number of deficiencies:

• It does not usefully handle WBHF waverforms.
• It does not work for Duplex.
• It does not properly address autobaud waveforms
• It is complex
• The “start at 300bps” is problematic
• It does not work for non-ARQ multicast protocols such as ACP 142
• It does not allow for modern sender control techniques described in in the Isode whitepaper [Optimizing STANAG 5066 Parameter Settings for HF & WBHF].

These are addressed by the paper [Data Rate Selection in STANAG 5066 for Autobaud Waveforms]. Isode strongly recommends adoption of this specification and also complete removal of the current DRC mechanism, which is complex and not useful now that autobaud waveforms are generally available.

CAS-1 Pipelining

The paper [Pipelining the CAS 1 Linking Protocol] defines a mechanism to reduce hand-shaking for ARQ data. This is important for many modern protocols which transfer small amounts of data.

Padding DPDU

The paper [STANAG 5066 Padding DPDU] adds a simple padding DPDU, which improves performance and resilience by enabling exchange of additional EOTs and EOWs.

Annex K (CSMA) Slotting and Clarification

The paper [Slotted Option for STANAG 5066 Annex K] defines an approach which improves performance and resilience for small CSMA networks. It also clarifies use of single and multiple CAS-1 links, which will address interoperability issues with Annex K implementations that do not follow this specification.

ALE

ALE is important to use with STANAG 5066. Although this does not impact protocol, it seems important that the approaches used are clearly specified and STANAG 5066 should be updated to properly address this with reference to the NATO ALE standards.   This is straightforward specification work.

The issues around this are covered in Isode HFIA Presentation “USING ALE WITH STANAG 5066” (February 2017).   Four specific ALE models are noted.

Implicit ALE

For a two node network, use of ALE can be transparent to the S5066 server; ALE is handled by the modem layer on request to transmit.

Explicit ALE

This supports a common scenario of multiple nodes sharing a set of frequencies. STANAG 5066 Server will need to request establishing ALE link prior to CAS-1 (with ALE Station derived from STANAG 5066 Node Address), and operate one CAS-1 link at a time.

Multi-Point ALE

ALE can be used to establish multi-node networks. This means that ALE can be used with Annex L (WRTP) and Annex K (CSMA) networks. Use of ALE enables such networks to adapt to conditions and select best frequency.

Sharing limited Modem Pool

When a system (e.g., a shore station) has access to multiple modems but there are more peers (e.g., mobile units) than modems there is a need to share modems between the operational units. A solution to this is described in the HFIA presentation.

Interfaces

STANAG 5066 defines a number of interfaces between components. These interfaces do not impact end to end interoperability, and so vendors can progress these areas without standardization. However, some interfaces would benefit from standardization.

SIS Replacement

SIS (Subnet Interface Service) is the STANAG 5066 protocol between applications using STANAG 5066 and a STANAG 5066 server. While it provides a viable basic service,  it has some critical deficiencies:

• Lack of security.   There is no data confidentiality or authentication.
• Simplistic flow control prevents optimal traffic scheduling in complex scenarios (multiple applications; multiple priorities; multiple destinations).
• Status reporting is inadequate, particular for monitored bulk applications such as messaging.

Isode plans to develop a new protocol to address these issues and will publish as an S5066-EP that can be used by NATO.

Unidata Confirm

When Unidata is received, it is transferred to the application with a Unidata Indication. There is no Unidata Confirm back from application to STANAG 5066. This is a minor design error that needs to be corrected and can lead to unreliability in certain situations.

Issue and solution described in “XEP-0365 (XMPP Extension Protocol) Server to Server communication over STANAG 5066 ARQ” (presentation to BLOS Comms, September 2015). This change impacts the service interface, but does not change server to server protocol.

Annex E Removal

Annex E defines a simplistic serial line modem control protocol. This is not useful for anyone. Ideally a modern TCP based control protocol would be standardized. This would need to be agreed between modem vendors. The practical situation is that this control is going to be vendor proprietary.

Annex D Updates

Annex D defines the Synchronous Serial interface between STANAG 5066 and Modem or Crypto.

Synchronous Serial Clarifications

Annex D is specified as if this was a byte-aligned interface. Raw synchronous serial interfaces used for these applications are bit-aligned.

Bit alignment can be supported using the Maury-Styles header (known in the industry as “90EB” reflecting data on the wire). This critical information  is not documented in STANAG 5066 and it should be.

TCP Modem Interface

An option for TCP interface to a modem should be added. Such an interface is specified in MIL-STD-188-110C Appendix A. This interface should be a part of STANAG 5066. This will be particularly useful if the crypto layer is moved upwards.

TCP Crypto Interface

MIL-STD-188-110C Appendix A is designed for modem support and is not suitable for STANAG 5066 communication to a Crypto box. As communication to a Crypto box is the standard configuration a standard TCP protocol to achieve this would be highly desirable. To be useful, this protocol would need to be supported by Crypto vendors. MIL-STD-188-110C Appendix A might be used as the basis for such a protocol.

Anticipated Annex L Updates

Annex L (Wireless Token Ring) is an interesting new part of STANAG 5066 Ed3. Deployment experience with this is limited. The STANAG 5066 update should seek experience with Annex L deployment, and plan to update Annex L in light of this experience. Two possible change areas are:

1. Annex L is fixed speed.  This is an odd constraint, and it seems likely to be desirable to extend Annex L to use variable speed so that transmission rates can adapt to conditions and load.
2. Reports suggest that recovery times from “ring failure” are too long, and that it would be desirable to look at approaches to improve ring recovery time.

It seems likely that there will be additional things to address, and the PoW should allow for updates.

Tidy Up

STANAG 5066 has grown around a core designed for 1200 bps support: the core has been tweaked and a series of annexes added. The result is now difficult for the inexperienced to understand. The document needs a major tidy up and restructure to reflect current and evolving use and goals. Removal of elements no longer needed will clean the specification and facilitate adoption and interoperability. The rest of this section summarizes changes needed.

Annex A Restructure

Annex A defines a number of things:

1. The STANAG 5066 Service
2. The flow control and encoding of the SIS protocol (A PDU forma). TCP mapping is defined in Annex F.
3. Use of the CAS sub-layer (Channel Access).
4. Encoding of the B PDUs that are passed to CAS and share some encoding with the A PDUs.

This inter-relationship is quite confusing and restructure would facilitate understanding of STANAG 5066.

Dropping Hard Links

The concept of hard links was introduced in “Clark, D., and N. Karavassillis, Open Systems for Radio Communications: A Subnet Architecture for Data Transmission over HF Radio, TM-937, May 1998”, which is the NATO report that was the basis for STANAG 5066. The concept was to allow easy switching between data and voice, which could have been useful. In practice this gets handled by modem level switching.

Hard links in STANAG 5066 are a complex part of the service interface and the details are bizarre. They do not seem useful and we do not believe they are ever used. Recommend to remove hard links from STANAG 5066.

Extend Waveform Support

STANAG 5066 is specified around 1200 bps waveforms. This needs updating to reflect the modern waveform family, in particular STANAG 5069 (WBHF).

Annex G Fold into Core

Annex G specifies use of 2400 bps and faster waveforms. This material should be in the core and not as an Annex.

Annex H Update or Removal

Annex H contains implementation guidelines and notes. Some of this material is interesting, but relates to 1200 bps deployment and below. Ideally this information needs updating to provide modern guidelines.

Annex J, K and L relationship to core

The media access model set out in Annex J belongs in the core. It does not really make sense to operate without either Annex K or Annex L (or future new media access mechanisms) and this needs to be set out more clearly.

Annex I Removal

Annex I does not appear useful or used. It should be removed.

Duplex Clarification

The core STANAG 5066 text is focused on simplex operation. STANAG 5066 supports duplex operation, but this needs clarification. Notes provided by Nigel Arthurs of Selex are a good basis for this clarification.