This feature continues the technical description of tactical data links from previous features in ADBR, and addresses the fundamentals of LINK 16 synchronisation 

The need to synchronise intelligence and tactics is key to achieving information advantage and battlefield success in multi-domain operations. While this is driven by doctrine at the strategic level, it is the technologies that we employ at the tactical level that ultimately underpin this success.

Tactical Data Link (TDL) 16 is one of the technologies utilised to provide military intelligence. Link 16 is both the ADF’s and US Department of Defense’s primary TDL, and is essential in enabling secure situational awareness, integrated fire control, and command and control capabilities

Describing the value of Link 16 in Clausewitzian Friction and Future War, Barry D Watts, a senior fellow at the Center for Strategic and Budgetary Assessments (CSBA), draws upon data collected from operational experience during Operation Desert Storm where F-15Cs, aided in most cases by E-3A Airborne Warning and Control Systems (AWACS) aircraft, downed 28 Iraqi fighters without a single loss.

When Link 16-equipped F-15s flew against the same fighter/AWACS combination that had done so well in the Gulf War, the Link 16 ‘information advantage’ enabled them to “dominate opponents by exchange ratios of four-to-one or better”.

Yet in order to achieve the necessary levels of situational awareness, Link 16 platforms first need to achieve synchronisation. So, how is that done?

COMMON TIME REFERENCE
In the January-February 2020 issue of ADBR our Link 16 series of articles began to explore synchronisation and network synchronisation, and the need to know where the 12-second frame begins and ultimately where it ends. Synchronisation is a function of platforms being aligned to a specific Frequency-Hopping Pattern (FHP) and the requirement to utilise a common Network Time Reference (NTR).

This common time reference is provided either by a single platform’s Link 16 terminal, or via an external source, most commonly Coordinated Universal Time (UTC), via satellite. This results in the establishment of either a System Time Reference Network (STRN) or an External Time Reference Network (ETRN). The weakness of an STRN is that only one platform can be the NTR, whereas in an ETRN multiple platforms could be the NTR, as they all derive time from the same source.

At this point it is important to recognise that the role of NTR is a defined Link 16 duty and is allocated as part of the planning process. Secondly, not all platforms are External Time Reference (ETR) capable, but all Link 16 platforms can operate in either an STRN or an ETRN.

It is the allocation of the NTR duty that is important, and this allocation must be carefully managed based upon the type of network in use.

TIME QUALITY
In order to maintain an aligned FHP we need to ensure that all Link 16 platforms have and maintain system time; synchronisation after all is the adjustment of a clock to show the same time as another. Within Link 16 a feature known as Time Quality (Qt) is maintained by every platform to support its own accuracy of time with respect to the common time reference so that, in essence, each platform’s terminal estimates how well it knows system time. It achieves this by building a clock drift model – an assessment of the rate at which their own internal clock drifts by comparison to that of system time.

Qt is expressed as value from 0 to 15, with each value representing the number of nanoseconds’ deviation. A Qt value of 15 is the best and represents a deviation of less than, or equal to, 50 nanoseconds. In an STRN, only the NTR has a Qt of 15 but in an ETRN there could be multiple NTR’s and the Qt of each NTR could actually be lower than 15.

This is because its Qt is based upon its own connectivity with the ETR. A terminal that is ETR capable is provided the time through a continuous stream of precise timing pulses. When an ETR-capable terminal sets NTR it uses those timing pulses to achieve fine synchronisation. The Qt it then transmits is directly related to the accuracy of those timing pulses and, as such, the platforms’ relationship to satellite coverage.

JOINING A LINK 16 NETWORK
The process of synchronisation can be considered as having 4 separate phases

INITIAL NET ENTRY
The single most important role of the NTR is to define network time to enable platforms that wish to join the network (need the time) to achieve Initial Net Entry. To do this the NTR transmits a J0.0 Initial Entry Message (IEM) within the very first time slot every 12-second frame. The J0.0 IEM provides all other platforms what the sender’s Qt is and is the beginning of understanding the actual system time.

When a terminal is set as NTR, the transmission of the IEM is an automatic function. All terminals, except the NTR, are initialised to receive in the very first time slot on the default net, usually Net 0. So, any platform wishing to join a network automatically listens for the IEM. Once a joining platform receives an error-free IEM, its terminal adjusts its time to match that of the NTR and achieves coarse synchronisation.

But what happens when a joining platform is outside of line-of-sight (LoS) of the NTR and cannot receive the IEM?

INITIAL ENTRY JTIDS UNIT
Any platform can support the NTR by setting the terminal to perform the Link 16 duty of Initial Entry JTIDS Unit (IEJU), sometimes called Network Entry Transmit Enable (NETE). Once these platforms have themselves synchronised, they transmit the IEM in exactly the same time slot (TS) but every other 12-second frame. Since an IEJU uses the same TS as the NTR, there is no increase in TS use by having as many such platforms as the network may require.

In today’s Link 16 networks – which may span over a wide geographical area – it is critical for network connectivity, and therefore data exchange, that as many platforms as possible set IEJU to provide system time to those platforms that are beyond LoS of the NTR.

COARSE SYNCHRONISATION
The terminal is now able to receive data from other platforms which are already in the network but cannot transmit data. Although it adjusted its clock to match that of the NTR, it did not allow for the time taken (propagation) for the IEM to travel between its own terminal and that of the NTR; as such, it only knows system time to within one time slot. Once this inaccuracy/error in system time has been removed, the terminal will progress to fine synchronisation. Fine synchronisation can be achieved in two ways, either actively or passively, with the latter being far easier to explain!

ACHIEVING FINE SYNCHRONISATION – BY PASSIVE MEANS
Passive synchronisation is only used by platforms operating in radio silence. Once a joining platform achieves coarse synchronisation it is able to receive data, specifically the reception of other platforms’ Precise Participant Location and Identification (PPLI) data pivotal to the synchronisation process.

This PPLI data provides the geographical position and quality of the sender, but importantly it also provides Qt. Using the PPLI data being received along with its own position, the joining platform’s terminal can estimate the range between itself and other active platforms and thus the time taken (propagation). Simply put, it compares the expected time of arrival with the actual time of arrival.

Finally, by combining all the information, notably the Qt being received, the joining platform’s terminal can adjust its estimate of system time by removing any propagation error, subsequently achieving fine synchronisation.

ACHIEVING FINE SYNCHRONISATION – BY ACTIVE MEANS
As described earlier, once a joining platform’s terminal achieves coarse synchronisation it is able to receive data, notably PPLI data which includes Qt. The joining platform’s terminal stores and monitors this data in its internal table and is able to evaluate which platforms have the highest Qt.

Active synchronisation involves a joining platform terminal transmitting a Round Trip Timing-Interrogation (RTT-I)message and hoping that an already active terminal replies, otherwise known as RTT-R. This reply uses the same TS. RTT messages can be exchanged in one of two modes, RTT-Addressed (RTT-A) or RTT-Broadcast (RTT-B).

ROUND TRIP TIMING-ADDRESSED
Although RTT-A is an active synchronisation mode, it is arguably no longer employed. RTT-A requires that every platform in the network is allocated its own Time Slot (TS) through the network design process to transmit an RTT-I message. In today’s oversubscribed and congested Link 16 networks, this is simply an inefficient use of TS.

During RTT-A, a joining platform terminal transmits an RTT-I to the platform with the highest Qt it holds in its internal table, ie it is addressed to a specific Link 16 unit (JU). To achieve fine synchronisation, the joining platform needs the platform being addressed to provide an RTT-Reply. If no reply is received, the joining platform simply transmits an RTT-I to the next JU with the highest Qt. The detailed information in both the RTT-I and RTT-R is used by the joining platform to adjust its system time by removing any error to achieve fine synchronisation. Figure 2 explains the RTT-A synchronisation mode.

ROUND TRIP TIMING-BROADCAST
RTT-B usually requires no more than eight time slots which all platforms in the network share – hence it is far more efficient. When using RTT-B, the RTT process and calculations are the same as described above. The difference is that, having determined which JU has the highest Qt, the joining platform transmits its RTT-I on the net whose number is equal to the highest observed Qt using the broadcast address. Platforms which have achieved fine synchronisation, when not transmitting their own RTT-I messages used to maintain their Qt, listen for RTT-Interrogations on the net number equal to their own Qt, and reply to them on that net number. A joining platform does not care which platform replies as long as one does. RTT-B operates in a form of stacked net system using net numbers 1 to 15. Figure 3 explains the RTT-B synchronisation mode.

MAINTENANCE
Once in fine synchronisation all platforms terminals then maintain how accurate they know system time by transmitting RTT messages every minute, and also measure the time of arrival of all other messages they receive to build what we now know as the clock drift model. Using the accuracy with which platform terminals reply to RTT-I messages and their estimate of system time, plus the time since the last RTT-R was received, enables a platform to set its own Qt.

If a platform later loses LoS with all other platforms in the network, it uses this clock drift model to adjust its own clock. By so doing a terminal can maintain synchronisation with the network for many hours, but its Qt will slowly degrade once RTT responses are no longer received. The great advantage of ETR-capable platforms operating in an ETRN, is that they can maintain fine synchronisation by directly observing the ETR precise timing pulses. Of course, some platforms may experience poor satellite coverage and, consequently, their Qt could decrease. But as all platforms perform the RTT process they can use this source, ensuring the best of both worlds.

Ultimately, it does not matter if it is an STRN or ETRN, as all Link 16 platforms need the time to synchronise. Figure 4 summarises the full Link 16 synchronisation process.

INFORMATION ADVANTAGE
Emerging US doctrine describes Information Advantage as “The application of information capabilities, including space, cyberspace, EMS, and influence, resulting in comparative advantage to support all-domain operations. It includes intense targeting of adversary command and control and intelligence, surveillance, reconnaissance, and targeting.”

The need to synchronise intelligence and tactics is key to achieving information advantage and battlefield success in multi-domain operations. At the technical level this involves fine synchronisation of the Link 16 TDL.