LtCol. Bart Hoeben has more than 30 years’ experience in the Royal Netherlands Air Force. Trained as a fighter controller, he has held various operational positions in the Netherlands and NATO, including NATO AWACS and CAOC Uedem. He worked for nearly three years in the F-35 Programme Office on interoperability, followed by a total of six years at the Defence Staff in Air C2, ISR, unmanned and space requirements. Recently, LtCol. Hoeben spent a year in the Royal Australian Air Force as an International Fellow, studying new concepts for Air C2 and ISR in a 5th generation air force. Currently, he is Section Head Air C2 at the Royal Netherlands Air Force HQ.

LtCol. Hoeben started his presentation with an example which demonstrates the idea behind C2 in the combat cloud. He presented a website called ‘Jobspot’ which has the motto: “Find a professional for all your jobs in and around the house”. This website allows people to advertise a job to be done by professionals, get responses from them and finally assign that job. He then posed the question of whether this method could be used in C2.

LtCol. Hoeben continued by explaining how the idea had originated. He did a conceptual study in Australia on “5th Generation Air C2 and ISR”, driven by the notion that new capabilities and weapons bring the need for new C2 concepts. Moreover, near-peer adversaries are becoming more and more capable and this also requires new approaches to C2. His study was therefore set up as a conceptual framework and it should be considered in this manner.

The future operational environment in which we fight a peer adversary has the potential to become very complex and highly dynamic. In this environment, we need to be able to adjust our actions constantly to cope with any situation that may develop and to react in real-time to emerging threats and opportunities. We need to be agile; ready to resort to a high degree of dynamic (re-)tasking to outpace and outmanoeuvre the adversary.

Based on the NATO NEC C2 Maturity Model, which was designed in the late 1990s/early 2000s, the closer you stay to the bottom-left corner, the more rigid the methods of C2. We should certainly stay away from the bottom-left corner, but we should be able to move along the axes in accordance with the requirements of the operational environment. The axes are: distribution of information among entities, patterns of interaction among entities and allocation of decision rights to the collective. The broader you make them, the closer you get to the “Edge C2” (the top-right-forward corner of the cube). However, Edge C2 is fairly contextual. We are looking for a more tangible design.

The combat cloud is the collective of nodes wherein no single node or combination of nodes is essential for the cloud to exist. Nodes join and disconnect as required, information density increases close to effects and decreases again once the effect is achieved, creating a very dynamic information environment. In many models, the combat cloud approach consists of three layers: a network layer, an information layer and an application layer.

LtCol. Hoeben uses an adjusted four-layer model, consisting of a network layer, a data layer, a services layer and a collaboration layer. The collaboration layer is essential for the military way of doing business. Peer-to-peer collaboration is essential to progress in the C2 Maturity Model towards more agile C2. What is important to understand is that the combat cloud is not an off-the-shelf IT system. It is a new way of doing business and can perhaps be regarded as a new method of C2. Later on in his presentation, LtCol. Hoeben elaborated further on the layers of the combat cloud.

In ‘classic’ Air C2, there are mostly hierarchical relationships. This means tasking goes downwards and reporting goes upwards. Also, one-on-one tasking and platform-centric relationships exist. If we take Air C2 structure as an example: sensors and shooters report to ASACS (CRCs, AWACS) or GCS/PED and they report to C2ISR(AOC). To move towards Edge C2 we should take three measures. First, we should move from hierarchical relationships to collaborative relationships. This needs to be designed on the basis of the commander’s intent and on mutual trust. The commander should trust the warfighter at the tactical edge and not be engaged in micromanagement. On the other hand, if a commander intervenes all the way down to the tactical edge, the warfighter must trust that the commander has good reason to do so and accept this as a form of C2 assistance. Furthermore, peer-to-peer interaction should increase for more effective collaboration. A second measure would be to move from task-centric to effects-centric collaboration. The third and last measure is moving from platform-centric interaction to information-centric operations.

Transition to C2 in the combat cloud requires four steps. It starts with classifying the function(s) of every node.. Four functions are available: C2 nodes, sensor nodes, effector nodes and knowledge nodes. The term knowledge node deserves some explanation. Knowledge nodes are involved in adding value to data, creating information, intelligence and/or knowledge. As such, the PED of an ISR-asset can be classified as a knowledge node. One entity can have more than one function. For instance, an AOC can be a knowledge and a C2 node at the same time. The second step is to create grids by tying all the nodes according to their functions. Consequently, there will be a C2, an effector, a sensor and a knowledge grid. The C2 grid ensures resilience. The effector and sensor grids will create a structure where sensors and effectors can collaborate instead of using the hierarchical way of collaboration. This increases agility and synchronization, enabling a faster OODA loop. The third step is intra- and inter-grid collaboration. All the nodes inside every grid can collaborate effectively and collaboration between grids is essential as well. Finally, in the fourth step, the intra- and inter-grid collaboration is projected in the collaboration layer of the combat cloud.

Going back to the analogy at the very beginning: ‘Jobspot’. Its peer-to-peer C2 regime can be used as a good example of increased C2 agility. Basically, combat cloud C2 promises to speed up the OODA loop by eliminating the time loss caused by hierarchy.. There are some initial (good) examples of a combat cloud-like concept. Exercise Unified Vision-18 experimented for the first time with a federated PED concept. A PED unit which had a great capability to interpret GMTI information but no organic GMTI sensor was connected to a unit which had GMTI sensors but no GMTI interpreting capability. In this way, the sensor grid was connected to the knowledge grid. Also, in exercise Northern Viking 20, participants will experiment with federated C2 functions (services) such as targeting and ISR-D functions. Using federated C2-services makes targetability of an AOC function much harder, hence creating resilience.

Key take-away

The future operating environment in which we fight a peer adversary has the potential to become very complex and highly dynamic.

We need to shorten OODA loop time by changing the hierarchical C2 connections with efficient C2 grids.

In the NATO C2COE study ‘Future of the Command Post Part 1’ (please refer to c2coe.org), one of the conclusions is: ‘Future command posts should be distributed and dispersed’. Lt Col Hoeben stressed that this concept also brings resilience. In this manner, the combat cloud concept framework is also verifying the outcome of the study.

Download Powerpoint Presentation: C2 in the Combat Cloud Framework for Future Capability Development – LtCol. Bart Hoeben