208 can enhance the publish/subscribe logic of the DIP system 200 to allow the publisher of a piece of content to specify known destinations of the content it publishes. In this manner, the RIPL node(s) 208 can immediately send the content to the specified destinations regardless of subscription matches (or lack thereof). Accordingly, the RIPL node(s) 208 can work to eliminate the need to have a base subscription already ingested and break the bootstrapping issue. Thus, regardless of how the RIPL nodes 208 are configured (pre-placed subscriptions or not), a published mission model would be disseminated to all RIPL nodes 208 operating in the DIP network of the combat cloud environment 202.

According to a non-limiting embodiment, the DIP system 200 is configured to communicate knowledge of the state of the network (e.g., the communication status among all RIPL nodes 208) operating in the combat cloud environment 202 to the DIPCE software running on the RIPL nodes 208 so that a given RIPL node 208 can make decisions about the overall mission. In this manner, one or more of the RIPL nodes 208 can publish an updated IERs 209 to change the mission model in response to certain network conditions, triggers, and/or scenario data provided by the MIO devices 230.1-230.6. This knowledge can be provided to an external OMS application listening on the ASB by using OMS Product Metadata (OMSPM) and OMS Product Location (OMSPL) messages that describe the MIO devices 230.1-230.6 and point to a location, e.g., via a Uniform Resource Locator (URL), as shown in FIG. 2.

According to a non-limiting embodiment, the RIPL 208 can be enhanced to provide network knowledge about two main network parameters: (1) attributes of available network paths; and (2) health status of IERs 209. To achieve this enhancement, the underlying networking layer of the RIPL 208 can operate according to the concept of gradient routing to provide efficient multi-QoS routing at the tactical edge, meaning Mobile Ad hoc Networks (MANETs). The network layer informs the content management layer of the reachability status of various nodes in the network as well as path characteristics to these nodes, i.e., the various quality-of-service (QoS) attributes of the paths.

The RIPL nodes 208 can also be enhanced so that subscriptions can be defined to be “local-only”, meaning they require to not be disseminated. To achieve this local-only enhancement, an RIPL node 208 expresses mission communication needs via IERs 209 that define the publishing capabilities and the information needs of RIPL nodes 208. According to a non-limiting embodiment, the IERs 209 can be assigned service levels including Minimum, Normal, Maximum, which express how and when a subscribing RIPL node 208 is willing to receive the information. For example, if an RIPL node 208 is publishing a sensor image periodically, the subscriber RIPL node 208 can express how often and at what resolution it is willing to get that image.

The RIPL node 208 can also be enhanced to publish IER 209 health status information objects. According to a non-limiting embodiment, a RIPL node 208 serving as a receiver node knows the associated IER 209 for a subscription of which it receives a piece of content. As mentioned above, IERs 209 can specify different service levels. A publishing RIPL node 208 can shape the information it sends to subscriber RIPL nodes 208 based on the network conditions and/or scenario data provided by the AOI devices 230.1-230.6 at the time of sending. The RIPL node 208 can shape the content in two domains: size and frequency. Accordingly, a health status can be provided to reflect the overall status of the data reception from a given RIPL node 208 as well as the IER service level that the RIPL node 208 shaped and sent that data.

FIG. 3, is a timing diagram 400 depicting an example of a timeline of data emitted by a sender RIPL node 208 and received by a subscriber RIPL node 208 operating according to the enhancements described above. In a RIPL node 208 described herein, the metadata that accompanies the data specifies the publishing time (at the sender) so that is used to determine the sending period. The relative latency (receive time minus publishing time) gives an indication of how the network is performing over time. Accordingly, the RIPL node 208 publishes an MIO 207 for a publishing RIPL node 208 pair that contains: a timestamp; a IER ID; a publishing node ID; and observed/deduced service point level; a health status: (e.g., normal, degraded, unreachable during which a publisher RIPL node 208 is no longer reachable, silent during which a publisher RIPL node 208 has sent content in the past but no longer sends content.

With continued reference to FIG. 1, the mission layer 220 is in signal communication with the provisional layer 204 to receive the operational data 206. The mission layer 220 is architecturally arranged above the provisioning layer 204 and executes various logic, algorithms, and dynamic mission models to perform decision-making and command execution. The mission layer 220 also exchanges data directly with the MIO devices 230.1-230.6, providing them with timely updates necessary for decision-making. The mission layer 220 provides the MIO devices 230.1-230.6 with directives, which may require system adjustments or the initiation of corrective actions to address emerging issues or optimize network performance of the combat cloud environment 202.

The mission layer 220 includes one or more C2 nodes 222, which serve as a strategic hub within the combat cloud environment 202. The C2 node 222 is configured to receive the operational data 206 (e.g., status data) from one or more of the RIPL nodes 208. The C2 node 222 can execute various mission models 223 and information provisional applications 225, and analyze this data 206 to make informed decisions regarding mission control and operational adjustments. For example, the C2 node 222 processes the incoming published data 206a, (IERs, node metrics, and MIOs) from the provisioning layer 204 and/or the MIO data 207 received from the MIO devices 230.1-230.6 to maintain situational awareness and assess the current mission environment. Based on the analysis of received data 206, the C2 node 222 updates and/or modifies the data 206a, (e.g., the IERs 209) to generate data plans that are returned or published to the provisioning layer 204. These published data plans 206b dictate how operational data should be handled, routed, and prioritized across the combat cloud environment 202 to effectively meet the objectives of one or more mission. Accordingly, the C2 node 222 ensures that the operations of the combat cloud environment 202 align with strategic goals and respond dynamically to evolving scenarios, leveraging real-time data to optimize mission outcomes.

Referring now to FIG. 4, the data exchange between MIO devices 230.1-230.6 and a C2 node 222 that is supervising an overall mission according to a non-limiting embodiment. The MIO devices 230.1-230.6 each operate a respective RIPL node 230.1-230.6. The C2 node 222 operates with RIPL node 208.0 to establish the DIP system 200 that serves as a command link, which is in signal communication with each of the MIO devices 230.1-230.6.

In this example the MIO devices 230.1-230.6 can be referred to as “scenario nodes” 230.1-230.6, each which perform respective missions to achieve the overall mission supervised by the C2 node 222. The scenario nodes 230.1-230.6 can include stationary nodes and/or mobile nodes. In this example, the scenario nodes 230.1-230.6 include one or more satellite nodes 230.1, one or more Intelligence, Surveillance and Reconnaissance (ISR) nodes 230.5, one or more Offensive Counterattack (OCA) nodes 230.3, one or more strike node and a Suppression of Enemy Air Defense (SEAD) nodes 230.4, one or more Special Operations Force (SOF) entities 230.6, and one or more Data Ferry nodes 230.2. The satellite node(s) 230.1 are configured to relay data from one or more of the remaining scenario nodes 230.1-230.6 to the C2 node 222, and vice versa. The ISR node(s) 230.5 can provide imagery and tracking data of adversarial air and/or ground forces. The OCA nodes 230.3 can serve to keep some adversarial air forces at bay. The SEAD nodes 230.4 are tasked as a primary strike force with a mission to strike adversarial forces. The SOF entities 230.6 perform various missions on the ground while exchanging data via the satellite node. The Data Ferry node(s) 230.2 showcases the ability for a RIPL node 208 (see FIG. 1) to communicate in a Disadvantaged, Intermittent, high-Latency (DIL) environment.

According to a non-limiting embodiment, RIPL node 208.0 can automatically receive MIOs 207 from the scenario nodes 230.1-230.6 in response to certain types of triggers throughout a mission execution and the C2 node 222 can dynamically modify the IERs 209 based on an MIO 207. The types of triggers include, but are not limited to, tasking or re-tasking of the scenario nodes 230.1-230.6 during the overall mission execution and changes in network conditions affecting the information exchanges. As shown in FIG. 4, the C2 node 222 can react to scenario data 207 received from the 230.1-230.6 to change and disseminate a mission's IERs 209, which are then provided to the scenario nodes 230.1-230.6.

An example scenario will now be described with continued reference to FIG. 4. In this scenario the data-ferry node 230.2 is alternately connected to the C2 node 222 via RIPL node 208, then completely disconnected from any of the remaining scenario nodes, then connected to one of the ISR node 230.5, then completely disconnected again and then connected again to the C2 node 222, and the cycle of disconnection connections repeats. Given the resiliency and robustness of the RIPL data exchange protocols, this allows data to flow to and from the isolated ISR node 230.5 over time from and to the other scenario nodes 230.5 operating in the combat cloud environment 202, with the data-ferry node 230.2 carrying the data back and forth to the scenario nodes 230.1-230.6 it is connected to one at a time.

During the course of the overall mission, for example, communication with the SEAD node 230.4 is lost and as a result the strike mission is assumed to have failed. RIPL node 208.0 receives an MIO 207 indicating loss of communication with the SEAD node 230.4 and the C2 node 222 then modifies the mission model to task a pair of OCA nodes 230.3 to strike the target initially assigned to the SEAD node 230.4. The mission modification requires the IERs 209 of the OCA nodes 230.3 to be modified as they now need to receive adversarial ground tracking information and imagery on top of the adversarial air tracking data they were already receiving. The SOF element 230.6 connects to the rest of the scenario nodes 222 via the satellite node 230.1 and receives adversarial ground tracking information. Using encrypted text-based messages, for example, the SOF entities 230.1 requests Close Air Support (CAS) to strike a secondary ground target as well as additional reconnaissance data. The C2 node 222 can then repurpose the SEAD node 230.4 and task it with the CAS strike. The C2 node 222 is then tasked to manage the isolated ISR node 230.5 with a different reconnaissance task. As a result of these new tasks, the IERs 209 for SEAD 230.4 and for the isolated ISR 230.5 are modified. Throughout the course of the overall mission, the modified mission model is published by the DIPCE server 213 on the C2 node 222. The RIPL software executed by the RIPL node 208.0 then disseminates the modified IERs 209 indicating the modified mission model to all the scenario nodes 230.1-230.6 operating in the combat cloud environment 202. At least one advantage of the DIP system 200 described herein resides in the automation and the speed of deployment of the new IERs rather than requiring human intervention to modify the IERs and manually set up new communication channels. Such human intervention can take a significant amount of time and is susceptible to human error which can be detrimental to the overall mission.

Referring now to FIG. 5, an operation flow process of the combat cloud environment 202 is illustrated according to a non-limiting embodiment. In this example, the combat cloud environment 202 includes a DIP system 200 and a plurality of MIO devices 230.2-230.6. The DIP system 200 includes a C2 node 222 operating RIPL node 208.0, while each of the MIO devices 230.2-230.6 operate their respective RIPL node 208.2-208.6. The combination of the C2 node 222 and RIPL node 208.0 is referred to as “node 1”, while the combination the MOI devices 230.2-230.6 and respective RIPL node 208.2-208.6 are referred to as “nodes 2 through 6.”

Upon detecting a change in the rate of information served via a subscription due to a broken link 201 between nodes 2 and 4, node 4 creates and publishes an MIO 207 about this finding, which gets disseminated from node 5 to the C2 via RIPL 208.0 of node 1. As a result, mission replanning determines that a new asset (e.g., node 3) be dispatched into theater to provide additional networking. Accordingly, the mission replanning leads to node 3 becoming available and able to communicate with nodes 2 and 4 via a new communication path, thereby compensating for the broken link 201. In addition, the C2 node 222 publishes updated IERs 209 that affect prioritization of traffic across multiple missions sets.

Turning to FIG. 6, a method for performing dynamic adaptation of mission models in a combat cloud environment is illustrated according to a non-limiting embodiment of the present disclosure. The method begins at operation 700 and at operation 702 data is received from a plurality of nodes performing a mission according to mission requirements within a combat cloud environment. At operation 704, a publish/subscribe system is utilized to distribute mission-critical information based on predefined information exchange requirements (IERs). At operation 706, the IERs are dynamically modified in response to detecting changes in one or both of network conditions of the data communications network and the mission requirements. At operation 708, updates for the mission models are automatically disseminated to the plurality of nodes to facilitate real-time operational adjustments, and the method ends at operation 710.

Referring to FIG. 7 a block diagram of an example of a computer system 100 capable of operating the DIP system 200 is illustrated according to a non-limiting embodiment of the present disclosure. Computer system 100 includes a bus 102 or other communication mechanism for communicating information, and a hardware processor 104 coupled with the bus 102 for processing information. Hardware processor 104 may be a general-purpose microprocessor.

Computer system 100 also includes a main memory 106, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 102 for storing information and instructions to be executed by processor 104. Main memory 106 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 104. Such instructions, when stored in one or more non-transitory storage media accessible to processor 104, render computer system 100 into a special-purpose machine that is customized to perform the operations specified in the instructions.

Computer system 100 further includes a read only memory (ROM) 108 or other static storage device coupled to bus 102 for storing static information and instructions for processor 104. A storage device 110, such as a magnetic disk or optical disk, is provided and coupled to bus 102 for storing information and instructions.

Computer system 100 may be coupled via bus 102 to a display 112, such as a liquid crystal display (LCD), plasma display, electronic ink display, cathode ray tube (CRT) monitor, or any other kind of device for displaying information to a computer user. An input device 114, including alphanumeric and other keys, may be coupled to bus 102 for communicating information and command selections to processor 104. Alternatively or additionally, computer system 100 may receive user input via a cursor control 116, such as a mouse, a trackball, a trackpad, or cursor direction keys for communicating direction information and command selections to processor 104 and for controlling cursor movement on display 112. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. Alternatively or additionally, computer system 100 may include a touchscreen. Display 112 may be configured to receive user input via one or more pressure-sensitive sensors, multi-touch sensors, and/or gesture sensors. Alternatively or additionally, computer system 100 may receive user input via a microphone, video camera, and/or some other kind of user input device (not shown).

Computer system 100 may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware, and/or program logic which in combination with other components of computer system 100 causes or programs computer system 100 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 100 in response to processor 104 executing one or more sequences of one or more instructions contained in main memory 106. Such instructions may be read into main memory 106 from another storage medium, such as storage device 110. Execution of the sequences of instructions contained in main memory 106 causes processor 104 to perform the process steps described herein. Alternatively or additionally, hard-wired circuitry may be used in place of or in combination with software instructions.

In an embodiment, one or more non-transitory computer-readable storage media store instructions that, when executed by one or more hardware processors, cause performance of any of the operations and/or methods described herein and/or recited in any of the claims.

Any combination of the features and functionalities described herein may be used in accordance with an embodiment. In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the Applicant to be the scope of the invention, is the literal and equivalent scope of the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction.

In an embodiment, techniques, methods, and/or operations performed by the DIP system 200 described herein are implemented by one or more special-purpose computing devices (i.e., computing devices specially configured to perform certain functionality). The special-purpose computing device(s) may be hard-wired to perform the techniques and/or may include digital electronic devices such as one or more application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), and/or network processing units (NPUs) that are persistently programmed to perform the techniques. Alternatively or additionally, a computing device may include one or more general-purpose hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, and/or other storage. Alternatively or additionally, a special-purpose computing device may combine custom hard-wired logic, ASICs, FPGAs, or NPUs with custom programming to accomplish the techniques. A special-purpose computing device may include a desktop computer system, portable computer system, handheld device, networking device, and/or any other device(s) incorporating hard-wired and/or program logic to implement the techniques.

The term “storage media” as used herein refers to one or more non-transitory media storing data and/or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 110. Volatile media includes dynamic memory, such as main memory 106. Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape or other magnetic data storage medium, a CD-ROM or any other optical data storage medium, any physical medium with patterns of holes, a RAM, a programmable read-only memory (PROM), an erasable PROM (EPROM), a FLASH-EPROM, non-volatile random-access memory (NVRAM), any other memory chip or cartridge, content-addressable memory (CAM), and ternary content-addressable memory (TCAM).

A storage medium is distinct from but may be used in conjunction with a transmission medium. Transmission media participate in transferring information between storage media. Examples of transmission media include coaxial cables, copper wire, and fiber optics, including the wires that comprise bus 102. Transmission media may also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 104 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a network, via a network interface controller (NIC), such as an Ethernet controller or Wi-Fi controller. A NIC local to computer system 100 may receive the data from the network and place the data on bus 102. Bus 102 carries the data to main memory 106, from which processor 104 retrieves and executes the instructions. The instructions received by main memory 106 may optionally be stored on storage device 110 either before or after execution by processor 104.

Computer system 100 also includes a communication interface 118 coupled to bus 102. Communication interface 118 provides a two-way data communication coupling to a network link 120 that is connected to a local network 122. For example, communication interface 118 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 118 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 118 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link 120 typically provides data communication through one or more networks to other data devices. For example, network link 120 may provide a connection through local network 122 to a host computer 124 or to data equipment operated by an Internet Service Provider (ISP) 126. ISP 126 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 128. Local network 122 and Internet 128 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 120 and through communication interface 118, which carry the digital data to and from computer system 100, are example forms of transmission media.

Computer system 100 can send messages and receive data, including program code, through the network(s), network link 120 and communication interface 118. In the Internet example, a server 130 might transmit a requested code for an application program through Internet 128, ISP 126, local network 122, and communication interface 118.

The received code may be executed by processor 104 as it is received, and/or stored in storage device 110, or other non-volatile storage for later execution.

In an embodiment, a computer network provides connectivity among a set of nodes running software that utilizes techniques as described herein. The nodes may be local to and/or remote from each other. The nodes are connected by a set of links. Examples of links include a coaxial cable, an unshielded twisted cable, a copper cable, an optical fiber, and a virtual link.

A subset of nodes implements the computer network. Examples of such nodes include a switch, a router, a firewall, and a network address translator (NAT). Another subset of nodes uses the computer network. Such nodes (also referred to as “hosts”) may execute a client process and/or a server process. A client process makes a request for a computing service (for example, a request to execute a particular application and/or retrieve a particular set of data). A server process responds by executing the requested service and/or returning corresponding data.

A computer network may be a physical network, including physical nodes connected by physical links. A physical node is any digital device. A physical node may be a function-specific hardware device. Examples of function-specific hardware devices include a hardware switch, a hardware router, a hardware firewall, and a hardware NAT. Alternatively or additionally, a physical node may be any physical resource that provides compute power to perform a task, such as one that is configured to execute various virtual machines and/or applications performing respective functions. A physical link is a physical medium connecting two or more physical nodes. Examples of links include a coaxial cable, an unshielded twisted cable, a copper cable, and an optical fiber.

A computer network may be an overlay network. An overlay network is a logical network implemented on top of another network (for example, a physical network). Each node in an overlay network corresponds to a respective node in the underlying network. Accordingly, each node in an overlay network is associated with both an overlay address (to address the overlay node) and an underlay address (to address the underlay node that implements the overlay node). An overlay node may be a digital device and/or a software process (for example, a virtual machine, an application instance, or a thread). A link that connects overlay nodes may be implemented as a tunnel through the underlying network. The overlay nodes at either end of the tunnel may treat the underlying multi-hop path between them as a single logical link. Tunneling is performed through encapsulation and decapsulation.

In an embodiment, a client may be local to and/or remote from a computer network. The client may access the computer network over other computer networks, such as a private network or the Internet. The client may communicate requests to the computer network using a communications protocol, such as Hypertext Transfer Protocol (HTTP). The requests are communicated through an interface, such as a client interface (such as a web browser), a program interface, or an application programming interface (API).

In an embodiment, a computer network provides connectivity between clients and network resources. Network resources include hardware and/or software configured to execute server processes. Examples of network resources include a processor, a data storage, a virtual machine, a container, and/or a software application. Network resources may be shared amongst multiple clients. Clients request computing services from a computer network independently of each other. Network resources are dynamically assigned to the requests and/or clients on an on-demand basis. Network resources assigned to each request and/or client may be scaled up or down based on, for example, (a) the computing services requested by a particular client, (b) the aggregated computing services requested by a particular tenant, and/or (c) the aggregated computing services requested of the computer network. Such a computer network may be referred to as a “cloud network.”

In an embodiment, a service provider provides a cloud network to one or more end users. Various service models may be implemented by the cloud network, including but not limited to Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS). In SaaS, a service provider provides end users the capability to use the service provider's applications, which are executing on the network resources. In PaaS, the service provider provides end users the capability to deploy custom applications onto the network resources. The custom applications may be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, the service provider provides end users the capability to provision processing, storage, networks, and other fundamental computing resources provided by the network resources. Any applications, including an operating system, may be deployed on the network resources.