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 the series is available here.
1. The Current Acknowledgement Mechanism
APDU acknowledgement is specified in A.3.1.2 of STANAG 5066. This defines an 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 the 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 that is different from 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 reuse. Note that the server will need to correlate the ID to the UPDU in order to provide an 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 that have not been used for a configurable period of time.
3. Backwards Compatibility
This specification is not backward compatible. Use of the Extended Capability EOW specified in S5066-EP7 ensures that this specification will only be used between implementations that support it.
Whitepaper Licensing
Isode whitepapers are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
![]()
Browse Related Whitepapers
Need some more information on this topic?
If you’d like to learn more about the content in this white paper, or any of the products and services that we provide you can fill out our contact form and one of our team will be happy to speak with you.