Patent Description:
The present disclosure relates to computer networks. More particularly, this disclosure relates to a system and method for establishing and maintaining a mesh network.

A computing platform or digital platform refers to the environment in which a piece of software is executed. A computing platform may be the hardware or the operating system (OS), even a web browser and associated application programming interfaces, or other underlying software, as long as the program code is executed with it. Computing platforms have different abstraction levels, including a computer architecture, an OS, or runtime libraries. A computing platform is the stage on which computer programs can run.

Middleware is computer software that provides services to software applications beyond those available from the operating system. It can be described as "software glue". Middleware makes it easier for software developers to implement communication and input/output. The term middleware commonly refers to software that enables communication and management of data in distributed applications. As one definition, middleware is "those services found above the transport (e.g., over TCP/IP) layer set of services but below the application environment" (e.g., below application-level APIs). In this more specific sense middleware can be described as the dash ("-") in client-server, or the -to- in peer-to-peer. Middleware includes web servers, application servers, content management systems, and similar tools that support application development and delivery. <CIT> proposes a wireless network device. <CIT> proposes a communication device arranged to delay a procedure for joining a network until it detects activity on the network. <NPL>, defines the mesh link establishment (MLE) protocol for establishing and configuring secure radio links in IEEE <NUM>. <NUM> radio mesh networks.

Particular embodiments are defined by the subject-matter of the dependent claims.

The present disclosure relates to systems and methods for establishing and maintaining a mesh network amongst a plurality of nodes. The system includes one or more computing platforms that each initiates execution of a software application on each of the plurality of nodes in a non-deterministic order. Upon each node coming online (the software application completing the initiation process), the respective node broadcasts multicast identification messages to other nodes on the mesh network at a transient state rate. Each multicast identification message includes a unique identifier for the corresponding node (e.g., a network address and an open port number) and data characterizing a token register of the corresponding node.

Additionally, in response to receipt of a multicast identification message, each node examines the corresponding token register to determine if a communication link has been established with the node that broadcast the respective multicast identification message, which node is referred to as a broadcasting node. If a communication link has not been established with the broadcasting node, each node that received the multicast identification message (which can be referred to as receiving nodes) establishes a communication link with the broadcasting node based on the unique identifier of the broadcasting node (e.g., the network address and open port). Additionally, in response to a subsequent multicast identification message from the broadcasting node, each receiving node adds the broadcasting node to the token register, along with an indication that a communication link has been established between the receiving node and the broadcasting node. Further, in response to each multicast identification message, each receiving node adds an indication of other nodes (if any) identified in the multicast identification message for which a communication link has not been established to the corresponding token register. Accordingly, the token register in each receiving node includes an indication of nodes identified in a multicast identification message, but where no (direct) communication link is established. This process continues until there is a communication link between each (online) node in the mesh network, such that the mesh network is a fully connected mesh network.

Additionally, after a fully connected mesh network is established, each of the node on the mesh network reduces a rate of broadcasting the multicast identification messages from the transient state rate to a steady state rate to reduce network traffic. However, if at some point in the future a given node in the mesh network detects a failed communication link between the given node and a particular node, then the given node removes the particular node from the token register and changes the rate of the broadcast messages from the steady state rate to the transient state rate. By implementing the systems and methods described herein, a serverless mesh network without a single point of failure can be established and maintained. Furthermore, as noted, nodes on the mesh network can be initiated in a non-deterministic manner (e.g., an unpredictable order).

<FIG> illustrates an example of a system <NUM> for establishing and maintaining a peer-to-peer (e.g., serverless) fully connected mesh network of N number of nodes <NUM>, where N is an integer greater than or equal to two. As used herein, the term "fully connected mesh network" indicates that each node <NUM> eventually has a direct connection to every other node <NUM>.

The N number of nodes <NUM> can be representative of software services (e.g., an application and middleware) that execute on a computing platform <NUM>. Although <FIG> illustrates one computing platform, it is understood that there could be multiple computing platforms. As one example, the system <NUM> could be implemented on an aircraft, wherein each of the N number of nodes <NUM> represent different software services for controlling a different portion of the aircraft.

Each of the nodes <NUM> can include a middleware application to facilitate communications between nodes <NUM>. The middleware can provide an isolated runtime environment for a software application executing thereon. In some examples, each of the N number of nodes <NUM> can communicate with a standard communications protocol such as a communication protocol within the Transmission Control Protocol Internet Protocol (TCIP/IP) stack. More specifically, in some examples, the nodes <NUM> can communicate via the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP).

As used herein, the phrase "comes online" indicates that a corresponding node <NUM> has completed execution of a startup process and is ready to communicate with other nodes on the mesh network. Similarly, the phrase "goes offline" indicates that the corresponding node cannot communicate with other nodes on the mesh network. Upon an initial startup of the computing platform <NUM>, each of the N number of nodes <NUM> are initiated. Moreover, at least two of the N number nodes <NUM> come online (e.g., complete a startup process) in a nondeterministic order. Stated differently, at least two of the nodes complete an initial startup sequence in an unpredictable order. As an example, on a first startup of the computing platform <NUM>, node <NUM> may complete its startup process after node <NUM> such that node <NUM> is online prior to node <NUM>. Further, on a second startup of the computing platform, node <NUM> may complete its startup process before node <NUM>, such that node <NUM> is online prior to node <NUM>. The sequence of starting each of the N number of node <NUM> can be based, for example, on factors (e.g., network latency, operating system priorities and/or environmental factors) that may be outside of the control of the computing platform <NUM>.

Each node <NUM> stores a token register <NUM> that tracks nodes <NUM> on the mesh network. More particularly, the token register <NUM> of each node <NUM> stores data that identifies information characterizing the node <NUM> associated with the token register <NUM>. Additionally, the token register <NUM> of each node <NUM> stores data for nodes <NUM> on the mesh network that have established a communication link with the node <NUM> associated with the token register <NUM>. Further, the token register <NUM> of each node <NUM> stores data for nodes <NUM> on the mesh network that have not established a communication link with the node <NUM> associated with the token register <NUM> but have been identified in a multicast identification message from at least one other node <NUM>. Stated differently, for a given node <NUM>, the token register <NUM> for the given node identifies (i) the given node <NUM> (itself) (ii) each other node <NUM> that the given node <NUM> has established communication link with and (iii) each node <NUM> for which a communication link has not been established, but has been identified in a multicast identification message from another node <NUM>.

From the time the computing platform <NUM> is initialized, and until the mesh network is a fully connected mesh network, each of the N number of nodes <NUM> operates in a transient state. In the transient state, each of the N number of nodes <NUM>, upon completing the corresponding startup procedure, broadcasts a multicast identification message to each active node in the mesh network at a transient state rate. Each of the (broadcasted) multicast identification messages includes a unique identifier of node <NUM> that broadcast the multicast identification message. The unique identifier can be a network address (IP address) and data characterizing an open port on the node <NUM> that broadcast the multicast identification message. Each node <NUM> is configured such that a one-way communication link can be established with the given node through the open port identified in the broadcasted multicast identification messages.

As a given example (hereinafter, "the given example"), it is presumed that node <NUM> comes online (e.g., completes the startup process) first, node <NUM> comes online second and node <NUM> comes online third. In the given example, upon completing the startup process, node <NUM> broadcasts the multicast identification messages at the transient state rate. Initially, since node <NUM> is the first node <NUM> of the N number of nodes <NUM> to come online, the multicast identification messages are not received by node <NUM> or node <NUM>.

Continuing in the given example, upon node <NUM> coming online (e.g., completes the startup process), node <NUM> receives the next multicast identification message broadcast by node <NUM>. In response to receiving the next multicast identification message, node <NUM> establishes (opens) a communication link from node <NUM> to node <NUM>. The communication link could be a TCP connection, a UDP connection or a connection using a different protocol. Additionally, in response to receipt of a subsequent multicast identification message broadcast by node <NUM>, node <NUM> updates the token register of node <NUM> to add an indication that a communication link has been established with node <NUM>.

Further, continuing with the given example, node <NUM> also broadcasts the multicast identification messages at the transient state rate. Since node <NUM> is not yet online (e.g., has not completed the startup process) node <NUM> does not receive the multicast identification message from node <NUM>. However, since at this point in the given example, node <NUM> is online, node <NUM> receives the multicast identification message. The multicast identification message from node <NUM> includes the unique identifier of node <NUM> and data characterizing the token register <NUM> of node <NUM>. The unique identifier includes a network address (e.g., IP address) and an open port number for a communication link to node <NUM>. More generally, the unique identifier sent by a given node <NUM> in a multicast identification message includes information for establishing a communication link with the given node. In response to receipt of the multicast identification message, node <NUM> opens a communication link with node <NUM>. Additionally, in a subsequent multicast identification message, node <NUM> provides data characterizing the token register <NUM> of node <NUM> to node <NUM> as well as the unique identifier of node <NUM> (e.g., the IP address and open port number). In response to receipt of the data characterizing the token register <NUM> of node <NUM>, node <NUM> updates the token register <NUM> of node <NUM>. More particularly, node <NUM> adds an indication to the token register <NUM> that a communication link has been established with node <NUM>.

Continuing with the given example, at a subsequent time, node <NUM> comes online. Upon coming online, node <NUM> broadcasts a multicast identification message that includes the unique identifier (e.g., IP address and open port number) of node <NUM>. In the given example, it is presumed that node <NUM> receives the first multicast identification message from node <NUM>, but that node <NUM> does not receive the multicast identification message. The multicast identification message may not be received by every online node <NUM> on the mesh network due to communication collisions and/or lost packets on the mesh network. Thus, in response to the multicast identification message, node <NUM> establishes a communication link with node <NUM> and provides the data characterizing the token register <NUM> of node <NUM> to node <NUM> in a subsequent multicast identification message.

In response to receipt of the data characterizing the token register <NUM> of node <NUM>, node <NUM> updates the token register <NUM> of node <NUM>. In particular, node <NUM> adds an indication to the token register <NUM> that a communication link has been established with node <NUM> and another indication for node <NUM> indicating that node <NUM> is on the mesh network, but that a communication link has not been established with node <NUM>. That is, at this point of the given example, the token register of node <NUM> has two different indicators, a given indicator for nodes <NUM> in the mesh network that have established communication links with and another indicator for nodes for which a communication link has not been established, but for which another node (e.g., node <NUM>) has identified as being a member of the mesh network.

Continuing with the given example, in a subsequent multicast identification message, node <NUM> provides data characterizing an updated status of the token register of node <NUM> to node <NUM>. In response to the data characterizing the updated token register <NUM> of node <NUM>, node <NUM> updates the token register <NUM> of node <NUM>. In particular, node <NUM> stores data in the token register <NUM> indicating that node <NUM> is a member of the mesh network, and that no communication link has been established with node <NUM>.

Continuing with the given example, each of the N number nodes <NUM> continues to broadcast the multicast identification messages at the transient state rate. It is noted that the transient state rate may be the same or different for different nodes <NUM>. At some point, it is presumed that a multicast identification message broadcast by node <NUM> is received at node <NUM>. In response, node <NUM> establishes a communication link with node <NUM>. Additionally, in a subsequent multicast identification message, node <NUM> provides the unique identifier of node <NUM> (e.g., the IP address and open port number) and data characterizing the token register <NUM> to node <NUM>. In response, node <NUM> establishes a communication link with node <NUM> and in a subsequent multicast identification message, provides the unique identifier (e.g., IP address and open port number) of node <NUM> and data characterizing the token register of node <NUM> to node <NUM>. In response to the subsequent multicast identification message, node <NUM> modifies its token register <NUM> to record that a communication link is established with node <NUM>. Thus, at this point in the given example, direct, bi-directional communication is established between each node <NUM> of the mesh network. Accordingly, the mesh network is fully connected mesh network.

In subsequent multicast identification messages broadcast by each node <NUM> of the system <NUM>, the data characterizing the corresponding token register <NUM> identifies every node on the mesh network. Thus, after a predetermined amount of time (e.g., <NUM>-<NUM> seconds), the mesh network is considered to be in a steady state. In such a situation, after the predetermined amount of time, each node <NUM> can reduce the rate of broadcasting the multicast identification messages from the transient state rate to a steady state rate. As one example, in the steady state rate, each node <NUM> broadcasts the multicast identification messages at a rate that is at least one-half less than the transient state rate to reduce network traffic on the mesh network. Thus, if a given node <NUM> broadcasts the multicast identification messages at a rate of one (<NUM>) message per second in the transient state rate, the given node would broadcast the multicast identification messages at a steady state rate of one (<NUM>) message every two (<NUM>) seconds or slower.

Continuing with the given example, it is presumed that at some point in time, after achieving the steady state, node <NUM> goes offline (becomes disabled). In one example, node <NUM> may go offline, for example, due to a failure in software executing on node <NUM>. In another example, node <NUM> may go offline in a situation where an aircraft has sustained damage in a region where physical components of the system <NUM> support node <NUM>. In any such event, upon either node <NUM> or node <NUM> (the remaining function nodes <NUM>) attempting to send a message to the offline node (node <NUM>), the attempt fails. Such a failure could be detected, for example, with a lack of acknowledgement to the message sent.

Continuing with the given example, it is presumed that node <NUM> detects that node <NUM> is not responding to messages. In such a situation, node <NUM> removes node <NUM> from node <NUM>'s token register <NUM>, and node <NUM> switches back to the transient state, wherein node <NUM> broadcasts multicast identification messages at the transient state rate that includes data characterizing the token register <NUM> in the updated state. In response to receipt of the multicast identification message, node <NUM> examines the data characterizing the token register <NUM> of node <NUM> and identifies that node <NUM> is missing. In response, node <NUM> can attempt to send a message to node <NUM>. Since node <NUM> is disabled in the given example, the attempt fails. In response, node <NUM> can remove node <NUM> from the token register <NUM> and return to the transient state, such that multicast identification messages are broadcast at the transient state rate.

Continuing with the given example, upon both remaining online nodes <NUM> (node <NUM> and node <NUM>) detecting that the corresponding token registers do not contain any other nodes in the mesh network, the mesh network returns to the steady state. In the given example, in the steady state, both nodes, nodes <NUM> and <NUM> reduce the rate of transmitting the multicast identification messages from the transient state rate to the steady state rate.

By implementing the system <NUM>, the fully connected mesh network can be established quickly without employment of a server. Moreover, as noted, there is no requirement of any order in which the nodes <NUM> are activated and/or complete a startup process. That is, each node <NUM> on the mesh network can be brought online in any order and/or non-deterministically. Furthermore, the system <NUM> does not have a single point of failure. Rather, the system <NUM> is serverless, such that each node <NUM> can communicate with other nodes <NUM> without an intermediary system. Furthermore, the middleware can be configured such that messages from an application executing on the middleware are delayed until the intended recipient of the message (e.g., another application) comes online.

<FIG> illustrate an example of a system <NUM> for establishing and maintaining a fully connected mesh network amongst a plurality of nodes <NUM>. In the example illustrated, there are four (<NUM>) nodes <NUM>. However, in other examples, there could be more or less nodes <NUM>. The nodes <NUM> can be employed to implement the nodes <NUM> of <FIG>. The nodes <NUM> can be representative of software services executing on a computing platform. Each software service can operate on a middleware that facilitates communication between the nodes <NUM>. Each node <NUM> includes a token register <NUM> (labeled "TR" in <FIG>). It is understood that throughout <FIG>, nodes <NUM> that are illustrated with solid lines (such as node <NUM> and node <NUM> in <FIG>) are considered to be online (completed a startup process). Moreover, throughout the example illustrated in <FIG>, nodes <NUM> with dashed lines (such as node <NUM> and node <NUM> of <FIG>) are considered to be offline (e.g., disabled and/or not completed a startup process).

Each token register <NUM> includes an identification of the corresponding node <NUM>, and a given indication for nodes <NUM> (if any) within the mesh network with which the corresponding node <NUM> has established a communication link. Additionally, each token register <NUM> includes another indication for nodes (if any) within the mesh network that have been identified by another node <NUM>, but where a communication link is not established.

In <FIG>, it is presumed that the network is in a transient state. In particular, as noted, in <FIG> it presumed that node <NUM> and <NUM> are online (completed a startup process) as indicated by solid lines, while nodes <NUM> and <NUM> are offline, as indicated by the dashed lines. In <FIG>, node <NUM> broadcasts a multicast identification message, as indicated by an arrow <NUM>. Since node <NUM> and node <NUM> are offline, node <NUM> receives the multicast identification message <NUM>. The multicast identification message <NUM> can include a unique identifier (e.g., an IP address and an open port number) and a token register for the node <NUM> broadcasting the multicast identification message <NUM>. In response to the multicast identification message <NUM>, as illustrated in <FIG>, node <NUM> establishes a communication link with node <NUM> that is indicated by an arrow <NUM> on the open port identified in the multicast identification message from node <NUM>.

As illustrated in <FIG>, in a next multicast identification message <NUM> broadcast by node <NUM> indicated by an arrow <NUM> includes data characterizing the token register <NUM> of node <NUM>. Since node <NUM> established the communication link <NUM> with node <NUM> and node <NUM> and node <NUM> received the data characterizing the token register <NUM> of node <NUM>, node <NUM> adds node <NUM> to the token register <NUM> of node <NUM>. More particularly, node <NUM> adds node <NUM> to the token register <NUM> along with the given indication that a communication link <NUM> has been established with node <NUM>. As illustrated in <FIG>, node <NUM> establishes a communication link with node <NUM> on the open port of node <NUM> indicated by an arrow <NUM>. Additionally, in a subsequent multicast identification message <NUM>, node <NUM> provides data characterizing the token register <NUM> of node <NUM>, which identifies node <NUM> and node <NUM>. In response, node <NUM> adds node <NUM> to the token register <NUM> of node <NUM> along with a given indication that communication link has been established with node <NUM>.

Furthermore, in <FIG>, direct, bi-directional communication is established between each node <NUM> that is online. Accordingly, in an example where no additional nodes <NUM> come online within a threshold time (e.g., <NUM>-<NUM> seconds), the resultant mesh network is a fully connected mesh network between two nodes <NUM>. Thus, the mesh network is in the steady state, and in such a situation, node <NUM> and node <NUM> reduce a rate of broadcasting the multicast identification messages from a transient state rate to a steady state rate. However, in <FIG> it is presumed that node <NUM> comes online causing node <NUM> and node <NUM> to return to the transient state.

More particularly, in <FIG>, upon node <NUM> coming online, node <NUM> broadcasts a multicast identification message, as indicated by an arrow <NUM>, that includes the unique identifier (e.g., IP address and open port number) and data characterizing the token register <NUM> of <FIG>. In response, node <NUM> establishes a communication link with node <NUM> as indicated by an arrow <NUM>. As illustrated in <FIG>, a subsequent multicast identification message <NUM> (also illustrated in <FIG>) broadcast by node <NUM> provides data characterizing the token register <NUM> of node <NUM>. It is noted that throughout <FIG>, the same reference numbers are employed with different arrows to indicate different endpoints for the same multicast identification message. For example, the multicast identification message <NUM> is broadcast by node <NUM> to both node <NUM> and node <NUM>.

In response to the multicast identification message broadcast <NUM> by node <NUM>, node <NUM> modifies its token register <NUM>. More particularly, node <NUM> adds node <NUM> to the token register <NUM> of node <NUM> along with the given indication that the communication link <NUM> has been established with node <NUM>. Additionally, node <NUM> adds node <NUM> to the token register <NUM> of node <NUM> along with another indication that a communication link has not been established with node <NUM>. As illustrated in <FIG>, nodes <NUM> on the mesh network for which a communication link has not been established are represented in token registers <NUM> with inverted coloring, as indicated by reference number <NUM>.

In <FIG>, in response to the multicast identification message <NUM> from node <NUM>, node <NUM> establishes a communication link with node <NUM>, as indicated by an arrow <NUM>. Additionally, in a subsequent multicast identification message <NUM> broadcast by node <NUM>, node <NUM> provides data characterizing the token register <NUM> of node <NUM>. In this situation, it is presumed that node <NUM> does not receive this particular multicast identification message. In response, node <NUM> adds node <NUM> to the token register <NUM> of node <NUM> along with the given indication that the communication link <NUM> has been established with node <NUM>. Additionally, a subsequent multicast identification message <NUM> from node <NUM> with the data characterizing the token register <NUM> of node <NUM> is received at node <NUM>. In response, node <NUM> adds node <NUM> to the token register <NUM> along with the other indication that a communication link is not established with node <NUM>.

In <FIG>, a subsequent multicast identification message <NUM> broadcast by node <NUM> is received at node <NUM>. In response, node <NUM> establishes a communication link with node <NUM> on the open port of node <NUM>, as indicated by an arrow <NUM>. Additionally, in a subsequent multicast identification message <NUM> broadcast by node <NUM>, node <NUM> provides data characterizing the token register <NUM> of node <NUM> to node <NUM> (and node <NUM>). In response, since the communication link <NUM> from node <NUM> to node <NUM> is established, node <NUM> changes the token register <NUM> of node <NUM> to indicate that the communication link <NUM> is established with node <NUM>.

Further, as illustrated in <FIG>, in further response to the multicast identification message <NUM> broadcast by node <NUM>, node <NUM> establishes a communication link with node <NUM> on the open port of node <NUM>, indicated by an arrow <NUM>. Further, in a subsequent multicast identification message <NUM>, node <NUM> broadcasts the token register <NUM> to node <NUM> (and node <NUM>). Since the communication link <NUM> is established from node <NUM> to node <NUM>, in response, node <NUM> changes the token register <NUM> of node <NUM> to indicate that the communication link <NUM> is established with node <NUM>.

Moreover, similar to the situation illustrated in <FIG>, in <FIG>, direct, bi-directional communication is established between each node <NUM> that is online. Accordingly, in an example where no additional nodes <NUM> come online within a threshold time (e.g., <NUM>-<NUM> seconds), the resultant mesh network is a fully connected mesh network between three (<NUM>) nodes <NUM>. Thus, the mesh network is in the steady state, and in such a situation node <NUM>, node <NUM> and node <NUM> reduce a rate of broadcasting the multicast identification messages from the transient state rate to the steady state rate. However, in <FIG> it is presumed that node <NUM> comes online causing node <NUM>, node <NUM> and node <NUM> to return to the transient state.

More particularly, in <FIG>, upon node <NUM> coming online, as indicated by an arrow <NUM>, node <NUM> broadcasts a multicast identification message that includes the unique identifier (e.g., IP address and open port number) and data characterizing the token register <NUM> of node <NUM>. In the example illustrated in <FIG>, it is presumed that node <NUM> receives the multicast identification message from node <NUM>, and that node <NUM> and node <NUM> do not receive the multicast identification message <NUM> from node <NUM>. In response, node <NUM> establishes a communication link with node <NUM> as indicated by an arrow <NUM>. As illustrated in <FIG>, in a subsequent multicast identification message <NUM> (also illustrated in <FIG>), node <NUM> provides data characterizing the token register <NUM> of node <NUM>. In response, node <NUM> modifies its token register <NUM>. More particularly, node <NUM> adds node <NUM> to the token register <NUM> of node <NUM> along with the given indication that the communication link <NUM> has been established with node <NUM>. Additionally, node <NUM> adds node <NUM> and node <NUM> to the token register <NUM> along with the other indication that a communication link has not been established with node <NUM> or node <NUM>. Further, node <NUM> and node <NUM> each modify their corresponding token registers <NUM> to add an indication that node <NUM> is a node on the mesh network, and that a communication link with node <NUM> has not been established.

As illustrated by <FIG>, a subsequent multicast identification message <NUM> is received by node <NUM>, and in response, node <NUM> opens a communication link, indicated by an arrow <NUM> with node <NUM>. Moreover, a subsequent multicast identification message <NUM> broadcast by node <NUM> is received by node <NUM> and node <NUM>, and not by node <NUM>. In response, node <NUM> modifies its token register <NUM> to indicate the communication link <NUM> has been established with node <NUM>. Additionally, in a manner described herein, node <NUM> establishes a communication link indicated by an arrow <NUM> on the open port of node <NUM> identified in the multicast identification message <NUM> and node <NUM> broadcasts a subsequent multicast identification message <NUM>. In response to the multicast identification message <NUM> from node <NUM> since the communication link <NUM> is established from node <NUM> to node <NUM>, node <NUM> modifies its token register <NUM> to include the given indication that the communication link <NUM> has been established to node <NUM>.

Further still, in response to the multicast identification message <NUM> from node <NUM>, node <NUM> establishes a communication link, indicated by an arrow <NUM> with node <NUM>. Moreover, in response to a subsequent multicast identification message <NUM> broadcast from node <NUM>, node <NUM> modifies its token register <NUM> to include the given indication that the communication link <NUM> is established with node <NUM>.

As illustrated in <FIG>, a subsequent multicast identification message <NUM> broadcast by node <NUM> is received by node <NUM>, node <NUM>, node <NUM> and node <NUM>. In response, node <NUM> opens a communication link indicated by an arrow <NUM> with node <NUM>. Additionally, in response to receipt of a subsequent multicast identification message <NUM> from node <NUM>, node <NUM> modifies its token register <NUM> to include the given indication that the communication link <NUM> has been established with node <NUM>. Additionally, in response to the subsequent multicast identification message <NUM> broadcast by node <NUM>, which is received at node <NUM> (as well as node <NUM> and node <NUM>). In response, node <NUM> opens a communication link indicated by an arrow <NUM> on the open port of node <NUM>. In response to a subsequent multicast identification message <NUM> broadcast by node <NUM>, node <NUM> modifies its token register <NUM> to include the given indication that the communication link <NUM> has been established with node <NUM>.

Moreover, similar to the situation illustrated in <FIG> and <FIG>, in <FIG> direct, bi-directional communication is established between each node <NUM> that is online. Accordingly, in an example where no additional nodes <NUM> come online within a threshold time (e.g., <NUM>-<NUM> seconds), the resultant mesh network is a fully connected mesh network between three (<NUM>) nodes <NUM>. Thus, the mesh network is in the steady state, and in such a situation node <NUM>, node <NUM>, node <NUM> and node <NUM> reduce a rate of broadcasting the multicast identification messages from the transient state rate to the steady state rate.

Further, in <FIG>, it is presumed that node <NUM> goes offline in a non-determinate manner. As some examples, node <NUM> may go offline due to a software crash. In other examples, node <NUM> may go offline due to a hardware failure, such as damage to an aircraft carrying hardware for node <NUM>. In such a situation, multicast identification messages that are broadcast by node <NUM>, node <NUM> and node <NUM>, are not received by node <NUM>, as indicated by the dashed lines at <NUM>, <NUM> and <NUM>. Additionally, at some point, node <NUM> attempts to communicate with node <NUM> via the communication link <NUM>. Further, node <NUM> attempts to communicate with node <NUM> via the communication link <NUM> and node <NUM> attempts to communication with node <NUM> via the communication link <NUM>. Since node <NUM> is offline, each of the communication links <NUM>, <NUM> and <NUM> are severed, as indicated by the dashed lines <NUM>, <NUM> and <NUM>. Accordingly, in this situation, node <NUM>, node <NUM> and node <NUM> switch back to the transient mode, increasing the rate of broadcast of the multicast identification messages from the steady-state rate to the transient state rate.

As illustrated in <FIG>, upon detecting that node <NUM> is offline, node <NUM>, node <NUM> and node <NUM> modify their respective token registers <NUM> to indicate that node <NUM> is a node on the mesh network, but that a communication link has not been established with node <NUM>. Further, after a predetermined amount of time (e.g., <NUM>-<NUM> seconds), as illustrated in <FIG>, node <NUM>, node <NUM> and node <NUM> modify their respective token registers <NUM> to remove node <NUM> from the mesh network. Additionally, in an example where no additional nodes <NUM> come online within a threshold time (e.g., <NUM>-<NUM> seconds), the resultant mesh network is a fully connected mesh network between three (<NUM>) nodes <NUM>. Thus, the mesh network is in the steady state, and in such a situation, node <NUM>, node <NUM> and node <NUM> reduce a rate of broadcasting the multicast identification messages from the transient state rate to the steady state rate.

By employing the system <NUM> of <FIG>, each of the nodes <NUM> can be brought online and/or go offline in a non-deterministic order. Moreover, the middleware that facilitates communication of the nodes <NUM> can delay messages until each corresponding token register <NUM> indicates that a communication link has been established. In this manner, delays due to re-sending of messages and/or collisions on the mesh network can be curtailed. Furthermore, as demonstrated, the system <NUM> is serverless, such that no single point of failure of the system <NUM> exists. In fact, as demonstrated in <FIG>, each node <NUM> is configured to take remedial action in response to detecting another node <NUM> going offline.

<FIG> illustrates an example of a computing platform <NUM> that can support N number of nodes <NUM>, where N is an integer greater than or equal to one (<NUM>), such as the nodes <NUM> of <FIG> and/or <NUM> of <FIG>. The computing platform <NUM> includes hardware <NUM>. In some examples, the hardware <NUM> includes a non-transitory memory (e.g., volatile memory and/or non-volatile memory) for storing machine readable instructions and a processing unit (e.g., one or more processor cores) for accessing the memory and executing the machine-readable instructions. In some examples, the memory can be implemented as a hard disk drive, a solid-state drive, flash memory, random access memory, or any combination thereof. In other examples, the hardware <NUM> can include a microcontroller with instructions embedded therein. Further, in other examples, the hardware <NUM> includes an application specific integrated circuit (ASIC) chip. The hardware <NUM> can also include an interface for communicating with other computing platforms, such as an Ethernet interface, a Wi-Fi interface, a Bluetooth interface, etc..

The computing platform <NUM> can include an operating system <NUM> that executes on the hardware <NUM>. The operating system <NUM> can manage the hardware <NUM> and software resources and can provide common services for computer programs. Further, N number of instances of a middleware <NUM> (e.g., application software) can execute on the operating system <NUM>. Each of the N number of instances of middleware <NUM> can be implemented on a corresponding node <NUM>. The middleware <NUM> can facilitate communication between N number of applications <NUM>, wherein each node <NUM> includes an application. More particularly, each instance of middleware <NUM> can direct network communications (e.g., TCP and/or UDP packets) from one application <NUM> to another, including situations where the two such applications are executing on separate computing platforms. Further, each middleware <NUM> instance can delay requests by a corresponding application <NUM> for communication with another application until a node corresponding to the application comes online. That is, the middleware <NUM> can prevent attempts by a given application <NUM> to communicate with an offline application. In some examples, the N number of instances of middleware <NUM> can provide an isolated runtime environment for the corresponding application <NUM>.

<FIG> illustrates an example of a system <NUM> that could be employed to implement the system <NUM> of <FIG> and/or the system <NUM> of <FIG>. Moreover, the system <NUM> includes three (<NUM>) computing platforms <NUM>. Each computing platform <NUM> can be representative of an instance of the computing platform <NUM> of <FIG>. The system <NUM> is provided as an example of software that could execute on a combat rated aircraft.

The system <NUM> includes nodes executing on each of the computing platforms <NUM>. Each node could be representative of an instance of a node <NUM> of <FIG> and/or a node <NUM> of <FIG>. In the example illustrated in <FIG>, computing platform <NUM> includes a navigation node <NUM> and a controls node <NUM>. The navigation node <NUM> can include, for example, software for controlling a navigation system of the aircraft. The controls node <NUM> can represent software for pilot controls of the aircraft.

Computing platform <NUM> can include, for example, a landing gear node <NUM> that can be representative of software for controlling landing gear of the aircraft. Further, computing platform <NUM> can include a weapons node <NUM> for controlling operations of weapons systems for the aircraft. Each of the navigation node <NUM>, the controls node <NUM>, the landing gear node <NUM> and the weapons node <NUM> can be brought online or offline in a non-deterministic manner, as described herein. Moreover, as illustrated, a bi-directional communication links <NUM> (which can represent two one-way communication links) connect each node in the system <NUM> to every other node in the system <NUM>. In this manner, the system <NUM> operates a fully-connected mesh network. Additionally, the resultant mesh network of the system <NUM> is serverless, such that the system <NUM> does not have a single point of failure.

<FIG> illustrates an example of a method <NUM> for establishing and maintaining a mesh network amongst a plurality of nodes operating on a computing platform. The method <NUM> can be executed by a given node (e.g., a node <NUM> of <FIG> and/or a node <NUM> of <FIG>).

At <NUM>, the given node initializes an application executing thereon, such that the given node is brought online. At <NUM>, the node broadcasts multicast identification messages at a transient state rate. At <NUM>, the node receives a multicast identification message broadcast by another node on the mesh network.

At <NUM>, a determination is made as to whether a communication link has been established with the other node. If the determination at <NUM> is negative (e.g., NO), the method <NUM> proceeds to <NUM>. If the determination at <NUM> is positive (e.g., YES), the method <NUM> proceeds to <NUM>. At <NUM>, the given node establishes a communication link with the other node that broadcast the multicast identification message at a communication port identified in the multicast identification message, and the method returns to <NUM>.

At <NUM>, a determination is made as to whether a node or multiple nodes are to be added to a token register of the given node. The determination can be based, for example, on a determination that the other node which broadcasted the multicast identification message is not in the token register of the given node and/or a third node not in the token register of the given node is identified in the multicast identification message broadcast by the other node. If the determination at <NUM> is positive (e.g., YES), the method <NUM> proceeds to <NUM>. If the determination at <NUM> is negative (e.g., NO), the method <NUM> proceeds to <NUM>. At <NUM>, the given node modifies its token register based on the determination at <NUM>. In particular, the token register at <NUM> records a given indication for each node of the mesh network that the given node has established communication with and another indication of each node on the mesh network for which communication has not been established, and the method <NUM> returns to <NUM>.

At <NUM>, another determination is made as to whether the mesh network has achieved a steady state. The determination at <NUM> can be based, for example, on an amount of time lapse since the token register of the given node was modified in response to a multicast identification message. If the determination at <NUM> is negative (e.g., NO), the method <NUM> can return to <NUM>. If the determination at <NUM> is positive (e.g., YES), the method <NUM> proceeds to <NUM>. At <NUM>, the given node reduces the broadcasting rate of the multicast identification messages to a steady state rate (from the transient state rate).

Claim 1:
A system (<NUM>) for establishing a mesh network
comprising: one or more computing platforms that:
initiates execution of a software application for each of a plurality of nodes (<NUM>) executing on the one or more computing platforms,
wherein each of the plurality of nodes (<NUM>):
establishes a communication link in the mesh network with another node of the plurality of nodes (<NUM>) in response to a multicast identification message from the other node;
records, in a token register (<NUM>), a given indication of each node in the plurality of nodes (<NUM>) for which a communication link is established and another indication of each node of the plurality of nodes (<NUM>) that is identified in one or more multicast identification messages with which a communication link is not established;
broadcasts multicast identification messages on the mesh network in response to the initiation of the respective node, wherein a given multicast identification message from the respective node includes a given identifier for each node of the plurality of nodes (<NUM>) for which the respective node established a communication link and another identifier for each node identified in the one or more multicast identification messages with which the respective node has not established a communication link;
establishes a communication link with each node of the plurality of nodes for which the respective node has not established a communication link based on the other identifier included in the given multicast identification message from the respective node;
reduces a rate of broadcasting the multicast identification messages from a transient state rate to a steady state rate in response to establishing a communication link with each of the plurality of nodes (<NUM>);
detects a failed communication link between the respective node and a particular node;
removes the particular node from the token register; and
changes the rate of the broadcasting the multicast identification messages from the steady state rate to the transient state rate.