Brevet FR3116983A1 — publié le 20220603

L’invention concerne un traitement de données pour établir une communication selon une voie descendante depuis un système d’information (BE) vers un équipement communiquant cible (EC) via au moins un terminal (RM) dans un réseau collaboratif, le terminal (RM) relayant la communication entre le système d’information (BE) et l’équipement communicant cible (EC). En particulier, on prévoit, au niveau du système d’information (BE), de : - obtenir des identifiants de terminaux (RM) ayant relayé des communications précédentes au moins en voie montante entre des équipements communicants (EC) et le système d’information (BE), et alimenter avec au moins lesdits identifiants une base de données (BDH) stockant des données d’historique de communication dans le réseau collaboratif, - et, pour établir la communication en voie descendante vers l’équipement communicant cible (EC), interroger la base de données pour sélectionner au moins un terminal (RM) susceptible de relayer la communication en voie descendante vers l’équipement communicant cible (EC) et initier la communication en voie descendante via le terminal ainsi sélectionné. Figure de l’abrégé : Figure 1 Mise en œuvre d’une voie descendante dans un réseau collaboratif La présente divulgation relève du domaine des réseaux collaboratifs de communication. En communication ou télécommunications, La construction de réseaux collaboratifs (ou « Crowd Networking » en anglais) est basée sur la participation d'un grand nombre de terminaux mobiles cellulaires d'utilisateurs (type smartphones), dotés d'une interface radiofréquence de relativement courte portée (par rapport à la portée du réseau cellulaire) comme par exemple les interfaces Bluetooth ou encore Bluetooth Low Energy (BLE). Ainsi grâce à la mobilité et à la densité escomptée des terminaux, cet ensemble de terminaux cellulaires peut couvrir un territoire en permanence. Etant équipé d’une interface de communication radiofréquence de courte portée, chaque terminal cellulaire peut interagir avec d'autres équipements dans son voisinage comme par exemple des équipements communicants déployés massivement dans le cadre notamment des applications du type « Internet des objets » (ou « IoT »). Ainsi une population d'équipements IoT peut être connectée à un système d'information par l’intermédiaire d’une population de terminaux cellulaires pour la réalisation des applications IoT. La donne une vue d’ensemble d’un réseau collaboratif typique. Dans ce type d'architecture, il est assez aisé de réaliser la connectivité en voie montante des équipements communicants EC vers le système d’information (ou ci-après « backend ») BE qui centralise la collecte (remontée des informations). Cette connectivité peut se réaliser de façon opportuniste via les terminaux mobiles RM qui en permanence réceptionnent des messages sur leur interface de courte portée et relayent les messages via leur interface cellulaire au système d’information pour que ces informations soient triées, stockées et traitées pour enfin être exploitées. En revanche, la réalisation de la connectivité des équipements communicants en voie descendante est habituellement problématique. La réalisation de la connectivité en voie descendante via des connexions de proximité n’est pas aussi aisée que pour la voie montante. Ceci est dû principalement à la mobilité des terminaux cellulaires qui doivent réaliser les connexions de proximité et la nature dynamique de la présence ou non de ces terminaux cellulaires près des équipements EC à connecter. La mobilité éventuelle des équipements eux-mêmes ne fait qu’augmenter ces difficultés. Une solution possible pourrait consister à suivre en permanence la position des équipements EC et les terminaux cellulaires RM afin de pouvoir à chaque instant établir une correspondance, et plus particulièrement afin de savoir à chaque instant les équipements EC qui peuvent être atteints par chaque terminal cellulaire. Ainsi, une fois une connexion avec un équipement EC établie, la position de cet équipement EC devrait servir à sélectionner au moins un terminal cellulaire RM à proximité de celui-ci et de lui assigner la mission de relayer vers l’équipement les données qui lui sont destinées. Cette solution nécessite toutefois un couplage fort entre les terminaux cellulaires devant intervenir et le système d’information BE (ou « backend ») avec un coût en signalisation important. Par ailleurs le suivi de localisation des équipements EC en situation de mobilité rendrait cette solution encore plus compliquée et couteuse à mettre en œuvre. Une autre solution consisterait à télécharger périodiquement une liste de missions sur l’ensemble de terminaux cellulaires sensés évoluer à l’intérieur d’une région géographique contenant les équipements EC ciblés et laisser les terminaux cellulaires RM se connecter aux équipements EC de façon opportuniste. Cette technique, bien que plus simple, a néanmoins l’inconvénient de nécessiter la gestion et la maintenance d’une liste de missions de connexion auprès de chaque terminal cellulaire et la synchronisation de ces listes locales avec une liste globale sur le backend BE. Ces difficultés liées notamment à la mobilité des équipements cellulaires RM et des équipements EC ne peuvent être surmontées qu’au prix d’un couplage fort avec le backend BE et d’une signalisation très importante. Résumé La présente divulgation vient améliorer la situation. Il est proposé un procédé de traitement de données pour établir une communication selon une voie descendante depuis un système d’information (référence BE de la présentée précédemment) vers un équipement communicant cible (EC) via au moins un terminal (RM) dans un réseau collaboratif, le terminal (RM) relayant la communication entre le système d’information (BE) et l’équipement communicant cible (EC). On entend ainsi par « réseau collaboratif » le fait que les terminaux sont reliés au système d’information (BE) par un réseau étendu, par exemple un réseau cellulaire ou autre, alors qu’un équipement communicant cible (EC) ne l’est pas. Le système d’information précité peut être un serveur de type backend, par exemple, comme présenté plus haut. Les terminaux précités peuvent être mobiles, ou non (même si l’on augmente les chances de connecter tous les équipements communicants avec des terminaux mobiles tandis que des terminaux fixes (comme des hotspots wifi, ou passerelles fixes) ne connectent que les mêmes équipements, fixes, qui sont à proximité). Le procédé au sens de la présente description comporte alors, au niveau du système d’information (BE) : - obtenir des identifiants de terminaux (RM) ayant relayé des communications précédentes au moins en voie montante entre des équipements communicants (EC) et le système d’information (BE), et alimenter avec au moins lesdits identifiants une base de données stockant des données d’historique de communication dans le réseau collaboratif, - et, pour établir la communication en voie descendante vers l’équipement communicant cible (EC), interroger la base de données pour sélectionner au moins un terminal (RM) susceptible de relayer la communication en voie descendante vers l’équipement communicant cible (EC) et initier la communication en voie descendante via le terminal ainsi sélectionné. Ainsi, il est proposé une solution centralisée faisant usage d’un historique d’interactions entre équipements communicants et terminaux (par exemple mobiles) faisant relais en voie montante notamment, pour déterminer les terminaux susceptibles de faire relais pour la voie descendante car ayant statistiquement une forte probabilité de se situer à proximité des équipements visés et ainsi réaliser la connexion en voie descendante vers ces équipements visés. Cette approche a l’avantage de ne pas utiliser la localisation comme seul élément de détermination de la possibilité pour un équipement visé d’être à proximité d’un terminal relai, mais d’utiliser en outre notamment le fait que cet équipement a déjà interagi avec un terminal donné pouvant alors être adressé pour réaliser le relai. Ainsi, malgré le fait que la proximité soit un concept géographique, les informations géographiques (de localisation typiquement) ne sont pas nécessairement utilisées, ni utilisées seules, pour déterminer les relais mobiles susceptibles de se trouver à proximité d’un équipement communicant à atteindre en voie descendante. La solution proposée est davantage basée sur un historique des interactions. Dans le cas des équipements communicants stationnaires et peu mobiles, ces interactions peuvent êtres récurrentes notamment avec des terminaux mobiles présentant une régularité et/ou une périodicité dans leurs déplacements. Ainsi, par exemple dans un mode de réalisation, les données d’historique de la base de données peuvent comporter, outre les identifiants de terminaux ayant relayé une communication, des données d’horodates respectives de communication via ces terminaux. Dans une telle réalisation, pour établir la communication en voie descendante vers l’équipement communicant cible, la base de données peut alors être interrogée pour sélectionner au moins un terminal ayant une horodate de relai de communication pour l’équipement communicant cible la plus récente. Pour augmenter les chances de contacter un équipement communicant, la base de données peut être interrogée pour sélectionner une pluralité de terminaux, une partie au moins de ces terminaux sélectionnés étant alors utilisée pour relayer la communication en voie descendante vers l’équipement communicant cible. Dans ce mode de réalisation, l’équipement cible peut ne pas tenir compte de messages redondants déjà reçus par exemple. Le nombre de terminaux choisis pour effectuer les relais peut être optimisé pour : - augmenter les chances de contacter un équipement communicant, d’une part, - sans saturer le réseau collaboratif par des communications redondantes, d’autre part. Dans cette réalisation notamment, les données d’historique de la base de données comportent : - outre les identifiants de terminaux ayant relayé une communication, - des données d’horodates respectives de communication via ces terminaux et - des données de localisations respectives de ces terminaux à ces horodates. La base de données peut alors être interrogée pour sélectionner une pluralité de terminaux ayant des horodates de relai de communication pour l’équipement communicant cible les plus récentes et à une même localisation, une partie au moins des terminaux sélectionnés étant utilisée pour relayer la communication en voie descendante vers l’équipement communicant cible. Il est ainsi possible de donner une date de validité d’une localisation courante, et déterminer par exemple si l’équipement cible est mobile et estimer quantitativement un degré de mobilité de cet équipement. Il est possible en outre de sélectionner les terminaux ayant relayé une communication dans cette localisation par exemple. Dans une réalisation alternative ou complémentaire, la base de données peut être interrogée pour compter, pour chaque terminal ayant précédemment relayé des communications pour l’équipement communicant cible, un nombre d’occurrences de relai pour cet équipement communicant cible. On peut alors sélectionner au moins une première partie de terminaux ayant un nombre d’occurrences supérieur à un premier seuil choisi, en vue de relayer la communication en voie descendante vers l’équipement communicant cible. Une telle réalisation se base ainsi essentiellement sur des statistiques et probabilités d’utiliser des terminaux efficaces comme relais, et pas spécialement sur des localisations passées, typiquement. Dans ce mode de réalisation, la base de données peut être interrogée pour compter en outre, pour chaque terminal ayant précédemment relayé des communications pour tout équipement communicant, un nombre total d’occurrences de relai. On peut sélectionner alors, outre la première partie précitée, une deuxième partie de terminaux ayant un nombre total d’occurrences supérieur à un deuxième seuil choisi, en vue de relayer la communication en voie descendante vers l’équipement communicant cible. On comprendra alors que ce mode de réalisation particulier propose de compter aussi sur des terminaux « actifs » dans le sens où ils ont déjà relayé beaucoup de communications pour des équipements (notamment différents de l’équipement cible) et où il peut s’agir alors par exemple de terminaux mobiles, actifs pour relayer des communications de plusieurs équipements différents par exemple. On peut compter par exemple le nombre d’équipements différents pour lequel chacun de ces terminaux a déjà effectué un relai, et définir ainsi un critère de sélection de ces terminaux dans la deuxième partie précitée. On peut aussi ne retenir que ce dernier critère pour construire la deuxième partie précitée. Ainsi, dans une telle réalisation, la base de données peut être interrogée pour compter, pour chaque terminal donné (RM), le nombre d’équipements communicants, autres que l’équipement cible (EC), et pour lesquels le terminal donné (RM) a précédemment relayé au moins une communication. On peut alors sélectionner, outre la première partie précitée, une deuxième partie de terminaux ayant ce nombre d’équipements autres que l’équipement cible (EC) supérieur à un deuxième seuil choisi (N), en vue de relayer la communication en voie descendante vers l’équipement communicant cible (EC). Les terminaux de cette deuxième partie sont alors les plus « sociables », si un parallèle pouvait être fait avec les réseaux sociaux. Par ailleurs, le deuxième seuil précité peut être diminué si le nombre de terminaux candidats pour le relai dans la première partie précitée est insuffisant (inférieur à un seuil). A l’inverse, on peut ne pas avoir recours à la deuxième partie si le nombre de terminaux candidats pour le relai dans la première partie est suffisant. Dans la réalisation où les données d’historique de la base de données comportent, outre les identifiants de terminaux ayant relayé une communication, des données d’horodates respectives de communication via lesdits terminaux et des données de localisations respectives de ces terminaux à ces horodates, la base de données peut être interrogée en outre pour déterminer un écart temporel d’horodates de relai par des terminaux situés à une même localisation, pour un équipement communicant cible donné, afin d’évaluer un degré de mobilité de cet équipement communicant cible donné, comme indiqué précédemment. Dans une telle réalisation, il est possible en outre : - si le degré de mobilité est inférieur à un seuil, de sélectionner les terminaux ayant des horodates de relai de communication pour l’équipement communicant cible les plus récentes et à une même localisation, et - si le degré de mobilité est supérieur à un seuil, de sélectionner au moins la première partie de terminaux précitée, une partie au moins des terminaux sélectionnés étant alors utilisée pour relayer la communication en voie descendante vers l’équipement communicant cible. Ainsi dans une telle réalisation, si le degré de mobilité de l’équipement cible est élevé, une désignation de terminaux comme relais possibles fondée uniquement sur une localisation passée peut être contreproductive. Pour augmenter les chances de contacter l’équipement communicant, mobile, on a recours préférentiellement aux première et éventuellement deuxième parties de terminaux précitées. Dans une forme de réalisation complémentaire ou alternative, la base de données peut être interrogée en outre pour compter, pour chaque terminal ayant précédemment relayé des communications pour tout équipement communicant, un nombre total d’occurrences de relai, et on exclut de la sélection de terminaux pour relayer la communication en voie descendante vers l’équipement communicant cible, les terminaux ayant un nombre total d’occurrences de relai supérieur à un seuil choisi (typiquement supérieur aux premier et deuxième seuils précités, bien entendu). Une telle réalisation permet de ne pas retenir toujours les mêmes terminaux comme candidats possibles pour le relai, et assure ainsi un nivellement de charge des terminaux assurant le relai. Une autre manière d’atteindre ce but peut consister simplement à tirer aléatoirement les terminaux qui sont effectivement choisis pour effectuer le relai. Ainsi, dans une telle réalisation, on tire aléatoirement, dans la sélection de terminaux précitée, des terminaux choisis pour relayer la communication en voie descendante vers l’équipement communicant cible (EC). Comme indiqué précédemment, le critère de localisation d’un équipement à contacter n’est pas essentiel. Dès lors, les terminaux peuvent être mobiles et leur localisation (même si elle peut être utilisée dans un mode de réalisation) n’est pas non plus un paramètre essentiel pour la mise en œuvre de la présente description. Ainsi, dans un mode de réalisation, une partie au moins des terminaux du réseau collaboratif peuvent être des terminaux mobiles, la méconnaissance de leur localisation n’ayant pas d’impact pour mettre en œuvre l’objet de la présente description dans certaines formes de réalisation tout au moins. La présente description vise aussi un système de traitement de données pour établir une communication selon une voie descendante depuis un système d’information (BE) vers un équipement communicant cible (EC) via au moins un terminal (RM) dans un réseau collaboratif, le terminal (RM) relayant la communication entre le système d’information (BE) et l’équipement communicant cible (EC), le système de traitement comportant : - un dispositif de traçage d’identifiants de terminaux (RM) ayant relayé des communications précédentes au moins en voie montante entre des équipements communicant (EC) et le système d’information (BE), et - une mémoire pilotée par le dispositif de traçage pour stocker des données d’historique de communication dans le réseau collaboratif, lesdites données étant organisées selon une base de données (BDH) alimentée avec au moins lesdits identifiants, le dispositif de traçage étant configuré en outre pour interroger la base de données pour sélectionner au moins un terminal (RM) susceptible de relayer la communication en voie descendante vers l’équipement communicant cible (EC), et pour délivrer un identifiant du terminal sélectionné au système d’information (BE) pour initier la communication en voie descendante via ledit terminal sélectionné. La présente description vise aussi un dispositif de traçage d’un tel système de traitement, comportant en particulier un circuit de traitement configuré pour coopérer au moins avec la mémoire de stockage de la base de données d’historique, pour la mise en œuvre du procédé présenté ci-avant. Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre de tout ou partie d’un procédé tel que défini dans les présentes lorsque ce programme est exécuté par un circuit de traitement, par exemple d’un dispositif de traçage du type précité. Selon un autre aspect, il est proposé un support d’enregistrement non transitoire, lisible par un ordinateur, sur lequel est enregistré un tel programme. D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1 montre un exemple de contexte d’application d’un procédé au sens de la présente description, dans un réseau collaboratif. Fig. 2 montre un premier mode de réalisation possible du procédé. Fig. 3 montre un deuxième mode de réalisation possible du procédé, plus sophistiqué et basé notamment sur des horodates de communication via un terminal en tant que relai. Fig. 4 montre un troisième mode de réalisation possible du procédé, basé sur un nombre d’occurrences de communications déjà relayées par un même terminal. Ci-après, on désigne par : - Equipement Communicant (EC) tout objet communicant déployé dans la cadre d’une application de type Internet des Objets (IoT), ces objets pouvant communiquer via une interface radiofréquence de proximité, notée I-Prox (type Bluetooth ou équivalent). - Relai Mobile (portant la référence RM sur les dessins) un terminal cellulaire, mobile, et doté d’une interface radiofréquence de proximité I-Prox (type Bluetooth ou équivalent) et d’une interface radiofréquence longue portée I-Cloud (liaison cellulaire ou équivalent). Le système d’information ou Backend BE, comprenant des entités de traitement et de stockage des informations concernant le réseau collaboratif. Les terminaux RM se connectent aux équipements EC via une liaison I-Prox. Les terminaux RM se connectent au backend BE via la liaison I-Cloud. La notation UL désigne la voie montante des données issues d’un ou plusieurs équipements EC en formant donc la chaîne : EC -> RM -> BE. La notation DL désigne la voie descendante des données destinées à un ou plusieurs équipements EC en formant donc la chaîne : BE -> RM -> EC. Dans une trame de communication de données, les données proprement dites à transmettre sont dans une section dite de Data-Payload (ou PLD) contenant alors l’information qui doit être transportée par l’intermédiaire de relais mobiles RM. Le backend BE est capable d’identifier des équipements EC et des relais mobiles RM intervenant dans chaque communication. Chaque équipement EC ou terminal RM peut être identifié par un identifiant donné, ou « identificateur » ci-après, tel que par exemple adresse réseau de type MAC ou tout autre identificateur applicatif. Il est possible en outre de prévoir des identificateurs spéciaux permettant d’adresser un groupe complet d’équipements ou terminaux (par exemple un identifiant de diffusion ou « broadcast » à tous les équipements liés à une application ou à un client). En faisant référence à nouveau à l’architecture présentée dans la ci-avant, un data-payload est disponible au niveau du backend BE et il est souhaité le transférer sur un équipement communicant ciblé EC en organisant une voie descendante à cet effet. Il convient alors de sélectionner un ou plusieurs terminaux RM agissant comme relais mobiles susceptibles de se trouver (éventuellement) à proximité de l’équipement ciblé EC. Ensuite le data-payload est transmis aux terminaux RM sélectionnés, via l’interface I-Cloud et une fois qu’une proximité avec l’équipement EC ciblé est détectée sur l’interface I-Prox, le data-payload est transféré à l’équipement EC ciblé. On décrit ci-après comment sélectionner les terminaux mobiles faisant relais RM et capables de réaliser ce transfert du data-payload. Pour la réalisation de la voie descendante DL, il est adjoint au backend BE un dispositif de traçage DT des interactions en voie montante UL au moins, pour une mise en œuvre de l’objet de la présente description. Un tel dispositif DT est capable d’analyser les flux de données (notamment via la voie montante), d’archiver ainsi le contenu d’une base de données d’historiques des interactions des équipements avec des relais mobiles (cette base de données étant présentée plus loin), et d’utiliser ensuite le contenu de cette base de données pour organiser les communications par la voie descendante. Comme illustré sur la , un tel dispositif DT peut comporter un circuit de traitement comprenant notamment une mémoire MEM pour le stockage des instructions d’un programme informatique au sens de la présente description, et un processeur PROC capable de coopérer avec la mémoire MEM pour lire et exécuter les instructions de ce programme. Bien entendu, ce circuit de traitement peut comporter en outre une interface de communication avec la base de données précitée BDH et avec le système d’information backend BE. Ainsi à chaque transfert de données en voie montante UL un ensemble d’informations sont sauvegardées afin de pouvoir tracer un historique des interactions entre équipements communicants EC et terminaux mobiles relais RM. Ces informations sont stockées et organisées dans la base de données d’historique BDH, stockant alors au moins : - les données d’une occurrence d’interaction comprenant un identifiant de l’objet communicant EC-ID, - un identifiant du terminal relai ID-RM, - le cas échéant un identifiant d’application ID-APP si l’interaction était dans le cadre d’une application spécifique, - éventuellement un identifiant de localisation ID-LOC, - une horodate HOR, - une information sur le sens de communication UL ou DL. L’identifiant d’application ID-APP permet typiquement de regrouper l’ensemble des objets communicants EC liés à une application donnée. L’indicateur UL ou DL donne la possibilité de tracer les interactions en voie descendante et en faire la distinction si souhaité. Le formatage de ces informations est standard et ces données peuvent être accessibles typiquement dans des en-têtes de trames de communication, en plus du champ des données utiles ou « payload » de ces trames. Ces informations sont accessibles au moins en voie montante, typiquement. Dans le cas notamment où les identifiants des terminaux et/ou des objets communicants, tels que des adresses dans un réseau en Bluetooth, sont variables d’une communication à l’autre (par exemple pour des raisons de confidentialité ou autres), une application spécifique peut être installée dans ces équipements pour assigner un identifiant fixe à chaque terminal relai et/ou à chaque équipement communicant, et cet identifiant peut être ajouté en tant que donnée additionnelle, de type métadonnée par exemple (accompagnant des données d’horodate, de localisation ou autres), dans le champ de payload. On retiendra ainsi que le dispositif de traçage DT peut ainsi rassembler ces données (disponibles notamment en voie montante, initialement) et alimenter la base de données BDH, de manière générale. L’architecture de la base BDH permet en outre au dispositif de traçage DT de formuler des requêtes pour récupérer une liste des interactions impliquant un équipement EC et/ou un relai mobile RM. Il est possible de formuler des requêtes permettant de filtrer des interactions selon des critères spécifiques de la base BDH, comme des horodates ou des localisations particulières ou de combiner des filtres de requêtes (ID-RM et localisation et horodate précises, par exemple). Afin de déterminer un groupe de relais mobiles RM susceptibles de se trouver à proximité d’un équipement communicant EC, il est présenté ci-après trois groupes d’étapes algorithmiques. Il est proposé en premier lieu un algorithme simple, puis un algorithme amélioré, capable d’accommoder des équipements EC qui ne se déplacent pas (ou se déplacent très peu en restant dans une même portée radiofréquence de courte portée de type Bluetooth) et enfin un troisième algorithme capable d’accommoder des équipements EC susceptibles de se déplacer (au-delà d’une portée radiofréquence de type Bluetooth). En référence à la , lors d’une première étape S10 de désignation d’un équipement ciblé EC à adresser en voie descendante, un identificateur ID-EC de cet équipement est fourni comme entrée d’interrogation de la base de données BDH à l’étape S11. La requête d’interrogation vise à chercher dans la base BDH une liste LST des interactions passées concernant cet identificateur ID-EC. A partir de cette liste LST obtenue à l’étape S12, on extrait à l’étape S13 tous les identificateurs de relais mobiles RM présents dans cette liste et donc impliqués précédemment dans une communication avec cet équipement EC (en voie montante et éventuellement déjà en voie descendante). A l’étape S14, pour chaque identificateur ID-RMj de relai mobile, on compte le nombre d’occurrences de cet identificateur ID-RMj dans la liste LST. A l’étape S15, on identifie le relai mobile RMi ayant un nombre Ni maximal d’occurrences dans la liste LST et on peut sélectionner comme relai le terminal mobile RMi ayant ce nombre Ni maximal d’occurrences dans la liste à l’étape S16. Alternativement ici, on peut sélectionner plutôt K relais mobiles dont les nombres Nj sont supérieurs à un seuil par exemple, en privilégiant ainsi toujours les identificateurs dont les compteurs sont les plus élevés mais en sélectionnant plus d’un terminal. Le nombre K peut être un paramètre fixé à l’avance ou de façon dynamique selon un critère choisi. A l’étape S16, dans ce cas, on obtient alors une liste de K terminaux mobiles RMi comme relais possibles. En référence maintenant à la , sur la base de l’algorithme simple de la , un algorithme optimisé permet, grâce à des heuristiques appliqués aux informations historiques des interactions passées et stockées dans la base BDH, de mieux tirer profit de la stationnarité ici des équipements communicants ciblés EC, mais de tenir compte à l’inverse de la mobilité des terminaux relais sur le terrain. On cherche à identifier les relais mobiles « récidivistes » par rapport à un ou plusieurs objets communicants cibles EC, par exemple une flotte d’objets communicants statiques. Ainsi, on cherche un ou plusieurs relais mobiles qui auraient été en interaction avec au moins l’un de ces objets communicants cibles plusieurs fois. Dans la liste des interactions avec un équipement cible donné EC, l’identificateur d’un relais mobile « récidiviste » devrait être référencé plusieurs fois. Ainsi, pour un identificateur donné d’équipement cible EC supposé stationnaire à l’étape S20 de la , on cherche à l’étape S21 dans la base BDH la liste des interactions concernant cet identificateur, cette liste LST étant obtenue à l’étape S22. On détermine en particulier dans cette liste LST une date limite de validité. A cet effet par exemple, on peut appliquer un filtre de recherche dans la liste qui est fonction de la date de l’interaction la plus ancienne de l’équipement cible avec un terminal dont la localisation est encore compatible à la localisation de l’interaction la plus récente de l’équipement cible avec un terminal. Concrètement, une réalisation possible consiste, à l’étape S23, à déterminer la localisation courante LOC CUR de la dernière interaction ayant eu lieu avec cet équipement EC. Il s’agit donc de la dernière en date dans la liste LST, à l’horodate HR NEW. Ensuite, à l’étape S24, on ne retient de la liste LST que les interactions ayant la même localisation LOC CUR. On détermine ainsi à l’étape S25, la date limite de validité de la localisation courante LOC CUR, probable de l’équipement EC, et il est alors possible d’identifier des terminaux, dans la même localisation, susceptibles d’interagir encore avec l’équipement EC. Ainsi, à l’étape S26, on élimine de la liste LST les interactions plus anciennes que cette date limite. Ensuite, on peut trier la liste résultante par nombre d’interactions par identificateur de relais mobile (compté à l’étape S27, similaire à l’étape S14 de la ), en éliminant en particulier les identificateurs de relais mobiles non récidivistes (au test S28), pour sélectionner finalement à l’étape S29 les identificateurs de relais mobiles ayant eu un nombre plus grand ou égal à L interactions (L étant un paramètre fixé initialement ou de façon dynamique selon un critère choisi). On peut ainsi établir une liste de relais mobiles ainsi sélectionnés. Dans une forme de réalisation où l’on cherche à traiter la mobilité des objets communicants sans pour autant utiliser des informations de nature géographique les concernant, on raisonne toujours sur les interactions passées entre un équipement communicant cible EC, donné, et des relais mobiles, fournies par la base de données BDH, et on se fie ici au grand nombre et à la mobilité des relais mobiles RM pour garantir éventuellement une interaction future d’au moins un relais mobile sélectionné avec l’équipement communicant cible. A cet effet, on prévoit un algorithme de type « best effort » pour des équipements communicants EC en situation de mobilité maintenant. Le groupe de relais mobiles sélectionnés se présente en deux sous-groupes. Le premier sous-groupe est constitué de relais mobiles qui ont déjà interagi avec l’équipement communicant cible EC. Ensuite on attribue à chacun de ces relais mobile une priorité de sélection en fonction du nombre d’équipements communicants EC différents avec lesquels un relais mobile a déjà été en interaction (en plus de l’équipement communicant cible EC). Grâce à cette priorité de sélection, on maximise ainsi la probabilité qu’au moins l’un des relais mobiles ainsi sélectionnés puisse éventuellement être en interaction avec l’équipement communicant cible EC. Le deuxième sous-groupe contient des relais mobiles qui ont un grand nombre d’interactions indépendamment de l’équipement communicant cible EC. Ce deuxième sous-groupe couvre le cas des équipements communicants cibles dont la mobilité et les interactions ne présentent pas de caractéristiques spécifiquement récurrentes, ce qui peut alors enrichir une sélection de relais mobiles dans le premier sous-groupe qui est restreinte à l’historique des interactions des relais mobiles avec cet équipement communicant EC seulement. Ainsi, en référence maintenant à la , pour un identificateur de l’équipement communicant cible EC donné à l’étape S30, on cherche dans la base BDH à l’étape S31 la liste LST des interactions concernant cet identificateur. Pour chaque identificateur de relais mobile dans la liste, on calcule sa priorité de sélection à partir du nombre des identificateurs différents des équipements communicants EC avec lesquels ce relais mobile a déjà interagi. On établit ensuite une liste des identificateurs de relais mobiles avec leur priorité. On trie en particulier cette liste par priorité de relais mobile, pour former à l’étape S32 le premier sous-groupe en sélectionnant les M identificateurs de relais mobiles en tête de liste (les plus prioritaires). On cherche ensuite dans la base BDH la liste des relais mobiles indépendants de l’identificateur de l’équipement communicant cible EC. Pour chaque identificateur de relais mobile dans la liste, on calcule sa priorité de sélection à partir du nombre des identificateurs différents des équipements communicants avec lesquels chaque relais mobile a interagi. On établit une liste des identificateurs de relais mobiles, triée par priorité de relais mobile. On forme ainsi à l’étape S33 le deuxième sous-groupe en sélectionnant les N premiers identificateurs de relais mobiles dans cette liste triée. La liste finalement des relais mobiles sélectionnables est constituée de l’union des premier et deuxième sous-groupes précités à l’étape S34. Les nombres M et N sont des paramètres fixés a priori ou de façon dynamique selon un critère choisi. Par exemple, on peut fixer N=0 initialement, et en cas de non réponse par exemple d’un équipement cible EC par liaison montante, augmenter N progressivement jusqu’à obtenir une réponse, ce qui peut montrer que la transmission par la voie descendante ainsi construite a pu être effective. Par ailleurs, on peut déterminer le profil de mobilité (stationnaire ou mobile) d’un équipement cible EC, comme suit. Un objet communicant dont la localisation des interactions n’a pas évolué pendant une période donnée (cette période étant un paramètre qui peut être tiré de la base BDH, par exemple fixé a priori sur la base de considérations applicatives) peut être défini comme stationnaire. Dans le cas contraire, il est considéré comme mobile. Dans ce dernier cas, il est possible de traiter les localisations des interactions de cet objet communicant afin d’estimer la fréquence de changement de localisation et ainsi qualifier le profil de mobilité comme étant rapide ou lent. Cette qualification supplémentaire permet alors de raffiner le paramétrage algorithmique et de choisir par exemple entre le traitement de la ou le traitement de la . De manière plus générale, la présente divulgation ne se limite pas aux exemples de réalisation décrits ci-avant, seulement à titre d’exemple, mais elle englobe d’autres variantes envisageables pour un homme de l’art. Par exemple, on peut prévoir en outre une sélection aléatoire des terminaux mobiles qui sont utilisés comme relais, comme suit, afin d’égaliser autant que possible les charges des terminaux et éviter ainsi que les mêmes terminaux soient systématiquement retenus pour effectuer le relai. Dans cette réalisation, chaque fois qu’un choix de K relais mobiles a été réalisé, on sélectionne d’abord N > K relais et ensuite il est réalisé une sélection aléatoire de K relais parmi les N relais. Par ailleurs, pour accommoder plusieurs équipements communicants cibles, on peut donner une liste des identificateurs RM en répétant l’algorithme simple autant de fois qu’on a d’identificateurs d’équipements communicants cibles comme décrit ci-avant, ou alternativement fournir une adresse générique (de type broadcast ou multicast) de sorte que la recherche dans la base BDH fournisse les interactions passées de tous les équipements communicants. Il est possible en outre de construire des identificateurs de groupes composites qualifiés par des filtres de sélection géographiques. Par exemple, on peut identifier les objets communicants d’une application A, du client B et qui sont localisés dans une région C. Par ailleurs, on a décrit ci-avant une réalisation possible où un terminal mobile de type smartphone, par exemple relié au réseau cellulaire, assure un relai. D’autres types de terminaux peuvent être utilisés néanmoins dans le cadre de la présente description, par exemple des ordinateurs ou tablettes et éventuellement connectés à un réseau autre que cellulaire (par exemple via une passerelle ou un hotspot wifi). De même, les objets communicants précités sont au sens plus général tout équipement doté d’une interface de radiofréquence courte portée par exemple de type Bluetooth (ou Bluetooth Low Energy, « BLE »). Par ailleurs, l’interface de proximité I-Prox précitée peut être animée par le protocole Bluetooth (ou BLE) ou par des protocoles de type balise (ou « beacon ») sur BLE par exemple. De même, l’interface I-Cloud peut correspondre à une interface cellulaire utilisant par exemple mais non exclusivement des protocoles de type MQTT(S) ou autres (pour « Message Queuing Telemetry Transport »). Le backend peut se présenter sous la forme d’une ou plusieurs plateformes dans le « nuage » (ou « cloud ») de type LiveObject, ou autre. Ainsi, l’objet de la présente description offre très avantageusement des possibilités de mise en œuvre d’une voie descendante dans un réseau collaboratif de télécommunications. La mise en œuvre d’une telle voie descendante trouve de nombreuses applications. Elle permet notamment mais non limitativement d’agir à distance dans les réseaux de capteurs-actionneurs par exemple, de reparamétrer des objets communicants (mise à jour horloge/date, localisation etc.), de mettre à jour des logiciels de fonctionnement (de type firmware ou autre) des objets communicants, de mise à jour de clés de cryptage d’objets communicants ou autres. Procédé de traitement de données pour établir une communication selon une voie descendante depuis un système d’information (BE) vers un équipement communiquant cible (EC) via au moins un terminal (RM) dans un réseau collaboratif, le terminal (RM) relayant la communication entre le système d’information (BE) et l’équipement communicant cible (EC), le procédé comportant, au niveau du système d’information (BE) : - obtenir des identifiants de terminaux (RM) ayant relayé des communications précédentes au moins en voie montante entre des équipements communicants (EC) et le système d’information (BE), et alimenter avec au moins lesdits identifiants une base de données (BDH) stockant des données d’historique de communication dans le réseau collaboratif, - et, pour établir la communication en voie descendante vers l’équipement communicant cible (EC), interroger la base de données pour sélectionner au moins un terminal (RM) susceptible de relayer la communication en voie descendante vers l’équipement communicant cible (EC) et initier la communication en voie descendante via le terminal ainsi sélectionné. Procédé selon la revendication 1, dans lequel les données d’historique de la base de données (BDH) comportent, outre les identifiants de terminaux ayant relayé une communication, des données d’horodates respectives de communication via lesdits terminaux, et dans lequel, pour établir la communication en voie descendante vers l’équipement communicant cible (EC), la base de données est interrogée pour sélectionner au moins un terminal (RM) ayant une horodate de relai de communication pour l’équipement communicant cible (EC) la plus récente. Procédé selon l'une des revendications précédentes, dans lequel la base de données est interrogée pour sélectionner une pluralité de terminaux (RM), une partie au moins des terminaux sélectionnés étant utilisée pour relayer la communication en voie descendante vers l’équipement communicant cible (EC). Procédé selon la revendication 3, dans lequel les données d’historique de la base de données (BDH) comportent, outre les identifiants de terminaux ayant relayé une communication, des données d’horodates respectives de communication via lesdits terminaux et des données de localisations respectives desdits terminaux auxdites horodates, et dans lequel la base de données est interrogée pour sélectionner une pluralité de terminaux (RM) ayant des horodates de relai de communication pour l’équipement communicant cible (EC) les plus récentes et à une même localisation, une partie au moins des terminaux sélectionnés étant utilisée pour relayer la communication en voie descendante vers l’équipement communicant cible (EC). Procédé selon l’une des revendications précédentes, dans lequel la base de données est interrogée pour compter, pour chaque terminal ayant précédemment relayé des communications pour l’équipement communicant cible (EC), un nombre d’occurrences de relai pour cet équipement communicant cible (EC), et dans lequel on sélectionne au moins une première partie de terminaux ayant un nombre d’occurrences supérieur à un premier seuil choisi (M), en vue de relayer la communication en voie descendante vers l’équipement communicant cible (EC). Procédé selon la revendication 5, dans lequel la base de données est interrogée en outre pour compter, pour chaque terminal ayant précédemment relayé des communications pour tout équipement communicant (EC), un nombre total d’occurrences de relai, et dans lequel on sélectionne, outre la première partie, une deuxième partie de terminaux ayant un nombre total d’occurrences supérieur à un deuxième seuil choisi (N), en vue de relayer la communication en voie descendante vers l’équipement communicant cible (EC). Procédé selon la revendication 5, dans lequel la base de données est interrogée en outre pour compter, pour chaque terminal donné (RM), le nombre d’équipements communicants, autres que l’équipement cible (EC), et pour lesquels le terminal donné (RM) a précédemment relayé au moins une communication, et dans lequel on sélectionne, outre la première partie, une deuxième partie de terminaux ayant ledit nombre d’équipements autres que l’équipement cible (EC), supérieur à un deuxième seuil choisi (N), en vue de relayer la communication en voie descendante vers l’équipement communicant cible (EC). Procédé selon l’une des revendications précédentes, dans lequel les données d’historique de la base de données (BDH) comportent, outre les identifiants de terminaux ayant relayé une communication, des données d’horodates respectives de communication via lesdits terminaux et des données de localisations respectives desdits terminaux auxdites horodates, et la base de données (BDH) est interrogée pour déterminer un écart temporel d’horodates de relai par des terminaux situés à une même localisation, pour un équipement communicant cible donné (EC), afin d’évaluer un degré de mobilité de cet équipement communicant cible donné (EC). Procédé selon la revendication 8, prise en combinaison avec la revendication l’une des revendications 5 à 7, dans lequel : - si le degré de mobilité est inférieur à un seuil, on sélectionne les terminaux (RM) ayant des horodates de relai de communication pour l’équipement communicant cible (EC) les plus récentes et à une même localisation, - si le degré de mobilité est supérieur à un seuil, on sélectionne au moins ladite première partie de terminaux, une partie au moins des terminaux sélectionnés étant utilisée pour relayer la communication en voie descendante vers l’équipement communicant cible (EC). Procédé selon l'une des revendications précédentes, dans lequel la base de données est interrogée en outre pour compter, pour chaque terminal ayant précédemment relayé des communications pour tout équipement communicant (EC), un nombre total d’occurrences de relai, et dans lequel on exclut de la sélection de terminaux pour relayer la communication en voie descendante vers l’équipement communicant cible (EC), les terminaux ayant un nombre total d’occurrences de relai supérieur à un seuil choisi. Procédé selon l'une des revendications précédentes, dans lequel on tire aléatoirement, dans la sélection de terminaux, des terminaux choisis pour relayer la communication en voie descendante vers l’équipement communicant cible (EC). Procédé selon l'une des revendications précédentes, dans lequel une partie au moins des terminaux (RM) du réseau collaboratif sont des terminaux mobiles. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 12, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement. Système de traitement de données pour établir une communication selon une voie descendante depuis un système d’information (BE) vers un équipement communicant cible (EC) via au moins un terminal (RM) dans un réseau collaboratif, le terminal (RM) relayant la communication entre le système d’information (BE) et l’équipement communicant cible (EC), le système de traitement comportant : - un dispositif de traçage d’identifiants de terminaux (RM) ayant relayé des communications précédentes au moins en voie montante entre des équipements communicants (EC) et le système d’information (BE), et - une mémoire pilotée par le dispositif de traçage pour stocker des données d’historique de communication dans le réseau collaboratif, lesdites données étant organisées selon une base de données (BDH) alimentée avec au moins lesdits identifiants, le dispositif de traçage étant configuré en outre pour interroger la base de données pour sélectionner au moins un terminal (RM) susceptible de relayer la communication en voie descendante vers l’équipement communicant cible (EC), et pour délivrer un identifiant du terminal sélectionné au système d’information (BE) pour initier la communication en voie descendante via ledit terminal sélectionné. Dispositif de traçage d’un système de traitement selon la revendication 14, comportant un circuit de traitement configuré pour coopérer au moins avec la mémoire de stockage de la base de données d’historique (BDH), pour la mise en œuvre du procédé selon l’une des revendications 1 à 12.