Summary

Traditional HF Radio communication, which has a 9600 bits/sec maximum speed is being extended to Wideband HF (WBHF) which can give a maximum speed of 128 kbits/sec. STANAG 5066, the NATO data link protocol for use with HF, currently constrains application performance over WBHF. This whitepaper looks at STANAG 5066 protocol extensions to address this.

Creative Commons License

Problem Statement

STANAG 5066 is a widely used data link protocol for military deployments of HF Radio. See [STANAG 5066: The Standard for Data Applications over HF Radio] for a general description.

STANAG 5066 was designed for data rates of up to 20 kbits/sec. When operating at WBHF speeds of up to 120 kbps, there is significant degradation for ARQ data. For more details on the problem see Isode's presentation to the High Frequency Industry Association in September 2012 "Application and STANAG 5066 performance over Wideband HF".

The reason for this degradation is that to obtain good throughput over HF or WBHF, transmissions need to be long, ideally using the 127.5 second maximum transmit duration. The combination of max DPDU size (1024 bytes) and maximum window size (128) constrains ARQ transmission length, leading to suboptimal performance.

This effect can also be seen at high end standard HF speeds (9600 bits/sec) if DPDU size is not set to the maximum value. Addressing this problem appears critical for deployment of WBHF. This proposal is written to facilitate pilot activity, and as input to an updated STANAG 5066 specification.

This version updates the original whitepaper of July 2013, based in implementation experience. It adds a new “LFSN-RESET/WIN RESYNC” PDU which is needed, and adds a capability to negotiate use of this extension in soft link establishment.

Solution Technical Summary

The solution to extend STNAG 5066 is technically straightforward, and can be addressed in a manner which is expected to co-exist cleanly with implementations that do not support these extensions.

This proposal is uses four new PDUs to deal with the extension, designed in a manner that will be easy to slot into existing implementations, and will lead to useful errors if sent to a compliant STANAG 5066 server. It extends the Data PDU by a single byte. This byte is used to extend the Frame Sequence Number from 256 to 65,536 to give a maximum window size of 32,768.


DPDU Size vs Window Size

The extra byte can be used to extend the Window size (half the Frame Sequence Number) and/or the DPDU size. In terms of addressing the basic problem, both approaches work and both changes are equally efficient in terms of using the extra data.
The next sections consider the trade-offs.

DPDU Size Analysis

DPDUs have a compact encoding, and are a reasonably efficient way of transferring data. The table below shows the overhead of different sizes.

DPDU Size
Overhead (%)
Notes
200 9 STANAG 5066 Recommended Size
1024 1.88 Maximum current DPDU Size
2048 0.88  
4096 0.44 Possible new Maximum value

It can be seen that extending the DPDU size to 4096 bytes would reduce overhead by 1.44%. This is not a critical saving, but could nonetheless be useful if all else is equal.

A key trade-off with DPDU size for ARQ transmission is that if the DPDU is lost, then it has to be retransmitted. This trade-off leads to a recommendation in STANAG 5066 to use a DPDU size of around 200 bytes. This was based on measurements at classic HF speeds (up to 2400 bits/sec). It would be useful to make measurements at higher speeds, which Isode plans to do.

It is straightforward to analyze the optimum DPDU size for a given error level. Consider:

b: number of user bytes in DPDU
L: the average length of transmission between a bit error not corrected by the modem
n: number of DPDUs sent

The length can be determined, given a DPDU overhead of 18 bytes as:

L = n * (b + 18)

The tradeoff point is where the cost of retransmission is equal to the header overhead, so:

b+ 18 = n * 18

This determines L as:

L = (b + 18)**2 / 18

So we can now calculate L. The following table shows L for a number of DPDU sizes, and time to transmit this data at 1200 bits/sec (traditional HF speed), 9600 bits/sec (max HF speed) and 120 kbits/sec (max WBHF speed). A BER (bit error rate) is also calculated, which represents bit errors that corrupt a DPDU. This is not quite the same as classic BER, as clustering of bit errors is likely to mean that a significant percentage of bit errors will impact the same DPDU. However, it gives some guidance. The percentage DPDU loss shows the percentage of DPDU loss where this size of DPDU becomes optimal.

DPDU Size Length (L) Time (1200) Time (9600) Time (128k) BER % DPDU Loss
100 774 5 0.64 0.05 1.62E-004 13
200 2640 18 2.2 0.17 4.73E-005 7.6
512 15606 104 13 0.98 8.01E-006 3.3
1024 60320 402

50.27

3.77 2.07E-006 1.7
2048 237131 1581 197.61 14.82 5.27E-007 0.86
4096 940278 6269 783.56 58.77 1.33E-007 0.43

To optimize throughput, it will generally be desirable to operate at the "edge of the waterfall". If you are optimizing latency, it makes sense to transmit slower. To maximize throughput, it is likely that you will be transmitting at speed where there is some data loss. Our best guess is that optimal throughput will be obtained with a DPDU size in the existing range. It is highly desirable that measurements are made in order to verify this.

In light of this, we do not think it is worth extending the DPDU size, in order to gain a potential 1.44% throughput increase

Window Size Analysis

In order to transmit for 127.5 seconds at 120 kbits/sec with 1024 bytes, a window size of 1992 is needed. Two factors will increase this:

  1. If there is a full transmission, and there is an error in an early DPDU, the window will only advance as far as the first error. If only a moderate percentage of the DPDUs have errors, you will need almost as much window again to transmit. Loss of an ACK PDU will cause similar problems. We suggest that a factor of at least 4 is needed, to counter this effect, possibly more to support conditions with high error rate.
  2. If there is a high bit error rate, it may well make sense to use smaller DPDUs. We suggest to allow a factor of 4 here, so that DPDUs of around 256 bytes can be used without hitting Window size problems.

These numbers combined suggest a window size of around 32,000 should be allowed for, which means a frame sequence number of around 64,000. This proposal to use two bytes give a maximum value of 65,536. This seems in line with what is needed.

Protocol

This section sets out changes to protocol. It is designed to make extension of existing implementations straightforward.

New PDUs

Four new “LFSN” (Long Frame Sequence Number) PDUs are introduced, using up four of the six spare slots.

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

Expedited Data

It would arguably be sensible to introduce equivalent changes for expedited data. It is felt that expedited data is usually used for small amounts of high priority data, so that the changes for high volumes of data seem less appropriate. Also, there are insufficient spare PDU slots.

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 will need to be updated 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.

When a sending implementation gets to the maximum of the standard Frame Sequence Number (256) and if Window is within the standard range, it will have the choice to either wrap at this point or shift to Long Frame Sequence numbers. If it has more data to transmit, the choice is clear. An implementation may also choose to move to Long Frame Sequence Numbers if it anticipates this will be needed in subsequent transmissions.

PDU Changes

The PDU Changes are shown by first showing the relevant segments of the existing PDU, and then the changes made.

LFSN-DATA-Only

The change to LFSN-DATA-Only is simply to add an extra byte to encode the longer Frame Sequence Number. DATA-Only encoding is:

 
MSB
7
6
5
4
3
2
1
LSB
0
...  
4+m            
MSB
5+m
Size of Segmented C-PDU in BytesLSB
6+m
Transmission Frame Sequence Number (Max 256)
CRC  
...  

The change for LFSN-DATA-Only is straightforward

 
MSB
7
6
5
4
3
2
1
LSB
0
...  
4+m            
MSB
5+m
Size of Segmented C-PDU in BytesLSB
6+m
MSBTransmission Frame Sequence Number (Max 65, 536)
7+m
LSB
CRC  
...  

LFSN-ACK-Only

The key parts of the standard ACK-only are shown below:

 
MSB
7
6
5
4
3
2
1
LSB
0
...  
3      
Size of Header in Bytes (h)
3+m
Source and Destination Address
4+m
Receiver Lower Window Edge (RX LWE)
4+m+s
Selective Acks (0-16 bytes)
CRC  
...  

The LFSN-ACK-only encoding is:

 
MSB
7
6
5
4
3
2
1
LSB
0
...  
3      
MSBSize of Header in Bytes (h)
4
LSB
4+m
Source and Destination Address
5+m
MSBReceiver Lower Window Edge (RX LWE)
6+m
LSB
6+m+s
Selective Acks (0-4096 bytes)
CRC  
...  

The following changes are noted.

  1. Receive Lower Window Edge is extended to two bytes, to reflect the increase in Frame Sequence Number.
  2. The header size is extended by a byte, to enable an increase of Selective Acks to up to 4096 bytes, which reflects a maximum of 32,768 DPDUs to report on.

It is noted that in good conditions, the Window size is likely to remain a long way below the maximum, and so the ACK-only PDU size will be a good deal less than the potential maximum.

LFSN-DATA-ACK

Analogous changes are made to 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. Where the ACK is large (e.g., in poor conditions) it may be beneficial to use LFSN-DATA-Only ply LFSN-ACK-Only instead of LFSN-DATA-ACK, to keep the DPDUs smaller and reduce risk of loss.

DATA-ACK encoding is:

 
MSB
7
6
5
4
3
2
1
LSB
0
...  
3      
Size of Header in Bytes (h)
3+m
Source and Destination Address
4+m            
MSB
5+m
Size of Segmented C-PDU in BytesLSB
6+m
Transmission Frame Sequence Number (Max 256)
7+m
MSBReceiver Lower Window Edge (RX LWE)
8+m
Selective Acks (0-16 bytes)
CRC  
...  

LFSN-DATA-ACK encoding is:

 
MSB
7
6
5
4
3
2
1
LSB
0
...  
3      
MSBSize of Header in Bytes (h)
4
LSB
4+m
Source and Destination Address
5+m            
MSB
6+m
Size of Segmented C-PDU in BytesLSB
7+m
MSBTransmission Frame Sequence Number (Max 256)
8+m
LSB
9+m
MSBReceiver Lower Window Edge (RX LWE)
10+m
LSB
11+m+s
Selective Acks (0-4096 bytes)
CRC  
...  

LFSN-RESET/WIN RESYNC

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

RESET/WIN RESYNC encoding is:

 
MSB
7
6
5
4
3
2
1
LSB
0
...  
4+m  
5+m
New Receiver Lower Window Edge (RX-LWE)
6+m
Reset Frame ID Number
CRC  
...  

LFSN-RESET/WIN RESYNC encoding is:

 
MSB
7
6
5
4
3
2
1
LSB
0
...  
4+m  
5+m
LSBNew Receiver Lower Window Edge (RX-LWE)
6+m
MSB
7+m
Reset Frame ID Number
CRC  
...  

LFSN Capability Negotiation

The choice to use either the current STANAG 5066 protocol or to use the LFSN 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 LFSN is negotiated, the PDUs which the LFSN 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 LFSN. The current PHYSICAL LINK REQUEST C_PDU encoding is:

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

This is modified to:

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

The LFSN bit will be used to request use of LFSN 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 LFSN and wishes to use LFSN for a link, it will explicitly agree this using the PHYSICAL LINK ACCEPTED C_PDU. Note that LFSN will only be negotiated if both ends support it. The current PHYSICAL LINK ACCEPTED C_PDU is:

MSB
7
6
5
4
3
2
1
LSB
0
Type
Not Used

This is modified to:

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

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

Conclusions

This specification extends STANAG 5066 to increase the Frame Sequence Number, which will lead to significant performance improvements with WBHF and some improvements for the top end HF speeds.