Tactical Data Links: Potential Communication Enhancements
This White Paper looks at Tactical Data Links and sets out some ways to potentially enhance them. Tactical Data Links (TDL), sometimes referenced as Tactical Digital Information Links (TADIL), are a key real time military communication service. TDL is often referenced by one of the many standards used to provide TDL, including Link 11, Link 16, Link 22 and J-Message. This paper starts with a very brief overview of TDLs.
The paper then considers two possible areas for improving TDL operation:
- Use of XMPP (eXtensible Messaging and Presence Protocol) to support TDLs. XMPP is the NATO standard for Chat and Presence.
- Improved HF Radio communication by using the NATO standard STANAG 5066 HF link layer.
Tactical Data Links
The basic concept of TDL is to exchange standardized short messages over a shared communications channel, in particular UHF and HF Radio. A core function is to share location information of friendly and hostile mobile units using information from radar and other sources. This tracking function is central to TDL, and leads to the service being commonly referred to as “tracks”.
TDL systems can be used as three distinct functions:
- Message Format. The base of this is a fixed structure message, although some TDL specifications do much more.
- Message Catalogues. Definitions of messages to support a range of functions, including Precise Participant Location Information (tracking), network management, surveillance, weapons co-ordination, electronic warfare support, status and information management.
- Protocols to operate over the various link types. These are detailed and complex protocol specifications.
TDL Standards and Names Used
TDL is often referenced by the standards used, a this section gives a brief overview. Many of the key TDL specifications are necessarily classified, but there is ample unclassified information to give a clear understanding of TDLs.
- Link 11 is the original TDL which is still in use. TDL was developed in the 1950-60s by Ralph Benjamin at the UK Admiralty Surface Weapons establishment (ASWE). It was subsequently adopted and standardized by NATO. It transfers 24 bit messages in a 30 bit payload, operating over HF and UHF with fixed speed. It can use half duplex transmission between a pair of nodes or a broadcast mode. In half duplex, a “roll call” mechanism from a controlling node allows members of the network to transmit in turn.
- Link 16 is a more modern and sophisticated TDL, primarily used for aeronautical communication. It operates in a specific UHF segment and shares a single fixed frequency channel using TDMA. As well as the basic TDL short structure messages, Link 16 supports other services including voice, text messaging and image transfer.
- J Message or J Series Messages is a widely referenced catalogue of TDL messages. The “J” comes from TADIL-J, which is a version of Link 16. Some other versions are sometimes references in a similar manner (e.g., M Message). J Message gives a clean way to reference TDL messages.
- SIMPLE (Standard Interface for Multiple Platform Link Evaluation) is specified in STANAG 5062. SIMPLE enables transfer of TDL messages over IP. Both SIMPLE and the framework on which it is based appear to be obsolete and JREAP C is preferred in practice.
- JREAP (Joint Range Extension Applications Protocol) provides a means to transfer TDL messages over long distance networks. The core TDL protocols are designed for tactical networks and JREAP enables integration with strategic networks. There are three JREAP variants. JREAP A (half duplex) and JREAP B (duplex) support constrained links. JREAP C provides UDP and TCP mechanisms to operate over IP networks.
- Link 22 is a modern replacement for Link 11 with naval focus. It makes use of Link 16 capabilities so can also be an upgrade path for Link 16 systems. Link 22 was developed by the NATO Improvements to Link 11 (NILE) program and it is commonly referred to as NILE. Key features of Link 22:
- Supports J Messages - compatible with Link 16
- Operates over HF and UHF, fixed speed and fixed frequency.
- Used a Dynamic TDMA (DTMA) approach for members of a network.
- Allows nodes to join a network (late network entry).
- Supports multiple interconnected networks (a Super Network) and relay between networks.
- Messages can be directed to a list of nodes, all nodes on the network, or all nodes on the Super Network
- Error correction
- Resilient to node loss
- Messages have priority.
- Congestion management, giving preference to higher priority messages.
- Message creation time and perishability (when message is no longer valid).
C2 and C4ISR
The broader context for TDLs is Command and Control (C2) which is a part of NATO and national command, control, communication, computers, intelligence, surveillance and reconnaissance (C4ISR)
The other key communication technology for C2 is Message Text Formats, in particular the ADatP-3 format, as part of the APP11 framework. These technologies, alongwith their support by Isode, are discussed in the white paper C2 Systems use of MTF and Messaging.
TDLs are broadly conceived as being used on closed networks with all participating nodes connected to the network. C2 systems will often have broader reach andthe considerations on XMPP relate to supporting C2 systems with nodes beyond the TDL.
XMPP (eXtensible Messaging and Presence Protocol) is the NATO standard for Chat and Presence. This section considers how XMPP could be used to support TDL. For operation over a tactical network it makes sense to utilize optimized TDL protocols. However, TDL information can also be useful in the strategic domain. XMPP provides a flexible high performance mechanism for switching and sharing short messages, which might be useful for TDL services. This section looks at two integration approaches.
Gatewaying TDL and XMPP
Many XMPP services are provided for human users exchanging short text messages, often using Multi-User Chat (MUC) rooms. The first integration approach is to convert between (binary) TDL messages to XMPP text messages. NATO’s experimental work on this approach to integrate between J Messages using JREAP C and XMPP messages led to Isode consideration of XMPP and TDL. The NATO approach is based on the Networked Interoperable Real-time Information Services (NIRIS) service that NATO provides integrating with XMPP. NIRIS is a middleware, which provides situational awareness information to specialised Functional Area Systems.
Some TDL services include free from text messages. It is natural to convert these with XMPP so that TDL users can exchange chat messages with XMPP users and TDL messages can be shared in MUC rooms.
It is also possible to convert TDL messages into human readable representation. This could be of some value to provide easy human monitoring of TDL information. This may be helpful for low volume streams of data which can easily be interpreted by a human. While this approach could be used for application handling of information, the second approach seems preferable.
Using XMPP as a TDL Transport
The second approach is to use XMPP as a mechanism to transport binary TDL messages.XMPP messages are XML stanzas which can carry arbitrary payload and not just text messages. It would be straightforward to encapsulate TDL messages within an XMPP stanza. This complements TDLs using native transport and effectively enables interconnection of TDLs.
The advantage of this encapsulation approach is that any TDL message can be easily carried over XMPP and then extracted to be processed by a system capable of handling TDL messages. This gives a very flexible approach to distributing messages, particularly to include many systems monitoring activity provided with TDL.
The benefits of an approach like this is that it can utilize a distributed messaging infrastructure, which can enable TDL distribution to interested parties that are not directly connected to the TDL network. This can support strategic locations and cross domain access to TDL information.
Another potential benefit of XMPP transport for TDL is that XMPP PubSub could be utilized. In this publish subscribe mechanism, TDL messages would be routed to an XMPP PubSub node. Systems interested in some or all of these messages could subscribe to the node with an appropriate filter, which would enable the node to be sent messages of interest. This provides a flexible mechanism for wide and selective rapid distribution of TDL. The filtering can also be used to constrain traffic on networks of limited bandwidth.
TDL over HF using STANAG 5066
Military applications operating over HF will generally use the STANAG 5066 HF link level protocol. This provides efficient use of the HF layer and enables applications to share an HF link. Isode originally suggested using STANAG 5066 to transport TDL at a presentation to NATO BLOS Technical Group “Using STANAG 5066 to support Tactical Data Links” in August 2016. This paper is restating that thinking.
Why Sharing HF Channel is Good
HF systems are expensive and bulky. HF systems typically operate half duplex, because when a radio is transmitting, the level of RF noise prevents receiving. To operate duplex or to operate multiple HF channels, physical separation is important. On shore this is straightforward, with transmit and receive sites typically located many miles apart. With care, this separation can also be achieved on large mobile units, such as a large ship. For small mobile units this is impractical.
Size and separation requirements mean that in many situations it is desirable to have applications share a single HF channel. STANAG 5066 is designed to support application multiplexing. Link-11 and Link-22 (the two TDL HF specifications) define their own HF link protocols. This means that TDL using the current standards cannot share an HF channel with other applications.
By operating TDL over STANAG 5066, channel sharing would be easy
Mapping TDL onto STANAG 5066
It would be straightforward to define a mechanism to transfer TDL over STANAG 5066. STANAG 5066 specifies how to transport a wide variety of applications and the service needed for TDL is clear.
TDMA vs CSMA and WTRP
There are three broad architectures for data sharing an HF Channel:
- CSMA (Carrier Sense Multiple Access) – specified in STANAG 5066 Annex K
- WTRP (Wireless Token Ring Protocol) – specified in STANAG 5066 Annex L.
- TDMA (Time Division Multiple Access). This is used by Link-22 and Link-11. It has been considered for addition to STANAG 5066.
Use of TDMA, and in particular the robust protocol of Link-22 makes sense for dedicated TDL use of an HF channel. It is a fair and robust protocol.
For general purpose HF, CSMA and WTRP are the best options. This technical view is nicely presented in “IMPACT OF TURNAROUND TIME ON WIRELESS MAC PROTOCOLS” -Eric E. Johnson, Manikanden Balakrishna, and Zibin Tang’ which compares TDMA, CSMA and WTRP. It concludes that CSMA is best for lightly loaded networks and WTRP is best for heavily loaded networks. When sharing a channel with other applications, it would make sense for TDL to use a good general purpose solution.
TDL and Priority
STANAG 5066 allows applications to differentiate based on priority. TDL data is generally needed to be delivered rapidly, so it is likely that it would be assigned a high priority so that TDL data is delivered ahead of applications. This choice and related considerations such as maximum transmission time would depend on the overall application and quality requirements.
HF Surface Wave propagates a long way beyond line of sight, particularly over water. This makes is a useful option for naval task group communication, typically using WTRP to fairly share the channel. This setup usually has good propagation characteristics and it would be natural to share such HF links between TDL and other applications.
Skywave and ALE
HF Skywave provides a more difficult channel. It is often best to work between pairs of nodes and use ALE (Automatic Link Establishment) to select a frequency that works between a pair of nodes. This gives significant advantage over fixed frequency as used by Link-11 and Link-22. Use of ALE will help to give improved connectivity in difficult conditions.
Isode supplies STANAG 5066 products and XMPP products and is a strong advocate of these technologies. This white paper has suggested some approaches using these technologies that Isode believes have potential to usefully improve TDL. Isode does not supply any TDL products, but would be interested to work with partners on the ideas proposed here.