Edge-based routing software instance, device and method

Abstract

An edge-based routing (EBR) software instance configured in a device for a multi-transport network architecture is disclosed, the edge-based routing device includes an edge-based routing core having a processor configured to provide service model based data services and utility functions, a client application programming interface configured to receive producer application data and output consumer application data, and a proxy application programming interface configured to establish network layer routed connectivity between producer applications and consumer applications as a function of network conditions and / or capabilities.

Description

[Technical field]

[0001] (cross reference) This international application claims priority to U.S. Provisional Application No. 63 / 305,062, filed January 31, 2022, the entire contents of which are incorporated herein by reference.

[0002] (Technical field) An edge-based routing (EBR) software instance configured as an EBR device for a multi-transport network architecture is disclosed, where edge-based routing encompasses data convergence of a tactical data fabric with multi-level security for message and object-oriented data exchange. Also disclosed is a method for managing communications across multiple networks between network producer applications and network consumer applications using the network edge-based routing (EBR) device. [Background technology]

[0003] Digital transformation can provide a valuable opportunity to move core mission functions away from manual and automated critical areas such as sensors, C2, and fire and effects. This can enable commander decision making while reducing processing time for actionable information in the era of JADC2. Modern efforts address the rapidly growing need for interoperability, situational awareness, and lethality to fight peer adversaries and enable the joint force to converge effects from all domains.

[0004] At the core of Joint All-Domain Command and Control (JADC2) is Command, Control, Computers, Communications, Cyber, Intelligence, Surveillance, and Reconnaissance (C5ISR), and at the heart of the C5ISR mission is data. Data is the commodity commanders need to act intelligently. Data is also needed by Soldiers at all ranks to fire, move, and communicate effectively. Data is leveraged through data dissemination and used for situational understanding.

[0005] In the digital battlefield, the proliferation of currently available data sources and software-driven capabilities, from direct human observation and automated sensors to legacy data now being digitized for a wide range of users, has resulted in a deep reliance on data to make informed decisions. The pace at which software, configurations, and data connections need to be updated and deployed will increase to match the evolving pace of warfighting.

[0006] EBR is a software services framework that can include middleware (e.g., EBR Core) and at least one application programming interface (API) that operates to provide processor-based client applications with a means to discover and provide data across a multi-transport network architecture. EBR can act as a core abstraction, relieving any application of the burden of having to be aware of the available networks and its inherent network capabilities. EBR can leverage each node's available transports and can optionally perform, for example, service and / or sensor discovery, smart routing, and efficient data distribution between client applications and services.

[0007] EBR can use network-aware route selection and link monitoring to sustain data delivery while operating with dynamic topologies. To maximize the density of data delivered in given network conditions (e.g., maximize the data sent over a network path), EBR can use content-aware shaping rules to simultaneously increase data density and reduce traffic load without having to modify applications running on the EBR device. The data shaping capabilities of EBR devices can be useful for capacity-limited network architectures that do not easily or optimally support true end-to-end network layer connectivity. This can result in increased elastic data delivery to end users (e.g., soldiers in a combat environment) and can provide greater confidence in the network architecture.

[0008] The present disclosure addresses the problem of achieving an EBR device system that is domain, platform, and functional mission lane agnostic in the face of today's challenges presented by the ever-evolving combat environment. A viable solution disclosed herein can address the challenges that exist with respect to data persistence and distribution across mixed radio communication architectures / technologies, incompatible data formats, cumbersome planning and management tasks, mixed data classification and security enclaves, and the exploding number of communities looking to leverage the "tactical internet." Exemplary embodiments described herein address this problem by providing a service model-based solution to data distribution in the form of an EBR device and associated methodology, which are described in detail below. Summary of the Invention [Means for solving the problem]

[0009] An embodiment may relate to an edge-based routing device configured for a multi-transport network architecture. The edge-based routing device may include an edge-based routing core having a processor configured to provide service model based data services and utility functions. The edge-based routing device may further include a client application programming interface configured to receive producer application data and output consumer application data. The edge-based routing device may further include a proxy application programming interface configured to establish network layer routed connectivity between producer and consumer applications as a function of network conditions and / or capabilities.

[0010] An embodiment may relate to a method of managing communications across multiple networks between a producer application of a network and a consumer application of a network (e.g., an application running on a network) using a network edge based routing device. The method may include receiving a service model based consumer application request for consumer data at the edge based routing device. The method may further include performing discovery of the consumer data across the multiple networks via the edge based routing device. The method may further include receiving the discovered consumer data of the edge based routing device from the producer application across the multiple networks and a selected transport mechanism appropriate for the network specified for the multiple networks. The method may further include providing a list of available data producer applications via the edge based routing device to a consumer application associated with the service model based consumer application request. The method may further include passing the service model based consumer application request across the multiple networks to the producer application. The method may further include receiving the producer application data at the edge based routing device for transport to the consumer application.

[0011] Other objects and advantages of the present disclosure will become apparent to those skilled in the art upon reading the following detailed description of illustrative embodiments in conjunction with the accompanying drawings, in which like reference numerals are used to designate like elements and in which: [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 illustrates an exemplary edge-based routing device configuration including software function allocation as disclosed herein. [Diagram 2]1 is a flow diagram illustrating an example method for managing communications across multiple networks between a network producer application and a network consumer application using a network EBR device. [Diagram 3] FIG. 1 is a diagram of a notation system illustrating an example tactical landscape in which EBR devices and EBR networks can be implemented. [Figure 4] FIG. 2 illustrates an edge-based routing functional architecture that may be implemented and / or modified as disclosed herein with respect to FIG. 1. [Diagram 5] FIG. 2 illustrates an example edge-based routing device data flow as disclosed herein. [Figure 6] FIG. 2 illustrates an example message routing using proactive advertising messages as disclosed herein. [Figure 7] FIG. 1 illustrates an example message routing performed by a routing engine of an EBR device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] In accordance with an exemplary embodiment of the present disclosure, the EBR device solution leverages available service models and transports to provide resilient access to data, including any critical data, while minimizing any pre-configuration and management burden, enabling a agile operational soldier. The exemplary solution not only provides a transport-agnostic interface to allow applications to access the data they need without needing to know the network, but also understands the network and network conditions, as well as the ability to optimally perform routing selection when data traverses multi-transport (e.g., tactical) network architectures, and the content of the data being moved to enable enhanced shaping.

[0014] Known tactical data distribution techniques do not use a service approach model and flexible network awareness concepts, resulting in an inability to perform routing selection and advanced content shaping to ensure that a rich set of data is delivered under current network conditions.

[0015] An EBR device configured as an example embodiment disclosed herein provides network-aware transport routing in a service model-based data delivery architecture to enable resilient access to data and services connected to dynamic heterogeneous networks. The EBR device uses content awareness, or knowledge of the data, to enable delivery within transport constraints, moving data through the transport using mechanisms that are more efficient when the transport is in use at the time.

[0016] The disclosed exemplary EBR device includes a software service model-based framework including middleware and at least one API that provides client applications with the means to discover and provide data across multi-transport network architectures using the techniques disclosed herein. The EBR device can use enhanced network-aware routing and link monitoring to operate with dynamic topologies while maintaining data services. To maximize the density of data delivered given network conditions, the EBR device uses enhanced content-aware shaping disciplines to increase data density while simultaneously reducing traffic loading without the need to modify applications. For example, when applied to capacity-constrained network architectures that do not readily or optimally support true end-to-end network layer connectivity, increased resilient data delivery can be achieved to benefit end users, such as soldiers in combat environments. Such enhanced robustness can provide greater confidence in network architectures (e.g., tactical network architectures).

[0017] According to the exemplary embodiments, data can be considered as a common product for the network. Access to and exchange of data between consumer applications residing on heterogeneous processing devices can be easily managed when this data is provided as a service using a service model based mindset in the ecosystem. A service as disclosed herein can be considered as a mechanism by which a user accesses specific data via a request such as an advertisement or subscription (e.g., Common Operating Picture (COP)). By using a service model based approach, the exemplary embodiments disclosed herein enable the decoupling of data from 1) the direction in which it is provided to the consumer and 2) how it is transmitted, supporting a variety of different types of networks. These capabilities will be especially important for networks that do not easily or optimally support true end-to-end network layer connectivity. Service-based EBR devices can be considered as a means to provide new and enhanced data delivery capabilities. For example, · Access to transport and network status information when an alarm is observed. · Electronic Support (ES) sensors capable of reporting radio frequency (RF) detection according to required parameters. Distribution of area specific situational awareness (SA) information regardless of the network connection type that is loading the data.

[0018] In some embodiments, a service model (e.g., a service model-based application and / or service that can provide data) can refer to a software application and / or network application that allows one or more consumers (e.g., clients, consumer EBR devices, devices requesting data) to access data that can be made available through one or more producers (e.g., producer EBR devices, producers that collect and / or share data) via a request for the data, whereby the one or more consumers do not have to be specifically configured to access and / or request the data. For example, a service model can include a software application that provides data to multiple clients, where a client device can access and / or request data from the software application via an Internet connection and a web browser. In this example, no additional configuration of the client device is required to enable the client device to access and / or request data from the software application. Thus, the software application can be said to be a service model-based software application because the client device can access data provided by the software application without additional configuration and / or modifications to the client device.

[0019] In a service model-based EBR network, each EBR device in the EBR network can provide data to other EBR devices in the EBR network in response to a request for data. The service model can further refer to a network of devices (e.g., EBR devices) in which the device requesting the data is decoupled from the format of the data, such that the device requesting the data (e.g., consumer device) does not need to be specifically configured to request and / or receive data from the device collecting and / or providing the data (e.g., producer device) to the device requesting the data. Thus, the service model allows multiple devices in the network to request data when the data is requested without requiring any special configuration of each device of the multiple devices. Each device of the multiple devices can be unaware (e.g., not specifically configured) of the mechanisms by which data can be collected, formatted, and / or transported within the network (e.g., service model-based network) or how the data is collected, formatted, and / or transported by an application (e.g., service model-based application).

[0020] As an example, a service model based data service can include a software application that can expose one or more collections of related information via an interface that can be of interest to a given community (e.g., a community of consumer EBR devices) regardless of the system and / or system configuration (e.g., sensors, producer EBR devices, etc.) that is generating the data. This related information (e.g., data) can be grouped within an EBR network such that the data is discoverable by consumer EBR devices that can use the service name in a request without having to specifically configure the consumer EBR device. As a further example, a producer EBR device can provide a location report where the location represents data including the reported location of a user or platform. The location report can include location, identification, and date and / or time. Thus, a consumer EBR device can request a location report by sending a request that includes the service name, and the consumer EBR device does not need to be specifically configured to interact with and / or connect to the service that provides the location report.

[0021] Exemplary processor-stored consumer applications can achieve expanded and / or efficient access to discoverable data and services using a set of APIs, as opposed to known network-specific mechanisms. Processors configured with such client applications (e.g., consumer applications, producer applications) can utilize APIs to register and / or advertise capabilities, as well as register and / or advertise data or types of data, and client applications can own storage devices (e.g., any available hardware memory) locally or remotely (e.g., cloud or centralized databases) for other processor-based devices to discover and access.

[0022] Furthermore, through this same API, processor-based applications can perform data services and / or sensor discovery or requests for data or services of interest to select users or processor-based data consuming devices.

[0023] In some embodiments, a producer application may refer to a software application (e.g., software instructions) executing on a processor of an EBR device (e.g., a producer EBR device) where the EBR device can collect data (e.g., via one or more sensors) for providing to other EBR devices (e.g., consumer EBR devices) of the EBR network. The producer application may manage a collection of data for the EBR device and / or may manage sensors of the EBR device (e.g., a camera of the EBR device) configured to collect data. The producer application may be configured to manage producer application data present on the EBR device that is collecting the data, and the producer application may include one or more interfaces whereby the producer application data present in the producer application may be shared with and / or sent to the EBR device whereby the EBR device can share the producer application data with other EBR devices of the EBR network. For example, the producer application data may be made accessible to the consumer EBR device via a service model-based data service associated with the producer application data. Service model-based data services can be made discoverable by consumer EBR devices via an EBR service framework that enumerates available data services.

[0024] In some embodiments, a producer application may include any software program, software application, and / or system capable of generating data that is provided (e.g., via an interface) for access to consumer applications in the EBR network. Enabling delivery of data to consumer applications may be accomplished by associating the data with a data service of the EBR network and providing the data via the data service. The data service may be discoverable via an EBR service framework, which includes a list of multiple data services that can be provided to EBR devices of the EBR network.

[0025] In some embodiments, a consumer application may refer to a software application (e.g., software instructions) executing on a processor of an EBR device (e.g., a consumer EBR device) that enables the EBR device to request and / or retrieve data from other EBR devices (e.g., producer EBR devices) in the EBR network. The consumer application may manage the retrieval of data from the EBR device and / or manage the use of the data in the consumer application. For example, a consumer application may receive producer application data from a producer EBR device, and the consumer application may use the data to generate output, such as output for displaying GUI elements (e.g., charts, pictures, etc.) so that the data can be viewed by a user of the EBR device. Additionally or alternatively, the consumer application may use the producer application data to perform analytics and generate output from the consumer application to the EBR device. A consumer application can be configured to manage consumer application data present on an EBR device that is receiving the producer application data, and the consumer application can include one or more interfaces that allow the producer application data to be shared and / or transmitted from other EBR devices, thereby allowing the EBR devices to share the producer application data with the consumer application. For example, a consumer application running on a consumer EBR device may be interested in receiving or accessing producer application data made available by a producer EBR device. The consumer application can access and / or receive the producer application data via discovery of a data service associated with the producer application data of the producer application of the producer EBR device.Using a request that includes the name of a data service, the consumer EBR can access and / or receive producer application data made available by the producer EBR device.

[0026] In some embodiments, a consumer application may include any software program, software application, and / or system that may be interested in receiving and / or accessing data made available by a producer application in the EBR network. The means by which a consumer application may receive data generated by a producer application (or generated via a sensor associated with a producer EBR device) may be accomplished through discovery of associated data services in the EBR network. That is, a consumer application may discover associated data services by sending a request requesting data. A consumer application may receive a list of data services that can provide data to the request via associated data service discovery.

[0027] In some embodiments, producer application data may refer to data collected and / or maintained by a producer application executing on an EBR device acting as a producer (e.g., a producer EBR device). For example, an EBR device acting as a producer may collect data and send the data to a consumer EBR device that requested the producer application data. Producer application data may reside in a producer application executing on an EBR device acting as a producer.

[0028] In some embodiments, consumer application data may refer to data received and / or maintained by a consumer application executing on an EBR device acting as a consumer (e.g., a consumer EBR device). For example, an EBR device acting as a consumer may request data from one or more producer EBR devices, and an EBR device acting as a consumer may receive the requested data from one or more producer EBR devices. Consumer application data may reside in a consumer application executing on an EBR device acting as a consumer.

[0029] Although producer applications, consumer applications, producer application data, and consumer application data are described herein as residing and / or executing on producer EBR devices and / or consumer EBR devices, the role of an EBR device in an EBR network may include producer, consumer, or both producer and consumer at a given instance depending on the operation of the EBR device. Thus, the terms producer application, consumer application, producer application data, consumer application data, producer EBR device, and consumer EBR device should not be limited to a particular EBR device, but may be applied appropriately in situations where an EBR device in an EBR network is operating as a producer, a consumer, or both a producer and a consumer.

[0030] Decoupling of application and transport is one improvement provided by EBR devices and networks. This decoupling can be configured as described herein to achieve the key benefit of providing a transport independent interface for user facing applications without the need to know the network. This understanding of the network, its conditions, and capabilities allows for robust performance of routing and enhanced shaping of data as it traverses the multi-transport tactical fabric.

[0031] The EBR device disclosed herein provides an innovative method to address data discovery and distribution in denied, degraded, intermittent or limited (DDIL) and / or disadvantaged, disconnected, intermittent or limited (DDIL) network architectures. To maintain reliable distribution of data, the new EBR method disclosed herein leverages one or more of the following modalities in an integrated manner to address current data transport issues such as those facing the US DoD in tactical operations. Four exemplary innovations employed in accordance with exemplary embodiments of the EBR device disclosed herein are: Data Through Services - Exemplary embodiments can leverage a service model based method of data delivery to provide EBR devices with a means to discover, advertise, and access data across a communications fabric, such as a tactical communications fabric via geo-based publish / subscribe, request / response, and other asynchronous model mechanisms. Network-Aware Transport Routing - Exemplary embodiments can provide resilient access to data and services connected to dynamic, heterogeneous (e.g., tactical) networks (e.g., the U.S. Army Integrated Combat Network (ITN) Capability Set Architecture). Content Aware Data Shaping - Exemplary embodiments can enable delivery of the richest data given network conditions and capabilities through novel content shaping in a service model based environment. Transport-independent but aware operation - exemplary embodiments can provide services using lightweight transport-friendly mechanisms without burdening applications with the need to be aware.

[0032] FIG. 1 illustrates an exemplary functional allocation of a service model based EBR device node that contains software modules (e.g., applications, services, microservices, etc.) configured in hardware according to the present disclosure, where the EBR device is in a system that includes processor-based applications that use the EBR data services framework. The various components of FIG. 1 may be implemented on a common processor or on any number of interconnected dedicated processors with associated memory and communication I / O interface devices. Each of the components illustrated in FIG. 1 will be described in the context of an exemplary embodiment.

[0033] With reference to FIG. 1, an embodiment relates to an edge-based routing (EBR) device configured for a multi-transport network architecture that includes a software function allocation configuration 100 as disclosed herein. The EBR device configuration 100 can include an EBR core 102 having a processor configured to provide service model based data services and utility functions. The EBR device configuration 100 can include a client application programming interface (API) 104 configured to receive producer application data and output consumer application data. The EBR device configuration 100 can include a proxy API 106 configured to establish network layer routing connectivity between producer and consumer applications as a function of network conditions and / or capabilities.

[0034] A service model based data service may include a software application (e.g., software instructions) executing on a processor that may cause the processor to provide (e.g., expose to other applications, interfaces, etc.) a collection of related information (e.g., data) that may be of interest to a given community regardless of the system generating the information. Data may be grouped within the EBR network so that it can be discovered using a service name that is associated with the group of data. For example, a location report may reflect the reported location of a user or platform. The location report may include location, identification, data, and / or time.

[0035] 1, the EBR device configuration 100 may further include a client application 108, a tasking graphical user interface (GUI) 110, a sensor driver 112, and one or more custom applications 114, each executing on a processor of the EBR device. The EBR core 102 may execute on the EBR device processor. The EBR core 102 may include an associated microservices application that allows the EBR core 102 to communicate with one or more client applications 108, tasking GUI 110, sensor driver 112, and one or more custom applications 114 executing on the EBR device. In some embodiments, the EBR core 102 and associated microservices application may communicate with one or more client applications 108, tasking GUI 110, sensor driver 112, and one or more custom applications 114 executing on another EBR device connected to the EBR network. An EBR device that includes the EBR device configuration 100 can communicate with other EBR devices in the EBR network via a client API 104 and / or a proxy API 106 that are included to assist the EBR core 102 .

[0036] The EBR core 102 of the EBR device can communicate with an administration web graphical user interface (GUI) 116, a model nexus 120 (e.g., tensorflow serving), and a database service 122 (e.g., relational database, NoSQL database, etc.). The administration web GUI 116 can include a microservices web dashboard. The administration web GUI 116 can provide user control and / or access to initialize and / or configure the EBR instance, the EBR core 102, and / or the EBR device. For example, the administration web GUI 116 allows a user to modify runtime settings on the EBR device while the EBR device is connected to a live EBR network. A user can modify settings such as data shaping features. Additionally, a user can view the live status of the EBR core 102 and the EBR network including multiple EBR nodes.

[0037] Model nexus 120 can include microservice applications that can enable edge inference and management of machine learning models. An exemplary model nexus 120 can be built around an open source inference engine, such as tensorflow serving, which is part of the tensorflow extensions (TFX) architecture. Model nexus 120 can assist in serving and unserving machine learning models used by EBR 102. Model nexus 120 can return inferences based on data from EBR core 102. Model nexus 120 can generate inferences for EBR core 102 using custom processing functions and custom trained machine learning models. Model nexus 120 can send any inferences generated to EBR 102 for processing and / or consumption.

[0038] Model nexus 120 may also utilize the TensorFlow data validation library to implement a data drift service. The TensorFlow data validation library may detect schema drift by comparing the schema of the training data to the schema of the serving data using a TFX component called SchemaGen to check for data errors and / or anomalies. TFX may also detect data skewness and / or data drift by comparing statistics of the training data to statistics of the serving data using a TFX component called StatisticsGen. Data drift may be an optimal service for data requests, and thus the data drift service may be initialized when the data drift service is requested, for example, as part of EBR tasking or a local client interfacing directly with TFX.

[0039] The data drift service can be asynchronous to the model serving service of model nexus 120 and can be turned off if not needed. Data drift can include triggers to capture and retain training data used for anomaly detection and / or model retraining. Detection of data drift and anomalous data capture can result in delivery of the captured data if network conditions permit. Otherwise, alerts and notifications of collected data can be sent to requesting consumer EBR devices.

[0040] The database service 122 may include a microservices application that enables the EBR core 102 to communicate with a database (e.g., a database the same as or similar to the data store 412). The database service 122 may include a layer of abstraction that allows for easy cross-platform support and use of a wide variety of different databases without the need to specially configure the EBR core 102, the EBR device, and / or the database service 122. The database service 122 may include functionality that operates with EBR tables, such as clients, nodes, and tasking, as well as any data service specific tables. The data service specific tables may be initialized and interacted with by extending abstract classes provided by the EBR software development kit (SDK) (e.g., Centra SDK). An exemplary database service 122 may associate a relational database, a NoSQL database, or another suitable type of database.

[0041] The EBR core 102 of the EBR device configuration 100 may further include one or more data services 118, such as electronic sensor support, current operating procedures, software configuration management, one or more custom data services, etc. The EBR core 102 may further include one or more utility function engines 120, such as a routing engine, a data shaping engine, a sensor discovery engine, a tasking management engine, etc. The EBR core 102 may connect to one or more client interfaces (e.g., client application 108, tasking GUI 110, etc.) via a client API 104 and associated Google Remote Procedure Call (gRPC) client interfaces, associated REST client interfaces, one or more custom client interfaces, etc. The EBR core 102 may connect to one or more transport proxies 124 and / or proxy libraries 126 via a proxy API 106 and associated gRPC interfaces, one or more custom proxy interfaces, etc.

[0042] A client application 108 executing on an EBR device can expect to consume certain data. An EBR device executing a client application 108 that operates to consume data can be referred to as a consumer device (processor), or a "consumer." A client application 108 executing on an EBR device can have data to provide (e.g., send) to other consuming client applications. An EBR device executing a client application 108 that operates to generate data can be referred to as a producer device (processor), or a "producer." A single processor-based client application executing on an EBR device (e.g., client application 108) can be both a consumer and a producer.

[0043] The EBR core 102 may include one or more utility functions 120 as described herein. The one or more utility functions 120 enable data available for consumption by producers to be dynamically discovered, requested, and delivered to consumers across a network architecture, without either the consumers and / or producers needing to be aware of the mechanism by which the exchanged data travels between them. For example, the EBR core 102 may implement one or more client interfaces (e.g., client API 104) such that consumers and / or producers need only request data and / or send data without knowing the location of the data, availability of the data, transport protocols, data formats, and / or other factors. The utility functions 120 may include a routing engine, a data shaping engine (e.g., data shaping), a sensor discovery engine (e.g., sensor discovery), and a tasking management engine (e.g., tasking management).

[0044] In some embodiments, an EBR device (e.g., an EBR core 102 of an EBR device) can be configured as a service model that can generate data requests as a function of consumer processor-based services. The EBR core 102 can determine a path (e.g., one or more network paths) of the network architecture through which the data request is transported.

[0045] In some embodiments, an EBR device (eg, an EBR core 102 of an EBR device) can be configured for a dynamic heterogeneous tactical network architecture.

[0046] In some embodiments, an EBR device (e.g., an EBR core 102 of an EBR device) can be configured to perform dynamic data discovery based on proactive advertising messages. The EBR core 102 can be configured to distribute data based on the data requirements of a consumer processor-based service, where the data is shaped by the required data density.

[0047] In some embodiments, an EBR device (eg, an EBR core 102 of an EBR device) may include a proxy API 106 configured to provide transport mechanism independent messaging to assist in the transport of aggressive advertising messages.

[0048] In some embodiments, an EBR device (eg, EBR core 102) can be configured to access data from a producer processor using data requests and / or subscriptions.

[0049] In some embodiments, an EBR device (e.g., an EBR core 102 of an EBR device) can be configured to perform dynamic data discovery to access transport and network status information when alarms are observed and / or sensors report alarms with respect to required parameters.

[0050] In some embodiments, an EBR device (e.g., an EBR core 102 of an EBR device) can be configured to perform dynamic data discovery in collaboration with an edge-based routing device of a consumer processor and an edge-based routing device of a producer application.

[0051] In some embodiments, an EBR device (eg, an EBR core 102 of an EBR device) can be configured to assemble situational awareness information received from producer applications for a designated area in a tactical network environment.

[0052] With reference to Figure 2, an embodiment of a method 200 for managing communications across multiple networks between network producer applications and network consumer applications using a network edge-based routing device configured for a multi-transport network architecture is also disclosed. The steps illustrated in Figure 2 are for illustrative purposes only. It will be understood that additional, fewer, various, and / or different orders of steps may be used in some embodiments.

[0053] The method 200 may include step 202, which may include receiving a request for consumer data. For example, the EBR core 102 of the EBR device may receive a service model-based consumer application request for the consumer data.

[0054] The method 200 may further include step 204, which may include performing consumer data discovery. For example, the EBR core 102 may perform consumer data discovery across multiple networks via EBR devices.

[0055] Method 200 may further include step 206, which includes receiving the discovered consumer data. For example, EBR core 102 may receive the discovered consumer data at the edge-based routing device from a producer application over a plurality of networks and a selected transport mechanism appropriate for a specified network of the plurality of networks.

[0056] The method 200 may further include step 208, which includes providing a list of data producers. For example, the EBR core 102 may provide a list of available data producer applications to a consumer application associated with a service model based consumer application request via an edge based routing device.

[0057] The method 200 may further include step 210, which may include passing the request for consumer data. For example, the EBR core 102 may pass a service model-based consumer application request across multiple networks to a producer application.

[0058] The method 200 may further include step 212, which may include receiving the producer data. For example, the EBR core 102 may receive the producer application data at an edge-based routing device for transport to a consumer application.

[0059] 3, an exemplary tactical system 300 is shown in which connectivity across distributed sensors, shooters, and data in all domains to all forces enables distributed command and control at scale, time, and level to achieve commander intent. System 300 can be configured to be domain, platform, and functional mission lane agnostic. System 300 can include one or more networks, such as network 302, implemented by multiple EBR devices and one or more data sources 304 and / or data consumers 304, each connected via an EBR connection 306 of the EBR network.

[0060] 3 is an illustrative diagram of a system and force demonstrating the technology enabling the digital battle space through the implementation of EBR devices and an EBR network. For example, data from data sources 304 (e.g., producers and / or consumers) can be collected via automated sensors, and these data can be used to make a wide range of informed decisions. The use of EBR devices in conjunction with an EBR network can make the collection and use of data from various data sources 304 automated and seamless between the EBR devices, sensors, and applications running on the EBR devices in the EBR network. Additionally, the use of EBR devices in an EBR network can reduce the need to constantly update the configuration of devices and frameworks, such as the EBR core 102.

[0061] Referring now to FIG. 4, an EBR functional architecture 400 is shown that can be implemented and / or modified as disclosed herein with respect to the exemplary functional allocation of FIG. 1. Within the EBR network, one or more applications 402 (e.g., client application 108) can make requests for data via an EBR API 404. The EBR functional architecture 400 can include one or more transport proxies 406 that can perform service-specific operations such as message format compliance and can be responsible for reporting network status (e.g., stat) conditions. The path selection process can be performed by a logical forwarding engine (LFE) 408 that can read transport status from an intelligent network engine (INE) 410. If transport conditions change (e.g., network degradation or an EBR node becomes unreachable), the EBR framework can restore network paths to continue the flow of data and / or messages. The applications 402 do not need to be involved or aware of the path selection process.

[0062] Continuing with reference to FIG. 4, exemplary additional variable input interfaces can include sensor and configuration data via transport proxies 406, including a Blue Force Tracker (BFT) interface, a Cross Domain Operations (CDO) proxy, a Long Term Evolution (e.g., 4G) cellular interface, a Tactical Scalable MANet (TSM) interface, and an Upper Tactical Internet (UTI) interface. The EBR functional architecture 400 can further include a service management engine 410, a data store 412, and a machine learning management engine 414. One or more components of FIG. 4 can be the same as or similar to the components shown in FIG. 1. For example, the transport epoxy 406 can be the same as or similar to one or more transport proxies shown in FIG. 1.

[0063] In addition to providing dynamic discovery and distribution of data across a highly dynamic network architecture, the EBR functional architecture 400 can include provisions for discovering and distributing data across security enclaves separated by a cross-domain solution (CDS). This capability dynamically formats data and messaging into types supported by CDS policies (e.g., extensible markup language (XML)) to blur or filter data so that it meets the dictated requirements of sanctioned policies. The EBR functional architecture 400 can provide the capability to discover and task sensor platforms operating in different classifications from the same workstation. Signal detections can be populated and presented on a single display to provide a more intuitive view of the battlefield electromagnetic conditions.

[0064] The EBR functional architecture 400 can be developed in Java and configured to run within a Linux, Windows, and / or Android environment. For example, the EBR functional architecture 400 can be configured to work in conjunction with the Android Tactical Assault Kit (ATAK). The EBR functional architecture 400 can be integrated into Common Operating Environment Command Post (COE-CP) and Developmental Common Operating Environment Mounted Computing Environment (COE-MCE) applications. For example, the EBR functional architecture 400 can be integrated into COE-CP applications running on one or more processors within an operating system.

[0065] With respect to the EBR core 102, the EBR core 102 can be configured to manage relationships and data exchanges between external processes or client applications on processor-based devices across a network communication fabric (e.g., network architecture) that connects the platforms for the purpose of exchanging data. Client applications are connected via one or more client APIs and associated gRPC client interfaces, Representational State Transfer (REST) ​​client interfaces, and / or any custom client interfaces as required. In some embodiments, exemplary data services of the EBR core 102 can be supported by software modules (e.g., software instructions) that provide electronic sensor support, current operation picture (e.g., COP), software configuration management, and any custom data services as required. Utility functions of the EBR core 102 are supported by software modules that provide routing engine functions, data shaping, sensor discovery, tasking management functions, etc.

[0066] The routing engine may include software instructions (e.g., software applications, software components, etc.) that may be executed by at least one processor of an EBR device (e.g., a device implementing device configuration 100). The routing engine may be configured to cause a processor of the EBR device to select one or more network paths for transmitting one or more messages (e.g., routing message objects) from one or more initial points (e.g., consumers and / or producers) to one or more intended destinations (e.g., consumers and / or producers). A network path may include at least one source node (e.g., a source point in a network, a sending EBR device) and at least one target node (e.g., an intended destination, a receiving EBR device). In some embodiments, a network path may include at least one source node, one or more intermediate nodes, and at least one target node. A node in the network may include an EBR device (e.g., an EBR device node).

[0067] The routing engine may have access to a target destination list used by the routing message object. The target destination list may include a list including each target node connected to one or more network paths to which the source node is connected. For example, the target destination list may include an entry for each target node to which the source node may send a message via a network path. For each target node in the list of destinations, the routing engine may look up a network path to the target node in the EBR data store 412 shown in FIG. 4. The routing engine may select the network path that has the highest capability rank when compared to other network paths in the EBR data store 412. The capability rank may include a measure of the capability of the network path. The capability rank may refer to a measure determined based on several network factors including, but not limited to, network capacity, network latency, observed losses in the network, transport congestion in the network, and signal strength of the network (e.g., signal strength measured at the EBR device that is sending the message). Because not all transports are evaluated using the same network factors, the capability rank may include a rank specific to the transport and / or network path.

[0068] The routing engine may select one or more network paths based on maximum efficiency (e.g., a measure of efficiency based on transmission speed, number of messages to be transmitted, number of nodes a transmitted message must pass through to reach a target node, etc.). For example, the routing engine may select a network path with maximum efficiency for transmitting one or more routing message objects to one or more target nodes based on a number of intermediate nodes. In some embodiments, the one or more network paths with maximum efficiency may change over time. The routing engine may detect changes in one or more network paths and / or changes in maximum efficiency of one or more network paths, and the routing engine may dynamically determine a new network path for transmitting messages when network conditions change.

[0069] To determine one or more network paths based on maximum efficiency, the routing engine may divide one or more routing message objects into multiple message segments based on the type of the target node, the next hop node (e.g., an intermediate node connected to the source node through which the routing message object can be transmitted), and the network through which the one or more routing message objects are transmitted from the source node to the target node. For example, the routing engine may transmit each message segment of the one or more routing message objects through a network path having a network type that maximizes delivery of the one or more routing message objects to the one or more target nodes and minimizes the number of message transmissions. A message transmission may refer to a first node sending a message to a second node. Thus, the routing engine may minimize the number of message transmissions by transmitting one or more message segments from the source node to the target node when the selected network path includes a minimum number of intermediate nodes (e.g., each message segment passes through a minimum number of intermediate nodes).

[0070] The routing engine can then select a network path for the routing message object that has the least number of intermediate nodes. The routing engine can send the routing message object from one source node (e.g., one EBR device) to multiple destinations (e.g., multiple target nodes) using a transport protocol such as multicast or other transport protocol compatible with the network. Thus, the routing engine can enable the EBR core 102 to determine the network path messages that must be exchanged / passed for efficient routing of messages between the producer EBRS device and the consumer EBR device.

[0071] Through the routing engine of the EBR core 102, network paths between consumers and producers can be discovered during a discovery process initiated by the sensor discovery engine, which can then have one or more EBR discovery messages distributed across all transport protocols available to the EBR nodes through the transport proxies 318.

[0072] Referring to FIG. 7, a diagram of an example message routing performed by a routing engine of an EBR device in an example EBR network 700 is shown. A client EBR device proxy node 702 can decide to send a message to multiple target nodes (e.g., node 710, node 716, node 718). When a client EBR device connected to the EBR network of node 702 issues a discovery request for data, if no active tasking is yet discovered in the task management engine, the EBR core 102 of the EBR client device connected to node 702 can perform a discovery operation across available networks (e.g., BFTS2 network 704, TSM network 706, and / or Warfighter Information Network-Tactical (WIN-T) network 708). The discovery request can propagate across multiple hops (e.g., across one or more intermediate nodes) to allow discovery of all sources available in the EBR network. Once the paths are established, the EBR routing engine can perform hop-by-hop distribution of the data (e.g., from node 702 to node 716, from node 702 to node 710 to node 714, and from node 702 to one of nodes 706-708-712 to node 718) that adheres to the data shaping rules and protocols / encoding for each transport.

[0073] 7, as an example, an EBR message originating from an EBR device connected to the EBR network at node 702 may be identified by the routing engine to three target nodes (e.g., three destinations) in a list of target nodes: EBR clients connected to the EBR network at node 710, node 716, and node 718. In this example, the following steps may be taken:

[0074] For each node in the list of target nodes, the routing engine of the EBR device residing at node 702 can look up the best route (e.g., network path) to each target node in the EBR database (e.g., EBR data store 412). The best route can indicate the network path with the highest capability rank. For example, if two network paths have the same capability rank, the routing engine of the EBR device residing at node 702 can select the network path with the least number of hops (e.g., least number of intermediate nodes). The client EBR device residing at node 702 (e.g., the routing engine of the EBR device) can map each next hop of the multiple next hops to the list of target nodes. Thus, an example map can include the following:

[0075] target node 710-next hop node 710, target node 716-next hop node 716, target node 718-next hop node 710. A single proxy message can be used for any next hop nodes beyond the proxy that supports multicast. In this embodiment, a single message can be sent over TSM network 722 that is received by nodes 710 and 716.

[0076] When a message sent from a client EBR device residing at node 702 is received at an EBR device residing at node 716, the EBR device residing at node 716 acts upon the message. When a message is received by an EBR device residing at node 710, the EBR device residing at node 710 acts upon the message. If node 710 is an intermediate node (e.g., next hope node) in the network path from node 702 to node 718, the message may also contain information and / or signals that cause the EBR device residing at node 710 to forward the message to the EBR device residing at node 718.

[0077] The routing engine may continuously monitor the network (e.g., one or more network paths of the EBR network) for a first network path from a source node A to a target node B for transmitting a message. In a multi-hop transport topology (e.g., one or more intermediate nodes), the first network path may degrade. In this instance, the routing engine of the EBR device may identify an alternative network path that may enable the EBR system to maintain the same degree of connectivity as the first network path before the first network path degrades. The routing engine may identify the alternative network path by applying a new set of data shaping rules to data associated with the message to be transmitted. Alternatively, the routing engine may change the protocol and / or encoding of the data associated with the message when traversing the EBR network. Additionally, the EBR device can constantly monitor the network of the EBR network using the routing engine, so that if a first network path that was previously degraded before the message was transmitted continues to return to an initial status and / or connectivity, the EBR device can detect that the first network path has returned to its initial status, and if the first network path provides improved transmission of the message (e.g., greatest efficiency, highest capacity, least degraded connectivity, fastest transmission, etc. compared to other network paths), the EBR device can switch to the first network path and identify the first network path as the network path for transmission of the message.

[0078] A data shaping engine (e.g., a data shaping engine of the EBR core 102) may include software instructions (e.g., a software application, a software component, etc.) that may be executed by at least one processor of an EBR device (e.g., a device implementing the device configuration 100). The data shaping engine may be configured to cause at least one processor of the EBR device to shape data included in a routing message object when the routing message object is a message object that includes data associated with the message object (e.g., a data message object). Shaping of data and / or a function for shaping data (e.g., a shaping function) may refer to an operation that reduces the overall network capacity and / or capacity of a network path required to transmit data between EBR device nodes to meet the capacity requirements of the network used for the transmission. The data shaping engine may use one or more parameters to shape the data, and the one or more parameters may be configurable at each EBR device node.

[0079] The data shaping engine can shape data included in a data message object based on a capability rank of a network path through which the message object is transmitted. For example, a network path can have a capability rank associated with the network path that represents the capability and / or capacity of the network path for transmitting data. In some embodiments, the capability rank of the network path can include an integer value. The EBR core 102 (e.g., at least one processor of the EBR core 102) can determine a capability rank associated with a network path when a message object is transmitted and / or routed to proceed to another EBR device node (e.g., a target node) through the network path (e.g., a selected network path selected by the routing engine). For example, a capability rank of the network path can be established for the network path. Additionally, the data shaping engine can continuously monitor the capability rank of the network path. The data shaping engine can shape data associated with a data message object transmitted through the network path based on the capability rank. For example, the data shaping engine can determine how to shape data associated with a data message object to ensure that the data is transmitted over a network path without oversubscribing the network path (e.g., sending one or more data message objects over the same network path, causing the network path to reach and / or exceed its transmission capacity).

[0080] As an example, a COP message including an observation report, a COP message containing an image (e.g., image data) may be sent over a network path with a capability rank of 8. Before sending the COP message to the transport proxy, the data shaping engine may analyze the shaping configuration, which allows the data shaping engine to determine a shaping function that can be used based on the network path's capability rank of 8. The data shaping engine may invoke the shaping function to convert the observation report COP message so that the COP message can be efficiently sent over the network path. For example, the shaping function in the configuration may be set to compress the image in the COP message by 50% to generate a resulting observation report for the COP message. The data shaping engine may then send the COP message along with the resulting observation report to the target node.

[0081] Additionally, the data shaping engine may determine how and / or what data may be sent over a network path based on changing network conditions. For example, the data shaping engine may average the data associated with a message being sent and / or the data shaping engine may limit the size and / or amount of data sent in a message. The data shaping engine may determine how to shape the data based on rules associated with a message type of the message, which may be defined within a data service. For example, the data shaping engine may increase the time of message transmission to reduce the frequency with which messages are sent if the data associated with the message represents a location of an object and / or device. As a further example, the data shaping engine may compress the data associated with a message if the data represents a video stream. In other instances, the data associated with a message may be averaged over time based on the type of data and the needs of the consumer device. If a new type of data is introduced into the EBR system, the data shaping engine may be configured to process and / or recognize the new type of data.

[0082] The sensor discovery engine (e.g., sensor discovery of the EBR core 102) may include software instructions (e.g., software applications, software components, etc.) that may be executed on at least one processor of the EBR device (e.g., a device implementing the device configuration 100). The sensor discovery engine may be configured to cause at least one processor of the EBR device to discover one or more producer clients (e.g., producers) that may provide sensors and / or data collection capabilities. The sensor discovery engine may assist a consumer to determine and / or discover data that may be made available from one or more producers when the data and / or one or more producers are unknown to the consumer. A consumer in the EBR network may invoke a function that invokes the sensor discovery engine of the EBR core 102 to search for data based on a number of parameters. The number of parameters may include data parameters (e.g., geographic location, etc.) that may be standard data parameters and / or data parameters defined in a data service that may be associated with sensors of one or more producers. For example, one or more producers may have a radio frequency sensor. Data parameters that may be identified and / or discovered by the sensor discovery engine may include various machine learning model capabilities such as geographic location, radio frequency spectrum coverage, and / or modulation classification.

[0083] As an example, a consumer can send a sensor discovery message over the EBR network requesting a list of radio frequency sensors located in a particular geographic location if the radio frequency sensors are capable of performing signal classification of signals between 550 MHz and 1000 MHz. The sensor discovery engine can then identify and / or discover available radio frequency sensors and return the list of radio frequency sensors to the consumer along with the capabilities of each radio frequency sensor.

[0084] In some embodiments, a consumer client EBR can subscribe to an EBR application of a producer client EBR device based on a discovery message sent from a client consumer EBR device. For example, once the sensor discovery engine returns a list of sensors and / or data producers to the client consumer EBR device, the client consumer EBR device can subscribe to one or more sensors and / or data producers such that the client consumer EBR device receives all data updates and / or all data collected by the client producer EBR device that collects data via one or more sensors.

[0085] A tasking management engine (e.g., tasking management of EBR core 102) can include software instructions (e.g., software applications, software components, etc.) that can be executed on at least one processor of an EBR device (e.g., a device implementing device configuration 100). The tasking management engine can be configured to cause at least one processor of the EBR device to track EBR nodes having various attributes and / or capabilities. For example, the tasking management engine can track EBR nodes that can be discovered by a sensor discovery engine, and the tasking management engine can track EBR nodes that have certain capabilities.

[0086] In addition, the tasking management engine can track and / or identify active consumers requesting data, producers that can provide data, and active service sessions that are actively sending data from consumers to producers. For example, consumers and producers can perform various tasks to participate in data exchanges with other consumer and / or producer nodes. The tasking management engine can determine whether a new discovery can satisfy an existing tasking. For example, if there are two clients, client A and client B, on the same EBR node, and client B is trying to discover data that was previously provided to client A, the tasking management engine can provide both client A and client B with the data that was previously provided to client A without the need for discovery and tasking processes. Alternatively, the tasking management engine can provide client B with data that was previously provided to client A after the data has already arrived at client A, so that the same data does not have to be sent from the original producer of the data to client B.

[0087] Tasks managed by the tasking management engine may include certain functions, such as registration. For example, the tasking management engine may track and / or manage which EBR devices own what type of data and / or the capabilities that the EBR devices provide to the EBR network. Capabilities that may be tracked by the tasking management engine may include capabilities such as sensors, image capture, etc. The tasking management engine may track and / or manage the EBR devices in the EBR network by maintaining a list of one or more registered clients that reside on the EBR node.

[0088] As an example, a client device (e.g., a client EBR device) that includes an RF sensor can be registered by the tasking management engine of the ERB core 102 as an electronic support sensor (ESS) producer that provides a data service that includes RF sensor data. When registering a client device, the tasking management engine can collect and / or maintain information specific to the ESS and the data service provided by the client device, such as the available frequency range of the RF sensor, and can use signal classification by the RF sensor.

[0089] After a client device is discovered via a discovery process performed by the sensor discovery engine, a tasking management engine of a consuming client device (e.g., a consumer) can generate a task request, and the consuming client device can send the task request to the producer client device. The task request can include a task signal (e.g., a flag, a function, etc.) that causes the producer client device (e.g., a producer) to perform a task, such as providing the consuming client device with data that the consuming client device requested via the tasking request and / or data that the consuming client device previously requested. The tasking request can include a set of parameters defined by the data service, and the tasking request can include one or more task signals associated with a list of client devices where the task signal(s) of the one or more task signals can be sent to each client device in the list of client devices, causing each client device to perform the task (e.g., provide data to the consuming client).

[0090] The client EBR device can identify (e.g., by performing a lookup operation) each client device included in the list of client devices for sending a task request, and the client EBR device can send the task request to a target node of each client device. Each client device in the list of client devices that receives the task request can provide data matching the task request parameters so that the data matching the task request can be routed to the consumer client (e.g., client EBR device) that sent the tasking request. The tasking management engine can monitor the state of a tasking session such that all tasking requests of a client device (e.g., either tasking requests sent or tasking requests received by the client device) are tracked and / or recorded. A tasking session can refer to a two-way communication link between a consumer client device, a producer client device, and / or another device, bounded by an amount of time.

[0091] For example, a producer client device may establish a tasking session with a vehicle to monitor the vehicle's status (e.g., fuel level, engine status, etc.). The vehicle's status and the status of the tasking session may be registered with a task management engine running on the producer client device. When the producer client device receives a task request and provides the vehicle's status to the consumer client device that sent the task request, the task request is managed (e.g., processed, monitored, recorded, etc.) by the tasking management engine running on the producer client device.

[0092] Through one or more utility functions of the EBR core 102, data that is available for consumption by producers can be dynamically discovered, requested, and delivered to consumers throughout the network architecture, without either the consumer or the producer needing to be aware of the mechanism by which the exchanged data travels.

[0093] An EBR device (e.g., an EBR device implementing device configuration 100) can be content aware. Thus, an EBR device can be content format aware, and a producer EBR device can define the structure of the data that the producer EBR device can transmit over one or more EBR networks. One or more EBR devices connected to a BER network can access all data values ​​in the EBR network, regardless of how the structure of the data is defined. The ability to access data regardless of the structure of the data is distinct from simply transmitting the data as a payload.

[0094] EBR devices allow producers to explicitly define data structures, and EBR devices can define data structures in the EBR network and that can be accessed by consumer EBR devices. Thus, data structures do not have to be inferred based on other techniques such as packet sniffing. There are various embodiments of how EBR devices can demonstrate content awareness during operation.

[0095] The sensor discovery engine (e.g., via data discovery) can identify producers and / or data based on the identity of the producer and / or the content of the data provided by the producer. This EBR core 102 functionality (e.g., sensor discovery engine) can allow only the data the consumer wants to identify and send over the network path without identifying and sending data from outside. Additionally, EBR devices can enable access to data that fits the domain without needing to know the specifics of the source (e.g., producer). For example, there are several different formats in which the system can provide location associated data (e.g., VMF, Unified Data Library Feed (UDL), etc.). In general, consumer EBR devices need to know how to retrieve location associated data based on the format and source device in which the location associated data is provided. EBR devices allow consumers to request location associated data for a given area and producer EBR devices to report location associated data for a given area. Producer EBR devices can send location reports without regard to the specific source of the location associated data sent by the producer EBR device.

[0096] The data shaping engine can shape data according to the constraints of the current detected network conditions through the best network path (e.g., the network path with the most efficient time to transmit the message). For example, the data shaping engine can compress data associated with an image attachment of a message. The data shaping engine can average data associated with other types of messages across one or more messages before transmitting the one or more messages. The manner in which data is shaped by the data shaping engine can be defined within the data service on a per-message basis. The data shaping engine needs to detect the data format and / or data type in order to generate shaping rules for shaping and / or modifying data transmitted over the network path. Thus, the data shaping engine enables EBR devices to transmit data with high quality (e.g., data that is presented coherently to a consumer device) even when network conditions are poor and transmitting full unshaped and / or unmodified data is infeasible.

[0097] An EBR device can package data into a specific message format, such as VMF, for a certain type of network and / or application. An EBR device can package data into a message format if the schema of the data is known by the EBR device. In this way, an EBR device can map data values ​​to the schema of another message format. For example, an EBR device can send a position report as a VMF K05.1 message (e.g., including GPS location), or an EBR device can send an observation report as a VMF K04.1 (e.g., including size, location, and / or time).

[0098] The exemplary EBR core 102 provides a flexible application programming interface (e.g., client API 104) that client applications 108 can use to request data from producers connected to the network architecture. This same client API 104 can provide requesting consumer client applications 108 with the data that was requested and delivered to the EBR core 102. Additionally, the EBR core 102 can act as a central manager that performs the following exemplary functions: Manage client application requests and advertising data for the services described below. · Supports a mechanism for discovering data that satisfies the requirements of a client application. ·Determine which network routes messages that must be switched / filtered. · Using data shaping as described herein to determine and generate the density of data that can be transmitted over a given network.

[0099] Through the exemplary EBR core 102 and its use of utility functions, data consumable by producers can be dynamically discovered, requested, and delivered to consumers across the network architecture without either the consumer or the producer needing to be aware of the mechanism by which the exchanged data is moved between the consumer and producer.

[0100] The data service model architecture of the EBR core 102 is built to enable advertisement and discovery of data via the service model. The service model groups related types of data defined by object types and attributes into communities that are described and associated with each other. A service can represent data that already exists regardless of any requested need by a consumer. An example of data represented by a service can include the location of a platform. A platform has a location that can be represented as a data point of a service, and this location exists regardless of whether the location information is sought by any consumer. A service can also contain a description of data that requires an operation to determine whether the data exists. An example of a description of data can include a picture of a particular entity in a given area. An interest in a picture of a particular entity in a given area can exist without knowledge of whether a picture of the particular entity exists. Fulfilling this data request requires the operation of a camera observing the location until the sought object is detected, which can capture and provide the requested data (e.g., a picture of the particular entity).

[0101] The transport proxy 318 can include a microservice application that encompasses logic (e.g., software instructions) specific to monitoring, sending, and receiving traffic across a particular (e.g., tactical) network. Each EBR device node can have one or more transport proxies 318 spun up (e.g., initialized). One or more transport proxies 318 are intended to be easily and quickly constructed for new transports, for example. The transport proxy 318 can connect to the EBR core 102 via the proxy API 106, and further to associated gRPC proxy interfaces and / or any required custom proxy interfaces. The transport proxy 318 can operate in conjunction with associated communication protocols and optional custom-based network monitoring via proxy libraries. Core EBR utility libraries can be loaded from the transport proxy 318, for example, via the transport interfaces.

[0102] The transport proxy 318 is designed to work with various network types. In general, the transport proxy 318 can determine the protocol to implement for the network. Alternatively, the transport proxy 318 can have a protocol pre-determined based on the type of network. For example, the transport proxy 318 can compose messages in a variable message format (VMF) to transmit messages across a network, such as a network in which EBR devices implement Byzantine Fault Tolerance (BFT). Other transport protocols may or may not have requirements on message formats.

[0103] For example, when transmitting data and / or messages across a network having a type of Tactical Scalable Mobile Ad-Hoc Network (TSM™), multicast communication can be used as messages are broadcast to multiple client devices. The use of multicast communication can enable highly opportunistic discovery. However, networks such as Mobile User Objective System (MUOS) point-to-point networks or commercial cellular networks may not support multicast communication and thus require the use of unicast communication. In addition, some transport protocols are more suitable for transmitting large files across a network path than images and / or small messages. For example, the transport proxy 318 can determine which of two transport protocols supported by the transport proxy 318 can be used to transmit a message based on the content and / or size of the message. The transport proxy 318 can include suites of protocols and messaging formats included in the definition of the transport proxy 318 that can facilitate the use of new transport protocols as required by system and / or network parameters.

[0104] An EBR device can leverage the CDS system in which it is deployed. For example, the EBR core 102 can use the transport proxy 318, which includes a CDO proxy that can determine whether data provided to the CDS system conforms to the rules required by the CDS system. The CDO proxy of the transport proxy 318 can package messages and / or data into an Extensible Markup Language (XML) format (e.g., one of the accepted formats). The EBR core 102 or another component (e.g., the transport proxy 318) can perform obfuscation and / or filtering of data associated with messages sent by the EBR device through the CDO proxy of the transport proxy 318. The CDO proxy can perform filtering and / or clearing of data associated with messages on a field-by-field basis based on additional XML schema filtering that may need to be performed. The specification of the fields to be filtered for high and / or low messages can be determined by the transport proxy 318 based on the CDS policy and rules from the certifying organization.

[0105] Administrative Web GUI The admin web GUI can be, for example, a microservices web dashboard built on React and Node. In an exemplary embodiment, the admin GUI is not required to run EBR. The admin web GUI provides an easy and intuitive page to initialize the installation and configure the EBR instance, live modify runtime settings such as data shaping features, and view the live status of containers and the network of the EBR node.

[0106] Database Services The database service can be, for example, a microservice that enables the EBR to communicate with the platform's database. This layer of abstraction allows for easy cross-platform support and various databases. The database service can include functionality to work with general EBR tables such as clients, nodes, and tasks, as well as with any data service specific tables. Data service specific tables can be initialized and interacted with by extending abstract classes provided by an EBR SDK (software development kit), such as the Center SDK. An exemplary database service can be associated with a relational / NoSQL database.

[0107] Model Nexus Model nexus 120 can be, for example, a microservice that enables edge inference and management of machine learning models. An exemplary model nexus 120 is built around the open source inference engine TensorFlow Serving, which is part of the TensorFlow Extensions (TFX) architecture. Model nexus 120 assists in serving and unserving models, returning inferences on EBR data, and using custom pre- and post-processing functions.

[0108] Model Nexus 120 has also implemented a data drift service that utilizes the TFX tensorflow data validation library. The library detects schema drift by comparing the schema of the training data to the schema of the serving data using a TFX component called SchemaGen, and checks for data errors / anomalies. The library also detects data skew / drift by comparing statistics of the training data to statistics of the serving data using a TFX component called StatisticsGen. Data drift is an optional service for data requests, and thus the data drift service is only initialized when requested, for example, as part of the original EBR tasking or a local client that connects directly to TFX.

[0109] The data drift service is asynchronous to the model serving service and can be turned off if not required. Data drift is a trigger for ingestion and retention training used for anomalies and model retraining. Detection of data drift and anomalous data ingestion results in delivery of the ingested data if network conditions permit, otherwise notifications of these alerts and collected data are sent to requesting consumers.

[0110] 5, an example data flow behavior of an example service model based EBR device in an example EBR network 500 disclosed herein when connecting data consumers and providers across a multi-transport network architecture is shown. FIG. 5 shows an example data flow for functional steps "0" through "14" as follows: 0) Three potential producer EBR devices 502 can each run a producing application 506, and each producing application 506 can be registered with the producer EBR device 502 via the client API 104, and each producing application 506 can enumerate the data services it can provide. 1) A "consumer" EBR processing device 504 can request a type of data from the EBR client API 104 (eg, "consumer data"). 2) The consumer EBR device 504 can issue discovery requests for consumer data across multiple networks (eg, network 510, network 512, network 514) using mechanisms specific to each network through which the request is sent. 3) The producer EBR device 502-1 can distribute data to the network 510 in response to receiving a discovery request received on the network 512 from the consumer EBR device 504 via the producer EBR device 502-1 using a transport mechanism determined by the transport proxy 124 appropriate for the network 510. 4) Producer data search results can be returned to the requesting consumer EBR device 504 device node from all available producer EBR devices 502 (eg, producer EBR device 502-2, producer EBR device 502-3) that have data that satisfies the request conditions. 5) The consumer EBR device 504 node (eg, via a sensor discovery engine) can generate and provide a list of available producer EBR devices 502 that can satisfy discovery requests sent from the consumer EBR device 504. 6) The consumer EBR device 504 can request data from the producer EBR device 502-2 and / or the producer EBR device 502-3. 7) The request may be passed (eg, sent) from network 512 to network 510 via producer EBR device 502-1. 8) The producer EBR device 502-3 can include a processor-based producer application 506-3 that can be tasked with providing requested data to the consumer EBR device 504 over the network 514, and the producer application 506-3 can provide all available data via the producer EBR device 502-3 for distribution to the consumer EBR device 504. 9) The producer EBR device 502-3 can include an EBR device core (e.g., EBR core 102) that can be aware of the network conditions between the producer EBR device 502-3 and the requesting consumer EBR device 504. The EBR device core can determine that the producer EBR device 502-3 can provide all available data to the consumer EBR device 504 over the network 514 using the mechanism that is most suitable for the network 514. 10) The EBR device core of the consumer EBR device 504 can receive the data sent from the producer EBR device 502-3, and the consumer EBR device 504 can provide the data to a requesting consumer application 508 of the consumer EBR device 504. 11) The producer application 506-2 can be tasked to provide the requested data, and the producer application 506-2 can provide all available data in the producer EBR device 502-2 for delivery to the consumer EBR device 504. 12) The EBR device core (e.g., EBR core 102) of the producer EBR device 502-2 can be aware of the conditions between itself and the consumer EBR device 504, and the producer EBR device 502-2 can perform data shaping to shape the data using summarization rules. For example, the summarization rules can include, without limitation, providing only the top level details or critical attributes of the data, dropping attachments and providing only metadata, averaging values ​​or counts of data present across multiple instances such as detection reports, and / or using content extraction or object recognition to describe the content of vast data types such as images and videos. This shaped data can be sent to the producer EBR device 502-1 using the mechanism most suitable for the network 510. 13) The producer EBR device 502-1 can receive the requested data, and the producer EBR device 502-1 can pass (e.g., send) the data and / or content from the producer EBR device 502-2 to the requesting consumer EBR device 504 using the mechanism most appropriate for the network 512. 14) An EBR device core (e.g., EBR core 102) of the consumer EBR device 504 can receive the data from the producer EBR device 502-2, and the consumer EBR device 504 can provide the data to a requesting consumer application 508 of the consumer EBR device 504.

[0111] 6, the operation of service model-based proactive message routing in an exemplary EBR network 600 according to an exemplary embodiment is illustrated. Proactive advertisement messages can be sent, for example, upon new client registrations (e.g., EBR devices registering in the EBR network) and at a time period defined by the data service. Proactive advertisement messages are meant to proactively inform other nodes in the topology (e.g., other EBR devices) about clients, services, routes, etc., without flooding the EBR network. Proactive advertisement messages are broadcast from the source node over a transport backed by a TTL of 1.

[0112] In FIG. 6, the aggressive advertisement message 602 is shown originating from node 604 and node 606. Network 616 (directly connected to node 604, node 608, and node 606) represents a high performance network that supports unicast and multicast (e.g., Wi-Fi). Both aggressive advertisement messages 602 are routed to all nodes in network 616. Network 618 (directly connected to node 604, node 614, and node 610) represents a high performance network that does not support multicast (e.g., LTE). In the case of network 618, the aggressive advertisement message 602 can be sent to the NOC (Network Operations Center) of network 618, which all other nodes in network 618 know to access in order to search and / or view the aggressive advertisement message 602. Network 620 (directly connected to nodes 606, 608, 610, and 612) is a medium performance network that supports multicasting, so aggressive advertisement message 602 is transmitted to all nodes in network 620. Network 622 (directly connected to nodes 606 and 610) is a low performance network, so aggressive advertisement message 602 is not transmitted over this network.

[0113] As previously mentioned, the disclosed EBR device may be configured with any combination of one or more processors, associated local and / or remote memory, and functional software modules, each processor configured to execute software functions stored in local or remote memory to perform the operational features described herein. A hardware processor as used herein may be a dedicated or general-purpose processor device. A hardware processor device may be connected to a communication infrastructure such as a bus, a message queue, a network, a multi-core message passing scheme, etc. An exemplary computing device as used herein may include a memory (e.g., random access memory, read-only memory, etc.) and may also include one or more additional memories. The memory and the one or more additional memories may be read and / or written in a known manner. In an exemplary embodiment, the memory and the one or more additional memories may be non-transitory computer-readable storage media.

[0114] Any of the processors disclosed herein may be part of or in communication with a machine (e.g., a computing device such as an EBR device, logic device, circuit, operating module (hardware, software, and / or firmware)). A processor may be hardware (e.g., a processor, integrated circuit, central processing unit, microprocessor, core processor, computing device, etc.), firmware, software, etc. configured to perform operations by execution of instructions embodied in computer program code, algorithms, program logic, control, logic, data processing program logic, artificial intelligence programming, machine learning programming, artificial neural network programming, automated reasoning programming, etc. The processor may receive, process, and / or store data related to, for example, sensors and / or network communications (e.g., through an EBR network).

[0115] Any of the processors disclosed herein may be scalable processors, parallelizable processors, multi-threaded processors, etc. A processor may be a computer whose processing power is selected as a function of expected network traffic (e.g., data flow). A processor may include any integrated circuit or other electronic device (or collection of devices) capable of executing operations in at least one instruction, which may include a reduced instruction set core (RISC) processor, a CISC microprocessor, a microcontroller unit (MCU), a CISC-based central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), a field programmable gate array (FPGA), etc. The hardware of such devices may be integrated on a single substrate (e.g., a silicon "die") or distributed across two or more substrates. Various functional aspects of the processor may be implemented solely as software or firmware associated with the processor.

[0116] The processor may include one or more processing or operating modules. The processing or operating modules may be software or firmware operating modules configured to perform any of the functions disclosed herein. The processing or operating modules may be implemented as software and stored in a memory, the memory being operatively associated with the processor. The processing modules may be implemented as a web application, a desktop application, a console application, etc.

[0117] The processor may include or be associated with a computer or machine-readable medium. The computer or machine-readable medium may include a memory. Any of the memories discussed herein may be computer-readable memories configured to store data. The memory may include volatile or non-volatile, temporary or non-transient memory, and may be implemented as in-memory, active memory, cloud memory, etc. Examples of memory may include flash memory, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), flash EPROM, compact disc (CD)-ROM, digital optical disc (DVD), optical storage, optical media, carrier waves, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store the required information and that may be accessed by the processor.

[0118] Any of the processors may communicate with other processors of other devices (e.g., computing devices such as EBR devices, computer systems, laptop computers, desktop computers, etc.). For example, a processor of an EBR core 102 of an EBR device (e.g., a consumer EBR device) may communicate with a processor of another EBR device (e.g., a producer EBR device), etc. Any of the processors may have a transceiver or other communication device / circuitry to facilitate the transmission and reception of wireless signals. Any of the processors may include an API as a software intermediary that allows two or more applications to talk to each other. The use of an API allows software of a processor of the EBR device configuration 100 to communicate with software of a processor of another device (e.g., another EBR device of an EBR network).

[0119] The memory may be a non-transitory computer-readable medium. As used herein, the term "computer-readable medium" (or "machine-readable medium") is an extensible term that refers to any medium or any memory that participates in providing instructions to a processor for execution, or any mechanism that stores or transmits information in a form readable by a machine (e.g., a computer). Such media may store computer-executable instructions executed by the processing elements and / or control logic, and data operated on by the processing elements and / or control logic, and may take many forms, including, but not limited to, non-volatile media, volatile media, transmission media, etc. A computer or machine-readable medium may be configured to store one or more instructions. The instructions may be in the form of an algorithm, program logic, etc. that causes the processor to perform any of the functions disclosed herein.

[0120] An embodiment of the memory may include a processor module and other circuitry that allows for transfer of data to and from the memory, which may include other components of a communication system. This transfer may be via hardwire or wireless transmission. The communication system may include transceivers that may be used to facilitate communication via a communication scheme or protocol for controlled and coordinated signal transmission and processing to any other component or combination of the communication system, along with switches, receivers, transmitters, routers, gateware, waveguides, etc. The transmission may be via a communication link. The communication link may be electronic-based, optical-based, optical-electronic-based, quantum-based, etc. The communication may be via Bluetooth, near-field communication, cellular communication, telemetry communication, internet communication, etc.

[0121] Data stored (e.g., in memory) in the exemplary computing device may be stored on any type of suitable computer-readable medium, such as optical storage (e.g., compact disc, digital versatile disc, Blu-ray disc, etc.), magnetic tape storage (e.g., hard disk drive), or solid state drive. An operating system may also be stored in the memory.

[0122] In an exemplary embodiment, the data may be organized in any type of suitable database organization, such as a relational database, a Structured Query Language (SQL) database, a distributed database, an object database, etc. Suitable organizations and storage types will be apparent to those skilled in the art.

[0123] An exemplary computing device may also include a communications interface. The communications interface may be configured to allow software and data to be transferred between the computing device and external devices. Exemplary communications interfaces may include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, and the like. The software and data transferred over the communications interface may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals, as will be apparent to one skilled in the art. The signals may travel over a communications path that may be configured to carry the signals and may be implemented using wires, cables, optical fibers, telephone lines, cellular telephone links, radio frequency links, and the like. The transmission of data and signals may be through a transmission medium. The transmission medium may include coaxial cables, copper wire, optical fibers, and the like. The transmission medium may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications, or other forms of propagated signals (e.g., carrier waves, digital signals, and the like).

[0124] A memory semiconductor (e.g., DRAM, etc.) can be a means for providing software to a computing device. A computer program (e.g., computer control logic) can be stored in the memory. A computer program can also be received via a communication interface. Such a computer program, when executed, can cause a computing device to perform the methods discussed herein. In particular, a computer program stored on a non-transitory computer-readable medium, when executed, can cause a hardware processor device to perform the methods discussed herein. Thus, such a computer program can represent a controller of a computing device.

[0125] As previously mentioned, optimal utilization of the changing and increasing number of transports utilized across multiple networks in use at any given time relies on the original data fabric realizing how to most efficiently move data across a given transport at present. This becomes especially important when considering low tactical forces that are constrained and sometimes only able to provide kilobits per second of capacity. Known systems utilize transport-specific mechanisms whereby each transport is used with maximum efficiency. When new transport technologies are adopted, their efficient utilization includes rapidly incorporating them without causing cascading effects to all of the applications and transports already in use. A methodology that is agnostic on the outside of the application, but highly transport-aware on the inside, makes it easy to incorporate new network types and achieve transport optimization without disrupting existing applications that already leverage the data framework.

[0126] Known data fabric technologies leverage the most efficient mechanisms for delivering traffic over time while localizing aspects of the system that need to be transport specific. Known EBR solutions pass data using transport proxy microservices. These proxies act as transport specific components that either encode the data in any optimal format or use a specific discovery mechanism or protocol based on the design of the particular transport. User data moving through known EBRs is put into a variety of formats (e.g., concise binary object representation or variable message format (VMF)).

[0127] Additionally, each transport proxy utilizes the protocols and mechanisms most appropriate for the transport technology, for example determining when UDP or TCP network protocols are used and / or using a session protocol such as Constrained Application Protocol (CoAP), TCP sockets, or MIL-STD-2045-47001.

[0128] In an EBR-based system, a proxy listens to all incoming requests from the actual transport interface, and the proxy is responsible for implementing messaging or mechanisms specific to each transport, including service and / or sensor discovery and protocol manipulation on all outbound traffic. Known software designs separate data discovery and management functions from transport-aware mechanisms to include future evolution of the tactical network in the foundation of the data fabric.

[0129] In today's multi-transport tactical network architectures, access to data requires scalable pre-configuration and is not dynamically resilient to changes in network conditions or topology. Furthermore, efficient use of the network requires applications to be aware of the network on which they are running or users must take action to ensure that applications can operate with the networks currently being used. This makes application development unscalable and discourages the deployment of new networks, as all applications require user attention to be compatible or to reconfigure applications to function efficiently and keep data flowing.

[0130] When the present disclosure is implemented using software, the software can be stored in a computer program product or a non-transitory computer readable medium and loaded into a computing device using a removable storage drive or a communication interface. In an exemplary embodiment, any computing device disclosed herein can include a display interface that outputs a display signal to a display unit, such as an LCD screen, a plasma screen, an LED screen, a DLP screen, a CRT screen, etc.

[0131] It will be understood by those skilled in the art that the present disclosure can be embodied in other specific forms without departing from its spirit or essential characteristics. The presently disclosed embodiments are therefore considered in all respects to be illustrative and not restrictive. The scope of the disclosure is indicated by the appended claims, rather than the foregoing description, and all changes that come within the meaning and scope of the claims and equivalents thereto are intended to be embraced therein. [Explanation of symbols]

[0132] 102 EBR Core 104 Client API 106 Proxy API 108 Client Applications 110 Tasking GUI 112 Sensor Driver 114 Custom Applications 116 Administrative Web GUI 118 Data Services 120 Utility Functions 120 Model Nexus 122 Database Services 124 Transport Proxy 126 Proxy Library

Claims

1. 1. An edge-based routing device configured for a multi-transport network, comprising: an edge-based routing core having a processor configured to provide service model based data services and utility functions; a client application programming interface configured to receive producer application data and output consumer application data; a proxy application programming interface configured to establish network layer routing connectivity between producer applications and consumer applications as a function of network conditions and / or capabilities; An edge-based routing device comprising:

2. the edge-based routing device is configured as a software instance; the edge-based routing core is configured as a service model that generates data requests as a function of consumer processor-based services and determines a path in the network architecture along which the data requests are to be transported; The edge-based routing device of claim 1 .

3. The edge-based routing device of claim 1 , wherein the edge-based routing core is configured for a dynamic heterogeneous tactical network architecture.

4. 2. The edge-based routing device of claim 1, wherein the edge-based routing core is configured to perform dynamic data discovery based on proactive advertisement messages and distribute data based on data requirements of consumer processor-based services, the data being shaped by required data density.

5. The edge-based routing device of claim 1 , wherein the proxy application programming interface is configured to provide transport mechanism independent messaging to support transport of aggressive advertising messages.

6. The edge-based routing device of claim 1 , wherein the edge-based routing core is configured to access data from producer processors using data requests and / or subscriptions.

7. 2. The edge-based routing device of claim 1, wherein the edge-based routing core is configured to perform dynamic data discovery to access transport and network status information when an alarm is observed and / or a sensor reports an alarm regarding a required parameter.

8. The edge-based routing device of claim 1 , wherein the edge-based routing core is configured to perform dynamic data discovery in combination with an edge-based routing device of a consumer processor and an edge-based routing device of a producer application.

9. The edge-based routing device of claim 1 , wherein the edge-based routing core is configured to assemble situational awareness information received from producer applications for a designated area in a tactical network environment.

10. 1. A method for managing communications across multiple networks between a network producer application and a network consumer application using a network edge based routing device, comprising: The method comprises: receiving a service model based consumer application request for consumer data at an edge based routing device; performing discovery of the consumer data across multiple networks via the edge-based routing device; receiving the consumer data discovered at the edge-based routing device from a producer application over a plurality of networks and a selected transport mechanism appropriate for a specified network of the plurality of networks; providing a list of available data producer applications to a consumer application associated with the service model based consumer application request via the edge based routing device; passing the service model based consumer application requests across a plurality of networks to the producer application; receiving producer application data at the edge-based routing device for transport to the consumer application; The method includes:

11. Edge-based routing devices are configured as a service model, The method further comprises: generating a data request as a function of the consumer processor-based service via an edge-based routing device; determining a route in a network architecture along which the data request is transported via an edge-based routing device; The method of claim 10, comprising:

12. The method of claim 10 , wherein the edge-based routing device is configured for a dynamic heterogeneous tactical network architecture.

13. performing dynamic data discovery based on proactive advertisement messages via an edge-based routing device; distributing data based on data requirements of consumer processor-based services, said data being shaped by the data density required through edge-based routing devices; The method of claim 10 further comprising:

14. 11. The method of claim 10, wherein the proxy application programming interface is configured to provide transport mechanism independent messaging to assist in transporting aggressive advertising messages.

15. The method of claim 10 , further comprising accessing data from a producer processor using a data request and / or a subscription via an edge-based routing device.

16. performing dynamic data discovery via an edge-based routing device; accessing transport and network status information when an alarm is observed and / or when a sensor reports an alarm regarding a required parameter via an edge-based routing device; The method of claim 10 further comprising:

17. The method of claim 10 , further comprising the step of performing dynamic data discovery in combination with an edge-based routing device of the consumer processor and an edge-based routing device of the producer application.

18. 11. The method of claim 10, further comprising assembling the situational awareness information received from the producer applications for a designated area in the tactical network environment via an edge-based routing device.

Images