Software distribution in wireless AD HOC networks for AD-HOC data processing at source nodes

Abstract

This application relates to software distribution in wireless AD HOC networks for AD-HOC data processing on source nodes, a method of acquiring software by a source node in a wireless ad hoc network is disclosed. The method includes the source node executing an application software, identifying from the application software a need to process a particular data modality, and determining that the source node is unable to process the particular data modality. In response to the determination, the source node searches a local module repository (MR) of the source node for a software module usable to process the particular data modality, 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 neighbor node of a plurality of nodes within radio range of the source node. The source node receives the software module from the neighbor node and processes the particular data modality using the software module.

Description

[0001] This application is a divisional application of Chinese patent application 2020106676600, filed on July 13, 2020, entitled "Software distribution in a wireless ADHOC network for AD-HOC data processing on a source node". Technical Field

[0002] This disclosure generally relates to software distribution, and more particularly to software distribution in wireless ad hoc networks for ad-hoc (wireless ad hoc) data processing on source nodes (such as autonomous machines). Background Technology

[0003] Many modern machines are designed to operate with increased autonomy compared to other machines that require safe operation by trained operators. 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 spacecraft. Many of these autonomous machines are equipped with sensors and use software modules to process the data generated or provided by those sensors.

[0004] Autonomous machines are typically pre-loaded so that once a task is executed, software modules can be used to process data based on the task's purpose. Autonomous machines can communicate directly or indirectly with other autonomous machines or one or more hubs (such as ground stations) to report data acquired by their sensors. Autonomous machines are becoming increasingly intelligent, evolving into learning systems capable of determining their inability to process specific data modalities generated or provided by one or more of their sensors. However, distributing software modules to enable autonomous machines to process specific data modalities once a task is executed becomes more complex and often requires human intervention.

[0005] Therefore, it is 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

[0006] The exemplary embodiments of this disclosure are directed to software distribution, particularly to software distribution in wireless ad hoc networks for ad-hoc data processing at source nodes (such as autonomous machines). The exemplary embodiments provide a method for acquiring the intelligence, transactionality, distributed nature, and federation of software in a wireless ad hoc network (e.g., a network of autonomous machines). This method may include automatically determining the need to process data modalities, finding software modules available for processing data modalities through communication between nodes in the wireless ad hoc, acquiring the software modules, and using them to process the data modalities without human intervention.

[0007] The example implementation can enable a wireless ad hoc network that includes autonomous machines deployed on a task, which self-describe the task, find software modules that can be used to achieve the task objectives, and perform the task based on achieving those objectives.

[0008] Therefore, this disclosure includes, but is not limited to, the following exemplary implementation methods.

[0009] Some example implementations provide a method for a source node in a wireless ad hoc network comprising multiple nodes to acquire software, the method comprising: the source node executing application software to identify a need for processing a specific data modality from the application software; determining that the source node cannot process the specific data modality; and in response to the determination, searching in the source node's local module repository (MR) for a software module that can be used to process the specific data modality; in response to the source node failing to locate the software module in its local MR, broadcasting a request for the software module to those nodes within the source node's radio range, those nodes being neighbor nodes, the request causing one of the neighbor nodes to search for the software module in the neighbor node's corresponding local MR, and when the neighbor node fails to locate the software module in its corresponding local MR, rebroadcasting the request to those nodes within the neighbor node's radio range, those nodes being further neighbor nodes, and receiving the software module from one of the further neighbor nodes; and the source node further receiving the software module from the neighbor node; and using the software module to process the specific data modality.

[0010] In some example implementations of the method of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, the source node has a set of sensors, and the method further includes one of the sensors that generates or provides a specific data modality to application software, from which the application software identifies the need to process the specific data modality.

[0011] In some example implementations of the methods of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, it is determined that the method is made by the application software.

[0012] In some example implementations of the methods of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, the determination is made based on a request received by the source node from a remote terminal.

[0013] In some example implementations of the method of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, searching the local MR includes searching for a specially identified software module in the local MR, and wherein broadcasting a request includes broadcasting a request to specifically identify the software module.

[0014] In some example implementations of the method of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, searching the local MR includes searching in the local MR for any software module that can be used to process a particular data modality without requiring a specific identifier of the software module, and wherein broadcasting a request includes broadcasting a request describing the particular data modality without requiring a specific identifier of the software module.

[0015] In some example implementations of the method of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, the source node receiving the software module from the neighbor node includes the source node receiving a response from the neighbor node indicating that the neighbor node has the software module; unicasting a second request for the software module to the neighbor node; and receiving the software module from the neighbor node in response to the second request.

[0016] In some example implementations of the methods of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, using software modules includes performing operating system-level containerization on the source node, including creating and launching isolated containers on the source node where the software modules are to be used, and creating isolated containers includes installing the software modules in the isolated containers.

[0017] Some example implementations provide a method for a source node in a wireless ad hoc network, the wireless ad hoc network including a plurality of nodes, wherein those nodes within the radio range of the source node are neighbor nodes, the method comprising one of the neighbor nodes receiving a request from the source node for a software module that can be used to process a specific data modality, in response to the source node failing to locate the software module in its local model repository (MR), the request being broadcast from the source node to the neighbor node, the neighbor node responding to the request by: searching for the software module in its respective local MR; in response to the neighbor node failing to locate the software module in its respective local MR, rebroadcasting the request to those nodes within the radio range of the neighbor node, those nodes thus becoming further neighbor nodes; receiving the software module from one of the further neighbor nodes; and returning the software module to the source node that uses the software module to process the specific data modality.

[0018] In some example implementations of the method of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, the request includes a unique identifier, and the method further includes a neighboring node using the unique identifier and a record of previous requests received by the neighboring node to verify that the request is a new request for a specific software module from the source node.

[0019] In some example implementations of the method of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, searching for the corresponding MR includes searching for a specially identified software module in the corresponding MR, and wherein rebroadcasting the request includes rebroadcasting the request that specifically identifies the software module.

[0020] In some example implementations of the method of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, searching for a corresponding MR includes searching in the corresponding MR for any software module that can be used to process a particular data modality without requiring a specific identifier of the software module, and wherein rebroadcasting the request includes rebroadcasting a request that describes the particular data modality and does not include a specific identifier of the software module.

[0021] In some example implementations of the method of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, receiving a software module from a further neighbor node includes the neighbor node receiving a response from the further neighbor node indicating that the further neighbor node has the software module; unicasting a second request for the software module to the further neighbor node; and receiving the software module from the further neighbor node in response to the second request.

[0022] In some example implementations of the method of any of the foregoing example implementations, or in any combination of any of the foregoing example implementations, the neighbor node returning the software module to the source node includes: the neighbor node sending a response to the source node indicating that the neighbor node has the software module; receiving a second request for the software module unicast from the source node; and in response to the second request, returning the software module to the source node.

[0023] Some example implementations provide a source node operable in a wireless ad hoc network comprising multiple nodes, the source node including: a memory configured to store computer-readable program code; and processing circuitry configured to access the memory and execute the computer-readable program code to cause the source node to perform at least the methods of any of the foregoing example implementations or any combination of any of the foregoing example implementations.

[0024] Some example implementations provide a neighbor node operable in a wireless ad hoc network comprising multiple nodes, wherein those nodes within radio range of the source node are neighbor nodes. The neighbor node includes: a memory configured to store computer-readable program code; and processing circuitry configured to access the memory and execute the computer-readable program code to cause the neighbor node to perform at least the methods of any of the foregoing example implementations or any combination of any of the foregoing example implementations.

[0025] These and other features, aspects, and advantages of this disclosure will become apparent from the following detailed description and the accompanying drawings, which are briefly described below. This disclosure includes any combination of two, three, four, or more features or elements set forth herein, whether such features or elements are explicitly combined or otherwise described in the particular exemplary embodiments described herein. It is intended that this disclosure be understood holistically such that any separable feature or element of this disclosure should be considered composable in any aspect and exemplary embodiments of this disclosure unless the context of this disclosure explicitly indicates otherwise.

[0026] Therefore, it will be appreciated that the content of this invention is provided merely for the purpose of outlining some exemplary embodiments in order to provide a basic understanding of some aspects of this disclosure. It will also be appreciated that the above-described exemplary embodiments are merely examples and should not be construed as limiting the scope or spirit of this disclosure in any way. Other exemplary embodiments, aspects, and advantages will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which illustrate by way of example the principles of some of the described exemplary embodiments. Attached Figure Description

[0027] Therefore, exemplary embodiments of this disclosure have been described in general terms, and reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and in which:

[0028] Figure 1 A wireless ad hoc network is shown, and exemplary embodiments of this disclosure can be used in such a wireless ad hoc network;

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

[0030] Figure 3A , Figure 3B , Figure 3C and Figure 3D The process by which an unmanned vehicle (source node) can acquire software modules according to some example embodiments of this disclosure is illustrated;

[0031] Figure 4 A wireless ad hoc network according to an example embodiment of the present disclosure is shown;

[0032] Figure 5 and Figure 6 This is a flowchart illustrating the various steps in a method for acquiring software by a source node in a wireless ad hoc network comprising multiple nodes, according to an example embodiment; and

[0033] Figure 7 An apparatus according to some example implementations is shown. Detailed Implementation

[0034] Some embodiments of this disclosure will now be described more fully below with reference to the accompanying drawings, which illustrate some, but not all, of these embodiments. In fact, various embodiments of this disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these exemplary embodiments are provided so that this disclosure will be thorough and complete and will fully convey the scope of this disclosure to those skilled in the art. For example, unless otherwise indicated, references to first, second, etc., should not be construed as implying a particular order. Similarly, some things may be described as above others (unless otherwise stated), while they may instead be below them, and vice versa; and similarly, things described as being to the left of others may instead be to the right of them, and vice versa. Throughout the drawings, similar reference numerals indicate similar elements.

[0035] The exemplary embodiments of this disclosure generally relate to software distribution, and more particularly to software distribution in wireless ad hoc networks for ad-hoc data processing on source nodes. Some exemplary embodiments provide a method for a source node to acquire software in a wireless ad hoc network comprising multiple nodes. As described herein, a "node" is a physical network node, i.e., an active electronic device capable of creating, transmitting, or receiving information on a communication channel. An example of a suitable node is an autonomous machine, which is a machine configured to perform tasks independently of or with minimal human intervention. 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), unmanned spacecraft, etc.

[0036] Figure 1A wireless ad hoc network 100 is illustrated, and the example embodiments of this disclosure may be useful for this wireless ad hoc network 100. As shown, the wireless ad hoc network includes nodes shown as various unmanned vehicles 102 (including multiple UAVs 102a, UGVs 102b, USVs 102c, UUVs 102d, and unmanned spacecraft 102e that can be deployed on a mission). A mission may involve one or more unmanned vehicles, during which the unmanned vehicles may communicate with each other. In this regard, the unmanned vehicles can communicate with each other through corresponding communication channels and with ground station 104 (another node). Although a network is shown as unmanned vehicles, it should be understood that the wireless ad hoc network may include one or more autonomous robots or other autonomous machines other than or in place of unmanned vehicles. And, as described below, and even more generally, the wireless ad hoc network may simply include multiple nodes.

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

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

[0039] Software module 108 is a computer program configured to acquire one or more sources of input data (raw or derived) and zero or more configuration control sources that determine how the data should be manipulated and produce one or more output data modalities. The software module communicates with its host computer or other software modules or workflows using one or more well-known or predefined interfaces. The software module may follow known communication protocols via plug-in endpoints (e.g., via an API (Application Programming Interface)). For example, the software module may use the Hypertext Transfer Protocol Secure (HTTPS) protocol with a published Representation State Transfer (REST) ​​API.

[0040] One or more software modules 108 enable the creation and execution of workflows. Workflows include software modules organized according to an execution hierarchy (e.g., a DAG (Directed Acyclic Graph)) acquiring data, or acting as a feedback control system to improve the quality of output data within the workflow. A workflow is an interconnection of software modules such that the output of one software module is used as input or control for another software module in a DAG configuration or deterministic feedback mechanism that improves the output of the workflow in some way. Workflows can also function as software modules. Software modules or workflows can execute as linear programs or can be parallelized based on design, implementation, and capabilities.

[0041] Software module 108 (and workflow) may have similar or varying capabilities. Software modules may have permissions to read and (where appropriate) write data. Software modules can read raw data and can generate further data in the form of exported data. The software may or may not have permissions to manipulate raw or exported data. In this respect, software modules can read exported data and generate even further data in the form of further exported data. Exported data may be smaller or larger than the (source) data. Exported data (if smaller) may be a small fraction of the source data.

[0042] Depending on available communication capabilities, connectivity, and authorization, data in partial or complete form (raw or derived) 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.

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

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

[0045] MR 110 is a repository containing one or more software modules 108 (installed copies of the software modules). Well-known examples of commercial MRs include Docker Hub and Amazon Container Registry. Similar to well-known MRs, MRs store software modules on storage devices and manage CRUD (create, read, update, and delete) operations, licensing, version control, and more on the software modules.

[0046] MSS112 is a service running on a computer on unmanned vehicle 102 (or ground station 104). MSS provides a list of available software modules 108 and the nodes on which these software modules are available, based on search criteria. Similar to well-known search engines, MSS learns over time about the capabilities of available software modules, search requests from unique nodes, the requirements of individual nodes, new content being published, and old content being deleted.

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

[0048] According to an example implementation of this disclosure, an MSS 112 operating on an unmanned vehicle 102 can 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 respective MRs. To avoid circular requests, each request can carry a unique identifier, such as a Universally Unique Identifier (UUID), which may also hold or carry a timestamp (e.g., Coordinated Universal Time) to request unmanned vehicle identifiers, security tokens, access control parameters, and other identifiers and permissions, such as those found in standard web-based security tokens.

[0049] When MSS112 receives a request from the requesting MSS, it can verify that it has not recently received and processed the same request. To verify the request, the MSS can compare the timestamped tokens in 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 recently received and processed the same request, the MSS can either simply ignore the request, or it can additionally return an error to the requesting MSS to notify it that the request is a duplicate request or a potential circular request.

[0050] To illustrate an exemplary implementation of this disclosure, consider a first (first unmanned vehicle) of the unmanned vehicles 102 that has an AI engine that detects new patterns and modalities in data collected by one or more of its sensors 106. The AI ​​engine identifies the need to process the new data modalities, but determines that the first unmanned vehicle lacks a software module 108 available for processing the new data modalities.

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

[0052] The second MSS 112 (second MSS) in the unmanned vehicle 102 receives the request and can verify it to see if the first MSS is authorized to make the request and receive software module 108. If an error occurs, the second MSS can return "Permission denied" or choose not to respond for security reasons. Similarly, the second MSS can check if it has already received and processed the request containing the first token; if so, the second MSS can return and display a "Duplicate Request" error message.

[0053] If the check indicates that the request is unique, the second MSS 112 can search its local MR 110 for software module 108 (one or more) that provides a solution to the problem described in the request. If the second MSS fails to locate such a software module, it can rebroadcast the request to other MSSs of the unmanned vehicle 102. Alternatively, if the second MSS does locate such a software module in its local MR, it can send a response to the first MSS indicating 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 receive the software module from the second unmanned vehicle's MR request and as a response. The first unmanned vehicle can verify the module (e.g., for integrity and security) and start the software module and use it to 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, it can retry or abandon the request, for example, based on a machine learning inference engine decision or a heuristic algorithm programmed into the software application.

[0054] Figure 2 A wireless ad hoc network 200 according to an exemplary embodiment of the present disclosure is shown. The wireless ad hoc network 200 includes nine unmanned vehicles (UV1-UV9) that may correspond to unmanned vehicle 102, and a ground station GS1 that may correspond to ground station 104. Each of the one or more unmanned vehicles (UV1-UV9) may include a sensor 206, a software module 208, an MR 210, and an MSS 212, which may correspond to a corresponding one of sensor 106, software module 108, MR 110, and MSS 112. Ground station GS1 may also include at least a corresponding MR and MSS.

[0055] In this regard, consider an example where UV1 is performing a task, its sensors are capturing data, and it has an AI engine to process the data. The AI ​​engine identifies the need to process new data modalities, and it needs to search for one or more software modules M that can solve the problem of processing new data modalities. Other unmanned vehicles, namely UV4 and UV7, have the same software module M as ground station GS1.

[0056] In the unmanned vehicles, UV2, UV3, and UV4 are within the radio range of UV1 at time T1. Unmanned vehicle UV2 is further within the radio range of UV6 and UV7, while unmanned vehicle UV3 is further within the radio range of UV5, UV6, and UV7. Moreover, unmanned vehicle UV7 is further within the radio range of UV8 and UV9, as well as ground station GS1.

[0057] Figures 3A to 3D Based on some exemplary embodiments of this disclosure, refer to Figure 2 The wireless ad hoc network 200 illustrates the process by which an unmanned vehicle UV1 (source node) can acquire software module M (sensors 206, software module 208, MR 210, and MSS 212 are not shown separately). When UV1's AI engine identifies a need to process a new data modality, UV1 requests the software module M available to process the new data modality. As shown in Figure 3a, when UV1's MSS 212 fails to locate software module M in its local MR 210, the MSS broadcasts the request to UV1's neighbors (i.e., UV2, UV3, and UV4 within UV1's radio range). Unmanned vehicles UV2, UV3, and UV4 receive the request.

[0058] Unmanned vehicle UV4 has software module M and sends a response to the request; however, due to a connectivity issue, it is now outside the 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. Specifically, UV3 will rebroadcast the request to its further neighbors, namely UV5, UV6, and UV7 within UV3's further radio range. And unmanned vehicle UV2 will rebroadcast the request to its further neighbors, namely UV6 and UV7 within UV2's further radio range.

[0059] like Figure 3B As shown, 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 will ignore the request rebroadcast by UV2 or send a duplicate request error to UV2. Therefore, unmanned vehicle UV2 sends a "No" response to UV1.

[0060] like Figure 3C As shown, in response to the "Yes" response from UV7, the unmanned vehicle UV3 sends a "Get Module" request for software module M to UV7. In response, UV3 receives software module M from UV7, verifies software module M and stores it in its local MR 210, and updates its MSS212 to reflect that it now has software module M. Unmanned vehicle UV3 also sends a "Yes" response to UV1.

[0061] like Figure 3DAs shown, in response to a "Yes" response, the unmanned vehicle UV1 sends a "Get Module" message for software module M to UV3. UV1 receives software module M from UV3, verifies it, stores it in its local MR210, and updates its MSS212 to reflect that it now has software module M. UV1 initiates software module M according to a set of known rules, initializes it, and connects to it. UV1 can also test software module M, and if UV1 encounters a fault, it logs it and terminates software module M. Otherwise, UV1 is ready to use software module M. Furthermore, in some examples, UV1 returns and logs can be further received for aggregation and analysis.

[0062] As described above, although primarily within the context of unmanned vehicles, the exemplary embodiments of this disclosure are more generally applicable to wireless ad hoc networks comprising multiple 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, smartphones), wearable computers (e.g., smartwatches), etc. These computers may be stand-alone or may be embedded within larger mechanical or electrical systems.

[0063] Figure 4 A wireless ad hoc network 400 comprising a plurality of nodes 402 is illustrated according to an example embodiment of the present disclosure. The plurality of nodes includes a source node 402a configured to execute application software 408a, from which a need to process a specific data modality is identified. In some examples, the source node has a set of sensors 406a, one of which is configured to generate or provide a specific data modality to the application software 408a, from which a need to process the specific data modality is identified.

[0064] Source node 402a is configured to determine that the source node cannot handle a specific data modality. In some examples, this determination is made by application software 408a. In other examples, the determination is made based on a request received by the source node from a remote terminal, such as a ground station.

[0065] In response to this determination, source node 402a is configured to search its local module repository MR 410a for software modules that can be used to process a specific data mode. The source node is configured to broadcast a request for the software module to those nodes within its radio range, namely neighbor nodes 402b and 402c, in response to the source node's failure to locate the software module in its local MR. Although not shown individually for all nodes 402, in some examples, the source node and other nodes of the wireless ad hoc network 400 may also include local MSS, sensors, and / or software modules.

[0066] In some examples, source node 402a is configured to search for a specially identified software module in the local MR 410a and broadcast a request that specifically identifies 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 process a specific data modality without requiring a specific identifier for the software module. In these other examples, the source node is configured to broadcast a request that describes a specific data modality and does not include a specific identifier for the software module.

[0067] In response to a request broadcast by source node 402a, one of the neighboring nodes, neighbor node 402b, is configured to search for the software module in the corresponding local MR 410b of the neighboring node. The neighboring node is configured to rebroadcast the request to those nodes within the radio range of the neighboring node if it fails to locate the software module in the corresponding local MR, thereby becoming further neighboring nodes 402d, 402e. Furthermore, the neighboring node is configured to receive the software module from a further neighboring node 402d among the further neighboring nodes.

[0068] Source node 402a is configured to receive a software module from neighbor node 402b. In some examples, this includes source node 402a being configured to receive a response from neighbor node 402b indicating that the neighbor node has the software module. In these examples, the source node is configured to unicast a second request for the software module to the neighbor node and receive the software module from the neighbor node in response to the second request.

[0069] Upon receiving the software module, source node 402a is configured to use the software module to process a specific data modality. In some examples, the source node is configured to perform operating system-level containerization. This includes configuring the source node to create and launch isolated containers on the source node in which the software module will be used. Isolated containers are operating system-level (OS-level) virtualization. This is different from hardware virtualization, which uses a hypervisor (rather than a container engine) to create virtual machines to emulate the node, and generally requires less overhead. From the perspective of software applications running in isolated containers, the isolated containers may appear as real nodes, but these applications only have visibility to the resources allocated to their source node, assuming those resources are fully available. The creation of isolated containers can then include configuring the source node to install the software module within the isolated container.

[0070] From another perspective, in some examples, neighbor node 402b is configured to receive requests from source node 402a for software modules that can be used to process a specific data modality. This is in response to the source node failing to locate the software module in its local model repository MR410a, and the request is broadcast from the source node to neighbor nodes 402b and 402c. In some examples, the request includes a unique identifier, and the neighbor node is further configured to use the unique identifier and a record of previous requests received by the neighbor node to verify that the request is a new request for a specific software module from source node 402a.

[0071] In response to the request, neighbor node 402b is configured to search for the software module in the corresponding local MR 410b of the neighbor node. Neighbor node 402b is configured to rebroadcast the request to those nodes within the neighbor node's radio range, which are then further neighbor nodes 402d and 402e, in response to the neighbor node's failure to locate the software module in the corresponding local MR.

[0072] In some examples, neighbor node 402b is configured to search for a specially identified software module in the corresponding MR 410b and rebroadcast a request that identifies the software module. In other examples, the neighbor node is configured to search for any software module in the corresponding MR that can be used to process a specific data modality without requiring a special identifier for the software module. In these examples, the neighbor node is configured to rebroadcast a request that describes a specific data modality and does not include a special identifier for the software module.

[0073] Neighbor node 402b is configured to receive a software module from a further neighbor node 402d, which is a further neighbor node. In some examples, this may include the neighbor node being configured to receive a response from the further neighbor node indicating that the further neighbor node has the software module. In these examples, the neighbor node is configured to unicast a second request for the software module to the further neighbor node and receive the software module from the further neighbor node in response to the second request.

[0074] Upon receiving the software module, neighbor node 402b is configured to return the software module to source node 402a, which uses the software module to process a specific data modality. In some examples, this may include the neighbor node being configured to send a response to the source node indicating that the neighbor node has the software module. The neighbor node is then configured to receive a second request for the software module unicast from the source node and, in response to the second request, return the software module to the source node.

[0075] Figure 5 This is a flowchart illustrating the steps of a method 500 for a source node 402a in a wireless ad hoc network 400, comprising a plurality of nodes 402, according to an example embodiment. As shown in blocks 502 and 504, the method includes: the source node executing application software 408a, identifying a need to process a specific data modality from the application software 408a; and determining that the source node cannot process the specific data modality. In response to this determination, the method includes the source node searching in its local module repository MR 410a for software modules that can be used to process the specific data modality, as shown in block 506. 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 nodes within its radio range, namely neighbor nodes 402b, 402c, as shown in block 508.

[0076] In response to the request, one of the neighboring nodes, neighbor node 402b, searches for the software module in the corresponding local MR 410b 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 within its radio range, namely further neighboring nodes 402d and 402e. Furthermore, the neighboring node receives the software module from one of the further neighboring nodes, further neighboring node 402d. The method then further includes the source node receiving the software module from that neighboring node and using the software module to process a specific data mode, as shown in boxes 510 and 512.

[0077] Figure 6This is a flowchart illustrating the steps of a method 600 for obtaining software from a source node 402a in a wireless ad hoc network 400, according to other example embodiments. The wireless ad hoc network 400 includes a plurality of nodes 402, wherein those nodes within the radio range of the source node are neighbor nodes 402b, 402c. As shown in block 602, the method includes one of the neighbor nodes, 402b, receiving from the source node a request for a software module that can be used to process a specific data modality. The request is received in response to the source node's failure to locate the software module in its local model repository MR 410a, and the request is broadcast from the source node to the neighbor nodes.

[0078] In response to the request, neighbor node 402b searches for the software module in its corresponding local MR 410b, as shown in box 604. If the neighbor node fails to locate the software module in its corresponding local MR, it rebroadcasts the request to those nodes within its radio range, which are then further neighbor nodes 402d and 402e, as shown in box 606. Furthermore, the neighbor node receives the software module from one of these further neighbor nodes, 402d, and returns it to the source node 402a that uses the software module to process a specific data mode, as shown in boxes 608 and 610.

[0079] According to exemplary embodiments of this disclosure, software modules 108, 208, 408a, MRs 110, 210, 410a, 410b, and MSSs 112, 212, as well as node 402, can be implemented or otherwise executed by various means / apparatus. These means may include hardware, either alone or in the guidance of one or more computer programs from a computer-readable storage medium. In some examples, one or more apparatuses may be configured to act as or otherwise implement or execute the software modules, MRs and MSSs, and the nodes shown and described herein.

[0080] Figure 7 An apparatus 700 according to some exemplary embodiments of the present disclosure is shown. Generally, the apparatus of exemplary embodiments of the present disclosure may be contained in, included in, or embodied 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, smartphones), wearable computers (e.g., smartwatches), etc. The apparatus may include one or more of each of a plurality of components (e.g., processing circuitry 702 (e.g., a processor unit) connected to memory 704 (e.g., a storage device)).

[0081] The processing circuitry 702 may consist of one or more individual processors or one or more processors combined with one or more memories. Processing circuitry is generally 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 integrated circuits or multiple interconnected integrated circuits (sometimes more generally referred to as "chips"). Processing circuitry may be configured to execute computer programs, which may be stored on the processing circuit board or otherwise stored in memory 704 (of the same or another device).

[0082] According to a particular implementation, the processing circuit 702 may be multiple processors, a multi-core processor, or some other type of processor. Furthermore, the processing circuit may be implemented using multiple heterogeneous processor systems, where the main processor and one or more auxiliary processors reside on a single chip. As another illustrative example, the processing circuit may be a symmetric multiprocessor system comprising multiple processors of the same type. In yet another example, the processing circuit may be implemented as or otherwise include one or more ASICs, FPGAs, etc. Therefore, although the processing circuit is capable of executing a computer program to perform one or more functions, the various examples of processing circuits are capable of performing one or more functions without the assistance of a computer program. In any case, the processing circuit may be appropriately programmed to perform functions or operations according to exemplary embodiments of this disclosure.

[0083] Memory 704 is typically any computer hardware capable of temporarily and / or permanently storing information (e.g., data, computer programs (e.g., computer-readable program code 706), and / or other suitable information). Memory may include volatile 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 disk drive, flash memory, thumb drive, removable computer disk, optical disk, magnetic tape, or some combination thereof. Optical disk may include optical disk-read-only memory (CD-ROM), optical disk-read / write (CD-R / W), DVD, etc. In various contexts, memory may be referred to as a computer-readable storage medium. A computer-readable storage medium is a non-transitory device capable of storing information and can be distinguished from a computer-readable transmission medium such as an electronic transient signal capable of carrying information from one location to another. The computer-readable medium described herein may generally refer to a computer-readable storage medium or a computer-readable transmission medium.

[0084] In addition to memory 704, processing circuitry 702 may also be connected to one or more interfaces for displaying, transmitting, and / or receiving information. Interfaces may include communication interface 708 (e.g., a communication unit) and / or one or more user interfaces. Communication interfaces may be configured to transmit and / or receive information, for example, to and / or from one or more other devices, one or more networks, etc. Communication interfaces may be configured to transmit and / or receive information via physical (wired) and / or wireless communication links. Examples of suitable communication interfaces include network interface controllers (NICs), wireless NICs (WNICs), etc.

[0085] The user interface may include a display 710 and / or one or more user input interfaces 712 (e.g., input / output units). The display may be configured to present or otherwise display information to a user; suitable examples include liquid crystal displays (LCDs), light-emitting diode displays (LEDs), plasma display panels (PDPs), etc. The user input interface may be wired or wireless and may be configured to receive information from a user into the device, for example, for processing, storage, and / or display. Suitable examples of the user input interface include microphones, image or video capture devices, keyboards or keypads, joysticks, touch-sensitive surfaces (separate from or integrated into a touchscreen), biometric sensors, etc. The user interface may further include one or more interfaces for communicating with peripheral devices such as printers, scanners, etc.

[0086] As described above, program code instructions can be stored in memory and executed by processing circuitry programmed thereon to implement the functions of the systems, subsystems, tools, and their respective elements described herein. It will be understood that any suitable program code instructions can be loaded from a computer-readable storage medium onto a computer or other programmable device to produce a particular machine, such that particular machine becomes a means for implementing the functions specified herein. These program code instructions can also be stored in a computer-readable storage medium that can instruct a computer, processing circuitry, or other programmable device to function in a particular manner, thereby producing a particular machine or article of manufacture. Instructions stored in a computer-readable storage medium can produce an article of manufacture, wherein the article of manufacture becomes a means for implementing the functions described herein. Program code instructions can be retrieved from a computer-readable storage medium and loaded onto a computer, processing circuitry, or other programmable device to configure the computer, processing circuitry, or other programmable device to perform operations to be performed on or by the computer, processing circuitry, or other programmable device.

[0087] The retrieval, loading, and execution of program code instructions can be performed sequentially, such that one instruction is retrieved, loaded, and executed at a time. In some example implementations, retrieval, loading, and / or execution can be performed in parallel, such that multiple instructions are retrieved, loaded, and / or executed together. The execution of program code instructions can produce computer-implemented processes, such that the instructions, executed by a computer, processing circuitry, or other programmable device, provide operations for implementing the functions described herein.

[0088] By executing instructions through processing circuitry or storing instructions in a computer-readable storage medium, a combination of operations for performing a specified function can be supported. In this way, apparatus 700 may include processing circuitry 702 and a computer-readable storage medium or memory 704 coupled to the processing circuitry, wherein the processing circuitry is configured to execute computer-readable program code 706 stored in the memory. It should also be understood that one or more functions, and combinations thereof, can be implemented by a dedicated hardware-based computer system and / or processing circuitry, or a combination of dedicated hardware and program code instructions, that performs a specific function.

[0089] Furthermore, this disclosure includes embodiments as described in the following terms:

[0090] Clause 1. A source node 402a, 700 operable in a wireless ad hoc network 400 comprising a plurality of nodes 402, said source node comprising:

[0091] Memory 704, configured to store computer-readable program code 706; and

[0092] Processing circuitry 702 is configured to access the memory and execute the computer-readable program code to cause the source node to at least:

[0093] Execute application software 408a (502) to identify the need to process a specific data modality from the application software.

[0094] Determining that the source node described in 504 cannot process the specific data modality; and in response to the determination,

[0095] Search the local module repository of the source node, i.e., the local MR 410a, for 506 software modules that can be used to process the specific data modality;

[0096] In response to the source node's failure to locate the software module in the local MR, a request for the software module is broadcast (508) to those nodes within the source node's radio range, which are then neighbor nodes 402b and 402c. The request causes one of the neighbor nodes, 402b, to search for the software module in the corresponding local MR 410b of the neighbor node. When the neighbor node fails to locate the software module in its corresponding local MR, the request is rebroadcast to those nodes within the neighbor node's radio range, which are then further neighbor nodes 402d and 402e, and the source node receives the software module from one of these further neighbor nodes, 402d. The source node further causes:

[0097] Receive the software module 510 from the neighboring node; and

[0098] The software module described in 512 is used to process the specific data modality.

[0099] Clause 2. The source node 402a, 700 as described in Clause 1, wherein the source node has a set of sensors 406a, one of which is configured to generate or provide the particular data modality to the application software 408a, from which the application software identifies the requirement to process the particular data modality.

[0100] Clause 3. The source node 402a, 700 as described in any of the preceding clauses, wherein the determination is made by the application software 408a.

[0101] Clause 4. The source node 402a, 700 as described in any of the preceding clauses, wherein the determination is made based on a request received by the source node from a remote terminal.

[0102] Clause 5. The source node 402a, 700 as described in any of the preceding clauses, wherein the source node is caused to search for the specially identified software module in the local MR 410a, and

[0103] The source node broadcasts a request specifically identifying the software module.

[0104] Clause 6. The source node 402a, 700 as described in any of the preceding clauses, wherein the source node searches in the local MR 410a for any software module that can be used to process the particular data modality, without requiring a specific identifier for the software module, and

[0105] The request, which causes the source node to broadcast a description of the specific data modality and does not include a specific identifier of the software module, is described.

[0106] Clause 7. The source node 402a, 700 according to any of the preceding clauses, wherein causing the source node to receive the software module from the neighbor node 402b includes causing the source node to at least:

[0107] Receive a response from the neighboring node indicating that the neighboring node has the software module;

[0108] A second request for the software module is unicast to the neighboring nodes; and

[0109] In response to the second request, the software module is received from one of the neighboring nodes.

[0110] Clause 8. The source node 402a, 700 according to any of the preceding clauses, wherein making the source node use the software module includes making the source node at least:

[0111] Performing operating system-level containerization includes creating and launching isolated containers on the source node where the software module is to be used, and having the source node create the isolated containers includes having the source node install the software module in the isolated containers.

[0112] Clause 9. A neighbor node 402b, 700 operable in a wireless ad hoc network 400 comprising a plurality of nodes 402, wherein those nodes within radio range of a source node 402a are neighbor nodes 402b, 402c, said neighbor nodes comprising:

[0113] Memory 704, configured to store computer-readable program code 706; and

[0114] Processing circuitry 702 is configured to access the memory and execute the computer-readable program code to cause the neighboring node to at least:

[0115] In response to the source node's failure to locate a software module in its local model repository MR 410a that can be used to process a specific data modality, a request for the software module is received from the source node, the request being broadcast from the source node to the neighboring nodes, and in response to the request, the neighboring nodes at least:

[0116] Search for the software module described in 604 in the corresponding local MR 410b of the neighboring node;

[0117] In response to the neighbor node's failure to locate the software module in the corresponding local MR, the request is rebroadcast 606 to those nodes within the neighbor node's radio range, which are then further neighbor nodes 402d, 402e.

[0118] Receive the software module 608 from one of the further neighbor nodes 402d; and

[0119] The software module is returned to 610 to the source node that uses the software module to process the specific data modality.

[0120] Clause 10. Neighbor nodes 402b, 700 as described in Clause 9, wherein the request includes a unique identifier, and the processing circuitry 702 is configured to execute the computer-readable program code 706 to further enable the neighbor node to use the unique identifier and a record of previous requests received by the neighbor node to verify that the request is a new request for the specific software module from the source node 402a.

[0121] Clause 11. Neighbor nodes 402b and 700 as described in any of Clauses 9-10, wherein the neighbor nodes are caused to search for the specially identified software module in the corresponding MR 410b, and

[0122] This involves causing the neighboring nodes to rebroadcast the request specifically identifying the software module.

[0123] Clause 12. Neighbor nodes 402b and 700 as described in any one of Clauses 9-11, wherein the neighbor node is enabled to search in the corresponding MR 410b for any software module available for processing the specific data modality, without requiring a specific identifier for the software module, and

[0124] The request that causes the neighboring node to rebroadcast a description of the specific data modality and does not include a special identifier of the software module.

[0125] Clause 13. The neighbor node 402b, 700 according to any one of Clauses 9-12, wherein enabling the neighbor node to receive the software module from the further neighbor node 402d includes enabling the neighbor node to at least:

[0126] Receive a response from the further neighboring node indicating that the further neighboring node has the software module;

[0127] The software module is unicast to the further neighboring nodes a second request; and

[0128] In response to the second request, the software module is received from the further neighboring node.

[0129] Clause 14. The neighbor node 402b, 700 according to any one of Clauses 9-13, wherein causing the neighbor node to return the software module to the source node 402a includes causing the neighbor node to at least:

[0130] Send a response to the source node indicating that the neighboring node has the software module;

[0131] Receive a second request for the software module unicast from the source node; and

[0132] In response to the second request, the software module is returned to the source node.

[0133] Clause 15. A method 500 for a source node 402a in a wireless ad hoc network 400 comprising a plurality of nodes 402 to acquire software, the method comprising the source node:

[0134] Execute application software 408a (502) to identify the need to process a specific data modality from the application software.

[0135] Determining that the source node described in 504 cannot process the specific data modality; and in response to the determination,

[0136] Search the local module repository of the source node, i.e., the local MR 410a, for 506 software modules that can be used to process the specific data modality;

[0137] In response to the source node's failure to locate the software module in the local MR, a request for the software module is broadcast (508) to those nodes within the source node's radio range, which are then neighbor nodes 402b and 402c. The request causes one of the neighbor nodes, 402b, to search for the software module in the neighbor node's corresponding local MR 410b. When the neighbor node fails to locate the software module in the corresponding local MR, the request is rebroadcast to those nodes within the neighbor node's radio range, which are then further neighbor nodes 402d and 402e, and the source node receives the software module from one of these further neighbor nodes, 402d. The source node further:

[0138] Receive the software module 510 from the neighbor node; and

[0139] The software module described in 512 is used to process the specific data modality.

[0140] Clause 16. The method according to Clause 15, wherein the source node 402a has a set of sensors 406a, and the method further includes one of the sensors:

[0141] Generate or provide the specific data modality to the application software 408a, and identify the requirement to process the specific data modality from the application software.

[0142] Clause 17. The method according to any one of Clauses 15-16, wherein the determination is made by the application software 408a.

[0143] Clause 18. The method according to Clauses 15-17, wherein the determination is made based on a request received by the source node 402a from a remote terminal.

[0144] Clause 19. The method according to Clauses 15-18, wherein searching the local MR 410a includes searching within the local MR for the specifically identified software module, and

[0145] The broadcast request includes the broadcast of a request that specifically identifies the software module.

[0146] Clause 20. The method according to Clauses 15-19, wherein searching the local MR 410a includes searching within the local MR for any software module that can be used to process the specific data modality, without requiring specific identification of the software module, and

[0147] The broadcast request includes a request that describes the specific data modality but does not include a specific identifier of the software module.

[0148] Clause 21. The method according to Clauses 15-20, wherein the source node 402a receives the software module from the neighbor node 402b, including the source node:

[0149] Receive a response from the neighboring node indicating that the neighboring node has the software module;

[0150] A second request for the software module is unicast to the neighboring nodes; and

[0151] In response to the second request, the software module is received from the neighboring node.

[0152] Clause 22. The method according to Clauses 15-21, wherein the use of the software module includes the source node 402a:

[0153] Performing operating system-level containerization includes creating and launching isolated containers on the source node where the software module is to be used, and creating the isolated containers includes installing the software module in the isolated containers.

[0154] Clause 23. A method 600 for acquiring software by a source node 402a in a wireless ad hoc network comprising multiple nodes, wherein those nodes within the radio range of the source node are neighboring nodes 402b, 402c, the method including one of the neighboring nodes, neighboring node 402b:

[0155] In response to the source node's failure to locate a software module in its local model repository MR 410a that can be used to process a specific data modality, a request for the software module is received from the source node. This request is broadcast from the source node to the neighboring nodes, which respond to the request as follows:

[0156] Search for the software module described in 604 in the corresponding local MR 410b of the neighboring node;

[0157] In response to the neighbor node's failure to locate the software module in the corresponding local MR, the request is rebroadcast 606 to those nodes within the neighbor node's radio range, which are then further neighbor nodes 402d, 402e.

[0158] Receive the software module 608 from one of the further neighbor nodes 402d; and

[0159] The software module is returned to 610 to the source node that uses the software module to process the specific data modality.

[0160] Clause 24. The method according to Clause 23, wherein the request includes a unique identifier, and the method further includes the neighbor node 402b:

[0161] Using the unique identifier and a record of previous requests received by the neighboring node, verify that the request is a new request for the specific software module from the source node 402a.

[0162] Clause 25. The method according to Clauses 23-24, wherein searching the corresponding MR 410b comprises: searching in the corresponding MR for the software module specifically identified, and wherein rebroadcasting the request comprises rebroadcasting the request specifically identifying the software module.

[0163] Clause 26. The method according to Clauses 23-25, wherein searching the corresponding MR 410b includes searching within the corresponding MR for any software module that can be used to process the specific data modality, without requiring specific identification of the software module, and

[0164] The rebroadcast of the request includes rebroadcasting the request that describes the specific data modality but does not include a specific identifier of the software module.

[0165] Clause 27. The method according to Clauses 23-26, wherein the neighbor node 402b receives the software module from the further neighbor node 402d, including the neighbor node:

[0166] Receive a response from the further neighboring node indicating that the further neighboring node has the software module;

[0167] The software module is unicast to the further neighboring nodes a second request; and

[0168] In response to the second request, the software module is received from the further neighboring node.

[0169] Clause 28. The method according to Clauses 23-27, wherein the neighbor node 402b returns the software module to the source node 402a, including the neighbor node:

[0170] Send a response to the source node indicating that the neighboring node has the software module;

[0171] Receive a second request for the software module unicast from the source node; and

[0172] In response to the second request, the software module is returned to the source node.

[0173] Many modifications and other embodiments of this disclosure will occur to those skilled in the art upon which this disclosure pertains, based on the teachings presented in the foregoing specification and accompanying drawings. Therefore, it should be understood that this disclosure is not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Furthermore, although exemplary embodiments have been described in the foregoing specification and accompanying drawings in the context of certain example combinations of elements and / or functions, it should be understood that different combinations of elements and / or functions may be provided by alternative embodiments without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and / or functions compared to those explicitly described above, as may be set forth in some of the appended claims, are also contemplated. Although specific terminology is used herein, it is used only in a general and descriptive sense and not for limiting purposes.

Claims

1. A neighbor node (402b, 700) operable in a wireless ad hoc network (400) comprising multiple nodes (402), wherein those nodes within radio range of a source node (402a) are neighbor nodes (402b, 402c), said neighbor node comprising: A memory (704) configured to store computer-readable program code (706); and Processing circuitry (702) is configured to access the memory and execute the computer-readable program code to cause the neighboring node to at least: In response to the source node's failure to locate a software module in the local model repository (MR) (410a) that can be used to process a specific data modality, a request for the software module is received from the source node (602), the request being broadcast from the source node to the neighboring nodes, and in response to the request, the neighboring nodes at least: Search (604) for the software module in the corresponding local MR (410b) of the neighboring node; In response to the neighbor node's failure to locate the software module in the corresponding local MR, the request is rebroadcast (606) to those nodes within the neighbor node's radio range, which are then further neighbor nodes (402d, 402e). Receive (608) the software module from one of the further neighbor nodes (402d); and The software module is returned (610) to the source node that used the software module to process the specific data modality.

2. The neighbor node (402b, 700) according to claim 1, wherein the request includes a unique identifier, and the processing circuit (702) is configured to execute the computer-readable program code (706) to further enable the neighbor node to use the unique identifier and a record of previous requests received by the neighbor node to verify that the request is a new request for the specific software module from the source node (402a).

3. The neighbor node (402b, 700) according to any one of claims 1-2, wherein the neighbor node is made to search for the specially identified software module in the corresponding MR (410b), and This involves causing the neighboring nodes to rebroadcast the request specifically identifying the software module.

4. The neighbor node (402b, 700) according to any one of claims 1-3, wherein the neighbor node searches in the corresponding MR (410b) for any software module that can be used to process the particular data modality without requiring a specific identifier for the software module, and The request that causes the neighboring node to rebroadcast a description of the specific data modality and does not include a special identifier of the software module.

5. The neighbor node (402b, 700) according to any one of claims 1-4, wherein causing the neighbor node to receive the software module from the further neighbor node (402d) includes causing the neighbor node to at least: Receive a response from the further neighboring node indicating that the further neighboring node has the software module; The software module is unicast to the further neighboring nodes a second request; and In response to the second request, the software module is received from the further neighboring node.

6. The neighbor node (402b, 700) according to any one of claims 1-5, wherein causing the neighbor node to return the software module to the source node (402a) comprises causing the neighbor node to at least: Send a response to the source node indicating that the neighboring node has the software module; Receive a second request for the software module unicast from the source node; and In response to the second request, the software module is returned to the source node.

7. A method (600) for a source node (402a) to acquire software in a wireless ad hoc network comprising multiple nodes, wherein those nodes within the radio range of the source node are neighboring nodes (402b, 402c), the method including one of the neighboring nodes (402b): In response to the source node's failure to locate a software module in its local model repository (MR) (410a) that can be used to process a specific data modality, a request for the software module is received (602) from the source node, the request being broadcast from the source node to the neighboring node, the neighboring node responding to the request: Search (604) for the software module in the corresponding local MR (410b) of the neighboring node; In response to the neighbor node's failure to locate the software module in the corresponding local MR, the request is rebroadcast (606) to those nodes within the neighbor node's radio range, which are then further neighbor nodes (402d, 402e). Receive (608) the software module from one of the further neighboring nodes (402d); and The software module is returned (610) to the source node that used the software module to process the specific data modality.

8. The method of claim 7, wherein the request includes a unique identifier, and the method further includes the neighbor node (402b): Using the unique identifier and a record of previous requests received by the neighboring node, verify that the request is a new request for the specific software module from the source node (402a).

9. The method of claim 7 or 8, wherein searching for the corresponding MR (410b) comprises: The software module specifically identified is searched in the corresponding MR, and the rebroadcast of the request includes rebroadcasting the request specifically identifying the software module.

10. The method according to any one of claims 7-9, wherein searching the corresponding MR (410b) comprises searching within the corresponding MR for any software module that can be used to process the particular data modality, without requiring specific identification of the software module, and The rebroadcast of the request includes rebroadcasting the request that describes the specific data modality but does not include a specific identifier of the software module.

11. The method according to any one of claims 7-10, wherein the neighbor node (402b) receives the software module from the further neighbor node (402d) including the neighbor node: Receive a response from the further neighboring node indicating that the further neighboring node has the software module; The software module is unicast to the further neighboring nodes a second request; and In response to the second request, the software module is received from the further neighboring node.

12. The method according to any one of claims 7-11, wherein the neighbor node (402b) returning the software module to the source node (402a) includes the neighbor node: Send a response to the source node indicating that the neighboring node has the software module; Receive a second request for the software module unicast from the source node; and In response to the second request, the software module is returned to the source node.

Images