STANAG 5066 Ed5 Proposed Additions

Overview

STANAG 5066 Ed4 has recently been finalized and is out for ratification. It provides a solid base for HF communication.

The changes from Ed3 to Ed4 were deliberately constrained to key requirements, particularly to support ALE and WBHF. This white paper proposes a number of additions. All of the proposals are optional and can be added in a straightforward manner. Most of the proposals already have technical specifications written and so a draft Ed5 could be prepared rapidly.

This document is grouped into five sections:

1. Core Protocol.
2. MAC Layer.
3. Crypto
4. Applications and Layer Services
5. SIS Access Protocol

Core Protocol

Two possible changes to the core STANAG 5066 functions are noted.

Reduced Turnaround Time

Turnaround time is critical for HF performance. On a clear link, the overhead due to turnaround time is typically much larger than the protocol overhead. This is why long transmissions are used to optimize bulk throughput. It means that the tradeoff between reasonable latency and throughput is difficult. Limiting transmissions to less than 30 seconds will in most cases significantly reduce throughput.
The minimum possible turnaround is of order 150-200 milliseconds, constrained by waveform synchronization preamble and physical switching times. Details provided in the Isode white paper Turnaround Times in STANAG 5066.
STANAG 5066 does not allow anything close to this to be achieved. There are two problems:

1. The granularity of timing is 0.5 seconds.
2. There is no clear anchor for the receiver to measure this time against

This makes it hard to reduce turnaround.

A solution to this is proposed in Block Based EOTS (S5066-EP8). This works without change to STANAG 5066 protocol, but changes the EOT (End of Transmission) semantics to reference the end of the last modem block by a count. This enables precise timing, and would be introduced as an option in Annex C. All nodes would need to agree a priority to use it (as they do for other parameters such as ALE version and waveform).
Isode strongly recommends this enhancement, as the performance benefits are significant.

Client Acknowledgement

The client acknowledgement protocol in STANAG 5066 Annex A is ugly and inefficient. A solution is proposed in Acknowledgement (S5066-EP9). An alternative approach of returning a hash is used in the STANAG 5070 draft. While less elegant, this approach can be added in a fully backwards compatible manner.

The use of this capability is quite limited in standard applications. SLEP (described later) uses it in some error situations, but in a manner that is not particularly inefficient with the current protocol. Some ACP 127 deployments are believed to use it, but it is not standardized. Isode views that this change would be important if client acknowledgement were widely used. Isode recommends on balance to make this change using the has mechanism. It is a straightforwrd and safe change that may help future protocols using client acknowledgements.

MAC Layer

Support for Non-Contiguous Wideband

A decision needs to be taken on approach to support of non-contiguous wideband. Isode views that this should be done within STANAG 5066 and not in the proposed STANAG 5070 draft. Rationale for this view is set out in Isode white paper STANAG 5066, STANAG 5070, and achieving a single HF Link Protocol.

Isode strongly recommends that a mechanism is found to support non-contiguous in STANAG 5066.

Core Requirements

Non-contiguous is specified in STANAG 4539 Annex H. In order to integrate this with STANAG 5066 two things are required.

1. A mechanism to send and receive data over STANAG 4539 Annex H channels.
2. A specification of using ALE amd ALM for non-contiguous.

How to Achieve Integration

STANAG 5070 Draft Annex A provides mechanisms to drive STANAG 4539 Annex H including ALE and ALM. There are two ways that it could be used with STANAG 5066:

• Incorporating STANAG 5070 Draft Annex A as an Annex to STANAG 5066
• Referencing STANAG 5070 Draft Annex A as an external specification.

There would need to be a STANAG 5066 Annex to sepcify how to drive this. This can make use of material in STANG 5070 Draft 0.6 Annex D.

Possible Improvements

Embedding the Time Division Duplex MAC layer in STANAG 5070 Annex A means that there is no choice of MAC layer to use with non-contiguous. This leads to two problems:

1. There is no current mechanism for reliable multi-node communication that can be achieved with CSMA (STANAG 5066 Annex K) or WTRP (STANAG 5066 Annex L). It seems unfortunate to constrain non-contiguous deployment in this way.
2. TDD leads to poor bulk transfer performance. Even where physical switching is fast, the waveform synchronization preamble introduces a significant overhead for short transmission TDD. For bulk transfer, the forward channel is fully utilized, but there is a 50% wastage on the reverse channel that is not carrying bulk traffic.

It would make sense to address this as part of non-contiguous support in STANAG 5066.

TDD/TDMA

Use of TDMA (Time Division Multiple Access) and TDD (Time Division Duplex) have been discussed as possible new MAC options. There are two candidates for this:

1. The draft Annex M, which specifies a “long interval” TDMA approach. It was intended for Ed3, but did not get completed.
2. Use of the TDD specification from STANAG 5070 draft.

A TDD and/or TDMA MAC layer would fit cleanly into STANAG 5066.

STANAG 5066 provides CSMA and WTRP MAC mechanisms. Isode believes that these are good options and there is no reason to introduce another option. This technical view is nicely presented in “IMPACT OF TURNAROUND TIME ON WIRELESS MAC PROTOCOLS” -Eric E. Johnson, Manikanden Balakrishna, and Zibin Tang’ which compares TDMA, CSMA and WTRP. It concludes that CSMA is best for lightly loaded networks and WTRP is best for heavily loaded networks.
Operationally, adding choices increases deployment choice and complexity.
Isode therefore recommends against adding a new MAC layer.

Crypto

IP Crypto

Many nations are choosing to use IP Crypto to provide COMSEC. The pros and cons of doing this are discussed in the Isode white paper Using IP Crypto over HF. This also references detailed protocol specifications and sets out performance measurements of Isode pre-release products that support these specifications.

While use of IP Crypto is not a technically optimal approach, this addition may be desirable.

AES Key Management

STANAG 5066 Annex T and Half Loop ALE Linking Protection makes use of AES keys. It will be important to manage these in a distributed environment. Key Distribution for TRANSEC and Half Loop (S5066-EP15) proposed a mechanism to achieve this.

Applications and Layer Services

All of the following protocols operate over STANAG 5066 and could be easily added as new annexes.

Streaming Layer & SLEP

Many modern applications are built over a streaming service, in particular TCP, and this is a critical gap in the STANAG 5066 suite. SIS Layer Extension Protocol (SLEP) (S5066-APP3) provides this and two other services. Key Elements:

1. Generic PDU and framing mechanism used by all three services.
2. Extended addressing. This provides one part of a solution to overcome the 16 address limit for STANAG 5066 SAPs. This is done so that there is no overhead when extended addressing is not used.
3. Reliable Datagram Service. This addresses many deficiencies of the older RCOP specification. Isode had implemented this for MULE messaging in M-Switch with performance results in Isode white paper Measuring Performance of Messaging Protocols for HF Radio.
4. Unreliable Datagram Service.
5. Streaming Service. This was a key target and has been used in three Isode applications: HF-PEP and File Transfer described below and XMPP (XEP-0365). We believe that this is a strong validation of the approach.

Isode sees this as an important building block to add to STANAG 5066.

HF PEP for TCP

Support of IP Services is important. TCP and HTTP services are central, and these work poorly over IP Client (Annex U). A TCP PEP is important. HF-PEP: STANAG 5066 TCP Performance Enhancing Proxy Protocol (S5066-APP9) is designed to provide this function based on SLEP streaming service. This is Isode’s recommended solution.

This approach works well with performance numbers documented in the Isode white paper Measuring and Analysing HF-PEP for TCP communication and Web Browsing over HF. This shows good link utilization (over 90% in some situations) and excellent adaptation.

There have been other PEP specifications operating over IP Client. These will be much lower performance and will be impacted more severely by HF variance.

Performance Measurement and Testing

Testing STANAG 5066 with “real applications” is often problematic. It is useful to have specialized tools that can provide a variety of load and measurement. This would be desirable to achieve between vendors. HF Discovery, Ping and Traffic Load (S5066-APP2) specifies a simple protocol that can be used for latency and throughput testing with ability to control testing from one end. It also includes a basic node discovery mechanism. This is a straightforward addition that will facilitate distributed and multi-vendor testing.

File Transfer

Although dedicated file transfer is used much less than it used to be, Isode sees ongoing requests for file transfer. HF File Transfer Protocol (HFFTP) (S5066-APP8) specifies an efficient file transfer protocol using the SLEP streaming service. This would be a straightforward way to add a useful capability.

Location Services

It is operationally useful to know the location of Mobile Units. It is desirable to share this information with a red side protocol that can co-exist with applications running over STANAG 5066. HF Location & Information Sharing Protocol – HF-LISP (S5066-APP10) provides a simple mechanism modelled on the maritime Automatic Identification System (AIS).

This can support mobility management, such as that provided by Isode’s Icon-Topo product and optimal frequency selection based on mobile Unit location.

HF Broadcast

NATO BRASS is a HF broadcast service supporting ACP 127 messaging. Isode believes that there is a requirement for a more general capability.

Why ACP 127 Needs to be Replaced

ACP 127 is an ancient technology based on teletypes. NATO have dropped plans to replace it and there is a general high level view that “it does the job, so why replace it”. This complacent view is ignoring two real problems:

1. ACP 127 in practice means a number of standards (ACP 126; ACP 127G; ACP 128; JANAP 128; DOI 301S and others) plus national variants. It is an interoperability and vendor nightmare.
2. A reliable service comes at the cost of high level of operator cover, including a significant percentage needing detailed ACP 127 skills.

A modern protocol can give clean interoperability and most operation can be automatic with much reduced operator costs. In addition, features such as extended character sets with lowercase letters, attachments and delivery reports become available.

Most ACP 127 capabilities can already be provided with modern protocols, but there is no replacement for BRASS.

Why ACP 142 multicast does not suffice

ACP 142 provides a multicast protocol that can be used with HF for STANAG 4406 and SMTP messaging. This is an important and useful service that has some similarities to broadcast. It will be particularly useful for supporting a set of peers using a single HF channel, such as a naval task group running a shared channel with WTRP. It is a symmetrical protocol, with an Ack sent for every message.

BRASS type broadcasts are highly asymmetric, with powerful shore transmitters sending out broadcasts on multiple frequencies. Messages can be reliably received without any Ack. Ship to shore channels are used to request repeat transmissions where needed. This cleanly supports EMCON operation.

HFBP

Broadcast Protocol (HFBP) (S5066-APP11) specifies a generic broadcast protocol based on STANAG 5066 non-ARQ. It specifies use with SMTP, STANAG 4406 and XMPP. It supports efficient broadcast, with recap messages and capability to request retransmission of full messages or message fragments. It provides additional support for EMCON, where retransmission cannot be requested, using the Non-ARQ with Errors STANAG 5066 service. This capability fills a significant gap in the STANAG 5066 protocol suite.

SIS Access Protocol

A number of extensions to the SIS Access Protocol (Annex S) are proposed. Isode had drafted detailed specifications for all of these, but they have not been widely shared.

Interoperability Requirements

SIS Access Protocol is “local only” so all of these changes (apart from extended addressing) do not have end to end implications. They can be used as a deployment choice.

The SIS Access Protocol allows applications from different vendors to connect to a common STANAG 5066 service and so it is important to consider support for applications developed to the Ed4 SIS specification.

SIS Security

The SIS access protocol has no security. It is surprising that this has not raised security concerns for those deploying STANAG 5066. Proposed changes:

1. Add data confidentiality using TLS.
2. Add (STANAG 5066) server authentication with TLS.
3. Add optional client strong authentication, so that server can control which client accesses which SAP.

Although new, it is seen as likely that some deployments will mandate this as soon as it is available.

SIS Extension Framework

It is proposed to extend the current SIS Protocol with a framework to allow extensions. Isode has written (but not shared) technical specifications of this framework and all of the extensions proposed. We believe that everything proposed is straightforward and viable.
The framework would allow a SIS client to ask a server which extensions are available for use and negotiate which ones are used. It would also allow a client to detect an Ed4 server and fall back to not using any extensions.
The framework allows a server to work with Ed4 SIS clients and with SIS clients using extensions.
This is seen as an approach which has excellent backwards compatibility.

Extended Addressing

STANAG 5066 has 16 SAPs. This limits the number of protocols that can be used. Operational experience suggests that the limit is going to be tight and may well lead to problems as new applications are added.

SLEP, RCOP and UDOP define extended addressing, but do not specify all that is needed. This extension gives the “missing piece” which enables an application to listen on an extended address. The server will need to be aware of the protocol and correctly de-multiplex the extended addressing which technically are in the application protocol.

Delivered Data Confirmation

STANAG 5066 Client confirmation is sent when data is written to the SIS Access Protocol stream. This gives a reliability issue, as the data may not actually reach the application. This adds simple additional protocol so that client confirmation can confirm that data has reached the peer application. This is arguably a protocol bug fix.

QoS

This extension allows a SIS Client to indicated the Quality of Service desired for data, which can be for the whole stream or for specific data. This might be “low latency” or “bulk”, which will help the STANAG 5066 server make appropriate choices. For a bulk protocol, acknowledgement data might be given a different QoS. The detailed proposal suggests three ARQ QoS settings and four Non-ARQ settings.
This seems a desirable extension to enable a STANAG 5066 server to better tune performance for different types of application.

Extended Data Acknowledgement

STANAG 5066 has two types of acknowledgement (node and client). SIS access protocol only allows one of these to be requested, even though it would be straightforward to provide both.
There is a third type of acknowledgement of when data is sent OTA. There is an undocumented convention followed by multiple 5066 vendors that if node ack is requested for non-ARQ then this is what you do.
This extension allows a SIS client to request any combination of the three types of ack.
This can be very useful, for example application monitoring to show both when data is sent and when it is acknowledged.

Link Status Information

SIS access protocol sends data, and then only hears confirm or reject. This extension provides information on links being used to give better application control. Two examples as to how this could be very useful:

1. Where an application needs a faster link to be useful, it could use link speed information to determine that in current conditions that it should not even attempt to transfer data.
2. When monitoring a queue of applications messages, knowing speed and load will enable better reporting to the end user and better estimates of when messages will be delivered.

Improved Flow Control

The current on/off flow control mechanism is very simplistic and in complex multi-destination and multi-protocol situations does not allow sufficient control. Examples of problems:

1. Flow control can lead to high priority data being queued while lower priority data is being transferred.
2. When switching ALE links, a small amount of data for the open link could be flow controlled and it would be optimal to send it.
3. Bulk applications can squeeze out other applications.

A more sophisticated mechanism can address this. It can also, in conjunction with QoS, give control between applications, in the manner that it is envisioned that Rank in Ed3 was intended to function (but did not).
The problems arising from the Ed4 mechanism are expected to become more significant as STANAG 5066 usage becomes broader.

Queue Monitoring and Deletion

STANAG 5066 servers will generally try to keep queues short, but will need to keep at least two minutes of data for the current speed. In the the event of link speed dropping, it is possible for queues to build up that can be orders of magnitude longer. It is desirable to manage this situation.
This can be done with three new functions:

1. Monitor queue size, showing volume of un-transmitted and un-acknowledged data.
2. Purge queue for SAP. This can be useful to clear the queue when an application is exiting due to timeout or starting on a SAP. It can also be used by an operator.
3. Specific C_PDU no longer required. If still queued, the STANAG 5066 server can remove. This might be used by a messaging application to handle data from a message that is being removed at message application level.

Next Steps

This list of suggestions and suggestions from others needs to be reviewed by NATO BLOS Comms group. It is suggested to do this at the Summer meeting in Stockholm. This group needs to agree a target list of requirements for Ed5.

The changes for Ed4 in Annexes A/B/C needed a high level of consensus, as they led to changes which every STANAG 5066 system would support. The changes proposed here are all options, for implementation only by those parties interested in the additional functionality. It is anticipated that agreement here can be much easier.

These could be provided as a complete draft for review by end of 2022 in time for the next meeting in early 2023.