Method and device for controlling a mesh communication network for performing stateless function tasks

Abstract

The present invention relates to a method and device for controlling a mesh communication network for performing stateless tasks, 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 management gateway which elects (130) a computing orchestrator node per computing unit. The method calculates (170) a response to a request by 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 management gateway which transmits it (190) to a user who issued the request. Figure 2

Description

Title of the invention: Method and device for controlling a mesh communication network for the execution of tasks relating to stateless functions Technical field

[0001] The present invention relates to the execution of tasks relating to stateless functions at the edge of a mesh communication network comprising loT nodes. In particular, the present invention relates to the control of such a mesh communication network. Technological background

[0002] 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.

[0003] In an effort 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 expanded its services by adding nodes at the edge of mesh communication networks: These are commonly referred to as Fog or Edge.

[0004] In cloud computing, edge nodes support fewer computing resources than other nodes in the cloud. Their lower latency and network load, however, are sufficient to meet the demands of current applications. Even if the addition of resources at the edge of mesh communication networks solves current resource demand problems, cloud computing still relies on computing resources that will have to evolve over time. The development of cloud computing is therefore economically and environmentally fragile because it can be strongly impacted by future semiconductor shortages and / or resource crises.

[0005] 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.

[0006] IoT (Internet of Things) devices are a major source of underutilized computing resources. Their number is increasing exponentially, making it possible to keep up with the evolution of Cloud computing needs. IoT nodes are generally characterized by their lack of onboard resources (computing, power, and storage), intermittent availability, and faults. These nodes typically experience network outages and unexpected crashes that leave them unreachable for extended periods. These IoT nodes may also experience Byzantine faults due to low-end features or malicious attacks.

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

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

[0009] 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 geographical 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 being a carrier of 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).

[0010] A user corresponds, for example, to a natural person carrying a mobile communication device of the smartphone type 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, called TCU (Telematic Control Unit), or a mobile communication device of the smartphone type embedded in the vehicle and connected to the latter via a wired connection (for example of the USB type (Universal Serial Bus or in French “Universal Serial Bus”)) or wireless connection (for example of the Bluetooth® or Wifi® type).

[0011] The mesh communication network 1 implements, for example, commu communications based on LTE (Long-Term Evolution), LTE-Advanced (Long-Term Evolution - Advanced), C-V2X (Cellular - Vehicle to Everything), which is based on 4G and soon 5G, based on LTE.

[0012] The mesh communication network 1 is intended to execute tasks relating to stateless functions. These tasks are ordered by user through requests sent via the mesh communication network 1. The user then receives responses to his requests via the mesh communication network 1.

[0013] The topology of the mesh communication network 1 comprises nodes called gateways to indicate that these nodes correspond to gateways (servers) of the mesh communication network 1, and loT nodes to indicate that these nodes correspond to loT devices.

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

[0015] Gateways PI to P6 manage a large set of loT nodes. They are considerably fewer in number than loT nodes but more resourceful and more available than loT nodes. Their availability is almost complete. However, even though this may occur much less frequently than for loT nodes, gateways can suffer 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 refuse service to the gateway and the loT devices in its subnet.

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

[0017] The definition of such a method involves the definition of a consensus model for controlling the mesh communication network 1.

[0018] Such a consensus model must (i) guarantee system security under both Byzantine and non-Byzantine faults which include network partitioning, delays, node inability to reach and packet loss, (ii) maintain service availability as soon as at least one gateway and three loT nodes are available, (iii) be time-independent to synchronize 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.

[0019] Consensus models (consensus algorithms) were born out of the necessity to provide non-trivial solutions to achieve 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 several processes and mechanisms, guarantee a single output value between a set of possible values ​​proposed by different machines (nodes) on a set of machines ("cluster" in English).

[0020] Paxos (A.Yousefpour. 2019. All one needs to know about fog computing and related edge computing paradigms: A completed 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 achieve 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.

[0021] Paxos has been widely criticized due to its complex applicability to real-world distributed systems due to system heterogeneity and group 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.

[0022] 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, docks, 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. Even though 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.

[0023] 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 is based on Lamport's logical clocks (L. Lamport. 2019. Time, docks, 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 fail.

[0024] Pirogue (A.Munir et al. 2017. IFCIoT: Integrated Fog Cloud loT: A novel architectural paradigm for the future Internet of Things. In IEEE Consumer Electronics Magazine) presents itself as a variant of Raft. Pirogue focuses on high reduction of its energy footprint while maintaining a similar performance to 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 case of disconnection of a gateway (server). Pirogue proposes a new role of the nodes: witness, the node is then able to participate in the consensus quorum when needed.This role is implemented by low-power devices that do not have the capacity to store all of the system's data, thus reducing the energy footprint of the node group.

[0025] These optimizations allow Pirogue to achieve performance, availability and fault tolerance close to that of a five-node group modeled by Raft with low energy footprint configurations such as four-node groups or three nodes and a witness.

[0026] Current consensus models cannot operate on mesh communication network topologies 1 comprising heterogeneous loT nodes of the type described in relation to [Fig.l] given the high heterogeneity, the limited resources of the loT nodes, the intermittent availability of the loT nodes, the high dynamics of the loT nodes and the lack of direct connection between the loT nodes within the mesh communication network 1.

[0027] Indeed, the loT nodes and gateways are very heterogeneous among themselves in terms of resources which depend not only on their hardware characteristics which 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 loT nodes and gateways without interrupting their original functions.

[0028] Furthermore, loT nodes are highly resource-constrained. Even though gateways are much less resource-constrained, they still represent a small portion of the total nodes in the mesh communication network 1. On the other hand, loT devices are characterized, for the most part, by their lack of hardware resources (computing and storage) and their battery constraints, since they are generally powered by batteries. Current consensus models are generally deployed on server nodes (gateways) capable of storing a full copy of the logs of the communication network nodes, which is not the case for loT nodes.

[0029] In addition, loT nodes have intermittent availability. Despite the high connectivity capabilities of gateways, loT nodes often experience network outages and unexpected crashes. Their availability is therefore unreliable, unpredictable, and generally intermittent.

[0030] Furthermore, 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 loT nodes, multiple backbones are present requiring messages to pass through several intermediate nodes before reaching their destination. Thus, reducing the number of messages is necessary to improve the performance of a consensus model.

[0031] In addition, loT 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.

[0032] It is therefore necessary to define a consensus model that can be deployed on a mesh communication network 1 comprising gateways and loT nodes that address the various limitations of current consensus models set out above.

[0033] Summary of the present invention

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

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

[0036] The present invention is based on an original consensus model which can be compared 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: i. roles and classification of nodes: The consensus model divides the nodes into two layers based on their energy and computing capabilities: 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 loT nodes. In addition, the loT nodes are dynamically grouped into subnetworks, also called computing units (UC), based on their degree of availability and computing capabilities, to optimize the execution of tasks related to user requests. Thus, PCM operates on a heterogeneous set of layers. ii. control of the mesh communication network at two levels: at the level of a gateway then resource manager which is dynamically elected and at the level of each subnet by electing an OC calculation orchestrator node for each subnet. iii. dynamic subnet update capabilities and OC node election to respond to a highly dynamic mobile IoT environment that causes each of the subnets to change.

[0037] This consensus model aims to compensate for the limitations of loT 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, synchronization of information in the mesh communication network and coordination of task execution.

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

[0039] Two-level control and clustering of nodes of their availability degree and computing capacity allows to compensate their errors and improve the overall performance of task execution by the mesh communication network.

[0040] The present invention limits energy consumption for performing 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.

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

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

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

[0044] 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 loT nodes to indicate that these nodes correspond to devices connected to the internet, said method comprising the following steps: - obtaining computing units from loT nodes, each computing unit comprises loT nodes and is attached to a gateway to form a subnetwork of the mesh communication network; - election of a resource manager gateway from 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 loT nodes of a computing unit for the execution of tasks of said request by the loT 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 loT node of the computing unit to the computing orchestrator node following the execution of the task by said loT node of the computing unit; - obtaining, by the calculation orchestrator node, a final response from a majority vote based on the intermediate responses collected; - transmission of the final response by the computing orchestrator node to the resource management gateway; and - transmission of the final response by the resource management gateway to the user.

[0045] 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 time limit has elapsed, said request is assigned to another calculation unit.

[0046] 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.

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

[0048] 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 loT 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 of a resource management gateway.

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

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

[0051] 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.

[0052] 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 to implement the steps of the method according to the first aspect of the present invention.

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

[0054] According to a fourth aspect, the present invention relates to a computer program which comprises instructions adapted for executing 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.

[0055] Such a computer program may use any programming language, and 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.

[0056] 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.

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

[0058] Furthermore, 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 an Internet-type network.

[0059] 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

[0060] 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:

[0061] [Fig-1] schematically illustrates, according to a particular embodiment example and not limiting of the present invention;

[0062] [Fig.2] illustrates a flowchart of the different stages of the election process 10 of a resource management gateway according to a particular and non-limiting exemplary embodiment of the present invention;

[0063] [Fig.3] illustrates an example of embodiment of the method 10 of [Fig.l];

[0064] [Fig.4] illustrates a flowchart of the different stages 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;

[0065] [Fig.5] 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;

[0066] [Fig.6] 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;

[0067] [Fig.7] 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;

[0068] [Fig.8] 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.

[0069] Description of the examples of embodiment

[0070] Methods and devices will now be described in the following with joint reference to Figures 1 to 8. The same elements are identified with the same reference signs throughout the description which follows.

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

[0072] 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 loT nodes of this mesh communication network 1.

[0073] The present invention also relates to a method 30 for forming computing units by grouping loT nodes.

[0074] According to the present invention, each gateway of the mesh communication network 1 stores three up-to-date tables: 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).

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

[0076] 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 the GTT tables as will be seen later.

[0077] The TTT table includes 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 will be seen later.

[0078] An loT node is either in a “follower” state or in a Calculus Orchestrator (OC) state.

[0079] A follower node is a passive loT 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.

[0080] A computation orchestrator node, called an OC node, is an loT node that is elected for each computation unit UC. An OC node of a computation 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 computation unit UC following the execution of this task by the other follower nodes of the computation unit UC. The OC node produces a final response from a voting process based on the intermediate responses that it has obtained as will be seen later.

[0081] A gateway can be either in a resource manager (RM) state, or in a dispatcher state, or in a candidate state.

[0082] An RM gateway is suitable for implementing the method 20 for controlling a mesh communication network for the execution of tasks relating to stateless functions. In particular, an RM gateway is suitable for managing all user requests (if a user sends 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 sending a task execution request.

[0083] An RM gateway is also adapted to implement the method 20 for updating the topology of the mesh communication network 1. In particular, an RM gateway is adapted to manage the dynamics of the loT nodes and to broadcast a state of a topology of the mesh communication network 1, as known from the RM gateway, to the other gateways of the mesh communication network 1. An RM gateway also synchronizes the GTT and TTT tables stored by the gateways of the mesh communication network 1.

[0084] The RM gateway is also adapted to implement a method 30 of forming the computing units UC by grouping the loT nodes.

[0085] For example, the RM gateway can determine a group of loT nodes and add new loT nodes to this group without consulting other gateways, only having to propagate information about this addition once the decision has been made. In particular, an RM gateway is adapted to optimally choose an OC node for each computing unit UC.

[0086] The use of a central RM gateway simplifies the management of the highly dynamic GTT, SFTT and TTT tables that are used for task execution.

[0087] Although gateway failures are considerably less frequent than those of loT nodes, an RM gateway may fail or disconnect from the mesh communication network 1, in which case a new RM gateway is elected.

[0088] A dispatcher responds to requests from an RM gateway.

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

[0090] 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-network. Thus, eras act as logical clocks, allowing gateways to identify the most recent information.

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

[0092] 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).

[0093] Given the intermittent availability and dynamics of the loT nodes, the nodes of the mesh communication network 1 communicate using asynchronous remote procedure calls (RPCs) via asynchronous message devices deployed on the gateways. An asynchronous message device deployed on a gateway makes it possible to transmit a message from the gateway to the loT nodes of the subnetwork attached to this gateway. The messages are then delivered at most once to the recipients in order to improve performance. A message intended for an loT node is however retransmitted by a gateway in case an error occurred during the connection of the IoT node with the gateway. Messages are retained until they are consumed or deleted. Gateways can clean up the message stacks of IoT nodes to delete old, unconsumed messages that arrived at the gateway while these recipient IoT nodes were unavailable.

[0094] 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).

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

[0096] configuration of a follower loT node intended to be known by a distributor;

[0097] GTT table intended to be known to a recipient;

[0098] SFTT table intended to be known to a recipient; and

[0099] TTT table intended to be known to a recipient.

[0100] 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.

[0101] 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<Actif, Occupé, Endormi> with the addition 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.

[0102] 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 table index concerned, 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 . message received.

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

[0104] If the information of the received message is obsolete, that is to say 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 of type 2) and its TTT table (message of type 4) to the sender of the received message.

[0105] [Fig.2] 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.

[0106] In a step 110, computing units UC are obtained, each computing unit UC comprising loT 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.

[0107] 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.

[0108] 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 from among the nodes of said computing unit based on the performance and availability of the nodes of said computing unit.

[0109] In a step 140, the RM gateway accepts a task execution request sent by a user.

[0110] Each request (called a “Function Execution Request” (FER) in English) contains a stateless function to be executed by the loT nodes of a CPU. A FER request is composed of function scripts to be executed and libraries necessary for the execution of these scripts.

[0111] 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.

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

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

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

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

[0116] 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.

[0117] According to a variant, if the RM gateway does not receive a final response relating to a request before a time limit has elapsed, the task is assigned to another computing unit UC.

[0118] 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.

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

[0120] 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 sends an asynchronous message carrying the query to the nodes of a computing unit assigned to execute the query.

[0121] This variant gives priority to the computing units formed by the least defective nodes at a given time.

[0122] When the OC node of the selected UC computing unit responds with the final response relating to a request, the RM gateway stores the final response in the entry of its local TTT table relating to the request, sends the final response to the user and synchronizes its TTT table with that of the distributors of the mesh communication network 1.

[0123] [Fig.3] illustrates an example of execution of the tasks according to a particular and non-limiting example of embodiment of the present invention.

[0124] According to the example of [Fig.3], a user Cil sends a request referenced fl 1 to an RM gateway. The RM gateway checks whether fl 1 matches an entry in one of its cache memories.

[0125] Suppose that fl 1 corresponds to a referenced request f2 stored in the FIFO referenced cache memory of the RM gateway. The RM gateway then sends to the user Cil the final response Rf2 stored in the FIFO cache memory in relation to f2. The era and the TTT table index of the RM gateway remain unchanged. In [Fig.3], the era is equal to 1 (e=l) and the index of the TTT table is equal to 1 (ttt_index=l).

[0126] Now suppose that fl 1 does not correspond to a cache entry FIFO. The RM gateway then saves the new fl 1 query in the cache memory and increments the TTT table index ttt_index by one, which increases to 2.

[0127] The RM gateway also selects a computing unit UC formed, according to the example of [Fig.3], of a node OC and two follower nodes Fl and F2 and transmits fl 1 to the node OC and to the nodes Fl and F2.

[0128] The OC node executes the request fl 1 and obtains an intermediate response referenced a.

[0129] The Fl node executes the request fl 1 and provides an intermediate response c to the OC node.

[0130] Node F2 executes request fl 1 and provides an intermediate response a to node OC.

[0131] 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 fl 1. The RM gateway then sends the final response a to the user CL1 (step 190).

[0132] 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 [Fig.3]: Thread registration implies the deletion of an entry corresponding to an fl request.

[0133] 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.

[0134] 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.

[0135] 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 (of 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.

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

[0137] 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.

[0138] 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 dispatcher. 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 dispatchers 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.

[0139] It may also occur that a dispatcher receives a message from another gateway, RM or dispatcher at any time with an era or table index higher 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 may probably be due to malicious behavior or segmentation of the mesh communication network 1.

[0140] In this case, according to a particular and non-limiting embodiment, the dispatcher 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.

[0141] 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 the network connection. 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 operates in the opposite direction when receiving an old era number from another dispatcher.

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

[0143] 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.

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

[0145] 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 ([Fig.4])

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

[0147] In a step 420, a candidate gateway is determined among the dispatchers of the list of dispatchers.

[0148] For this, for example, a most recent GTT table in the 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.

[0149] Initially, two variables optimalDispatcher and optimalNumberOfMsgs are initialized to the value NULL.

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

[0151] In step 430, a number of messages totalMessages is initialized to 0.

[0152] In step 440, for each dispatcher available in the dispatcher list, a number expectMsgs The number of messages expected to be exchanged between the DispLeadTmp dispatcher and the disp dispatcher is determined by assuming that the DispLeadTmp dispatcher is elected as the RM gateway. The total number of messages totalMsgs is then updated by: totalMsgs + expectMsgs *distance(dispLeadTmp, disp) where distance(DispLeadTmp, disp) indicates a distance between the DispLeadTmp and disp dispatchers.

[0153] 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.

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

[0155] When executing this election process 40, some dispatchers may not respond within a time period less than an election expiration time. Each of these dispatchers that has exceeded this election expiration time in turn executes the election process 40 and informs the candidate gateway resulting from the first election that, to its knowledge, this candidate gateway is the most optimal RM gateway for this new era. If a dispatcher of 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 rest of the 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.

[0156] 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 the entire 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.

[0157] 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.

[0158] In event c), at the end of an election period, none of the candidate gateways has 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 re-executed, thus increasing the era. This time, it is confirmed that all participating dispatchers share the same GTT table, and therefore the same candidate gateway. Once a candidate gateway wins the election, this gateway propagates the decision to the rest of the dispatchers.

[0159] According to a particular and non-limiting exemplary 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.

[0160] [Fig.5] 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.

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

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

[0163] Each gateway then tracks the faults of the loT nodes flexibly since each loT node has a different availability and periodicity.

[0164] According to a particular and non-limiting embodiment, each loT 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 from an loT node of said subnetwork during a given period, said gateway assumes that the loT 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 from an loT node of said subnetwork, said gateway assumes that the loT node is connected and adds it to its SFTT table.

[0165] 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.

[0166] [Fig.6] 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.

[0167] Let us assume in this example that the mesh communication network 1 comprises an RM gateway and four distributors D2 to D5.

[0168] Let us also assume that the RM gateway includes a local GTT table formed from 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=l) and the GTT table index is equal to 1 (i=l).

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

[0170] Once this message has been 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 that it stores based on the relevant information carried by this received message.

[0171] For example, this dispatcher updates the era (e=l) and the GTT table index (i=l) as well as its GTT table according to the GTT table carried by the type 2 message.

[0172] According to the example in [Fig.6], the distributor D2 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.

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

[0174] 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).

[0175] If the RM gateway finds no changes (case 1 in [Fig.6]), the RM gateway ignores the content of the received messages.

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

[0177] According to the example in [Fig.6], the distributors D3 and D4 each have an SFTT table modified by the appearance or disappearance of at least one loT node in their subnetwork. These modified SFTT tables are referenced SFTT3' and SFTT4'. The distributors D3 and D4 then each send a type 3 message to the RM gateway which detects a change in the SFTT tables of the 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 in [Fig.6]). The era of the RM gateway remains equal to 1 (e=l). The GTT table index only increases by one unit each period, regardless of the number of changes detected.

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

[0179] According to the example of [Fig.6], 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).

[0180] Since this process relies on comparing SFTT tables, it is advantageous 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.

[0181] According to a variant of the process for 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 the 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 (have a higher era or the same era but a higher table index than that of the SFTT table of the GTT table).

[0182] [Fig.7] illustrates a flowchart of the different steps of the method 30 for forming the computing units by grouping loT nodes, according to a particular and non-limiting exemplary embodiment of the present invention;

[0183] The performance of each computing unit UC is highly dependent on the speed of receiving at least half of the votes from the nodes in the computing unit UC so that the node OC can determine a final response to a query.

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

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

[0186] In addition, given the limited capabilities of IoT devices, and in order to waste as few computational periods as possible, the computational unit formation method also examines the current computational unit distribution to assign nodes to a computational unit in such a way as to minimize changes in this distribution.

[0187] In a step 320, a number of calculation units N is calculated as a function of a number of nodes M per calculation unit.

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

[0189] This embodiment is advantageous because it makes it possible to obtain performances of optimal calculations according to tests carried out by the inventor.

[0190] In a step 330, each computing unit UC is formed by grouping N loT 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.

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

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

[0193] 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.

[0194] 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 an SFTT table representing the availability and the characteristics of the loT nodes of the subnetwork. The loT nodes of this computing unit UC are informed of their attachment to this computing unit UC.

[0195] 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 the nodes.

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

[0197] According to a particular and non-limiting exemplary embodiment, the method of forming a computing unit only occurs if one of the following conditions is verified: a. a computing unit does not contain an OC node or a high-performance loT node; b. the number of loT nodes in the mesh communication network 1 is less than 3.N c. (c) when a predetermined period has elapsed to reoptimize the distribution of loT nodes.

[0198] The RM gateway monitors the loT nodes to ensure that these rules are respected.

[0199] According to a variant, to keep the infrastructure as efficient as possible, by compensating for node losses, the RM gateway prioritizes the execution of tasks to the UC computing units with all their quorum of active high-performance nodes.

[0200] According to a variant, the RM gateway informs the OC node of a computing unit UC each time a change occurs in this computing unit UC concerning the number of nodes of this computing unit.

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

[0202] According to a variant, when a disconnection of an OC node from a computing unit UC occurs, the RM gateway must choose another OC node for this computing unit UC among the nodes of this computing unit UC so that this computing unit UC is operational until the computing unit formation process is executed again.

[0203] In this way, each computing 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.

[0204] Once an loT node of a computing unit UC receives a message carrying a request to execute tasks, this loT 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.

[0205] According to a particular and non-limiting exemplary 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 re-plicated 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 to 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 CPU to be able to tolerate n failures instead of the 2n + 1 required by Raft.This property allows CPU computing units to operate with fewer members with an acceptable level of fault tolerance, which is critical in a faulty and highly dynamic environment.

[0206] [Fig.8] 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.

[0207] 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.

[0208] According to various particular embodiments, the device 23 is communicatively coupled with other similar devices or systems, for example the cal 20, 21 and / or 22 and / or with communication devices, for example a TCU (Telematic Control Unit), for example via a communication bus or through dedicated input / output ports.

[0209] 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.

[0210] 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.

[0211] 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: i. RF radio frequency interface, for example Bluetooth® or Wi-Fi®, LTE (Long-Term Evolution), LTE-Advanced; ii. USB interface (from the English “Universal Serial Bus” or “Universal Serial Bus” in French); iii. HDMI interface (from the English “High Definition Multimedia Interface” or “High Definition Multimedia Interface” in French); iv. LIN interface (from the English “Local Interconnect Network”).

[0212] 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 type (from the English “Controller Area Network” or in French “Réseau de contrôles”), CAN FD (from the English “Controller Area Network Flexible Data-Rate” or in French “Réseau de flexible data rate controllers”), FlexRay (standardized by ISO 17458) or Ethernet (standardized by ISO / IEC 802-3).

[0213] 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 thereby departing from the scope of the present invention. The same would apply to a device configured for the implementation of such a method.

[0214] The present invention also relates to a vehicle, for example an automobile or more generally an autonomous land-based motor vehicle, comprising the device of [Fig.8].

Claims

1. Claims 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 loT 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 loT nodes, each computing unit comprises loT 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 manager 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 manager gateway (RM), of a task execution request issued by a user; - assignment (150), by the resource manager gateway (RM), of said request to loT nodes of a computing unit for the execution of tasks of said request by the loT nodes of said computing unit; - collection (160), by a calculation orchestrator node (OC) of said calculation unit, of at least one intermediate response to said request, each intermediate response being either obtained by the calculation orchestrator node or emitted by an loT node of the calculation unit to the calculation orchestrator node (OC) following the execution of the task by said loT node of the calculation 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.

2. The method of claim 1, wherein if the resource manager (RM) gateway does not receive a final response to said request before a time limit has elapsed, said request is assigned to another computing unit.

3. 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.

4. 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.

5. 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 loT 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).

6. Method according to one of the preceding claims, in which a new election (120) of a resource manager gateway (RM) is triggered to check whether a current resource manager gateway minimizes the number of messages exchanged in the mesh communication network for the execution of tasks.

7. 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.

8. 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 network. mesh communication.

9. 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 implementing the steps of the method according to one of claims 1 to 8.

10. A vehicle comprising a device of claim 9.

Images