PROCEDURE FOR SELECTING A ROUTE IN AN AD HOC NETWORK

Description

Arrière-plan de l'invention

[0001] The invention relates to the general field of communications between several devices or terminals, such as, for example, computers, mobile phones, digital tablets, etc.

[0002] It concerns, more specifically, peer-to-peer (P2P) communication between several devices or terminals, more generally referred to as "nodes" hereafter. Peer-to-peer communication between two nodes refers to the exchange of data between these two nodes without typically going through a central server. There are no limitations on the type of data exchanged between the nodes (voice, text, etc.) during peer-to-peer communication. This communication can consist of a direct exchange of data between the two nodes (this is called D2D or "Device-to-Device" communication), or an exchange via one or more intermediate nodes implementing D2D communication in pairs, these intermediate nodes forming a route between the two nodes seeking to communicate with each other.The set of nodes thus connected peer-to-peer forms a mesh network without a central hierarchy, also called an ad hoc network. When nodes in the ad hoc network are mobile, it is called a MANET, or Mobile Adhoc Network.

[0003] Nodes within the same ad hoc network can use different connectivity technologies to detect the presence of neighboring nodes, identify the applications or services provided by these neighboring nodes, and connect to each other for peer-to-peer communication. They can rely on technologies such as Bluetooth, Wi-Fi (Wireless Fidelity), Wi-Fi Direct, LTE (Long Term Evolution) Direct, and others. Furthermore, they can connect to elements external to the ad hoc network, such as other devices belonging to operator networks (e.g., 3G, 4G, 5G networks, etc.) or private networks, to access, for example, the public internet.

[0004] While ad hoc networks, and MANETs in particular, possess the ability to self-organize rapidly, they are also highly unstable: some of the nodes that compose them are mobile and therefore susceptible to disappearing or suddenly appearing in the network as they move. Routing messages between two nodes in an ad hoc network can thus prove to be a complex task.

[0005] Several routing protocols proposed by the MANET standardization group have been standardized within the IETF (Internet Engineering Task Force). These routing protocols can be classified into three main categories.

[0006] The first category includes so-called proactive routing protocols. These protocols ensure that each node in the ad hoc network maintains an up-to-date knowledge of the network topology in order to quickly determine the available routes within the network for exchanging data with other nodes. To this end, proactive routing protocols involve the periodic broadcasting of control messages ("Hello" messages) throughout the ad hoc network by each node, in parallel with data transmission messages. These messages declare the state of the links that each node maintains with its neighboring nodes. The broadcasting of these control messages allows each node in the ad hoc network to discover all valid (i.e., available) routes to all nodes in the network, and thus to maintain an up-to-date routing table identifying these routes and taking into account any topology changes that may affect the network.

[0007] Examples of proactive routing protocols include DSDV (Dynamic Destination Sequence Distance Vector), GSR (Global State Routing), and OLSR (Optimized Link State Routing Protocol). These protocols offer the advantage of efficient routing of data messages within small ad hoc networks, thanks to routing tables maintained by each network node. However, due to the numerous control messages (some of which are unnecessary) periodically broadcast on the network, and the maintenance of all possible routes even if they are not in use, their efficiency decreases as the size of the ad hoc network increases.

[0008] A second category of protocols comprises reactive routing protocols. Unlike proactive routing protocols, reactive routing protocols determine and maintain the available routes within the ad hoc network based on the needs of nodes wishing to transmit data across the network. Route Request messages, designed to discover available routes on the network, are sent by a node only when it needs to identify a route to transmit data to another node, and it does not already have such a route stored in its routing table. The routing tables maintained by the network nodes are therefore only populated at their request. Each network node has only partial knowledge of the network topology, limited to the nodes with which it has already communicated.

[0009] Examples of reactive routing protocols include Dynamic Source Routing (DSR) and Ad Hoc On-Demand Distance Vector (AODV). The major advantage of these reactive routing protocols is that they do not result in excessive network flooding with untimely broadcast control messages. They are therefore particularly well-suited for dense networks. However, the time it takes for a node to determine a route can be lengthy, even when the message's destination node is in its immediate vicinity.

[0010] A third category of protocols combines proactive and reactive approaches: these are known as hybrid routing protocols. These protocols rely on a proactive approach to determine routes in the vicinity of nodes (i.e., those located within a few hops of the nodes, for example, two or three hops). Beyond this proximity, they use a reactive approach for route discovery (i.e., on-demand route discovery, only when a node specifically needs a route). An example of a hybrid routing protocol is the Zone Routing Protocol (ZRP).

[0011] Hybrid routing protocols are preferred for networks with mobile nodes: they prevent excessive network flooding with control messages and adapt to the variable and potentially large size of ad hoc networks. However, while they optimize short-distance data routing, the time it takes for a node to discover a route to reach another node that is not in its immediate vicinity can be long (as with reactive routing protocols).

[0012] US documents 2012 / 134298, US 2004 / 029553, and Xianfeng Li et al.'s document "LEPR: Link Stability Estimation-based Preemptive Routing protocol for Flying Ad Hoc Networks" 2017 IEEE SYMPOSIUM ON COMPUTERS AND COMMUNICATIONS (ISCC) all describe route discovery methods in an ad hoc network and maintaining up-to-date routing tables in that network.

[0013] There is therefore a need to improve the routing mechanisms proposed in the state of the art, particularly in the context of networks involving mobile nodes. Objet et résumé de l'invention

[0014] The invention addresses this need in particular by proposing a method for selecting a route in an ad hoc network intended to be implemented by a node of this network, called the "first node", this selection method comprising: a step of maintaining an up-to-date routing table containing at least one route available within the ad hoc network, each route comprising at least one route segment directly linking two nodes of the ad hoc network by a connectivity link of which a type is identified in the routing table, said routing table further comprising, for each node other than the first node belonging to said route segment, an indication concerning a degree of mobility of that node, the routing table being maintained up-to-date from information extracted from control messages issued on the ad hoc network intended for the first node and from control messages issued on the network transiting through the first node;When sending a data message from the first node to a second node in the ad hoc network: ∘ an identification step using the routing table to find at least one available route between the first and second nodes to send the data message; and ∘ if several available routes are identified: ▪ a determination step, for each identified available route, of a stability level based on information regarding the degree of mobility of the route's nodes and the type of connectivity links of the route segments contained in the routing table; and ▪ a selection step of the identified available route corresponding to the best determined stability level.

[0015] Correspondingly, the invention also relates to a node of an ad hoc network, called the "first node", comprising: a routing table maintenance module containing at least one route available within the ad hoc network, each route comprising at least one route segment directly linking two nodes of the ad hoc network by a connectivity link of which a type is identified in the routing table, said routing table further comprising, for each node other than the first node belonging to said route segment, an indication concerning a degree of mobility of that node, the routing table being maintained up to date from information extracted from control messages issued on the ad hoc network intended for the first node and from control messages issued on the network transiting through the first node;modules activated when a data message is sent by the first node to a second node in the ad hoc network, and comprising: ∘ an identification module, configured to identify at least one available route between the first node and the second node using the routing table maintained up to date by the maintenance module; ∘ modules activated if several available routes between the first node and the second node are identified by the identification module, these modules comprising a determination module, configured to determine for each identified available route a level of stability based on indications concerning the degree of mobility of the route nodes and the type of connectivity links of the route segments contained in the routing table, and a selection module configured to select the identified available route corresponding to the best determined level of stability.

[0016] No limitations are attached to the nature of the nodes to which the invention applies. Indeed, the invention applies to any type of device capable of peer-to-peer communication with another device, and equipped with a connectivity interface enabling it to establish a connectivity link with that other device. This connectivity interface can be of various types: it can be a wired interface such as, for example, an Ethernet, xDSL (Digital Subscriber Line), fiber optic interface, etc., or a wireless interface such as Wi-Fi, Bluetooth, 2G, 3G, 4G, LTE, etc.

[0017] Furthermore, the invention is advantageously applicable to ad hoc networks that may include both fixed and mobile nodes. To improve routing within such networks, the invention proposes, when several routes to a node (the second node as defined in the invention) are available within the ad hoc network (i.e., are active within the network), to select the route that appears most stable in terms of connectivity. This route stability is evaluated by taking into account: - the assumed stability of the connectivity links connecting the nodes of the route. This assumed stability of the connectivity links depends on the type of these links and, in particular, on the nature of the connectivity interfaces used on these links (such as, for example, whether it is a Wi-Fi, Bluetooth, Ethernet connection, etc.); and on the stability of the nodes themselves through which the route passes. The stability of the nodes is estimated based on their degree of mobility (for example, "fixed" or "mobile"). Indeed, the more mobile a node is, the more limited its longevity within the network is likely to be (it has a probability of appearing and disappearing suddenly, obviously higher than that of a fixed node), and therefore the more its stability is threatened.

[0018] By choosing the most stable route, as proposed by the invention, for routing data messages exchanged within the ad hoc network, the reliability of the routes used is ensured, thereby reducing the risk of routes suddenly becoming unavailable and resulting in interrupted or delayed exchanges. The quality of exchanges within the ad hoc network and the resulting user experience are thus improved thanks to the invention.

[0019] To enable the selection of the most stable route within the network, the invention relies on maintaining up-to-date routing tables hosted by network nodes. This maintenance utilizes routing information contained in all control messages broadcast on the network and passing through these nodes. Such control messages are typically those broadcast under a proactive routing protocol and / or those broadcast under a reactive routing protocol, and include, in particular, announcement messages, route discovery messages, response messages to discovery messages, and error messages indicating the unavailability of a node or an ad hoc network link detected by another node.Thus, contrary to the prior art, maintaining the routing table of an ad hoc network node does not simply rely on advertisement messages destined for that node and sent by its neighbors, or messages sent in response to route discovery messages sent by the node. Instead, it considers all control messages transiting (i.e., relayed) through that node that are not directly addressed to it. By continuously utilizing these control messages destined for or transiting through the node, the relevance and validity of the information in its routing table are improved. This allows each node in the network to more quickly identify changes in the network's configuration topology, both at the level of the nodes that compose it and the connectivity links existing between those nodes.

[0020] In one particular embodiment, the selection process further comprises: a step of assigning a so-called local stability score to each type of connectivity link and to each type of degree of mobility likely to be contained in the routing table; and a step of calculating a so-called global stability score for each available identified route reflecting the level of stability of that route, this global stability score being calculated from a weighted sum of the local stability scores assigned to the connectivity links of the segments of that route according to their type and to the nodes of that route according to the indications concerning their degree of mobility contained in the table.

[0021] This embodiment offers a simple and effective way to assess the stability of a route. It allows for easy differentiation, via the assigned local stability scores, of the various connectivity links of the segments of each route as well as the degrees of mobility of the nodes of that route.

[0022] For example, during the allocation stage: The local stability score assigned to a wired connectivity link is better than the local stability score assigned to a wireless connectivity link; and / or the local stability score assigned to a fixed mobility degree is better than the local stability score assigned to a mobile mobility degree.

[0023] This allows us to prioritize connectivity links and nodes that have better stability by nature, namely wired connectivity and fixed nodes.

[0024] Furthermore, for the same type of connectivity link (for example, a wireless connection), different local stability scores can be assigned depending on the connectivity interface used (e.g., Wi-Fi, Bluetooth, Wi-Fi Direct, etc.). Thus, for example, a Wi-Fi connection can be assigned a higher local stability score than a Bluetooth connection (which has a shorter range), or compared to a Wi-Fi Direct connection (which is more unstable in practice than a Wi-Fi connection).

[0025] In one embodiment variant, the local stability score assigned to a type of connectivity link may depend on a connectivity interface used on that link and a theoretical throughput achievable on that type of link.

[0026] This allows for an additional level of granularity in the local stability scores assigned based on the type of connectivity link used. For example, for the same type of connectivity link (e.g., a Wi-Fi interface), a local stability score can be assigned that differs depending on the theoretical throughput achievable on that type of link, and in particular, a better local stability score can be assigned to a link with a higher theoretical throughput.

[0027] Similarly, the granularity of the local stability scores assigned according to the degree of mobility of the nodes can be adjusted to take into account the nature of these nodes (i.e., is it a box, a base station associated with a relay antenna of a mobile telecommunications network, a smartphone, a digital tablet, etc.).

[0028] In this way, it is possible to have a more reliable estimate of the stability of a route by taking into account the characteristics of the connectivity links of its segments and nodes.

[0029] In a particular embodiment, during the selection step, the route is selected taking into account, in addition: of a type of data carried by the message; and / or of a constraint in terms of propagation time, latency and / or throughput between the first node and the second node; and / or of an absence or presence of at least one type of connectivity link for the segments of the route.

[0030] This implementation not only allows for the selection of the most stable (and therefore most sustainable) route within the network, but also the route whose technical characteristics best meet the functional requirements (e.g., propagation time constraints, throughput, etc.) of the application hosted by the node and wishing to exchange data on the network (e.g., a real-time video conferencing application), thus further enhancing the user experience. Furthermore, it optimizes route utilization within the ad hoc network and regulates traffic on these routes.

[0031] In a particular embodiment, during the maintenance step, the routing table is further maintained using routing information extracted from data messages sent on the ad hoc network destined for the first node and / or from data messages sent on the network passing through the first node.

[0032] This allows, on the one hand, for improved relevance of the information contained in the routing table, and on the other hand, for easier implementation of the previously mentioned embodiment in which route selection also takes into account the functional requirements of the applications hosted by the network nodes that wish to exchange data on this network. Indeed, the data messages carried on the network can contain information about the characteristics of the nodes and the route segments used by these messages (e.g., propagation times on these segments, latencies, time-to-lives, etc.), which allows for a more precise understanding of them and enables a more relevant selection of a suitable, stable route for transmitting data.

[0033] It should be noted that the invention applies regardless of the routing protocol implemented within the network. However, it has a preferred application when this routing protocol is a hybrid routing protocol, which is particularly well suited when all or part of the nodes of the ad hoc network are mobile nodes.

[0034] For example, in a particular embodiment: The ad hoc network is organized into clusters; the routing table also includes, for each node other than the first node belonging to said route segment, an identifier of at least one cluster of the ad hoc network to which that node belongs; the first node uses a reactive routing protocol to issue route discovery messages to nodes not belonging to a cluster to which it belongs.

[0035] In this particular embodiment, the first node can also use a proactive routing protocol to update its routing table with routes enabling it to reach the nodes of the cluster to which it belongs.

[0036] In one particular embodiment, the different stages of the selection process are determined by instructions from computer programs.

[0037] Consequently, the invention also relates to a computer program on an information medium, this program being capable of being implemented in a network node or more generally in a computer, this program comprising instructions adapted to the implementation of the steps of a selection process as described above.

[0038] This program can use any programming language, and be in the form of source code, object code, or code somewhere between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0039] The invention also relates to a computer-readable information or recording medium, and comprising instructions for a computer program as mentioned above.

[0040] The information or recording medium can be any entity or device capable of storing the program. For example, the medium may include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard drive.

[0041] On the other hand, the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The program according to the invention can, in particular, be uploaded to a network such as the Internet.

[0042] Alternatively, the information or recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

[0043] The invention also relates to an ad hoc communication network comprising a plurality of nodes conforming to the invention.

[0044] The ad hoc communication network according to the invention has the same advantages mentioned above as the selection method and the node according to the invention.

[0045] Furthermore, in a particular embodiment, the nodes are organized into a plurality of clusters, these nodes being configured to implement a proactive routing protocol within the clusters to which they respectively belong and a reactive routing protocol outside these clusters, each cluster comprising a so-called master node designated for the cluster capable of issuing control messages according to the reactive routing protocol to the master nodes of the other clusters, the master node designated for a cluster corresponding to the node among the nodes of the cluster that is the most stable in terms of connectivity and / or activity within the ad hoc network.

[0046] Such a designation of master nodes for clusters further increases the sustainability of the routes selected by the nodes.

[0047] It can also be envisaged, in other embodiments, that the selection process, the node of the ad hoc network, and the ad hoc communication network according to the invention have in combination all or part of the aforementioned characteristics. Brève description des dessins

[0048] Other features and advantages of the present invention will become apparent from the description below, with reference to the accompanying drawings, which illustrate an example of an embodiment without being limiting in any way. In the figures: there figure 1 represents, schematically, an ad hoc communication network conforming to the invention, in a particular embodiment; the figure 2 represents the hardware architecture of a node conforming to the invention belonging to the ad hoc communication network of the figure 1 , in a particular embodiment; the figure 3 illustrates an example of a routing table maintained by a node of the ad hoc communication network of the figure 1 ; and the figure 4 represents, in the form of a flowchart, the main steps of a selection process according to the invention as implemented by each node of the ad hoc communication network of the figure 1 . Description détaillée de l'invention

[0049] There figure 1 represents, in its environment, an ad hoc communication network 1 conforming to the invention, in a particular embodiment.

[0050] The ad hoc network 1 comprises a plurality of nodes (generally referenced by N), conforming to the invention (represented by circles on the figure 1 ). There are no limitations on the nature of these nodes per se: they can be any communication devices capable of communicating with other devices, such as terminals like tablets, smartphones, laptops or desktop computers, or home gateways (also commonly called "boxes"), servers, etc. Obviously, the example shown on the figure 1 is given for illustrative purposes only and a different number of nodes can be considered.

[0051] According to the invention, the nodes of the ad hoc network 1 are distinguished according to their degree of mobility: they can be mobile nodes, which are designed to move over time, such as a mobile phone, a tablet, etc., or fixed nodes, which, on the contrary, are not intended to be mobile once installed (or only exceptionally so), such as an access point to a communication network like a Wi-Fi access point or a base station of a mobile communication network, a residential gateway, or a sedentary server. It should be noted that the fixed or mobile nature of a node can depend on its type (mobile phone, desktop computer, router, etc.), but also on its context of use; therefore, we are interested here in the assumed or declared degree of mobility of this node (see previous examples) or the observed degree of mobility of this node.For example, if the node is not moved for a period of time exceeding a predetermined threshold, this node can be considered, within the meaning of the invention, as fixed. This could be the case, for example, of a laptop computer fixed to a docking station and used as a desktop computer.

[0052] The nodes of ad hoc network 1 can communicate with each other using various connectivity technologies, such as wireless technologies like WiFi, WiFi Direct, Bluetooth, Bluetooth Low Energy, cellular technologies like 3G, 4G, 5G, etc., or wired technologies like Ethernet, ADSL, etc. There are no limitations on the technologies used to establish connectivity links between nodes within ad hoc network 1. Each node can use one or more of these access technologies to communicate with its neighboring nodes; for example, a single node can have multiple links with a neighboring node, each using a different technology. In the following description, the term "neighboring nodes" refers to the nodes with which a node has an active connectivity link.It is noted that the notion of neighborhood is not necessarily linked to geographical proximity depending on the technology used on the connectivity link, but is linked to the range of this technology.

[0053] In the embodiment described here, each node N of the ad hoc network 1 has the hardware architecture of a computer, as represented in the figure 2 . It includes in particular a processor 2, a read-only memory 3, a random-access memory 4, a non-volatile memory 5, and means of communication 6. These means of communication 6 allow the node N to communicate with the other nodes of the ad hoc network 1, via at least one connectivity interface using one of the technologies mentioned above (WiFi, WiFi Direct, Bluetooth, Bluetooth Low Energy, 3G, 4G, 5G, Ethernet, ADSL, fiber optic, etc.).

[0054] The read-only memory 3 of node N constitutes a storage medium according to the invention, readable by the processor 2, on which is stored a computer program PROG according to the invention, comprising instructions for executing a route selection method according to the invention. The PROG program equivalently defines various functional and software modules of node N (namely, an update module 7, an identification module 8, a determination module 9, and a selection module 10), capable of implementing the steps of the route selection method according to the invention, and based on the hardware elements 2-6 of node N described above. This selection method is used by each node N to select a route within the ad hoc network 1 to route the data messages it wishes to send to the other nodes of the ad hoc network 1, as further described later with reference to the figure 4 .

[0055] In the example considered in the figure 1 The nodes of the ad hoc network 1 are grouped into subsets also called "clusters". More specifically, on the figure 1 The ad hoc network 1 comprises four clusters A, B, C, D. Each cluster aggregates nodes located within a given geometric perimeter and sharing common characteristics: in the example of the figure 1 Nodes belonging to the same cluster are connected to each other by the same type of connectivity link. For example: Nodes A1, A2B2, A3, A4, A5 and A6 belonging to cluster A are connected where appropriate by a connectivity link using WiFi technology; nodes B1, A2B2, B3, B4C4 and B5 belonging to cluster B are connected where appropriate by a connectivity link using WiFi Direct technology; nodes C1D4, C2, C3 and B4C4 belonging to cluster C are connected where appropriate by a connectivity link using a mobile radio technology such as 3G, 4G or 5G; and nodes D1, D2, B3D3, C1D4 and D5 belonging to cluster D are connected where appropriate by a connectivity link using Bluetooth Low Energy technology.

[0056] Of course, this example is only given for illustrative purposes and one can consider a different number of clusters, a different number of nodes per cluster, different connectivity interfaces within each cluster, as well as different criteria for grouping nodes within the same cluster (for example, nodes grouped within the same cluster may share the same peer-to-peer application, belong to the same geographical area, etc.).

[0057] It should also be noted that the same node can belong to different clusters. This is the case, for example, on the figure 1 nodes A2B2 (which belongs to cluster A and cluster B), B4C4 (which belongs to cluster B and cluster C), C1D4 (which belongs to cluster C and cluster D) and B3D3 (which belongs to cluster B and cluster D).

[0058] In each cluster A, B, C, D, one node is designated as the master node (also called the "cluster-head" in English) (represented by a hatched circle on the figure 1 ): A1 for cluster A, B1 for cluster B, C1D4 for cluster C, and D1 for cluster D. In the embodiment described here, the master nodes are designated within each cluster based on the (declared, assumed, or observed) stability of the different nodes in the cluster. More specifically, the master node of a cluster is the node that exhibits the best stability in terms of connectivity (due in particular to its degree of mobility ("fixed" or "mobile") or the type of connectivity links it maintains with the other nodes of the ad hoc network) and / or its activity within the ad hoc network (are messages sent on the ad hoc network via this node, etc.). This stability can be evaluated using various criteria, such as: A node can declare to the other nodes in the cluster that it is fixed (and therefore a priori more stable than a mobile node); a node can be considered stable because it is connected to other nodes of the ad hoc network 1 by a wired connectivity link (using for example ADSL or fiber optic technology); a node can be considered stable because it belongs to a route whose longevity (i.e. its age or lifespan) is proven, i.e. it has been ongoing and active for a period of time greater than a predetermined threshold; a node can be considered stable by definition because of its nature or functions, for example it is a WiFi access point or it is attached to an antenna of a mobile operator's network or it is the group owner of a WiFi Direct group for example, etc.

[0059] A weighted combination of all or some of these criteria (and / or other criteria reflecting the stability or instability of a node) can be considered to designate the master node of each cluster: this weighted combination is then evaluated for each node in the cluster, and the node corresponding to the combination reflecting the greatest stability is selected as the master node of the cluster. The list of criteria to be evaluated and the weighting mechanism are not described in further detail here.

[0060] In an alternative implementation, or if it proves impossible to determine the most stable node of the cluster in view of the criteria considered, the master node of a cluster can be chosen empirically: it can be chosen, for example, randomly, or the first node at the origin of the formation of the cluster can be designated as the master node.

[0061] Note that the criteria used to designate the master node, and the weighted combination of these criteria where applicable, are preferably re-evaluated at different times, for example periodically, and the master node may be changed if another node in the cluster turns out to have become more stable than the current master node.

[0062] In the embodiment described here, the nodes of the ad hoc network 1 are configured to implement a hybrid routing protocol based on a proactive routing protocol within their clusters and a reactive routing protocol outside their clusters, described briefly below.

[0063] To this end, each node of the ad hoc network 1 is configured to regularly (periodically) send control messages, and more specifically announcement messages (referred to here as "Hello"), to its neighboring nodes (i.e., those with which it has an active connectivity link) in each cluster to which it belongs. These messages signal its presence to these neighboring nodes. Such announcement messages are commonly used in state-of-the-art proactive routing protocols, such as OLSR and OSPF (Open Shortest Path First). The dissemination and reception of these "Hello" messages within the cluster allows each node N in the cluster to maintain an RT(N) routing table listing the active routes to reach each of the other nodes in its cluster. An example of such an RT routing table is illustrated in Figure 1. figure 3 ,for node N=A2B2 belonging to cluster A and cluster B. For example, it is stored in non-volatile memory 5 of node A2B2.

[0064] In the embodiment described here, the RT(N) routing table of a node N comprises a plurality of rows, each row being associated with a "destination" node of the ad hoc network 1 (multiple rows may be associated with the same node), and a plurality of columns listing: the identifier of the destination node corresponding to the line in question (see ID reference in the routing table of the figure 3 ), the nature (e.g., "box", "antenna", "PC", "tablet") or the degree of mobility of this receiving node (e.g., fixed or mobile) (see reference "TYPE" on the figure 3 ), knowing that, as previously indicated, the nature of the recipient node provides an indication of its degree of mobility; the cluster(s) to which the recipient node belongs (see reference "CLUSTERS" on the figure 3 ), and the route to reach this destination node from node N (see reference "ROUTE" on the figure 3 ): Each route comprises one or more route segments, each route segment directly connecting two nodes of the ad hoc network 1 (in other words, representing a connectivity link between two nodes of the ad hoc network 1). In the RT(N) routing table example, it is presented as a list of pairs, each pair corresponding to a route segment and associated with characteristics of the connectivity link implemented on that segment (Wi-Fi, Wi-Fi Direct (WFD), LTE Direct (LTE), and Bluetooth Low Energy (BLE) in the example considered on the figure 3 These characteristics identify, in particular, the type of connectivity link existing between the two nodes connected by the segment (that is, here, the nature of the connectivity interface used by the two nodes to communicate with each other peer-to-peer). Alternatively, they may include other information such as an observed propagation delay on this segment, a theoretical throughput, a bandwidth, a lifetime in the ad hoc network, etc.

[0065] Thus, in the example of the RT routing table (N=A2B2) illustrated in the figure 3 Node A2B2 is a direct neighbor of node A1, which belongs to cluster A and is a router, and has a "WiFi" connectivity link with this neighbor. Similarly, according to the RT(A2B2) routing table, node A2B2 can reach node A3, which belongs to cluster A and is a personal computer (PC), in two hops via node A1, since nodes A1 and A2B2 are directly connected via a WiFi connectivity link, as are nodes A1 and A3, and so on.

[0066] The RT(N) routing table maintained by a node N therefore contains different active routes within the ad hoc network 1 allowing node N to reach other nodes of this network.

[0067] Note that there are no limitations on the actual form of the RT(N) routing table maintained by each node N of the ad hoc network 1. This routing table can take forms different from the one illustrated in the figure 3 For example, instead of directly referencing the routes allowing node N to reach a node in ad hoc network 1, it may contain only active route segments within the ad hoc network (and for each segment contain its origin node, its end node, and the characteristics of the connectivity link established between these two nodes (including its type)), then it is up to node N, via an appropriate algorithm, to identify the routes composed of one or more active segments listed in the routing table allowing it to reach a given node in ad hoc network 1.

[0068] If a node belongs to several clusters at the same time, such as node A2B2, it is configured to send "Hello" messages to all its neighbors in all the clusters to which it belongs (clusters A and B in the example of node A2B2).

[0069] These "Hello" messages are relayed peer-to-peer in the cluster so as to propagate through the cluster and thus reach all nodes of the cluster.

[0070] In the embodiment described here, the "Hello" messages broadcast by the nodes within their cluster(s) include the following fields: a "deviceId" field containing an identifier of the node that originated the "Hello" message; a "clusterId" field containing an identifier of the cluster to which the node that originated the "Hello" message belongs; a "fromId" field containing an identifier of the last node through which the "Hello" message passed, this field being updated each time the "Hello" message is retransmitted by a node in the cluster; a "hopCount" field indicating the number of hops already made by the "Hello" message (i.e., nodes traversed in the cluster); a "TTL" field for "Time-to-Live" representing the number of hops remaining before the propagation of the "Hello" message stops in the cluster; a "deviceType" field containing the type of the node that originated the "Hello" message; this field here reflects the nature (e.g."box", "antenna", "PC", "tablet", "mobile") or the degree of mobility (fixed or mobile) of the node in question; a "fromType" field containing the type of the last node through which the "Hello" message passed; this field here reflects the nature (e.g., "box", "antenna", "PC", "tablet") or the degree of mobility (fixed or mobile) of the node in question, this field being updated each time the "Hello" message is retransmitted by a node in the cluster; a "linkType" field containing the type of connectivity link of the last route segment traversed, this field being updated each time the "Hello" message is retransmitted by a node in the cluster. In the illustrative example considered here, the type of connectivity link can be Wifi, WifiDirect (WFD), LTE Direct (LTE) or Bluetooth Low Energy (BLE).

[0071] The "deviceType", "fromType", and "linkType" fields allow cluster nodes to populate their routing tables with information representative of the nature or degree of mobility of the cluster nodes, as well as the type of connectivity links established within the cluster.

[0072] The fields indicated above are given for illustrative purposes. Alternatively, the "Hello" message may include other fields (in addition to or less than those indicated above) that allow nodes to populate their routing tables appropriately to implement the invention (for example, the "linkType" field may be omitted if all links within the same cluster use the same connectivity, etc.).

[0073] Thus, in the example of the figure 1 For cluster A and node A6, node A6 is configured to send a "Hello" message to its neighboring node A5, the content of whose fields is reproduced below: deviceId clusterId fromId hopCount TTL deviceType fromType linkType A6 A A6 0 10 Mobile Mobile Wifi

[0074] In another embodiment, the "Hello" message may contain an additional field containing the characteristics of the route taken by the message from the node at the origin of the message to the current node (for example, node A4 may receive a Hello message from node A6 and having passed through nodes A5 and A1 containing in this field the route (Wifi, A6), (Wifi, A5), (Wifi, A1)).

[0075] When node A5 receives the "Hello" message from node A6, it first updates its RT(A5) routing table with the information contained in the "Hello" message.

[0076] In the embodiment described here, each route listed in a node's routing table is associated with a "Timestamp" temporal attribute that stores the time of receipt of a message impacting that route (not shown on the figure 3 When a "Hello" message is received by a node, the node determines whether the message contains a route or route segment corresponding to the information conveyed by the message (in the example described here, a route segment allowing it to reach node A6). If so, it updates the time attribute associated with that route or route segment with the time the "Hello" message was received. Otherwise, it creates a new entry in the table listing the route or route segment indicated in the "Hello" message and associates it with the time the "Hello" message was received.

[0077] Then, as shown in the table below, it inserts the value A5 into the "fromId" field of the "Hello" message, decrements the "TTL" field by 1 and increments the "hopCount" field by 1. Node A5 then transfers the updated "Hello" message to its neighbors in cluster A (i.e., nodes A1 and A4 in the example considered). deviceId clusterId fromId hopCount TTL deviceType fromType linkType A6 A A5 1 9 Mobile Mobile WiFi

[0078] Similarly, node A1 receives the "Hello" message from node A5 and updates its RT(A1) routing table as described above. Then, as shown in the table below, it inserts the value A1 into the "fromId" field of the "Hello" message, decrements the "TTL" field by 1, increments the "hopCount" field by 1, and forwards the updated message to its neighbors A3, A4, and A2B2 in cluster A. deviceId clusterId fromId hopCount TTL deviceType fromType linkType A6 A A1 2 8 Mobile box WiFi

[0079] For its part, node A4 receives the "Hello" message from node A5 and from node A1. It updates its RT routing table based on the received "Hello" messages. However, since it has already received these messages from its only two neighbors in cluster A, it does not retransmit them.

[0080] Finally, nodes A3 and A2B2 receive the "Hello" message from A1, update their respective routing tables from the information contained in the message, but do not forward it: indeed, node A3 has no other neighbor in cluster A than node A1 from which it received the "Hello" message, and node A2B2 does have another neighbor (node ​​B1) but this one does not belong to cluster A.

[0081] Note that a mechanism to prevent the repeated retransmission of "Hello" messages within the cluster can be implemented; such a mechanism is known (already used in some proactive routing protocols) and is not described here. It uses, for example, the TTL field of the "Hello" message. This field can also be used to prevent the "Hello" message from propagating too far into ad hoc network 1, and to prevent too many "Hello" messages from flooding ad hoc network 1.

[0082] In addition, it is possible in an alternative implementation to use a proactive routing protocol different from the one just described within each cluster to populate the routing tables of the nodes of each cluster, such as for example a proactive routing protocol known as the DSDV, GSR, OLSR protocol, etc.

[0083] As mentioned earlier, the nodes of ad hoc network 1 are configured to use a reactive protocol to exchange information with nodes not belonging to their cluster.

[0084] More specifically, for this purpose, each master node, denoted MN, in a cluster has a cluster table, CT(MN), listing the clusters it knows and the master nodes of those clusters. Furthermore, each master node MN in a cluster is configured to regularly (periodically) send control messages, which we will call "InfoCluster" messages, to the master nodes of the clusters it knows exist—in other words, those listed in its cluster table, CT(MN)—to share with these master nodes the information it has about the clusters it knows exist, and in particular, the master nodes of those clusters.

[0085] In the embodiment described here, the "InfoCluster" messages broadcast by the master nodes to the master nodes of other clusters include the following fields: a "deviceId" field containing an identifier of the master node that originated the "InfoCluster" message; a "clusterId" field containing an identifier of the cluster to which the master node that originated the "InfoCluster" message belongs; a "fromDeviceId" field containing an identifier of the last master node through which the "InfoCluster" message passed, this field being updated each time the "InfoCluster" message is retransmitted by a master node of a cluster; a "fromClusterId" field containing an identifier of the cluster of the last master node through which the "InfoCluster" message passed, this field being updated each time the "InfoCluster" message is retransmitted by a master node of a cluster; a "knownClusters" field containing the list of (cluster identifier, corresponding master node) pairs known to the master node that originated the "InfoCluster" message; a "TTL" field for "Time-to-Live" representing the number of hops remaining (i.e.master nodes through which the message passes) before the propagation of the "InfoCluster" message stops.

[0086] The fields shown above are for illustrative purposes only. Alternatively, the "InfoCluster" message may include other fields (in addition to or fewer than those shown above).

[0087] Thus, in the example illustrated in the figure 1 If we consider the master node C1D4 of cluster C, it is aware of clusters B and D, and sends an "InfoCluster" message to the master node B1 and the master node D1, the content of which is indicated in the table below: deviceId clusterId from DeviceId from ClusterId knownClusters TTL C1D4 C C1D4 C (B, B1), (D, D1) 3

[0088] When master node B1 receives the "InfoCluster" message from master node C1D4, it first updates its cluster table CT(B1) with the information contained in the message. For example, it updates its cluster table CT(B1) if the "InfoCluster" message it receives contains new clusters that it did not previously know about (for example, here, with cluster D and master node D1 of cluster D, if master node B1 did not already know about cluster D) or if the master nodes of clusters that it knows have changed compared to the master nodes identified in its cluster table.

[0089] Then it modifies the "fromDeviceId", "fromClusterId" and TTL fields of the "InfoCluster" message as shown in the table below and forwards the message to the other cluster master nodes it knows except for the master node C1D4 from which it received the message, namely here to the master nodes A1 and D1. deviceId clusterId from DeviceId from ClusterId known Clusters TTL C1D4 C B1 B (B, B1), (D, D1) 2

[0090] Master node D1 proceeds in the same way as master node B1 from the "InfoCluster" message received from master node C1D4.

[0091] Master node A1 receives the "InfoCluster" message from master node B1 and updates its CT(A1) cluster table in a similar manner to what was previously described for B1. It is now aware of the existence of clusters B, C, and D, and the master nodes designated for these clusters.

[0092] Note that, as with "Hello" messages, an anti-looping mechanism can be implemented, notably through the TTL field to stop the retransmission of an "InfoCluster" message in a loop.

[0093] Furthermore, in the embodiment described here, each master node is assumed to maintain an up-to-date CT cluster table containing the clusters and the master nodes of the clusters it knows. In an alternative embodiment, not only the master nodes of the clusters maintain such a table, but also the other nodes of the cluster, this table containing the clusters known to the node.

[0094] Thanks to the cluster table maintained by the master nodes, it is possible, as mentioned previously, to implement a reactive routing protocol outside of each cluster. It is assumed here that each node within a cluster knows the master node of its own cluster (for example, via a cluster table as described above, managed by the node).

[0095] When an originating node, for example node A3 of cluster A, wants to send a message containing data to another node in ad hoc network 1, for example node D2 belonging to cluster D, it examines its RT(A3) routing table to determine if it knows the destination node D2 and a route to reach that node. If node D2 is listed in its routing table (i.e., there is at least one row corresponding to ID=D2 in the table), node A3 identifies the route to reach node D2 (in the routing table example shown in the...). figure 3 It retrieves the route(s) contained in the "ROUTE" column of its table and corresponding to an "ID" field equal to D2, and sends its data message to the next node indicated by the route. The case where multiple routes are determined is described in more detail later with reference to the figure 4 .

[0096] If, on the other hand, node D2 is not listed in its routing table—in other words, node A3 does not know of a route to reach node D2—it sends a control message to the master node A1 of its cluster according to a reactive routing protocol. This control message is a route discovery RREQ request, comprising a plurality of fields, namely: a "sequenceNumber" field containing a sequence number to differentiate RREQ requests when they pass through a common node; a "sourceDeviceId" field containing an identifier of the node that originated the RREQ request; a "sourceClusterId" field containing an identifier of the cluster of the node that originated the RREQ request; a "destDeviceId" field containing an identifier of the node that receives the RREQ request (for example D2 in the example considered here of the route to reach node D2); a "destClusterId" field containing an identifier of the cluster of the node that receives the RREQ request (for example D in the example considered here of the route to reach node D2); a "hops" field containing the list of nodes relaying the RREQ request as well as the characteristics of the connectivity links they maintain with the nodes directly preceding them in the list.These characteristics include, in particular, the type of connectivity link, but may also include other link characteristics such as the theoretical throughput of this link, the propagation time on the link, the available bandwidth, etc.; a "hopsCount" field indicating the number of hops already made by the RREQ request (i.e., the number of intermediate nodes traversed); and a "TTL" field for "Time-to-Live" representing the number of hops remaining (i.e., nodes) before the RREQ request propagation stops.

[0097] The fields indicated above are given for illustrative purposes. Alternatively, the "RREQ" control message may include other fields (in addition to or fewer than those indicated above). It should be noted, however, that the "hops" field described above is particularly advantageous within the context of the invention since it conveys information on the characteristics of the connectivity links existing between the nodes (and in particular on the type of these connectivity links).

[0098] If node A3 belongs to multiple clusters, it sends an RREQ request to all master nodes of the clusters to which it belongs.

[0099] Upon receiving the RREQ request, master node A1 examines its routing table to determine if it knows a route to node D2. If node D2 is listed in its routing table (i.e., there is at least one row corresponding to ID=D2 in the table), master node A1 identifies the route to reach node D2 and indicates it in response to the RREQ request issued by node A3 via a control message, in this case, an RREP response message. Otherwise, master node A1 examines its cluster table and then forwards the RREQ request to the master nodes of the clusters it knows (or, alternatively, its neighboring clusters) after updating the "hop", "hopsCount", and "TTL" fields of the request. In other words, in this example, it forwards the request to master node B1 of cluster B, master node D1 of cluster D, and master node C1D4 of cluster C via the routes indicated in its routing table to reach these master nodes.

[0100] Upon receiving the RREQ request from master node A1, master node B1 examines its RT(B1) routing table to determine if it knows node D2. If D2 is listed in a row of its RT(B1) routing table, it retrieves the corresponding route(s) and returns them to master node A1 via a control message, in this case an RREP response message.

[0101] If master node B1 does not know a route to reach node D2 (D2 is not listed in its routing table), master node B1 forwards the RREQ route discovery request to the master nodes of the clusters it knows except for master node A1 (obtained from its cluster table), in this case to master nodes D1 and C1D4.

[0102] Upon receiving the RREQ request from master node B1, master node D1 examines its RT(D1) routing table to determine if it knows of node D2. Since it does (D2 belongs to its cluster), it sends the route(s) to reach D2 to master node B1 in an RREP response message (a control message as defined in the invention). It is assumed here that the RREP response message has the same format and contains the same fields described previously as the RREQ request.

[0103] Note that master node D1 receives the RREQ request from two different master nodes, namely master node B1 and master node A1. This allows it to discover several routes with different characteristics. The RREP response message is therefore also sent to master node A1, which in turn relays it to node A3.

[0104] Master node B1 forwards the response message to master node A1, which in turn relays it to node A3.

[0105] Furthermore, the master node C1D4, which also received the RREQ request, also knows a route to reach node D2 (since it belongs to the same cluster D here). Master node C1D4 therefore also sends the corresponding route to master node B1 in an RREP reply message. Master node B1 forwards the reply message to master node A1, which in turn relays it to node A3.

[0106] According to the invention, each master node through which an RREP reply message passes extracts the routing information contained in that message and advantageously updates its routing table with this information before retransmitting the reply message to the next (master) node.

[0107] Upon receiving the two reply messages sent respectively by master nodes D1 and C1D4, node A3 updates its RT(A3) routing table. Specifically, it adds two rows to its RT(A3) routing table (if each message contains a single route; otherwise, as many rows as there are routes in the reply messages) indicating the routes communicated by master nodes C1 and C1D4 that allow access to node D2. The method by which node A3 selects one of these routes is described in more detail later with reference to the figure 4 .

[0108] Note that in one embodiment variant it is possible to use a reactive routing protocol different from the one just described to discover routes outside each cluster and populate the routing tables of the nodes of the ad hoc network, such as for example a reactive routing protocol known as the DSR, AODV, etc. protocol.

[0109] According to the invention, the RT(N) routing table of a node N is updated, as described above, through the "Hello" control messages exchanged within the framework of the proactive routing protocol implemented within each cluster to discover the active routes within that cluster, through the RREQ requests and the RREP responses to these requests exchanged within the framework of the reactive protocol outside the clusters, but also more generally from information conveyed by each control message issued within the ad hoc network 1 to enable the routing of data within it.These control messages include, in particular, all the control messages exchanged within the framework of the proactive and reactive routing protocols described above, that is to say, not only the messages aimed at announcing itself to its neighboring nodes ("Hello" messages), the route discovery requests RREQ and the responses to these requests RREP, but also the error messages RRER raised by the network nodes when, for example, they detect that an intermediate node on a route has become unreachable or that a connectivity link has broken, etc.

[0110] As is known in an ad hoc network such as ad hoc network 1, during a data exchange between a source node and a destination node via a route determined by the source node using its routing table, if one of the intermediate nodes on the route becomes unreachable (for example, an intermediate node disconnects from ad hoc network 1) and another node on the route detects the problem, the latter is configured to send an error message, referred to here as an RERR message, to the source node. For illustrative purposes, let's assume in the example of the figure 1 If node A3 exchanges data with node C3 via the route consisting of nodes A3-A1-A2B2-B1-B4C4-C1D4-C3, and node B4C4 leaves the ad hoc network 1 (for example, it disconnects), the route taken by the data exchanged between nodes A3 and C3 becomes invalid. Consequently, when node A3 sends a new data message to node C3, the link to node B4C4 is no longer available by the time the data message arrives at node B1. Node B1 detects this problem and sends an RERR error message back to node A3 to report the issue.

[0111] In the embodiment described here, the RERR error message includes a plurality of fields, namely: a "sourceDeviceId" field containing an identifier of the node that detected a problem affecting the connectivity of one of the nodes of the ad hoc network 1 (node ​​that became unreachable) and therefore which is the source of the RERR error message; a "sourceClusterId" field containing an identifier of the cluster of the node that originated the RERR error message; an "errorDeviceId" field containing an identifier of the node that became unreachable; an "errorClusterId" field containing an identifier of the cluster of the node that became unreachable; an "errorLink" field containing the type of connectivity link to the node that became unreachable which is no longer usable (to handle cases where a node can be reached via several connectivity interfaces and only one of them is no longer usable);a "route" field which contains all intermediate nodes belonging to the route which has become invalid as well as the characteristics of the connectivity links between these nodes (for example in the form of a series of pairs including the identifier of the nodes and the characteristics of the connectivity links as described previously for the routing table). ;

[0112] The fields indicated above are given for illustrative purposes. Alternatively, the "RRER" error message may include other fields (in addition to or fewer than those indicated above). It should be noted, however, that the "errorLink" field described above is particularly advantageous within the context of the invention since it conveys information about the characteristics of the connectivity link to the node that has become unreachable.

[0113] All intermediate nodes traversed on the route between nodes B1 and C3, namely in this example nodes A2B2 and A1, relay the RERR error message issued by node B1 to signal the unavailability of node B4C4. According to the invention, before relaying the error message to the next node on the route, the traversed nodes extract from the error message the information reflecting the unavailability of node B4C4 (contained in the errorDeviceId, errorClusterId, and errorLink fields, among others) and take the opportunity to update their respective routing tables. This update consists of invalidating all routes that pass through node B4C4 in their routing tables; in other words, removing the routes passing through node B4C4 from their routing tables.In the variant where the routing tables only include route segments directly connecting two nodes, this update consists of removing from the routing tables the segments whose origin node or end node of the segment is the node that has become unreachable, i.e. here the B4C4 node.

[0114] In the embodiment described here, the nodes of ad hoc network 1 also update their routing tables based on routing information carried by data messages exchanged on ad hoc network 1 and destined for or passing through them. In another embodiment, when a master node of a cluster receives a control message such as an error message, it propagates it to the nodes of its cluster so that they can update their routing tables accordingly.

[0115] In the embodiment described here, the nodes of the ad hoc network 1 also update their routing tables from routing information carried by data messages exchanged on the ad hoc network 1 and destined for or passing through them.

[0116] As is known, once a route has been determined in an ad hoc network between a source node of a data message and a destination node, there are two commonly implemented strategies to ensure that the data message takes this route: The data message contains, for example in a header field, a list of the identifiers of all intermediate nodes along the route, as well as the characteristics of the connectivity links connecting these intermediate nodes (for example, as a list of pairs including the identifier of each intermediate node associated with the characteristics of the connectivity link to be used with that node). When an intermediate node receives the data message, it simply forwards it to the next node identified in the list via the specified connectivity link; or the data message contains, for example in a header field, only the identifier of the next intermediate node it must pass through. When an intermediate node receives the data message, it consults its routing table and determines the next node to which to send the message.

[0117] The first strategy has the advantage of reduced node transit time, as nodes do not need to consult their routing tables to relay the data message. However, the drawback is that if a route becomes invalid (for example, due to an intermediate node disconnecting), an RERR error message must be sent to the node that originated the data message so that it can choose a new route and signal this change by retransmitting the data message using the new route. Therefore, the first strategy is primarily useful when the nodes of the ad hoc network 1 are stable and the connectivity links between the nodes are not expected to change frequently over time.

[0118] The second strategy, on the other hand, allows an intermediate node that detects a connectivity problem on the route to change it in real time, and thus adapt to the new ad hoc network topology. However, the transit time for each intermediate node is longer than with the first strategy, because it must consult its routing table.

[0119] In the embodiment described here, the first strategy is assumed to be implemented by the nodes of ad hoc network 1 when sending data messages: each node originating a data message selects a route within ad hoc network 1 for that message, as detailed later, and signals it in its entirety in the data message header. It should be noted that the invention, by advocating the selection of a route that maximizes the stability of the intermediate nodes and the connectivity links connecting these nodes, improves the efficiency of the first strategy.

[0120] As mentioned previously, the nodes of ad hoc network 1 also update their respective routing tables here using routing information carried by data messages exchanged on ad hoc network 1 and destined for or passing through them. Indeed, in the embodiment described here, each data message contains in its header a list of intermediate nodes along the route chosen by the node that originated the data message, as well as the connectivity link type of each segment used. The data message also contains information about the origin and / or destination node of the message. The intermediate nodes used by the data message can therefore advantageously use this information to refresh their routing tables.

[0121] Typically, intermediate nodes can use routing information contained in data messages passing through them to discover the existence of new nodes within the network and the routes to reach these new nodes, thus extending their knowledge of the elements of the ad hoc network 1. But they can also update their routing tables with additional information to assess the stability of routes and / or their activities (for example, by storing in their routing tables additional information characterizing the routes or listed segments, such as a parameter corresponding to the last use of a route or by updating a lifetime parameter characterizing the time since a route has existed.Intermediate nodes can also remove routes that have become invalid from their routing tables when they forward an error message issued in response to a data message.

[0122] Note that in the embodiment described here, each node N of the ad hoc network 1 maintains a single routing table RT(N) referencing all the network nodes it knows. Alternatively, each node can manage multiple routing tables, for example, one routing table for the nodes in its cluster and another routing table for nodes outside its cluster.

[0123] We will now describe, with reference to the figure 4 ,the main steps implemented by a so-called origin node, referenced by N-ORIG, to select a route in the ad hoc network 1 when it wishes to exchange data with a so-called destination node, referenced by N-DEST, belonging to the ad hoc network 1. These steps are the steps of a selection process according to the invention as implemented by the maintenance module 7, identification module 8, determination module 9 and selection module 10 of the origin node N-ORIG in accordance with the invention.

[0124] We therefore assume here that a node of the ad hoc network 1 N-ORIG, for example node N-ORIG=A2B2, wishes to send a data message to a destination node N-DEST of the ad hoc network 1, for example node N-DEST=D1 (step E10). To this end, it consults, via its identification module 8, its routing table RT(N-ORIG), an example of which for node A2B2 is illustrated in the figure 3 (test step E20), to determine if it contains one or more routes allowing it to reach the destination node N-DEST.

[0125] As mentioned previously, the nodes of ad hoc network 1, and in particular node N-ORIG, are configured to keep their respective routing tables up to date using information retrieved from control messages and data messages passing through them or destined for them. At any time, if these tables do not contain the routes required to reach a destination node with which they wish to exchange data, they can complete them by sending a route discovery message (RREQ request) as described previously. These various updates constitute a maintenance step within the meaning of the invention (step E00), implemented by the maintenance module 7 of each node of ad hoc network 1.It is clear that updates to a node's routing table are not necessarily correlated with the sending of a data message by that node, but can be carried out asynchronously based on control and data messages circulating within the ad hoc network 1 and passing through the node in question; however, an update to a node's routing table can be triggered in relation to the sending of a data message by that node to a destination node if the node does not contain in its routing table an identified route allowing it to reach the destination node (no response to test step E20).

[0126] In the example of the RT(N-ORIG=A2B2) routing table of the N-ORIG=A2B2 node given to the figure 3 , there are two available (i.e., active) routes identified in the table that allow reaching the destination node D1 (yes answer in step E20): a first route R1 passes through nodes B1 and B3D3, before arriving at the destination node D1; a second route R2 passes through nodes B1, B4C4, C1D4 and D2 before arriving at the destination node D1.

[0127] Consulting its routing table RT(N-ORIG) allows the origin node N-ORIG, and more specifically its identification module 8, to identify X routes R1,...,RX available to reach the destination node N-DEST (X denoting an integer greater than or equal to 1), with X=2 in the example of the figure 3 , the two identified routes being the aforementioned R1 and R2 routes (step E30).

[0128] If only one route R1 is identified (X=1, answer yes in test step E40), the N-ORIG node indicates in the header of the data message it wishes to send to the destination node N-DEST the route thus identified, R1, and sends its data message via this route to the destination node N-DEST (step E50), in a manner known per se and not described in detail here. The data message is relayed by the intermediate nodes of the route as mentioned previously, until it reaches the destination node N-DEST. Each intermediate node updates its routing table, if necessary, based on the routing information indicated by the origin node N-ORIG in the data message header.

[0129] If several available routes R1,...,RX have been identified by the identification module 8 in the routing table RT(N-ORIG=A2B2) (i.e. X>1, no response to test step E40), according to the invention the node N-ORIG, via its determination module 9 and its selection module 10, selects the most stable available route within the ad hoc network 1.

[0130] To this end, the N-ORIG node determination module 9 determines, for each available route Rx, x=1,...,X identified in the routing table, a route stability level noted STAB-LEV(Rx) reflecting here the stability level of the nodes of this route and the connectivity links connecting these nodes together (step E60).

[0131] In the embodiment described here, to determine the STAB-LEV(Rx) stability level, a local stability score was first assigned to each possible connectivity link type. In the example considered here, this local stability score is lower the more stable the connectivity link is considered. This convention is, of course, not restrictive, and the reverse convention can be used.

[0132] More specifically, in the embodiment described here, the local stability score assigned to a wired connectivity link is lower than the local stability score assigned to a wireless connectivity link: the local stability score of a wired connectivity link, according to the adopted convention, is therefore better than the local stability score of a wireless connectivity link. For example, by way of illustration, consider the following local stability scores assigned to the different connectivity links that could be used in ad hoc network 1: Wired connectivity links: ∘ local score of 1 for an optical link, ∘ local score of 2 for an Ethernet link, ∘ local score of 3 for an xDSL (Digital Subscriber Line) link, etc.; Wireless connectivity links: ∘ local score of 10 for a link using a mobile network (2G, 3G, 4G, etc.), ∘ local score of 11 for an LTE Direct link, ∘ local score of 20 for a WiFi link, ∘ local score of 21 for a WiFi Direct link, ∘ local score of 30 for a Bluetooth link, etc.

[0133] Of course, this example is only given for illustrative purposes. It should be noted that the local stability score can also depend on a theoretical throughput associated with the connectivity link and achievable on that link. For this purpose, different throughput ranges can be defined, for example, a DR1 range from 0 to 1 Mbps, a DR2 range from 1 to 30 Mbps, a DR3 range from 30 to 100 Mbps, and a DR4 range for throughputs greater than 100 Mbps. A local score can be associated with each of these ranges (for example, the higher the throughput on a link, the lower the associated score), which is added to the local stability score associated with the different types of connectivity links mentioned above to characterize the overall score of a connectivity link.

[0134] Similarly, a local stability score is associated with the degree of mobility of each node in the ad hoc network 1. For this purpose, a local stability score can be assigned in a binary fashion depending on whether the node is considered mobile or fixed, but greater granularity can be achieved by assigning, within each category (corresponding to a "fixed" degree of mobility or a "mobile" degree of mobility), local stability scores based on the type of node considered (e.g., whether it is a mobile phone, a router, a base station associated with a mobile network antenna, etc.). Fixed nodes are considered more stable than mobile nodes, and therefore a lower local stability score (i.e., better according to the adopted convention) is assigned to a fixed node compared to a mobile node. For example, by way of illustration: For fixed nodes, a local score between 1 and 3 is assigned according to the following distribution: ∘ a local score of 1 is assigned to a base station associated with a radio antenna of a mobile network, ∘ a local score of 2 is assigned to an operator's box, ∘ a local score of 3 is assigned to a terminal such as a desktop or laptop computer or a connected object such as an IoT (Internet of Things) object; for mobile nodes, a local score of 10 is assigned regardless of the nature of the node considered (smartphone, digital tablet, etc.).

[0135] Of course, this example is given for illustrative purposes only.

[0136] Based on the local stability scores assigned to the different link types and the different possible degrees of mobility of the nodes in the ad hoc network 1, the determination module 9 calculates an overall stability score for each available route Rx, x=1,...,X identified by the identification module 8. This overall stability score reflects the STAB-LEV(Rx) stability level of each route Rx. It is calculated here by summing the local stability scores assigned to the connectivity links of the route segments according to their type and to the nodes of this route according to their degree of mobility. Thus, in the example considered here of the two routes R1 and R2: STAB − LEV R 1 = 21 + 10 ︸ segment A 2 B 2 , B 1 + 21 + 10 ︸ segment B 1 , B 3 D 3 + 30 + 3 ︸ segment B 3 D 3 , D 1 let STAB-LEV(R1)=95, and: STAB − LEV R 2 = 21 + 10 ︸ segment A 2 B 2 , B 1 + 21 + 10 ︸ segment B 1 , B 4 C 4 + 11 + 1 ︸ segment B 4 C 4 , C 1 D 4 + 21 + 10 ︸ segment C 1 D 4 , D 2 + 30 + 3 ︸ segment D 2 , D 1 so STAB-LEV(R2)=138.

[0137] Alternatively, a weighted sum of local scores assigned to links and nodes can be considered with different weights from the unit (for example to distinguish the importance of link stability from that of nodes, etc.).

[0138] Once these two stability levels are calculated, the selection module 10 of node N-ORIG selects the route from among routes R1 and R2 exhibiting the best stability (i.e., the highest stability level), in other words, using the convention considered here, the one corresponding to the lowest calculated stability level (step E70). Therefore, it is route R1 that is selected by the selection module 10 to send the data message to the destination node N-DEST=D1.

[0139] The N-ORIG node indicates this route in its data message and sends it via its means of communication on the ad hoc network 1 to the D1 node, in a conventional and known way (step E80).

[0140] In the embodiment described here, route selection is performed to maximize its stability, and more specifically, the stability of its segments and nodes. In another embodiment, in addition to route stability, the selection module 10 also considers other factors when selecting the route on which to send data destined for node N-DEST; in particular, it may consider the type of data that node N-ORIG wishes to send to node N-DEST and the real-time constraints imposed by this type of data. These factors can be taken into account, for example, when calculating the stability level by assigning each route a score for its suitability to carry this type of data (intended to be added to the overall stability score calculated for the route). This additional suitability score can be set based on, for example: of the expected latency on the route compared to a minimum latency to be guaranteed for the data; of the throughput offered by the route; of the propagation time on the route compared to a maximum propagation time set for the data (an important constraint for real-time applications); of the presence on the route of a certain type of connectivity (for example, one may wish to favor a stable route not using Bluetooth connectivity).

[0141] These criteria are evaluated, for example, based on the characteristics of the connectivity links stored in each node's routing table. In any case, the aforementioned constraints are taken into account in addition to route stability; in other words, the most stable route is favored according to the invention, regardless of any additional constraints.

Claims

1. Method for selecting a route in an ad hoc network (1) which is intended to be implemented by a first node of this network, said selection method comprising: - a step (E00) of keeping a routing table containing at least one available route within the ad hoc network up to date, said at least one route comprising at least one route segment directly linking two nodes of the ad hoc network together by means of a connectivity link, a type of which is identified in the routing table, said type relating to a connectivity interface existing between said two nodes, said routing table further comprising, for at least one linked node which is different from said first node, an indication relating to a degree of mobility of said linked node, the routing table being kept up to date on the basis of information extracted from control messages transmitted over the ad hoc network (1) which are intended for the first node and from control messages transmitted over the network passing through the first node; - when a data message is sent (E10) by the first node (N-ORIG) to a second node (N-DEST) of the ad hoc network: ∘ a step (E30) of identifying, using the routing table, at least one available route between the first node and the second node for sending the data message; and ∘ if several available routes are identified (E40): ▪ a step (E60) of determining stability levels of said identified available routes, on the basis of indications relating to the degree of mobility of the nodes of said routes and the type of connectivity links of the segments of the routes contained in the routing table; and ▪ a step (E70) of selecting one of the identified available routes depending on said determined stability levels.

2. Selection method according to Claim 1, further comprising: - a step of assigning a stability score referred to as local to at least one type of connectivity link and to at least one type of degree of mobility which are likely to be contained in the routing table; and - a step (E60) of calculating a stability score referred to as global for at least one identified available route reflecting the stability level of this route, this global stability score being calculated on the basis of a weighted sum of the local stability scores which are assigned to the connectivity links of the segments of this route depending on their type and to the nodes of this route depending on the indications relating to their degree of mobility which are contained in the table.

3. Selection method according to Claim 2, wherein, during the assignment step: - the local stability score assigned to a wired connectivity link is better than the local stability score assigned to a wireless connectivity link; and / or - the local stability score assigned to a fixed degree of mobility is better than the local stability score assigned to a mobile degree of mobility.

4. Selection method according to Claim 2 or 3, wherein the local stability score assigned to a type of connectivity link depends on a connectivity interface used over this link and / or on a theoretical throughput which can be achieved over this type of link.

5. Selection method according to any one of Claims 1 to 4, wherein, during the selection step (E80), the route is selected further taking into account: - a type of data carried by the message; and / or - a constraint in terms of propagation time, latency and / or throughput between the first node and the second node; and / or - an absence or a presence of at least one type of connectivity link for the segments of the route.

6. Selection method according to any one of Claims 1 to 5, wherein the control messages on the basis of which the routing table is kept up to date are control messages of a reactive routing protocol comprising announcement messages, route discovery messages, response messages in response to the discovery messages and error messages indicating that a node or link of the ad hoc network is unavailable.

7. Selection method according to any one of Claims 1 to 6, wherein, during the keeping up to date step (E00), the routing table is further kept up to date on the basis of routing information extracted from data messages transmitted over the ad hoc network which are intended for the first node and / or from data messages transmitted over the network passing through the first node.

8. Selection method according to any one of Claims 1 to 7, wherein: - the ad hoc network (1) is organized in clusters (A,B,C,D); - the routing table also comprises, for said at least one node which is different from the first node belonging to a said route segment, an identifier of at least one cluster of the ad hoc network to which this node belongs; - the first node uses a reactive routing protocol to transmit route discovery messages to nodes not belonging to a cluster to which it belongs.

9. Computer program (PROG) comprising instructions for executing the steps of the routing method according to any one of Claims 1 to 8 when said program is executed by a computer.

10. Computer-readable storage medium (3) on which a computer program (PROG) according to Claim 9 is stored.

11. Node (N-ORIG) of an ad hoc network, referred to as the "first node", comprising: - a module (7) for keeping a routing table containing at least one available route within the ad hoc network up to date, said route comprising at least one route segment directly linking two nodes of the ad hoc network together by means of a connectivity link, a type of which is identified in the routing table, said type relating to a connectivity interface existing between said two nodes, said routing table further comprising, for at least one linked node which is different from said first node belonging to a said route segment, an indication relating to a degree of mobility of said linked node, the routing table being kept up to date on the basis of information extracted from control messages transmitted over the ad hoc network (1) which are intended for the first node and from control messages transmitted over the network passing through the first node; - modules (8,9,10) activated when a data message is sent by the first node to a second node (N-DEST) of the ad hoc network, and comprising: o an identification module (8), configured to identify at least one available route between the first node and the second node using the routing table kept up to date by the keeping up to date module; ∘ modules (9,10) activated if several available routes between the first node and the second node are identified by the identification module, these modules comprising a determination module (9) configured to determine, for said identified available routes, stability levels on the basis of indications relating to the degree of mobility of the nodes of said routes and the type of connectivity links of the segments of said routes contained in the routing table, and a selection module (10) configured to select one of said identified available routes depending on said determined stability levels.

12. Ad hoc communication network (1) comprising a plurality of nodes (N) according to Claim 11.

13. Ad hoc communication network (1) according to Claim 12, wherein the nodes are organized in a plurality of clusters (A,B,C,D), said nodes being configured to implement a proactive routing protocol within the clusters to which they respectively belong and a reactive routing protocol outside these clusters, each cluster comprising a node referred to as the master node designated for the cluster which is able to transmit control messages according to the reactive routing protocol to the master nodes of the other clusters, the designated master node for a cluster corresponding to the node among the nodes of the cluster that is the most stable in terms of connectivity and / or activity within the ad hoc network.