This document clarifies optional and mandatory use of CAS 1 Linking Protocol, to improve STANAG 5066 performance, particularly for transfer of small amounts of data. 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)

1. CAS-1 and Overhead

The STANAG 5066 Channel Access Sublayer defines a mechanism to establish a physical link between a pair of nodes, call the "CAS 1 Linking Protocol", referenced in this document as CAS‑1.

CAS-1 uses a handshake of short C PDUs to establish a physical link, and a similar handshake to break a link. CAS-1 is used between a pair of node exchanging ARQ data.

CAS-1 has a significant overhead when transferring small amounts of data. Consider an application that needs to transfer one byte of data. There is a handshake to establish the physical link, a handshake to transfer the data and a handshake to break the link. If a 1 second block size is used each transfer will take two seconds if lead-in time is also 1 second. If switching time is 0.5 seconds, it will take 14.5 seconds to transfer the data. If the data was simply exchanged and acknowledged it would take only 4.5 seconds. For an interactive protocol such as XMPP real time messaging, the overhead of CAS1 is significant.

The specification provides a mechanism to reduce this overhead.

2. Reasons for CAS-1

CAS-1 addresses three issues:

  1. The scenario where CAS-1 initial handshake is useful is where there is a multi-node HF network being used for bulk transfer and there is a significant probability that link setup will fail (either because the link does not propagate or because of issues at the responder end, such as responder not listening). In this scenario, doing a small CAS-1 handshake before exchanging bulk data is very sensible. The CAS-1 setup will only take a short time and will prevent wasteful attempts to transfer of data to a node that cannot be reached.
  2. CAS-1 causes initialization of the ARQ protocol, as set out in C.6.3.1. This is an essential function, as ARQ state cannot in general be reliably known.
  3. In a CSMA (Annex K) network, CAS-1 Link Break can be observed by other nodes, and this will signal that they can start to transmit.

3. CAS-1 Mandatory

CAS-1 is optional in the current specification, set out in B.3 section 1a. This notes that "It is strongly recommended to use the CAS 1 linking protocol if three or more active nodes are on the same frequency."

ARQ initialization is important in all scenarios. Therefore systems following this S5066-EP3 specification shall always use CAS-1.

4. CAS-1 Pipelining

The key change in this specification is that the requirement for handshaking is removed. The same PDUs are exchanged. The details are set out below.

This change will allow a small amount of data to be reliably exchanged with a single handshake using two Transmissions:


Essentially the same data is exchanged, but there is only one handshake. The approaches for link establishment and link break pipelining are different and one or both may be supported.  

4.1 Communicating Pipelining Capability

The C_PDU structure is extended by this specification to include information on pipelining capability. The standard encoding of physical link request and physical link confirm C_PDUs is shown below:

Not Used

This specification defines the use of the bits as follows:


Bit 1 is used for LFSN capability, as specified in S5066-EP5.
Bit 2 is used to specify pipelining capability.  If set to 1, this specification is supported,
Bit 3 is reserved for future use and must be set to 0.

While this information cannot be used to negotiate pipelining capability prior to its use, it enables a node to explicitly determine if a peer supports pipelining.

If a sender is not aware of peer support for CAS-1 pipelining, it is recommended to use standard CAS-1 first and use the information in bits 2 and 3 to determine peer capability.

A sender may use CAS-1 pipelining speculatively.  If it receives a WARNING D_PDU, it shall fall back to using standard CAS-1.

5. Pipelining Link Setup

5.1 Benefits of Pipelined Link Setup

Use of pipelined link setup eliminates a handshake. This enables user data to be sent with lower latency. It also reduces the time that the communication channel is used, thus enabling the channel to be used sooner for other purposes and thus increasing channel utilization.

5.2 Setup Mechanism

The C_PDUs for handling physical link setup and break are sent as expedited data. Expedited data must be sent ahead of normal data, but expedited and normal data may be sent together in a single transmission. This use of expedited data does not prevent pipelined operation.

The requirement to use a separate handshake for physical link setup comes from A. "Protocol for Establishing a Soft Link Data Exchange Session". The key text is "After the physical link is made, both peer Subnetwork Interface Sublayers shall (3) declare that the Soft Link Data Exchange Session has been established between the respective source and destination nodes. Data may then be exchanged in accordance with the protocols specified in Section A.3.2.4."

This specification relaxes this constraint, and allows data to be sent as soon as the soft link has been requested, which will enable the data transfer layer to send data in the same transmission as the physical link request.  

The standard does not explicitly require that link break is done with a separate handshake, although this does appear to be de facto implementation approach.

5.3 Considerations on Link Establishment

If the physical link request C_PDU or the physical link accepted C_PDU are lost in transmission, all subsequent transmission is wasted. Therefore the following considerations should be taken when using pipelining:

  1. Transmission should take place at a conservative transmission speed to minimize risk of data loss, taking into account data rate change information from S5066-EP4.  
  2. If there is space in the transmission, it is highly desirable to repeat the C_PDU with physical link requests/accept, to minimize risk of data loss.  A sender MAY repeat this C_PDU at points of the transmission after ARQ data has been sent.  This approach will minimize risk of loss.   A receiver is recommended to be aware of this and if ARQ data is received prior to the physical link request C_PDU it is recommended look at the rest of the transmission for duplicate transmission. If a receiver receives ARQ data outside of a CAS-1 link and does not find an associated physical link request it shall send a WARNING D_PDU.
  3. Long data transmissions in association with CAS-1 pipelining are not recommended.  In general the first transmission should be restricted to one block of data or perhaps a small number of blocks.  

6. Pipelining Link Break

6.1 Benefits of Pipelined Link Break

By pipelining the link break a handshake is eliminated. This reduces the time that the communication channel is used, thus enabling the channel to be used sooner for other purposes and thus increasing channel utilization

6.2 Break Problems to Address

Link break pipelining has some problems to address not faced on link setup:

  1. Before a link can be closed, all data transferred has to be acknowledged. If the break is pipelined with the data being sent, there is a need to ensure that this data is correctly transferred before the link is broken.
  2. A common scenario is that data is sent and then an application response is immediately sent back over the same link.   This means that the final data is transferred from initiator to responder. Standard soft link break requires a timer before this can happen (A. "Since a called peer can terminate a Soft Link Data Exchange Session if it has higher priority data destined for a different Node, called peers shall (3) wait a configurable minimum time before unilaterally terminating sessions, to prevent unstable operation of the protocol."). It is desirable to eliminate this delay as well as the handshake.

6.3 Break Mechanism

The Link Break service is provided by the same interface specified in B.2 for both normal and pipelined link break. Two new C_PDUs are introduced to provide the pipelined break capability. These PDUs both the use the following single byte encoding:

Not Used

The values of the type code is shown in the following table, which extends the table in B.3.1.

c_PDU Name Type Code

Unlike the other C_PDUs (which are transferred using expedited non-ARQ) these PHYSICAL LINK OPTIONAL BREAK C_PDU is transferred using normal ARQ service and the PHYSICAL LINK OPTIONAL BREAK CONFIRM C_PDU is transferred using normal non-ARQ. The confirm is sent with non-ARQ as the transfer does not need confirmation. They may be pipelined with normal data and will be sent after all data has been sent on the physical link. Because they are sent as ARQ, the receiving system will be able to determine if any data sent prior to the C_PDU has been lost. The following procedure is used:

  1. When either node is transmitting and has no more data to transmit beyond the data included in the transmission and no data outstanding to receive (that it knows of) it will send the PHYSICAL LINK OPTIONAL BREAK C_PDU at the end of the transmission.  
  2. A PHYSICAL LINK OPTIONAL BREAK C_PDU shall use the ARQ Deliver-In-Order Mode. This ensures that all outstanding data has been received and protects against out-of-order reception as a result of D_PDU duplication.
  3. If the node receiving the transmission in 1 determines that is has no data outstanding to receive and has data to transmit that can be transmitted in a single transmission it transmits this data and will send the PHYSICAL LINK OPTIONAL BREAK C_PDU at the end of the transmission.
  4. If the node receiving the transmission in 1 determines that is has no data outstanding to receive and has no data to transmit, it will send a transmission with necessary acknowledgements and a PHYSICAL LINK OPTIONAL BREAK CONFIRM C_PDU at the end of the transmission.
  5. When a node makes a transmission of a PHYSICAL LINK OPTIONAL BREAK C_PDU and does not get a PHYSICAL LINK OPTIONAL BREAK CONFIRM C_PDU response it will continue with normal ARQ transmission procedure.
  6. When a node receives a PHYSICAL LINK OPTIONAL BREAK CONFIRM C_PDU it shall treat the link as broken.

Note that this procedure shall not be used when expedited data other than link management C_PDUs are being handled and standard CAS-1 shall be used.

7. Minimum Length and Extended Soft Links

In normal use with Annex-K/CSMA style operation, it will make sense to close soft links as soon as there is no more data to send. This will allow other nodes to send data at the earliest possible point.   
There are three exceptions to this, where a link may be held open longer.

  1. Duplex link on a two node network not using ALE. For a duplex link either end can initiate transmission at any time. As the link is only being used by two nodes there is no benefit from breaking a soft link, and so the link can be kept open.
  2. Annex L. The WRTP multi-link model gives each node on the network a chance to transmit, and so there is no need to break soft links. They can be kept open for an extended period.

Half duplex link on an active network not using ALE. For a half duplex link, only the node currently “holding the turn” can transmit. To enable both nodes to send data, the turn needs to be exchanged to prevent blocking. If the nodes can send data back an forth, the physical link may be held open for an extended period. A possible variant is to keep a physical link open in this manner for a configurable time after the last user data is transferred.

8. Backwards Compatibility

This specification negotiates use of the capability using a bit in the C_PDUs for CAS negotiation that is reserved in the standard.   This will mean that when negotiating with an implementation that does not support this specification that the capability will not be negotiated and interoperability will follow the standard.