A Common Approach To Switching In Tactical Trunk Communications Systems

Introduction

Trunk communications for land operations have traditionally provided voice (telephony), messaging systems and latterly data networks down to formation level within a corps structure. The Australian situation, especially in dispersed operations, is significantly different to traditional operational concepts. Independent, dispersed brigade-level operations with large areas of operation do not match well with traditional trunk solutions. In such a scenario, linkages into the strategic communications base become more important, and will be conducted at a lower organisational level. To some extent this challenge is also being faced by other modern armies, for instance with deployments in Kosovo and Bosnia.

Over and above the operational concept changes, there has been a rapidly increasing demand for data services over the trunk communications. The pace of these changes has not been universally matched by developments in the trunk communications systems. In the Australian example, many projects have created their own protocol stack and associated equipment to solve independently the communications challenge that should have been met by a common trunk communications system. The advent of new technologies and the opportunity to adapt trunk approaches leads to a need to reconsider the composition of the trunk system.

In this paper we seek to examine the purpose of the trunk system, consider technical approaches (particularly overseas models) to meeting the purpose and propose a new trunk architecture.

Purpose of trunk communications

Figure 1, slightly adapted from [1] and [2], seeks to put the trunk system into the context of the entire Land Communications Architecture. The architecture proposes a heterogeneous but interoperable system of communications systems with different elements to meet the disparate needs of land forces, for instance combat radio sub-system to provide highly mobile, all-informed communications.

Figure 1 is not strictly a Systems Architectural view in accordance with the C4ISR architectural framework [3] since the allocation of systems to operational entities is implicit. As discussed in [2], the trunk system provides the gateway between the strategic communications system and deployed elements. It is deployed down to at least brigade (task force) level, with potential for extension down to unit level. The trunk system provides voice (telephony) and messaging systems along with increasing support for data services. For management and the most effective sharing of limited bandwidth, these services should travel over a “converged” network capable of carrying all communications services both real-time (voice/telephony, interactive video and some data applications) and non-real-time (messaging and other data applications).

Arguably the key function of the trunk system is to provide relatively high capacity between major aggregations of staff or command support functions. The trunk system provides a backbone for interconnecting other systems into the system of systems for instance the interconnection of discrete sub-networks of the tactical data distribution system.

Technical approaches

Figure 2 (from [1] and [2]) describes the “area communications” form of trunk communications currently fielded in larger, conventional armies such as the US and UK. The fundamental concept is of a series of backbone “trunk nodes” laid across the battlefield into which HQ “access nodes” can connect. The trunk nodes are sited for optimum communications and coverage of the area of operations, allowing access nodes to be sited tactically.

Current technology focuses on user-access circuit switches operating in a “system high” security mode. Circuit switches at the trunk nodes also operate at the system high to allow for signalling interchanges with the access nodes. The approach allows individual user connections to be processed at the trunk node to employ optimum routing through the trunk network and reserves the trunk-to-access links for employment only for traffic terminating or originating at the access node.

Issues with the area trunk concept

In the current generation of area trunk systems, the circuit switching technology provides the convergence for all services, that is telephony and messaging/data. Accordingly, there is a lack of clarity in the conceptual division between the trunking network per se and the services being carried. With the advent of newer converged network technologies, there is an opportunity to reconsider what networking elements might provide the basis of the trunk nodes.

The current generation of area trunk systems has primarily come from a NATO heritage. Thus the systems generally have a terrestrial radio focus and generally assume a relatively secure rear area behind a forward edge of the battle area (FEBA). In Australian dispersed operations, it is artificial to physically separate the trunk node from the access node. In dispersed operations, with significant reliance on satellite communications, the trunk nodes are likely to be in the same town or defended locality as access nodes. Full coverage of the area of operations via independent deployment of trunk nodes would not be tactically feasible.

Regardless, even if access and trunk nodes are collocated, technical/managerial separation arguments can still be sustained. A key aspect of the trunk concept is that trunk infrastructure should follow appropriate communications connectivity. The details of the trunk topology is hidden from the user (access node) layer, thus the command chain and other communications links are established through virtual connections across the infrastructure or “cloud”. In such dispersed operations, each formation would be required to independently link into the strategic communications system and the tactical trunk cloud should seamlessly merge into the strategic cloud.

The specific Australian problem

The trunk system for the Australian land forces is being provided by Project Parakeet. This military specification network is arriving too late for many other communications users such as the Army Battlefield Command Support System (BCSS). Parakeet is also fielding an older technology circuit switching technology ill-suited for modern data communications. As a consequence the physical layer, in particular the satellite system, has become the convergence layer instead of the trunk network acting in this role. This has seen independent development of stovepipes: vertical acquisitions rather than horizontal except perhaps at physical layer. Figure 3 shows some examples of current communications orientated projects and how their scope of development and delivery of products cross the OSI Model boundaries. (A brief explanation of each project is at the end of this paper). From an acquisition viewpoint, the problems are:

• Project solutions tend to be developed independently of each other, therefore, effort/money will be wasted in reinventing solutions and these solutions are not easily ported to other applications.
• Each project must solve a greater problem than might have been the case if they could leverage off work already done.
• Integrated logistic support costs increase when independent solutions are used, when a common one may have been suitable.
• Independently developed systems are likely to be incompatible, making communications in the field more difficult and limiting a commander’s flexibility.

The Risk

Historically, defence forces have adopted a low-risk approach to acquisition. Because projects have their own cost/schedule pressures to meet, the projects have sought to control all aspects that might impact their schedule. Contractors for each project are each given a series of functional specifications, which they turn into solutions independently. This leads to the creation of stovepipes.

Of course the defence force would be loath to specify solutions for application-specific requirements. A frivolous example would be specifying a commercial spreadsheet application as the data fusion engine for the Australian Collins submarine combat data system. Obviously, there is a chance that the spreadsheet application might not be the best tool for the job and the Commonwealth of Australia would be responsible for the outcome.

Yet defence management, with little or no risk, often specifies power requirements, cabling and other low-level items. Indeed, for its UHF communications, the Australian Defence Organisation has gone so far as to stipulate the satellite access control protocol (Demand Assigned Multiple Access—DAMA). Doing so doesn’t cause any of the agencies/people involved any concerns about risk because such aspects are well understood and well tried.

This leads to the hypothesis that the risk associated with specifying solutions is proportional to how application specific the problem is. One can argue that this is related to the layer in the OSI model. That is, specifying solutions for the Physical Layer (Layer 1), which has broad application, is less risky than specifying solutions above the Application Layer (Layer 7), that by definition are application specific.

With this in mind it is critical that defence management move up from the physical layer and begin to specify standards (hence technical solutions, architecture and specifications for higher layers of the model. This has become particularly important in Australia because of the emerging Defence satellite system.

With the implementation of one project, JP 2008 Phase 3D, the Australian Defence Organisation is going to build the most complex communications hub it owns—X and Ka band anchor stations being built to operate with the Cable and Wireless Optus C1 satellite. Additionally, other C and Ku band systems will be incorporated. To make this work the systems using it need to conform to an overall architecture.

The real risk is not that defence management over-specifies solutions, but is that it fails to plan; this leads to individual project solutions developing incompatible architectures.

An alternative approach

If defence management decided to adopt a common higher layer protocol, for instance by establishing an appropriate trunk network standard, Figure 3 would look considerably different. Most notably, individual projects can be split in two. This would provide a separation between the pipes that deliver the data and the services and applications that provide capability. Figure 4 depicts this idea with Asynchronous Transfer Mode (ATM) as the common switch infrastructure—that is, the trunk switching system. This has similar benefits to the standardisation on the Internet Protocol (IP) Suite (commonly referred to as TCP/IP) as the data communications standard for computing applications. The key argument is that a common layer should be specified, that ATM provides the most appropriate (for the moment) common layer for tactical communications is discussed later.

Security considerations

While [2] does not discuss the security architecture of the trunk system, there is clearly a need for multi-levels of communications security to support, for instance, intelligence, operations and civil interaction. Accordingly there will be user-level switching at these different security levels. Use of payload encryption, where the user data is protected but plain language protocol headers/signalling are available, allows the traffic to be switched by unclassified switches. Such an approach is shown in Figure 5. This shows voice switches (PBX), video teleconferencing facilities and routers being aggregated over ATM infrastructure. Payload encryption devices (Z) allow different “system high” enclaves to interconnect with peers over the same unclassified infrastructure.

In the context of the trunk system one can argue that the user-level switching and payload encryption devices logically comprise the access node while the unclassified switching infrastructure is the trunk system. This provides the potential for the use of civil infrastructure as an extension of the trunk system where available.

An unclassified trunk system with classified access nodes is also well placed to carry traffic that has adopted an end to end security paradigm, for instance Speakeasy and Future Narrowband Digital Terminal (FNBDT) as used in the strategic arena. There may be arguments for the tactical user network to operate with different security architectures, for instance voice services operating within trusted system high zones (similar to current data security architecture) rather than employing the end to end paradigm of the strategic voice system. Nevertheless, an architecture based on an unclassified trunk switching system and payload encryption of access node traffic can successfully integrate with strategic communications security architectures through red gateways.

ATM vs IP

Figure 4 describes an approach using ATM rather than the IP suite. It is acknowledged that the commercial data world, and to some extent the commercial voice world, have embraced the IP suite—see [4] which acts as a preface to a number of DSTO reports on the use of IP in the commercial world, especially [5] for telephony. Nevertheless, the tactical communications situation is significantly different to the strategic/commercial world and it is argued that IP mechanisms are not yet proven effective for providing the convergence layer for land tactical communications. Some key technical issues are:

• ATM switching technology was designed from the beginning to provide (technical) Quality of Service (QoS). This is a capability that allows the switched network to manage the performance of the network in areas such as latency, jitter, errors/losses. Being able to manage these technical quality factors means that the network can carry all types of user traffic, both real-time (such as interactive voice and video) as well as non-real-time. IP QoS mechanisms are less mature and, in the end, are limited in effectiveness by the variable (and long) packet length of the IP protocol. To provide QoS, IP networks will often need to segment large IP packets into smaller packets, each with their own headers, with consequent impact on bandwidth efficiency. Bandwidth efficiency is not generally an issue for commercial networks with the increasing rollout of fibre optics, and many commercial networks achieve QoS through over-dimensioning the bandwidth of the network.
• There has been considerable criticism of the bandwidth overhead of ATM with its fixed 5 byte header versus 48 byte payload (approximately 10% overhead). This is contrasted to the IP packet with typically 20 bytes header with 1480 byte payload (less than 2% overhead). While this is valid for large data transfers where maximum packet sizes can be employed, small packets, for instance acknowledgments and real time services, can suffer inordinately high overheads. As an example, the transmission of 20-byte voice packets suffer about 50% overhead. While there are techniques to compress IP headers, these are not within the capability of current IP packet encryptors and also make the packets headers more vulnerable to errors. In respect of IP packet encryptors, the standard mechanism (Encapsulating Security Payload technique of IPSec discussed in [6] and defined at [7] and [8]) encrypts the total packet (IP header and payload) then pre-pends a plain language IP header, with further overhead impacts.
• As discussed in [9], [10] and [11], the IP suite, with its large packets, are quite susceptible to failure even under low error rates. Accordingly, tactical links carrying IP traffic require error protection to restore network error rates to near that attained on commercial networks. A compromise needs to be struck between the capacity costs of the error protection and the capacity cost of residual errors. However, many real time services, in particular voice, are quite resilient to bit errors but are more sensitive to any delays entailed through error protection (such as deep interleavers used for data protection). Accordingly, the preference would be to provide different amounts and types of error protection to different types of service. This is easily carried out within an ATM architecture.

Accordingly, especially in light of existing strategic infrastructure and emerging ATM capability in Parakeet and other trunk systems around the world, ATM is recommended as the most appropriate switching technology for the land tactical trunk network for the immediate future.

Conclusions

The overarching direction of this paper is to argue a revised way to think of the trunk system:

• We need a common layer for all communications services to operate over.
• Higher level projects and systems need to be mandated to operate over standards and services provided by this common layer.
• In the land tactical world this common layer should be provided by the trunk system (in the strategic arena in Australia this is the unclassified Defence Switched Data Network (DSDN).
• For the moment, ATM is the logical technical solution as the switching protocol and common communications layer.

The trunk architecture of access and trunk nodes needs now to be interpreted as user level switching (using whatever is the most appropriate technology) and trunk level switching (the ATM cloud).

Disclaimer

The views expressed in this paper are those of the authors and do not necessarily reflect the position of the Department of Defence.

Australian Project Examples

The Australian projects in Figures 3 and 4 are:

References

Authors

Bill Blair is a Senior Research Scientist in Network Architecture Group of the Defence Science and Technology Organisation. He has been involved in research into the application of ATM to military strategic and tactical communications since leaving the Australian Army.

Scott Egan is a RAEME Major within the Defence Materiel Organisation supporting Joint Project 2008 (MILSATCOM). He has worked with ATM link hardening at the UK Defence Evaluation and Research Agency and in Project Parakeet with tactical trunks over ATM.