FR3146775A1 - Method and device for controlling a mesh communication network for the execution of tasks relating to stateless functions - Google Patents

Abstract

The present invention relates to a method and a device for controlling a mesh communication network for the execution of tasks relating to stateless functions, said mesh communication network comprising nodes called gateways and IoT nodes. The method groups (110) the IoT nodes into computing units, elects (120) a resource manager gateway which elects (130) a computing orchestrator node per computing unit. The method calculates (170) a response to a request by a majority vote based on intermediate responses collected (160) by the IoT nodes of a computing unit. The final response is then transmitted (180) by the computing orchestrator node to the resource manager gateway which transmits it (190) to a user sending the request. Figure for abstract: Figure 2

Description

Method and device for controlling a mesh communication network for the execution of tasks relating to stateless functions

The present invention relates to the execution of tasks relating to stateless functions at the edge of a mesh communication network comprising IoT nodes. In particular, the present invention relates to the control of such a mesh communication network.

Technological background

With the new forms of connected objects, smartphones and computers, the applications implemented on these connected objects have gradually increased their demand for connectivity and computing power. This increase in the resource requirements of applications has been accompanied by a constant increase in the embedded characteristics, energy consumption and price of the devices.

In order to keep devices affordable for the public and to perform tasks related to, for example, stateless functions in a resource-optimized environment, cloud computing has extended its services by adding nodes at the edge of mesh communication networks: These are commonly called Fog or Edge.

In cloud computing, edge nodes support fewer computing resources than other nodes in the cloud. However, their lower latency and network load are sufficient to meet the demands of current applications. Although adding resources at the edge of mesh communication networks solves current resource demand issues, cloud computing still relies on computing resources that will need to evolve over time. The development of cloud computing is therefore economically and environmentally fragile because it may be heavily impacted by future semiconductor shortages and/or resource crises.

To improve the capabilities of the edge layer of the cloud without deploying massive amounts of additional computing resources, it is necessary to leverage the resources that are already deployed.

IoT (Internet of Things) devices are a major source of underutilized computing resources. Their number is increasing exponentially to keep up with the evolving needs of cloud computing. IoT nodes are typically characterized by their lack of onboard resources (computation, energy, and storage), their intermittent availability, and their faults. These nodes typically experience network interruptions and unexpected crashes that leave them unreachable for long periods of time. These IoT nodes may also encounter Byzantine faults due to low-end features or malicious attacks.

To use IoT nodes for cloud computing, it is therefore necessary to implement a method of controlling the infrastructures of mesh communication networks to overcome the faults of the IoT nodes and thus ensure the security and availability of task calculations at the edge of the cloud.

schematically illustrates a mesh communication network 1, according to a particular and non-limiting exemplary embodiment of the present invention.

The mesh communication network 1 advantageously corresponds to a cellular type network, for example a mobile telephone cellular network. Such a cellular network is composed of a set of cells, each cell corresponding to a geographic coverage area of a communication antenna (also called a base station) making it possible to establish radio communications between users (also called clients or users, each user carrying a mobile communication device) and/or between the users and the mesh communication network 1. The size of a cell varies and is for example between 1 km and a few tens of kilometers (for example 20 or 30 km).

A user corresponds, for example, to a natural person carrying a mobile communication device such as a smartphone or a tablet. According to a variant, a user corresponds to a vehicle carrying a computer-type communication device, for example a telematic control unit, known as a TCU (Telematic Control Unit), or a mobile communication device such as a smartphone embedded in the vehicle and connected to the latter via a wired connection (for example of the USB type (Universal Serial Bus)) or wireless connection (for example of the Bluetooth® or Wifi® type).

The mesh communication network 1 implements, for example, communications according to LTE technology (from the English "Long-Term Evolution" or in French "Evolution à long terme"), LTE-Avanced (from the English "Long-Term Evolution - Advanced" or in French "Evolution à long terme supérieure"), C-V2X (from the English "Cellular - Vehicle to Everything" or in French "Cellulaire - Véhicule vers tout") which is based on 4G and soon 5G, based on LTE.

Mesh communication network 1 is intended to perform tasks related to stateless functions. These tasks are ordered by user through requests issued via mesh communication network 1. The user then receives responses to his requests via mesh communication network 1.

The topology of the mesh communication network 1 includes nodes called gateways to indicate that these nodes correspond to gateways (servers) of the mesh communication network 1, and IoT nodes to indicate that these nodes correspond to IoT devices.

According to the example of the , Mesh communication network topology 1 has a fully connected backbone between six gateways P1 to P6 and a set of star subnets in which each gateway P1 to P6 can reach a group of IoT nodes (represented by unreferenced circles). The unreferenced circles in solid lines represent IoT nodes that are either sleeping or awake. The light gray circles represent failed IoT nodes or gateways. The dotted circles represent faulty IoT nodes or gateways. The solid lines represent viable connection links while the dotted lines represent faulty connection links.

Gateways P1 to P6 manage a large set of IoT nodes. They are considerably fewer in number than IoT nodes but more resourceful and more available than IoT nodes. Their availability is almost complete. However, even though it may happen much less often than for IoT nodes, gateways can experience network outages, unexpected crashes, or malicious attacks. These attacks have a greater impact in the case of mesh communication network 1 because they then generally deny service to the gateway and the IoT devices in its subnet.

Thus, it is imperative to provide a method for controlling the mesh communication network 1 which manages the faults of the IoT nodes and gateways in order to ensure continuity of the execution of tasks relating to stateless functions in the “cloud”.

Defining such a process involves defining a consensus model to control the mesh communication network 1.

Such a consensus model must (i) guarantee the security of the system under both Byzantine and non-Byzantine faults which include network partitioning, delays, node inability to reach a node and packet loss, (ii) maintain service availability as soon as at least one gateway and three IoT nodes are available, (iii) be independent of timing to synchronize the topology and task execution and implement an asynchronous intermediate communication mechanism and (iv) be completed as soon as a majority is reached and be able to compensate for the performance loss caused by slower nodes.

Consensus models (consensus algorithms) were born from the need to provide non-trivial solutions to reach an agreement between multiple machines in the most efficient and reliable way possible and to strengthen the fault tolerance of systems. These algorithms, through the use of multiple processes and mechanisms, guarantee a unique output value between a set of possible values proposed by different machines (nodes) on a set of machines ("cluster" in English).

Paxos (A. Yousefpour. 2019. All one needs to know about fog computing and related edge computing paradigms: A complete survey. In J. of Syst. Architecture. Elsevier., D. Ongaro. 2014. In search of an understandable consensus algorithm. In 2014 USENIX Annual Technical Conference) is one such consensus model. Paxos works by allowing a group of nodes to reach agreement on a value, synchronizing these values, and making them learnable for all nodes in a group of nodes. To do this, Paxos classifies nodes into three roles (proposer, acceptor, and learner); it is possible for a node to play more than one role at the same time. To simplify vote counting and avoid desynchronization between nodes when responding to different simultaneous requests, this model implements a two-phase process: (1) a promise phase and, once the majority of nodes have reached agreement on a value, (2) a validation phase, during which the proposer determines the final answer to a request and propagates the result to all nodes in the node group to ensure that the entire mesh communication network is synchronized.

Paxos has been widely criticized due to its complex applicability to real-world distributed systems due to system heterogeneity and cluster node constraints. Multiple proposals have attempted to improve this adaptability and reduce the complexity of Paxos. However, these proposals are still too complex for systems using IoT nodes.

With the goals of achieving high performance levels and facilitating the understanding and implementation of the consensus model, as well as adaptability to real distributed systems, Raft (L. Lamport. 2019. Time, clocks, and the ordering of events in a distributed system. In Concurrency: the Works of Leslie Lamport) then emerged as an alternative to Paxos for managing logs replicated across all nodes in a node group. Although Raft focuses on storing data replication rather than executing tasks, the way of reaching agreements on the synchronization and integrity of stored data is based on the same principles as Paxos.

To simplify the distribution of tasks (i.e., system coordination or maintenance of the mesh communication network topology), Raft proposes three exclusive and different roles of nodes: (a) "leader", the node is then responsible for coordinating all system management actions and requests and ensuring consistency and organization, (b) "follower", the node then passively listens and follows the leader's orders, and (c) "candidate", the node then intervenes during a leader election process. In addition to this centralization of power by the leader, and the means to resolve inconsistencies in the synchronization of log tables, Raft relies on Lamport logical clocks (L. Lamport. 2019. Time, clocks, and the ordering of events in a distributed system. In Concurrency: the Works of Leslie Lamport.) by adding a counting number (called a “term” in Raft) that allows the detection of obsolete information and the restoration of the nodes’ log table. However, despite the simplifications and optimizations provided by Raft, the complexity and cost of the voting process on which this model is based makes its applicability difficult to mesh communication networks comprising IoT nodes that are highly mobile and faulty.

Pirogue (A. Munir et al. 2017. IFCIoT: Integrated Fog Cloud IoT: A novel architectural paradigm for the future Internet of Things. In IEEE Consumer Electronics Magazine) is presented as a variant of Raft. Pirogue focuses on the high reduction of its energy footprint while maintaining a performance similar to that of Raft. In Pirogue, the classic static voting process is replaced by a dynamic linear voting process (S. Jajodia et al. 1990. Dynamic voting algorithms for maintaining the consistency of a replicated database. In ACM Transactions on Database Systems.). This change replaces the classic static quorum majority with a dynamic quorum, requiring fewer nodes to obtain a majority in the event of a gateway (server) disconnection. Pirogue proposes a new role for nodes: witness, the node is then able to participate in the consensus quorum if needed. This role is implemented by low-power devices that do not have the capacity to store all of the system's data, which reduces the energy footprint of the node group.

These optimizations enable Pirogue to achieve performance, availability, and fault tolerance close to those of a five-node cluster modeled by Raft with low-energy footprint configurations such as four-node clusters or three nodes and a witness.

Current consensus models cannot operate on mesh communication network topologies1 comprising heterogeneous IoT nodes of the type described in relation to the considering the high heterogeneity, limited resources of IoT nodes, intermittent availability of IoT nodes, high dynamics of IoT nodes and lack of direct connection between IoT nodes within the mesh communication network 1.

Indeed, IoT nodes and gateways are very heterogeneous among themselves in terms of resources that depend not only on their hardware characteristics that can be either high-end or low-end, but also on the duty cycle and software of these nodes and gateways, since the aim is to use the reserve resources of the IoT nodes and gateways without interrupting their original functions.

Furthermore, IoT nodes are highly resource-constrained. Although gateways are much less resource-constrained, they still represent a small fraction of the total mesh communication network nodes 1 . On the other hand, IoT devices are characterized, for the most part, by their lack of hardware resources (computation and storage) and their battery constraints, since they are usually powered by batteries. Current consensus models are usually deployed on server nodes (gateways) that are able to store a full copy of the logs of the communication network nodes, which is not the case for IoT nodes.

Additionally, IoT nodes have intermittent availability. Despite the high connectivity capabilities of gateways, IoT nodes often experience network outages and unexpected crashes. Their availability is therefore unreliable, unpredictable, and usually intermittent.

Moreover, consensus models rely on a large number of coordination and synchronization messages transmitted over a fully connected backbone, but given the size of mesh communication network topologies comprising IoT nodes, multiple backbones are present requiring messages to pass through multiple intermediate nodes before reaching their destination. Thus, reducing the number of messages is necessary to improve the performance of a consensus model.

Additionally, IoT nodes are highly mobile nodes, both physically and from a network perspective. This makes it difficult to maintain complete synchronization of log tables as required by current consensus models.

It is therefore necessary to define a consensus model that can be deployed on a mesh communication network 1 comprising gateways and IoT nodes that address the various limitations of current consensus models outlined above.

Summary of the present invention

An object of the present invention is to solve at least one of the problems of the technological background described above.

An object of the present invention is a collaborative computing service platform targeting the execution of stateless functions and using IoT nodes having low to medium availability of an already deployed communication network infrastructure.

1. des rôles et une classification des nœuds : Le modèle de consensus divise les nœuds en deux couches en fonction de leurs capacités énergétiques et de calcul : une première couche, qui contient peu les passerelles susceptibles d’être gestionnaire des ressources du réseau de communication maillé, et une deuxième couche, qui contient de nombreux nœuds IoT. De plus, les nœuds IoT sont regroupés dynamiquement en sous-réseau, encore appelé unité de calcul UC, en fonction de leur degré de disponibilité et des leurs capacités de calcul, pour optimiser l’exécution des tâches relatives à des requêtes utilisateur. Ainsi, PCM opère sur un ensemble hétérogène de couches.
2. un contrôle du réseau de communication maillé à deux niveaux : au niveau d’une passerelle alors gestionnaire des ressources qui est élue dynamiquement et au niveau de chaque sous-réseau en élisant un nœud orchestrateur de calcul OC pour chaque sous-réseau.
3. des possibilité de mise à jour dynamique des sous-réseaux et de l’élection de nœud OC pour répondre à un environnement IoT mobile hautement dynamique qui entraîne la modification de chacun des sous-réseaux.

The present invention is based on an original consensus model that can be related to the consensus models of the state of the art such as Raft or Pirogue. But the consensus model of the present invention extends these classic consensus models by adding:

1. roles and classification of nodes: The consensus model divides the nodes into two layers according to their energy and computing capacities: a first layer, which contains few gateways likely to be managers of the resources of the mesh communication network, and a second layer, which contains many IoT nodes. In addition, the IoT nodes are dynamically grouped into subnets, also called computing units UC, according to their degree of availability and their computing capacities, to optimize the execution of tasks relating to user requests. Thus, PCM operates on a heterogeneous set of layers.
2. a two-level mesh communication network control: at the level of a gateway then resource manager which is dynamically elected and at the level of each subnet by electing a calculation orchestrator node OC for each subnet.
3. dynamic subnet update capabilities and OC node election to meet a highly dynamic mobile IoT environment that causes each of the subnets to change.

This consensus model aims to compensate for the limitations of IoT nodes (i.e., high heterogeneity, limited resources, intermittent availability, high dynamics, and lack of direct connection between nodes within the platform) to ensure fault tolerance, information synchronization in the mesh communication network, and coordination of task execution.

The present invention enables the execution of tasks by a weakly connected mesh communication network infrastructure by optimizing the election of a resource management gateway which reduces the total number of messages exchanged.

Two-level control and clustering of nodes in terms of their availability and computing capacity helps to compensate for their errors and improve the overall performance of task execution by the mesh communication network.

The present invention limits the energy consumption for executing tasks at the edge of the cloud because it uses the resources of IoT devices instead of traditional nodes at the edge of the cloud.

The present invention centralizes the management of resources of a large number of IoT nodes without significantly increasing the messages exchanged or slowing down the performance of the mesh communication network.

Since the present invention improves fault tolerance and task coordination, it helps reduce the on-board resources required by vehicles, thereby reducing the price of the on-board architectures of these vehicles.

The present invention offers many possibilities for the development of future resilient Vehicle-to-Anything (V2X) applications that could be commercialized.

According to a first aspect, the present invention relates to a method for controlling a mesh communication network for the execution of tasks relating to stateless functions, said mesh communication network comprising nodes called gateway to indicate that these nodes correspond to gateways of the mesh communication network and nodes called IoT nodes to indicate that these nodes correspond to devices connected to the internet, said method comprising the following steps:
- obtaining computing units from IoT nodes, each computing unit comprises IoT nodes and is attached to a gateway to form a subnetwork of the mesh communication network;
- election of a resource manager gateway among the gateways of the mesh communication network, said resource manager gateway minimizing a number of messages exchanged in the mesh communication network for the execution of tasks;
- election, by the resource management gateway, of a computing orchestrator node for each computing unit, a computing orchestrator node of a computing unit being elected from among the nodes of said computing unit based on the performance and availability of the nodes of said computing unit;
- acceptance, by the resource management gateway, of a task execution request issued by a user;
- assignment, by the resource management gateway, of said request to IoT nodes of a computing unit for the execution of tasks of said request by the IoT nodes of said computing unit;
- collection, by a computing orchestrator node of said computing unit, of at least one intermediate response to said request, each intermediate response being either obtained by the computing orchestrator node or emitted by an IoT node of the computing unit to the computing orchestrator node following the execution of the task by said IoT node of the computing unit;
- obtaining, by the calculation orchestrator node, a final response from a majority vote based on the collected intermediate responses;
- transmission of the final response by the calculation orchestrator node to the resource management gateway; and
- transmission of the final response by the resource management gateway to the user.

According to a particular and non-limiting exemplary embodiment, if the resource management gateway does not receive a final response relating to said request before a delay has elapsed, said request is assigned to another computing unit.

According to a particular and non-limiting exemplary embodiment, the method further comprises a step of verifying the presence of said request in a cache memory of the resource management gateway, and a step of sending a final response stored in the cache memory in relation to said request if said request is stored in said cache memory.

According to a particular and non-limiting exemplary embodiment, the content of the cache memory of the resource management gateway is synchronized with the contents of the cache memories of the other gateways of the mesh communication network.

According to a particular and non-limiting exemplary embodiment, the resource management gateway periodically broadcasts to the gateways of the mesh communication network a message comprising a first table formed from a union of several second tables, each second table representing an availability and characteristics of the IoT nodes of a subnetwork of the mesh communication network , if a gateway receives no message during an election expiration period, said gateway triggers a new election of a resource management gateway.

According to a particular and non-limiting exemplary embodiment, a new election of a resource management gateway is triggered to check whether a current resource management gateway minimizes the number of messages exchanged in the mesh communication network for the execution of tasks.

According to a particular and non-limiting exemplary embodiment, a new election of a resource management gateway is triggered as soon as a gateway of the mesh communication network is disconnected.

According to a particular and non-limiting exemplary embodiment, the method further comprises a step of updating a topology of the mesh communication network and broadcasting an updated topology to all the gateways of the mesh communication network.

According to a second aspect, the present invention relates to a device for controlling a mesh communication network for the execution of tasks relating to stateless functions, the device comprising a memory associated with a processor configured for the implementation of the steps of the method according to the first aspect of the present invention.

According to a third aspect, the present invention relates to a vehicle comprising a device according to the third aspect.

According to a fourth aspect, the present invention relates to a computer program which comprises instructions adapted for the execution of the steps of the method according to the first aspect of the present invention, in particular when the computer program is executed by at least one processor.

Such a computer program may use any programming language, and may be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.

According to a fifth aspect, the present invention relates to a computer-readable recording medium on which is recorded a computer program comprising instructions for carrying out the steps of the method according to the first aspect of the present invention.

On the one hand, the recording medium may be any entity or device capable of storing the program. For example, the medium may include a storage medium, such as a ROM memory, a CD-ROM or a microelectronic circuit type ROM memory, or a magnetic recording medium or a hard disk.

On the other hand, this recording medium may also be a transmissible medium such as an electrical or optical signal, such a signal being able to be conveyed via an electrical or optical cable, by conventional or hertzian radio or by self-directed laser beam or by other means. The computer program according to the present invention may in particular be downloaded from a network such as the Internet.

Alternatively, the recording medium may be an integrated circuit in which the computer program is incorporated, the integrated circuit being adapted to perform or to be used in performing the method in question.

Brief description of the figures

Other characteristics and advantages of the present invention will emerge from the description of the particular and non-limiting exemplary embodiments of the present invention below, with reference to the appended figures 1 to 8, in which:

schematically illustrates, according to a particular and non-limiting exemplary embodiment of the present invention;

illustrates a flowchart of the different steps of the method 10 for electing a resource management gateway according to a particular and non-limiting exemplary embodiment of the present invention;

illustrates an example of carrying out the method 10 of the ;

illustrates a flowchart of the different steps of the method 40 for controlling the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention;

illustrates a flowchart of the different steps of the method 20 for updating the topology of the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention;

illustrates an example of broadcasting an SFTT table in the mesh communication network 1 according to a particular and non-limiting example of the present invention;

illustrates a flowchart of the different steps of the method 30 for forming the calculation units, according to a particular and non-limiting exemplary embodiment of the present invention;

schematically illustrates a device for controlling the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention.

Description of examples of implementation

Methods and devices will now be described in the following with joint reference to Figures 1 to 8. Like elements are identified with like reference signs throughout the description which follows.

The present invention relates to a method 10 for controlling a mesh communication network 1 for the execution of tasks relating to stateless functions.

The present invention also relates to a method 20 for updating the topology of the mesh communication network 1 to orchestrate the fault-tolerant execution of tasks on often faulty or unavailable IoT nodes of this mesh communication network 1.

The present invention also relates to a method 30 of forming computing units by grouping IoT nodes.

According to the present invention, each gateway of the mesh communication network 1 stores three tables up to date: a global topology table (GTT), a topology table of the nodes of the sub-network attached to the gateway (SFTT) and a task tracking table (TTT).

The SFTT table represents the availability and characteristics of the IoT nodes of a subnetwork of the mesh communication network 1 comprising several IoT nodes. This subnetwork is attached to a gateway. The SFTT table is stored by each gateway.

The GTT table of a gateway is formed by the union of SFTT tables of other gateways that are known to said gateway. A table index gtt_index is associated with each GTT table. This table index is used for the synchronization of GTT tables as will be seen later.

The TTT table contains the tasks to be executed and their execution status. A table index ttt_index is associated with each TTT table. This table index is used for synchronizing the TTT tables as we will see later.

An IoT node is either in a “follower” state or in a Calculus Orchestrator (OC) state.

A follower node is a passive IoT node, i.e. it does not issue any requests by itself. A follower node executes the task execution requests assigned to it and sends an intermediate response to an OC node of the computing unit to which this follower node belongs.

A compute orchestrator node, called an OC node, is an IoT node that is elected for each compute unit UC. An OC node of a compute unit UC executes the task execution requests assigned to it and obtains an intermediate response following the execution of a task. An OC node also collects intermediate responses produced by follower nodes of this compute unit UC following the execution of this task by the other follower nodes of the compute unit UC. The OC node produces a final response from a voting process based on the intermediate responses it has obtained as we will see later.

A gateway can be in either a Resource Manager (RM) state, a Dispatcher state, or a Candidate state.

An RM gateway is suitable for implementing the method 20 for controlling a mesh communication network for executing tasks relating to stateless functions. In particular, an RM gateway is suitable for managing all user requests (if a user issues a request to another gateway of the mesh communication network 1, this request is redirected to the RM gateway). It is also suitable for assigning a task to be executed to follower nodes of a computing unit UC, for dynamically selecting the OC nodes and for retransmitting a final response to a user issuing a task execution request.

An RM gateway is also suitable for implementing the method 20 for updating the topology of the mesh communication network 1. In particular, an RM gateway is suitable for managing the dynamics of the IoT nodes and for broadcasting a state of a topology of the mesh communication network 1, as known to the RM gateway, to the other gateways of the mesh communication network 1. An RM gateway also synchronizes with each other the GTT and TTT tables stored by the gateways of the mesh communication network 1.

The RM gateway is also suitable for implementing a method 30 of forming the computing units UC by grouping the IoT nodes.

For example, the RM gateway can determine a group of IoT nodes and add new IoT nodes to this group without consulting other gateways, having to propagate information about this addition only after the decision is made. In particular, an RM gateway is suitable for optimally choosing an OC node for each computing unit UC.

Using a central RM gateway simplifies the management of the highly dynamic GTT, SFTT and TTT tables that are used for task execution.

Although gateway failures are considerably less frequent than IoT node failures, an RM gateway can fail or disconnect from the mesh communication network 1, in which case a new RM gateway is elected.

A dispatcher responds to requests from an RM gateway.

According to the present invention, time is divided into periods of variable length called eras. The eras are numbered with a consecutive integer.

Different dispatchers may observe transitions between eras at different times, and they may not always be aware that one or more elections occurred while they were off-grid. Thus, eras act as logical clocks, allowing gateways to identify the most recent information.

The eras and table indexes (gtt_index and ttt_index) are used for synchronizing the GTT and TTT tables as will be seen in detail later.

A gateway in the candidate state, in short candidate gateway, is used to elect a new RM gateway. When converting a gateway to a candidate gateway, the gateway increments its era by one, initializes its indexes of the GTT and TTT tables to 0, triggers the election process of an RM gateway, and resets an election timer (election delay).

Given the intermittent availability and dynamics of IoT nodes, nodes in the mesh communication network 1 communicate using asynchronous remote procedure calls (RPCs) via asynchronous message devices deployed on gateways. An asynchronous message device deployed on a gateway is used to transmit a message from the gateway to the IoT nodes in the subnet attached to this gateway. The messages are then delivered at most once to the recipients in order to improve performance. However, a message destined for an IoT node is retransmitted by a gateway in the event that an error has occurred during the connection of the IoT node with the gateway. The messages are retained until they are consumed or deleted. Gateways can clean the message stacks of IoT nodes to delete old unconsumed messages that arrived at the gateway while these recipient IoT nodes were not available.

Different messages are defined. Each message includes a type, identifiers of a sending node and a receiving node, an era of information carried by this message, a table index and a useful part ("payload" in English).

According to a particular and non-limiting example of embodiment, a message can be of one of the following four types 1, 2, 3 or 4:

configuration of a follower IoT node intended to be known by a distributor;

GTT table intended to be known to a recipient;

SFTT table intended to be known to a recipient; and

TTT table intended to be known to a recipient.

The table index of a message can be equal to gtt_index for messages of type 1 to 3 and ttt_index for messages of type 4.

The useful part of the message depends on the message type. If type 1 then the part includes a follower duty cycle. The follower duty cycle is defined in milliseconds by three values <Active, Busy, Asleep> with the sum of these three values less than 120s). If type 2 then the useful part includes a GTT table. If type 3 then the useful part includes the SFTT table. If type 4 then the useful part includes the TTT table.

When a receiver receives a new message of type 1, 2, 3 or 4, if the information in the received message is relevant, i.e. if the era of this message is greater than the current era of the receiver, the receiver updates its era and updates its local information. The information in the received message may also be relevant if the era of this message is equal to the current era of the receiver and if the index of this message is greater than a table index of the receiver (gtt_index or ttt_index). In this case, the receiver updates its local information, i.e. it updates the relevant table index which then becomes equal to the index carried by the received message and updates the corresponding table according to the useful part of this received message. If the information in the received message is relevant, an update history log is updated by adding an entry for any new information in the message that is not already present in the log and by deleting entries from the log that do not match the information carried by the received message. An update history log is updated by adding an entry for any new information in the message that is not already present in the log and by deleting entries from the log that do not match the information carried by the received message.

If an existing log entry conflicts with a new entry, the existing entry and everything after it are deleted.

If the information of the received message is obsolete, that is, if the era of this message is less than the current era of the receiver or if the era of this message is equal to the current era of the receiver and if the index of this message is less than a table index of the receiver, then the message is ignored and the receiver sends its GTT table (message type 2) and its TTT table (message type 4) to the sender of the received message.

illustrates a flowchart of the different steps of the method for controlling the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention.

In a step 110, computing units UC are obtained, each computing unit UC comprising IoT nodes of the mesh communication network 1. Each computing unit UC is attached to a gateway of the mesh communication network 1 and forms a subnetwork of the mesh communication network.

In a step 120, a gateway is elected as an RM gateway among the gateways of the mesh communication network 1, said RM gateway minimizing a number of messages exchanged in the mesh communication network for the execution of tasks.

In a step 130, an OC node is elected by the RM gateway for each computing unit UC, an OC node of a computing unit being elected among the nodes of said computing unit according to the performance and availability of the nodes of said computing unit.

In a step 140, the RM gateway accepts a task execution request issued by a user.

Each request (called a Function Execution Request (FER)) contains a stateless function to be executed by the IoT nodes of a computing unit UC. A FER request is composed of function scripts to be executed and libraries needed to execute these scripts.

In a step 150, the RM gateway assigns the request to nodes of a computing unit UC for the execution of the tasks of this request by the nodes of this computing unit UC.

In a step 160, the OC node of said computing unit UC collects at least one intermediate response, each intermediate response being either obtained by the OC node or emitted by a follower node of the computing unit to the OC node following the execution of the task by said follower node of the computing unit UC.

In a step 170, the OC node determines a final response from a majority vote based on collected intermediate responses.

In a step 180, the OC node transmits the final response to the RM gateway.

In a step 190, the RM gateway transmits the final response to the user.

According to a variant of the method, in a step 135, the topology of the mesh communications network 1 is updated and broadcast to all the gateways of the mesh communications network 1.

Alternatively, if the RM gateway does not receive a final response to a request before a timeout has elapsed, the task is assigned to another CPU.

According to a variant, in a step 145, the RM gateway checks the presence of each request received by the RM gateway in its local cache memory.

If the query has already been requested and matches one of the queries stored in a cache, in a step 146, the RM gateway sends the final stored response to the user and refreshes the cache.

If no cache entry matches the query, the RM Gateway adds the query to its Gateway TTT table as a new entry, increments the TTT table index, and emits an asynchronous message carrying the query to the nodes of a compute unit assigned to execute the query.

This variant prioritizes computing units formed by the least faulty nodes at a given time.

When the OC node of the selected UC computing unit responds with the final response to a query, the RM gateway stores the final response in its local TTT table entry for the query, sends the final response to the user, and synchronizes its TTT table with that of the dispatchers in the mesh communication network 1.

illustrates an example of performing the tasks according to a particular and non-limiting example of embodiment of the present invention.

According to the example of the , a user Cl1 issues a request referenced f11 to an RM gateway. The RM gateway checks whether f11 matches an entry in one of its caches.

Suppose that f11 corresponds to a referenced request f2 stored in the referenced cache FIFO of the RM gateway. The RM gateway then sends to the user Cl1 the final response Rf2 stored in the cache FIFO in relation to f2. The era and the table index TTT of the RM gateway remain unchanged. On the , the era is equal to 1 (e=1) and the index of the TTT table is equal to 1 (ttt_index=1).

Now suppose that f11 does not match a FIFO cache entry. The RM gateway then stores the new query f11 in the cache and increments the TTT table index ttt_index by one to 2.

The RM gateway also selects a formed UC computing unit, according to the example of the , an OC node and two follower nodes F1 and F2 and emits f11 to the OC node and to nodes F1 and F2.

The OC node executes the query f11 and obtains an intermediate response referenced a .

Node F1 executes query f11 and provides an intermediate response c to node OC.

Node F2 executes query f11 and provides an intermediate response a to node OC.

The OC node therefore obtains a majority of votes and considers the intermediate response a as being the final response (step 170). The OC node then sends the final response a to the RM gateway (step 180) which stores it in the FIFO memory in relation to the new entry corresponding to the request f11. The RM gateway then sends the final response a to the user CL1 (step 190).

It can be noted that the cache memory can follow the principle of a FIFO stack (First In First Out). In this case, when the maximum number of cache entries is reached, any new entry implies the deletion of an entry stored in the cache memory. This is what is illustrated in the : Saving f11 involves deleting an entry corresponding to a query f1.

According to a particular and non-limiting exemplary embodiment, the content of the cache memory of the RM gateway is synchronized with the contents of the cache memories of the other gateways in the same way as the GTT tables, that is to say that each time a new entry is added or deleted to the cache memory of an RM gateway, the index of the cache memory is incremented by one unit and asynchronous messages are broadcast to synchronize the cache memories of the other distributors of the mesh communication network 1 with the cache memory of the RM gateway.

According to a particular and non-limiting exemplary embodiment, the triggering of an election of an RM gateway (step 120) is based on a heartbeat mechanism defined as follows.

When a gateway starts, it positions itself in the dispatcher state and broadcasts a type 2 message informing the other gateways of the mesh communication network 1 of the contents of its GTT table (the SFTT tables that it knows). The gateway remains in this dispatcher state until it receives a message indicating that an RM gateway is valid or a message indicating that it must switch to a candidate state.

According to a particular and non-limiting exemplary embodiment, an RM gateway periodically broadcasts a type 2 message comprising its GTT table to the gateways of the mesh communication network 1 in order to maintain its authority and to keep the tables of all the gateways synchronized. However, if a distributor does not receive any message during a so-called election expiration period, this distributor assumes that no RM gateway or election process is in progress and triggers a new election to choose a new RM gateway (step 120).

According to a particular and non-limiting embodiment, a new election is triggered as soon as a gateway is disconnected from the mesh communication network 1.

According to a particular and non-limiting exemplary embodiment, a new election is triggered to verify whether a current RM gateway minimizes the number of messages exchanged in the mesh communication network for the execution of tasks. In this case, the RM gateway triggers a new election of an RM gateway (step 120) by considering itself as a distributor. If the RM gateway is no longer the candidate gateway resulting from an election, the RM gateway increases the era and determines its successor, by propagating its choice both to the new candidate gateway and to the rest of the distributors of the mesh communication network 1. This succession mechanism makes it possible to accelerate the election of a new RM gateway (step 120) and to ensure over time the optimality of a current RM gateway.

It may also occur that a dispatcher receives a message from another gateway, RM or dispatcher at any time with a higher era or table index than its era (or with the same era or table index from a different RM gateway) while having already considered an active RM gateway. This case can probably be due to malicious behavior or segmentation of the mesh communication network 1.

In this case, according to a particular and non-limiting embodiment, the distributor alerts the active RM gateway, which merges its GTT table with the GTT table of the other RM gateway, triggers the election process again to lead to an election of a single RM gateway.

According to a particular and non-limiting exemplary embodiment, if an RM or candidate gateway is "obsolete", this gateway is assumed to have temporarily lost network connectivity. This gateway synchronizes with the era and table indexes of the RM gateway and triggers a new RM gateway election (step 120), returning to the dispatcher state. This same mechanism works in the opposite direction when receiving an old era number from another dispatcher.

According to a particular and non-limiting example embodiment, if an election expiration time of the RM gateway elapses without receiving any request sent by the RM gateway, a distributor increments its era by one unit and launches a new election of a new RM gateway.

If a candidate gateway receives a message from a node claiming to be an RM gateway for the same or higher era, the candidate gateway switches to the dispatcher state.

According to a particular and non-limiting exemplary embodiment, if the election period elapses without a majority of distributors, the candidate gateways merge their GTT tables, increase the era and trigger a new RM gateway election (step 120).

According to a particular and non-limiting exemplary embodiment, the election of an RM gateway is implemented by a method 40 of deterministic election of an RM gateway based on a list of all the distributors of the mesh communication network 1 ( )

In a step 410, a distributor increments its era by one unit.

In a step 420, a candidate gateway is determined among the distributors in the distributor list.

For this, for example, a most recent GTT table in mesh communication network 1 is considered. This GTT table contains a list of dispatchers, each having a list of connected nodes and their computing capabilities. This list excludes the RM gateway.

Initially, two variables optimalDispatcher and optimalNumberOfMsgs are initialized to NULL value.

For each dispatcher dispLeadTmp in the dispatcher list, steps 430, 440, and 450 are performed.

In step 430, a message count totalMessages is initialized to 0.

In step 440, for each dispatcher disp in the dispatcher list, a number expectMsgs of messages that are expected to be exchanged between the dispatcher DispLeadTmp and the dispatcher disp is determined by considering that the dispatcher DispLeadTmp is elected RM gateway. The total number of messages totalMsgs is then updated by: totalMsgs + expectMsgs ∗distance(dispLeadTmp, disp) in which distance(DispLeadTmp, disp) indicates a distance between the dispatchers DispLeadTmp and disp.

In step 450, if the total number of messages totalMsgs is less than an optimal number of messages optimalNumberOfMsgs then the dispatcher DispLeadTmp is considered as an RM gateway and a variable optimalDispatcher is updated with the identifier of the dispatcher DispLeadTmp. The optimal number of messages optimalNumberOfMsgs is also equal to the total number of messages totalMsgs.

When each DispLeadTmp dispatcher in the GTT list has been considered, the optimalDispatcher variable indicates which dispatcher was elected as the candidate gateway and the optimalNumberOfMsgs variable indicates the total number of messages relating to this dispatcher.

When performing this election process 40, some dispatchers may not respond within a time period less than an election timeout. Each such dispatcher that has exceeded this election timeout in turn performs the election process 40 and informs the candidate gateway from the first election that, to its knowledge, this candidate gateway is the most optimal RM gateway for this new era. If a dispatcher in the mesh communication network 1 receives one of these messages, it attempts to reach this candidate gateway. If it succeeds, then this gateway is considered to have voted for this candidate gateway to be the new RM gateway. If the dispatcher is unable to wait for this candidate gateway, it will trigger an election in the remaining dispatchers that have not already voted for this candidate gateway. Then, this dispatcher transitions to the candidate gateway state until one of three events occurs: (a) it wins the election, (b) another dispatcher wins the election or is already the RM gateway, or (c) an election period elapses without a winner.

In event a) occurs, a candidate gateway wins an election only if the majority of available dispatchers in mesh communication network 1 vote that it is the most optimal RM gateway. Each dispatcher votes for exactly one candidate gateway in each election, which, given the deterministic behavior of the election process, must always be the same if these dispatchers are synchronized across mesh communication network 1; this never leads to split voting. However, to ensure the correctness of the process, the majority rule guarantees that only one candidate gateway can win the election for a particular era.

In event b), while waiting for votes, a candidate gateway may receive a message from another candidate gateway claiming to be the RM gateway. If the era of this RM gateway is at least as large as the current era of the candidate gateway, the candidate gateway recognizes it as a legitimate RM gateway and returns to the dispatcher state. However, if the era of this RM gateway is smaller than the current era, the message is rejected and the candidate gateway remains in the candidate state.

In event c), at the end of an election period, none of the candidate gateways have enough votes to win or lose the election. This can happen if there are multiple fractures in the mesh communication network 1 that do not allow the dispatchers to have an up-to-date GTT table. When this happens, each candidate gateway sends its GTT table to the rest of the candidate gateways. This merges the GTT tables and the election process is rerun, increasing the era. This time, it is confirmed that all participating dispatchers share the same GTT table, and thus the same candidate gateway. Once a candidate gateway wins the election, this gateway propagates the decision to the rest of the dispatchers.

In a particular and non-limiting example embodiment, since the election of an RM gateway is calculated according to a deterministic method, split votes are unusual. However, if this occurs, the split nodes merge their GTT tables and restart a new election of an RM gateway.

illustrates a flowchart of the different steps of the method 20 for updating the topology of the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention.

In a step 210, the gateway to which a subnet is attached determines the availability of each node of this subnet and updates its SFTT table to indicate the availability and characteristics of each available node of the subnet.

It is advantageous to delegate the maintenance of the availability of the nodes of a subnet to the gateway to which this subnet is attached because the congestion of the mesh communication network 1 and the overall number of messages exchanged on this network are reduced.

Each gateway then tracks IoT node faults flexibly since each IoT node has different availability and periodicity.

According to a particular and non-limiting embodiment, each IoT node of each subnetwork periodically emits a message to indicate that it is available. If a gateway attached to a subnetwork does not receive said message or a message relating to an execution of a task of an IoT node of said subnetwork during a given period, said gateway assumes that the IoT node has disconnected and purges it from its SFTT table. Similarly, if a gateway attached to a subnetwork receives a message for the first time relating to an execution of a task of an IoT node of said subnetwork, said gateway assumes that the IoT node is connected and adds it to its SFTT table.

In a step 220, the SFTT tables of the gateways are broadcast to the gateways of the mesh communication network 1 so that the new topology of a subnetwork is known to all the gateways of the mesh communication network 1.

illustrates an example of broadcasting an SFTT table in the mesh communication network 1 according to a particular and non-limiting example of the present invention.

Let us assume in this example that mesh communication network 1 includes an RM gateway and four D2 to D5 splitters.

Let us also assume that the RM gateway includes a local GTT table formed by the union of its local SFTT table referenced SFTT1 and the SFTT tables of each of the distributors D2 to D5 referenced respectively SFTT2, SFTT3, SFTT4 and SFTT5. The current era of the RM gateway is equal to 1 (e=1) and the GTT table index is equal to 1 (i=1).

In step 221, the RM gateway periodically broadcasts a type 2 message to broadcast its GTT table to all other distributors in the mesh communication network 1.

Once this message is received by a dispatcher, in step 222, if the information in the received message is relevant, this dispatcher updates its GTT table and the information it stores based on the relevant information carried by this received message.

For example, this dispatcher updates the era (e=1) and the GTT table index (i=1) as well as its GTT table based on the GTT table carried by the type 2 message.

According to the example of the , the D2 distributor thus stores its local SFTT table referenced SFTT2, the GTT table referenced GTT1 carried by the received message. Each other distributor D3 to D5 does the same.

In a step 223, each distributor sends a type 3 message carrying its SFTT table to the RM gateway.

In a step 224, the RM gateway compares the SFTT table of each message received with information that it knows from the subnetwork corresponding to this SFTT table (local SFTT tables forming the local GTT table).

If the RM gateway finds no changes (case 1 on the ), the RM gateway ignores the content of the received messages.

If the RM Gateway finds a change, in step 225, the RM Gateway merges the changes into its local GTT table and increases the GTT table index. The index increases by only one each period, regardless of the number of changes detected.

According to the example of the , distributors D3 and D4 each have an SFTT table modified by the appearance or disappearance of at least one IoT node in their subnetwork. These modified SFTT tables are referenced SFTT3' and SFTT4'. Distributors D3 and D4 then each send a type 3 message to the RM gateway which detects a change in the SFTT tables of distributors D3 and D4. The RM gateway then merges the changes into its local GTT table (now referenced GTT2) and increases the index of the GTT table (i=2) (case 2 on the ). The RM gateway era remains equal to 1 (e=1). The GTT table index only increases by one unit each period, regardless of the number of changes detected.

In a step 226, the RM gateway broadcasts the new GTT table to all the distributors of the mesh communication network 1.

According to the example of the , the distributors D2 to D5 are then informed of the new GTT table (GTT2) of the RM gateway during a next broadcast of the type 2 message (step 221).

Since this process relies on comparing SFTT tables, it is beneficial to keep the comparison as lightweight as possible. However, the sizes of these tables are different. The SFTT table has a list of a dozen nodes, and the GTT table has a list of dozens of SFTT tables for example.

According to a variant of the process of updating the topology of the mesh communication network 1, the RM gateway compares the pair <era, table index> of the received message with that stored locally, which makes it possible to identify which is the most recent table among SFTT tables and the local GTT table. The process then continues by comparing the SFTT tables with each other once the SFTT tables contained in the received message are more recent than the local GTT table (has a higher era or the same era but a higher table index than that of the SFTT table of the GTT table).

illustrates a flowchart of the different steps of the method 30 for forming the computing units by grouping IoT nodes, according to a particular and non-limiting exemplary embodiment of the present invention;

The performance of each UC compute unit depends heavily on how quickly at least half of the votes from the UC nodes are received so that the OC node can determine a final answer to a query.

Accordingly, the computational unit formation method (step 110) attempts to minimize the gap between the availability periods of the nodes.

In a step 310, the RM gateway classifies the IoT nodes according to their degree of availability and their computing capacities: an IoT node is said to be efficient when its degree of availability and its computing capacities are high and said to be non-efficient otherwise.

Additionally, considering the limited capabilities of IoT devices, and in order to waste as few computation periods as possible, the computation unit formation method also examines the current computation unit distribution to assign nodes to a computation unit in a way that minimizes changes in this distribution.

In a step 320, a number of calculation units N is calculated based on a number of nodes M per calculation unit.

According to a particular and non-limiting embodiment, N is equal to 5.

This embodiment is advantageous because it allows optimal calculation performance to be obtained according to tests carried out by the inventor.

In a step 330, each computing unit UC is formed by grouping N IoT nodes of the mesh communication network 1, at least one of said nodes being efficient and at least one of said nodes being non-efficient.

According to a particular and non-limiting embodiment, the N fastest nodes are for example distributed among the computing units UC.

According to a particular and non-limiting embodiment, each computing unit comprises an OC node.

According to a particular and non-limiting embodiment, when a computing unit comprises 5 nodes, one of the nodes of a computing unit is considered to be a computing orchestrator node, two other nodes are high-performance nodes and two other nodes are non-performance nodes.

In a step 340, each computing unit UC forms a subnetwork of the mesh communication network 1 which is attached to a gateway of the mesh communication network 1. The gateway stores a table SFTT representing the availability and the characteristics of the IoT nodes of the subnetwork. The IoT nodes of this computing unit UC are informed of their attachment to this computing unit UC.

This method of forming computing units makes it possible to increase the number of computing periods and to homogenize the capacities of the infrastructure of the mesh communication network 1 while seeking to maintain a previous distribution of nodes.

This computational unit formation process may consume significant resources and add overhead to the mesh communication network control process 1. Thus, if the IoT nodes have high intermittency in their availability, this computational unit formation process cannot be executed every time an IoT node disconnection occurs without severely penalizing the performance of the mesh communication network control process 1.

1. une unité de calcul ne contient pas de nœud OC ou de nœud IoT performant ;
2. le nombre de nœuds IoT du réseau de communication maillé 1 est inférieur à 3.N
3. (c) lorsqu’une période prédéterminée est écoulée pour réoptimiser la distribution des nœuds IoT.

According to a particular and non-limiting exemplary embodiment, the method of forming a calculation unit only occurs if one of the following conditions is verified:

1. a compute unit does not contain an OC node or a high-performance IoT node;
2. the number of IoT nodes in mesh communication network 1 is less than 3.N
3. (c) when a predetermined period has elapsed to re-optimize the distribution of IoT nodes.

The RM Gateway monitors IoT nodes to ensure these rules are followed.

Alternatively, to keep the infrastructure as performant as possible, by compensating for node losses, the RM gateway prioritizes task execution to the UC compute units with their full quorum of active performant nodes.

Alternatively, the RM gateway informs the OC node of a computing unit UC whenever a change occurs in that computing unit UC regarding the number of nodes of that computing unit.

This variant optimizes the performance of the mesh communication network control process 1.

Alternatively, when a disconnection of an OC node from a UC compute unit occurs, the RM gateway must choose another OC node for that UC compute unit from among the nodes of that UC compute unit so that that UC compute unit is operational until the compute unit formation process is performed again.

This way, each compute unit can tolerate one node disconnection outside the quorum of performing nodes and up to three disconnections if two of them are non-performing nodes.

Once an IoT node of a computing unit UC receives a message carrying a request to execute tasks, this IoT node executes these tasks and returns its result to the OC node of this computing unit UC. The OC node, which knows the state of the computing unit UC, then checks whether it is able to obtain a majority vote.

In a particular and non-limiting example embodiment, the voting method used by the OC node is a variant of the voting process known as DLV [S. Jajodia et al. 1990. Dynamic voting algorithms for maintaining the consistency of a replicated database. In ACM Transactions on Database Systems]. DLV dynamically defines a majority threshold of votes as a function of the number of connected nodes, which makes it possible to improve the flexibility and performance of the voting process. In the event of a tie, the OC node favors its intermediate response over a FER or, if its intermediate response is not part of the tied intermediate responses, the first intermediate response that reaches the tied quantity is retained as the final response. The use of the voting process based on DLV requires at least n + 2 servers per computing unit UC to be able to tolerate n failures instead of the 2n + 1 required by Raft. This property allows UC computing units to operate with fewer members with an acceptable level of fault tolerance, which is critical in a faulty and highly dynamic environment.

schematically illustrates a device for controlling the mesh communication network 1 for the execution of tasks relating to stateless functions, according to a particular and non-limiting exemplary embodiment of the present invention.

The device 23 is for example configured for the implementation of at least one of the steps of at least one method 10, 20, 30 or 40. The elements of the device 23, individually or in combination, can be integrated into a single integrated circuit, into several integrated circuits, and/or into discrete components. The device 23 can be produced in the form of electronic circuits or software (or computer) modules or even a combination of electronic circuits and software modules.

According to various particular embodiments, the device 23 is coupled in communication with other similar devices or systems, for example the computers 20, 21 and/or 22 and/or with communication devices, for example a TCU (from the English “Telematic Control Unit” or in French “Telematic Control Unit”), for example via a communication bus or through dedicated input/output ports.

The device 23 comprises one (or more) processor(s) 230 configured to execute instructions for carrying out at least part of the steps of at least one method 10, 20, 30 or 40 and/or for executing the instructions of the software(s) embedded in the device 23. The processor 230 may include integrated memory, an input/output interface, and various circuits known to those skilled in the art. The device 23 further comprises or is in association with at least one memory 231 corresponding for example to a volatile and/or non-volatile memory and/or comprises a memory storage device which may comprise volatile and/or non-volatile memory, such as EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, magnetic or optical disk.

The computer code of the embedded software(s) comprising the instructions to be loaded and executed by the processor is for example stored in the memory 231.

1. interface radiofréquence RF, par exemple de type Bluetooth® ou Wi-Fi®, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Advanced (ou en français LTE-avancé) ;
2. interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ;
3. interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français) ;
4. interface LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local »).

According to a particular and non-limiting embodiment, the device 23 comprises a block 232 of interface elements for communicating with external devices, for example a remote computing device. The interface elements of the block 232 comprise one or more of the following interfaces:

1. RF radio frequency interface, for example of the Bluetooth® or Wi-Fi® type, LTE (Long-Term Evolution), LTE-Advanced;
2. USB interface (from the English “Universal Serial Bus” or “Universal Serial Bus” in French);
3. HDMI interface (from the English “High Definition Multimedia Interface” or “High Definition Multimedia Interface” in French);
4. LIN interface (from the English “Local Interconnect Network”).

According to another particular embodiment, the device 23 comprises a communication interface 233 which makes it possible to establish communication with other devices, such as the on-board computers 20, 21 and/or 22 of the vehicle via a communication channel 234. The communication interface 233 corresponds for example to a transmitter configured to transmit and receive information and/or data via the communication channel 234. The communication interface 233 corresponds for example to a wired network of the CAN (Controller Area Network), CAN FD (Controller Area Network Flexible Data-Rate), FlexRay (standardized by the ISO 17458 standard) or Ethernet (standardized by the ISO/IEC 802-3 standard).

Of course, the present invention is not limited to the exemplary embodiments described above but extends to a method of controlling a mesh communication network for the execution of tasks relating to stateless functions which would include secondary steps without departing from the scope of the present invention. The same would apply to a device configured for the implementation of such a method.

The present invention also relates to a vehicle, for example an automobile or more generally an autonomous land-powered vehicle, comprising the device of the .

Claims (10)

A method of controlling a mesh communication network for the execution of tasks relating to stateless functions, said mesh communication network comprising nodes called gateways to indicate that these nodes correspond to gateways of the mesh communication network and nodes called IoT nodes to indicate that these nodes correspond to devices connected to the internet, said method comprising the following steps:
- obtaining (110) computing units from the IoT nodes, each computing unit comprises IoT nodes and is attached to a gateway to form a subnetwork of the mesh communication network;
- election (120) of a resource manager gateway (RM) among the gateways of the mesh communication network, said resource manager gateway (RM) minimizing a number of messages exchanged in the mesh communication network for the execution of tasks;
- election (130), by the resource management gateway (RM), of a calculation orchestrator node for each calculation unit, a calculation orchestrator node of a calculation unit being elected from among the nodes of said calculation unit according to the performance and availability of the nodes of said calculation unit;
- acceptance (140), by the resource management gateway (RM), of a task execution request issued by a user;
- assignment (150), by the resource manager gateway (RM), of said request to IoT nodes of a computing unit for the execution of tasks of said request by the IoT nodes of said computing unit;
- collection (160), by a computation orchestrator node (OC) of said computation unit, of at least one intermediate response to said request, each intermediate response being either obtained by the computation orchestrator node or emitted by an IoT node of the computation unit to the computation orchestrator node (OC) following the execution of the task by said IoT node of the computation unit;
- obtaining (170), by the calculation orchestrator node, a final response from a majority vote based on the collected intermediate responses;
- transmission (180) of the final response by the calculation orchestrator node (OC) to the resource management gateway (RM); and
- transmission (190) of the final response by the resource management gateway (RM) to the user. The method of claim 1, wherein if the resource management gateway (RM) does not receive a final response to said request before a time limit has elapsed, said request is assigned to another computing unit. Method according to one of the preceding claims, which further comprises a step (145) of verifying the presence of said request in a cache memory of the resource management gateway, and a step (146) of sending a final response stored in the cache memory in relation to said request if said request is stored in said cache memory. The method of claim 3, wherein the contents of the cache memory of the resource management gateway are synchronized with the contents of the cache memories of the other gateways of the mesh communication network. Method according to one of the preceding claims, in which the resource management gateway periodically broadcasts to the gateways of the mesh communication network a message comprising a first table (GTT) formed from a union of several second tables (SFTT), each second table representing an availability and characteristics of the IoT nodes of a subnetwork of the mesh communication network , if a gateway does not receive any message during an election expiration period, said gateway triggers a new election (120) of a resource management gateway (RM). Method according to one of the preceding claims, in which a new election (120) of a resource management gateway (RM) is triggered to check whether a current resource management gateway minimizes the number of messages exchanged in the mesh communication network for the execution of tasks. Method according to one of the preceding claims, in which a new election (120) of a resource manager (RM) gateway is triggered as soon as a gateway of the mesh communication network is disconnected. The method of claim 1, which further comprises a step (135) of updating a topology of the mesh communication network and broadcasting an updated topology to all gateways of the mesh communication network. Device for controlling a mesh communication network for the execution of tasks relating to stateless functions comprising a memory associated with at least one processor configured for the implementation of the steps of the method according to one of claims 1 to 8. Vehicle comprising a device of claim 9.