Bandwidth Adaptability for Deployable Headquarters: Using a Limited Resource to Best Military Effect

Introduction

The central concepts of the current Revolution in Military Affairs (RMA) are: dominant battlefield awareness; speed of reaction; mobility and manoeuvrability; precise targeting and delivery of munitions; full-spectrum defence; and focused logistics. Battlefield awareness and mobility combine to enhance both offensive and defensive capabilities and reduce an adversary’s chances of targeting defensive forces [1]. Given changes in the nature of conflict, and the increasing frequency of Coalition operations, a forward element of Command and Control offers several distinct advantages. For example, if each of the Coalition partners in a combined operation maintained deployed headquarters in close proximity, these would promote timely co-ordinated action at the operational level and also facilitate contact with local officials. Factors such as these are leading defence forces throughout the world to develop organisations and supporting systems for deployable operational headquarters. One such development is the Deployable Joint Force Headquarters (DJFHQ), which has recently been integrated into the Australian Defence Force’s command structure [2].

Dominant battlefield awareness derives from information dominance — superior information gathering, processing and distribution capabilities together with the ability to limit or interfere with an opponent’s capabilities. To achieve such dominance, numerous specialised systems need to exchange information and services in a meaningful and timely fashion. In the tactical context, however, communications resources between deployed headquarters and superior, inferior, collateral and Coalition headquarters will frequently be oversubscribed. Mobility and portability requirements for a DJFHQ place further constraints on available communication resources. Two principal issues are those of how to use such limited resources for best military effect and how to adapt quickly to network failures.

Current generation C3I systems, and the COTS products on which they depend, are typically designed for a well-provisioned communications environment. Little consideration is currently given to accommodating changes in available bandwidth in operational areas, arising from wide variations in demand or from elements of the communications infrastructure coming under attack. Current systems typically fall into two categories: strategic and operational systems designed assuming a Local Area Network environment, and tactical systems designed assuming a constrained tactical communications environment. Significant problems can be encountered when systems from the first category are taken into the field, or even connected via Wide Area Networks. Systems in the second category are often limited to message-based communications, but some innovative ways of performing database updates using messages are now being developed (see [3], for example). One long-standing feature of military messaging systems is that of message precedence: urgent messages pre-empt routine traffic. There are, however, several disadvantages of this approach:

• Users must set the message precedence. While this has the advantage of flexibility, precedence may well be based on doctrine that does not consider extant network conditions.
• Current messaging infrastructures (for example: X.400, ACP 128) do not readily support emerging applications such as multimedia and Web-based applications.
• Current messaging infrastructures are not able to take full advantage of integrated communications systems that support several different technologies (satellite, VHF, HF, etc.). This is particularly true of applications with strict performance requirements.

The nature of bandwidth constraints

Communications capabilities available to a deployable operational headquarters will vary according to the nature of the particular mission. Such capabilities may well include:

Fixed telecommunications networks.

Cellular mobile communications.

Satellite voice and or data communications.

Global Broadcast by Satellite (GBS).

UHF, VHF and HF Radio.

Available bandwidth could thus range from kilobits to tens of megabits per second. C3I systems used within a deployable operational headquarters need to be structured to best achieve their purposes given a possible range of several orders of magnitude in communications bandwidth (and smaller variations in other parameters such as latency and error rate). Computer-based tools for distributed co-operative work might, for example, use videoconferencing plus shared whiteboard facilities when bandwidth is available. As bandwidth becomes more constrained, Computer Supported Collaborative Work (CSCW) tools could drop back to teleconferencing and a shared whiteboard, to structured text-based tools such as Lotus Notes, and ultimately to short text messages. Ideally, such tools would negotiate with the communications infrastructure and automatically adapt their operations according to the priority and volume of other traffic and available network resources, based on predetermined policies and priorities. Clearly, high priority alerts and commands must not be delayed because of ad hoc queries or routine location updates on a situation display.

Failure to plan for best use of communications assets can have a significant impact on operations. During the Gulf War, for example, the US Navy had to fly Air Tasking Orders (ATO) onto carriers because of software and hardware problems and lack of satellite circuits, with the result that [4]:

“a couple of junior enlisted air controllers on a three-week caffeine high in the back of a combat information center would have to flip through this six-pound chunk of fanfold paper on their knees to find the whereabouts of a tanker for their combat air patrol.”

This incongruous situation arose despite the ATOs being of high priority and originally generated in digital form. Much of the traffic on available satellite circuits would have contributed less to overall military effectiveness than timely availability of digital ATOs. The underlying problem here was one of policy determination and implementation, so that limited resources could be managed appropriately.

In summary, a new approach is required for overall C3I systems architectures, including policy-based negotiation between individual applications and the network management infrastructure, so that better use can be made of available communications.

Adaptability to communications variations

Our envisaged approach to accommodating conflicting requirements is based on the Adaptive Computing Architecture (ACA) being developed at the University of Queensland [5]. This architecture is based in part on the premise that effective adaptation to changes in network conditions requires a detailed information base regarding the operating environment. The work presented here explores application of ACA concepts to heterogeneous defence networks. An important characteristic of such networks is the extent of variability in Quality of Service (QOS), resulting from changes in classes and volumes of traffic, varying environmental conditions and possible physical attack on network elements. Perversely, the available QOS is likely to be poorest when good service is most critical — just prior to and during conflict.

The two key concepts in ACA research are derivation of Adaptability Policies and representation of topology-based QOS. Adaptability Policies allow system developers, administrators and users to pre-specify policies that determine how the system will react to various resource states for given traffic loads. Picture a scenario in which an automated alert generated within a brigade HQ has to be forwarded to an operational HQ. Suppose that, because of poor communications conditions and the extent of background data traffic, the alert takes 25 minutes to deliver and arrives too late for appropriate action to be taken. To minimise such occurrences we would obviously like to implement a policy of giving high priority messages precedence over other traffic. Further, our policies might state that under certain problem conditions an operator should be alerted within the brigade HQ so that alternative action can be taken if necessary, using a high priority message to ensure timely delivery.

Example

We now describe a hypothetical military operation to illustrate the concepts underlying our approach.

Following ongoing but somewhat ambiguous evidence of a low-level incursion on a remote Australian coastal area, an operational headquarters is deployed to the general area, along with a supporting Task Force HQ and organic assets. Troops manoeuvre into position and intelligence information begins to flow throughout the C3I system. Forward night scouts disturb an unidentified group that flees, abandoning protective equipment together with what are apparently chemical or biological materials. At about the same time, microwave links to a regional satellite ground station fail (possibly as a result of physical attack), causing a loss of civilian satellite circuits (50% of total satellite bandwidth). At the very time when effective communications are most needed, the headquarters loses half of its already fully subscribed capacity.

Consider the example communications environment and how it supports military operation prior to the link failure. Figure 1 gives a simplified view of the communications between the Task Force and Deployable Joint Force HQs, linked via satellite and HF radio links. Initially, several voice conferences are in progress. All traffic defaults to satellite links due to HF bandwidth limitations.

Using current approaches, a percentage of the voice calls and application traffic would be terminated, at least until higher priority traffic is manually switched to remaining circuits. In the scenario outlined, this could have serious consequences if initial notification of an impending chemical/biological attack is delayed and co-ordination of a response is hampered by a shortage of voice circuits. Urgent decisions regarding reconfiguration of failed network resources will usually attempt to address local perceptions of priority. Such decisions can easily exacerbate the overall situation, however.

With an ACA-like architecture, a considered and pre-tested policy for dynamically reallocating scarce resources according to overall operational impacts can automatically be called into play. The effect at the application level would be that an Adaptability Manager would notify applications that current QOS contracts had to be renegotiated. In contributing to an overall 50% reduction in satellite link traffic, a CSCW application might for example choose a new level of QOS that let it continue with teleconferencing by subjecting packet voice data to greater levels of compression (causing some loss of voice quality, but reducing communications demands). At the network management level, background messaging traffic could be diverted via HF. Assuming that no further problems occur, all connections could be maintained (with a reduced QOS for non-urgent communications), until the damaged circuits were restored. As overall demands and availability of circuits changed, QOS contracts would be renegotiated and applications would adapt appropriately.

While the above scenario is oversimplified, it indicates the benefits that can flow from effective application/network adaptation and the strategies we are pursuing.

Adaptability policies

Adaptability Policies are used to specify actions the system should take under certain conditions. The policies need to be simple enough for users and administrators to understand and modify, yet sufficiently specific for a computer to interpret unambiguously. Sloman’s management policy language [6] fulfils these requirements. The stated policies can be expressed such that reallocation decisions are made in the light of current network and QOS information. Such decisions typically take the form of allocating or releasing resources within the network, or notifying an application that network conditions have changed. In the latter case, the previously negotiated QOS becomes subject to renegotiation (up or down).

Several useful classes of policies are already evident:

• Inter-application preferences (for example: maintain real-time messaging in preference to routine database updates)
• Selection from alternative resources (for example: according to bandwidth/delay). Note that this could be to satisfy application requirements and not necessarily to optimise overall QOS.
• User priority (for example: allow only certain users, groups or applications to consume non-trivial external communication resources at times of serious over-subscription).

An example where the last category might apply would be a deployed military HQ with limited communications capabilities. There may be existing HQ wide policies that messaging is routed via satellite because it is delay tolerant, or that certain users get preference for allocation of communications assets. In addition, under certain conditions, application requests for substantial bandwidth over a protracted period between the HQ and external sites, such as a large file transfer or database “snapshots”, may be denied or delayed. Examples of other policies are:

• Connect to one of multiple available wireless networks according to lowest “cost”.
• Do not route certain classes of traffic through domain X (insecure) under any circumstances.
• Use topology-based information to allocate resources in all adjacent cells so that connections will not be affected by pending change of location, or to minimise “single point of failure” vulnerabilities.

Policy conflicts

There is a substantial body of research regarding policy conflict detection and prevention [7]. Nevertheless, conflicts may still go unnoticed until run-time, or worse, remain latent until a particular unanticipated situation comes into existence. (Almost by definition, this is most likely to occur during a time of conflict.) A reasonable system-wide policy might be that a minimum prescribed voice quality be maintained for urgent high-priority discussions. The simple scenario depicted in Figure 1 refers to an application-level policy of using reduced voice quality to maintain connections during reductions in available bandwidth. Assume that local commanders at several sites are engaged in background planning discussions, using reduced voice quality teleconferencing and a shared whiteboard, when a high-priority alert requiring their immediate attention arrives. They are likely to continue using the CSCW tool for agreeing on a course of action in response to the alert, rather than trying to re-establish contact using other tools. If the designers of the CSCW tool failed to anticipate the above possibility and did not include a simple method for upgrading the application’s priority, there would be a clear danger of policy conflict.

People often use tools in unanticipated and quite creative ways. Logical analysis together with extensive exercises and testing can identify most potential policy conflicts, but backup procedures need to be instituted to avoid “deadlocks” and other consequences of policy conflicts. For example, policies could be assigned relative precedence. In addition, meta-policies could be defined that specify actions to take in the event of lower-level policy conflicts.

Representation of network topology and QOS

Topology information can be portrayed as a city street map, with the width of the road and the distance between points representing overall QOS. Topology-based QOS information is required to answer questions of the form “how much will it cost to send this message” or “how long will it take to send this message” or even “what is the probability that this message will not be delivered within five minutes”. Such information is required for making appropriate adaptability decisions, thereby enhancing the Adaptability Manager’s ability to react to changes in the environment. Example uses of network information include: selecting between routes through the network to optimise cost, performance or security (using IP source routing for example); choosing between networks or network interfaces on the basis of cost, performance or security; and activating dial-up links according to high level policy.

Some examples of topology-based QOS include:

• Static and dynamic QOS characteristics (bandwidth, delay, jitter, error rates, cost, etc.).
• Transport reliability.
• Long term network reliability, for example MTBF (Mean Time Between Failures).
• Whether a domain/link is secure/insecure, or supports encryption, etc.
• Existence of application level gateways (for example: a firewall or conversion between video compression standards).
• Location of services with regard to the topology (this may be represented explicitly or implicitly).
• Whether a link supports the ability to pre-allocate bandwidth and what kind of guarantee is offered regarding such reservations.
• Existence of dial-up links.

Statistical modelling of traffic sources in computer networks is known to be difficult and often inaccurate [8]. However, for shared media networks such as Ethernet and IP, where no reservations are made and no guarantees are given, statistical assertions are the strongest that can be made. For example, it may be that traffic flowing through a particular IP domain has a probability of 30% of achieving an effective throughput of at least 50kbps.

Link security is represented in addition to performance-based QOS measures. The two security-related attributes currently supported by our model are encryption and domain security. These attributes specify whether or not a link is encrypted and how physically secure a domain is considered to be. A tactical domain near the front line may, for example, be subject to being overrun by an opposing force and thus is relatively insecure.

The above observations lead to requirements for different attributes to characterise different networks. At the same time, we would like to minimise unnecessary differences, to simplify the task of the Adaptability Manager.

Figure 2 depicts the basic components of the Adaptive Computing Architecture. Each component of the architecture in the diagram is a system or sub-system in its own right. The Network QOS Manager stores topology-based information and communicates with the network in, for example, setting up ATM connections. Topology information (including QOS domains abstracted from the physical connectivity) can be manually edited using the Graphical Topology Editor. The Network QOS Manager also provides information to the Adaptability Manager, and allocates resources on its behalf. The Adaptability Manager receives communication requests from applications (for example, a messaging or geographical information system) and processes these requests in accordance with adaptability policies stored in the policy service. The policy service also has analysis tools to detect conflicts in the policies.

The Adaptability Manager must be able to use dynamic monitoring information when available. The importance of dynamic network status information is underscored by the possibility of physical damage to parts of defence networks during times of conflict. Issues of how such information should be distributed remain to be explored.

In addition to network topology, significant adaptability is enabled by simply knowing the QOS available between application hosts (Transport Layer QOS). This is the approach commonly adopted in earlier work (for example, [9]).

As detailed in [5], our architecture supports representation of network topology and QOS, transport layer QOS and QOS associated with application services (for example, performance of a database server).

Conclusions

A prime requirement for deployable operational headquarters is freedom of information flows, with assurance that high-priority alerts and directives will not be impeded by lower-priority traffic. Available bandwidth is usually a limiting and highly variable resource here, especially during times of conflict. Increasing reliance of military operations on networked computer systems stresses the need for a tighter integration of applications and network management to make best use of available resources.

To best satisfy their functional requirements, tactical military networks need to adapt to differing classes and priorities of traffic and changing network conditions. In addressing this need we have proposed use of an Adaptive Computing Architecture in which resource allocation decisions are made on the basis of carefully evaluated adaptability policies (as specified by developers, administrators or users). In contrast to the typical default network policy of shared network access or network policy decisions made “on the run”, such an architecture promises to help achieve the best military outcomes from limited and dynamically changing resources.

References

Authors

Bruce McClure is with the Command and Control Information Systems Interoperability Laboratory (CCISIL) at the Defence Science and Technology Organisation’s C3 Research Centre. He holds a Bachelors degree in computer engineering and is pursuing his PhD at the University of Queensland.

Iain Macleod is a Senior Research Scientist in the CCISIL. He holds a BE in Electrical Engineering and a PhD in Computer Science.