A source node operable in a wireless self-organizing network comprising a plurality of nodes and a method for obtaining software by the source node

Abstract

The present invention relates to a distributed ledger for software distribution in a wireless ad hoc network for self-organizing data processing on a source node, and discloses a method for obtaining software by a source node in a wireless ad hoc network. The method includes the source node executing application software from which a need for performing a task is identified, and determining that the source node cannot perform the task. In response to the determination, the source node searches a local module repository (MR) of the source node for a software module that can be used to perform the task, and in response to the source node failing to locate the software module in the local MR, broadcasts a request for the software module to a neighboring node among the plurality of nodes within the radio range of the source node. The source node receives the software module from the neighboring node and performs the task using the software module.

Description

Technical Field

[0001] The present disclosure relates generally to software distribution, and in particular, to software distribution in wireless ad hoc networks for ad hoc data processing on source nodes such as autonomous machines. Background Art

[0002] Many modern machines are designed to have greater autonomy than other machines that require trained operators to operate safely. These autonomous machines include autonomous robots and various unmanned vehicles including unmanned ground vehicles (UGVs), unmanned aerial vehicles (UAVs), unmanned surface vehicles (USVs), unmanned underwater vehicles (UUVs), and unmanned space vehicles. Many of these autonomous machines are equipped with software modules to process data generated or provided by sensors.

[0003] Autonomous machines are often preloaded with software modules so that once a mission is performed, the software modules can be used to process data based on the machine operating requirements and the purpose of the mission. Autonomous machines can communicate directly or indirectly with other autonomous machines and / or with one or more hubs such as ground stations to exchange data and / or report data acquired by their sensors. Autonomous machines are becoming increasingly intelligent, becoming learning systems that can determine that they cannot process a specific modality of data generated or provided by one or more of their sensors. However, once a mission is performed, distributing software modules to enable an autonomous machine to perform a mission and / or process data in a specific modality becomes more complex, often requiring human intervention.

[0004] It would therefore be desirable to have a system and method that takes into account at least some of the issues discussed above, as well as other possible issues. Summary of the invention

[0005] Example embodiments of the present disclosure relate to software distribution, and in particular, to software distribution in a wireless ad-hoc network for ad-hoc data processing on source nodes such as autonomous machines. Example embodiments provide an intelligent, transactional, distributed, and federated method for acquiring software in a wireless ad-hoc network such as a network of autonomous machines. The method may include automatically determining the need to perform a task, such as processing a data modality, finding a software module that can be used to perform the task by communicating across nodes in the wireless ad-hoc, acquiring the software module, and using it to perform the task without human intervention.

[0006] Example embodiments may also define management of the methods, compliance, and utilization. A distributed ledger of immutable data entries may be provided for verifying events associated with authorization, usage monitoring, contract usage compliance, related value exchange, event monitoring / auditability (request, configuration of software modules into workflows, transfer, installation, use, uninstallation), etc.

[0007] Example implementations may enable a wireless ad hoc network including autonomous machines that are deployed to perform a task, self-describe the task, find software modules that can be used to achieve the goals of the task, and perform the task based on achieving those goals. In some examples, this may include a query of a distributed ledger of immutable entries having information about software modules installed on the machine and the versions of the installed software modules. Dynamic discovery may include sufficient system intelligence to learn the software modules required to achieve the desired functionality, the correct / acceptable configuration(s), the current location, the mode of transmission, and the network capabilities of the transmission software.

[0008] Accordingly, the present disclosure includes, but is not limited to, the following example embodiments.

[0009] Some example embodiments provide a method for obtaining software by a source node in a wireless ad hoc network including a plurality of nodes, the method comprising the source node: executing application software from which a need for performing a task is identified; determining that the source node cannot perform the task; and in response to the determination, accessing a corresponding local copy of a distributed ledger that is replicated, shared, and synchronized across the plurality of nodes, the distributed ledger and thereby the corresponding local copy including immutable entries specifying access rights to a plurality of software modules including a software module that can be used to perform the task; searching the immutable entries of the corresponding local copy for an immutable entry indicating that the source node is authorized to access the software module; and searching a local module repository (MR) of the source node for a software module that can be used to perform the task only if the source node is authorized. ; in response to the source node failing to locate the software module in the local MR, broadcasting a request for the software module to those of the multiple nodes within the radio range of the source node that are thus neighboring nodes, one of the multiple neighboring nodes, to search for the software module in the corresponding local MRs of the neighboring nodes, when the neighboring node fails to locate the software module in the corresponding local MR, rebroadcasting the request to those of the multiple nodes within the radio range of the one neighboring node that are thus further neighboring nodes, and receiving the software module from one of the further neighboring nodes; and the source node further receiving the software module from the one neighboring node; and performing the task using the software module.

[0010] In some example embodiments of the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments, the method also includes the source node: recording the request in an additional immutable entry in the corresponding local copy of the distributed ledger; and broadcasting the additional immutable entry to the neighboring nodes to initiate synchronization of the corresponding local copy of the distributed ledger with a copy of the distributed ledger at other nodes of the plurality of nodes.

[0011] In some example embodiments of the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments, the method also includes the source node: in response to the neighboring node recording the request broadcast from the source node, receiving further additional immutable entries broadcast from the neighboring node in the corresponding copy of the distributed ledger at the neighboring node; and adding the further additional immutable entries to the corresponding local copy of the distributed ledger to synchronize the corresponding local copy with the corresponding copy of the distributed ledger at the neighboring node.

[0012] In some example embodiments of the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments, the method also includes the source node: recording the receipt of the software module in an additional immutable entry in the corresponding local copy of the distributed ledger; and broadcasting the additional immutable entry to the neighboring nodes to initiate synchronization of the corresponding local copy of the distributed ledger with a copy of the distributed ledger at other nodes of the plurality of nodes.

[0013] In some example embodiments of the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments, the method also includes the source node: recording use of the software module in an additional immutable entry in the corresponding local copy of the distributed ledger; and broadcasting the additional immutable entry to the neighboring nodes to initiate synchronization of the corresponding local copy of the distributed ledger with a copy of the distributed ledger at other nodes of the plurality of nodes.

[0014] Some example embodiments provide a method for obtaining software by a source node in a wireless ad hoc network comprising a plurality of nodes, wherein nodes of the plurality of nodes within radio range of the source node are neighboring nodes, the method comprising one of the neighboring nodes: in response to the source node failing to locate the software module in a local module repository (MR), receiving a request from the source node for a software module that can be used to perform a task, the request being broadcasted from the source node to the neighboring node, the one neighboring node responding to the request: accessing a corresponding local copy of a distributed ledger replicated, shared and synchronized across the plurality of nodes, the distributed ledger and thereby the corresponding local copy comprising a specified an immutable entry of access rights to a software module; searching the immutable entry of the corresponding local copy for an immutable entry indicating that the source node is authorized to access the software module; and searching the corresponding local MR of the one neighboring node for the software module only when the source node is authorized; in response to the one neighboring node failing to locate the software module in the corresponding local MR, rebroadcasting the request to those nodes of the plurality of nodes that are further neighboring nodes that are within radio range of the one neighboring node; receiving the software module from one of the further neighboring nodes; and returning the software module to the source node that uses the software module to perform the task.

[0015] In some example embodiments of the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments, the distributed ledger and thereby the corresponding local copy also include an immutable entry in which a previous request received by the one neighboring node is recorded, and wherein the method also includes the one neighboring node searching the immutable entry to verify that the request is a new request for the software module from the source node.

[0016] In some example embodiments of the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments, the method further includes the one neighboring node: recording the request in an additional immutable entry in the corresponding local copy of the distributed ledger, and broadcasting the additional immutable entry to the source node and the further neighboring nodes to initiate synchronization of the corresponding local copy of the distributed ledger with copies of the distributed ledger at other nodes of the plurality of nodes.

[0017] In some example embodiments of the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments, the method also includes the one neighboring node: in response to the further neighboring node recording the request rebroadcast from the one neighboring node, receiving a further additional immutable entry broadcasted from the further neighboring node in a corresponding copy of the distributed ledger at the further neighboring node; and adding the further additional immutable entry to the corresponding local copy of the distributed ledger to synchronize the corresponding local copy with the corresponding copy of the distributed ledger at the further neighboring node.

[0018] In some example embodiments of the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments, the method also includes the one neighboring node: recording the receipt of the software module in an additional immutable entry in the corresponding local copy of the distributed ledger; and broadcasting the additional immutable entry to the source node and the further neighboring nodes to initiate synchronization of the corresponding local copy of the distributed ledger with copies of the distributed ledger at other nodes of the plurality of nodes.

[0019] Some example embodiments provide a method for obtaining software by a source node in a wireless self-organizing network including multiple nodes, the method comprising the source node: executing application software from which a need for performing a task is identified; determining that the source node cannot perform the task; and in response to the determination, accessing a local copy of a module repository (MR) implemented in a distributed ledger that is replicated, shared and synchronized across the multiple nodes, the distributed ledger and thus the local copy of the MR including immutable entries with software modules available to the multiple nodes; searching the local copy of the MR for a software module that can be used to perform the task; and performing the task using the software module.

[0020] In some example embodiments of the method of any preceding example embodiments and any combination of any preceding example embodiments, searching the local copy of the MR includes searching the local copy of the MR for the specifically identified software module.

[0021] In some embodiments of the method of any of the foregoing example embodiments and any combination of any of the foregoing example embodiments, searching the local copy of the MR includes searching the local copy of the MR for any software module that can be used to perform the task without specific identification of the software module.

[0022] In some example embodiments of the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments, the distributed ledger and thereby the local copy of the MR also include immutable entries specifying access rights to multiple software modules including the one software module, and wherein the method also includes, before using the software module, the source node searching the local copy of the MR for an immutable entry indicating that the source node is authorized to access the software module, and the source node uses the software module only if the source node is authorized.

[0023] In some example embodiments of the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments, the method also includes the source node: recording use of the one software module in an additional immutable entry in the local copy of the MR; and broadcasting the additional immutable entry to those of the multiple nodes within radio range of the source node to initiate synchronization of the local copy of the MR with a copy of the MR at other nodes of the multiple nodes.

[0024] Some example embodiments provide a source node operable in a wireless ad hoc network comprising a plurality of nodes, the source node comprising a memory configured to store a computer-readable program code; and a processing circuit configured to access the memory and execute the computer-readable program code so that the source node performs at least the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments.

[0025] Some example embodiments provide a neighboring node operable in a wireless self-organizing network comprising a plurality of nodes, wherein nodes within a radio range of a source node are neighboring nodes, the one neighboring node comprising a memory configured to store a computer-readable program code; and a processing circuit configured to access the memory and execute the computer-readable program code so that the one neighboring node performs at least the method of any of the foregoing example embodiments or any combination of any of the foregoing example embodiments.

[0026] By reading the following detailed description and the accompanying drawings briefly described below, these and other features, aspects and advantages of the present disclosure will become apparent. The present disclosure includes any combination of two, three, four or more features or elements elaborated in detail in the present disclosure, regardless of whether such features or elements are explicitly combined or narrated in the specific example embodiments described herein. The present disclosure is intended to be read as a whole, so that in various aspects and example embodiments of the present disclosure, any separable features or elements of the present disclosure should be considered combinable, unless the context of the present disclosure clearly indicates otherwise.

[0027] Therefore, it will be understood that the present disclosure is provided only for the purpose of summarizing some example embodiments in order to provide a basic understanding of some aspects of the present disclosure. Therefore, it will be understood that the example embodiments described above are merely examples and should not be interpreted as narrowing the scope or spirit of the present disclosure in any way. Other example embodiments, aspects and advantages will become apparent from the following detailed description in conjunction with the accompanying drawings that illustrate by way of example the principles of some of the described example embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Having thus described example embodiments of the present disclosure in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and in which:

[0029] Figure 1 shows a wireless ad hoc network that may be useful for example implementations of the present disclosure;

[0030] Figure 2 A wireless ad hoc network including a number of unmanned vehicles and ground stations is shown according to an example implementation of the present disclosure;

[0031] Figure 3A , Figure 3B , Figure 3C and Figure 3D shows a process by which an unmanned vehicle (source node) may acquire a software module according to some example embodiments of the present disclosure;

[0032] Figure 4 and Figure 5 A wireless ad hoc network according to an example implementation of the present disclosure is shown;

[0033] Figure 6 A system including a plurality of wireless ad hoc networks according to an example implementation is shown;

[0034] Figure 7 , Figure 8 and Fig. 9 is a flowchart illustrating various operations in a method of acquiring software by a source node in a wireless ad hoc network including a plurality of nodes according to an example embodiment; and

[0035] Fig.10 Devices according to some example embodiments are shown. DETAILED DESCRIPTION

[0036] Some embodiments of the present disclosure will now be described more fully with reference to the accompanying drawings, in which some but not all embodiments of the present disclosure are shown. In fact, various embodiments of the present disclosure can be implemented in many different forms and should not be interpreted as limited to the embodiments elaborated in detail herein; on the contrary, these example embodiments are provided so that the present disclosure will be comprehensive and complete and will fully convey the scope of the present disclosure to those skilled in the art. For example, unless otherwise specified or clearly known from the context, references to first, second, etc. should not be interpreted as implying a specific order. A feature may be described as being above another feature (unless otherwise specified or clearly known from the context), may be below another feature, and vice versa; and similarly, a feature described as being on the left side of another feature may also be on the right side, and vice versa. As used herein, unless otherwise specified or clearly known from the context, an "or" of a set of operands is an "inclusive or", and thus if and only if one or more of the operands is true, the "inclusive or" is true, contrary to the "exclusive or" which is false when all operands are true. Thus, for example, if [A] is true, or if [B] is true, or if [A] and [B] are both true, then "[A] or [B]" is true. In addition, the articles "a" and "an" mean "one or more" unless otherwise specified or clear from context to be directed to the singular. Like reference numerals refer to like elements throughout.

[0037] Example embodiments of the present disclosure generally relate to software distribution, and in particular, to software distribution in a wireless ad hoc network for self-organizing data processing on a source node. Some example embodiments provide a method for obtaining software by a source node in a wireless ad hoc network including a plurality of nodes. As described herein, a "node" is a physical network node, i.e., an active electronic device capable of generating, transmitting or receiving information through a communication channel. An example of a suitable node is an autonomous machine that is configured to perform tasks independent of human intervention or with minimal human intervention. And examples of suitable autonomous machines include autonomous robots and various unmanned vehicles including unmanned ground vehicles (UGVs), unmanned aerial vehicles (UAVs), unmanned surface vehicles (USVs), unmanned underwater vehicles (UUVs), and unmanned spacecraft. These can include self-driving cars, airplanes, trains, industrial vehicles, distribution center robots, supply chain robots, robotic vehicles, mine sweepers, etc. Other examples of suitable nodes include computers, computer systems, etc.

[0038] Figure 1 A wireless ad hoc network 100 that may be useful for an example embodiment of the present disclosure is shown. As shown, the wireless ad hoc network includes nodes of various unmanned vehicles 102, such as various UAVs 102a, UGVs 102b, USVs 102c, UUVs 102d, and unmanned spacecrafts 102e, that are shown to be deployable when performing a mission. A mission may involve one or more of the unmanned vehicles, during which the unmanned vehicles may be connected to one another. In this regard, the unmanned vehicles may be connected to one another via corresponding communication channels and may be connected to a ground station 104 (another node). Although shown as a network of unmanned vehicles, it should be understood that the wireless ad hoc network may include one or more autonomous robots or other autonomous machines in addition to or in place of unmanned vehicles. And as explained below, even more generally, a wireless ad hoc network may simply include multiple nodes.

[0039] Each of one or more of the nodes of the wireless ad hoc network 100 including unmanned vehicles 102 and / or ground stations 104 may include a collection of sensors 106, software modules 108, a module repository (MR) 110, and a module search service (MSS) 112 (specifically shown for the unmanned spacecraft 102e).

[0040] In some examples, the set of sensors 106 is configured to collect data when the unmanned vehicle is performing a mission, and the software module 108 is used to process or analyze the data, such as for planning, collection, analysis, data distribution, etc. In this regard, the unmanned vehicle 102 can process the raw data and store it locally, and if possible and necessary, it can also be transmitted. In some examples, the software module can also be used to add metadata to the raw data, and the metadata can be stored and / or transmitted with the raw data.

[0041] A software module 108 is a computer program that is configured to acquire one or more input data sources (raw or derived data) and zero or more configuration control sources that determine how the data should be manipulated and produce one or more output modalities of the data. The software module uses one or more well-known or predefined interfaces to communicate with its host or other software modules or workflows. The software module may follow a well-known communication protocol via a plug-in endpoint, such as via an API (application programming interface). For example, the software module may use the Hypertext Transfer Protocol Secure (HTTPS) protocol in conjunction with a published Representational State Transfer (REST) ​​API.

[0042] One or more of the software modules 108 may enable the generation and execution of a workflow. A workflow includes software modules organized in an execution hierarchy, such as a DAG (directed acyclic graph), to acquire data, or as a feedback control system to improve the quality of output data within a workflow. A workflow is an interconnection of software modules such that the output of one software module serves as an input or control to another software module in a DAG configuration or in a deterministic feedback mechanism that improves the output of the workflow in some way. A workflow may also be used as a software module. A software module or workflow may be executed as a linear program, or in parallel based on design, implementation, and capabilities.

[0043] Software modules 108 (and workflows) may have similar or varying capabilities. Software modules may have permission to read and, when appropriate, write data. Software modules may read original data and may generate further data in the form of derived data. Software may or may not have permission to manipulate original data or derived data. In this regard, software modules may read derived data and even generate further data in the form of further derived data. Derived data may be smaller or larger than the (source) data derived therefrom. If smaller, the derived data may be a small portion of the source data.

[0044] Depending on the available communication capabilities, connectivity, connection authorization, distribution authorization, and reception authorization, the data in partial or complete form (raw or derived data) can be delivered as a service to one or more destinations. Examples of suitable destinations include other unmanned vehicles 102, ground stations 104, manned vehicles, mobile or fixed communication terminals, etc.

[0045] Examples of suitable software modules 108 include a computer vision module, a content management module, a network security module, a data optimization module, a data reduction module, a data quantization module, a data analysis module, a machine-to-machine communication module, a machine learning (ML) module, an artificial intelligence (AI) engine, and a client software module that communicates with other software modules on the same unmanned vehicle 102 or other unmanned vehicles.

[0046] In addition to the sensors 106 and the software modules 108, the unmanned vehicle 102 (and the ground station 104) may also include a MR 110 and a MSS 112. The MR and MSS may run on one or more computers in a distributed manner. The MR and MSS may also run on a computer on the unmanned vehicle 102.

[0047] MR 110 is a repository containing one or more software modules 108 (non-installed copies of software modules). Examples of well-known commercial MRs include Docker Hub and Amazon Container Registry. Similar to well-known MRs, MR stores software modules on a storage device and manages CRUD (create, read, update, and delete) operations, permissions, version control, etc. on the software modules.

[0048] MSS 112 is a service running on a computer on the unmanned vehicle 102 (or ground station 104). MSS provides a list of available software modules 108 based on search criteria and the nodes on which the software modules are available. MSS learns over time the same as well-known search engines in terms of the capabilities of available software modules, search requests from unique nodes, requirements of various nodes, new content being published, and old content being deleted.

[0049] According to example embodiments of the present disclosure, the MSS 112 on the unmanned vehicles 102 (and perhaps the ground stations 104) can form a dynamic mesh network that can be organized in a manner similar to a typical Domain Name System (DNS) network. Requests and responses can be handled by an API hosted by a server on the unmanned vehicle. The MSS grid across connected unmanned vehicles can also be organized in a manner similar to a Content Delivery Network (CDN).

[0050] In some specific examples, the wireless ad hoc network 100 may include limited-use unmanned vehicles 102 arranged in a geographic cluster network. The unmanned vehicles can be placed together and their communication networks synchronized into the cluster, loading and exporting software modules 108 compatible with the unmanned vehicles. Each unmanned vehicle can collect data and transmit it to one of the unmanned vehicles designated as the primary vehicle. The primary vehicle can be configured to combine the data into a single system and present it in real time to a designated receiver such as a ground station 104 for actionable processing.

[0051] According to an example embodiment of the present disclosure, the MSS 112 running on the unmanned vehicle 102 may be configured to search for one or more requested software modules 108 within its own MR 110, or broadcast a request to other MSSs to search for the requested software modules in their corresponding MRs. To avoid looping requests, each request may be accompanied by a unique identifier, such as a universally unique identifier (UUID), which may also be maintained or accompanied by a timestamp (e.g., UTC), a requesting unmanned vehicle identifier, a security token, access control parameters, and other identifiers and permissions, such as those found in standard Web-based security tokens.

[0052] When the MSS 112 receives a request from the requesting MSS, it can verify that it has not already received and processed the same request in the recent past. To verify the request, the MSS can compare time-stamped tokens from previous requests. In this regard, the MSS can sort previous requests by when its unmanned vehicle 102 received those requests, the identifier of the requesting unmanned vehicle, and when the request was made. If the MSS has already received and processed the same request in the recent past, the MSS can simply ignore the request, or alternatively can return an error to the requesting MSS to notify the requesting MSS that the request is a duplicate request or a potential looping request.

[0053] In some example embodiments, nodes of the wireless ad hoc network 100 including the unmanned vehicle 102 and / or the ground station 104 may also include a distributed ledger (DL) 114 and a DL software server (DSS) 116 (specifically shown for the unmanned spacecraft 102e). Similar to the MR 110 and the MSS 112, the DL and DSS may be run on one or more computers in a distributed manner and may also be run on computers on the unmanned vehicle, ground station, etc.

[0054] The DL 114 and DSS 116 may implement a distributed ledger technology (DLT) model to provide event-level traceability, event-triggered activities, and communicate software module inventory and utilization. Traceability may take into account who / which node requested the software module 108, which node (or MSS 112) broadcast or rebroadcast the request, which node has the requested software module, etc. The DLT model may provide authorization to send, receive, and load software modules, which may result in verification and confirmation of the transfer and authorization. The API may then be triggered to provide space for the software module while the software module is in transit, adjust any prerequisite items, and begin loading or installing the software module once the transfer is verified to be complete. The DLT model may also track the number of times a single software module has been requested, which may enable the software module to be preloaded into certain nodes that are closer to the requested situation, and to be removed from nodes that are not actively using it, thereby better utilizing the software module, reducing discovery time, and making resources available that do not require the software module.

[0055] DL 114 is a distributed ledger that is replicated, shared, and synchronized across nodes of a wireless ad hoc network including unmanned vehicles 102 and / or ground stations 104, each node having a local copy of the distributed ledger. DSS 116 is a server configured to manage the DL or more specifically the corresponding local copy of the DL. In some examples, the DSS is configured to record digital data in additional immutable entries in the local copy of the DL and implement a consensus algorithm to ensure replication and synchronization of digital data across nodes.

[0056] The DL 114 is a consensus of replicated, shared, and synchronized digital data that is passed across nodes. In some examples, the DL is implemented as a database that is passed across the nodes, with each node replicating and saving a respective local copy of the DL and updating it independently. The DL and thus each respective local copy include immutable entries of digital data, where immutability is defined as the unchangeability of digital data stored in the DL.

[0057] In some examples, the DL 114 can be implemented as a blockchain, which is a growing list of immutable entries (records) called blocks that are linked and protected using cryptography. Each block in the blockchain can contain a cryptographic hash of the previous block, a timestamp, and transaction data. The blockchain is inherently resistant to modification of the digital data stored in the blockchain. The blockchain can be used as a decentralized, distributed, and public or private authority based on a digital ledger for recording transactions across nodes of a wireless ad hoc network.

[0058] Thus, the DL 114 may include immutable entries with many different types of data related to the wireless ad hoc network 100, its nodes (e.g., unmanned vehicles 102, ground stations 104), and sensors 106 of its nodes, software modules 108, MR 110, and / or MSS 112. In some examples, the DL includes immutable entries that specify access rights to software modules of nodes of the wireless ad hoc network that can be used including unmanned vehicles (or ground stations if not). Additionally or alternatively, in some examples, the DL includes immutable entries in which transactions between nodes are recorded. The DL may include immutable entries indicating the configuration of the workflow generated from the software module. In some examples, the MR 110 may be implemented as a DL; and in these examples, the DL and thereby the MR may include immutable entries with software modules of nodes that can be used for the wireless ad hoc network.

[0059] In some examples, a node of the wireless ad hoc network 100 may serve as a central node for the wireless ad hoc network. Figure 1 In the wireless ad hoc network shown in , the ground station 104 can be used as a central node. The central node can include a software module 108 as well as a master MR 110', a central MSS 112', a master DL 114' and a central DSS 116'. The central node can participate in software distribution similar to other nodes of the wireless ad hoc network. Additionally or alternatively, in some examples, the central node can enable initial software definition, including the master MR and the master DL as authorized MRs and DLs for the wireless ad hoc network, and provide optimization analysis for software distribution in the wireless ad hoc network.

[0060] In some examples, at the beginning of a mission performed by a node of the wireless ad hoc network 100, the unmanned vehicle 102 may be loaded with critical information, such as critical information from a central node (e.g., a ground station 104). Such information may include, for example, a list of capabilities of the onboard sensors 106 and software modules 108. The information may include a list of software modules available in the wireless ad hoc network, and optionally other wireless ad hoc networks in the same operating area as the wireless ad hoc network. The information may include permissions regarding which unmanned vehicles the unmanned vehicle can request software modules from and / or which unmanned vehicles to transfer software modules to. The information may include any relevant encryption algorithms for the DL 114. In addition, for example, the information loaded onto the unmanned vehicle may include instructions for which other unmanned vehicles within the wireless ad hoc network the unmanned vehicle can synchronize with to maintain authorization for the DL.

[0061] To illustrate an example implementation of the present disclosure, consider that a first one of the unmanned vehicles 102 (the first unmanned vehicle) has an AI engine that detects new patterns and new modalities of data within the data collected by its one or more sensors 106. The AI ​​engine identifies a need to perform a task, such as processing a new modality of data, but determines that the first unmanned vehicle lacks a software module 108 that can be used to perform the task.

[0062] In a specific example, consider a UGV 102b that is configured to scan for mines before scanning the ground. The UGV looks at the ground for disturbances and scans for metal. If the mine is made of a ceramic material, the UGV may pass through it. According to an example embodiment, the UGV may request a software module compatible with its onboard sensors 106 to determine the material composition. This will enable the UGV to detect the ceramic composition, update its composition table, and perform future scans in the area to be able to identify additional ceramic mines and either mark them or detonate them according to mission instructions.

[0063] The AI ​​engine of the first unmanned vehicle 102 generates a description of the problem, and the MSS 112 of the first unmanned vehicle (the first MSS) broadcasts a request including the description of the problem, and may include with the request a unique token pointing to the first unmanned vehicle and the request (a first token generated from or using a local copy of the DL 114). The first MSS may broadcast the request using a predefined protocol or as free-form content (after an unsuccessful search of its local MR 110). The first MSS may broadcast the request using well-known protocols such as Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), User Datagram Protocol (UDP), etc., optionally using encryption or other well-known or proprietary security mechanisms. In this regard, the first MSS may use a proprietary method of packaging the request and broadcasting the request, optionally using encryption or other well-known or proprietary security mechanisms.

[0064] The second one of the unmanned vehicles 102 (the second unmanned vehicle) receives the request and may compare it to a local copy of the DL 114 to determine authorization or denial before allowing communication between the node of the software module 108 and the transmission.

[0065] The second MSS 112 (second MSS) of the unmanned vehicle 102 receives the request and can verify the request to see if the first unmanned vehicle is authorized and thereby authorizes the first MSS to make the request and receive the software module 108. The second MSS can request verification of the authorization of the first unmanned vehicle, and the DSS 116 (second DSS) can access the corresponding local copy of the DL 114 and search for an immutable entry in the corresponding local copy, which indicates that the first unmanned vehicle is authorized and has access to the software module. Additionally or alternatively, the DSS can record the request in an additional immutable entry in the corresponding local copy of the DL and synchronize the corresponding local copy with other local copies of the DL, optionally using encryption or other well-known or proprietary security mechanisms. The recorded request can include information such as the requested software module, the source node, the node recording the request (e.g., the second unmanned vehicle), the status of the transmission of the required network / protocol associated with enabling the transmission, the authorization for network use, and / or the like. In the event of an error, the second MSS may return "Permission Denied", or may choose not to respond for security reasons. Similarly, the second MSS may check whether it has already received and processed the request containing the first token; and if so, the second MSS may return and display a "Duplicate Request" error message.

[0066] If the check indicates that the request is unique and the first unmanned vehicle is authorized, the second MSS 112 can search its local MR 110 for a software module 108 (one or more) that sends a solution to the problem described in the request. If the second MSS fails to locate such a software module, the second MSS can rebroadcast the request to the MSSs of other unmanned vehicles in the unmanned vehicle 102. On the other hand, if the second MSS does locate such a software module in its local MR, the second MSS can send a response to the first MSS that it has a software module that can solve the problem. The first MSS can receive the response from the second MSS. The first unmanned vehicle can request and receive a software module from the MR of the second unmanned vehicle in response. The first unmanned vehicle can verify the module (e.g., for integrity and security), and start the software module and use it to perform tasks (e.g., process new data modalities). In the event of an error, or if the first unmanned vehicle fails to receive a response within a specific time period, the first unmanned vehicle can retry or abandon the request, such as based on a machine learning inference engine decision or heuristics programmed into the software module.

[0067] In some examples, the access rights specified in DL 114 can specify certain access rights to the software module; and in these examples, the first unmanned vehicle can use the software module in accordance with those certain access rights. The access rights can specify that the access rights expire, such as after a limited time or a limited number of uses. In some of these examples, the first unmanned vehicle can delete the software module when the access rights expire; and the deletion of the software module by the first unmanned vehicle can be recorded in the DL and synchronized across the nodes.

[0068] In various examples, the DSS 116 may record requests and / or responses between the nodes (or more particularly, their MSSs 112) in immutable entries in the DL 114, which may be synchronized across the nodes of the wireless ad hoc network 100. This may be used for many different purposes, such as verifying the efficacy of the nodes participating in the search and satisfaction of requests for software patterns. Similarly, node usage of software modules 108 may be recorded in the DL and synchronized across the nodes. In examples where a node configures a workflow from a software module, the configuration of the workflow may also be recorded in the DL and synchronized across the nodes.

[0069] In some examples, the ground station 104 can receive the request and process the request in the same or similar manner as the second unmanned vehicle in the unmanned vehicle 102. The ground station can simply be another node in the wireless ad hoc network 100. However, in some examples, the ground station (or even the second unmanned vehicle itself) can be used as a central node for the wireless ad hoc network. As described above, in these examples, the central node can include a software module 108, as well as a master MR 110', a central MSS 112', a master DL 114', and a central DSS 116' for the wireless ad hoc network.

[0070] Figure 2 A wireless ad hoc network 200 according to an example embodiment of the present disclosure is shown, which includes nine unmanned vehicles UV1-UV9 that may correspond to the unmanned vehicle 102 and a ground station GS1 that may correspond to the ground station 104. Each of one or more of the unmanned vehicles UV1-UV9 may include a sensor 206, a software module 208, an MR 210, an MSS 212, a DL 214, and a DSS 216, which may correspond to corresponding ones of the sensor 106, the software module 108, the MR 110, the MSS 112, the DL 114, and the DSS 116. The ground station GS1 may also include at least corresponding MRs, MSSs, DLs, and DSSs.

[0071] In this regard, consider an example where UV1 is performing a task, its sensors are capturing data, and it has an AI engine that processes the data. The AI ​​engine identifies the need to perform a task, such as processing a new data modality, and it needs to search for one or more software modules M that can solve the problem of performing the task. The other unmanned vehicles in the unmanned vehicle fleet, namely UV4 and UV7, have software modules M as does ground station GS1.

[0072] Among the unmanned vehicles, UV2, UV3, and UV4 are within radio range of UV1 at time T1. Unmanned vehicle UV2 is further within radio range of UV6 and UV7, and unmanned vehicle UV3 is further within radio range of UV5, UV6, and UV7. And unmanned vehicle UV7 is further within radio range of UV8 and UV9 and ground station GS1.

[0073] Figures 3A-3D The process according to some example embodiments of the present disclosure is shown, wherein reference is made to Figure 2 In the wireless ad hoc network 200, the unmanned vehicle UV1 (source node) can obtain the software module M through the process (without separately showing the sensor 206, the software module 208, the MR 210, the MSS 212, the DL 214 and the DSS 216). When the AI ​​engine of UV1 identifies the need to perform a task (e.g., processing data of a new modality), UV1 requests the software module M that can be used to perform the task. As shown in FIG. 3a, when the MSS 212 of UV1 fails to locate the software module M in its local MR 210, the MSS broadcasts the request to the neighboring parts of UV1 within the radio range of UV1, namely UV2, UV3 and UV4.

[0074] Unmanned vehicles UV2, UV3, and UV4 receive the request and search the corresponding local copies of DL 214 to verify that UV1 has access to software module M. Unmanned vehicles UV2, UV3, and UV4 may also record the request in the corresponding local copies of DL and synchronize their corresponding local copies with other local copies across the wireless ad hoc network 200. DL has an immutable entry indicating that UV1 is authorized to access software module M.

[0075] Unmanned vehicle UV4 has software module M, and sends a response to the request; however, due to connectivity issues, it is now out of radio range of UV1, so the response does not reach UV1 and eventually times out. Unmanned vehicles UV2 and UV3 do not have software module M, so they rebroadcast the request. In particular, UV3 rebroadcasts the request to its further neighbors, namely UV5, UV6 and UV7, which are within further radio range of UV3. And unmanned vehicle UV2 rebroadcasts the request to its further neighbors, namely UV6 and UV7, which are within further radio range of UV2.

[0076] Unmanned vehicles UV5, UV6, and UV7 receive the request(s) and search the respective local copies of DL 214 to verify that UV1 has access to software module M. Unmanned vehicles UV5, UV6, and UV7 may also record the request(s) in respective local copies of DL and synchronize their respective local copies with other local copies across the wireless ad hoc network 200. As before, DL has an immutable entry indicating that UV1 is authorized to access the software module.

[0077] like Figure 3B As shown in , unmanned vehicles UV5 and UV7 do not have software module M and send a NO response to UV3. Unmanned vehicle UV7 has software module M and sends a YES response to UV3. Since UV6 and UV7 have already received the request from UV3, they ignore the request rebroadcast by UV2 or send a duplicate request error to UV2. Therefore, unmanned vehicle UV2 sends a NO response to UV1. Similar to the request(s), these responses can also be recorded in the corresponding local copies of DL 214 and synchronized across the wireless ad hoc network 200.

[0078] like Figure 3C As shown in FIG, in response to a YES response from UV7, unmanned vehicle UV3 sends a GET MODULE request to UV7 for software module M. In response, UV3 receives software module M from UV7, verifies software module M and saves software module M in its local MR 210, and updates its MSS 212 to reflect that it now has software module M. Unmanned vehicle UV3 also sends a YES (confirmation) response to UV1. The GET MODULE and response, as well as the YES response, can be recorded in the DL 214, similar to other requests and responses.

[0079] like Figure 3DAs shown in , in response to the yes response, the unmanned vehicle UV1 sends a GET MODULE for software module M to UV3. The unmanned vehicle UV1 receives software module M from UV3, verifies software module M and saves software module M in its local MR 210, and updates its MSS 212 to reflect that it now has software module M. Likewise, the GET MODULE and response can be recorded in the DL 214. The unmanned vehicle UV1 starts software module M through a set of known rules, and initializes software module M and connects to software module M. The unmanned vehicle UV1 can also test software module M, and if UV1 encounters a failure, it logs it and terminates software module M. Otherwise, UV1 is ready to use software module M. And in some examples, UV1 returns and logs can be further received for aggregation and analysis. Likewise, in some examples, UV1 can log the use of software module M in the DL.

[0080] Simply return to Figure 1 To further illustrate an example implementation of the present disclosure, consider another example of a UAV 102a having sensors 106 that transmit data of various different modalities. For example, in particular, the sensors may include one or more of the following:

[0081] (1) a high-resolution, ultra-high-definition (4K or 8K UHD) video camera configured to capture video at 60 Hz,

[0082] (2) a medium resolution high definition (1080P HD) stereo camera configured to capture video at 30 Hz,

[0083] (3) an ultra-high resolution, wide-area surveillance multi-camera assembly having an effective image size greater than 2000 megapixels per frame at 2 Hz monochrome (black and white),

[0084] (4) a wide area surveillance or wide area motion imagery (WAMI) multi-camera assembly having an ultra-high resolution effective image size of 250 megapixels per frame at 2 Hz near infrared (NIR),

[0085] (5) LiDAR (Light Detection and Ranging) Sensor,

[0086] (6) Highly accurate and reliable satellite-based navigation (e.g., GPS) and inertial measurement unit (IMU) devices that determine absolute and relative position (pitch, yaw, and roll state), and / or

[0087] (7) One or more sensors providing high-precision pan-tilt-zoom status of each camera.

[0088] Additionally, the UAV may include a Tactical Common Data Link (TCDL) or Common Data Link (CDL) for air-to-ground communications when within line of sight, SATCOM (satellite communications), etc.

[0089] In the example above, a high-resolution, ultra-high-definition video camera can allow a detailed zoomed-in view of what the camera is looking at with very high spatiotemporal resolution, with high-precision spatial (latitude longitude) positioning available for each pixel. A medium-resolution high-definition stereo camera can allow the generation of a real-time 3D model at medium resolution of the area the camera is looking at with high-precision 3D positioning available for each pixel (latitude, longitude, elevation below mean sea level and above ground level).

[0090] Ultra-high-resolution, wide-area surveillance multi-camera assemblies and Ultra-high-resolution wide-area surveillance or WAMI multi-camera assemblies can provide high-resolution views over very wide areas, for example, monochrome sensors like the ground Figure 1 Looking down like this, consider a 45,000 x 45,000 pixel image looking down from an airplane, capturing data at about 25 centimeters per pixel, thus covering an area of ​​about 11 kilometers by 11 kilometers, or over 120 square kilometers. At that resolution captured at two frames per second, one could capture two people playing tennis and register the presence of the tennis ball based on sub-pixel distortion and shadows. NIR images can be one-eighth the screen resolution of a monochrome sensor.

[0091] The LiDAR sensor can provide a very precise location of each point captured, but the distance between two points cannot be that short. Various positioning sensors including satellite-based navigation and IMU devices and (one or more) sensors that provide pan-tilt-zoom state can provide the ability to know where the UAV 102a is located, how it is oriented, and what it is looking at from the perspective of each sensor.

[0092] The UAV 102a may be preloaded with one or more software modules 108 configured to calculate the product of each of the data sets. Thus, the UAV may have onboard storage and computing resources sufficient to generate and serve very large monochrome images and then interpolate near infrared or NIR data on the ultra-high resolution monochrome. Thus, the UAV is able to generate a single 45000 x 45000 pixel image with 2 bands, monochrome (black and white) and NIR. The UAV may also be preloaded with one or more software modules configured to generate 3D models from stereo cameras, use computer vision to generate 2.5D models by using 8K cameras, and "clean up" 3D meshes from LiDAR data.

[0093] In various examples, the UAV 102a may determine that the UAV lacks a software module 108 that can be used to merge data sets and generate, for example, tracks of all objects moving from the WAMI data and identify the shape and temperature of each object. The UAV may determine that it lacks a software module that can be used to take this WAMI temperature and location data and predict whether the object is a vehicle in motion or a person in motion. The UAV may lack a software module that can be used to generate a very accurate 3D model of a specific area of ​​interest in that area of ​​certain moving objects or, for example, a moving car or a house relative to a car or a line of animals or people or vehicles moving in that broad area, and then zoom in and use computer vision to identify the make and model of vehicles, weapons, or people in that area. The UAV may lack training data and an inference model to use machine learning to infer the type of danger in the area being viewed by the sensor.

[0094] In these and similar examples, the UAV 102a may lack the appropriate software module 108 or a software module that performs each task but includes the necessary computing resources. When authorized, the UAV may search for the software module in its local MR 110, and when the UAV fails to locate it, broadcast a request for the software module in a manner similar to UAV1 above. In some examples, multiple software modules may be organized in an execution hierarchy, such as a DAG - workflow. In some of these examples, the nodes in the DAG may be software modules connected by edges, which are data and control paths between software modules.

[0095] As indicated above, although primarily described in the context of unmanned vehicles, example embodiments of the present disclosure are more generally applicable to wireless ad hoc networks comprising a plurality of nodes. Other examples of suitable nodes include computers such as desktop computers, server computers, portable computers (e.g., laptop computers, tablet computers), mobile phones (e.g., cell phones, smart phones), wearable computers (e.g., smart watches), etc. These computers can be stand-alone or embedded in larger mechanical or electrical systems.

[0096] Figure 4 A wireless ad hoc network 400 including a plurality of nodes 402 is shown according to an example implementation of the present disclosure. The plurality of nodes include a source node 402a, the source node being configured to execute application software (e.g., software module) 408a from which a need to perform a task such as processing data of a particular modality is identified. In some examples, the source node has a collection of sensors 406a, one of which is configured to generate or provide data of a particular modality to the application software 408a from which a need to perform a task is identified.

[0097] The source node 402a is configured to determine that the source node cannot perform a task (e.g., process data of a particular modality). In some examples, the determination is made by the application software 408a. In other examples, the determination is made from a request received by the source node from a remote terminal such as a ground station.

[0098] In response to the determination, the source node 402a is configured to access a corresponding local copy of a distributed ledger DL 410a that is replicated, shared, and synchronized across multiple nodes 402. The DL and thus the corresponding local copy include immutable entries that specify access rights to multiple software modules including software modules that can be used to perform the task. The source node is configured to search the immutable entries of the corresponding local copy for an immutable entry that indicates that the source node is authorized to access the software module.

[0099] The source node is configured to search for a software module that can be used to perform a task in the local module repository MR 412a of the source node only when the source node 402a is authorized. The source node is configured to broadcast a request for the software module to those of a plurality of nodes within the radio range of the source node, which are thus neighboring nodes 402b, 402c, in response to the source node failing to locate the software module in the local MR. Although not shown separately for all nodes 402, in some examples, the source node and other nodes of the wireless ad hoc network 400 may also include local MSSs, sensors and / or software modules.

[0100] In some examples, the source node 402a is configured to search the local MR 412a for a specifically identified software module and broadcast a request specifically identifying the software module. In other examples, the source node is configured to search the local MR for any software module that can be used to perform the task without the specific identification of the software module. In these other examples, the source node is configured to broadcast the request describing the task or the object of the task (e.g., data of a specific modality) and does not include the specific identification of the software module.

[0101] In some examples, the source node 402a is configured to record the request in an additional immutable entry in the corresponding local copy of the DL 410a. In some of these examples, the source node is configured to broadcast the additional immutable entry to neighboring nodes 402b, 402c to initiate synchronization of the corresponding local copy of the DL with the copy of the DL at other nodes in the plurality of nodes, optionally using encryption or other well-known or proprietary security mechanisms.

[0102] In some further examples, the source node 402a is configured to receive, in response to the neighboring node recording the request broadcasted from the source node, further additional immutable entries broadcasted from neighboring nodes 402b (optionally using encryption or another security mechanism), 402c in the corresponding copy of the DL at the neighboring node. In some of these examples, the source node is configured to add the further additional immutable entries to the corresponding local copy of the DL 410a to synchronize the corresponding local copy with the corresponding copy of the DL at the neighboring node.

[0103] In response to the request broadcast by the source node 402a, one of the neighboring nodes 402b is configured to access the corresponding local copy of the DL 410b and search the immutable entries of the corresponding local copy for an immutable entry indicating that the source node is authorized to access the software module. The neighboring node is configured to search for the software module in the corresponding local MR 412b of the neighboring node only when the source node is authorized. The neighboring node is configured to rebroadcast the request to those nodes in the plurality of nodes within the radio range of the neighboring node, which are further neighboring nodes 402d, 402e, in response to the neighboring node failing to locate the software module in the corresponding local MR.

[0104] The neighboring node 402b is configured to receive the software module from a further neighboring node 402d in the plurality of further neighboring nodes. The source node 402a is configured to receive the software module from the neighboring node 402b. In some examples, this includes the source node 402a being configured to receive a response from the neighboring node 402b indicating that the neighboring node has the software module. In these examples, the source node is configured to unicast a second request for the software module to the neighboring node, and in response to the second request, receives the software module from the neighboring node.

[0105] After receiving the software module, the source node 402a is configured to perform the task using the software module. In some examples, the source node is configured to perform operating system level containerization. This includes the source node being configured to generate and start an isolated container on the source node in which the software module is used. The isolated container is a kind of operating system level (OS level) virtualization. Unlike the hardware virtualization of the node that uses a hypervisor (rather than a container engine) to generate a virtual machine to simulate the node, it usually requires less overhead. From the perspective of the software application executed therein, the isolated container can be displayed as a real node, but these applications only have visibility to the resources of the source node assigned to it, and it is believed that these are all available. Then, the generation of the isolated container can include the source node being configured to install the software module in the isolated container.

[0106] In some examples, the source node 402a is configured to record the receipt of the software module in an additional immutable entry in the corresponding local copy of the DL 410a. In some of these examples, the source node is configured to broadcast the additional immutable entry to neighboring nodes 402b, 402c to initiate synchronization of the corresponding local copy of the DL with the copy of the distributed ledger at other nodes in the plurality of nodes (including the DL 410b).

[0107] In some examples, the source node 402a is configured to record the use of the software module in an additional immutable entry in the corresponding local copy of the DL 410a. In some of these examples, the source node is configured to broadcast the additional immutable entry to the neighboring nodes 402b, 402c to initiate synchronization of the corresponding local copy of the DL with the copy of the DL at other nodes in the plurality of nodes (including the DL 410b).

[0108] From another perspective, in some examples, the neighboring node 402b is configured to receive a request for a software module that can be used to perform tasks such as processing data of a specific modality from the source node 402a. This is in response to the source node failing to locate the software module in the local module repository MR 412a, wherein the request is broadcast from the source node to the neighboring nodes 402b, 402c. In some examples, the request includes a unique identifier, and the neighboring node is further configured to use the unique identifier and the record of the previous request received by the neighboring node to verify that the request is a new request for the software module from the source node 402a. In some examples, the corresponding local copy of DL 410b includes an immutable entry in which the previous request received by the neighboring node is recorded. In some of these examples, the neighboring node is configured to search for an immutable entry to verify that the request is a new request for the software module from the source node.

[0109] In response to the request, neighboring node 402b is configured to access a corresponding local copy of DL 410b including an immutable entry specifying access rights to the software module. The neighboring node is configured to search the immutable entries of the corresponding local copy for an immutable entry indicating that source node 402a is authorized to access the software module.

[0110] The neighboring node 402b is configured to search for the software module in the corresponding local MR 412b of the neighboring node only when the source node is authorized. The neighboring node 402b is configured to rebroadcast the request to those nodes in the plurality of nodes within the radio range of the neighboring node, which are further neighboring nodes 402d, 402e, in response to the neighboring node failing to locate the software module in the corresponding local MR.

[0111] In some examples, the neighboring node 402b is configured to search for a specifically identified software module in the corresponding MR 412b and rebroadcast a request to specifically identify the software module. In other examples, the neighboring node is configured to search for any software module that can be used to perform the task (e.g., process data of a specific modality) in the corresponding MR without the specific identification of the software module. In these examples, the neighboring node is configured to rebroadcast a request describing the task or the object of the task (e.g., data of a specific modality) and does not include the specific identification of the software module.

[0112] In some examples, the neighboring node 402b is configured to record the request in an additional immutable entry in the corresponding local copy of the DL 410b. In some of these examples, the neighboring node is configured to broadcast the additional immutable entry to the source node 402a and further neighboring nodes 402d, 402e to initiate synchronization of the corresponding local copy of the DL with the copy of the DL at other nodes of the plurality of nodes.

[0113] In some further examples, the neighboring node 402b is configured to receive, in response to the further neighboring node recording the request rebroadcasted from the neighboring node, the further additional immutable entries broadcasted from the further neighboring nodes 402d, 402e in the respective copies of the DL at the further neighboring node. In some of these examples, the neighboring node is configured to add the further additional immutable entries to the respective local copies of the DL 410b to synchronize the respective local copies with the respective copies of the DL at the further neighboring node.

[0114] The neighboring node 402b is configured to receive the software module from a further neighboring node 402d in the plurality of further neighboring nodes. In some examples, this may include the neighboring node being configured to receive a response from the further neighboring node indicating that the further neighboring node has the software module. In these examples, the neighboring node is configured to unicast a second request for the software module to the further neighboring node, and receive the software module from the further neighboring node in response to the second request.

[0115] After receiving the software module, the neighboring node 402b is configured to return the software module to the source node 402a that performs the task using the software module. In some examples, this may include the neighboring node being configured to send a response to the source node indicating that the neighboring node has the software module. The neighboring node is then configured to receive a second request for the software module unicast from the source node, and return the software module to the source node in response to the second request.

[0116] In some examples, the neighboring node 402b is configured to record the receipt of the software module in an additional immutable entry in the corresponding local copy of the DL 410b. In some of these examples, the neighboring node is configured to broadcast the additional immutable entry to the source node 402a and further neighboring nodes 402d, 402e to initiate synchronization of the corresponding local copy of the DL with the copy of the DL at other nodes in the plurality of nodes.

[0117] Figure 5 A wireless ad hoc network 500 including a plurality of nodes 502 according to other example embodiments of the present disclosure in which MR is implemented in DL is shown. The plurality of nodes include a source node 502a, the source node being configured to execute application software 508a, from which a need to perform a task such as processing data of a specific modality is identified. In some examples, the source node has a collection of sensors 506a, one of which is configured to generate or provide data of a specific modality to the application software 508a from which a need to perform a task is identified.

[0118] The source node 502a is configured to determine that the source node cannot perform the task. In some examples, the determination is made by the application software 508a. In other examples, the determination is made from a request received by the source node from a remote terminal such as a ground station.

[0119] In response to the determination, the source node 502a is configured to access a local copy of the module repository MR 510a implemented in the DL that is replicated, shared, and synchronized across multiple nodes 402. The DL and the local copy thereby include immutable entries with software modules that can be used for multiple nodes. The source node is configured to search for software modules that can be used to perform the task in the immutable entries of the local copy. In some examples, the source node is configured to search for specifically identified software modules in the local copy of the MR. In other examples, the source node is configured to search for any software module that can be used to perform the task in the local copy of the MR without the specific identification of the software module.

[0120] The source node 502a is configured to use the software module to perform the task. In some examples, the DL and thus the corresponding local copy of the MR 510a also include an immutable entry that specifies access rights to multiple software modules including the software module that can be used to perform the task. In some of these examples, the source node is configured to search the local copy of the MR for an immutable entry indicating that the source node is authorized to access the software module. In some of these examples, the source node is configured to use the software module only when the source node is authorized.

[0121] In some examples, the source node 502a is further configured to record the use of the software module in an additional immutable entry in the local copy of MR 510a. In some of these examples, the source node is configured to broadcast the additional immutable entry to those of the plurality of nodes within radio range of the source node (e.g., neighboring nodes 402b, 402c) to initiate synchronization of the local copy of the MR with the copy of the MR at other nodes of the plurality of nodes (including MR 510b).

[0122] Although described in the context of a wireless ad hoc network 100 including a plurality of nodes, such as unmanned vehicles 102 and ground stations 104, example embodiments of the present disclosure may be equally applicable to a plurality of wireless ad hoc networks, each of which includes a plurality of nodes. Figure 6 A system 600 including multiple wireless ad hoc networks 602 is shown according to some example embodiments, each of which may include multiple nodes 604. Each wireless ad hoc network may be constructed and operated as described herein for use in wireless ad hoc networks 100, 200, 400, 500. Each of the nodes may include corresponding sensors, software modules, MRs, MSSs, DLs, and DSSs (not shown separately). Nodes may distribute software modules within their respective wireless ad hoc networks and across wireless ad hoc networks in some examples. In some examples, nodes may move between wireless ad hoc networks.

[0123] Figure 7 700 is a flowchart illustrating various operations in a method 700 for acquiring software in a wireless ad hoc network 400 including a plurality of nodes 402 by a source node 402a according to an example embodiment. As shown at blocks 702 and 704, the method includes the source node executing an application software 408a from which a need for performing a task such as processing data of a specific modality is identified, and determining that the source node cannot perform the task. In response to the determination, the method includes accessing a corresponding local copy of a distributed ledger that is replicated, shared, and synchronized across the plurality of nodes, as shown at block 706. The distributed ledger and the corresponding local copy thereby include an immutable entry that specifies access rights to a plurality of software modules including a software module that can be used to perform the task. The method includes searching the immutable entries of the corresponding local copies for an immutable entry indicating that the source node is authorized to access the software module, as shown at block 708.

[0124] Only when the source node is authorized, the method 700 includes the source node 402a searching the local module repository MR412a of the source node for a software module that can be used to perform the task, as shown at block 710. The method includes, in response to the source node failing to locate the software module in the local MR, the source node broadcasting a request for the software module to those of the plurality of nodes within the radio range of the source node, which are thus neighboring nodes 402b, 402c, as shown at block 712.

[0125] In response to the request, a neighboring node 402b of the plurality of neighboring nodes searches for the software module in the corresponding local MR 412b of the neighboring node. In response to the neighboring node failing to locate the software module in the corresponding local MR, the neighboring node rebroadcasts the request to those nodes of the plurality of nodes within the radio range of the neighboring node, which are further neighboring nodes 402d, 402e. And the neighboring node receives the software module from a further neighboring node 402d of the plurality of further neighboring nodes. The method then further includes the source node receiving the software module from the neighboring node and performing the task using the software module, as shown at blocks 714 and 716.

[0126] Figure 8 8 is a flow chart illustrating various operations in a method 800 for acquiring software in a wireless ad hoc network 400 comprising a plurality of nodes 402 by a source node 402a, wherein those of the plurality of nodes within radio range of the source node are neighboring nodes 402b, 402c, according to other example embodiments. As shown at block 802, the method includes receiving, from a source node, a request by a neighboring node 402b of the plurality of neighboring nodes for a software module that can be used to perform a task such as processing data of a particular modality. The request is received in response to the source node failing to locate the software module in a local module repository MR412a, and the request is broadcasted from the source node to the neighboring nodes.

[0127] In response to the request, the neighboring node 402b accesses a corresponding local copy of the distributed ledger that is replicated, shared, and synchronized across multiple nodes, as shown at block 804. Similar to the above, the distributed ledger and the corresponding local copy thereof include immutable entries that specify access rights to the software module. The neighboring node searches the immutable entries of the corresponding local copy for an immutable entry that indicates that the source node 402a is authorized to access the software module, as shown at block 806.

[0128] Only when the source node 402a is authorized, the neighboring node 402b searches for the software module in the corresponding local MR 412b of the neighboring node, as shown at block 808. In response to the neighboring node failing to locate the software module in the corresponding local MR, the neighboring node rebroadcasts the request to those of the plurality of nodes within the radio range of the neighboring node, which are thus further neighboring nodes 402d, 402e, as shown at block 810. And the neighboring node receives the software module from one of the plurality of further neighboring nodes 402d, and returns the software module to the source node 402a which performs the task using the software module, as shown at blocks 812 and 814.

[0129] Fig. 9 Flowchart of various operations in a method 900 for obtaining software by a source node 402a in a wireless ad hoc network 400 including a plurality of nodes 402 according to yet another example embodiment. As shown at blocks 902 and 904, the method includes the source node executing an application software 408a from which a need for performing a task (e.g., processing data of a particular modality) is identified, and determining that the source node cannot perform the task. In response to the determination, the method includes accessing a local copy of an MR 412a implemented as a distributed ledger replicated, shared, and synchronized across a plurality of nodes, as shown at block 906. The distributed ledger and the local copy of the MR thereby include immutable entries with software modules available for a plurality of nodes. The method includes searching for a software module available for performing the task in the local copy of the MR, and performing the task using the software module, as shown at blocks 908 and 910.

[0130] Return to Figure 1 As explained above, the nodes of the wireless ad hoc network 100 including the unmanned vehicle 102 and / or the ground station 104 may include MR 110, MSS 112, DL 114, and DSS 116 to determine software configuration, software proximity, software access / authorization, etc. The DLT model implemented by the DL and DSS can be embedded in the system software layer, which provides an immutable record of software acquisition, distribution, configuration, and / or usage parameters. These parameters can be connected to an intermediate operation server via the DL, which can be implemented at an intermediate node (e.g., ground station 104). The intermediate operation server can coordinate the nodes, the wireless ad hoc network, and software event activities. Additionally or alternatively, the DLT model can be used to manage and control the software modules 108 introduced into and used within the wireless ad hoc network.

[0131] The introduction of the DLT model in the wireless ad hoc network 100 can simplify and improve the logistics management of software modules 108 registered and distributed within the wireless ad hoc network. The DLT model includes security features that can enhance the management and use of encryption within the wireless ad hoc network. The DLT model can also be used in intermediate nodes to facilitate the management of software modules introduced into the wireless ad hoc network by multiple software providers.

[0132] The DLT model can be used to establish an onboard record of software configuration, use and possible other vehicle events. This data can be used to determine the source of modules within the wireless ad hoc network 100. In some examples, DL 114 can be implemented in multiple DLs. The second DL can enable the sharing of autonomous network logic events between nodes, which can reduce logic operation overhead. This data can be used to determine the optimal data transmission of software module 108 from an adjacent node or a further adjacent node to a source node. In some examples, the DLT model can be used as a distribution mechanism for software modules. The DLT model can include smart contracting capabilities as a decision-making body to determine the authorization of authorized use and transmission from a transmission perspective. From the perspective of receiving, source node, and determination of the source, the authorization of the transmission can determine the authorization to receive and utilize the software module.

[0133] In some examples, the DLT model implemented by the DL 114 and the DSS 116 can use a value exchange mechanism that tracks the distribution and utilization of the software modules 108. From an operational perspective, the various services of the DLT model can be logically segmented. The DLT model used in association with the wireless ad hoc network 100 can be segmented with increased security features. An intermediate node with a main DL 114' and an intermediate DSS 116' can be used to manage software acceptance and use in a network that is open only to authorized nodes. These services of the DLT model can be analyzed to determine the effectiveness and utilization of the software modules. Added value can be derived through associated data analysis.

[0134] As compared to Figure 4 As explained above, in some examples, the source node 402a is configured to receive the software module from the neighboring node 402b. This may include the source node being configured to receive a response from the neighboring node 402b indicating that the neighboring node has the software module. The source node may then unicast a second request for the software module to the neighboring node, and receive the software module from the neighboring node in response to the second request.

[0135] In some examples, several nodes in the plurality of nodes 402, whether adjacent nodes 402b, 402c or further adjacent nodes 402d, 402e, may have a software module. A source node 402a may receive a response from a node indicating that the node has the software module. Thus, the source node may have an option for receiving the software module. In some of these examples, the node may have a corresponding cost and / or terms and conditions for providing the software module to the source node. The nodes in these examples may be considered "seller" nodes, and the source node may select one of these nodes that has the best "deal".

[0136] The source node 402a may unicast a second request to a selected seller node in the plurality of nodes 402, optionally with an agreement covering the cost and subject to any terms and conditions. The second request may travel the wireless ad hoc network 100 to the seller node, which may verify the transaction and send the software module back to the source node over the wireless ad hoc network. The source node may verify, scan, secure, and run the software module, and register the transaction as a completed transaction.

[0137] The source node 402a and the selected seller node in the plurality of nodes 402 can be synchronized in many different ways. In some examples, the source node can send a message to the selected seller node to confirm receipt of the software module, thereby completing the transaction. In response, the seller node can send an unlock code (optional) to the source node to enable permanent use of the software module. Regardless of the messages exchanged to perform the transaction, the path can have separate and stateless multiple requests and responses, unlike stateful financial transactions. Therefore, the transaction can obtain well-known authorizations to track the transaction. Input DL 410a, 410b to track transactions between the seller node with the software module and the source node requesting the software module.

[0138] In some examples, the requests and responses may be tracked by the nodes 402 in the wireless ad hoc network 400 using the DLs 410a, 410b, noting that the DL pipes are in place for each path from the source node 402a to a selected seller node in the plurality of nodes 402. However, in examples where a stateless dialogue for a transaction is less beneficial, the wireless ad hoc network may employ a transient stateful approach in the final transaction between the source node and the seller node.

[0139] According to example embodiments of the present disclosure, software modules 108, 208, 408a, 508a, MR 110, 110', 210, 412a, 412b, 510a, MSS 112, 112', 212, DL 114, 114', 410a, 410b and DSS 116, 116', 216 and nodes 402, 502 may be implemented or otherwise executed by various means. These means may include hardware, either alone or under the guidance of one or more computer programs from a computer-readable storage medium. In some examples, one or more devices may be configured to act as or otherwise implement or execute the software modules, MRs and MSSs and the nodes shown and described herein.

[0140] Fig.10 An apparatus 1000 according to some example embodiments of the present disclosure is shown. In general, an apparatus of an example embodiment of the present disclosure may include or be implemented in one or more fixed or portable electronic devices. Examples of suitable electronic devices include computers such as desktop computers, server computers, portable computers (e.g., laptop computers, tablet computers), mobile phones (e.g., cell phones, smart phones), wearable computers (e.g., smart watches), etc. The apparatus may include one or more of each of a number of components, such as, for example, a processing circuit 1002 (e.g., a processor unit) connected to a memory 1004 (e.g., a storage device).

[0141] Processing circuitry 1002 may consist of one or more processors alone, or in combination with one or more memories. Processing circuitry is typically any computer hardware capable of processing information such as data, computer programs, and / or other suitable electronic information. Processing circuitry consists of a collection of electronic circuits, some of which may be packaged as an integrated circuit or multiple interconnected integrated circuits (sometimes more commonly referred to as "chips"). Processing circuitry may be configured to execute a computer program, which may be stored on the processing circuitry, or otherwise stored in memory 1004 (of the same or another device).

[0142] Depending on the specific implementation, the processing circuit 1002 can be a number of processors, a multi-core processor, or some other type of processor. In addition, the processing circuit can be implemented using many heterogeneous processor systems, in which the main processor exists together with one or more auxiliary processors on a single chip. As another illustrative example, the processing circuit can be a symmetrical multi-processor system containing multiple processors of the same type. In another example, the processing circuit can be implemented as or otherwise include one or more ASICs, FPGAs, etc. Therefore, although the processing circuit may be able to execute a computer program to perform one or more functions, the processing circuits of various examples may be able to perform one or more functions without the help of a computer program. In either case, the processing circuit can be appropriately programmed to perform functions or operations according to example implementations of the present disclosure.

[0143] Memory 1004 is generally any computer hardware capable of storing information such as data, computer programs (e.g., computer readable program code 1006), and / or other suitable information on a temporary basis and / or on a permanent basis. Memory may include volatile memory and / or non-volatile memory, and may be fixed or removable. Examples of suitable memory include random access memory (RAM), read-only memory (ROM), hard drive, flash memory, thumb drive, removable computer disk, optical disk, tape, or some combination thereof. Optical disks may include compact disk-read-only memory (CD-ROM), compact disk-read / write (CD-R / W), DVD, etc. In various cases, memory may be referred to as computer-readable storage media. Computer-readable storage media are non-temporary devices capable of storing information, and are distinguished from computer-readable transmission media such as electronic transient signals capable of carrying information from one location to another. Computer-readable media as described herein may generally refer to computer-readable storage media or computer-readable transmission media.

[0144] In addition to the memory 1004, the processing circuit 1002 may also be connected to one or more interfaces for displaying, transmitting and / or receiving information. The interface may include a communication interface 1008 (e.g., a communication unit) and / or one or more user interfaces. The communication interface may be configured to transmit and / or receive information, such as to other devices, networks, etc. and / or to receive from other devices, networks, etc. The communication interface may be configured to transmit and / or receive information via a physical (wired) and / or wireless communication link. Examples of suitable communication interfaces include a network interface controller (NIC), a wireless NIC (WNIC), etc.

[0145] The user interface may include a display 1010 and / or one or more user input interfaces 1012 (e.g., input / output units). The display may be configured to present or otherwise display information to a user, suitable examples of which include a liquid crystal display (LCD), a light emitting diode display (LED), a plasma display panel (PDP), etc. The user input interface may be wired or wireless, and may be configured to receive information from a user into the device, such as for processing, storage, and / or display. Suitable examples of user input interfaces include a microphone, an image or video capture device, a keyboard or keypad, a joystick, a touch-sensitive surface (separate from or integrated into a touch screen), a biometric sensor, etc. The user interface may also include one or more interfaces for communicating with peripheral devices such as a printer, a scanner, etc.

[0146] As indicated above, program code instructions can be stored in a memory and executed by a processing circuit programmed thereby to implement the functions of the systems, subsystems, tools and their corresponding elements described herein. As will be appreciated, any suitable program code instructions can be loaded from a computer-readable storage medium onto a computer or other programmable device to produce a specific machine so that the specific machine becomes a device for implementing the functions specified herein. These program code instructions can also be stored in a computer-readable storage medium, which can guide a computer, a processing circuit or other programmable device to function in a specific manner, thereby generating a specific machine or a specific product. Instructions stored in a computer-readable storage medium can produce products, wherein the products become devices for implementing the functions described herein. The program code instructions can be retrieved from a computer-readable storage medium and loaded into a computer, a processing circuit or other programmable device to configure the computer, the processing circuit or other programmable device to perform operations to be performed on or by a computer, a processing circuit or other programmable device.

[0147] The retrieval, loading, and execution of program code instructions may be performed sequentially so as to retrieve, load, and execute one instruction at a time. In some exemplary embodiments, the retrieval, loading, and / or execution may be performed in parallel so as to retrieve, load, and / or execute multiple instructions together. The execution of program code instructions may produce a computer-implemented process such that the instructions executed by a computer, processing circuit, or other programmable device provide operations for implementing the functions described herein.

[0148] The instructions executed by the processing circuit or the storage of the instructions in the computer-readable storage medium support the combination of operations for performing the specified functions. In this manner, the device 1000 may include a processing circuit 1002 and a computer-readable storage medium or a memory 1004 coupled to the processing circuit, wherein the processing circuit is configured to execute a computer-readable program code 1006 stored in the memory. It will also be understood that one or more functions and combinations of functions may be implemented by a dedicated hardware-based computer system and / or a processing circuit that performs the specified functions or a combination of dedicated hardware and program code instructions.

[0149] Furthermore, the present disclosure includes embodiments according to the following clauses:

[0150] Item 1. A source node (402a, 1000) operable in a wireless ad hoc network (400) comprising a plurality of nodes (402), the source node comprising:

[0151] a memory (1004) configured to store computer readable program code (1006); and

[0152] A processing circuit (1002) configured to access the memory and execute the computer readable program code to cause the source node to at least:

[0153] executing (702) application software from which the task needs to be performed is identified;

[0154] determining (704) that the source node cannot perform the task; and

[0155] In response to the determining,

[0156] accessing (706) a respective local copy of a distributed ledger (410a) replicated, shared, and synchronized across a plurality of nodes, the distributed ledger and thereby the respective local copy comprising immutable entries specifying access rights to a plurality of software modules including software modules operable to perform the task;

[0157] searching (708) the immutable entries of the corresponding local copies for an immutable entry indicating that the source node is authorized to access the software module; and only if the source node is authorized,

[0158] searching (710) a local module repository (MR) (412a) of the source node for a software module that can be used to perform the task;

[0159] In response to the source node failing to locate the software module in the local MR (412a), broadcasting (712) a request for the software module to those of the plurality of nodes within the radio range of the source node that are thus neighboring nodes (402b, 402c), the neighboring node (402b) of the plurality of neighboring nodes, to search for the software module in the corresponding local MRs (412b) of the neighboring nodes, and when the neighboring node fails to locate the software module in the corresponding local MR (412b), rebroadcasting the request to those of the plurality of nodes within the radio range of the neighboring node that are thus further neighboring nodes (402d, 402e), and receiving the software module from further neighboring nodes of the plurality of further neighboring nodes; and further causing the source node to:

[0160] receiving (714) the software module from a neighboring node; and

[0161] The task is performed using (716) the software module.

[0162] Clause 2. The source node (402a, 1000) of Clause 1, wherein the processing circuit (1002) is configured to execute the computer-readable program code (1006) to further cause the source node to at least:

[0163] recording the request in an additional immutable entry in the respective local copy of the distributed ledger (410a); and

[0164] The additional immutable entry is broadcast to the neighboring nodes (402b, 402c) to initiate synchronization of the respective local copies of the distributed ledger with copies of the distributed ledger at other nodes of the plurality of nodes.

[0165] Clause 3. The source node (402a, 1000) of Clause 2, wherein the processing circuit (1002) is configured to execute the computer-readable program code (1006) to further cause the source node to at least:

[0166] receiving, in respective copies of the distributed ledger at the neighboring nodes, further additional immutable entries broadcasted from the neighboring nodes (402b, 402c) in response to the neighboring nodes recording the request broadcasted from the source node; and

[0167] The further additional immutable entries are added to the respective local copies of the distributed ledger (410a) to synchronize the respective local copies with the respective copies of the distributed ledger at the neighboring nodes.

[0168] Clause 4. The source node (402a, 1000) of any preceding clause, wherein the processing circuit (1002) is configured to execute the computer-readable program code (1006) to further cause the source node to at least:

[0169] recording receipt of the software module in an additional immutable entry in the respective local copy of the distributed ledger (410a); and

[0170] The additional immutable entry is broadcast to the neighboring nodes (402b, 402c) to initiate synchronization of the respective local copies of the distributed ledger with copies of the distributed ledger at other nodes of the plurality of nodes.

[0171] Clause 5. The source node (402a, 1000) of any preceding clause, wherein the processing circuit (1002) is configured to execute the computer-readable program code (1006) to further cause the source node to at least:

[0172] recording the use of the software module in an additional immutable entry in the respective local copy of the distributed ledger (410a); and

[0173] The additional immutable entry is broadcast to the neighboring nodes (402b, 402c) to initiate synchronization of the respective local copies of the distributed ledger with copies of the distributed ledger at other nodes of the plurality of nodes.

[0174] Article 6. A neighboring node (402b, 1000) operable in a wireless ad hoc network comprising a plurality of nodes, wherein those of the plurality of nodes that are within radio range of a source node (402a) are neighboring nodes (402b, 402c), the neighboring nodes comprising:

[0175] a memory (1004) configured to store computer readable program code (1006); and

[0176] A processing circuit (1002) configured to access the memory and execute the computer readable program code so that the neighboring node at least:

[0177] In response to the source node failing to locate the software module in a local module repository (MR) (412a), receiving (802) a request from the source node for a software module available for performing a task, the request being broadcast from the source node to the neighboring nodes, the neighboring nodes responding to the request:

[0178] accessing (804) a respective local copy of a distributed ledger (410b) replicated, shared and synchronized across the plurality of nodes, the distributed ledger and thereby the respective local copy comprising an immutable entry specifying access rights to a software module;

[0179] searching (806) the immutable entries of the corresponding local copies for an immutable entry indicating that the source node is authorized to access the software module; and only if the source node is authorized,

[0180] Searching (808) the software module in the corresponding local MR (412b) of the neighboring node;

[0181] in response to the neighboring node failing to locate the software module in the respective local MR (412b), rebroadcasting (810) the request to those of the plurality of nodes that are within radio range of the neighboring node that are further neighboring nodes (402d, 402e);

[0182] receiving (812) the software module from a further neighboring node of the plurality of further neighboring nodes; and

[0183] The software module is returned (814) to the source node which performs the task using the software module.

[0184] Clause 7. The neighboring node (402b, 1000) of Clause 6, wherein the distributed ledger and thereby the corresponding local copy (410b) further includes an immutable entry in which a previous request received by the neighboring node is recorded, and

[0185] Wherein the processing circuit (1002) is configured to execute the computer readable program code (1006) to further cause the neighboring node to search the immutable entry to verify that the request is a new request for the software module from the source node (402a).

[0186] Clause 8. The neighboring node (402b, 1000) of any one of Clauses 6 to 7, wherein the processing circuit (1002) is configured to execute the computer-readable program code (1006) to further cause the neighboring node to at least:

[0187] recording the request in an additional immutable entry in the respective local copy of the distributed ledger (410b); and

[0188] The additional immutable entry is broadcast to the source node (402a) and the further neighboring nodes (402d, 402e) to initiate synchronization of the respective local copies of the distributed ledger (410b) with copies of the distributed ledger at other nodes of the plurality of nodes.

[0189] Clause 9. The neighboring node (402b, 1000) of Clause 8, wherein the processing circuit (1002) is configured to execute the computer-readable program code (1006) to further cause the neighboring node to at least:

[0190] receiving, in a respective copy of the distributed ledger at the further neighboring node, a further additional immutable entry broadcasted from the further neighboring node (402d, 402e) in response to the further neighboring node recording the request rebroadcasted from the further neighboring node; and

[0191] The further additional immutable entry is added to the respective local copy of the distributed ledger (410b) to synchronize the respective local copy with the respective copy of the distributed ledger at the further neighboring node.

[0192] Clause 10. The neighboring node (402b, 1000) of any one of Clauses 6 to 9, wherein the processing circuit (1002) is configured to execute the computer-readable program code (1006) to further cause the neighboring node to at least:

[0193] recording receipt of the software module in an additional immutable entry in the corresponding local copy of the distributed ledger (410b); and

[0194] The additional immutable entry is broadcasted to the source node (402a) and the further neighboring nodes (402d, 402e) to initiate synchronization of the respective local copies of the distributed ledger with copies of the distributed ledger at other nodes of the plurality of nodes.

[0195] Clause 11. A source node (502a, 1000) operable in a wireless ad hoc network comprising a plurality of nodes, the source node comprising:

[0196] a memory (1004) configured to store computer readable program code (1006); and

[0197] A processing circuit (1002) configured to access the memory and execute the computer readable program code to cause the source node to at least:

[0198] executing (902) application software from which a need to perform a task is identified;

[0199] determining (904) that the source node cannot perform the task; and

[0200] In response to the determining,

[0201] accessing (906) a local copy of a module repository (MR) (510a) implemented in a distributed ledger that is replicated, shared, and synchronized across the plurality of nodes, the distributed ledger and thereby the local copy of the MR comprising immutable entries having software modules available to the plurality of nodes;

[0202] searching (908) the local copy of the MR for a software module that can be used to perform the task; and

[0203] The software module is used (910) to perform the task.

[0204] Clause 12. The source node (502a, 1000) of Clause 11, wherein causing the source node to search the local copy of the MR (510a) comprises causing the source node to search the local copy of the MR for the specifically identified software module.

[0205] Article 13. A source node (502a, 1000) according to any one of Articles 11 to 12, wherein causing the source node to search the local copy of the MR (510a) includes causing the source node to search the local copy of the MR for any software module that can be used to perform the task without specific identification of the software module.

[0206] Clause 14. The source node (502a, 1000) of any one of Clauses 11 to 13, wherein the distributed ledger and thereby the local copy of the MR (510a) further comprises immutable entries specifying access rights to a plurality of software modules including the software module, and

[0207] The processing circuit (1002) is configured to execute the computer-readable program code (1006) to further enable the source node to search the local copy of the MR for an immutable entry indicating that the source node is authorized to access the software module before using the software module, and the source node uses the software module only when the source node is authorized.

[0208] Clause 15. The source node (502a, 1000) of any one of Clauses 11 to 14, wherein the processing circuit (1002) is configured to execute the computer-readable program code (1006) to further cause the source node to at least:

[0209] recording the use of the software module in an additional immutable entry in the local copy of the MR (510a); and

[0210] The additional immutable entry is broadcast to those of the plurality of nodes that are within radio range of the source node to initiate synchronization of the local copy of the MR (510a) with the copy of the MR at other of the plurality of nodes.

[0211] Article 16. A method (700) for obtaining software by a source node (402a) in a wireless ad hoc network including a plurality of nodes, the method comprising the source node:

[0212] executing (702) application software from which a need to perform a task is identified;

[0213] determining (704) that the source node cannot perform the task; and

[0214] In response to the determining,

[0215] accessing (706) respective local copies of a distributed ledger replicated, shared, and synchronized across the plurality of nodes, the distributed ledger and thereby the respective local copies comprising immutable entries specifying access rights to a plurality of software modules including software modules operable to perform the task;

[0216] searching (708) the immutable entries of the corresponding local copies for an immutable entry indicating that the source node is authorized to access the software module; and only if the source node is authorized,

[0217] searching (710) a local module repository (MR) (412a) of the source node for a software module that can be used to perform the task;

[0218] In response to the source node failing to locate the software module in the local MR, broadcasting (712) a request for the software module to those of the plurality of nodes within a radio range of the source node that are thus neighboring nodes (402b, 402c), a neighboring node (402b) of the neighboring nodes to search for the software module in the corresponding local MRs of the neighboring nodes, and when the neighboring node fails to locate the software module in the corresponding local MR, rebroadcasting the request to those of the plurality of nodes within a radio range of the neighboring node that are thus further neighboring nodes (402d, 402e), and receiving the software module from one of the plurality of further neighboring nodes; and the source node further,

[0219] receiving (714) the software module from the neighboring node; and

[0220] The task is performed using (716) the software module.

[0221] Clause 17. The method (700) of Clause 16, further comprising the source node (402a):

[0222] recording the request in an additional immutable entry in the respective local copy of the distributed ledger (410a); and

[0223] The additional immutable entries are broadcasted to the neighboring nodes (402b, 402c) to initiate synchronization of the respective local copies of the distributed ledger with a copy of the distributed ledger at other nodes of the plurality of nodes.

[0224] Clause 18. The method (700) of Clause 17, further comprising the source node (402a):

[0225] receiving, in respective copies of the distributed ledger at the neighboring nodes, further additional immutable entries broadcast from the neighboring nodes (402b, 402c) in response to the neighboring nodes recording the request broadcast from the source node; and

[0226] The further additional immutable entries are added to the respective local copies of the distributed ledger (410a) to synchronize the respective local copies with the respective copies of the distributed ledger at the neighboring nodes.

[0227] Clause 19. The method (700) of any one of Clauses 16 to 18, further comprising the source node (402a):

[0228] recording receipt of the software module in an additional immutable entry in the respective local copy of the distributed ledger (410a); and

[0229] The additional immutable entries are broadcasted to the neighboring nodes (402b, 402c) to initiate synchronization of the respective local copies of the distributed ledger with a copy of the distributed ledger at other nodes of the plurality of nodes.

[0230] Clause 20. The method (700) of any one of Clauses 16 to 19, further comprising the source node (402a):

[0231] recording the use of the software module in an additional immutable entry in the respective local copy of the distributed ledger (410a); and

[0232] The additional immutable entries are broadcasted to the neighboring nodes (402b, 402c) to initiate synchronization of the respective local copies of the distributed ledger with a copy of the distributed ledger at other nodes of the plurality of nodes.

[0233] Item 21. A method (800) for acquiring software by a source node (402a) in a wireless ad hoc network comprising a plurality of nodes, wherein those of the plurality of nodes that are within radio range of the source node are neighboring nodes (402b, 402c), the method comprising a neighboring node (402b) of the plurality of neighboring nodes:

[0234] In response to the source node failing to locate the software module in a local module repository (MR) (412a), receiving (802) a request from the source node for a software module available for performing a task, the request being broadcast from the source node to the neighboring nodes, the neighboring nodes responding to the request:

[0235] accessing (804) a respective local copy of a distributed ledger replicated, shared, and synchronized across the plurality of nodes, the distributed ledger and thereby the respective local copy comprising an immutable entry specifying access rights to a software module;

[0236] searching (806) the immutable entries of the corresponding local copies for an immutable entry indicating that the source node is authorized to access the software module; and only if the source node is authorized,

[0237] searching (808) the software module in the corresponding local MR (412b) of the neighboring node;

[0238] in response to the neighboring node failing to locate the software module in the respective local MR, rebroadcasting (810) the request to those of the plurality of nodes that are within radio range of the neighboring node that are further neighboring nodes (402d, 402e);

[0239] receiving (812) the software module from a further neighboring node of the plurality of further neighboring nodes; and

[0240] The software module is returned (814) to the source node which performs the task using the software module.

[0241] Clause 22. The method (800) of clause 21, wherein the distributed ledger and thereby the corresponding local copy also includes an immutable entry recording a previous request received by the neighboring node (402b), and

[0242] The method further includes the neighboring node searching the immutable entry to verify that the request is a new request for the software module from the source node (402a).

[0243] Clause 23. The method (800) according to any one of Clauses 21 to 22, further comprising the neighboring node (402b):

[0244] recording the request in an additional immutable entry in the respective local copy of the distributed ledger (410b); and

[0245] The additional immutable entry is broadcasted to the source node (402a) and the further neighboring nodes (402d, 402e) to initiate synchronization of the respective local copies of the distributed ledger with copies of the distributed ledger at other nodes of the plurality of nodes.

[0246] Clause 24. The method (800) according to Clause 23, wherein the method further comprises the neighboring node (402b):

[0247] receiving, in a respective copy of the distributed ledger at the further neighboring node, a further additional immutable entry broadcasted from the further neighboring node (402d, 402e) in response to the further neighboring node recording the request rebroadcasted from the further neighboring node; and

[0248] The further additional immutable entry is added to the respective local copy of the distributed ledger (410b) to synchronize the respective local copy with the respective copy of the distributed ledger at the further neighboring node.

[0249] Clause 25. The method (800) according to any one of Clauses 21 to 24, further comprising the neighboring node (402b):

[0250] recording receipt of the software module in an additional immutable entry in the respective local copy of the distributed ledger; and

[0251] The additional immutable entry is broadcasted to the source node (402a) and the further neighboring nodes (402d, 402e) to initiate synchronization of the respective local copies of the distributed ledger with copies of the distributed ledger at other nodes of the plurality of nodes.

[0252] Article 26. A method (900) for obtaining software by a source node (502a, 1000) in a wireless ad hoc network including a plurality of nodes, the method comprising the source node:

[0253] executing (902) application software from which a need to perform a task is identified;

[0254] determining (904) that the source node is unable to perform the task; and in response to the determination,

[0255] accessing (906) a local copy of a module repository (MR) (510a) implemented in a distributed ledger that is replicated, shared, and synchronized across the plurality of nodes, the distributed ledger and thereby the local copy of the MR comprising immutable entries having software modules available to the plurality of nodes;

[0256] searching (908) the local copy of the MR for a software module that can be used to perform the task; and

[0257] The task is performed using (910) the software module.

[0258] Clause 27. The method (900) of Clause 26, wherein searching the local copy of the MR (510a) comprises searching the local copy of the MR for the specifically identified software module.

[0259] Clause 28. The method (900) of any one of Clauses 26 to 27, wherein searching the local copy of the MR (510a) comprises searching the local copy of the MR for any software module that can be used to perform the task without specific identification of the software module.

[0260] Clause 29. The method (900) of any one of Clauses 26 to 28, wherein the distributed ledger and thereby the local copy of the MR (510a) further comprises immutable entries specifying access rights to a plurality of software modules including the software module, and

[0261] The method further comprises the step of the source node (502a, 1000) searching the local copy of the MR for an immutable entry indicating that the source node is authorized to access the software module before using the software module, and the source node uses the software module only when the source node is authorized.

[0262] Clause 30. The method (900) according to any one of Clauses 26 to 29, further comprising the source node (502a, 1000):

[0263] recording the use of the software module in an additional immutable entry in the local copy of the MR (510a); and

[0264] The additional immutable entry is broadcast to those of the plurality of nodes that are within radio range of the source node to initiate synchronization of the local copy of the MR with the copy of the MR at other nodes of the plurality of nodes.

[0265] Those skilled in the art associated with the present disclosure will appreciate that many modifications and other embodiments of the present disclosure elaborated herein will have the benefit of the enlightenment presented in the foregoing description and associated drawings. Therefore, it should be understood that the present disclosure is not limited to the specific embodiments disclosed, and modifications and other embodiments are intended to be included within the scope of the appended claims. In addition, although the foregoing description and associated drawings describe example embodiments in the context of certain example combinations of elements and / or functions, it should be understood that different elements and / or functions can be provided by alternative embodiments without departing from the scope of the appended claims. For example, in this regard, as can be elaborated in some of the appended claims, combinations of elements and / or functions different from those explicitly described above are also envisioned. Although specific terms are used herein, these terms are used only in a general and descriptive sense, and not for the purpose of limitation.

Claims

1. A source node (502a, 1000) operable in a wireless ad hoc network comprising a plurality of nodes, the source node include: a memory (1004) configured to store computer readable program code (1006); Sensor (106, 506a); Software module (108); a module repository MR (510a) implemented in a distributed ledger replicated, shared and synchronized across the plurality of nodes, the distributed ledger and thus the local copy of the MR comprising immutable entries with software modules available to the plurality of nodes, the distributed ledger being implemented as a blockchain; a module search service MSS (112) configured to provide a list of available software modules based on a search criterion and said nodes on which said software modules are available; and A processing circuit (1002) configured to access the memory and execute the computer readable program code to cause the source node to at least: executing (902) application software from which a need to perform a task is identified; determining (904) that the source node cannot perform the task; and In response to the determining, Accessing (906) a local copy of the module repository MR (510a); searching (908) the local copy of the MR for a software module that can be used to perform the task only when the source node is authorized; and in response to the source node failing to locate the software module in the local copy of the MR (510a), broadcasting a request for the software module to nodes among the plurality of nodes within radio range of the source node; Using (910) the software module to perform the task; recording the use of the software module in an additional immutable entry in the local copy of the MR (510a); as well as The additional immutable entry is broadcast to nodes of the plurality of nodes within radio range of the source node to initiate synchronization of the local copy of the MR (510a) with copies of the MR at other nodes of the plurality of nodes.

2. The source node (502a, 1000) of claim 1, wherein causing the source node to search the local copy of the MR (510a) comprises causing the source node to search the local copy of the MR for the specifically identified software module.

3. A source node (502a, 1000) according to any preceding claim, wherein causing the source node to search the local copy of the MR (510a) includes causing the source node to search the local copy of the MR for any software module that can be used to perform the task without specific identification of the software module.

4. The source node (502a, 1000) according to any one of claims 1-2, wherein the distributed ledger and thereby the local copy of the MR (510a) further comprises immutable entries specifying access rights to the plurality of software modules including the software module, and The processing circuit (1002) is configured to execute the computer-readable program code (1006) to further cause the source node to search the local copy of the MR for an immutable entry indicating that the source node is authorized to access the software module before using the software module, and cause the source node to use the software module only when the source node is authorized.

5. A method (900) for acquiring software by a source node (502a, 1000) in a wireless ad hoc network comprising a plurality of nodes, The source node (502a, 1000) include: a memory configured to store computer readable program code; sensor; Software modules; a module repository MR (510a) implemented in a distributed ledger replicated, shared and synchronized across the plurality of nodes, the distributed ledger and thus the local copy of the MR comprising immutable entries with software modules available to the plurality of nodes, the distributed ledger being implemented as a blockchain; a module search service MSS (112) configured to provide a list of available software modules based on a search criterion and said nodes on which said software modules are available; The method comprises the source node: executing (902) application software from which a need to perform a task is identified; determining (904) that the source node cannot perform the task; as well as In response to the determining, Accessing (906) a local copy of the module repository MR (510a); searching (908) the local copy of the MR for a software module that can be used to perform the task only when the source node is authorized; and in response to the source node failing to locate the software module in the local copy of the MR (510a), broadcasting a request for the software module to nodes among the plurality of nodes within radio range of the source node; Using (910) the software module to perform the task; recording the use of the software module in an additional immutable entry in the local copy of the MR (510a); as well as The additional immutable entry is broadcast to nodes of the plurality of nodes within radio range of the source node to initiate synchronization of the local copy of the MR with copies of the MR at other nodes of the plurality of nodes.

6. The method (900) of claim 5, wherein searching the local copy of the MR (510a) comprises searching the local copy of the MR for the specifically identified software module.

7. The method (900) according to any one of claims 5-6, wherein searching the local copy of the MR (510a) includes searching the local copy of the MR for any software module that can be used to perform the task without specific identification of the software module.

8. The method (900) according to any one of claims 5-6, wherein the distributed ledger and thereby the local copy of the MR (510a) further comprises immutable entries specifying access rights to the plurality of software modules including the software module, and The method further comprises the step of the source node (502a, 1000) searching the local copy of the MR for an immutable entry indicating that the source node is authorized to access the software module before using the software module, and the source node uses the software module only when the source node is authorized.

9. A computer program product comprising at least one non-transitory computer-readable storage medium having computer-executable program code instructions stored therein, the program code instructions being configured to perform the method according to any one of claims 5-8.

Images