When attempting to plan and optimize the allocation of scarce or expensive resources, the situation can be viewed as a problem of supply and demand. This perspective applies to many domains that include satellite tracking, transportation, energy, and, of course, one with which everyone can relate, the supply and demand of healthcare resources.
Delivering communications to the warfighter should also be viewed as a supply and demand problem: creating efficiencies and cost savings while supporting the warfighter’s mission. Braxton Technologies has considered this problem, in concert with subject matter experts in several domains, and offers a unique perspective to address the supply and demand problem within the Military Satellite Communications (MILSATCOM) domain.
No matter how simple the concept seems, supply and demand must first be defined within the domain, as the variations of allocable assets quickly becomes complicated. At the macro level, MILSATCOM and Commercial Satellite Communications (COMSATCOM) supply equates to the space and ground assets available to support communication needs.
Various types of communications, protection levels, frequency bands, bandwidth, and a plethora of other aspects that are understood by most MilsatMagazine, must be addressed. In many cases, ground infrastructure resources are tightly coupled with the space segment. Demand refers to the requirements or requests for tactical or strategic communications, and includes voice, data, or video. Literally thousands of requests at any moment can represent the demand on the MILSATCOM infrastructure and, when considering COMSATCOM as an option, those commercial systems have other customer demands to manage, as well.
Organizing the resource structure is tricky with a domain this complex but is a critical step toward achieving optimal allocation of those resources. Ideally, the intent is to create a resource tree structure with the basic type of communication at the top of the tree (i.e., Wideband, Protected, Narrowband, and even Commercial).
The second level includes the specific systems: Wideband Global SATCOM and Defense Satellite Communications System under Wideband; Milstar and Advanced EHF (AEHF) under Protected; and MUOS under Narrowband.
Under the Commercial tree, the orbital regime at the next level (Geo vs. Leo) with the level after that organized by the owner-operator’s constellations may be considered. The structure continues to the point where a specific resource is allocated (a transponder for example, or even a channel).
Each of the lowest level resources is further defined by the effect they provide (voice, messaging, data, and even big data). However, what can make this structure powerful is to create categories and subcategories of allocable resources that cross over between constellations and major communication types.
For example, an approach that crosses DoD and commercial constellations requires an understanding of the assets available for a specific request or requirement. Therefore, when a request is presented for a communications type, all available assets which meet the request are considered.
Tasks to which the resources are allocated represent the demand side of the equation, either through a persistent/strategic requirement or an immediate/tactical request for communications. On the surface, tasks within the MILSATCOM domain may appear simple: a user needs to communicate with another entity from time A to time B.
However, the task request can get complex as a system considers the basic type of communications needed to complete the mission. Such communications can include the level of security, the equipment available on the ground or within the weapon system, and even the location, altitude and speed of the warfighter requiring the communications. To ensure that the proper demand of all resources is presented and the correct resources are allocated, the specific request must be detailed, directly down to the exact constraint within the request.
Constraints generally align with the task request and include the details specific to the MILSATCOM domain to allow allocation of an exact resource type, including bandwidth, frequencies and more. There are two constraint types that apply to nearly every resource domain, including MILSATCOM: the window constraint and the time-specific constraint.
Figure 1. MILSATCOM Resource Structure
The window constraint allows the system some flexibility to allocate the resource while considering other requests—for example, a warfighter needs specific communications but can actually use the communication any time during a specified window.
A time-specific constraint, on the other hand, could involve a submarine surfacing or a ground mission occurring at a specific time—in this case, the allocation of exact resources is essential when considering all the demand for the resources across the MILSATCOM enterprise.
In a nutshell, the appearance is that every aspect of the resource allocation process within the MILSATCOM domain is “complex”—but far worse is ahead. Defining the relationships between resources and the tasks (say, the user on the ground) is especially complex when considering the allocation of orbiting space resources.
Compounding the problem is the orbiting space asset that often has a direct relationship with another ground asset (for instance, a Globalstar satellite and a gateway). Resource allocation is significantly impacted by the geometrical relationships between the resources and the targets.
These relationships limit the availability of a resource to perform the required task. Referred to as the “feasible region,” the system performs allocations across the enterprise while calculating the relationship of a resource to the target.
Figure 2. Example1 Objective Functions
Orbiting objects and fixed ground assets present one problem, but what if the communication resource moves in a sub-orbital fashion (e.g., an aircraft), eliminating the use of pure math and known models to predict the exact location of the resource? This is a complex, but critical, aspect of the planning, whether long term or real-time.
Another key component of the resource allocation problem is to consider the objectives that need to be solved within the MILSATCOM domain. Flexibility is essential, but the system’s ability to solve for more than one objective also enhances the system’s effectiveness.
For example, one valuable objective is to satisfy as many communications requirements and requests as possible, or even to satisfy all requirements or requests placed on the MILSATCOM enterprise at any point in time. Another objective is to reduce the cost or allocate the resources in the most affordable manner possible. Affordability could mean the system allocates more (or less) commercially available resources.
Use of more than one, or even several objectives at a time, allows the analyst, planner or commander to address many higher-level requirements, including objectives that appear to be in direct conflict with each other.
Therefore, is a system that can perform such a function suitable for long-term planning and real-time decisions? The answer is… partially.
Figure 3. Example 2 Objective Functions
For long-term planning, the MILSATCOM enterprise can facilitate decisions such as the use of commercial versus DoD assets, repositioning a specific asset to a new orbital slot (while considering the cost of the maneuver), or even planning for a new constellation (quantitatively providing information on the exact effect needed and where it should reside). All of these decision types are applicable to such a system, providing a unique picture for the planner.
For real-time operations, today, there are terminal limitations that constrain a user’s flexibility to cross the domains between wideband, narrowband, and protected… and commercial… resources for specific tasks. Given that, in the short term, significant benefit could be gained instead from optimization among MILSATCOM’s major resource types. This would likely result in more efficient allocation of resources and would also free up scarce resources in a single domain where another, more abundant domain can fill the specific mission requirement, enabling far more cost-effective optimization.
In the longer term with greater terminal flexibility, space operators and combatant commanders could have immediate awareness on the stress within the MILSATCOM enterprise, in whole or in part. For example, if an anomaly occurs, operators and commanders could have real-time situational awareness and the system could even automatically provide a reallocation of the resources in response to the anomaly. Additionally, the operator and the commander could see the identical picture at the exact same time as the systems could be networked together, synchronizing the data.
Imagine a system that can provide such visibility and power to the MILSATCOM enterprise. Imagine such is not a custom system, requiring no new software code, but only data consumed by a powerful optimization engine. Imagine if decisions required only seconds, or even less, to complete.
Figure 4. Braxton’s Resource Domain Translator Separates the Physics and the Math
As part of an Air Force Research Laboratory (AFRL) Small Business Innovation Research (SBIR) Phase I contract, Braxton Technologies developed this very technology, which has been added to the company’s existing product suite, Advanced Control Equipment (ACE) Premier™ (ACE Premier™). The product is called Intelligent Resource Optimizer (AceIRO).
Taking advantage of modern computing technologies, the AceIRO architecture provides for distributed operations and is an excellent candidate for parallel processing. At the core, and what provides the resource optimization, AceIRO uses a powerful multi-objective genetic algorithm.
Braxton designed AceIRO as a data-driven system and implemented a patent-pending resource domain translator, which allows even the most complex domains, such as MILCOM, to be translated to this powerful optimization engine. Today, Braxton Technologies is working with a number of subject matter experts within several domains to demonstrate the power and versatility of AceIRO.