Date: 16 January 2017 / Version: 1.0 / Status: Implemented

This document introduces a new STANAG 5066 DPDU to pad transmissions, which enables enhanced performance with no overhead. This document is part of the STANAG 5066 Extension Protocol (S5066-EP) series. The complete set of documents in the 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)
Creative Commons License

1. Why Repeating DPDUs as Padding is Beneficial

STANAG 5066 Annex C sends out data as stream of DPDUs. Modern HF Waveforms send data in blocks, which means that the volume of data sent needs to be an exact number of block sizes. There is generally some extra space for one of two reasons:

  1. There is insufficient space to fit in the next DPDU (typically a data DPDU which might typically by 2-300 bytes); or
  2. Only a small amount of data is being sent, and there is space.

Annex C allows DPDUs to be repeated, and this is often a good way to fill the space. Reasons that it is preferable to use DPDUs (rather than just pad with non-DPDU data):

  1. If you repeat a DPDU, risk of data loss is reduced as the original may be corrupted.
  2. An EOW (Engineering Order Wire) single byte message can be sent with each DPDU for control purposes such as data rate change.  Extra DPDUs allow for more EOWs to be sent which allows for more information to be sent and reduces the risk of (important) EOW information from being lost.
  3. The EOT (End of Transmission) is a single byte sent with each DPDU to indicate time of transmission remaining.   This allows the receiver to determine the length of a transmission, which will enable it to know when the transmission is complete and when it can start transmission. This is very important for resilient operation.  Transmitting more EOTs reduces the risk of all EOT information getting lost.  

EOT and EOW repeats are particularly important at slower speeds when only a small number of DPDUs will be sent in each transmission.

It will generally make sense to repeat critical data.  ACKs are particularly useful to repeat and are small.  It can also make sense to repeat high priority DPDUs, giving priority to SAPs with low latency QoS requirements. Note that when a physical link has been established (CAS-1 for ARQ traffic) that ACKs can be used in both directions and this is recommended.

2. Why a Padding DPDU is Useful

It is often possible to repeat user data, particularly ACKs, which is useful. However, there are situations where it is not possible to do this. In particular:

  1. Where there is no physical link set up and non-ARQ data only is being sent. In this scenario it is not appropriate to send an ack.
  2. Where ACKs are large and so do not fit. As window opens up, the size of ACK PDUs increases. This problem increases when the Long Frame Sequence Number (LFSN) extension (S5066-EP5) is used.

In these situations, it is still highly desirable to repeat EOW and EOT information, as described above. This is enabled by use of a new Padding DPDU, which is a small DPDU specifically for padding transmission space.

The second scenario seems important, because if there is a one way data flow, the block size for returning ACKs is likely to be kept small. Where only one ACK will fit in the block, the Padding DPDU will be particularly useful.

3. Padding DPDU Specification

The Padding DPDU follows the syntax set out in C.3.1 of STANAG 5066 using C frame as illustrated in Figure C-2(a).  Parameters are set as follows:

  1. D_PDU type set to 14.
  2. EOW carries data as provided by the STANAG 5066 server.
  3. EOT set according to protocol.
  4. Size of address field is variable, reflecting length of source and destination address (maximum 7) if included and 0 if it is not.
  5. Size of header is set to 6
  6. Source and Destination Address, following the variable length encoding of C.3.2.6.  This field may be needed to correctly determine applicability of EOWs, and so should be set if it is needed.
  7. Header CRC set according to protocol.

4. Backwards Compatibility

The Padding DPDU uses standard DPDU framing. If received by an implementation that is not aware of type 14, and error will be returned by a complaint implementation. If an implementation following this specification receives such and error it must note that the peer does not support this specification and cease sending padding DPDUs to it.