Congestion Control and HF Radio

HF Radio provides a difficult medium for data transfer. In particular:

• Speed can be highly variable, ranging from 75 bps to 240 kbps.
• Latency is generally much higher than for faster networks.
• There can be extended periods when no data transfer at all is possible.

This means that for HF Radio networks, traffic will sometimes build up, leading to congestion.
Several techniques are used to deal with this:

1. STANAG 5066, the NATO link layer for HF Radio, which provides multiplexing between applications, marks all data with priority. This is used to control which data is sent first, both between and within applications.
2. Interactive applications such as Web browsing are only going to be used when conditions are good and are in practice “self-regulating”.
3. Some applications, such as XMPP chat, are assumed to be low volume with reliability expected. So, the application will just “keep going” until the messages are transferred.
4. For bulk applications, such as email and military messaging, messages are sent in strict priority order, and messages waiting for transmission are queued. Operators are given access to the message queues and have controls to:
   1. Modify the priority of messages to control the order in which messages are sent.
   2. Removal of queued messages (“vetting off”) to manage overall load.

These are important generic techniques, but are not what is needed for C2.

C2 and Tracks Requirements

C2 over HF is discussed in two Isode white papers:

• “Link-16 and other C2 protocols over HF Radio”.
• “Operating TAK over HF Radio”.

In order for these protocols to operate efficiently, a streaming approach is recommended that enables substantial data compression.

The major use of these protocols is to support “tracks” to share the location of friendly and other entities. These are typically small messages, with updates sent frequently (Link-16 has a 12-second default for updates). Although data volumes are low, there is significant potential for link congestion when HF is used. Two general requirements drive the approach taken to congestion:

1. “Tracks” is about current/recent information. As information ages, its value reduces and at some stage becomes worthless.
2. Where a “track” updates the location of an object, earlier tracks on the object become worthless.

These requirements drive the approach taken.

Icon-PEP Implementation Approach

Icon-PEP is Isode’s product that provides a streaming interface used for support of C2 protocols, with measurements published in the white papers.

In order to address the requirements above, it is necessary to break down the C2 stream into a sequence of messages (tracks) that are handled internally as a queue of messages. Four broad approaches are taken:

1. Generate the data to be streamed over HF (following STANAG 5066 Annex W) at the latest possible time.
2. Handle messages on a LIFO (Last In First Out) basis so that recent messages are sent first.
3. Purge the queue of very old messages.
4. For Tracks, identify the object and remove older tracks for that object from the queue.

These approaches provide effective C2 congestion control and retain the compression performance that a streamed approach enables.

Note: Some C2 protocols provide information as to when messages become obsolete (e.g., “stale_time” in TAK). Icon-PEP respects this information and does not remove messages that are currently valid. However, independent HF controls are seen to be important because of high HF latencies, and in many situations, it would be preferable to receive out-of-date information than no information.

Auditing and Monitoring

In order to perform congestion control, Icon-PEP needs to parse the C2 messages. This enables an audit of C2 messages and transmit/discard actions taken. It also enables Icon-PEP to provide operator monitoring of recent messages, as shown above. This enables the operator to see:

1. Summary of C2 messages transmitted and received, and message type.
2. Information on messages discarded, either due to age or due to being superseded by a more recent track.
3. Option to view detailed information on the message/track.

This is important operator information, illustrated in the following screenshots.

This screenshot shows basic operation when the system is “keeping up”. The operator can see tracks sent, with the time sent and the name of the object. This gives a clear overall view of what is going on.

When a track arrives that updates a queued message, this is also shown to the operator. The replaced message holds the queue position of the message being replaced. This means that the latest information is always sent, but the track for a given object is never dropped.

As well as tracks, there are other messages that get transferred, which can be TAK synchronisation messages and services such as GEO Chat. These non-track messages are also shown. It is expected that there will be HF capacity to handle all of these messages. It is only the tracks that get updated.

It is also possible for the operator to inspect individual messages. The screenshot above shows the inspection of a short TAK message, representing the structure of the data sent.

Experience with TAK

It is noted that Icon-PEP will need explicit support for each type of C2 message it supports. It is anticipated that future versions of Icon-PEP will add support for a range of C2 protocols, with the choice driven by customer requirements.

The initial C2 protocol supported is the TAK protocol used between TAK servers. A target scenario is exchanging TAK messages between two ships running TAK and connected over HF Radio. The architecture allows for a fallback from faster IP links to HF.

The above screenshot shows two WinTAK clients connected over a simulated HF link. Tracks are being generated on the LH system. The RH system has the tracks sent over HF with the display following changes on LH. This demonstration shows maintaining tracks for 30 objects over an HF link of 600 bps.

The result is that the system “keeps up”, and the techniques described prevent congestion build-up and enable the connected system to show information that is close to current.

STANAG 5066 and Flow Control

Traditional STANAG 5066 flow control is a simple on/off control from the server to all client applications. This means that a server needs to accept enough traffic to determine the length of transmission needed (up to two minutes). This crude approach leads to data being queued for several minutes in the STANAG 5066 server, which makes the C2 congestion approach less effective than it could be.

STANAG 5066 Ed5 introduces a new extended flow control mechanism, where the client provides information on data queued and the server requests information as needed. This enables data to rest in the client until the last possible moment, which makes the C2 Congestion control more effective and responsive.

This mechanism is implemented in Icon-PEP and will be supported in the next release of Icon-5066 (Release 4.0).

Conclusions

This paper has described an approach to effective provision of congestion control for C2 tracks operation over HF Radio and shown how it is implemented in Isode’s Icon-PEP product to support TAK.