Reducing Turnaround Times in STANAG 5066

Operational Experience & Consequences

When STANAG 5066 is currently deployed, turnaround times are measured in seconds or tens of seconds. This is seen in operational and lab systems, and is generally noted as a characteristic of STANAG 5066.

To address this, STANAG 5066 allows for long transmissions of up to 127.5 seconds (just over two minutes). Because of the long turnaround time, it is necessary to have long transmissions in order to achieve reasonable throughput, as if you use short transmissions a high percentage of the time is spent in turnaround. Some STANAG 5066 implementations force use of the maximum transmission time whenever there is data to send, in order to optimize throughput.

Reasonably low latency can only be achieved where low throughput (relative to modem speed) is needed. This is a problem for a link carrying a mix of high volume traffic and traffic that requires low latency or for traffic such as Web browsing that needs both.

It can be seen that improving turnaround time for STANAG 5066 is highly desirable.

Physical Limits

The limits of HF and modern HF equipment do not inherently need long turnaround times. Specifically:

• Transmission times are negligible (1,000 km takes 3.3 milliseconds).
• Modern HF equipment does not need any physical switching, unlike older equipment that needed to prevent the local receiver from being damaged by local transmission.
• STANAG 5066 switches on the same frequency, so there is no Antennae Tuner delay, which is likely to be the largest delay if frequency changes (unless a broadband antenna is used).
• Power Amplifiers (PA) need time to get up to full power. This delay is measured in tens of milliseconds and a modern PA would typically need 50 milliseconds or less.

So the limit of turnaround time on a modern system is expected to be 50 milliseconds or less.

Timings direct to Modem

In order to understand why there are delays, the system needs to be examined in more detail. We first consider a system where STANAG 5066 is directly connected to the modem with a fast asynchronous link. The following diagram shows data first arriving and then data being transmitted. The bottom line shows OTA timings and the top line shows timings between modem and STANAG 5066.

The key elements of this diagram are as follows:

• An OTA transmission starts with a preamble (shown in green) and then a series of blocks of interleaver length (shown in grey).
• The diagram shows a receiving a transmission, turnaround, and then transmitting a transmission.
• The transmission blocks contain STANAG 5066 data (shown in blue).
• When a block of data is received, it is processed as a whole and then (after a delay) data is passed quickly up to the modem. This is shown on the received side. You can see that data is passed up quickly to STANAG 5066 after the block has arrived.
• Older modem interfaces cannot precisely identify the start of user data, which means that modem padding data (shown in purple) is needed both before and after the user data to ensure that no user data is lost. This is invariably needed if a synchronous serial interface is used (next section). Modern modem interfaces, using data access such as that specified in MIL-STD-188-110C Annex A can avoid this overhead.
• Transmission is usually initiated by STANAG 5066 sending data to the modem. The diagram shows all of the data for the transmission being sent quickly. A useful and more sophisticated strategy is discussed later.

The key delays and overheads shown in the diagram are as follows:

1. Block Processing Time. There is a delay between the final data arriving at the modem and data being passed to STANAG 5066. The reason for this is that modern modem protocols (e.g., STANAG 4539; STANAG 5069) transmit data in blocks which must be fully processed. So each block is processed and then passed up to STANAG 5066, and so each block will arrive as a burst slightly after the block has arrived. For small blocks (small interleaver size) at slow speeds this delay will be negligible. For high WBHF speeds with long blocks, the delay can be significant (potentially seconds) because of the processing needed.
2. Reaction Time. This is the time needed for the receiving modem to determine that the inbound data has finished. STANAG 5066 uses an EOT (End of Transmission) field with 0.5 second granularity. This allows the end point to be determined when the end of the transmission is lost. This means that the reaction time will be at least 0.5 seconds.
3. PA Time. As described above, this will typically be 50 milliseconds or less.
4. Preamble Time. HF Transmissions always start with a pre-amble. These can be long (e.g., 4.8 seconds for medium and long interleavers for STANAG 4539 2400 bps and slower).
5. Modem Padding. This is data needed before the real transmission begins. In a modern system this should be small or zero.

Timings with Synchronous Serial Crypto

In most deployments, link level crypto is used between STANAG 5066 and the modem. Most crypto devices use synchronous serial interfaces, with clocking provided by the modem at modem speed. The impact of this is shown in the next diagram.

Notes on the diagram:

• When the modem receives data, after a block has been processed, it needs to be sent to the crypto at modem speed (the modem is clocking the serial interface), which adds an interleaver-length delay.
• The Crypto will add some delay, and so data received at the STANAG 5066 later is delayed slightly relative to the modem/crypto interface.
• The Crypto adds a pre-amble (shown) in orange, needed to synchronize the receiving Crypto.
• A full block of data needs to be received by the modem prior to transmission of the first block. This will usually lead to additional delay, discussed below.

This introduces a number of additional delays:

1. Block Delay (reception). A delay of one block length (interleaver length) arises because transmission of data through the crypto can only start after the block has been received.
2. Block Delay (transmission). A full block of data needs to be received by the modem prior to transmission of the first block. The PA Time and Preamble can over overlap this, but they will usually be less than the block size.
3. Crypto Delay. Some Crypto devices add a delay on processing data, which impacts both send and receive.
4. Crypto Padding. Some additional padding may be needed to support the crypto device. This should be small.
5. Crypto Preamble. The Crypto needs to add a preamble, to synchronize with the peer Crypto. This is expected to be a small overhead, except at slower narrowband HF speeds.

All of this makes clear why operational STANAG 5066 has delays, and these will increase significantly as longer interleavers are used.

Approaches to Reduce Turnaround Time

This section now considers how turnaround time can be reduced. While shorter interleavers can help, this approach is not taken, as in general longer interleavers are highly desirable to maximize throughput and to minimize data loss/retransmission.

Use a Short Preamble

The modem preamble can be a significant overhead. Notes on overheads:

• For STANAG 4539 2400 bps and below, the preamble is the same length as the interleaver, which means up to 4.8 seconds.
• For STANAG 4539 3200 and above, the preamble is a variable length, with a minimum of 120 milliseconds.
• For STANAG 5069 (WBHF, 75-240,000 bps), the preamble is a variable length, with a minimum of 132 milliseconds.

It is clearly important to use a sufficiently long preamble, as failure to synchronize is highly undesirable. In good conditions, it will be reasonable to use a minimum preamble (120/133 milliseconds). The smallest viable preamble should be used in order to minimize turnaround time.

Reducing Reaction Time

The EOT based reaction time is going to be at least 500 milliseconds. With older non-blocked waveforms, this is the best that can be achieved. With block waveforms a better approach is set out in [Block Based EOTs – 5066-EP8]. This repurposes the EOT to reference the number of blocks remaining. It will enable an accurate fix on the end of data transfer and reduce reaction time to a negligible amount.

Allow for Delays

Most of the delays can be eliminated by starting the STANAG 5066 data send before the data has finished arriving. This is shown below.

By starting the STANAG 5066 transfer early, the gap between transmit and receive at modem level can be closed down to the PA time. The turnaround overheads are:

• PA Time, which will be less than 50 milliseconds with a modern PA. This is the only gap needed between end of receive and start of transmit.
• Modem and Crypto padding, which will be negligible in a modern system.
• Crypto preamble, which will be negligible at faster narrowband and WBHF speeds.
• The modem preamble, which will be 133 milliseconds where STANAG 5069 is used.

There are four caveats:

• Crypto needs to be duplex.
• At least three blocks need to be transmitted. The first block will enable EOT synchronization and two blocks are needed to give sufficient time to minimize the turnaround time.
• If Annex L is used, the token needs to be in the first block.
• Block size needs to be the same in each direction.

It is also noted that starting the transmission before the inbound data is all received will delay acknowledgement of data received after the transmission starts. This will not impact performance where data is lost, but will add latency where data is lost and retransmission is needed. The core ARQ engine will also need to allow for this delay, to prevent premature/unnecessary resend of data.

This approach will need careful implementation and tuning for the specific hardware used. It will enable turnaround time to be reduced to 150-200 milliseconds.

Fast Synchronous Send

It is desirable to reduce overlap and to send data as late as possible, as this allows best reaction to incoming data (e.g., to acknowledge incoming data or to give priority to urgent outgoing data at the earliest time). It is clear that operating the Crypto faster would be helpful. Most deployed Crypto boxes use synchronous serial interfaces, so this section considers what can be done using synchronous serial crypto.

It is essential to avoid buffer underflow in a synchronous interface. For data received over the modem, there is little control over when it arrives. This means that for received data, a synchronous serial interface has to be operated at modem speed.

However, for sending data, it is possible to go faster. This is a desirable option, which can be used provided that:

• The Crypto supports operation with different speeds in each direction; and
• The Modem can buffer a full transmission, as it will all be sent at once.

It will be best to send the transmission data as fast as possible. This allows for two of the previous caveats to be removed:

• It will only be necessary to send two (rather than three) as the minimum block count for a transmission. The first block is needed to get EOT information, and transmission can start during reception of the final block.
• The block sizes do not need to be the same. This is a highly desirable optimization for one way data flow, as you want to use long interleavers on the sending data, and shorter interleaver at lower speed for the acknowledgements.

Asynchronous Crypto

The best option would be to use a high speed Crypto with asynchronous interfaces. These will not change the security architecture, but this option is not currently generally available. Ideally, this would use a TCP protocol interface (rather than serial) with a special protocol in the style of MIL-STD-188-110C Annex A, which specifies a TCP protocol to access a modem. This would improve performance and simplify integration.

Fast Asynchronous Crypto would enable received data to be transferred quickly to STANAG 5066, and so the minimum transmission could be reduced to one block.

An ideal sending pattern would have the STANAG 5066 server be aware of modem block size and timing. It would send data in blocks “just in time” for the modem. The benefit of this is that the STANAG 5066 server would be able to react and send high priority data that arrives while the transmission is in progress.

Acknowledgement

Thanks to Mark Jorgenson of Rockwell Collins for repeatedly noting that turnaround did not need to be slow, and for providing data to help write this paper which shows clearly that he is right.

Conclusions

This paper shows clearly why operational turnaround of STANAG 5066 takes many seconds or tens of seconds. It also explains how to eliminate most of this delay and bring down turnaround times to 150-200 milliseconds. This can lead to very significant improvements in throughput and latency for data transfer over STANAG 5066.

Use of Asynchronous Crypto with TCP interfaces is highly desirable to support this.