During the late 1980s, NATO, agreeing on the need to improve the performance of Link 11, produced a mission need statement that became the basis for the establishment of the NATO Improved Link Eleven (NILE) Program. The program specified a new tactical message standard in the NATO STANdardization AGreement [STANAG 5522] to enhance data exchange and provide a new layered communications architecture. This new data link was designated Link 22.
The Link 22 program was initially conducted collaboratively by seven nations under the aegis of a Memorandum Of Understanding (MOU). The original seven nations were Canada, France, Germany, Italy, the Netherlands, the United Kingdom (UK), and the United States (US), with the US acting as the host nation. Spain has replaced the Netherlands as a NILE nation.
A steering committee guides the complete program. The program is managed by the Project Management Office (PMO), located at the Space and Naval Warfare Command (SPAWAR)'s Program Management Warfare (PMW) 150 in San Diego, California. The PMO consists of a representative from each participating nation and a Project Manager from the US.
The Link 22 goals are
The Link 22 system is centered around its core component, the System Network Controller (SNC). This software exists as a single implementation, produced by the NILE PMO and owned by the NILE nations. To ensure compatibility across Link 22 implementations, all participants must use this SNC software. Each implementing nation will acquire this software and will implement it in a hardware environment suitable for its own application. Therefor the SNC is not available as commercial product and is applied by NILE PMO to NILE agreed Third-Party Sales nations at annual maintenance fee.
An excellent overview and introduction to Link 22 provides the "Link 22 Guidebook" published by the NILE PMO in July 2009. This Guidebook has been written in a manner that provides suitable information for Link 22 operators, planners, managers, executives, developers, and testers. Given below is an abstract of chapter 1 of the Link 22 Guidebook. The other chapters 2-3 of the Link 22 Guidebook are only available to NILE and Third-Party Sales nations.
Chapter 1 should be read by managers, procurers, and anyone who is new to Link 22.
Chapter 2 should be read by planners, operators, and technicians (those in charge of hardware configurations).
Chapter 3 should be read by implementers, integrators, testers, and software engineers.
Link 22 is a North Atlantic Treaty Organization (NATO) secure radio system that provides Beyond Line-Of-Sight (BLOS) communications. It interconnects air, surface, subsurface, and ground-based tactical data systems, and it is used for the exchange of tactical data among the military units of the participating nations. Link 22 will be deployed in peacetime, crisis, and war to support NATO and Allied warfare taskings.
The Link 22 Program was initially conducted collaboratively by seven nations under the aegis of a Memorandum Of Understanding (MOU). The original seven nations were Canada, France, Germany, Italy, the Netherlands, the United Kingdom (UK), and the United States (US), with the US acting as the host nation. Spain has replaced the Netherlands as a NILE (NATO Improved Link Eleven) Nation.
Link 22 was developed to replace and overcome the known deficiencies of Link 11. Link 22 was also designed to complement and interoperate easily with Link 16. It was designed with automated and simple management to ensure that it is easier to manage than both Link 11 and Link 16. This program is called “NATO Improved Link Eleven”, which is abbreviated to “NILE”. The tactical data link provided by the NILE system has been officially designated Link 22.
Link 22 employs a strong COMmunications SECurity (COMSEC) system, which is provided by the inclusion of an integral encryption/decryption device inside the Link 22 system. This cryptographic device (crypto) at the data link level is called the Link Level COMSEC (LLC). Link 22 transmission security is also available by the optional use of frequency hopping radios.
Tactical data is transmitted on Link 22 in fixed format messages, which are part of the J-Series family of messages. It uses the same field definitions as Link 16 to provide standardization between the two tactical data links. Many of the Link 16 tactical messages are transmitted without modification within Link 22 tactical messages. Link 22 specific messages are more efficient versions of Link 16 messages and therefore use less Bandwidth (signal processing). Link 22 provides a number of Quality of Service (QoS) features, which are specified with each transmission request. Among other features, the selection of messages for transmission is based on the priority and the QoS of each message, which provides better use of available resources based on the operational situation.
An operational Link 22 system is called a Link 22 Super Network. In its simplest form, a Link 22 Super Network consists of just two units communicating with each other in a single NILE Network. The most complex Link 22 Super Network would consist of the maximum number of units (125) with eight NILE Networks. A unit participating within the Link 22 Super Network can be a member of up to four of the NILE Networks. A more complex Super Network is shown below.
A Super Network enables seamless communication between units using different media to satisfy operational requirements within prevailing media radio propagation conditions. In a Super Network, any NILE unit can communicate with all other NILE units without regard to the NILE Network in which they are participating, thereby extending the operational theater. When a unit retransmits a message to extend coverage this is called relay, which is an automatic function of Link 22.
Coverage beyond what the media itself is capable of is provided by the automatic relay of messages and the ability to adapt to changes automatically, without operator intervention. This removes the need for dedicated air relay platforms and relay slot planning and management. A unit will automatically retransmit a received message when necessary to ensure that the message is received by its addressees. The System Network Controller (SNC) calculates whether the relay is necessary, based on its knowledge of the connectivity among units. The ability of a unit to relay can be affected by its relay setting. This setting’s default is automatic relay, but the unit can be disabled from performing relay or designated as a preferred relayer. Relay is performed on a per message basis. Because messages are retransmitted only when necessary, this reduces the use of bandwidth.
Each NILE Network can employ either High Frequency (HF) or Ultra High Frequency (UHF) communications.
HF communications are in the 2-30 MHz band, which provides Beyond Line-Of-Sight (BLOS) communication (HF Sky Wave or HF Ground Wave) optimized for (but not limited to) transmission up to 300 nautical miles (560 km). HF also provides direct Line-Of-Sight (LOS) communications.
UHF communications are in the 225-400 MHz band, which provides only LOS communication.
Within each band, either fixed frequency or frequency hopping radios can be used. Greater coverage is provided by the automatic relay of messages within the Link 22 system as previously mentioned.
Link 22 has better tactical data throughput than Link 11, and it can even work in conditions where Link 11 will not. When conditions are bad, Link 22 can use more robust media parameters and maintain communication, although at a lower data rate than usual. When conditions are good, Link 22 can optimize the media parameters to maximize its data throughput. For example, specific media parameters were designed to operate in high latitudes, which present some of the worst-case conditions, and where Link 11 rarely operates.
Link 22 uses distributed protocols, so it has no single point of failure (that is, the loss of a single unit does not cause the loss of an entire network). Some units perform specific management roles, but the system will continue operating without them. Each unit that performs a special role is required to designate a Standby unit, which can automatically take over the role in case of failure.
Link 22 has automated Network Management functions that require a minimum of operator interaction, if any. These functions are controlled by the transmission of Network Management messages. Each unit can define whether or not to automatically respond to, and whether or not to automatically perform, each of the Network Management functions.
Time Division Multiple Access (TDMA) is the method by which the transmission capacity available to the entire network is distributed among its members. A cyclical period of time is divided up into timeslots, which can be of different durations. Most timeslots are allocated to specific units in the network. A unit transmits during its own timeslots. All other units listen during this period, and they may or may not receive the transmission. Priority Injection timeslots may be available, which can reduce the length of time a unit has to wait before it is able to transmit high-priority messages. If multiple units transmit in a Priority Injection timeslot at the same time, the transmission may not be received. Because of this, the transmission is also repeated in the units’ own timeslot.
At the tactical level, when a unit is congested, it can reduce the local traffic that it generates based on the provided congestion information. In addition, Link 22 automates Congestion Management in a number of different ways. The routing of messages takes congestion into account and will route messages using alternative paths to reduce congestion. Link 22 has a Dynamic TDMA (DTDMA) protocol which, when enabled on a NILE Network, allow congested units to automatically request and receive additional capacity on a permanent or temporary basis (thereby modifying the TDMA structure). If DTDMA does not achieve the desired result, the unit managing a NILE Network can change the configuration of the network to redistribute the available capacity, or change the parameters of the media in use in an attempt to increase the network’s capacity. As a last resort, a unit can interact with the operator to decide which, if any, of the tactical messages received and queued for relay may be deleted.
After the Super Network has been started, units that arrive late can join the tactical data link by initiating a protocol called Late Network Entry (LNE). The system also supports units that just want to listen to a network, called receive-only units, which have the capability to request access to the network, but are not allocated any transmission capacity. In addition, the system also supports units that only want to listen to a network without performing any transmissions at all (silent join units).
Link 22 has extensive test facilities available for both compatibility and interoperability testing.
The compatibility test system is called the NILE Reference System (NRS), which was developed to test the System Network Controller (SNC) and ensure that all modifications to the SNC meet and continue to meet the Link 22 requirements. It can also be used to test the other components of the Link 22 system, such as the LLC and SPCs/Radios.
The interoperability test system is called the Multiple Link System Test & Training Tool (MLST3) which was extended to incorporate Link 22 and has multiple configurations available for testing.
This section covers the following Link 22 main features.
The design of Link 22 uses a layered communications stack approach to produce an open system architecture, with well defined interfaces between the subcomponents.
The approach maximizes extensions and enables contributions from multiple providers.
The inner grey box in the figure indicates the NILE Communications Equipment (NCE) components. These components are the following.
The Link 22 system, shown by the outer green box in the figure, consists of the NCE and the Link 22 portion of the Data Link Processor (DLP). Within the DLP, this consists of the interface to the SNC and the handling of the tactical messages that it transmits and receives on the data link. The tactical messages are defined in the NATO STANdardization AGreement STANAG 5522]. The DLP is connected to, or is part of, the Tactical Data System (TDS), also known as Host System of the NILE unit, which processes the received tactical messages and generates tactical messages for transmission in accordance with the unit’s national requirements.
All NILE system components have been jointly defined and designed. The SNC and LLC subsystems have been commonly developed. The development of all other Link 22 subsystems is a national or manufacturer’s responsibility.
The LLC uses a weekly key to encrypt and decrypt the data traffic that passes through it. Two sets of keys can be loaded into the device, enabling it to operate up to 14 days without any operator intervention. The next week’s key can be loaded at any time during the current week. Detailed information on the crypto key management is contained in the Crypto Key Management Plan document.
Transmission security is provided when frequency hopping radios are used. The system is capable of using frequency hopping radios in both the HF and UHF bands.
Tactical Messages within Link 22 are handled as sealed envelopes and the system works without access to the tactical data contents. This provides the possibility to encrypt the tactical data at the top level and still be able to transmit it. This additional level of security cannot be provided by Link 16 as the terminal must retain access to the tactical data being transmitted.
Link 22 transmits tactical data in fixed format messages, and uses the same data element definitions as Link 16. This provides standardization between the two tactical data links. Tactical messages are composed of from one to eight Tactical Message Words (TMWs). Each TMW is 72 bits in length. Link 22 messages are called F-Series messages and are part of the J-Family of messages. The F-Series consists of two types of messages, the Unique F messages and the FJ messages. The Unique F-Series messages are more compact versions of Link 16’s messages, or messages that do not exist in Link 16. The FJ messages encapsulate Link 16 J-Series messages within Link 22 messages, enabling Link 16 tactical messages to be transmitted without modification within Link 22. The DLP requests transmission of a Link 22 tactical message with a Transmission Service Request (TSR). Each request for transmission utilizes a unique identifier and defines the required Quality of Service (QoS). The DLP creates the Link 22 tactical messages from tactical data and the defined transmission requirements of [ STANAG 5522 ]. Alternatively, the tactical messages may be created by the TDS and then passed to the DLP. The DLP, however, is the component responsible for passing all Link 22 tactical messages to be transmitted to the NCE. Likewise, the DLP is the destination for all tactical messages received by the NCE. The DLP may perform limited processing of the received tactical messages or may simply pass them on to the TDS for processing. Each message, as mentioned above, can be defined with different QoS. The DLP performs other tactical functions, such as track management, correlation, reporting responsibility, conflict resolution, data filtering, and data forwarding [ STANAG 5616 Volumes II ] and [STANAG 5616 Volumes III ]. These functions are a national responsibility, and they may be performed either by the DLP or the TDS. The DLP can perform minimal tactical message processing, or it can be a complete multilink Command and Control (C2) system.
Link 22 provides a number of QoS features that are specified in the TSR. These features enable the efficient use of available resources. QoS features include the following.
Link 22 provides four levels of Priority (1-4), where priority 1 is the highest and 4 is the lowest. Priority 1 requests can also utilize the Priority Injection Indicator Flag, which has the effect of increasing the priority by moving the request to the top of the priority 1 queue and eligible for early additional transmission in a Priority Injection timeslot, if available. TSRs are considered during packing for transmission in a timeslot in highest priority, oldest TSR order.
The required reliability of the destination unit receiving the message is included with each tactical message to be transmitted. Three levels of reliability are provided: Standard Reliability has an 80 percent probability of reception, High Reliability has a 90 percent probability of reception, and there is also a Guaranteed Delivery protocol. The probability of reception requested is used to calculate how many repeat transmissions are made. Reliability Protocols remove the need for redundant transmissions by the DLP. The Guaranteed Delivery protocol minimizes the repetition of transmission based on the acknowledgements received.
The originator of the data to be transmitted is provided in the TSR. The Link 22 system ensures that this Data Originator Identification is delivered along with the data, so that any unit receiving it knows which unit originated the data regardless of its route through the system.
Four levels of message perishability are provided by the system, and the TSR specifies which level applies to the data to be transmitted. Perishability allows the definition of how old the data can be before it is no longer relevant, and the Link 22 system ensures that data that has perished is not transmitted.
There are two indicator flags.
Two different Addressing services are provided, with and without Acknowledgement, which can usually be used at the same time. For both of these services, there are five types of addressing available.
Link 22 requires each unit to initialize with the same fundamental parameters as all other units. This is fundamental to the operation of the system. It significantly reduces the amount of configuration data to be distributed by the system. These fundamental parameters are supplied to each unit in the Operational Tasking (OPTASK) Link Message (OLM), which is provided to the TDS. The fundamental parameters must be supplied to the SNC by the DLP during SNC initialization. This data is maintained within the SNC and is referred to as the Super Network (SN) Directory. The generation of the OLM is performed by network planners, who take into account many pieces of information, such as the location of the operations, how many units are expected to participate, the expected tactical message throughput of each unit, and so on. The planners also consider which other tactical data links will be involved. They understand the complete communications infrastructure and define where and how Link 22 is to be used.
Media using High Frequency (HF) in the 2-30 MHz band provides Beyond Line-of-Sight (BLOS) communications, optimized for (but not limited to) transmission up to 300 nautical miles (560 km). Media using Ultra High Frequency (UHF) in the 225-400 MHz band provides Line-of-Sight communications only. Within both bands, either fixed frequency or frequency hopping radios may be employed, for a total of four different media types.
Each media has one or more different settings, which use different modulation and encoding schemes. Along with the fragmentation rate, these factors determine the number of bits per network packet that are available for transmission, which ranges between 96 and 1824 bits, as can be seen in the following table. The duration of a UHF Frequency Hopping Media Coding Frame is a classified number, and is shown by the notation “<CN>” in the table.
| Media Type | Media Coding Frame (ms) |
Media Settings |
Fragmentation Rate |
Network Packet Size (bits) |
|---|---|---|---|---|
| HF Fixed Frequency |
|
|
|
|
| HF Frequency Hopping |
|
|
|
|
| UHF Fixed Frequency |
|
|
|
|
| UHF Frequency Hopping |
|
|
|
|
The Network Cycle Structure (NCS) defines the TDMA protocol for each NILE Network. Time is divided into fixed length periods called minislots, the duration of which varies according to the media type. Periods of time called timeslots are an integer number of minislots, which may be of different size within specific limits. A timeslot is either allocated to a specific NILE unit, or is a Priority Injection timeslot. A unit may only transmit in its allocated timeslot(s), or for certain high-priority messages it may also transmit them in a Priority Injection timeslot. This ensures that each unit has an opportunity to transmit at least once within a given period of time, called the Network Cycle Time (NCT).
The NCT is the number of minislots that form the network cycle (sum of the length of all timeslots). The NCT in the above figure is 40 minislots; however, this can vary up to a maximum of 1024.
When a network is operational the NCS is referred to as the Operational NCS (ONCS). Link 22 has the ability to modify the ONCS. This capability is called Dynamic TDMA (DTDMA). The SNC can also modify the ONCS by supplying a new one.
An NCS can be defined by the planners in the OLM. The planners take into account how many tactical messages per second a unit will need to transmit (Capacity Need), including relay traffic, and how long it can wait between transmissions (Access Delay). When the NCS is defined in the OLM, the DLP will initialize the network with the supplied NCS, which will then become the Operational NCS.
The SNC can also compute an NCS, in which case the Capacity Need and Access Delay of each unit in the network must be supplied. The SNC also uses two other parameters (Tolerance and Efficiency) in its computation, which enables the generation of an optimized NCS that does not meet all the input Capacity Need and Access Delay when it is physically impossible to do so.
Media types, media setting, and fragmentation rates all affect the size of timeslots in an NCS.
Every unit in the Link 22 Super Network uses the same Fundamental Link 22 Parameters to perform initialization. These parameters are specified in the OLM. This significantly reduces the volume of configuration data that needs to be distributed by the system. In fact, Link 22 can be initialized and can transmit tactical messages on a NILE Network at the instant the network is to start, with no prior communications on the network required.
Initialization consists of the following two parts.
The Link 22 unit’s subsystems must be initialized first, before it can initialize any networks. Hardware configuration information must be supplied to the SNC by the DLP. The DLP also must supply the Fundamental Link 22 Parameters so that the SNC can initialize its internal data.
When SNC Initialization is complete, the DLP can begin to initialize the individual NILE Networks. The OLM can specify one of the two types of initialization; either quick initialization (known as Short Network Initialization) or an initialization that requires probing of the environmental condition before allowing for tactical traffic to be generated (known as Initialization with Probing). Short Network Initialization can use an NCS defined in the OLM or let the SNC calculate the NCS based on the Capacity Need and Access Delay parameters described above.
If the unit has missed the start time for the network initialization, it should join the network by performing the Late Network Entry (LNE) protocol. Late Network Entry (LNE) provides the unit with the current parameters, which may have changed since the network was initialized.
Link 22 was designed, using lessons learnt from Link 16 experience, to operate with automated and simple management. The result is that it is significantly easier to plan and operate than either Link 11 or Link 16.
Link 22 has automated Network Management functions that require a minimum of operator interaction, if any. These functions are controlled by the transmission of Network Management messages. Each unit can define whether or not to automatically respond to, and whether or not to automatically perform, each of the Network Management functions.
Link 22 specifies two network management roles. For each role, a standby unit automatically takes over the role if the unit performing or assigned that role fails. The new management unit immediately nominates a new standby unit. The system will therefore continue operation without the presence of units originally nominated to perform these management roles, and will operate even if no units are performing the roles. After the Link 22 system has started, the Super Network Management Unit (SNMU) has overall management responsibility for the entire Super Network. The Network Management Units (NMUs) have management responsibility only for their particular NILE Network. The SNMU can order the NMUs to perform their network management functions. The SNMU can be the NMU for the networks that it is active on. A NMU may be the NMU of more than one network.
The SNMU and, in some cases the NMU, can order certain management changes to the Link 22 system, including the following.
Other management functions do not require the use of an order, but do require transmission of a message to initiate the change.
A unit that arrives after the Super Network has been started can still join by initiating the Late Network Entry (LNE) protocol. This protocol provides the unit with the most current parameters necessary to join the network. The protocol is initiated by the operator and is usually fully automatic, with the protocol’s progress available to the operator. A NILE unit may join a network in one of the following three ways.
The Link 22 system is designed to be resilient. If faults occur, it manages them and attempts to continue operating. A unit participating on multiple NILE Networks can have a failure on one network while continuing to operate on the other networks. A unit is able to handle the closure or shutdown of a network and the restart of the network after the hardware has been reset, without affecting the other networks. When the connectivity changes, possibly due to the loss of a unit or the failure of equipment, the relay automatically takes this into account and modifies message routing in an attempt to maintain the probability that messages get to their addressees. Link 22 automatically retransmits messages to ensure that the requested quality of service (Reliability) is achieved whenever possible. This removes the need for the DLP to perform redundant transmissions and minimizes bandwidth utilization. Retransmissions are always placed in different packets on the network so that the loss of a single packet cannot cause the loss of all repeated transmissions. The transmission on the NILE Networks is controlled by the TDMA structure, which is known to each unit, so the loss of any unit does not affect the ability of the remaining units to continue operation. Virtually all functions work in this manner (called distributed protocols), so there is no single point of failure. Some units perform special roles, but the loss of these units is not disastrous to the operation of Link 22. Any unit that is performing one of the special roles must ensure that it always has a standby unit available to take over the role in case the unit is lost or its Link 22 system fails. A Standby that takes over a role must ensure that a new standby is defined. Messages are exchanged between units, and the loss of reception from the role unit will cause its standby to activate the Role Takeover protocol. Similarly, if the role unit loses reception from its standby, it will give the standby role to another unit. Troubleshooting at the unit, network, or Super Network level is enabled by the reporting of monitoring and statistical data. Each unit’s SNC also validates all message data sent to it by the DLP before processing the message, and reports success or failure of each message back to the DLP. If the validation fails, the SNC also provides details of why the message failed validation.
Congestion Management is performed automatically in a number of ways. Message routing will use alternative paths to minimize congestion. When Dynamic TDMA (DTDMA) is enabled, a unit that is not congested can donate spare transmission capacity to a congested unit. This affects the allocation of timeslots within the ONCS, but does not affect the NCT. All of this occurs automatically, with no operator or DLP actions required. The NMU can change the ONCS to redistribute capacity. This function, called Network Reconfiguration, causes little or no network interruption. The NMU provides or causes the SNC to generate a new NCS, which can have a different NCT. On successful reconfiguration the NCS becomes the new ONCS. Media parameters can be modified by the NMU in an attempt to increase the available capacity of the network. This requires the network to be temporarily paused and reinitialized with new parameters, which causes a minor interruption of network operations. This procedure is called Network Re-Initialization. The NMU can optionally provide or causes the SNC to generate a new NCS, which can have a different NCT. On successful Re-Initialization the NCS becomes the new ONCS. Unit congestion arises from two sources: the messages the DLP requests to be transmitted, and the messages received from other units that must be relayed to ensure that the messages are received by their addressees. The DLP has full control over messages it has requested to be transmitted. The DLP could delete selected requests to reduce the congestion, and it could reduce the rate of transmission requests. Tactical messages that are being relayed are normally not under control of the DLP. In cases of high congestion, however, the DLP can be informed of the relay messages and decide whether it wants to delete any. This last resort reduces the congestion, but it also affects the delivery of messages. This decision process is called Relay Flow Control.
Link 11 is an old tactical data link that does not offer the capabilities and performance required by today’s operational community. Link 16 is a complex and robust tactical data link that attempts to meet current operational requirements but is still reasonably old technology. It does not offer recently derived operational concepts, requires extensive planning and is difficult to manage. Link 22 offers the latest technology and uses COTS products. It provides a simple-to-use, sophisticated suite of functions that require minimal operator interaction, and that enable it to be used as both an excellent stand-alone tactical data link or in a complementary role with Link 16. Link 22 significantly enhances NATO tactical data link capabilities and meets today’s increasing need for successful interoperability within allied operations.
Link 11 has been in existence since the mid-1950s. It was conceived to support small numbers of units performing mainly an Anti-Air Warfare (AAW) role on a single network. In normal use (Roll Call) a Link 11 network is controlled by a Net Control Station, which polls each unit in turn to request a transmission. When each unit is polled, it transmits its data without prioritizing the data, so no unit can be polled until the current transmitting unit completes its transmissions. A unit cannot transmit until it is polled. Link 22 was designed primarily as a maritime tactical data link for anti-surface and subsurface warfare, although, like Link 16, it supports all battle environments. A comparison of Link 11 to Link 22 follows.
Roll Call Transmission allocation. Increased net cycle times due to increasing numbers of Participating Units (PUs) and tracks. Large access delay Uses TDMA which provides deterministic access to the network. Prioritization of messages ensures most important are transmitted before less important No way to transmit urgent information The use of Priority Injection timeslots in the TDMA structure can be used to minimize the delay in the transmission of urgent information Limited number of participants (62) More units (125) A restrictive “playing area” based on the ranges of individual platforms, and more importantly, on its method of reporting its position, and that of its tracks, based on its distance from a Data Link Reference Point (DLRP). These factors limit the use of Link 11 in extended areas of responsibility, and also prevent polar operations Uses the Worldwide Geodetic System (WGS-84), same as Link 16, so no limitation. Each NILE unit can operate simultaneously on up to four networks; a Super Network can be composed of up to 8 networks. This flexibility greatly increases the playing area Link 11 Link 22 All units have to be in RF connectivity with the Net Control Station, again limits the area of operation The use of routing & relay protocols greatly increases the playing area, even when using line-of-sight UHF. Relatively easy to spoof because of weaknesses in the security of the system More difficult to spoof, and any attempts to spoof are easier to detect, due to features such as time based encryption Relatively easy to jam a single HF or UHF fixed frequency network A single HF or UHF fixed frequency network can still be jammed, however with multiple networks it is more difficult to jam all at the same time. The use of frequency hopping media makes it significantly more difficult to jam The encryption level is not sufficient for the processing power of modern computers Uses same crypto chip as Link 16. Crypto technology is being updated to meet future requirements The loss of the Net Control Station will cause the network to collapse Does not use a Net Control Station. Designed with no single point of failure The accuracy of Link 11’s M-Series messages is inadequate for modern targeting Data items are designed with improved ranges and granularity using same data dictionary as Link 16 Available waveforms limit communications under bad RF conditions (as occur in polar regions) A variety of more robust waveforms. In bad conditions strong coding can be used to maintain communication at the expense of throughput M-Series messages difficult to translate making data forwarding between links complex Link 22 is part of the J-Series family of messages, uses the same data dictionary as Link 16 and so makes translation and forwarding relatively easy compared to Link 11 Limited Bandwidth (1,800 bit/s for fast and 1,090 bit/s for slow) Range of bandwidths available depending on coding and media for example fixed frequency: HF 1,493 – 4,053 bit/s UHF 12,666 bit/s
Although it supports all Environment types, Link 16 is primarily an anti-air warfare (AAW) tactical data link. Link 22 is primarily a maritime tactical data link designed to complement Link 16 operations.
The raw (maximum) data rates shown in the figures are what is available for Tactical Data transmission, after the low level overheads (Error Detection And Correction (EDAC) bits, synchronization bits, etc.) have been taken into consideration.
| Link 11 HF/UHF |
Link 22 HF (fixed frequency) |
Link 22 UHF (fixed frequency) |
Link 16 JTIDS |
|---|---|---|---|
| 1090 or 1800 |
|
|
26.880 – 107.520 |
Link 22, unlike Link 11, can perform simultaneous different transmission on up to 4 networks, which increases bandwidth. Two typical configurations are shown below.
| 3 HF AND 1 UHF (fixed frequency) |
2 HF AND 2 UHF (fixed frequency) |
|---|---|
|
|
|
Link 22 complements Link 16 by providing additional bandwidth in other frequency ranges and in particular by providing the BLOS and automatic relay capabilities.
It can be seen from the Link 22 architecture that the following components need to be acquired to add the Link 22 capability to a platform.
Each listed item will be discussed further. Logistics spares also need to be acquired to provide an adequate level of cover in case of unit failure.
The Data Link Processor (DLP) is connected to, or is part of, the Tactical Data System (TDS) of the NILE unit. The DLP processes the received tactical messages and generates tactical messages for transmission in accordance with the unit’s national requirements. If Link 22 is to be added to an existing operator interface or TDS, it may be possible to incorporate the Link 22 TDS/DLP functions within the existing system; otherwise, a new processor will be required to run the functions. However, if the existing system has spare link interfaces, it may be possible to connect Link 22 to the existing system using a spare link interface. In this case, a gateway system that converts from the existing link format to Link 22 would need to be purchased.
The SNC software requires a computer processor to execute the code. This would usually be Personal Computer (PC) type hardware, either running Windows XP or Linux operating systems. The SNC software is written in Ada 95 and is easily portable to other platforms as long as there is an Ada 95 compliant compiler available on the platform. The computer does not require significant processor power and any available current technology processor is sufficient. As a guide, a 1 GHz processor with one GByte of memory is more than adequate. The processor needs to support at least one Ethernet connection (preferably 100 Mbit/s) but, depending on the configuration, two may be required. The processor requires some storage for the operating system, the SNC executable and the TOD interface software. Possible configurations include a VME backplane enclosure with power supply and a VME processor card, or a rack mountable industrial PC.
A single LLC can handle multiple networks depending on the type of media. The system can use a maximum of four LLCs which would be one LLC per network, but this would be an unusual configuration. A typical system will employ one LLC when up to four HF, or two UHF or one UHF and three HF networks are deployed. If more than two UHF Networks are deployed, two LLCs are needed. Associated with the LLC and its key loading, a Data Terminal Device (DTD), which is used to load the keys into the LLC, would need to be acquired from the national crypto agency. Depending on the method of key distribution employed, a paper tape reader KOI-18 may also be required. It is possible to distribute encrypted keys as PC files, in which case a special serial cable would be required to load the file from a PC into the DTD. The current LLC is a 19” rack mountable unit. The manufacturer refers to the LLC as the KIV-21/LLC.
An SPC is required for each network/media that the unit is required to operate on. A single SPC may be configured to use different media. An SPC hardware unit may contain more than one SPC. At the time this book was written, there were three manufacturers of SPCs, which all supported HF and UHF Fixed Frequency media. Frequency hopping media is also supported either within a separate SPC or embedded within a frequency hopping radio. The fixed frequency HF and UHF SPCs were available in 19” rack mountable chassis, with two of them containing VME cards which could be mounted in a suitably configured VME backplane. Radio frequency and power control by the SPC is optional. Refer to the SPC manufacturers’ specifications to determine the options that are available with the supported radios.
The appropriate radio system is required for each of the media types that will be used, and consists of the following.
The radio, power amplifier and power supply may be a single unit depending on the output power required. The higher the output power the more likely that separate units will be needed. One of the goals of the NILE program was to be able to reuse existing modern Link 11 radios and antennas equipment. If they are any available this would reduces the equipment that must be acquired.
Link 22 needs to be supplied with coordinated universal time (UTC) which, if not already available on the platform, must be acquired. The TOD must be supplied to the DLP, SNC, SPCs and frequency hopping radios, if equipped. The recommended TOD input to the SPCs is the Extended Have Quick format as defined in [ STANAG 4430 ]. The SNC is delivered with a separate application (Read TOD) that accepts a Brandywine Serial 485 and 1 pulse per second (pps) input in compliance with [ STANAG 4430 ]. The Read TOD can be customized to supply the SNC with the appropriate time as detailed in section 3 of the [ NRS IDD ]. The TDS may also require an accurate time to guarantee synchronization among all the subsystems. If a more accurate source is not available, the Global Positioning System (GPS) may be used. GPS-based TOD hardware normally consists of the following:
The equipment needs to be housed in suitable enclosures appropriate to the environment in which the equipment is to be installed. Whether installed in single or multiple enclosures will depend on the site and the way that communications equipment is usually configured on that platform. Each set of equipment will require power and appropriate allowance for cooling. The components of the Link 22 architecture have to be inter-connected via appropriate cabling and communications devices. The DLP-to-SNC interface and the SNC-to-LLC interface both use Transmission Control Protocol / Internet Protocol (TCP/IP). If TCP/IP is communicating within a processor, no cabling is required for the interface, which would be the case if the DLP and SNC were running on the same processor. When on separate equipment or processors, TCP/IP can use many types of network interfaces. The LLC interface uses Ethernet and so the SNC-to-LLC interface has to be Ethernet. Two Ethernet ports can be joined together with a simple cross-over Ethernet cable (point-to-point), or joined together using an Ethernet hub or switch. The use of an Ethernet hub is recommended to allow for monitoring of the interface. If the SNC host processor only has one Ethernet port then a single hub could be used for both the DLP-to-SNC and the one or more SNC-to-LLC interfaces. The LLC is connected to the SPC via RS-422 serial cable. The SPC is connected to its radio via a media specific interface, and is a national responsibility. It could even be implemented with the SPC being housed within the radio. Refer to the SPC and radio manufacturers’ manuals for exact details of the interface.
Logistics spares would also need to be acquired to provide an adequate level of cover in case of unit failure. The quantity and level of spares provided is a national responsibility and may vary depending on the platform, location and the number of operational units.
Based on the technical aspects defined in [STANAG 5522] and on the basis of operational procedures as defined in NATO document, Allied Data Publication [ADatP-33] this chapter is intended as a generic guideline for planners, operators and technicians uitlizing Link 22 in a single or a multiple link environment. National or platform specific procedures and operator actions are not covered in this guidebook.
This chapter contains technical details of Link 22, consisting of the architecture, functions, and protocols. It is primarily intended for integrators, software engineers and testers. Readers of this chapter are expected to have knowledge and understanding of the previous chapters, as this chapter will explain details without reiterating the higher level information already provided. This chapter will discuss non-tactical Link 22 features, functions, interfaces, and messages. The tactical messages were discussed in Chapter 2 Section D.
Available for download at The Link 22 portal for Foreign Nations @ NILE Project Management Office.