By Peter Layton
Fifth generation warfare incorporates four principal but overlapping elements: networks, combat cloud, multi-domain battle and fusion warfare. Long active in implementing digital networks, naval forces are now extending this to embrace the emerging combat cloud concepts. Indeed, a major combat cloud advocate,
Lt Gen Dave Deputula, USAF [Ret] observed in a recent OTH interview that in this area Navy is in the vanguard of all the Services, in particular with their Cooperative Engagement Capability (CEC) concept and associated initiatives. Given this, CEC is worth discussing to tease out ideas that might be useful as combat cloud thinking evolves and implementation begins.
The Navy did not take the lead by accident but rather it arose because of a fundamental problem warships have: they cannot see very far. Their sensors are limited by the horizon. Approaching subsonic sea-skimming anti-ship missiles – like the Harpoon – are only detected by a ship’s radar at around 15-20 miles – or less than two minutes to impact. Supersonic and now hypersonic missiles dramatically lower this response time to a minute or less. The problem worsens during naval operations close to shore where close-in, pop-up anti-ship missile attacks from the land may unexpectedly occur.
Some new ways to address this long acknowledged problem were ushered in with the 1990’s Information Technology revolution. Network centric warfare became the buzzword of the time and was applied to the ship defence problem in particular through developing CEC. The CEC network uses datalinks but these have long been used; Link 1 and Link 4 both entered service in the 1950s, Link 11 in the 1960s and Link 16 in the 1980s. These older datalinks were used to create data exchange networks that provided the status of network participants, fighter aircraft vector commands and varying-granularity situational awareness information. Where CEC differed was in purposefully building a targeting network – just as many advocate today with the combat cloud.
The key innovation of the CEC network over earlier datalink networks is that each participant has identical sensor data processing algorithms in their onboard computers. The computers can accordingly fuse their own ship’s radar and sensor data with the shared data coming from other network participants to create a composite single integrated air picture (SIAP). With all sharing data, each participant has available the same identical SIAP which crucially is of sufficient quality to be treated as own-ship data for engagements, even though most of the data may have originally been derived and transmitted from quite distant units. Each ship or aircraft can use the SIAP as if it was generated on the platform itself.
There are several aspects worthy of note in this. The CEC approach means that each network participant must have considerable onboard processing and that the datalinks used – the unique Data Distribution System – must be considerably better than most others in capacity, cycle time, update rate, message error rate and leeway against propagation fading. Secondly, in so taking the measurement data (unfiltered range, bearing, elevation, and ideally Doppler updates) from numerous radars and sensors and fusing them, the composite picture tracks are of a much higher quality than a single radar or sensor could provide. Lastly, noting the horizon limitation noted earlier, a key node in today’s CEC network is the E-2D Hawkeye. CEC is a line of sight system and so once ships disperse widely they cannot easily connect. The E-2D flying at medium altitudes has a much larger view and can act as the crucial enabler allowing all ships to connect through it to each other.
CEC is one of the pillars of the modern Naval Integrated Fire Control – Counter Air (NIFC-CA), sometimes colloquially called the “System of 51 Systems” because of its confusing complexity. The NIFC-CA Family of Systems includes three complete System of Systems kill chains: From-the-Air (FTA), From-the-Sea (FTS), and From-the-Land (FTL), each comprising sensors, a datalink network, weapon control systems, and active missile types. There are other kill chains for surface warfare and undersea warfare.
The long-term intent is to progressively merge the various kill chains into a cross-domain kill web that shares high fidelity targeting data between participants in real-time across domains. An early step in this direction is the anti-surface warfare ‘tactical cloud’ that disseminates weapon-targeting data to networked air, surface and subsurface platforms from multiple cross-domain sensors including in space-based. An anti-surface kill web is technically easier as the targets – ships – move relatively slowly compared to aircraft or missiles, and so data fidelity problems are greatly reduced.
A Different Warfighting Concept Emerging
With the embrace of the IT revolution through CEC, NIFC-CA and kill webs, the key future naval warfighting concept has become ‘distributed lethality’. No longer will individual ships fight battles essentially as separate units. Instead they will share highly precise radar tracking data across a digital network, form a composite picture from the various inputs, and then use this detailed picture to engage hostile targets – even if they themselves do not directly hold the target on their own radar. For a task group, it means the numerous ships involved now effectively operate as one.
There are several benefits. All the task group’s ships, not just the nearest, can defend against an attack by multiple cruise missiles. The chance of a single ship becoming overwhelmed by a saturation attack would be reduced. With netted surveillance data – especially from aircraft platforms – the attack warning time would be markedly increased. Moreover, distributed lethality means each ship has access to the larger stock of weapons carried across all task group ships, not just in terms of numbers but also including types of weapons.
An air warfare destroyer for instance can pass accurate targeting data to allow a frigate to quickly fire a Harpoon anti-ship missile at a hostile ship even though the frigate has not yet detected the target. Moreover, if the destroyer’s radar is active and is being tracked by hostile forces, then the adversary may be surprised from an engagement by a weapon that is not in the destroyer’s inventory. Distributed lethality can thereby magnify each ships’ combat effectiveness while reducing the likelihood of all the ships in a task group being detected and tracked. Such networking means that the ships in a task group can be widely dispersed and yet still able to support and defend each other.
Distributed lethality also applies cross-domain with aircraft and ships potentially able to exchange target data. An E-2D flying at medium altitude for example might be tracking a low-flying cruise missile that a destroyer with its limited radar horizon at sea level cannot detect. The destroyer can then fire a surface-to-air missile at the distant cruise missile using E-2D provided data for missile guidance. A recent test demonstrated this while highlighting an important issue for future kill webs.
The test involved firing an SM-6 surface-to-air missile fitted with an active radar seeker (derived from AMRAAM), rather than the older semi-active seeker. Seeker type was crucial as the radar tracking data from the airborne platform had slight data latency issues. The missile would have missed if it had not had an active seeker to independently locate the target as it got closer.
The distributed lethality concept is also impacting future naval surface force structure considerations. As part of thinking about the Future Surface Combatant requirement, a three ship-type concept has been developed. This model is built around distributed lethality with a large arsenal ship that carries considerable numbers of various types of long-range missiles but stays well away from high-threat areas; a smaller frigate-sized warship pushed forward into the operational area for reconnaissance, submarine hunting and to provide targeting for the larger ship’s long-range missiles; and an unmanned stealthy ship operating in high-risk contested areas primarily collecting crucial time-sensitive intelligence and passing this back via the network to the smaller frigate-sized warship.
The distributed lethality concept has some major implications that are worth discussing along with some ideas that might be equally applicable to combat cloud thinking as it develops.
Firstly, some fixate on the number or size of ships the Navy has as a measure of its combat power. In the age of distributed lethality this might be seriously misleading. Instead the capabilities of the network might be a better measure in assessing combat power relative to others. Reflecting this a Navy strategic studies group recently argued: “Navy’s next capital ship will not be a ship. It will be the Network of Humans and Machines, the Navy’s new center of gravity, embodying a superior source of combat power.” In this the size of any individual vessel may become less significant with connectivity and the role it plays within an integrated force structure more important attributes.
Secondly, there are many issues today with incompatible datalinks whether intra-service, inter-service or between nations but perhaps some problems can be shifted to the cloud. Key issues for tactical users of cloud data include who generated the data (i.e. can it be trusted), when was it last refreshed (i.e. its data latency) and is its fidelity sufficient for the weapons that might be used.
While at times a hard coupling via a compatible datalink between weapon-firing platform and distant detecting sensor is suggested, the data sent to the cloud could rather include information on both the data’s quality and that of the collection sensors e.g. each sensor’s track error basket. The weapon-firing platform can then access necessary data from any source and become sensor agnostic. The weapon-firing platform can merge this data onboard the platform in a manner broadly similar to the CEC concept. This can reduce to some degree the inherent data latency problems in combat cloud concepts.
High fidelity data is not needed all the time, or for all the contacts detected, only when it is necessary to support weapon employment against specific tracks. Instead, the necessary real-time, high-quality, secure targeting data (which varies depending on the weapon being used) just needs to be available on demand. The emerging Communications-as-a-Service (CaaS) concept aims to create such an on-demand network via a combination of tactical datalinks. The underlying idea is not to translate data into different formats but instead to encapsulate the data appropriately. There are many challenges in implementing CaaS that the earlier CEC discussion will have already suggested including sensing the data latencies, loss rates, throughput, and congestion of the datalinks being used; establishing data paths based on bounded latency and tolerance to loss of data; and deterministic networking to assure the delivery of the highest priority data reliably.
Thirdly, the datalink communications being used to access combat cloud data is an obvious vulnerability. These transmissions may be detected by an adversary and geo-located, allowing the associated platform – ship or aircraft – to be attacked. In previous times, an oft-used tactic was to go silent and not transmit at all; the likelihood of an adversary detecting the platforms presence and of identifying it was then significantly lowered. The distributed lethality concept though means all involved will be continually emitting and can be readily detected, tracked and targeted.
Given this, network participants need to have a self-defence capability as they can reasonably expect to be attacked. Survivability then becomes an issue of increased importance. In this, with ships likely to be damaged, it may be prudent to push forward ship repair capabilities to be near an operational area. This would allow more timely repairs to be completed allowing damaged vessels to rejoin the fight faster.
This concern is however, at odds with the earlier discussion about ship size now being less important. A large naval cruiser may have more extensive self-defense capabilities than a small frigate combatant. The larger ship will also have many more crew to be able to undertake urgent battle damage repairs when needed, unlike in a smaller ship where uncontained damage may result in the ship’s loss.
Fourthly, the quality of the targeting data that the combat cloud needs to hold depends on the weapons being used. As earlier noted the active SM-6 missile can handle greater data latencies and larger error baskets than other missile sensor types. If the quality of the data in the combat cloud is poor – and in a latency sense it might be if using SATCOM information – it may still be possible to target if the weapon’s sensor has a large field of view. This would be particularly so if attacking slow moving targets like ships but clearly more problematic for fast moving aircraft and missiles.
The extension of this is that if high-quality data can be guaranteed than weapons could be developed featuring low cost, unsophisticated sensors as the network could be relied on to get the weapon very close to the target. While sensible for low-intensity conflicts where the target may be worth less than the highly complex guided weapon attacking it, in near-peer wars this seems a dangerous approach. In more difficult wars an adversary might employ jamming, deception, or cyber techniques to seriously degrade the network. If so, network-dependent weapons might be negated.
Lastly, and looking forward to the already-upon-us unmanned vehicle era, future combat cloud and distributed lethality networks will need to be developed with the requirements of unmanned systems in mind. For example, the Navy’s future frigate vision is of a relatively small warship operating a localized sensor network that uses “passive onboard sensors, embarked aircraft and elevated/tethered systems and unmanned vehicles to gather information and then act as a gateway to the fleet tactical grid using resilient communications systems and networks.” Such a frigate will fight within contested environments using a complicated and diverse constellation of networked manned and unmanned air, surface and subsurface systems.
Thinking about our earlier discussion though raises issues with this vision. If the constellation is simply providing sensor data, then loose integration with the frigate might be acceptable, perhaps similar to the older Link 11 and Link 16 datalinks. On the other hand, if the constellation is intended to provide high-quality targeting data like the CEC network, much tighter integration will be necessary – with all its inherent problems.
Future warfighting concepts and network/combat cloud design are now interdependent – with the actual platform design of more secondary importance. In moving to a fifth-generation force, networks and combat clouds are the fundamental building blocks. They need to be got right.
Dr. Peter Layton, PhD is a RAAF Reserve Group Captain and a Visiting Fellow at the Griffith Asia Institute, Griffith University. He has extensive aviation and defence experience, and for his work at the Pentagon on force structure matters was awarded the US Secretary of Defense’s Exceptional Public Service Medal. He has a doctorate from the University of New South Wales on grand strategy and has taught on the topic at the Eisenhower College, US National Defence University. For his academic work he was awarded a Fellowship to the European University Institute, Fiesole, Italy.
The views expressed are those of the author and do not necessarily reflect the official policy or position of the Department of Defense or the U.S. or Australian Governments.