Tracks, TDL, Sensors & RAP display

Modern C2 operates in a highly distributed environment. The broad model is shown above. The arrows show flow of “tracks” which are typically short messages communicating location and other information on objects of interest. The key components are:

1. Sensors, such as radar which gather information on objects of interest.
2. Relays which convert, filter and switch tracks.
3. SA monitors that display information to operators.

There are many Situational Awareness (SA) monitors. Some examples used by NATO are: ICC; AirC2IS; NCOP;  and iGeoSIT. The following screenshot of AirC2IS gives a sense of what an SA Monitor will offer.

NIRIS

There are a wide variety of protocols used to carry Tracks. Some of these are discussed later. A key problem with building a large scale C2 system is to handle this variety. A broad goal is to collect data from many sensors and then share this data with many SA monitors.

NATO NIRIS (Networked Interoperable Real-time Information Service) is a widely used relay system. It supports a huge number of track protocols and provides integration capabilities for various SA Monitors. The ability to provide conversion and integration makes it a key component. NIRIS was also used for the measurements in this white paper.

Why HF Radio

In a modern deployment of the C2 architecture of the model described above, links will use fast IP connections wherever possible. Use of HF radio, which provides a relatively poor quality link will only be used when there is no other option. The primary scenarios are:

1. In scenarios, such as polar regions, where there is no other choice.
2. For fall back, particularly for longer distances links in Satcom-denied scenarios.

For modern C2 systems, HF will not be a default choice, but is very important to have available when it is needed.

TCP Streaming

There are a wide variety of protocols used for C2, so the approach proposed is to use TCP Streaming following the TCP PEP (Performance Enhancing Protocol) mechanism specified in STANAG 5066 Annex X “HF-PEP: TCP Performance Enhancing Proxy Protocol”. This provides a generic mechanism, which is independent of the specific C2 protocol used.

An alternative would be to use UDP (User Datagram Protocol) over IP Client as specified in STANAG 5066 Annex U. This alternative is not chosen for two reasons:

1. IP Addressing and other initialization overhead is needed once per stream with TCP and once per packet with UDP. This is a significant difference for small C2 messages.
2. C2 messages tend to be repetitive, so compression will give a significant gain if TCP is used. The measurements in the paper show this.

The TCP Streaming architecture of STANAG 5066 Annex X is shown above. Use of HF is transparent to the C2 Application, which simply connects over TCP as an end to end streaming service. The Annex X proxy efficiently maps the TCP stream over HF.

More information on TCP Streaming is provided in the Isode white paper “Providing TCP Services over HF Radio”.

 Test Architecture

The above diagram shows how TCP Streaming is provided with the Isode product set and the setup used in the various tests described. Notes on the setup:

• NIRIS 4.4 was used and links configured over TCP.
• TCP connections are routed to Icon-PEP using a standard IP router.
• Icon-PEP acts as a specialized IP router and controls routing of the proxy TCP and handles STANAG 5066 Annex X.
• Icon-5066 provides the STANAG 5066 HF link layer.
• MoRaSky, Isode’s HF simulator provides the connection.

Parameters used on the tests.

• Link layer controlled as a basic Simplex configuration.
• STANAG 4539 with short interleaver.
• Fixed speeds for each test. The following speeds were chosen:
  • 9600 bps – top Narrowband HF speed.
  • 1200 bps – a mid range HF speed.
  • 75bps – the usual lowest HF speed.Operating at the low end of HF speeds is seen as increasingly important.

Link-16

Link-16 is one of a large family of Tracks protocols referred to as Tactical Data Link (TDL). It is the primary target of this white paper, as Link-16 is very widely used.

JREAP C

These numbers are poor; significantly worse than the numbers shown below. The conclusion is that JREAP C is not suitable for operation over HF.

Observing the network explains why. NIRIS generally maintained two open TCP connections when connected over HF. There is an initial handshake and then a handshake every few seconds. This procedure clearly works well over faster low latency networks and leads to desirable operational characteristics. For HF, the high latency means that the message exchange kills performance.

Alternate Framing

NIRIS supports a number of framing protocols to operate Link-16 over TCP, including NACT, ASEP, MAXTERIX, IP/IP, and SIMPLE. These protocols operate without handshaking.

Tests were done using SIMPLE. No attempt was made to compare the framing protocols. It was noted that NACT messages were quite a bit larger. Performance is clearly impacted by message size.

Link 16 messages over SIMPLE are fixed size and 60 bytes each. Throughput measurements were made, using the NIRIS Link 16 generation tool, with options to give as wide a variety of messages as possible.

STANAG 5066 Annex X provides stream compression using the DEFLATE algorithm. Icon-PEP monitoring makes the amount of compression achieved on a stream straightforward to observe.

For a run of 100 Link-16 messages, 19% compression was noted. Longer runs gave much higher compression, up to 82% for long runs. Long lived connections are expected to be the usual case, so good compression is generally expected.

The effective speed was measured based on the number of 60 byte messages delivered. Compression leads to an effective speed that is greater than modem speed.

Other C2 Protocols

NIRIS supports a myriad of other C2 protocols that could be deployed in a similar way. Measurements were made on two protocols, chosen because they are quite different to Link-16 and are widely used.

1. OTH-Gold (Over The Horizon Gold) is used to share radar data, with messages in Message Text Format (MTF). It was used with OTG/JANAP framing.
2. NFFI (NATO Friendly Force Information) is an XML format message, tested with IP1/IP2 framing.

All tests were run for 10 minutes at 1200 bps. Link-16 result included below.

Although both of these protocols have much larger message size, compression is effective and leads to acceptable throughput rates.

It is anticipated that that similar performances will be achieved for other tracks protocols.

Deployment Considerations

This section considers three issues that will be relevant to deployment.

Security

All of the tests were conducted without any protection of the link. NIRIS enables use of TLS to protect C2 links. This will be important in many deployments. Icon-PEP can support this, without any additional performance cost, using TLS Proxy. This is described in the Isode white paper “Providing TCP Services over HF Radio”.

Multi-Node

The tests were performed using a single pair of nodes. It is expected that in some deployments, a node will wish to communicate with multiple peers using a single HF modem. There are two options for achieving this. It is expected that a C2 stream will have an ongoing sequence of messages, so a sharing approach is needed.

The first approach is to allow multiple nodes to share a single channel, using either CSMA (STANAG 5066 Annex K) or Wireless Token Ring Protocol (STANAG 5066 Annex L). The streams then get multiplexed by STANAG 5066. This is a good approach for an HF Surface wave deployment, such as a Naval Task Group, where good and consistent propagation is expected.

For Skywave, an ALE approach is preferable, using the ALE link sharing mechanisms described in STANAG 5066 Annex B. This will lead to a series of ALE links being made. The SLEP Streaming mechanism of STANAG 5066 Annex W used by Annex X is designed so that the SLEP stream will continue over the underlying ALE connections. This means that at the C2 level, multiple ongoing SLEP streams can be maintained.

Fall-Back

An important operational target is to provide fall back to HF in a Satcom-denied environment. The architecture here provides this naturally.

The key architectural point is that the IP routers used will be configured for both direct and HF links. When the direct link is available, traffic will use that. When the link fails, the connection will fail over to the HF link.

Link-22

Link-11 is a historically important TDL that was designed for operation over HF. It was of critical importance, but has largely been replaced by Link-16 which does not have HF support. Link-22 is a new TDL with HF support. Isode sees Link-22 as “the right answer to the wrong question”. The goal of Link-22 is clear from its other name NILE: NATO Improvements to Link-11.

Isode sees two key issues with Link-22.

1. Needing independent HF infrastructure. When Link-11 was specified, the current HF technology was not suitable for sharing HF infrastructure between applications. Since then HF modem waveforms have improved immeasurably, ALE gives flexible frequency usage and STANAG 5066 provides a multi-application link layer. Operationally, it makes sense to have a single HF infrastructure that can be shared between TDL and critical applications such as XMPP Chat and Formal Messaging.
2. No IP fallback. Link-22 is designed as a primary bearer. This does not reflect the primary operational use of HF as fallback technology.

Both of these issues are addressed with the architecture set out in this white paper.

Conclusions

This white paper has shown how Link-16 and other C2 protocols can be efficiently operated over HF using TCP Streaming based on STANAG 5066 Annex X. Lab performance measurements have been provided to validate the architecture.