Compact Acknowledgement (S5066-EP9)

This document specifies a mechanism for client acknowledgement of STANAG 5066 APDUs that improves efficiency and reliability of the current mechanism. This document is part of the STANAG 5066 Extension Protocol (S5066-EP) series. 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. The Current Acknowledgement Mechanism

APDU acknowledgement is specified in A.3.1.2 of STANAG 5066. This defines a S_PDU “Data Delivery Confirm” with type 1. This references the original PDU by encoding all or part of the original PDU.

This approach to referencing PDUs is also used in SIS and is sub-optimal. Using just a part of the PDU increases the possibility of an ambiguous reference. The full PDU may be ambiguous if the same data is sent twice.

Implementations have generally chosen to use the full PDU. This is not a significant issue for SIS, which will generally operate over a fast link. However, it leads to an undesirable and potentially significant overhead OTA.

2. Compact Acknowledgement

This specification defines an efficient acknowledgement mechanism, by using two new S_PDUs.

The first S_PDU is a new "Data with ID" S_PDU. This adds a four byte ID to the standard Data S_PDU. This S_PDU is of type 8, and is a modification of the Data S_PDU encoding, inserting the four bytes after TTD and before U_DATA.

The approach is to use a new "Compact Data Delivery Confirm" S_PDU, which uses a syntax based on "Data Delivery Confirm" and type is set to 9. This new S_PDU has a four byte ID field, replacing the U_PDU in Data Delivery Confirm.

When sending Data that requires client confirmation the server shall use the "Data with ID" S_PDU and shall not use the "Data" S_PDU. The ID shall be set to a value which is different to that of any pending acknowledgements. In other cases the "Data" S_PDU shall be used.

When confirming a "Data with ID" S_PDU, the "Compact Data Delivery Confirm" shall be used and the ID set to the value of the ID in the S_PDU being acknowledged.

When a server receives a "Compact Data Delivery Confirm" the procedure is broadly as for receipt of "Data Delivery Confirm". The ID shall be matched to the outgoing ID and the ID can be freed for re-use. Note that the server will need to correlate the ID to the UPDU, in order to provide a SIS confirmation to the client.

In the event of an anticipated "Compact Data Delivery Confirm" not being received, the server shall not retransmit the data. The server shall invalidate IDs which have not been used for a configurable period of time.

3. Backwards Compatibility

This specification is not backwards compatible. Use of the Extended Capability EOW specified in S5066-EP7 ensures that this specification will only be used between implementations that support it.