A Case Study Of The Development Of A SANDF Tactical Data Link Network Enabling Capability

Introduction

What is network enabled defence?

US Air Force Col John Richard Boyd developed the notion of the OODA (Observe-Orientate-Decide-Act) loop based on his experience as a fighter pilot. Boyd derived the notion that the adversary who could observe his enemy earlier, orientate towards threats quicker, decide which action to take faster and most effectively act out that decision would be most likely to be a victor of that battle [1]. Out of this notion the benefits for Network Centric Defence and Network Enabling Capabilities (NEC) for defence can be quantified.

Due to high cost of defence systems and the advent of multi-role military platforms, the requirement for Network Enabled Defence is even more imperative since it provides flexibility, interoperability and expansion of defence capabilities.

According to the South African Department of Defence (DoD) Information Strategy [2], a DoD strategy for Network Centric Defence was developed in response to these emerging theories of war. The SA DoD adopts and defines Network Centric Defence as “the capability inherent in the Defence Information and Communication Infrastructure to store, process and move essential data in planning, directing, coordinating and executing operations in digital format. It is all the normal functions of defence that can be done in a digital format”.

Why tactical data links?

Voice communications via radio frequency (RF) communications systems has been the primary means of communications on the military battlefield since World War II. Furthermore Pike and Sherman [3] describe how World War II sparked the development of components and equipment that first allowed very high frequency (VHF) and ultra high frequency (UHF) communication systems. These voice communications did however impose severe limitations when coherent and detailed battlespace information needed to be conveyed. Voice communications proved to be slow and prone to misunderstanding, thus adding inefficiencies in the execution of the OODA loop.

Tactical Data Links (TDL) evolved from combining digitisation and RF communications technology in order to meet a growing defence requirement for systems that can exchange more information, faster and without ambiguity [4]. In this sense, TDLs are an enabler for Network Enabled Defence and therefore a required Network Enabling Capability (NEC).

TDLs allow the exchange of digital information between command and control (C²) systems and weapons platforms. The types of information to be exchanged include platform positions, battlefield surveillance and intelligence, and mission management information. This exchange of information is required to allow defence forces to effectively manage the situational awareness, planning, tasking and control of their forces in the context of battlefield C² albeit it for conventional warfare or Operations Other Than War (OOTW).

South african tdl history

The requirement for TDLs in the SANDF was highlighted with the South African Strategic Defence Procurement Packages (SDPP) in 1999. South Africa embarked on the development of an indigenous South African TDL standard, now known as Link-ZA.

Most SDPPs were contracted with requirements for a Link-ZA capability. Platforms that would be Link-ZA compliant included fighter aircraft, Lead In Fighter Trainer (LIFT) aircraft, maritime helicopters, submarines as well as frigates. Subsequently Link-ZA became a requirement for most new systems in the SANDF and is pursued as part of achieving a Network Enabled Defence capability.

Delivery of the SDPP’s started in 2005 with frigates and submarines and was followed by the LIFT aircraft in 2006, maritime helicopters in 2007 and fighter aircraft in 2009.

The impression by many was that Link-ZA compliance by the SDPP acquisition projects would imply message exchange interoperability between all these platforms. Disappointingly it was found that most platforms could only exchange information between similar type platforms.

Some of the reasons for interoperability inconsistencies are discussed below.

No interoperability strategy. In the requirements, specifications and development philosophies of SDPP platforms no consideration was given to utilising platforms as an integrated joint capability, thus concluding that no clear strategy or owner was driving crosscutting project capability requirements for Network Enabled Defence.

Standard evolution. It was assumed that using a single standard would ensure interoperability between platforms. This could well have been a valid assumption if the Link-ZA standard was mature and implemented in a standard way across platform types. The standard being new and still in development was adapted and interpreted to accommodate the individual requirements of each acquisition project.

Ineffective interoperability testing. To prove Link-ZA compliance, platform developers were required to test their implementation via a common Data Link Reference System (DLRS). The DLRS could however accommodate any permutation of the Link-ZA standard, thus providing only evidence for interoperability between type specific platforms (such as fighter-to-fighter and frigate-to-frigate). Additionally the DLRS only provided means to test the interoperability of the protocol and not the interoperability of specific platform data messages at the C² level.

Defining the capability problem

With the establishment of the SANDF Interoperability Development Environment (IDE) in 2009, the issue of interoperability of defence capabilities was made a focus point for the SANDF. The IDE has taken on the challenge to solve TDL interoperability given current dissimilar Link-ZA implementations.

In order to develop or manage a capability, it would be applicable to define what the capability in question consist of. This paper proposes the following model to define the components of a generic TDL NEC, as shown in Figure 1.

The components of Figure 1 are based on the Processes, Applications, Infrastructure and Data (PAID) model as taken from the Levels of Information Systems Interoperability (LISI) [5] and could be applicable to any TDL capability.

Additionally this model also shows the value added to data as it progresses through the capability model and how data, becomes information, knowledge and wisdom in order to create a Network Centric Defence capability.

In relation to Figure 1, Link-ZA provides the information exchange protocol and data model functions to create the Tactical Data and Information levels for a SANDF TDL capability. This is represented by the Data arrows of Figure 1.

Due to the fact that the SANDF is still developing operational doctrine and processes for many of these SDPP platforms (representing the knowledge level of the capability model), it has become crucial to solve interoperability at the information and tactical data levels of the Capability Model. This paper addresses these two levels in more detail.

Data transfer protocol

Even though the Link-ZA standard has undergone extensive evolutions, the Session, Transport and Network Layers of the standard are consistent throughout implementations. This can be attributed to DLRS testing that has been effective in this area.

The data link and physical layer implementations has been imbedded into specific Military of the Shelf (MOTS) communications infrastructure. This strategy allows for common communications infrastructure but still hampers interoperability since it provided extensive flexibility in choosing different access mediums per platform.

This flexibility is found in that the standard can accommodate 1-persistent Carrier Sense Multiple Access (CSMA), p-persistent CSMA as well as Fixed and Dynamic Time Division Multiple Access (TDMA) medium access control. In addition, the TDMA timeslot lengths for these implementations can be chosen differently for each implementation which hampers interoperability.

TDMA platform implementers of the Link-ZA standard have also hardcoded access control options into platforms. These practices have resulted in different fixed timeslot length per platform type.

On the positive side, the flexibility of Link-ZA makes this single standard suited for multiple operational uses (conventional warfare as well as operations other than war, using landward, maritime or air data link applications). This is contradictory to NATO practices, where nations have invested in highly standardised architectures, such as Link 11, Link 16 or Link 22.

Table I compares the protocol characteristics of Link-ZA, Link 11, Link-16 and Link-22 as taken from [8,14–17].

Data model

The Link-ZA data model implements a bit by bit packing of data in standardised messages that can be understood by all platforms utilising the Link-ZA data transfer protocol. The implementation of such messages relate to the presentation and application layers of the Link-ZA standard.

Utilisation of the Link-ZA data model is however not limited to exclusive use with the Link-ZA protocol and has been utilised in applications with other transport protocols. (such as TCP/IP).

The use of standardised messages is to ensure that information exchange requirements between platforms are controlled and thus aims to ensure intelligible information to all participants.

The Link-ZA data model consists of three message types; Tactical Image Messages, Tactical Awareness Messages and Tactical Text Messages.

Messages include a header that provides destination addresses when messages are not unaddressed broadcasts. Messages also include Variable Message Format (VMF) capabilities.

The following comparison to Link-11, Link-16 and Link-22 messages set have been derived from [8,14–17].

In relation to the evolution of Link-ZA, the data model messages experienced the most changes over the SDPP period and still evolve today as new platforms and command and control applications are required to be Link-ZA capable.

Changes to the Link-ZA message set hampers the aim of utilising standardised messages, in that platforms imbedded the implementation of their Link-ZA messages within the host platform, resulting in very expensive system modification and engineering change proposals to make platform messages interoperable in a System of Systems (SoS) multi-platform environment.

From the above observations, three interoperability levels for Link-ZA can be derived to support the understanding of the interoperability issues at the tactical data and Information levels of the TDL capability model (Figure 1).

These levels are the data model, data transfer and access medium interoperability levels as depicted in Figure 2.

From the mentioned considerations it becomes apparent that interoperability between platforms can only be achieved through interoperability of all three levels. In order to create this interoperability, this paper proposes a short and long term strategy, of which an initial short-term strategy example is provided.

Short-term tdl NEC strategy

Data model interoperability

In the short term, interoperability will be achieved by integrating different non-interoperable platforms to a common experimental Gateway. The Gateway will mainly focus on solving Data Model interoperability issues between platforms. In addition the Gateway will include decision rules that can facilitate interoperability for joint operational doctrine and processes (Knowledge level of the TDL capability model in Figure 1).

The Gateway will be able to provide junction between differences in platform Information Exchange Requirements (IERs) by performing data conversion based on IERs derived from joint Concepts of Operation (CONOPS) rather than project specific requirements.

For the short term strategy, the Gateway will however have to be an additional node in the network and limited Gateway functionality will be imbedded into specific platforms.

Data transfer interoperability

As stated before, Link-ZA data transfer interoperability has been achieved to an executable level. There is however a requirement for an investigation relating to routing capabilities as well as data store and forward expansion for self managed beyond-line-of-sight (BLOS) V/UHF capabilities.

Access medium interoperability

Due to the issues listed earlier, communication infrastructure was found to be technically interoperable, but due to differences in access medium requirements for land, maritime and air platforms, communication infrastructure has been applied and implemented differently.

A strategy to develop interoperability between similar type air, land and maritime platforms with dissimilar access mediums is being pursued.

To enable this, the Gateway will be hosted on a communication test bed that will be established in such a way to accommodate numerous access mediums on different infrastructure. Through this communication test bed, information will be interoperable between land, maritime and air platforms.

The above focus areas will provide initial TDL capabilities that can facilitate technical interoperability up to the knowledge level of the TDL Capability model, thus providing means to perform the appropriate development of doctrine and processes. This concept is depicted in Figure 3.

An essential part of the short term strategy will include the development of Reference Implementations of Link-ZA capable platform types. This will be necessary to define the specific platform interfaces to the Gateway and communications test bed. The Reference Implementation of each platform type will be utilised to specify the requirements for the Gateway in order to facilitate Data Model Interoperability in the long term.

These requirements for interoperability would include data model consistency, generic interfaces to facilitate numerous transfer/access mediums, message translation, TDMA message packaging per timeslot, track numbering and correlation, network management (store and forward etc), etc.

This concept has been proven through an experimental implementation of a South African Air Force Gripen fighter ground station. Through this ground station, equipped with the experimental Gateway, TDL information has been received, translated if necessary, and forwarded to numerous ground based command and control applications as illustrated in Figure 4 [18].

Long term tdl NEC strategy

The long term strategy should always be to establish a TDL capability that ensures interoperability between platforms (air, maritime, and land), without the assistance of experimental gateways and additional communications infrastructure.

It is therefore envisaged to utilise the Gateway as a vehicle to specify a Link-ZA Data Link Processor (DLP). This DLP will be able to solve Data Model interoperability and would include clever routing to improve Access Medium interoperability. The DLP will become part of a standardised architecture for Link-ZA implementations that could be depicted as shown in Figure 5.

A concerted effort will have to be made to improve Access Medium interoperability for groups of platforms that can absorb such changes. This would mean that TDMA capable platforms must be made interoperable with each other and CSMA capable platforms must be made interoperable with each other.

Interoperability between access mediums would however still have to be facilitated through limited network stations that have been optimised for multiple access mediums, which would include access to the static defence information infrastructure as illustrated in Figure 6.

This strategy should be managed in such a way as to develop interoperability building blocks that will enable architecture standardisation, rather than solely relying on the interpretation of implementers of a common standard.

Conclusion

It is the findings of the authors that although the history of TDL in South Africa is only approximately eleven years old, the SANDF has managed to establish a very strong base for an indigenous capability in this area within the constraints of limited recourses.

Although the development of this capability underwent growing pains, it is at a mature enough stage where the initial investment and development efforts in communication infrastructure, platforms development, data model and data transfer protocols has been justified.

It is believed that the short term and long term TDL NEC development strategies described in this paper, when employed in a capability life cycle management philosophy, will enable the SANDF to realise a complete TDL capability as illustrated in Figure 1.

References

Authors

Mr Corné Smith is a Principal System Engineer at the Council for Scientific and Industrial Research (CSIR) and holds masters degrees in Signal Processing and Business Administration and is registered as a professional engineer with the Engineering Councils of South Africa and the United Kingdom. Email: csmith@csir.co.za. Phone: +27 12 841 3446, Fax: +27 12 841 2528.

Mr Cobus Venter is a Principal Systems Engineer at the CSIR with bachelor degrees in Electronic Engineering and Computer Science as well as a Master Degree in Engineering Management. He is currently the systems engineer for the SA Defence Force Interoperability Development Environment and holds interests in System-of-systems Engineering, interoperability and communications. Email: jpventer@csir.co.za. Phone: +27 12 841 2011, Fax: +27 12 841 2528.