WO2023067267A1 - Methode de transmission de donnees dans un reseau maille et dispositif de communication dans un tel reseau - Google Patents

Methode de transmission de donnees dans un reseau maille et dispositif de communication dans un tel reseau Download PDF

Info

Publication number
WO2023067267A1
WO2023067267A1 PCT/FR2022/051935 FR2022051935W WO2023067267A1 WO 2023067267 A1 WO2023067267 A1 WO 2023067267A1 FR 2022051935 W FR2022051935 W FR 2022051935W WO 2023067267 A1 WO2023067267 A1 WO 2023067267A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
mesh network
data
request
node
Prior art date
Application number
PCT/FR2022/051935
Other languages
English (en)
Inventor
Bruno CRACCO
Christophe Bureau
Original Assignee
Dotdot
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dotdot filed Critical Dotdot
Publication of WO2023067267A1 publication Critical patent/WO2023067267A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

  • TITLE METHOD OF DATA TRANSMISSION IN A MAIEEE NETWORK AND COMMUNICATION DEVICE IN A NETWORK TEE
  • the present invention relates to a method for transmitting data in a mesh network.
  • the data transmitted may in particular include files or parts of files.
  • the invention also relates to a communication device participating in this mesh network.
  • wireless peer-to-peer mesh networks of mobile devices constituting autonomously have multiple applications.
  • vehicles it is possible to equip vehicles with mesh network functionalities, networks of such vehicles being then constituted according to the position of each vehicle, the range of the network interfaces and other factors.
  • the network or networks then evolve dynamically according to the movements of the vehicles.
  • this type of network has many advantages, its dynamic evolution also imposes constraints - mesh network devices can suddenly become unavailable because they are out of range, disconnected or in a place that does not allow the passage of radio waves. This instability can for example be troublesome when a device or network node has to retrieve a relatively large amount of data, for example from a server external to the mesh network.
  • the link between the node and the server whether direct or indirect through other nodes, can be cut.
  • the present invention aims to compensate for certain constraints due to the dynamic evolution of the network.
  • One embodiment relates to a method of transmitting data in a mesh network of communication devices, the method being implemented by a given device of the mesh network equipped with a processor, the method comprising: obtaining first data identifying a file), said first data being to be obtained from a source external to the mesh network and excluding the devices of the mesh network, said file being obtainable in the form of a plurality of parts, the whole of which makes it possible to form the complete file; obtaining second data identifying the parts forming the file from the external source or from another device of the mesh network; obtaining at least a portion of the file from the external source or another mesh network device; the storage, in a storage module of the given device, of the second data and of the file parts for transmission in the event of a request from another device of the mesh network, the mesh network being organized in the form of a tree structure according to which each device is connected to at most one parent device and may be connected to zero, one or more child devices, the method further comprising receiving (S901) a request from a device directly
  • the storage, by one or more devices of the mesh network, of the second information identifying the parts of a file to be loaded, as well as the parts of file identified by this second information, makes it possible to make this information available even when the external source is not is not accessible.
  • the obtaining of the second data or of the at least part of the file comprises the transmission of a request to the devices directly connected to the given device in the mesh network in the tree structure, said request identifying the second data or the at least one file part to be obtained.
  • the method comprises receiving responses from the devices to which the request has been sent, the responses including, where appropriate, the address of one or more devices of the mesh network having stored the second data or the least one part of the file to be obtained and to which the request will have been sent or at least partially propagated.
  • the method comprises the determination, among the device or devices whose address or addresses have been received, of a device from which the second data or the at least part of the file are to be obtained, the determination being based on a cost function taking into account the link or links on the path, in the tree structure, between the given device and each of the device or devices whose address or addresses have been received.
  • the cost function takes into account one or more of one or more signal levels on the link(s) on said path, the number of hops on said path, the nature of the link(s) on said path, one or more stability indicators for the link(s) on said path.
  • the cost function takes into account the combination of one or more signal levels on the connection(s) on said path and one or more stability indicators for the link(s) on said path.
  • the cost induced by a link between a device of the mesh network and the external source is taken to be greater than the cost induced by a link between two devices of the mesh network.
  • the method comprises, in the event of absence of the element sought in the storage of the given device, the propagation of the request to the devices directly connected to the given device in the tree structure outside the device whose request was initially received, and collecting responses from devices to which the request was propagated to return a response to the device from which the request was originally received.
  • the method comprises, if the given device is connected to said external source and does not have the element sought in its storage, the return of the address of said external source in the response.
  • the method comprises receiving, from the external source, register data of a chain of blocks maintained by said external source, said chain of blocks containing a block with the second and third data or blocks with respectively the second data and the third data, the register data being adapted to allow the verification, by the node, of the integrity of the second and third data, the third data comprising at least part of the file.
  • One embodiment relates to a communication device adapted to connect to a mesh network comprising other devices, said device comprising a mesh network interface, a local storage module and a processor configured to drive said communication device to put in work: obtaining first data identifying a file), said first data being to be obtained from a source external to the mesh network and excluding the devices of the mesh network, said file being obtainable in the form of a plurality of parts whose set makes it possible to form the complete file; obtaining second data identifying the parts forming the file from the external source or from another device of the mesh network; obtaining at least a portion of the file from the external source or another mesh network device; storing, in the storage module of the communication device, the second data and the file parts for transmission in the event of a request from another device of the mesh network and, the mesh network being organized in the form of a tree structure wherein each device is connected to at most one parent device and may be connected to zero, one or more child devices, receiving (S901) a request from a device directly connected to the given device
  • the communication device comprises: - A programmable application interface for transmitting the first data to a client device and for receiving from this client device a request for obtaining a file identified in the first data and for transmitting the identified file to the client device;
  • - a download client for downloading the plurality of file parts corresponding to the identified file, to form the complete identified file from the file parts.
  • a node can thus be used by one or more clients, for example several client devices carried by a vehicle which also carries the node.
  • the communication device comprises a memory comprising software code, the processor of the communication device causing said device to implement the steps of any of the above methods.
  • FIG. 1 is a diagram of an overview of a system comprising a mesh network and in which the method and the device according to a particular non-limiting example can be implemented;
  • FIG. 2 is a functional block diagram of a device according to a particular non-limiting example
  • FIG. 3 is a simplified diagram of a non-limiting example of a mesh network comprising a plurality of nodes
  • - Figure 4 is a first diagram illustrating the communication connections between a node of the mesh network and other devices for choosing a data source for the evaluation of a cost function
  • - Figure 5 is a second diagram illustrating the communication connections between a node of the mesh network and other devices for choosing a data source for the evaluation of a cost function
  • FIG. 6 is a diagram representing the content of a seed file and the partition of a file to be downloaded according to a non-limiting embodiment
  • FIG. 7 is a diagram representing the content of an instruction file according to a non-limiting embodiment:
  • FIG. 8 is a flowchart of certain steps of a method according to a non-limiting embodiment
  • FIG. 9 is a flowchart of certain steps of a method according to a non-limiting embodiment
  • FIG. 10 is a flowchart of certain steps according to a non-limiting example embodiment
  • processor used in the following may designate any circuit or any combination of circuits capable of implementing the functionalities described, in particular one or more microprocessors, microcontrollers or other circuits executing suitable software code, or even circuits dedicated to provide the features described.
  • a node of the mesh network is generally carried by a mobile device of the vehicle type.
  • other applications are not excluded, in particular for the transmission of data and in particular of files in the context of computing at the edge of the network ('Edge computing' in English).
  • a communication device 101 - also called 'node' in what follows - configured to operate as part of a mesh network communicates with a client application 102 of the vehicle carrying the node.
  • the link between the node 101 and an electronic control unit of the vehicle is a wired serial link, for example by implementing a serial peripheral interface ('SPI'), an asynchronous universal receiver link transmitter ('UART') or an I2C bus.
  • Other links can be envisaged, including wireless, in particular WiFi (registered trademark) or Bluetooth (registered trademark).
  • the vehicle control unit or units send requests to the node 101 and receive messages therefrom.
  • node 101 becomes part of a wireless mesh network 103.
  • the mesh network has a tree structure in which a node is elected root node (node 104 in the example of the figure 1).
  • the node 101 can if necessary also be the root node.
  • the root node 104 notably has the role of establishing communication between the mesh network 103 and a server 105, through another network 106.
  • the network 106 is the Internet.
  • the interface between the root node and the network 106 may depending on the implementation comprise a cellular network interface, for example 4G or 5G according to the standards maintained by 3GPP.
  • the root node communicates directly with a base station (not shown).
  • the connection between the root node (104) and the network 106 is established through a router which can be a WiFi access point.
  • the connection between the root node (104) and the network (106) can, if necessary, be wired (for example a wired Ethernet connection).
  • FIG. 2 is a functional block diagram of the node 101 and of an electronic control unit 200 of the vehicle, this unit comprising the client application 102, according to the present embodiment.
  • the node 101 comprises a programmable application interface 201, commonly designated by the acronym API, allowing the client application 102 to communicate with the node 101, and in particular to transmit requests to it from the electronic control unit 200, as well as sending data back to this unit.
  • This API interface supports in particular communication with the application or download client 202.
  • the node further comprises a wireless interface 203, a file server 204, an interrupt management module 205, a status module 206 , a mass memory 207, a processor 208, a program memory 213, as well as a working memory 214 of the processor 208.
  • Wireless interface 203 allows the node to interact with other nodes in the mesh network.
  • this interface is based on the IEEE 802.11 standard, an additional layer implementing the mesh network functionality.
  • this additional layer is for example based on the 'ESP-Wifi-Mesh' protocol described in the document "ESP32 - ESP-IDF Programming Guide” v4.4-dev-2825-gb63ec47 of Espressif Systems published on August 27, 2021. This protocol gives the possibility of using a node both as a station to connect to an access point (then considered as a parent node) and, if necessary, as a data point.
  • the protocol makes it possible to obtain a tree structure of the mesh network which goes back to a root node, elected among the nodes of the network according to certain predetermined criteria.
  • the role of the file server 204 is to manage the function of local storage of the files which the node 101 and/or the electronic control unit 200 need, but also to manage a cache function - for certain types of file - for access by other nodes in the mesh network.
  • the server therefore has access to the non-volatile mass memory 207, which can be implemented using a hard disk or other long-term storage medium.
  • the interrupt management module 205 is connected to the electronic control unit 200 of the vehicle - it is bidirectional and allows, without limitation, the latter to warn the node 101 of a request from the unit electronic control 200 of the vehicle or to perform a predetermined action. Through this interrupt management module, the electronic control unit 200 can notify the node 101 of the end of consideration of a file or even of a desire to transmit data.
  • the role of the status module 206 is to notify the client application 102 of the status of the node's connection to a mesh network (connected to a mesh network, not connected).
  • download client 202 and status and interrupt modules may be implemented through one or more suitable software whose code is stored in the program memory 213 of the processor 208.
  • the processor 208 manages all the functions of the node on the basis of one or more software programs whose code is stored in the program memory 213 of the processor 208.
  • the electronic control unit 200 comprises, as already indicated, a client application 102 of the vehicle. It further comprises an electronic control unit system 209, which comprises a program memory 210, a processor 211, a working memory 212 of the processor 211, as well as a mass memory 215.
  • the program memory 210 contains, among other things, the firmware of the unit 200.
  • the processor 211 manages all the functions of the unit via appropriate software stored in the memory 210 or on another storage medium not illustrated - this processor notably executes the code of the client application 102. Other components necessary for the execution of the functions of the electronic control unit are not illustrated.
  • the Electronic Control Unit 200 has a unique identifier, called the Vehicle Identification Number or ‘VIN’.
  • the mass memory 215 makes it possible in particular to store the downloaded files.
  • FIG. 3 An example of a mesh network configuration 103 on the basis of which certain rules of behavior of this network will be explained is illustrated by FIG. 3.
  • the network comprises seven nodes numbered 301 to 307.
  • Element 300 represents the access point of the network 106 - a cellular base station for example.
  • a node has at most one parent node and zero, one or more child nodes.
  • a node has at most one parent node and zero or more child nodes.
  • the number of child nodes is limited.
  • a node is elected root node (node 301 in FIG. 3) - it is for example the node having the best signal level with an access point to a network of the type of network 106.
  • the rank of a node is the number of nodes on the path to the root node incremented by 1.
  • node 301 which in the example of Figure 3 is the root node, has rank 0.
  • the node 307 has for example rank 2.
  • the maximum number of ranks in the network can be limited.
  • a new node chooses as parent node the node which gives the lowest rank and if there are several possible choices according to this criterion, the node giving the best signal level.
  • the child nodes, grandchildren... of the disappeared node will apply the previous step performed by a new node.
  • Each node also knows which is its parent node and which are its child nodes, whatever their generation (children, grandchildren, etc.).
  • the mesh network therefore comprises two types of nodes, the first type communicating only through the wireless mesh network and capable of serving as a relay between two other nodes of this network, the second type, also called gateway, having the network functionality mesh wireless, but also the functionality of communication with an external network, for example of the cellular type.
  • the second type is equipped with a physical or electronic SIM card issued by a cellular network operator.
  • a node of the second type can see its communication functionality with the cellular network deactivated if it is not elected root node and then becomes a node of the first type.
  • Each node also has a medium access control address ('MAC' address).
  • nodes Since the nodes are in principle mobile, a given node can be disconnected at any time from the rest of the mesh network, or see its parent or one of its children disappear. Some nodes can remain in the same mesh network for quite a long time, especially when carried by vehicles parked in a parking lot.
  • the server 105 has the role of updating data from the electronic control units in the mesh network.
  • the data to be updated may include one or more files present in the control units, such as the firmware of these units, but the data is not limited to this context and may extend to database updates (e.g. geolocation maps) or applications or other type of data.
  • database updates e.g. geolocation maps
  • the server has several types of information:
  • a first type of information comprises at least one or more identifiers of the file or files that a control unit must download.
  • An indication for determining the validity of the first type of information is included.
  • this information is an electronic signature of the content by private key issued by the server 105, present in the header of the file and verified by the node by means of the public key which it holds in its program memory. .
  • this indication is an expiry date beyond which information of the first type is no longer considered valid.
  • the first type of information takes the form of an instruction file comprising information identifying information of the second type described below, this information making it possible, according to a non-limiting exemplary embodiment, to obtain the downloading one or more files, called 'seed' files.
  • Figure 7 is an example of an instruction file 700 according to a non-limiting embodiment.
  • This file comprises a header 701 (which according to the variant embodiment mentioned above includes the electronic signature by private key) as well as a list of one or more files (600, n, n-1, n-2 .. .) that a destination node should load.
  • the content of the file may differ from one control unit to another.
  • the first type of information also includes instructions 703 to be executed by the unit receiving this first type of information.
  • a second type of information comprises, for a file identified by the first type of information, the identification of the constituent parts of this file.
  • An example of such a file 600 is illustrated in Figure 6.
  • a file is divided into several parts (referenced 605 to 608, i.e. four parts in the example of Figure 6, without this being limiting) for easier transmission. Indeed, given the instability of the mesh network, the probability of transmitting parts of the file rather than the entire file is greater. Files of reasonable size given the transmission times in the mesh network are not divided into several parts.
  • a maximum size of a file or part of a file can be set. Parts of a file can be downloaded separately by a node. According to a non-limiting exemplary embodiment, it is not necessary for any order to be respected in the transmission of the different file parts.
  • the division into parts is carried out by the server, which also prepares the second type of information.
  • the second type of information can also take the form of a file, called “seed file” 601 in the following, and which comprises a header 602 as well as a section 603 listing the references 605 to 608 of all the parts needed to reconstruct the 600 file.
  • the seed file includes the data indicated in table 1:
  • the information of the second type may differ from the content of the file given as an example.
  • some information is not necessarily essential (identification of the author for example).
  • the function of some information can be fulfilled by other information.
  • the signature by private key allows each node to verify that the information of the second and of the third type has not been altered by mistake or intentionally thanks to the public key held by all the nodes in a secure part of their non-volatile memory.
  • a semi-closed (or also called “consortium”) block chain mechanism insofar as the blocks are mined by the server 105, is implemented.
  • the server 105 adds to the chain of blocks (the register) a new block containing the second and third type information then validates the block by a proof of work (mining).
  • the nodes obtain from the server 105, at the same time as the information of the first type, the register.
  • a node ensures that it is indeed in possession of the most recent version of the information of the second type and of the third type, whatever the source (other node of the mesh network).
  • the data of the second and of the third type are contained in distinct blocks.
  • the obsolescence date can also be replaced by other information allowing the validity of the file to be determined, for example it can be implicit (and in this case this information is not sent explicitly) or even be indicated in the form of a period of validity. There validity can also be indicated in the form of one or more conditions to be met other than those linked to time or date.
  • the default behavior of a node is that it will store the seed file on its mass memory 207 accessible by its file server 204 if it has requested the downloading of this file for the unit of electronic control with which it is associated, and that it does not store it in the opposite case (for example when the node serves only as a relay for the transmission of the file to another node).
  • the seed file 601 comprises additional information in the form of instructions 604 to the node or nodes through which the file passes, for example relating to the storage of data by the local file server 204 of the node(s) and in particular to deviate from the default behavior.
  • this additional information includes an instruction not to store the seed file in the mass memory 207 of the local file server 204.
  • This instruction can be sent for example when the content of the seed file is sensitive and that its accessibility by nodes other than a specific destination node must be controlled.
  • the destination node transmits the file received (after reconstitution of the file 600 on the basis of the downloaded parts, i.e. 605 to 608 according to the non-limiting example of FIG. 6) to the electronic control unit 200 but does not keep it in memory beyond this use.
  • the additional information comprises an instruction 604 to store the seed file 601 as well as the parts of the file constituting the file 600 associated with the seed file 601.
  • a node will store the seed file 601, as well only the parts of the associated file 600, even if he is not among the final recipient(s), for example if he sees the file as a relay node.
  • This option can be implemented for example for a seed file 601 and an associated file 600 in high demand or potentially in high demand, with the aim of increasing the number of nurse nodes which will be able to provide the related data in the event of a request from other knots.
  • a node erases a seed file and the files relating thereto (600 and 605 to 608 in the non-limiting example according to the non-limiting example of FIG. 6) stored by its file server once that the file will no longer be valid.
  • the list of parts of the file includes the respective unique identifiers of these parts.
  • a requesting node will include a part's unique identifier in a download request for that part.
  • a third type of information comprises the file parts themselves (605 to 608 in the non-limiting example of Figure 6).
  • the file parts are binary files.
  • the server also transmits a fourth type of information intended for the complete or partial cleaning of the file servers of a node.
  • This fourth type of information can also take the form of a file transmitted when a node connects and include instructions to delete one or more specific files or all data stored locally in the node.
  • the steps when activating a new node are as follows:
  • a new node referred to as the original node in the following, becomes active.
  • the origin node transmits a message to its parent node, this message going up the tree to the root node - the latter transmits it to the server if the root node is in communication with the server.
  • the message contains a unique identifier that can be authenticated by the server and allows it to identify both the originating node and the electronic control unit associated with the originating node.
  • the unique identifier is the VIN identifier of the electronic control unit of the vehicle associated with the originating node or the MAC address of the originating node or the combination of the VIN identifier and the MAC address.
  • the unique identifier is sent in the form of a hash.
  • the message also contains information enabling the server to determine whether an instruction file 700 should be sent to the electronic control unit of the original node.
  • This information is for example the indication of validity of an instruction file previously received by the originating node, or an indication that no instruction file is available at the level of the control unit of the node of origin.
  • an instruction file is transmitted by the server to the originating node, either directly if the originating node is the root node, or through the mesh network if the originating node is not is not the root node).
  • an electronic control unit monitors the validity of the instruction file that it stores. When the file is no longer valid, for example when the expiration date has passed, the vehicle client application launches a request to the node associated with the vehicle to request a new instruction file from the server.
  • the second type of information is then downloaded by the originating node.
  • the instruction file may relate to a plurality of files.
  • the download client 202 of the node transmits the instruction file 700 to the electronic control unit 200.
  • the download client proceeds to download the seed file 601 and then automatically proceeds to download the individual file parts (605 to 608 in the non-limiting example) based on the content of the seed file 601.
  • the download client verifies the integrity of the downloaded parts, assembles the complete file 600, verifies its integrity and informs the electronic control unit 200 through the interrupt management module.
  • the complete 600 file can then be transmitted to the electronic control unit.
  • the download module implements the additional instructions that may be contained in the seed file. From the point of view of the electronic control unit 200, the latter receives the instruction file 700 and can deduce therefrom, if necessary, the file or files 600 to be obtained.
  • the download client 202 proceeds as follows:
  • the download client 102 initiates the download and puts the request from the electronic control unit on hold until the availability of the complete file. o If the file is being downloaded but is not yet complete, the download client continues the download and puts the request from the electronic control unit on hold until the complete file is available.
  • a node when a node receives a request for a file from the electronic control unit, it returns data relating to the download status.
  • this data comprises at least one of an indication whether the file download is in progress and a download progress rate.
  • This last piece of data can simply consist of a ratio between the number of games already downloaded compared to the total number of games in the file.
  • the procedure for downloading the different types of information and parts of files within the framework of a mesh network will now be described.
  • the first type of information or instruction file is only available from the server 105 and is not stored in a distributed manner in the network.
  • a node requesting a download has a queue of files and/or file parts waiting to be downloaded. This queue is filled in particular on the basis of requests from the electronic control unit. This queue is not necessarily empty when connecting to the mesh network because the node may have been disconnected previously from the same mesh network or from another mesh network. If necessary, it can be filled as and when requested by the electronic control unit.
  • the requesting node transmits a request for an element such as a part of a file or an entire file (for example concerning the seed file) to its parent node and to its child nodes.
  • the queue is used to feed requests.
  • a request can relate to several file parts or files, but for reasons of clarity, the case of a single file part will be considered first.
  • a request makes it possible to determine whether a node in the network has the element in its local storage and to obtain the address of this node. It should be noted that when it launches a request, the node ignores the address(es) of the node(s) which will be able to provide it with the requested data.
  • a node receiving a request (whether from an initial requesting node or an intermediate node) and possessing the requested part of the file will inform the node having transmitted the request, including its own address, and stop propagating the request;
  • a node receiving a request (whether from an initial requesting node or an intermediate node) and not possessing the requested part of the file will propagate the request to its direct neighbors (parent, children).
  • Step by step the whole network can thus be reached - but the request is stopped in its propagation in a branch by a node which owns the file part.
  • the initial requesting node will therefore not necessarily have available an exhaustive list of nodes possessing the file, but will at least have a list of the closest nodes.
  • the server is considered a parent node in this process, although not part of the mesh network as such.
  • the addresses of the nodes possessing the file, called source nodes, are sent back to the initial requesting node through the intermediate nodes.
  • the initial requesting node chooses one of the source nodes to request the download by sending a message to it to this effect through the nearest node on the way to the chosen source node, message which is transmitted from node to node on this way .
  • the choice can be made for example by evaluating a cost function, or according to another criterion.
  • the initial requesting node sends a download request to that source node - the source node then initiates transmission of the item through the mesh network. If the source node and the initial requesting node are not in direct connection, the data packets corresponding to this element are transmitted step by step by the intermediate node or nodes.
  • a node which does not possess the part of the file requested in a request and which receives no positive response in this sense from its own sub-network sends negative information back to the node which propagated the request to it.
  • 'sub-network we mean all the part of the mesh network which is directly or indirectly connected to the node having received the request, excluding the part of the network connected to the node from which the request originates.
  • the parent node informs the initial requesting node that the element concerned is being downloaded , optionally with an indication of the progress rate.
  • the initial requesting node transmits a new request for this element after a waiting time, which is for example a fixed time (for example a few tens of seconds) or a randomly chosen time.
  • the response from a node may contain distinct responses for each of the elements, and in the case of several positive responses, as many addresses of source nodes.
  • the response from a node may contain distinct responses for each of the elements, and in the case of several positive responses, as many addresses of source nodes.
  • a request received by a node concerns several elements and this node only has part of the requested elements, it propagates only the part of the request concerning the element or elements for which it cannot give a positive response. It then concatenates all the responses received, including its own, into a single response which will be transmitted to the node from which it received the request.
  • the initial requesting node in order to allow the initial requesting node to receive all the addresses of the potential source nodes given that the various requests and responses must have time to propagate through the mesh network, the initial requesting node provides a waiting time after receiving a first positive response before choosing a source node.
  • This waiting time which can be modified by setting the node, can be, for example, a few seconds.
  • the request from the initial requesting node contains the IP address of this node, so that a node indirectly receiving the request via an intermediate node can respond directly to the initial requesting node with a message using this IP address as address. RECIPIENT. There is then no concatenation of the response by the intermediate node. It also assumes that this IP address is contained in requests propagated beyond nodes directly connected to the original requesting node.
  • the evaluation of a cost function of a download (of type of information, of file or of file part) is implemented to choose one among several source nodes to download a given element .
  • the cost function tends to favor a node of the mesh network as source rather than a server external to the mesh network, without however excluding this server.
  • the cost function takes into account: (a) The signal level (given by the RSSI, which is a negative value in dBm between 0 and -255) between two nodes
  • connection for example, cellular or non-cellular
  • the RSSI is the signal level between the Wifi client (the station part of a child node) and the Wifi access point (the Access Point part of a parent node).
  • Each link has its own RSSI.
  • the overall RSSI of a path between the requesting node and the potential supplier node of the element to be downloaded is the sum of these RSSIs.
  • We practice, to evaluate the cost of the link we will take the value 255 subtracted from the RSSI because the higher the signal level, the higher the RSSI (close to 0).
  • the values of the RSSI of the links between the requesting node and the provider node are conveyed in the positive response message from the provider node to the request to provide the file.
  • the response message contains two digital registers: RSSI and STABILITY, initialized by the supplier node to 0 and 1 respectively.
  • the supplier node transmits this message to the node which transmitted the file request to it.
  • the latter increments the RSSI register of the message with the value 255 subtracted from the value of the RSSI between itself and the supplier node and produces the product of the value of the STABILITY register with the value of the stability of the link between itself and the the provider node.
  • it transmits this message to the node which had transmitted to it the request which it had itself transmitted to the supplier node.
  • the process repeats until the message reaches the requesting node.
  • the latter performs the same operations then calculates the total cost of the path between itself and the supplier node by dividing the value of the RSSI register by that of the STABILITY register.
  • Table 2 illustrates the successive values taken by the RSSI and STABILITY registers as the message progresses through the network. [Table 2]
  • the cost of the path between the provider node (n) and the requester node (0) is:
  • a cost value of the link between the server 105 and the root node is provided by the latter to the other nodes of the mesh network.
  • the stability of the network is also taken into account in the form of a value between 0 and 1, where 1 represents maximum stability.
  • the stability of several consecutive connections is obtained by the product of the stabilities of each connection between the requesting node and the source node, and an evaluation of the signal power between these two nodes is compensated by dividing this power evaluation by the product of the stabilities .
  • the stability of an individual connection is a function of one or more criteria from among the connection time observed over a given period, the time of day, the stability of the neighborhood in the mesh network and other measurable criteria depending indirectly on the movements of the node.
  • FIG. 4 shows an example of a simple mesh network comprising server 400 and nodes 401-404.
  • Source 401 and node 404 are potential sources for data requested by requesting node 402.
  • Node 401 is the root node and the nodes 402, 403 and 404 are nodes of respective ranks 1, 2, 3.
  • An RSSI value is associated with each connection among the nodes. This RSSI value is denoted ‘RSSI x-y’ where x indicates the rank of a first node and y indicates the rank of a second node connected to the first node, with x ⁇ y.
  • the cost function evaluated for the two potential sources can then be of the form:
  • CostSourcel (255 - “RSSI 2-3”) + (255 - “RSSI 1-2”)
  • Source2Cost (255 - “RSSI 0-1”) + TELCO
  • ‘TELCO’ is a cost associated with the access network to which the root node is connected.
  • the cost associated with the TELCO link is the maximum cost of a link in the mesh network, i.e. -255.
  • Figure 5 is a costed example of a network and the cost assessment taking into account the stability of each connection.
  • server 500 and nodes 501-504 are respectively connected similarly to server 400 and nodes 401-404 of Figure 4.
  • Node 502 further has a child 505 and a small -son 506. The figure gives the values of the different criteria taken into account in the cost function.
  • Node 506 is the lowest cost source node. Note that as a source, the server has an average cost, in particular thanks to the significant stability value associated with the connection with the root node.
  • Figure 8 is a flowchart illustrating some of the steps according to one of the embodiments previously described and implemented at a node.
  • a first step S801 includes obtaining first data identifying a file to be obtained.
  • a second step S802 includes obtaining second data identifying a plurality of parts of the file to be obtained.
  • a third step S803 includes storing the second data locally.
  • a fourth step S805 includes obtaining at least part of the file.
  • a fifth step includes storing the at least one part obtained locally.
  • the node can then serve as a source for the second information and/or the part or parts of the file stored locally. It should be noted that the node can of course serve as a source for the second information without parts of the file already being stored locally.
  • FIG. 9 is a flowchart illustrating some of the steps according to one of the embodiments previously described and implemented at the level of a node.
  • a first step S901 comprises the reception, at the level of a given node, of a request from another node of the mesh network to verify the presence of an element in the local storage of the given node.
  • the given node verifies the presence of the element in its local storage (step S902). If the element is present, the given node identifies itself as the source node and transmits a positive response to the node having sent the request in a step S903.
  • the given node specifies an identifier such as an address which will allow another node receiving this identifier to contact it.
  • the request is propagated, according to a step S904, to the nodes in direct connection with the given node, with the exception of the node having sent the request.
  • the given node then waits for responses from the nodes to which the request has been propagated. If a positive response is received with an identification of a source node, which is tested in step S905, then the given node transmits this identification to the node that sent the request in step S907.
  • the source node can be one of the nodes in direct connection with the given node, or another node to which the request will have been propagated elsewhere, or the server. Several source nodes can identify themselves and their identification transmitted. If no positive response is received, the given node transmits a negative response to the node having sent the request, according to a step S906.
  • FIG. 10 is a flowchart illustrating some of the steps according to one of the embodiments previously described and implemented at the level of a node.
  • a given node transmits, to the nodes in direct connection, a request to verify the presence of an element to be downloaded. If at least one identifier of a source node is obtained in return (positive test at step S1002), then a selection of a source node is made during a step S1003, a request for transmission of the element is sent to the selected source node in step S1004, and the item is received and stored locally in step S1005. If no source node identifier is obtained, step S1001 is resumed if certain conditions are met (for example, and without limitation, such conditions may include one or more of: the mesh network is connected again to a server, the given node got a new child node, new nodes announced themselves in the mesh network).
  • Method according to E2 where obtaining the second data (601) or the at least part of the file (605 - 608) comprises the transmission (S 1001) of a request to the devices directly connected to the given device in the network meshed in the tree structure, said request identifying the second data or the at least one file part to be obtained.
  • Method according to E3, comprising the reception of responses from the devices to which the request has been sent, the responses including, where appropriate, the address of one or more devices of the mesh network having stored the second data or the at least one file part to obtain and to which the request will have been sent or at least partially propagated.
  • Method according to E4 comprising determining, among the device or devices from which the address or addresses have been received, a device from which the second data or the at least part of the file are to be obtained, the determination being based on a cost function taking into account the link or links on the path, in the tree structure, between the given device and each of the device or devices whose address or addresses have been received.
  • E6 Method according to E5, in which the cost function takes into account one or more of one or more signal levels on the link(s) on said path, the number of hops on said path, the nature of the link(s) on said path , one or more stability indicators for the link or links on said path.
  • E7 Method according to E6, in which the cost function takes into account the combination of one or more signal levels on the connection or connections on said path and one or more stability indicators for the link or connections on said path.
  • Method according to E2 comprising receiving (S901) a request from a device directly connected to the given device in the tree structure of the mesh network, said request identifying a searched item, and sending (S903) a positive response to the device whose request has been received if the element sought is one among the second data and the at least one file part stored by said given device, the positive response comprising an address of the given device.
  • Method according to E9 comprising, in the event of absence of the element sought in the storage of the given device, the propagation (S904) of the request to the devices directly connected to the given device in the tree structure outside the device whose request has was originally received, and collecting responses from devices to which the request was propagated to return (S906, S907) a response to the device from which the request was originally received.
  • a communication device adapted to connect to a mesh network comprising other devices, said device comprising a mesh network interface (203), a local storage module (207) and a processor (208) configured to drive said communication device to be implemented: obtaining (S801) first data (700) identifying a file (600) to be obtained from a source external (105) to the mesh network and excluding the devices of the mesh network, said file being obtainable in the form of a plurality of parts, the whole of which makes it possible to form the complete file; obtaining (S802) second data (601) identifying the parties (605-608) forming the file (600) from the external source or from another device of the mesh network; obtaining (S804) at least a portion of the file from the external source or from another device of the mesh network; storing (S803, S805), in the storage module (207) of the communication device, the second data and the file parts for transmission in the event of a request from another device of the mesh network.
  • a download client (202) for downloading the plurality of file parts corresponding to the identified file (600), to form the complete identified file from the file parts.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Il est décrit une méthode de transmission de données dans un réseau maillé (103) de dispositifs de communication (301-307), la méthode étant mise en œuvre par un dispositif donné (101) du réseau maillé muni d'un processeur (208). La méthode comprend; l'obtention (S801) de premières données (700) identifiant un fichier (600), lesdites premières données étant à obtenir d'une source externe (105) au réseau maillé et à l'exclusion des dispositifs du réseau maillé, ledit fichier étant obtenable sous la forme d'une pluralité de parties dont l'ensemble permet de former le fichier complet; l'obtention (S802) de secondes données (601) identifiant les parties (605-608) formant le fichier (600) à partir de la source externe ou d'un autre dispositif du réseau maillé; l'obtention (S804) d'au moins une partie du fichier à partir de la source externe ou d'un autre dispositif du réseau maillé; le stockage (S803, S805), dans un module de stockage (207) du dispositif donné, des secondes données et des parties de fichier pour transmission en cas de demande d'un autre dispositif du réseau maillé; le réseau maillé étant organisé sous la forme d'une structure arborescente selon laquelle chaque dispositif est connecté au plus à un dispositif parent et peut être connecté à zéro, un ou plusieurs dispositifs enfant, le procédé comportant en outre la réception (S901) d'une requête d'un dispositif directement connecté au dispositif donné dans l'arborescence du réseau maillé, ladite requête identifiant un élément recherché, et l'envoi (S903) d'une réponse positive au dispositif dont la requête a été reçue si l'élément recherché est l'un parmi les secondes données et l'au moins une partie de fichier stockées par ledit dispositif donné, la réponse positive comportant une adresse du dispositif donné. Un autre objet est un dispositif de communication mettant en œuvre la méthode.

Description

DESCRIPTION
TITRE : METHODE DE TRANSMISSION DE DONNEES DANS UN RESEAU MAIEEE ET DISPOSITIF DE COMMUNICATION DANS UN TEE RESEAU
Domaine technique de 1’invention
La présente invention concerne une méthode de transmission de données dans un réseau maillé. Les données transmises peuvent notamment comprendre des fichiers ou parties de fichiers. L’invention concerne également un dispositif de communication participant à ce réseau maillé.
Arrière-plan technique
Dans le cadre d’applications mobiles, les réseaux maillés pair-à-pair sans fil d’appareils mobiles se constituant de façon autonome ont de multiples applications. Il est notamment envisageable d’équiper des véhicules de fonctionnalités de réseau maillé, des réseaux de tels véhicules se constituant alors en fonction de la position de chaque véhicule, de la portée des interfaces réseau et d’autres facteurs. Le ou les réseaux évoluent alors de façon dynamique en fonction des déplacements des véhicules. Bien que ce type de réseau comporte de nombreux avantages, son évolution dynamique impose également des contraintes - des dispositifs du réseau maillé peuvent soudainement devenir indisponibles car hors de portée, débranchés ou encore dans un lieu ne permettant pas le passage des ondes radio. Cette instabilité peut par exemple être gênante lorsqu’il s’agit pour un dispositif ou nœud du réseau de récupérer une quantité relativement importante de données, par exemple à partir d’un serveur externe au réseau maillé. La liaison entre le nœud et le serveur, qu’elle soit directe ou indirecte à travers d’autres nœuds, peut être coupée. La présente invention vise à compenser certaines contraintes dues à l’évolution dynamique du réseau.
Résumé de l’invention Un mode de réalisation concerne une méthode de transmission de données dans un réseau maillé de dispositifs de communication, la méthode étant mise en œuvre par un dispositif donné du réseau maillé muni d’un processeur, la méthode comprenant: l’obtention de premières données identifiant un fichier ), lesdites premières données étant à obtenir d’une source externe au réseau maillé et à l’exclusion des dispositifs du réseau maillé, ledit fichier étant obtenable sous la forme d’une pluralité de parties dont l’ensemble permet de former le fichier complet ; l’obtention de secondes données identifiant les parties formant le fichier à partir de la source externe ou d’un autre dispositif du réseau maillé ; l’obtention d’au moins une partie du fichier à partir de la source externe ou d’un autre dispositif du réseau maillé ; le stockage, dans un module de stockage du dispositif donné, des secondes données et des parties de fichier pour transmission en cas de demande d’un autre dispositif du réseau maillé le réseau maillé étant organisé sous la forme d’une structure arborescente selon laquelle chaque dispositif est connecté au plus à un dispositif parent et peut être connecté à zéro, un ou plusieurs dispositifs enfant, le procédé comportant en outre la réception (S901) d’une requête d’un dispositif directement connecté au dispositif donné dans l’arborescence du réseau maillé, ladite requête identifiant un élément recherché, et l’envoi (S903) d’une réponse positive au dispositif dont la requête a été reçue si l’élément recherché est l’un parmi les secondes données et l’au moins une partie de fichier stockées par ledit dispositif donné, la réponse positive comportant une adresse du dispositif donné.
Le stockage, par un ou plusieurs dispositifs du réseau maillé, des secondes informations identifiant les parties d’un fichier à charger, ainsi que des parties de fichier identifiées par ces secondes informations, permet de rendre ces informations disponibles même quand la source externe n’est pas accessible.
Selon un mode de réalisation particulier l’obtention des secondes données ou de l’au moins une partie du fichier comprend la transmission d’une requête aux dispositifs directement connectés au dispositif donné dans le réseau maillé dans l’arborescence, ladite requête identifiant les secondes données ou l’au moins une partie de fichier à obtenir.
Selon un mode de réalisation particulier, la méthode comprend la réception de réponses des dispositifs auxquels la requête a été envoyée, les réponses comportant le cas échéant l’adresse d’un ou plusieurs dispositifs du réseau maillé ayant stocké les secondes données ou l’au moins une partie de fichier à obtenir et auxquels la requête aura été envoyée ou au moins partiellement propagée.
Selon un mode de réalisation particulier, la méthode comprend la détermination, parmi le ou les dispositifs dont la ou les adresses ont été reçues, d’un dispositif auprès duquel les secondes données ou l’au moins une partie du fichier sont à obtenir, la détermination étant basée sur une fonction de coût prenant en compte la ou les liaisons sur le chemin, dans la structure arborescente, entre le dispositif donné et chacun du ou des dispositifs dont la ou les adresses ont été reçues.
Selon un mode de réalisation particulier, la fonction de coût prend en compte un ou plusieurs parmi un ou des niveaux de signal sur la ou les liaisons sur ledit chemin, le nombre de sauts sur ledit chemin, la nature de la ou des liaisons sur ledit chemin, un ou des indicateurs de stabilité de la ou des liaisons sur ledit chemin.
Selon un mode de réalisation particulier, la fonction de coût prend en compte la combinaison d’un ou des niveaux de signal sur la ou les connexions sur ledit chemin et un ou des indicateurs de stabilité de la ou des liaisons sur ledit chemin.
Selon un mode de réalisation particulier, le coût induit par une liaison entre un dispositif du réseau maillé et la source externe est pris supérieur au coût induit par une liaison entre deux dispositifs du réseau maillé.
Selon un mode de réalisation particulier, la méthode comprend, en cas d’absence de l’élément recherché dans le stockage du dispositif donné, la propagation de la requête aux dispositifs directement connectés au dispositif donné dans l’arborescence en dehors du dispositif dont la requête a été initialement reçue, et la collecte des réponses des dispositifs auprès desquels la requête a été propagée pour renvoi d’une réponse au dispositif dont la requête a été initialement reçue.
Selon un mode de réalisation particulier, la méthode comprend, si le dispositif donné est connecté à ladite source externe et ne possède pas l’élément recherché dans son stockage, le renvoi de l’adresse de ladite source externe dans la réponse. Selon un mode de réalisation particulier, la méthode comprend la réception, à partir de la source externe, de données de registre d’une chaine de blocs maintenue par ladite source externe, ladite chaine de blocs contenant un bloc avec les secondes et troisièmes données ou des blocs avec respectivement les secondes données et les troisièmes données, les données de registre étant adaptées à permettre la vérification, par le nœud, de l’intégrité des secondes et troisièmes données, les troisièmes données comprenant au moins une partie du fichier. 1
Un mode de réalisation concerne un dispositif de communication adapté à se connecter à un réseau maillé comprenant d’autres dispositifs, ledit dispositif comprenant une interface de réseau maillé, un module de stockage local et un processeur configuré pour conduire ledit dispositif de communication à mettre en œuvre : l’obtention de premières données identifiant un fichier ), lesdites premières données étant à obtenir d’une source externe au réseau maillé et à l’exclusion des dispositifs du réseau maillé, ledit fichier étant obtenable sous la forme d’une pluralité de parties dont l’ensemble permet de former le fichier complet ; l’obtention de secondes données identifiant les parties formant le fichier à partir de la source externe ou d’un autre dispositif du réseau maillé ; l’obtention d’au moins une partie du fichier à partir de la source externe ou d’un autre dispositif du réseau maillé ; le stockage, dans le module de stockage du dispositif de communication, des secondes données et des parties de fichier pour transmission en cas de demande d’un autre dispositif du réseau maillé et, le réseau maillé étant organisé sous la forme d’une structure arborescente selon laquelle chaque dispositif est connecté au plus à un dispositif parent et peut être connecté à zéro, un ou plusieurs dispositifs enfant, la réception (S901) d’une requête d’un dispositif directement connecté au dispositif donné dans l’arborescence du réseau maillé, ladite requête identifiant un élément recherché, et l’envoi (S903) d’une réponse positive au dispositif dont la requête a été reçue si l’élément recherché est l’un parmi les secondes données et l’au moins une partie de fichier stockées par ledit dispositif donné, la réponse positive comportant une adresse du dispositif donné.
Selon un mode de réalisation particulier, le dispositif de communication comprend : - une interface programmable d’ application pour transmettre les premières données à un dispositif client et à recevoir de ce dispositif client une requête pour l’obtention d’un fichier identifié dans les premières données et pour transmettre le fichier identifié au dispositif client ;
- un client de téléchargement pour télécharger la pluralité de parties de fichier correspondant au fichier identifié, pour former le fichier identifié complet à partir des parties du fichier.
Un nœud peut ainsi être utilisé par un ou plusieurs clients, par exemple plusieurs dispositifs clients portés par un véhicule qui porte aussi le nœud.
Selon un mode de réalisation particulier, le dispositif de communication comprend une mémoire comportant du code logiciel, le processeur du dispositif de communication conduisant ledit dispositif à mettre en œuvre les étapes de l’une quelconque des méthodes ci-dessus.
Brève description des figures
D'autres caractéristiques et avantages de l'invention apparaitront au cours de la lecture de la description détaillée qui va suivre pour la compréhension de laquelle on se reportera aux dessins annexés pami lesquels :
- la figure 1 est un diagramme d’une vue d’ensemble d’un système comportant un réseau maillé et dans lequel la méthode et le dispositif selon un exemple particulier non limitatif peuvent être mis en œuvre ;
- la figure 2 est un diagramme bloc fonctionnel d’un dispositif selon un exemple particulier non-limitatif ;
- la figure 3 est un diagramme simplifié d’un exemple non-limitatif de réseau maillé comportant une pluralité de nœuds ;
- la figure 4 est un premier diagramme illustrant les connexions de communication entre un nœud du réseau maillé et d’autres appareils pour le choix d’une source de données en vue de l’évaluation d’une fonction de coût ; - la figure 5 est un second diagramme illustrant les connexions de communication entre un nœud du réseau maillé et d’autres appareils pour le choix d’une source de données en vue de l’évaluation d’une fonction de coût;
- la figure 6 est un diagramme représentant le contenu d’un fichier germe et la partition d’un fichier à télécharger selon un exemple de réalisation non limitatif ;
- la figure 7 est un diagramme représentant le contenu d’un fichier d’instructions selon un exemple de réalisation non limitatif :
- la figure 8 est un organigramme de certaines étapes d’une méthode selon un exemple de réalisation non limitatif ;
- la figure 9 est un organigramme de certaines étapes d’une méthode selon un exemple de réalisation non limitatif ;
[Fig. 10] - la figure 10 est un organigramme de certaines étapes selon un exemple de réalisation non limitatif
Description détaillée de l'invention
Dans la description qui va suivre, ainsi que dans les figures, des éléments identiques, similaires ou analogues seront désignés par les mêmes chiffres de référence.
Les fonctionnalités des éléments décrits à l’aide des figures peuvent être implémentées à l’aide d’un ou plusieurs logiciels exécutés par un ou plusieurs processeurs adaptés, par des circuits dédiés ou génériques, ou une combinaison de circuits et de logiciels.
Le terme processeur utilisé dans ce qui suit peut désigner tout circuit ou toute combinaison de circuits aptes à mettre en œuvre les fonctionnalités décrites, notamment un ou plusieurs microprocesseurs, microcontrôleurs ou d’autres circuits exécutant du code logiciel adapté, ou encore des circuits dédiés pour fournir les fonctionnalités décrites.
Les exemples de réalisation détaillés qui vont être décrits se placent dans le contexte où un nœud du réseau maillé est généralement porté par un dispositif mobile de type véhicule. D’autres applications ne sont cependant pas exclues, notamment pour la transmission de données et en particulier de fichiers dans le cadre d’informatique en périphérie de réseau (‘Edge computing’ en langue anglaise). Selon le présent exemple de réalisation et tel qu’illustré schématiquement par la figure 1, un dispositif de communication 101 - encore appelé ‘nœud’ dans ce qui suit - configuré pour fonctionner dans le cadre d’un réseau maillé communique avec une application client 102 du véhicule portant le nœud. Selon le présent exemple de réalisation, la liaison entre le nœud 101 et une unité de contrôle électronique du véhicule est une liaison série filaire, par exemple par mise en œuvre d’une interface périphérique série (‘SPI’), une liaison universelle asynchrone récepteur transmetteur (‘UART’) ou encore d’un bus I2C. D’autres liaisons peuvent être envisagées, y compris sans fil, notamment WiFi (marque déposée) ou Bluetooth (marque déposée). Comme il sera vu plus en détail plus loin, la ou les unités de contrôle du véhicule émettent des requêtes vers le nœud 101 et en reçoivent des messages. Lorsqu’il est à portée d’autres nœuds, le nœud 101 s’intégre dans un réseau maillé sans fil 103. Le réseau maillé possède une structure arborescente dans laquelle un nœud est élu nœud racine (le nœud 104 dans l’exemple de la figure 1). Le nœud 101 peut le cas échéant également être nœud racine. Le nœud racine 104 a notamment pour rôle d’établir une communication entre le réseau maillé 103 et un serveur 105, à travers un autre réseau 106. Selon un exemple de réalisation non limitatif le réseau 106 est l’internet. L’interface entre le nœud racine et le réseau 106 peut selon l’implémentation comprendre une interface de réseau cellulaire, par exemple 4G ou 5 G selon les normes maintenues par 3GPP. Le nœud racine communique directement avec une station de base (non-illustrée). Selon une variante de réalisation, la connexion entre le nœud racine (104) et le réseau 106 s’établit au travers d’un routeur qui peut être un point d’accès Wifi. Selon une autre variante de réalisation, la connexion entre le nœud racine (104) et le réseau (106) peut, le cas échéant, être filaire (par exemple une connexion filaire Ethernet).
Selon le présent exemple de réalisation, le transfert de données entre le nœud racine 104 et le serveur 105 se fait, sans que cela soit restrictif, par l’un ou plusieurs parmi les protocoles HTTP, HTTPS, FTP, FTPS ou UPD, au-dessus du protocole TCP/IP. Ees échanges peuvent être chiffrés, notamment lors de l’utilisation de HTTPS et FTPS, et un mécanisme d’authentification sur base de clés peut par ailleurs être mis en œuvre entre des appareils échangeant des données et/ou des fichiers. La figure 2 est un diagramme bloc fonctionnel du nœud 101 et d’une unité de contrôle électronique 200 du véhicule, cette unité comportant l’application client 102, selon le présent exemple de réalisation. Le nœud 101 comporte une interface programmable d’application 201, communément désignée par l’acronyme API, permettant à l’application client 102 de communiquer avec le nœud 101, et notamment de lui transmettre des requêtes en provenance de l’unité de contrôle électronique 200, ainsi que de renvoyer des données vers cette unité. Cette interface API supporte en particulier la communication avec l’application ou client de téléchargement 202. Le nœud comporte en outre une interface sans fil 203, un serveur de fichier 204, un module de gestion d’interruptions 205, un module d’état 206, une mémoire de masse 207, ’un processeur 208, une mémoire de programme 213, ainsi qu’une mémoire de travail 214 du processeur 208.
L’interface sans fil 203 permet au nœud d’interagir avec d’autres nœuds du réseau maillé. Selon le présent exemple de réalisation non-limitatif, cette interface est basée sur la norme IEEE 802.11, une couche supplémentaire implémentant la fonctionnalité de réseau maillé. Selon le présent exemple de réalisation non limitatif, cette couche supplémentaire est par exemple basée sur le protocole ‘ESP-Wifi-Mesh’ décrit dans le document « ESP32 - ESP-IDF Programming Guide » v4.4-dev-2825-gb63ec47 d’Espressif Systems publié le 27 août 2021. Ce protocole donne la possibilité d’utiliser un nœud à la fois en tant que station pour se connecter à un point d’accès (considéré alors comme nœud parent) et le cas échéant en tant que point d’accès pour établir une communication avec un ou plusieurs autres nœuds, (considérés quant à eux comme nœuds enfants). Le protocole permet d’obtenir une structure arborescente du réseau maillé qui remonte vers un nœud racine, élu parmi les nœuds du réseau selon certains critères prédéterminés. Quelques règles de base de fonctionnement de ce type de réseau maillé seront décrites plus loin.
Le rôle du serveur de fichiers 204 est de gérer la fonction de stockage local des fichiers dont le nœud 101 et /ou l’unité de contrôle électronique 200 ont besoin, mais aussi de gérer une fonction de cache - pour certains types de fichier - pour accès par d’autres nœuds du réseau maillé. Le serveur a pour cela accès à la mémoire de masse non volatile 207, qui peut être implémentée à l’aide d’un disque dur ou d’un autre support de stockage longue durée. Le module de gestion d’interruptions 205 est connecté à l’unité de contrôle électronique 200 du véhicule - il est bidirectionnel et permet, sans que cela soit limitatif, à cette dernière d’avertir le nœud 101 d’une requête de l’unité de contrôle électronique 200 du véhicule ou d’effectuer une action prédéterminée. Par ce module de gestion d’interruptions, l’unité de contrôle électronique 200 peut avertir le nœud 101 de la fin de prise en compte d’un fichier ou encore d’une volonté de transmettre des données. Le module d’état 206 a pour rôle d’avertir l’application client 102 de l’état de la connexion du nœud à un réseau maillé (connecté à un réseau maillé, non connecté).
Bien qu’illustrées de manière séparée en tant que fonctions du nœud 101, le client de téléchargement 202 et les modules d’état et d’interruption peuvent être implémentés par l’intermédiaire d’un ou plusieurs logiciels appropriés dont le code est stocké dans la mémoire de programme 213 du processeur 208. De manière générale, le processeur 208 gère l’ensemble des fonctions du noeud sur base d’un ou plusieurs programmes logiciels dont le code est stocké dans la mémoire de programme 213 du processeur 208.
L’unité de contrôle électronique 200 comporte, comme déjà indiqué, une application client 102 du véhicule. Elle comporte en outre un système d’unité de contrôle électronique 209, qui comporte une mémoire de programme 210, un processeur 211, une mémoire de travail 212 du processeur 211, ainsi qu’une mémoire de masse 215. Selon le présent exemple de réalisation, la mémoire de programme 210 contient entre autres le micrologiciel (‘firmware’ en anglais) de l’unité 200. Le processeur 211 gère l’ensemble des fonctions de l’unité par l’intermédiaire de logiciels appropriés stockés dans la mémoire 210 ou sur un autre support de stockage non illustré - ce processeur exécute notamment le code de l’application client 102. D’autres composantes nécessaires à l’exécution des fonctions de l’unité de contrôle électronique ne sont pas illustrées. L’unité de contrôle électronique 200 possède un identifiant unique, appelé numéro d’identification du véhicule ou ‘VIN’. La mémoire de masse 215 permet de stocker notamment les fichiers téléchargés.
Un exemple de configuration de réseau maillé 103 sur la base duquel certaines règles de comportement de ce réseau seront expliquées est illustré par la figure 3. Le réseau comporte sept nœuds numérotés 301 à 307. L’élément 300 représente le point d’accès du réseau 106 - une station de base cellulaire par exemple. a. Selon le présent exemple de réalisation, un nœud a au plus un nœud parent et zéro, un ou plusieurs nœuds fils. Un nœud comporte au plus un nœud parent et zéro ou plus de nœuds fils. Selon un exemple de réalisation, le nombre de nœuds fils est limité. b. Un nœud est élu nœud racine (nœud 301 dans la figure 3) - il s’agit par exemple du nœud possédant le meilleur niveau de signal avec un point d’accès à un réseau de type du réseau 106. Plusieurs nœuds proches du même point d’accès ou proches de plusieurs points d’accès peuvent être en concurrence. c. Le rang d’un nœud est le nombre de nœuds sur le chemin jusqu’au nœud racine incrémenté de 1. Par exemple, le nœud 301, qui dans l’exemple de la figure 3 est le nœud racine, a le rang 0. Le nœud 307 a par exemple le rang 2. Le nombre maximal de rangs dans le réseau peut être limité. d. Un nouveau nœud choisit comme nœud parent le nœud qui donne le rang le plus faible et s’il y a plusieurs choix possibles selon ce critère, le nœud donnant le meilleur niveau de signal. e. Quand un nœud disparaît, l’arborescence est reconstruite localement.
Par exemple, les nœuds enfants, petits-enfants... du nœud disparu vont appliquer l’étape précédente effectuée par un nouveau nœud.
Chaque nœud sait en outre quel est son nœud parent et quels sont ses nœuds enfants, quelle qu’en soit la génération (enfants, petits-enfants.. .).
Le réseau maillé comporte donc deux types de nœuds, le premier type ne communiquant qu’à travers le réseau sans fil maillé et capable de servir de relais entre deux autres nœuds de ce réseau, le second type, aussi appelé passerelle, possédant la fonctionnalité réseau sans fil maillé, mais également la fonctionnalité de communication avec un réseau externe, par exemple de type cellulaire. Pour ce faire, dans le cas d’un réseau de type cellulaire, le second type est équipé d’une carte SIM physique ou électronique émise par un opérateur de réseau cellulaire. Un nœud du second type peut voir sa fonctionnalité de communication avec le réseau cellulaire désactivée s’il n’est pas élu nœud racine et devient alors un nœud du premier type. Chaque nœud possède par ailleurs une adresse de contrôle d’accès du médium (adresse ‘MAC’).
Etant donné que les nœuds sont en principe mobiles, un nœud donné peut être déconnecté à tout moment du reste du réseau maillé, ou voir son parent ou l’un de ses enfants disparaître. Certains nœuds peuvent rester dans le même réseau maillé pendant un temps assez long, notamment lorsqu’ils sont portés par des véhicules garés sur un parking.
Selon un exemple de réalisation, le serveur 105 a un rôle de mise à jour de données des unités de contrôle électroniques dans le réseau maillé. Les données à mettre à jour peuvent comporter un ou plusieurs fichiers présents dans les unités de contrôle, tels les micrologiciels de ces unités, mais les données ne sont pas limitées à ce contexte et peuvent s’étendre à des mises à jour de banques de données (par exemple des cartes de géolocalisation) ou des applications ou un autre type de données. Le serveur dispose pour ce faire de plusieurs types d’information :
(I) Un premier type d’information comprend au moins un ou des identifiants du ou des fichiers qu’une unité de contrôle doit télécharger. Une indication permettant de déterminer la validité du premier type d’information est incluse. Selon une variante de réalisation, cette information est une signature électronique du contenu par clé privée émise par le serveur 105, présente dans l’entête du fichier et vérifiée par le nœud au moyen de la clé publique qu’il détient dans sa mémoire de programme.
Selon un exemple de réalisation, cette indication est une date d’expiration au-delà de laquelle des informations du premier type ne sont plus considérées comme valides.
Selon un exemple de réalisation, le premier type d’information prend la forme d’un fichier d’instructions comportant des informations identifiant des informations du second type décrits ci-dessous, ces informations permettant selon un exemple de réalisation non limitatif d’obtenir le téléchargement d’un ou plusieurs fichiers, dits fichiers ‘germe’.
La figure 7 est un exemple d’un fichier d’instructions 700 selon un mode de réalisation non limitatif. Ce fichier comporte un en-tête 701 (qui selon la variante de réalisation mentionnée ci-dessus inclut la signature électronique par clé privée) ainsi qu’une liste d’un ou plusieurs fichiers (600, n, n-1, n-2.. .) qu’un nœud destinataire doit charger. Selon un exemple de réalisation, le contenu du fichier peut différer d’une unité de contrôle à l’autre.
Selon un exemple de réalisation, le premier type d’information comporte également des instructions 703 à exécuter par l’unité réceptrice de ce premier type d’information.
(II) Un second type d’information comporte, pour un fichier identifié par le premier type d’information, l’identification des parties constitutives de ce fichier. Un exemple d’un tel fichier 600 est illustré par la figure 6. Selon sa taille, un fichier est découpé en plusieurs parties (référencées 605 à 608, soit quatre parties dans l’exemple de la figure 6, sans que cela soit limitatif) pour une transmission plus aisée. En effet, au vu de l’instabilité du réseau maillé, la probabilité de transmettre des parties de fichier plutôt que le fichier entier est plus grande. Des fichiers de taille raisonnable au vu des temps de transmission dans le réseau maillé ne sont pas découpés en plusieurs parties. Une taille maximale d’un fichier ou d’une partie d’un fichier peut être fixée. Les parties d’un fichier peuvent être téléchargées séparément par un nœud. Selon un exemple de réalisation non limitatif, il n’est pas nécessaire qu’un quelconque ordre soit respecté dans la transmission des différentes parties de fichier.
Selon un mode de réalisation particulier, le découpage en parties est réalisé par le serveur, qui prépare également le second type d’information. Le second type d’information peut également prendre la forme d’un fichier, dénommé « fichier germe » 601 dans ce qui suit, et qui comporte un en-tête 602 ainsi qu’une section 603 listant les références 605 à 608 de toutes les parties nécessaires pour reconstituer le fichier 600.
Selon un autre mode de réalisation particulier, le fichier germe comprend les données indiquées dans le tableau 1 :
[Tableau 1]
Figure imgf000014_0001
Figure imgf000015_0001
Il est clair pour la personne du métier que les informations du second type peuvent différer du contenu du fichier donné en exemple. Par exemple, certaines informations ne sont pas forcément indispensables (identification de l’auteur par exemple). Par ailleurs, la fonction de certaines informations peut être remplie par d’autres informations.
La signature par clé privée permet à chaque nœud de vérifier que les informations du second et du troisième type n’ont pas été altérées par erreur ou intentionnellement grâce à la clé publique détenue par tous les nœuds dans une partie sécurisée de leur mémoire non volatile. Dans une variante de ce mode de réalisation, un mécanisme de chaine de blocs (blockchain en langue anglaise) semi fermée (ou aussi dite « à consortium ») dans la mesure où les blocs sont minés par le serveur 105, est mis en œuvre. Lors de la mise à disposition de nouveaux fichiers à distribuer vers les unités de contrôle électroniques, le serveur 105 ajoute à la chaine de blocs (le registre) un nouveau bloc contenant les informations de second et troisième type puis valide le bloc par une preuve de travail (minage). Les nœuds obtiennent de la part du serveur 105, en même temps que l’information du premier type, le registre. Avec ce registre, un nœud s’assure qu’il est bien en possession de la version la plus récente de l’information du second type et du troisième type, quelle qu’en soit la source (autre nœud du réseau maillé). Selon une variante de réalisation, les données du second et du troisième type sont contenues dans des blocs distincts. La date d’obsolescence peut également être remplacée par une autre information permettant de déterminer la validité du fichier, par exemple elle peut être implicite (et dans ce cas cette information n’est pas envoyée explicitement) ou encore être indiquée sous la forme d’une durée de validité. La validité peut aussi être indiquée sous la forme d’une ou plusieurs conditions à remplir autres que celles liées au temps ou à la date.
Selon un mode de réalisation, le comportement par défaut d’un nœud est qu’il stockera le fichier germe sur sa mémoire de masse 207 accessible par son serveur de fichiers 204 s’il a demandé le téléchargement de ce fichier pour l’unité de contrôle électronique auquel il est associé, et qu’il ne le stocke pas dans le cas contraire (par exemple lorsque le nœud sert uniquement de relais pour la transmission du fichier à un autre nœud).
Selon une variante de réalisation, le fichier germe 601 comprend des informations additionnelles sous la forme d’instructions 604 au nœud ou aux nœuds par lequel ou lesquels le fichier transite, par exemple relativement au stockage de données par le serveur local de fichiers 204 du ou des nœud(s) et en particulier pour dévier du comportement par défaut.
Selon un premier exemple non-limitatif, ces informations additionnelles comprennent une instruction de ne pas stocker le fichier germe dans la mémoire de masse 207 du serveur local de fichiers 204. Cette instruction peut être envoyée par exemple quand le contenu du fichier germe est sensible et que son accessibilité par d’autres nœuds qu’un nœud destinataire spécifique doit être contrôlée. Le nœud destinataire transmet le fichier reçu (après reconstitution du fichier 600 sur la base des parties téléchargées, soit 605 à 608 selon l’exemple non limitatif de la figure 6) à l’unité de contrôle électronique 200 mais ne le garde pas en mémoire au-delà de cette utilisation.
Selon un second exemple non-limitatif, les informations additionnelles comprennent une instruction 604 de stocker le fichier germe 601 ainsi que les parties de fichier constitutives du fichier 600 associé au fichier germe 601. Dans ce cas, un nœud stockera le fichier germe 601, ainsi que les parties du fichier 600 associé, même s’il n’est pas parmi le ou les destinataires finaux, par exemple s’il voit le fichier en tant que nœud relais. Cette option peut être mise en œuvre par exemple pour un fichier germe 601 et un fichier 600 associé très demandés ou potentiellement très demandés, dans le but d’augmenter le nombre de nœuds nourrices qui pourront fournir les données afférentes en cas de demande d’autres nœuds.
Selon un exemple de réalisation, un nœud efface un fichier germe et les fichiers qui y sont relatifs (600 et 605 à 608 dans l’exemple non limitatif selon l’exemple non limitatif de la figure 6) stocké par son serveur de fichiers une fois que le fichier ne sera plus valide. Selon un exemple de réalisation, la liste des parties du fichier comporte les identifiants uniques respectifs de ces parties. Un nœud demandeur inclura l’identifiant unique d’une partie dans une requête de téléchargement de cette partie.
(III) Un troisième type d’information comprend les parties de fichier elles-mêmes (605 à 608 dans l’exemple non limitatif de la figure 6). Selon un exemple de réalisation, les parties de fichier sont des fichiers binaires.
(IV) Selon une variante de réalisation, le serveur transmet également un quatrième type d’information destiné au nettoyage entier ou partiel des serveurs de fichier d’un nœud. Ce quatrième type d’information peut également prendre la forme d’un fichier transmis lorsqu’un nœud se connecte et comprendre des instructions de suppression d’un ou plusieurs fichiers spécifiques ou de l’ensemble des données stockées localement dans le nœud.
Selon un mode de réalisation, les étapes lors de l’activation d’un nouveau nœud sont les suivantes :
(i) Un nouveau nœud, appelé nœud d’origine dans ce qui suit, devient actif.
(ii) Le nœud d’origine s’insère dans l’arborescence du réseau maillé.
(iii) Le nœud d’origine transmet un message à son nœud parent, ce message remontant dans l’arborescence jusqu’au nœud racine - ce dernier le transmet au serveur si le nœud racine est en communication avec le serveur.
Le message contient un identifiant unique pouvant être authentifié par le serveur et lui permettant d’identifier à la fois le nœud d’origine et l’unité de contrôle électronique associée au nœud d’origine. Selon un exemple de réalisation, l’identifiant unique est l’identifiant VIN de l’unité de contrôle électronique du véhicule associé au nœud d’origine ou l’adresse MAC du nœud d’origine ou la combinaison de l’identifiant VIN et de l’adresse MAC. Selon un exemple de réalisation, l’identifiant unique est envoyé sous la forme d’un hachage.
Le message contient également une information permettant au serveur de déterminer si un fichier d’instructions 700 doit être envoyé à l’unité de contrôle électronique du nœud d’origine. Cette information est par exemple l’indication de validité d’un fichier d’instructions précédemment reçu par le nœud d’origine, ou une indication comme quoi aucun fichier d’instruction n’est disponible au niveau de l’unité de contrôle du nœud d’origine.
(iv) Le cas échéant, un fichier d’instructions est transmis par le serveur au nœud d’origine, soit directement si le nœud d’origine est le nœud racine, soit à travers le réseau maillé si le nœud d’origine n’est pas le nœud racine).
Selon un exemple de réalisation, une unité de contrôle électronique surveille la validité du fichier d’instructions qu’elle stocke. Lorsque le fichier n’est plus valide, par exemple lorsque la date d’expiration est dépassée, l’application client du véhicule lance une requête auprès du nœud associé au véhicule pour demander un nouveau fichier d’instructions au serveur.
Sur base du fichier d’instructions, le second type d’information est ensuite téléchargé par le nœud d’origine. Dans ce qui suit, on prendra le cas simple où un seul fichier doit être obtenu et donc qu’un seul fichier germe est géré. Il est bien entendu que cela constitue un exemple non limitatif et que le fichier d’instruction peut concerner une pluralité de fichiers.
Selon le présent exemple de réalisation, le client de téléchargement 202 du nœud transmet le fichier d’instruction 700 à l’unité de contrôle électronique 200. Sur requête de cette dernière pour le fichier 600 à travers l’API 201, le client de téléchargement procède au téléchargement du fichier germe 601 puis procède automatiquement au téléchargement des parties individuelles de fichier (605 à 608 dans l’exemple non limitatif) sur base du contenu du fichier germe 601. Une fois toutes les parties individuelles téléchargées, le client de téléchargement vérifie l’intégrité des parties téléchargées, assemble le ficher complet 600, en vérifie l’intégrité et informe l’unité de contrôle électronique 200 au travers du module de gestion d’interruptions. Le fichier 600 complet pourra alors être transmis à l’unité de contrôle électronique. Selon une variante de réalisation, le cas échéant, le module de téléchargement implémente les instructions supplémentaires pouvant être contenues dans le fichier germe. Du point de vue de l’unité de contrôle électronique 200, cette dernière reçoit le fichier d’instructions 700 et peut en déduire le cas échéant le ou les fichiers 600 à obtenir.
Suite à la réception d’une requête pour un fichier 600, le client de téléchargement 202 procède comme suit :
I. Si un fichier demandé est complet et disponible dans le serveur de fichier, ce fichier est transmis à l’unité de contrôle électronique à travers l’API 201.
II. Si le fichier n’est pas disponible ou incomplet : o Si le fichier est n’est pas en cours de téléchargement, le client de téléchargement 102 initie le téléchargement et met la requête de l’unité de contrôle électronique en attente jusqu’à la disponibilité du fichier complet. o Si le fichier est en cours de téléchargement mais n’est pas encore complet, le client de téléchargement continue le téléchargement et met la requête de l’unité de contrôle électronique en attente jusqu’à la disponibilité du fichier complet.
Selon un mode de réalisation particulier, lorsqu’un nœud reçoit une requête pour un fichier de l’unité de contrôle électronique, il renvoie des données relatives à l’état de téléchargement. Selon un mode de réalisation, ces données comportent au moins l’un parmi une indication si le téléchargement du fichier est en cours et un taux de progression du téléchargement. Cette dernière donnée peut simplement consister en un ratio entre le nombre de parties déjà téléchargées par rapport au nombre total de parties du fichier.
La procédure de téléchargement des différents types d’information et des parties de fichier dans le cadre d’un réseau maillé selon un exemple de réalisation va maintenant être décrite. Dans ce qui suit, on parlera essentiellement de partie de fichier, mais le processus décrit s’applique tout autant au second type d’information ou fichier germe. Le premier type d’information ou fichier d’instruction n’est disponible qu’ auprès du serveur 105 et n’est pas stocké de façon distribuée dans le réseau. Un nœud demandeur d’un téléchargement possède une file de fichiers et/ou de parties de fichier en attente de téléchargement. Cette file d’attente est remplie notamment sur base de demandes de l’unité de contrôle électronique. Cette file n’est pas nécessairement vide lors de la connexion au réseau maillé car le nœud a pu être déconnecté précédemment du même réseau maillé ou d’un autre réseau maillé. Le cas échéant, elle peut se remplir au fur et à mesure des requêtes de l’unité de contrôle électronique. Le nœud demandeur transmet une requête pour un élément tel qu’une partie de fichier ou fichier entier (par exemple concernant le fichier germe) à son nœud parent et à ses nœuds enfants. La file d’attente sert à alimenter les requêtes. Une requête peut concerner plusieurs parties de fichier ou fichiers, mais pour des raisons de clarté, le cas d’une partie de fichier unique sera considéré dans un premier temps. Une requête permet de déterminer si un nœud dans le réseau possède l’élément dans son stockage local et d’obtenir l’adresse de ce nœud. Il est à noter que lorsqu’il lance une requête, le nœud ignore la ou les adresses du ou des nœuds qui pourront lui fournir les données demandées.
De manière générale :
(a) un nœud recevant une requête (que ce soit d’un nœud demandeur initial ou d’un nœud intermédiaire) et possédant la partie de fichier demandée va en informer le nœud ayant transmis la requête, en y joignant sa propre adresse, et arrêter de propager la requête ;
(b) un nœud recevant une requête (que ce soit d’un nœud demandeur initial ou d’un nœud intermédiaire) et ne possédant pas la partie du fichier demandée va propager la requête à ses voisins directs (parent, enfants).
De proche en proche, tout le réseau peut ainsi être atteint - mais la requête est arrêtée dans sa propagation dans une branche par un nœud qui possède la partie de fichier. Le nœud demandeur initial n’aura donc pas forcément à disposition une liste exhaustive de nœuds possédant le fichier, mais aura au minimum une liste de nœuds les plus proches.
Le serveur est considéré comme un nœud parent dans ce procédé, bien que ne faisant pas partie en tant que tel du réseau maillé. Les adresses des nœuds possédant le fichier, dits nœuds source, sont remontées vers le nœud demandeur initial à travers les nœuds intermédiaires.
Le nœud demandeur initial choisit l’un des nœuds source pour demander le téléchargement en lui adressent un message en ce sens à travers le nœud le plus proche sur le chemin vers le nœud source choisi, message qui est transmis de nœud en nœud sur ce chemin. Le choix peut être opéré par exemple en évaluant une fonction de coût, ou selon un autre critère.
Une fois le nœud source choisi, le nœud demandeur initial envoie une demande de téléchargement à ce nœud source - le nœud source initie alors la transmission de l’élément à travers le réseau maillé. Si le nœud source et le nœud demandeur initial ne sont pas en liaison directe, les paquets de données correspondant à cet élément sont transmises de proche en proche par le ou les nœuds intermédiaires.
Selon un mode de réalisation particulier, un nœud qui ne possède pas la partie du fichier demandée dans une requête et qui ne reçoit aucune réponse positive en ce sens de son propre sous-réseau remonte une information négative au nœud qui lui a propagé la requête. On entend par ‘sous-réseau’ toute la partie du réseau maillé qui est connectée directement ou indirectement au nœud ayant reçu la requête, hors la partie du réseau connectée au nœud dont provient la requête.
Selon une variante de réalisation, si l’élément demandé n’est pas disponible mais est en cours de téléchargement par le nœud parent du nœud demandeur initial, alors le nœud parent informe le nœud demandeur initial que l’élément concerné est en cours de téléchargement, optionnellement avec une indication du taux de progression. Le nœud demandeur initial transmet une nouvelle requête pour cet élément après un temps d’attente, qui est par exemple un temps fixe (par exemple quelques dizaines de secondes) ou un temps choisi aléatoirement.
Dans le cas où une requête propagée concerne plusieurs éléments, la réponse d’un nœud peut contenir des réponses distinctes pour chacun des éléments, et dans le cas de plusieurs réponses positives, autant d’adresses de nœuds sources. Selon une variante de réalisation, dans le cas où une requête reçue par un nœud concerne plusieurs éléments et que ce nœud possède seulement une partie des éléments demandés, il ne propage que la partie de la requête concernant le ou les éléments pour lesquels il ne peut apporter une réponse positive. Il concatène alors toutes les réponses reçues, y compris la sienne, en une seule réponse qui sera transmise au nœud dont il a reçu la requête.
Selon une variante de réalisation, en vue de permettre au nœud demandeur initial de recevoir l’ensemble des adresses des nœuds source potentiels étant donné que les diverses requêtes et réponses doivent avoir le temps de se propager à travers le réseau maillé, le nœud demandeur initial prévoit un temps d’attente après réception d’une première réponse positive avant de choisir un nœud source. Ce temps d’attente, modifiable par paramétrage du nœud, peut être, par exemple, de quelques secondes.
Selon une variante de réalisation, la requête du nœud demandeur initial contient l’adresse IP de ce nœud, pour qu’un nœud recevant indirectement la requête par un nœud intermédiaire puisse répondre directement au nœud demandeur initial par un message utilisant cette adresse IP comme adresse destinataire. Il n’y a alors pas de concaténation de la réponse par le nœud intermédiaire. Cela suppose aussi que cette adresse IP est contenue dans les requêtes propagées au-delà des nœuds directement connectés au nœud demandeur initial.
Selon une variante de réalisation, l’évaluation d’une fonction de coût d’un téléchargement (de type d’information, de fichier ou de partie de fichier) est implémentée pour choisir l’une parmi plusieurs nœuds source pour télécharger un élément donné. Selon le présent mode de réalisation, la fonction de coût tend à privilégier un nœud du réseau maillé comme source plutôt qu’un serveur extérieur au réseau maillé, sans toutefois exclure ce serveur.
Selon un exemple de réalisation particulier de cette variante, la fonction de coût prend en compte : (a) Le niveau de signal (donné par le RSSI, qui est une valeur négative en dBm entre 0 et -255) entre deux nœuds
(b) Le nombre de sauts (nombre de nœuds intermédiaires entre un nœud demandeur initial et un nœud source)
(c)Le type de connexion (par exemple, cellulaire ou non-cellulaire)
Concernant le point (a), le RSSI est le niveau du signal entre le client Wifi (la partie station d’un nœud enfant) et le point d’accès Wifi (la partie Access Point d’un nœud parent). Chaque liaison a son propre RSSI. Le RSSI global d’un chemin entre le nœud demandeur et le nœud fournisseur potentiel de l’élément à télécharger est la somme de ces RSSI. On pratique, pour évaluer le coût de la liaison, on prendra la valeur 255 retranchée du RSSI car plus le niveau du signal est élevé, plus le RSSI est élevé (proche de 0). Les valeurs des RSSI des liaisons entre le nœud demandeur et le nœud fournisseur sont véhiculées dans le message de réponse positive du nœud fournisseur à la demande de fourniture du fichier. A cette fin, le message de réponse contient deux registres numériques : RSSI et STABILITE, initialisés par le nœud fournisseur respectivement à 0 et 1. Le nœud fournisseur transmet ce message au nœud qui lui a transmis la demande du fichier. Ce dernier incrémente le registre RSSI du message avec la valeur 255 retranchée de la valeur du RSSI entre lui-même et le nœud fournisseur et réalise le produit de la valeur du registre STABILITE avec la valeur de la stabilité de la liaison entre lui-même et le nœud fournisseur. Puis il transmet ce message au nœud qui lui avait transmis la demande qu’il avait lui-même transmise au nœud fournisseur. Le processus se répète jusqu’à ce que le message parvienne au nœud demandeur. Ce dernier réalise les mêmes opérations puis calcule le coût total du chemin entre lui et le nœud fournisseur en divisant la valeur du registre RSSI par celle du registre STABILITE.
Le tableau 2 illustre les valeurs successives prises par les registres RSSI et STABILITE au fur et à mesure de la progression du message dans le réseau. [Tableau 2]
Figure imgf000024_0002
Le coût du chemin entre le nœud fournisseur (n) et le nœud demandeur (0) est :
Figure imgf000024_0001
Concernant le point (c), une valeur de coût de la liaison entre le serveur 105 et le nœud racine est fournie par ce dernier aux autres nœuds du réseau maillé.
Selon une autre variante de réalisation, la stabilité du réseau est également prise en compte sous la forme d’une valeur entre 0 et 1, où 1 représente une stabilité maximale. La stabilité de plusieurs connexions consécutives est obtenue par le produit des stabilités de chaque connexion entre le nœud demandeur et le nœud source, et une évaluation de la puissance du signal entre ces deux nœuds est compensée en divisant cette évaluation de puissance par le produit des stabilités. Selon un mode de réalisation particulier, la stabilité d’une connexion individuelle est fonction d’un ou plusieurs critères parmi le temps de connexion constaté sur une période donnée, l’heure de la journée, la stabilité du voisinage dans le réseau maillé et d’autres critères mesurables dépendant indirectement des déplacements du nœud.
La figure 4 montre un exemple de réseau maillé simple comprenant un serveur 400 et des nœuds 401 à 404. La source 401 et le nœud 404 sont des sources potentielles pour des données requises par le nœud demandeur 402. Le nœud 401 est le nœud racine et les nœuds 402, 403 et 404 sont des nœuds de rangs respectifs 1, 2, 3. Une valeur de RSSI, est associée à chaque connexion parmi les nœuds. Cette valeur de RSSI est notée ‘RSSI x-y’ où x indique le rang d’un premier nœud et y indique le rang d’un second nœud connecté au premier nœud, avec x<y.
La fonction de coût évaluée pour les deux sources potentielles peut alors être de la forme :
CoûtSourcel = (255 - « RSSI 2-3 ») + (255 - « RSSI 1-2 »)
CoûtSource2 = (255 - « RSSI 0-1 ») + TELCO où ‘TELCO’ est un coût associé au réseau d’accès auquel le nœud racine est connecté. Selon le présent exemple, le coût associé à la liaison TELCO le coût maximum d’une liaison dans le réseau maillé, soit ‘-255.
La figure 5 est un exemple chiffré d’un réseau et de l’évaluation des coûts prenant en compte la stabilité de chaque connexion. Dans l’exemple de la figure 5, le serveur 500 et les nœuds 501 à 504 sont respectivement connectés de manière similaire au serveur 400 et aux nœuds 401 à 404 de la figure 4. Le nœud 502 possède par ailleurs un fils 505 et un petit-fils 506. La figure donne les valeurs des différents critères pris en compte dans la fonction de coût.
[Tableau 3]
Figure imgf000025_0001
Figure imgf000026_0001
Le nœud 506 est le nœud source donnant le coût le plus faible. A noter qu’en tant que source, le serveur a un coût moyen, notamment grâce à la valeur de stabilité importante associée à la connexion avec le nœud racine.
Bien que les deux exemples donnés ci-dessous combinent différents critères d’une certaine dans les fonctions de coût présentées, ces différents critères peuvent être utilisés indépendamment les uns des autres ou combinés de manière différente, selon les besoins. Il reste également possible de rajouter un ou plusieurs autres critères.
La figure 8 est un organigramme illustrant certaines des étapes selon l’un des modes de réalisation précédemment décrits et mises en œuvre au niveau d’un nœud.
Une première étape S801 comporte l’obtention des premières données identifiant un fichier à obtenir. Une seconde étape S802 comporte l’obtention de secondes données identifiant une pluralité de parties du fichier à obtenir. Une troisième étape S803 comporte le stockage des secondes données en local. Une quatrième étape S805 comporte l’obtention d’au moins une partie du fichier. Une cinquième étape comporte le stockage de l’au moins une partie obtenue en local.
Le nœud peut alors servir de source pour les secondes informations et/ou la ou les parties du fichier stockées en local. A noter que le nœud peut bien entendu servir de source pour les secondes informations sans que des parties de fichier soient déjà stockées localement.
La figure 9 est un organigramme illustrant certaines des étapes selon l’un des modes de réalisation précédemment décrits et mises en œuvre au niveau d’un nœud.
Une première étape S901 comporte la réception, au niveau d’un nœud donné, d’une requête d’un autre nœud du réseau maillé pour la vérifier la présence d’un élément dans le stockage local du nœud donné. Le nœud donné vérifie la présence de l’élément dans son stockage local (étape S902). Si l’élément est présent, le nœud donné s’identifie comme nœud source et transmet une réponse positive au nœud ayant envoyé la requête dans une étape S903. Le nœud donné précise un identifiant tel qu’une adresse qui permettra à un autre nœud recevant cet identifiant de le contacter. Si l’élément n’est pas présent dans le stockage local, la requête est propagée, selon une étape S904, aux nœuds en liaison directe avec le nœud donné, à l’exception du nœud ayant envoyé la requête. Le nœud donné attend alors des réponses des nœuds auxquels la requête aura été propagée. Si une réponse positive est reçue avec une identification d’un nœud source, ce qui testé lors d’une étape S905, alors le nœud donné transmet cette identification au nœud ayant envoyé la requête dans une étape S907. Le nœud source peut être l’un des nœuds en liaison directe avec le nœud donné, ou un autre nœud auquel la requête aura été propagée par ailleurs, ou le serveur. Plusieurs nœuds source peuvent s’identifier et leur identification transmise. Si aucune réponse positive n’est reçue, le nœud donné transmet une réponse négative au nœud ayant envoyé la requête, selon une étape S906.
La figure 10 est un organigramme illustrant certaines des étapes selon l’un des modes de réalisation précédemment décrits et mises en œuvre au niveau d’un nœud.
Selon une étape S 1001, un nœud donné transmet, aux nœuds en liaison directe, une requête pour la vérifier la présence d’un élément à télécharger. Si au moins un identifiant d’un nœud source est obtenu en retour (test positif à l’étape S1002), alors une sélection d’un nœud source est opérée lors d’une étape S 1003, une demande de transmission de l’élément est envoyée au nœud source sélectionné lors d’une étape S1004, et l’élément est reçu et stocké localement dans une étape S1005. Si aucun identifiant de nœud source n’est obtenu, l’étape S1001 est reprise si certaines conditions sont remplies (par exemple et de façon non limitative, de telles conditions peuvent comprendre l’une ou plusieurs parmi : le réseau maillé est de nouveau connecté à un serveur, le nœud donné a obtenu un nouveau nœud enfant, de nouveaux nœuds se sont annoncés dans le réseau maillé.. .).
Exemples
EL Méthode de transmission de données dans un réseau maillé (103) de dispositifs de communication (301-307), la méthode étant mise en œuvre par un dispositif donné (101) du réseau maillé muni d’un processeur (208), la méthode comprenant: l’obtention (S801) de premières données (700) identifiant un fichier (600), lesdites premières données étant à obtenir d’une source externe (105) au réseau maillé et à l’exclusion des dispositifs du réseau maillé, ledit fichier étant obtenable sous la forme d’une pluralité de parties dont l’ensemble permet de former le fichier complet ; l’obtention (S802) de secondes données (601) identifiant les parties (605-608) formant le fichier (600) à partir de la source externe ou d’un autre dispositif du réseau maillé ; l’obtention (S804) d’au moins une partie du fichier à partir de la source externe ou d’un autre dispositif du réseau maillé ; le stockage (S803, S805), dans un module de stockage (207) du dispositif donné, des secondes données et des parties de fichier pour transmission en cas de demande d’un autre dispositif du réseau maillé
E2. Méthode selon El, le réseau maillé étant organisé sous la forme d’une structure arborescente selon laquelle chaque dispositif est connecté au plus à un dispositif parent et peut être connecté à zéro, un ou plusieurs dispositifs enfant.
E3. Méthode selon E2, où l’obtention des secondes données (601) ou de l’au moins une partie du fichier (605 - 608) comprend la transmission (S 1001) d’une requête aux dispositifs directement connectés au dispositif donné dans le réseau maillé dans la structure arborescente, ladite requête identifiant les secondes données ou l’au moins une partie de fichier à obtenir.
E4. Méthode selon E3, comprenant la réception de réponses des dispositifs auxquels la requête a été envoyée, les réponses comportant le cas échéant l’adresse d’un ou plusieurs dispositifs du réseau maillé ayant stocké les secondes données ou l’au moins une partie de fichier à obtenir et auxquels la requête aura été envoyée ou au moins partiellement propagée.
E5. Méthode selon E4, comprenant la détermination, parmi le ou les dispositifs dont la ou les adresses ont été reçues, d’un dispositif auprès duquel les secondes données ou l’au moins une partie du fichier sont à obtenir, la détermination étant basée sur une fonction de coût prenant en compte la ou les liaisons sur le chemin, dans la structure arborescente, entre le dispositif donné et chacun du ou des dispositifs dont la ou les adresses ont été reçues.
E6. Méthode selon E5, dans laquelle la fonction de coût prend en compte un ou plusieurs parmi un ou des niveaux de signal sur la ou les liaisons sur ledit chemin, le nombre de sauts sur ledit chemin, la nature de la ou des liaisons sur ledit chemin, un ou des indicateurs de stabilité de la ou des liaisons sur ledit chemin. E7. Méthode selon E6, dans laquelle la fonction de coût prend en compte la combinaison d’un ou des niveaux de signal sur la ou les connexions sur ledit chemin et un ou des indicateurs de stabilité de la ou des liaisons sur ledit chemin.
E8. Méthode selon E7, dans laquelle le coût induit par une liaison entre un dispositif du réseau maillé et la source externe est pris supérieur au coût induit par une liaison entre deux dispositifs du réseau maillé.
E9. Méthode selon E2, comportant la réception (S901) d’une requête d’un dispositif directement connecté au dispositif donné dans l’arborescence du réseau maillé, ladite requête identifiant un élément recherché, et l’envoi (S903) d’une réponse positive au dispositif dont la requête a été reçue si l’élément recherché est l’un parmi les secondes données et l’au moins une partie de fichier stockées par ledit dispositif donné, la réponse positive comportant une adresse du dispositif donné.
E10. Méthode selon E9, comportant, en cas d’absence de l’élément recherché dans le stockage du dispositif donné, la propagation (S904) de la requête aux dispositifs directement connectés au dispositif donné dans l’arborescence en dehors du dispositif dont la requête a été initialement reçue, et la collecte des réponses des dispositifs auprès desquels la requête a été propagée pour renvoi (S906, S907) d’une réponse au dispositif dont la requête a été initialement reçue.
El i. Méthode selon E9 ou E10, comprenant, si le dispositif donné est connecté à ladite source externe (105) et ne possède pas l’élément recherché dans son stockage, le renvoi de l’adresse de ladite source externe dans la réponse.
E12. Méthode selon l’une parmi El à El i, comprenant la réception, à partir de la source externe (105), de données de registre d’une chaine de blocs maintenue par ladite source externe, ladite chaine de blocs contenant un bloc avec les secondes et troisièmes données ou des blocs avec respectivement les secondes données et les troisièmes données, les données de registre étant adaptées à permettre la vérification, par le nœud, de l’intégrité des secondes et troisièmes données, les troisièmes données comprenant au moins une partie du fichier.
E 13. Dispositif de communication adapté à se connecter à un réseau maillé comprenant d’autres dispositifs, ledit dispositif comprenant une interface (203) de réseau maillé, un module de stockage local (207) et un processeur (208) configuré pour conduire ledit dispositif de communication à mettre en œuvre : l’obtention (S801) de premières données (700) identifiant un fichier (600)à obtenir d’une source externe (105) au réseau maillé et à l’exclusion des dispositifs du réseau maillé, ledit fichier étant obtenable sous la forme d’une pluralité de parties dont l’ensemble permet de former le fichier complet ; l’obtention (S802) de secondes données (601) identifiant les parties (605-608) formant le fichier (600) à partir de la source externe ou d’un autre dispositif du réseau maillé ; l’obtention (S804) d’au moins une partie du fichier à partir de la source externe ou d’un autre dispositif du réseau maillé ; le stockage (S803, S805), dans le module de stockage (207) du dispositif de communication, des secondes données et des parties de fichier pour transmission en cas de demande d’un autre dispositif du réseau maillé.
El 4. Dispositif de communication selon El 3, comprenant
- une interface programmable d’application (201) pour transmettre les premières données à un dispositif client (200) et à recevoir de ce dispositif client une requête pour l’obtention d’un fichier identifié (600) dans les premières données et pour transmettre le fichier identifié au dispositif client ;
- un client de téléchargement (202) pour télécharger la pluralité de parties de fichier correspondant au fichier identifié (600), pour former le fichier identifié complet à partir des parties du fichier.
E15. Dispositif de communication selon El 3 ou El 4, dans lequel le processeur est configuré pour conduire ledit dispositif à mettre en œuvre l’une des méthodes selon El à E12.

Claims

29 REVENDICATIONS
1. Méthode de transmission de données dans un réseau maillé (103) de dispositifs de communication (301-307), la méthode étant mise en œuvre par un dispositif donné (101) du réseau maillé muni d’un processeur (208), la méthode comprenant: l’obtention (S801) de premières données (700) identifiant un fichier (600), lesdites premières données étant à obtenir d’une source externe (105) au réseau maillé et à l’exclusion des dispositifs du réseau maillé, ledit fichier étant obtenable sous la forme d’une pluralité de parties dont l’ensemble permet de former le fichier complet ; l’obtention (S802) de secondes données (601) identifiant les parties (605-608) formant le fichier (600) à partir de la source externe ou d’un autre dispositif du réseau maillé ; l’obtention (S804) d’au moins une partie du fichier à partir de la source externe ou d’un autre dispositif du réseau maillé ; le stockage (S803, S805), dans un module de stockage (207) du dispositif donné, des secondes données et des parties de fichier pour transmission en cas de demande d’un autre dispositif du réseau maillé ; le réseau maillé étant organisé sous la forme d’une structure arborescente selon laquelle chaque dispositif est connecté au plus à un dispositif parent et peut être connecté à zéro, un ou plusieurs dispositifs enfant, le procédé comportant en outre la réception (S901) d’une requête d’un dispositif directement connecté au dispositif donné dans l’arborescence du réseau maillé, ladite requête identifiant un élément recherché, et l’envoi (S903) d’une réponse positive au dispositif dont la requête a été reçue si l’élément recherché est l’un parmi les secondes données et l’au moins une partie de fichier stockées par ledit dispositif donné, la réponse positive comportant une adresse du dispositif donné.
2. Méthode selon la revendication 1, où l’obtention des secondes données (601) ou de l’au moins une partie du fichier (605 - 608) comprend la transmission (S 1001) d’une requête aux dispositifs directement connectés au dispositif donné 30 dans le réseau maillé dans la structure arborescente, ladite requête identifiant les secondes données ou l’au moins une partie de fichier à obtenir. Méthode selon la revendication 2, comprenant la réception de réponses des dispositifs auxquels la requête a été envoyée, les réponses comportant le cas échéant l’adresse d’un ou plusieurs dispositifs du réseau maillé ayant stocké les secondes données ou l’au moins une partie de fichier à obtenir et auxquels la requête aura été envoyée ou au moins partiellement propagée. Méthode selon la revendication 3 comprenant la détermination, parmi le ou les dispositifs dont la ou les adresses ont été reçues, d’un dispositif auprès duquel les secondes données ou l’au moins une partie du fichier sont à obtenir, la détermination étant basée sur une fonction de coût prenant en compte la ou les liaisons sur le chemin, dans la structure arborescente, entre le dispositif donné et chacun du ou des dispositifs dont la ou les adresses ont été reçues. Méthode selon la revendication 4, dans laquelle la fonction de coût prend en compte un ou plusieurs parmi un ou des niveaux de signal sur la ou les liaisons sur ledit chemin, le nombre de sauts sur ledit chemin, la nature de la ou des liaisons sur ledit chemin, un ou des indicateurs de stabilité de la ou des liaisons sur ledit chemin. Méthode selon la revendication 5, dans laquelle la fonction de coût prend en compte la combinaison d’un ou des niveaux de signal sur la ou les connexions sur ledit chemin et un ou des indicateurs de stabilité de la ou des liaisons sur ledit chemin. Méthode selon la revendication 6, dans laquelle le coût induit par une liaison entre un dispositif du réseau maillé et la source externe est pris supérieur au coût induit par une liaison entre deux dispositifs du réseau maillé. Méthode selon la revendication 1, comportant, en cas d’absence de l’élément recherché dans le stockage du dispositif donné, la propagation (S904) de la requête aux dispositifs directement connectés au dispositif donné dans l’arborescence en dehors du dispositif dont la requête a été initialement reçue, et la collecte des réponses des dispositifs auprès desquels la requête a été propagée pour renvoi (S906, S907) d’une réponse au dispositif dont la requête a été initialement reçue. Méthode selon l’une des revendications 1 ou 8, comprenant, si le dispositif donné est connecté à ladite source externe (105) et ne possède pas l’élément recherché dans son stockage, le renvoi de l’adresse de ladite source externe dans la réponse. Méthode selon l’une des revendications 1 à 9, comprenant la réception, à partir de la source externe (105), de données de registre d’une chaine de blocs maintenue par ladite source externe, ladite chaine de blocs contenant un bloc avec les secondes et troisièmes données ou des blocs avec respectivement les secondes données et les troisièmes données, les données de registre étant adaptées à permettre la vérification, par le nœud, de l’intégrité des secondes et troisièmes données, les troisièmes données comprenant au moins une partie du fichier. Dispositif de communication adapté à se connecter à un réseau maillé comprenant d’autres dispositifs, ledit dispositif comprenant une interface (203) de réseau maillé, un module de stockage local (207) et un processeur (208) configuré pour conduire ledit dispositif de communication à mettre en œuvre : l’obtention (S801) de premières données (700) identifiant un fichier (600), lesdites premières données étant à obtenir d’une source externe (105) au réseau maillé et à l’exclusion des dispositifs du réseau maillé, ledit fichier étant obtenable sous la forme d’une pluralité de parties dont l’ensemble permet de former le fichier complet ; l’obtention (S802) de secondes données (601) identifiant les parties (605-608) formant le fichier (600) à partir de la source externe ou d’un autre dispositif du réseau maillé ; l’obtention (S804) d’au moins une partie du fichier à partir de la source externe ou d’un autre dispositif du réseau maillé ; le stockage (S803, S805), dans le module de stockage (207) du dispositif de communication, des secondes données et des parties de fichier pour transmission en cas de demande d’un autre dispositif du réseau maillé ; et, le réseau maillé étant organisé sous la forme d’une structure arborescente selon laquelle chaque dispositif est connecté au plus à un dispositif parent et peut être connecté à zéro, un ou plusieurs dispositifs enfant, la réception (S901) d’une requête d’un dispositif directement connecté au dispositif donné dans l’arborescence du réseau maillé, ladite requête identifiant un élément recherché, et l’envoi (S903) d’une réponse positive au dispositif dont la requête a été reçue si l’élément recherché est l’un parmi les secondes données et l’au moins une partie de fichier stockées par ledit dispositif donné, la réponse positive comportant une adresse du dispositif donné. Dispositif de communication selon la revendication 11, comprenant
- une interface programmable d’application (201) pour transmettre les premières données à un dispositif client (200) et à recevoir de ce dispositif client une requête pour l’obtention d’un fichier identifié (600) dans les premières données et pour transmettre le fichier identifié au dispositif client ;
- un client de téléchargement (202) pour télécharger la pluralité de parties de fichier correspondant au fichier identifié (600), pour former le fichier identifié complet à partir des parties du fichier. Dispositif de communication selon l’une des revendications 11 ou 12, dans lequel le processeur est configuré pour conduire ledit dispositif à mettre en œuvre l’une des méthodes des revendications 1 à 10.
PCT/FR2022/051935 2021-10-18 2022-10-14 Methode de transmission de donnees dans un reseau maille et dispositif de communication dans un tel reseau WO2023067267A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2111029 2021-10-18
FR2111029A FR3128343A1 (fr) 2021-10-18 2021-10-18 Methode de transmission de donnees dans un reseau maille et dispositif de communication dans un tel reseau

Publications (1)

Publication Number Publication Date
WO2023067267A1 true WO2023067267A1 (fr) 2023-04-27

Family

ID=79170814

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2022/051935 WO2023067267A1 (fr) 2021-10-18 2022-10-14 Methode de transmission de donnees dans un reseau maille et dispositif de communication dans un tel reseau

Country Status (2)

Country Link
FR (1) FR3128343A1 (fr)
WO (1) WO2023067267A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2844659A1 (fr) * 2002-09-16 2004-03-19 Trident Media Guard Tmg Procede de limitation de transfert de fichiers informatiques, dispositifs et programmes d'ordinateurs correspondants
US20060282405A1 (en) * 2005-06-10 2006-12-14 Microsoft Corporation System and method for optimized distributed file transfer
US20100094923A1 (en) * 2008-10-09 2010-04-15 Axiometric, Llc File Distribution in Wireless Networks
US20190349426A1 (en) * 2016-12-30 2019-11-14 Intel Corporation The internet of things
US20200412801A1 (en) * 2016-06-10 2020-12-31 Comcast Cable Communications, Llc Content Distribution Using Ad Hoc Mesh Networks

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2844659A1 (fr) * 2002-09-16 2004-03-19 Trident Media Guard Tmg Procede de limitation de transfert de fichiers informatiques, dispositifs et programmes d'ordinateurs correspondants
US20060282405A1 (en) * 2005-06-10 2006-12-14 Microsoft Corporation System and method for optimized distributed file transfer
US20100094923A1 (en) * 2008-10-09 2010-04-15 Axiometric, Llc File Distribution in Wireless Networks
US20200412801A1 (en) * 2016-06-10 2020-12-31 Comcast Cable Communications, Llc Content Distribution Using Ad Hoc Mesh Networks
US20190349426A1 (en) * 2016-12-30 2019-11-14 Intel Corporation The internet of things

Also Published As

Publication number Publication date
FR3128343A1 (fr) 2023-04-21

Similar Documents

Publication Publication Date Title
EP3058706B1 (fr) Procede et systeme de decouverte dynamique de fonctions service
FR2923969A1 (fr) Procede de gestion de trames dans un reseau global de communication, produit programme d&#39;ordinateur, moyen de stockage et tete de tunnel correspondants
FR3009159A1 (fr) Procede de traitement de donnees de geolocalisation
FR3023662A1 (fr) Procede d&#39;adhesion a une grappe de dispositifs electroniques communiquant via un resau sans fil, dispositif electronique mettant en oeuvre ledit procede, et systeme associes
EP3891959A1 (fr) Passerelle pour communiquer par réseau radio avec au moins un noeud et par un réseau filaire, par le biais d&#39;une blockchain
WO2020115002A1 (fr) Dispositif pour communiquer dans un reseau de passerelles heterogenes par reseau radio avec au moins un nœud et par un reseau longue distance, avec au moins un destinataire
EP2070276B1 (fr) Procédé pour évaluer la fiabilité d&#39;une route dans un réseau coopératif
WO2002001313A2 (fr) Procede de transmission d&#39;un agent mobile dans un reseau; emetteur, recepteur, et agent mobile associes
FR3036906A1 (fr) Procede d&#39;obtention d&#39;une route de communication par courants porteurs en ligne.
EP2210396B1 (fr) Système d&#39;interconnexion entre au moins un appareil de communication et au moins un système d&#39;information distant et procédé d&#39;interconnexion
EP3934108A1 (fr) Procédé de détermination d&#39;un mode de communication entre deux dispositifs voisins d&#39;un réseau
WO2023067267A1 (fr) Methode de transmission de donnees dans un reseau maille et dispositif de communication dans un tel reseau
EP3777308B1 (fr) Procédé de communication
EP3785400A1 (fr) Procédé de réenregistrement d&#39;un compteur électrique intelligent
EP3785403B1 (fr) Procédé d&#39;élaboration de données d&#39;utilisation de relais utilisés au cours d&#39;une communication entre deux appareils, de recherche desdites données, et appareils associés
EP3135017A1 (fr) Procédés d&#39;échange de données avec un équipement comprenant des moyens de communication radio
EP3675562B1 (fr) Procédés de traitement de données, dans un réseau ad hoc de radiocommunication, stations mobiles de radiocommunication et programmes d&#39;ordinateur associés
WO2017215970A1 (fr) Procede de dissemination de donnees dans un reseau maille
EP3675463A1 (fr) Procédé d&#39;identification d&#39;un objet connecté dans une infrastructure réseau
FR3098972A1 (fr) Procédé de validation atomique de chaines de messages à travers un réseau décentralisé
FR2915044A1 (fr) Procede de determination de la dynamique d&#39;un reseau logique
EP3675561A1 (fr) Procédé de routage dynamique dans des réseaux interconnectés d&#39;objets connectés
FR3095917A1 (fr) Procédé de routage dynamique dans des réseaux interconnectés d’objets connectés
FR3095914A1 (fr) Procédé de routage dynamique dans un réseau d’objets connectés
WO2018193201A1 (fr) Procédés pour le partage de données de localisation entre un dispositif source d&#39;un utilisateur et un dispositif destinataire d&#39;un tiers, serveur, dispositif source d&#39;un utilisateur, dispositif destinataire d&#39;un tiers et programme d&#39;ordinateur correspondants

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22801513

Country of ref document: EP

Kind code of ref document: A1