This specification addresses performance problems caused by window exhaustion which impacts WBHF and faster speeds for standard HF. 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. Problem to be Addressed

STANAG 5066 has a window size for ARQ transfers of 128. This is inadequate for higher speed transfers with narrow band HF and significantly impacts ARQ performance for Wideband HF.

This specification sets out a protocol extension to address this.  The protocol on which this specification is based was originally  set out in the Isode white paper Extending STANAG 5066 to improve ARQ Performance over Wideband HF Radio, which also includes background information.  This has been developed based on subsequent experience and input from STANAG 5066 vendors (Isode, RapidM, and Rohde & Schwarz).

2. Overview of Approach

The approach taken to this protocol is to increase frame sequence number (FSN) from one byte to two bytes. This is described as Long Frame Sequence Number (LFSN). This increases the window size to an adequate size (32,768), adding one byte to the DPDUs used. The CAS-1 CPDUs used to negotiate link setup are extended (using spare bits) to enable this capability to be negotiated.

3. Extended Protocol to support LFSN

This section sets out changes to protocol to support Long Frame Sequence Numbers and associated functionality. This is referred to as Extended Capability.

3.1 New PDUs

Four new "Extended" PDUs are introduced, using up four of the six spare slots.

New PDU Number Equivalent Existing PDU
Extended-DATA-Only 9 DATA-Only
Extended-ACK-Only 10 ACK-Only
Extended-DATA+ACK 11 DATA-ACK
Extended-RESET/WIN RESYNC 12 RESET/WIN RESYNC

3.2 Choice of PDU & Protocol

The details of the protocol procedures, such as C.6.2 D_PDU Frame-Sequence Numbers and Flow-Control when in the DATA STATE need editorial change to reflect these protocol changes and operation with large frame sequence number.

These changes are expected to give performance benefits at the higher end of the HF range, so the design approach is to use the (more compact) standard PDUs whenever possible. Whenever a message can be encoded with the current standard, this should be done.

This protocol allows negotiation of the option to use the new Extended PDUs. If this option is not negotiated, the Extended PDUs shall not be used. If this option is negotiated, the Extended PDUs shall be used and the equivalent standard PDUs shall not be used.

3.3 PDU Changes

The PDU Changes are described in the following sections, making clear changes relative the STANAG 5066 ed3.

3.3.1 Extended-DATA-Only

The change to Extended-DATA-Only is simply to add an extra byte to encode the longer Frame Sequence Number. Where encoding is different to the DATA-Only PDU, the line is marked “*” and the change indicated by colour.

 
MSB
7
6
5
4
3
2
1
LSB
0
0 DPDU Type = 9 EOW Type
1 EOW
2 EOT
3 Size of Address Field (m) Size of Header (h)
3+m Source and Destination Address
4+m C_PDU START C_PDU END DELIVER IN ORDER DROP C_PDU TX WIN UWE TX WINE UWE  
5+m Segment Size (n)
6+m*   Frame Sequence Number MSB
7+m* LSB (increase to 16 bits)  
CRC CRC on Header

h+m

h+m+n+1

Segmented C_PDU
CRC
CRC
CRC
CRC
CRC on Data

3.3.2 Extended-ACK-Only

The encoding of Extended-ACK-only, with changes relative to ACK-only, are shown below:

 
MSB
7
6
5
4
3
2
1
LSB
0
0 DPDU Type = 10 EOW Type
1 EOW
2 EOT
3 Size of Address Field (m) Size of Header (h)
3+m Source and Destination Address
4+m*    Received Lower Window Edge MSB
5+m* LSB (increase 8 to 16 bits)  
6+m* Encoding Offset
7+m* Ack Length (aa)

8+m*

 

h+m-3

Ack Data (0-21 bytes)
CRC CRC on Header

h+m*

h+m+n+1*

Ack Data
CRC*
CRC*
CRC*
CRC *
CRC on Ack Data

The following changes are noted.

  1. Receive Lower Window Edge is extended to two bytes, to reflect the increase in Frame Sequence Number.
  2. There is an option to encode up to 21 bytes of Ack data in the header, which gives a compact encoding where only a small amount of Ack data is needed.
  3. Where more Ack data is needed, there is an option to encode Acknowledgement data outside of the header. The number of byes of additional Acknowledgement data is specified in the Ack Length field. The DPDU has this data after the header followed by a 32 bit checksum, which is the same checksum used for the DATA PDU.  When this option is used, no Ack data is encoded in the header.
  4. The maximum window size can lead to up to 32,768 packets to be acknowledged, which would need up to 4096 bytes with the standard mechanism. It will generally be desirable to keep Ack packets smaller than this. The offset mechanism provides a means to do this, by enabling reporting relative to an offset of the Lower Window Edge. The Offset value is multiplied by 256 to determine the size of the offset in bits (where each bit represents a PDU that is being acknowledged). This enables the acknowledgement data to be reduced, so that the Ack Data may be reduced so that it will never exceed 32 bytes.
  5. Two options are provided to encode Ack Data. The first mechanism is the one used in STANAG 5066 and the second is a Run Length encoding described below. The Encoding bit is set to indicate that  Run Length Encoding is used. A sender may choose to use either or both encodings. A receiver shall support both encodings. The encodings are described below.

The standard Ack encoding is that a bit is set to 1 to indicate that a Data PDU has been accepted. The data starts with reference to the first PDU after the Offset.   Bit encoding follows the rules of C.3.4. It is safe to add trailing zeros to pad to exact number of bytes.

Run Length Encoding provides an encoding of the standard Ack encoding. In some common situations, this will be more compact.  It is recommended to use the more compact encoding. The encoding is illustrated below. 

  MSB
7
6 5 4 3 2 1 LSB
0
0 Value Extended = 0 MSB Length LSB
  MSB
7
6 5 4 3 2 1 LSB
0
  Value Extended = 1 MSB Length LSB
0 LSB

The first bit (Value) is set to 0 or 1 and shows the value that is being repeated. If the Extended bit is set to 0, the encoding uses one byte and Length is specified in 6 bits. If the Extended bit is set to 1, the encoding uses two bytes and Length is specified in 14 bits. The Length indicates the number of repeats of the value, so if length is zero the value occurs once and is not repeated.

3.3.3 Extended-DATA-ACK

ACKs will often be very small (e.g., just changing the window edge, with no selective acks) and the combined PDU seems a useful optimization. This Extended-DATA-ACK encodes up to 18 bytes of acknowledgement information in the header (which leads to maximum header size). If the Encoding bit is set to zero, standard STANAG 5066 encoding is used. If the Encoding bit is set to 1, the Run Length Encoding defined for Extended-ACK-ONLY is used.  This allows acknowledgement of PDUs up to 152 ahead of the Lower Window Edge. Where there is a need to acknowledge PDUs more than 152 ahead, separate Extended-ACK PDUs shall be used.

  MSB
7
6 5 4 3 2 1 LSB
0
0 DPDU Type = 11 EOW Type
1 EOW
2 EOT
3 Size of Address Field (n) Size of header (h)
3+m Source and Destination Address

4+m

C_PDU START C_PDU END DELIVER IN ORDER DROP C_PDU TX WIN UWE TX WIN UWE  
5+m Segment Size (n)
6+m*   Transmit Frame Sequence Number MSB
7+m* LSB (increase 8 to 16 bits)  
8+m*   New Reciever Lower Window Edge MSB
9+m* LSB (increase 8 to 16 bits)  
10+m* Encoding Not Used

11+m*

...

h+m-3

Selective Acks (0-18) bytes

(increase 16 to 18 bytes)

CRC
CRC
CRC on Header

h+m

h+m+n-1

Segmented C_PDU
CRC
CRC
CRC
CRC
CRC on Data

3.3.4 Extended-RESET/WIN RESYNC

The PDU for dealing with link resets and synchronization also needs to be extended.

Extended-RESET/WIN RESYNC encoding is:

  MSB
7
6 5 4 3 2 1 LSB
0
0 DPDU Type = 12 EOW Type
1 EOW
2 EOT
3 Size of Address Field (m) Size of header (h)
3+m Source and Destination Address

4+m

Unused FRC RTWQ RRWC R
5+m*   New Reciever Lower Window Edge MSB
6+m* LSB (increase 8 to 16 bits)  
7+m* Reset Frame ID Number
CRC
CRC
CRC on Data

3.4 Extended Capability Negotiation

The choice to use either the current STANAG 5066 protocol or to use the Extended Capability and the four new PDUs (instead of the original ones) will be negotiated in soft link establishment. Either the current protocol will be used, or the modified protocol with a longer frame sequence number will be used. If Extended Capability is negotiated, the PDUs which the Extended Capability variants replace shall not be used.

When a link is established, the request is made with a PHYSICAL LINK REQUEST C_PDU. This PDU is extended to enable negotiation of Extended Capability. This is shown below:

MSB
7
6 5 4 3 2 1 LSB
0
Type = 1 Not Used LFSN* Link

The Extended bit will be used to request use of Extended Capability for a link. STANAG 5066 requires that unused bits are set to zero, so it is unlikely that this capability will be accidentally negotiated.

If a responder supports Extended Capability and wishes to use Extended Capability for a link, it will explicitly agree this using the PHYSICAL LINK ACCEPTED C_PDU. Note that Extended Capability will only be negotiated if both ends support it. The encoding is:

MSB
7
6 5 4 3 2 1 LSB
0
Type = 2 Not Used LFSN* Link

If the responder wishes to use Extended Capability, it will set the LFSN bit to 1.

4. 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 so this capability will only be used between implementations that support this specification.