HF Wireless Token Ring Protocol (S5066-EP12)

This document sets out a protocol which is a complete replacement for STANAG 5066 Ed3 Annex L.

The core of this document is a modified version of Annex L, which corrects a number of issues with the specification as published in STANAG 5066 Ed3, which can be used directly as Annex L for STANAG 5066 Ed4. This specification also provides a number of functionality and performance enhancements.

This enables performance improvements. The complete set of documents in this series are:

  1. STANAG 5066 Extension Protocol Index (S5066-EP1)
  2. STANAG 5066 Padding DPDU (S5066-EP2)
  3. Pipelining the CAS 1 Linking Protocol (S5066-EP3)
  4. Data Rate Selection in STANAG 5066 for Autobaud Waveforms (S5066-EP4)
  5. STANAG 5066 Large Windows Support (S5066-EP5)
  6. Slotted Option for STANAG 5066 Annex K (S5066-EP6)
  7. Advertising Extended Capabilities (S5066-EP7)
  8. Block Based EOTs (S5066-EP8)
  9. Compact Acknowledgement (S5066-EP9)
  10. Extension DPDU (S5066-EP10)
  11. Variable C_PDU Segment Size (S5066-EP11)
  12. HF Wireless Token Ring Protocol (S5066-EP12)
  13. STANAG 5066 Routing Sublayer (S5066-EP13)
  14. STANAG 5066 TRANSEC Crypto Layer using AES and other Protocols (S5066-EP14)
  15. AES Key Distribution for TRANSEC and Half Loop (S5066-EP15)
Creative Commons License
Isode whitepapers are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

1. Why an Update

The initial approach taken was to record an errata and set of clarifications to STANAG 5066 Ed3 Annex L. It became clear that there were too many errors for this approach to be manageable. Interoperability seems unlikely to be achievable for any but the simplest deployments. Specific issues noted:

  • Many minor errors.
  • Some aspects of the protocol cannot work and need to be changed.
  • The original Ergen protocol worked in a different environment. Annex L adapted this for HF, but did not work through all of the details. This has led to an awkward mish-mash.
  • The protocol attempts to shoe-horn the PDUs into Management D_PDU. This is a mess and violates some basic STANAG 5066 extensibility principles.

As well as addressing these issues, the specification addresses some additional requirements. Some of these are seen as critical requirements, which it is not possible to address with the STANAG 5066 Ed3 Annex L specification.

  • Supporting indirect communication. Annex L supports communication of indirect structures, but does not provide a mechanism or framework to use it. This specification provides a framework to address this problem, which is then addressed by [STANAG 5066 Routing Sublayer (S5066-EP13)].
  • Smaller PDUs and not transmitting PDUs in stable networks. The Annex L PDUs are considerably larger than necessary. Although PDUs are acceptable size for anticipated target speeds, there are clear benefits in reducing size:
    • For HF, reducing size is always good.
    • Small PDUs are less likely to hit errors, so reliability (and in particular avoiding token loss) is improved.
    • Small PDUs can be transmitted multiple times to improve reliability.
  • Sharing link quality information. This enables:
    • Better decisions on optimum topology, as best links can be used.
    • Variable speed. Surface wave deployments are a key target and SNR will reduce with distance. Adapting speed is highly desirable.

2. Overview of Differences with Ed3 Annex L

This details of this specification are similar to the one in Ed3. The goals and high level model are unchanged. The core state machine is almost identical. One key change is that there is no Relay state. Ed3 follows Ergen (which uses the term hidden node). This is sensible for Ergen, where predictable latency is key. In Ed3 Relay State, only the token is transmitted (no user data). In this specification, user data may transmitted whenever the token is held. Where a token is held multiple times by one node in a circuit, it is likely to be relaying data. Transmitting data each time is expected to improve performance.

The protocol in this specification is simpler and significantly different to Ed3. The Token is transferred using a single standard EOW. This enables the token to be included many times in a transfer, which will reduce overhead and improve resilience.

Information on TOL, connectivity and link quality is transferred in special PDUs. These are only used when connectivity changes, so there is no overhead in a stable ring.

We've published the modified version of Annex L as a PDF.