STANAG 5066 Edition 5 Proposed Additions
STANAG 5066 Ed4 has recently been finalized and is out for ratification. It provides a solid base for HF communication.
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:
- Core Protocol.
- MAC Layer.
- Applications and Layer Services
- SIS Access Protocol
Two possible changes to the core STANAG 5066 functions are noted. The first is recommended, but the second is not.
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:
- The granularity of timing is 0.5 seconds.
- There is no clear anchor for the receiver to measure this time against
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.
The client acknowledgement protocol in STANAG 5066 Annex A is ugly and inefficient. A solution is proposed in Acknowledgement (S5066-EP9).
While this is a simple change, it would be awkward to introduce in a backwards compatible way.
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. Given the level of usage, Isode recommends no change.
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 5066, STANAG 5070, and achieving a single HF Link Protocol.
There are a number of ways in which non-contiguous could be supported. A simple approach, which Isode would recommend, is to define a mapping from STANAG 5066 to STANAG 4539 Annex H. This would require some extension to the STANAG 5066 Data Rate Selection mechanism.
Note that this is different to STANAG 5070, which locks support into the TDD and modem level extensions noted below.
Isode strongly recommends that a mechanism is found to support non-contiguous in STANAG 5066.
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:
- The draft Annex M, which specifies a “long interval” TDMA approach. It was intended for Ed3, but did not get completed.
- Use of the TDD specification from STANAG 5070 draft.
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.
Modem Level Variable Speed and ARQ
STANAG 5070 introduces a modem level ARQ mechanism which includes rate control. It would be possible to include such a mechanism as an Annex to STANAG 5066 or to extend Annex C to specify interface to such a mechanism specified elsewhere.
Isode analysed the best level for data rate control, published in “Optimizing applications and data links for HF radio intermediate term variations: Can you ride the wave?” presented at Nordic HF in August 2016. This looked at how random changes in HF speed are, and concluded that short term variation after about five seconds is completely random. In order to adapt to short term changes to gain performance, you need switch in a second or two and the performance gain is much less than the overhead of switching. This concludes that this sort of mechanism will not improve performance.
Isode therefore recommends against adding this capability.
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:
- Generic PDU and framing mechanism used by all three services.
- 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.
- 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.
- Unreliable Datagram Service.
- 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.
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.
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.
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.
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:
- 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.
- 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.
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.
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.
The SIS access protocol has no security. It is surprising that this has not raised security concerns for those deploying STANAG 5066. Proposed changes:
- Add data confidentiality using TLS.
- Add (STANAG 5066) server authentication with TLS.
- 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.
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.
Delivere 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.
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 Achnowledgement
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:
- 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.
- 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:
- Flow control can lead to high priority data being queued while lower priority data is being transferred.
- 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.
- Bulk applications can squeeze out other applications.
The problems arising from the Ed4 mechanism are expected to become more significant as STANAG 5066 usage becomes broader.
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 2012 in time for the next meeting in early 2023.