Operating TAK over HF Radio

What is TAK?

TAK stands for two things:

• Tactical Assault Kit. This reflects its initial military use by the Marine Corps. It is now used much more widely.
• Team Awareness Kit. This reflects wider use for Law Enforcement, First Responders, Commercial and recreational purposes.

TAK is provided as a number of open-source client and server implementations. There is plenty of information on TAK generally available, which is not repeated here. The best place for information is https://tak.gov/, which also provides access to client and server implementations.

Client implementations provided for all major platforms:

• Android (ATAK) is downloadable from Google Play. This is the most widely used client, shown in the screenshot above.
• iPhone (iTAK) is available from the App Store.
• Windows (WinTAK) is available from tak.gov.

There are several TAK server implementations. The most widely deployed one and the one described in this paper is the open-source server developed by Raytheon and available from tak.gov.

TAK Protocols and Deployment

TAK uses the protocol stack shown above for Client-to-Server communication. The TLS (Transport Layer Security) provides link security.

CoT (Cursor on Target) is an XML format designed by Mitre Corporation to handle a range of message types. When used in TAK, the encoding is specified by the initial byte. TAK clients generally use an XML encoding.

 While the XML encoding is widely supported, current systems will generally use a more compact Protobuf encoding.

The TCP/TLS connection is opened using two-way strong authentication. Then a stream of CoT messages flows in both directions.

There is also a mapping onto UDP (User Datagram Protocol) where a single CoT message is sent to either a unicast or a multicast IP address. This stack is used for two things:

1. Specialized mobile TAK clients report their location to listening TAK servers.
2. TAK client operation on a single subnet without a server.

TAK uses the protocol stack shown above for server-to-server communication. Key differences with the Client to Server protocol:

• CoT messages use a protoBuf encoding, which is more compact than XML.
• There is a gRPC layer added, which provides message framing and keepalive heartbeats using HTTP/2.

TAK servers can federate with other servers and are typically configured to filter traffic that is appropriate for each peer server. It is also possible to use a special federation server that interconnects a number of TAK servers with a “star” configuration.

The following diagram shows a simple TAK configuration.

TAK messages flow between clients and servers, noting that for TAK, UDP clients only send messages. Messages may be sent from one client to a single client. More commonly, messages are sent to groups of clients to widely share location and other information.

Operation over HF

The links shown above will operate over IP networks. The solution described here enables one or more of these links to operate over HF using an approach which is transparent to TAK clients and servers. The following diagram shows where this can be provided.

There are two potential places where HF can be used in the TAK architecture, illustrated above:

1. Between a pair of TAK servers. Two example scenarios:
   1. To connect TAK servers on two ships using an HF link.
   2. To connect a field HQ to base, with field clients accessing the server over both UDP and TCP. This can include nodes simply using TAK or CoT to report position.
2. Between a TAK client and server. For example, a mobile TAK client might connect to its server using HF.

The technical solution described next can be applied to either of these scenarios.

The diagram above shows the architecture using the Isode products that support it. This approach uses open standards, so equivalent products could be used. This enables two TAK servers to communicate over HF.

The bottom layer shows Icon-5066, which uses STANAG 5066 as the link layer over HF. This is described in the Isode white paper STANAG 5066: The Standard for Data Applications over HF Radio. Use of STANAG 5066 is important to provide reliability and to enable multiple applications to share the underlying HF infrastructure.

Icon-PEP is an application running over STANAG 5066 that provides a TCP PEP, as described in the Isode white paper Providing TCP Services over HF Radio. The TCP connection from the TAK server or client is terminated at Icon-PEP, and the Icon-PEP servers communicate over HF with the optimized HF-PEP protocol specified in STANAG 5066 Annex X (Ed5 draft). HF-PEP provides:

1. Very efficient use of the underlying STANAG 5066 service.
2. Compression, which is very effective for TAK where messages share common elements.

Isode’s Icon-PEP includes two things which are critical for TAK operation over HF:

1. TLS Proxy. This means that TLS is not used directly over HF. This avoids the overheads and handshaking of TLS and enables compression of stream data. Details in the Isode white paper, Providing TCP Services over HF Radio.
2. HTTP/2 proxy. This enables the TAK S2S protocol to operate efficiently over HF. This proxy handles HTTP/2 heartbeats locally and extends HTTP/2 window size.

A TAK server or client will communicate indirectly with Icon-PEP through an IP router, which will connect to Icon-PEP using GRE (Generic Routing Encapsulation), which is supported by most suitable IP routers. The IP router essentially treats Icon-PEP as an adjacent IP router.

A key benefit of the IP router architecture is that the IP router can be aware of IP routes to the peer. This enables the use of direct IP links when available, with switching to HF when they are not. This is important, as HF will invariably provide a poorer link to direct IP and should only be used when it is the only option.

Chat and XMPP

Chat is an increasingly important capability. TAK clients offer two chat capabilities:

1. Chat using CoT can be used to communicate with other members of a TAK network.
2. Chat using XMPP, which enables communication with a wider set of users.

The built-in chat is supported as part of the core TAK system. XMPP needs additional components to work over HF. A detailed description is provided in the Isode white paper Operating XMPP over HF Radio and Constrained Networks. The summary is that this can be supported by Isode’s M-Link server, which can communicate over STANAG 5066. This provides a good example of the benefits of using STANAG 5066 to multiplex applications.

It can be seen that a TAK client will talk to both a TAK server and an M-Link XMPP server. Both XMPP and TAK traffic is then multiplexed by Icon-5066 over HF.

Performance Measurements

Measurements were made in the lab using the Isode products Icon-PEP and Icon-5066 as illustrated above, with a simulated HF Network provided by Isode’s MoRaSky tool. Two configurations were measured: client/server and server/server.

Speeds for each test: 9600 bps, which is the top speed of narrowband HF, 1200 bps, and 75 bps. All using a short interleaver.

Latency tests were made by measuring the latency between two WinTAK clients for an object location message. The typical size of the CoT XML messages is a few hundred bytes. Latency was measured by sending messages and manually timing.

Traffic was generated using the PyTAK Python TAK library. Measurements were made using standard CoT messages reporting the location of an object. Here is an example:

This is a standard object message, extended sequence and position to facilitate monitoring. The time was current when sent, and the location was generated randomly. On average, messages were 530 bytes.

Client / Server

In this setup, the Icon-PEP chains were inserted between WinTAK clients and the TAK server. The WinTAK connection monitoring was turned off. This WinTAK option generates traffic that makes HF operation not viable.

This test was made between two standard TAK servers, using the built-in client. Icon-PEP was configured as a TLS proxy with HTTP/2 proxy enabled.

These numbers are similar to the client/server numbers but slightly higher. The client/server analysis applies.

The message size for server-to-server communication using gRPC is 376-380 bytes, which is somewhat smaller than the XML Client/Server (530 bytes).  In the table below, effective speed is calculated based on the XML message size.

Potential Optimizations

There are two optimizations that could be made to improve performance:

1. Attribute Thinning. CoT messages are structured as a set of attributes that are sent in each message. Some of these attributes (e.g., OS version; battery level) do not seem operationally critical. It makes sense to allow selected attributes to be stripped and so reduce message size.
2. Latest message only. Messages typically report the location/status of an object and will be repeated at intervals for a moving object. When a queue builds up and there are two messages about the same object, it makes sense to remove the older message from the queue.

These capabilities may be considered for a future version of Icon-PEP.

Conclusions

This paper has shown how TAK can be deployed over HF using STANAG 5066 to enable link sharing. Measurements for Client/Server and Server/Server show that acceptable performance over HF can be achieved, and communication can work down to the lowest HF speeds.