FR 3084233 A1 20200124 FR 1856654 A 20180718 La présente invention concerne un dispositif et un procédé permettant de faire transporter des trames émises par un terminal sur un réseau sans fil à grande portée et à faible consommation d'énergie par un réseau de communication par courants porteurs en ligne d'un système de gestion automatique de relevés de compteurs électriques. Avec l'apparition récente de l'intemet des objets (« Internet of Things (IoT) » en terminologie anglo-saxonne) est apparu un nouveau type de réseaux : les réseaux sans fil à grande portée et à faible consommation d'énergie (« Low Power Wide Area Network (LPWAN) », en terminologie anglo-saxonne). Parmi ces réseaux LPWAN, on peut citer des réseaux basés sur la technologie LoRa (marque déposée) (« Long Range» en terminologie anglo-saxonne) et les réseaux de la société Sigfox. Un réseau basé sur la technologie LoRa (appelé « réseau LoRa » par la suite) utilise un protocole appelé LoRaWAN. Un réseau LoRa est composé de stations de base ou passerelles (« gateways » en terminologie anglo-saxonne) généralement placées sur des points hauts afin de couvrir une grande zone géographique. Les passerelles, appelées passerelles LoRa par la suite, sont aptes à détecter des messages émis dans leur zone par des équipements ou terminaux (« endpoints » en terminologie anglo-saxonne) et à les remonter vers au moins un serveur (« LoRa Network Server (LNS) » en terminologie anglo-saxonne), appelé serveur LNS par la suite, qui les traitera. Dans un fonctionnement classique d'un réseau LoRa, un terminal désirant transmettre un message (Le. des données) au serveur LNS, transmet ce message dans une trame, dite trame LoRa montante, conforme au protocole LoRaWAN. La trame LoRa montante est transmise en mode multidiffusion (« broadcast » en terminologie anglo-saxonne). Cette trame LoRa montante est reçue par au moins une passerelle LoRa. Chaque passerelle LoRa ayant reçu la trame LoRa montante la décode et retransmet le message au serveur dans une requête HTTP (protocole de transfert hypertext, « HyperText Transfer Protocol » en terminologie anglo-saxonne). Si plusieurs passerelles LoRa ont reçu la trame LoRa montante, le serveur reçoit plusieurs requêtes HTTP contenant le message. Le serveur doit alors désigner parmi les passerelles LoRa ayant reçu la trame LoRa montante, la passerelle LoRa à utiliser pour relayer une réponse au message contenu dans la trame LoRa montante. La réponse est transmise du serveur à la passerelle LoRa désignée dans une requête 5 HTTP, puis en point à point, de la passerelle LoRa désignée au terminal dans une trame LoRa descendante conforme au protocole LoRaWAN. Bien que les réseaux LPWAN se répandent de plus en plus, il existe des zones hors de portée de ces réseaux. Ces zones n'ont alors pas accès à l'internet des objets. D'autres réseaux offrent une couverture beaucoup plus fine des territoires, 10 notamment dans les pays développés. On peut notamment penser aux réseaux électriques. Les réseaux électriques, qui à la base étaient destinés exclusivement au transport d'électricité, ont évolué dernièrement pour devenir des réseaux dans lesquels des données peuvent circuler. Les réseaux de communication par courants porteurs en ligne (« PowerLine Communications » en terminologie anglo-saxonne) pour des 15 systèmes de type AMM (gestion automatique de relevés de compteurs, « Automated Meter Management » en terminologie anglo-saxonne) utilisent ainsi des infrastructures des réseaux électriques pour créer un réseau, dit réseau logique. Parmi ces réseaux logiques, dits réseaux CPL (Courants Porteurs en Ligne), on peut citer les réseaux conformes aux spécifications PRIME (« PoweRline Intelligent Metering 20 Evolution » en terminologie anglo-saxonne) ou les réseaux conformes au standard G3- PLC spécifié dans la recommandation ITU-T G.9903. Dans les réseaux CPL, des communications sont établies entre des compteurs électriques, dits intelligents (« smart electrical meters » en terminologie anglo-saxonne), et un dispositif appelé concentrateur de données (« data concentrator » en terminologie anglo-saxonne) pour 25 permettre notamment une relève automatisée à distance de mesures de consommation électrique effectuées par lesdits compteurs électriques intelligents. Par la suite nous appelons simplement compteur chaque compteur électrique intelligent. Une pluralité de concentrateurs de données est typiquement géographiquement déployée dans un réseau CPL de manière à répartir la charge de gestion à distance d'une multitude de 30 compteurs. Chaque concentrateur de données est lui-même connecté à une même unité centralisée permettant la gestion du système de type AMM qui est gérée par un opérateur du réseau d'alimentation électrique auquel lesdits compteurs sont connectés. Comme l'indique l'acronyme AMM, les réseaux CPL, pour les systèmes de type AMM, sont destinés à transporter des données de métrologie émanant de compteurs. Rien n'est prévu, ni en termes matériels, ni en termes protocolaires, pour transporter autre chose que des données de métrologie provenant de compteurs. Les réseaux électriques, qui, contrairement aux réseaux LPWAN, couvrent finement les territoires, ne peuvent donc, à l'heure actuelle, être utilisés pour transporter des données 5 provenant d'objets connectés dans des zones non couvertes par les réseaux LPWAN. Il est souhaitable de pallier ces inconvénients de l'état de la technique. Il est notamment souhaitable de proposer un procédé et un dispositif permettant de bénéficier de la couverture d'un réseau CPL pour les systèmes de type AMM pour acheminer vers un serveur LNS des données en provenance d'objets connectés qui 10 seraient hors de portée d'un réseau LPWAN. Le procédé et le dispositif doivent préférentiellement assurer une rétrocompatibilité avec les systèmes existant et notamment avec des serveurs LNS existants. Les données de métrologie étant prioritaires sur les réseaux CPL pour les systèmes de type AMM, le procédé proposé doit, par ailleurs, assurer que le transport de données provenant d'objets connectés 15 n'affecte pas le transport des données de métrologie. Il est de plus souhaitable de fournir une solution qui soit simple à mettre en oeuvre et à faible coût. Selon un premier aspect de la présente invention, la présente invention concerne un dispositif permettant d'échanger des premières trames, dites trames LPWAN, entre 20 un terminal et un serveur, ledit terminal étant adapté pour échanger des trames LPWAN avec au moins une passerelle, dite passerelle LPWAN, par l'intermédiaire d'un premier réseau sans fil à grande portée et à faible consommation d'énergie, et le serveur étant adapté pour échanger des trames LPWAN avec des passerelles LPWAN, chaque trame LPWAN échangée entre le terminal et le serveur devant transiter par au 25 moins un compteur et un concentrateur de données compris dans un deuxième réseau de communication par courants porteurs en ligne et formant un système de gestion automatique de relevés d'une pluralité de compteurs électriques, dit système AMM, au moins un compteur dudit système AMM implémentant une passerelle LPWAN et comportant une interface de communication lui permettant d'échanger des trames 30 LPWAN avec ledit terminal par l'intermédiaire du premier réseau. Le dispositif est relié à chaque concentrateur de données par l'intermédiaire d'un troisième réseau et au serveur par l'intermédiaire d'un quatrième réseau et en ce que chaque trame LPWAN échangée entre ledit terminal et le serveur transite par le dispositif, chaque trame LPWAN échangée entre le dispositif et le serveur est encapsulée dans une deuxième trame conforme à un format de trames que le serveur échangerait avec une passerelle LPWAN, et lorsqu'une trame LPWAN émise par le terminal est reçue directement par une pluralité de compteurs et par une pluralité de concentrateurs de données du deuxième réseau de sorte que le dispositif reçoit plusieurs copies de la trame LPWAN, 5 le dispositif est adapté pour transmettre une seule copie de la trame LPWAN au serveur, ladite trame LPWAN étant associée dans la deuxième trame à une information représentative d'un des compteurs ayant reçu directement la trame LPWAN choisi par le système intermédiaire suivant un critère prédéterminé. Selon un deuxième aspect de l'invention, l'invention concerne un système de 10 communication comprenant un terminal et un serveur, ledit terminal étant adapté pour échanger des trames LPWAN avec au moins une passerelle, dite passerelle LPWAN, par l'intermédiaire d'un premier réseau sans fil à grande portée et à faible consommation d'énergie, et le serveur étant adapté pour échanger des trames LPWAN avec des passerelles LPWAN, chaque trame échangée entre le terminal et le serveur 15 devant transiter par un compteur et un concentrateur de données compris dans un deuxième réseau de communication par courants porteurs en ligne d'un système de gestion automatique de relevés d'une pluralité de compteurs électriques, dits compteurs, lesdits compteurs de la pluralité de compteurs étant rattachés à au moins un concentrateur de données via le deuxième réseau, au moins un compteur de la 20 pluralité implémentant une passerelle LPWAN et comportant une interface de communication lui permettant d'échanger des trames LPWAN avec ledit terminal par l'intermédiaire du premier réseau. Le système comprend un dispositif selon le premier aspect. Selon un troisième aspect de l'invention, l'invention concerne un procédé 25 permettant d'échanger des premières trames, dites trames LPWAN, entre un terminal et un serveur, ledit terminal étant adapté pour échanger des trames LPWAN avec au moins une passerelle, dite passerelle LPWAN, par l'intermédiaire d'un premier réseau sans fil à grande portée et à faible consommation d'énergie, et le serveur étant adapté pour échanger des trames LPWAN avec des passerelles LPWAN, chaque trame 30 LPWAN échangée entre le terminal et le serveur devant transiter par au moins un compteur et un concentrateur de données reliés entre eux par un deuxième réseau de communication par courants porteurs en ligne et formant un système de gestion automatique de relevés d'une pluralité de compteurs électriques, au moins un compteur implémente une passerelle LPWAN et comporte une interface de communication lui permettant d'échanger des trames LPWAN avec ledit terminal par l'intermédiaire du premier réseau. Le procédé est exécuté par un dispositif intermédiaire relié à chaque concentrateur de données par l'intermédiaire d'un troisième réseau et au serveur par l'intermédiaire d'un quatrième réseau de sorte que 5 chaque trame LPWAN échangée entre ledit terminal et le serveur transite par le dispositif intermédiaire, chaque trame LPWAN échangée entre le dispositif intermédiaire et le serveur étant encapsulée dans une deuxième trame conforme à un format de trames que le serveur échangerait avec une passerelle LPWAN, et comprend : recevoir (415) une ou plusieurs copies d'une même trame LPWAN émise 10 par le terminal de la part d'une pluralité de concentrateur de données, la trame LPWAN ayant été reçue directement par une pluralité de compteurs ; et, transmettre une seule copie de la trame LPWAN au serveur, ladite trame LPWAN étant associée dans la deuxième trame à une information représentative d'un des compteurs ayant reçu directement la trame LPWAN, choisi par le système intermédiaire suivant un 15 critère prédéterminé. Selon un mode de réalisation, le critère prédéterminé consiste à choisir la première copie de la trame LPWAN reçue ou aléatoirement une copie de la trame LPWAN ou une copie de la trame LPWAN reçue avec la meilleure qualité par un compteur du deuxième réseau. 20 Selon un mode de réalisation, lorsque suite à la transmission d'une trame LPWAN au serveur, la trame LPWAN ayant été reçue directement par une pluralité de compteurs, le dispositif intermédiaire reçoit une trame de réponse destinée au terminal de la part du serveur, le serveur ayant inséré dans la trame de réponse un identifiant d'un compteur choisi par le serveur pour relayer ladite trame de réponse vers le 25 terminal, le procédé comprend : déterminer le compteur de la pluralité de compteurs ayant reçu la trame LPWAN avec la meilleure qualité ; et, insérer un identifiant du compteur déterminé dans la trame de réponse à la place de l'identifiant inséré par le serveur. Selon un mode de réalisation, chaque trame LPWAN comprise dans une 30 deuxième trame est encapsulée au format JSON. Selon un quatrième aspect de l'invention, l'invention concerne un programme d'ordinateur comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon le troisième aspect lorsque ledit programme est exécuté par un processeur dudit dispositif Selon un cinquième aspect de l'invention, l'invention concerne des moyens de stockage, stockant un programme d'ordinateur comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon le premier aspect lorsque ledit programme est exécuté par un processeur dudit dispositif 5 Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : - la Fig. 1 illustre schématiquement un exemple de système de type AMM dans 10 lequel est mise en oeuvre l'invention ; - la Fig. 2 illustre schématiquement une représentation d'un réseau logique correspondant à un réseau physique illustré dans la Fig. précédente; - La Fig. 3 illustre schématiquement un exemple d'architecture matérielle d'un module de traitement ; 15 - la Fig. 4 illustre schématiquement un exemple de mise en oeuvre dans un système de type AMM d'un procédé permettant d'acheminer des trames émises par un terminal sur un réseau de type LPWAN ; - la Fig. 5 illustre schématiquement une encapsulation d'une trame LoRa montante dans une trame G3-PLC ; 20 - la Fig. 6 illustre schématiquement une encapsulation d'une trame LoRa montante dans une trame HTTP; - la Fig. 7 illustre schématiquement une encapsulation dans le format JSON d'une trame LoRa montante dans une trame HTTP ; - la Fig. 8 illustre schématiquement une encapsulation dans le format JSON 25 d'une trame LoRa descendante dans une trame HTTP; - la Fig. 9 illustre schématiquement une encapsulation d'une trame LoRa descendante dans une trame HTTP; - la Fig. 10 illustre schématiquement une encapsulation d'une trame LoRa descendante dans une trame G3-PLC; et, 30 - la Fig. 11 illustre schématiquement une procédure d'autorisation de connexion adaptée à l'invention. L'invention est décrite dans un contexte de réseau CPL d'un système de type AMIVI dans lequel les communications sont basées sur le protocole G3-PLC. Par ailleurs, comme nous le verrons par la suite, certains compteurs du réseau CPL comprennent une interface de communication permettant de communiquer sur un réseau LPWAN de type LoRa en utilisant des trames conformes au protocole LoRaWAN. L'invention pourrait tout aussi bien être utilisée dans un autre contexte. Le réseau CPL du système de type AMM pourrait tout aussi bien utiliser des 5 communications basées sur les spécifications PRIME. Par ailleurs, le réseau LPWAN pourrait être un réseau SigFox. La Fig. 1 illustre schématiquement un exemple de système de type AMM dans lequel est mise en oeuvre l'invention. Le système de type AMM de la Fig. 1 comporte un système de terminaison, dit 10 système HES (« Head End System (HES) » en terminologie anglo-saxonne) 140. Le système HES 140 reçoit des informations de mesure de consommation électrique collectées par une pluralité de compteurs 120A, 120B, 120C, 120D et 120E (notés 120A-E) et les traite. Pour permettre auxdits compteurs de transmettre lesdites informations au système HES 140, des communications CPL sont établies entre 15 chacun desdits compteurs et un concentrateur de données 110. Le système de communication comporte typiquement une pluralité de concentrateurs de données 110, un seul étant représenté sur la Fig. 1. A chaque concentrateur de données 110 est connectée, de manière logique, une pluralité de compteurs. Un réseau CPL 101 est ainsi formé entre chaque concentrateur de données 110 20 et la pluralité de compteurs qui lui est connectée. Ce réseau CPL 101 s'appuie sur un réseau de distribution électrique 100 (i.e. réseau physique) servant à alimenter en électricité les installations électriques que lesdits compteurs 120A-E sont en charge de surveiller. Chaque compteur 120A-E comporte ainsi une interface 1 1 1 de communication CPL permettant de communiquer via le réseau CPL 101. De même, 25 chaque concentrateur de données 110 comporte une telle interface 1 1 1 de communication CPL permettant de communiquer via le réseau CPL 101. Selon un exemple de réalisation, le réseau CPL 101 est conforme au protocole G3-PLC. Dans la Fig. 1, chaque compteur 120A-E comprend une interface de communication 114 avec un réseau de type LPWAN de type LoRa, dit réseau LoRa. 30 Le réseau LoRa permet à chaque compteur 120A-E de communiquer avec des terminaux se trouvant à portée desdits compteurs, chaque terminal étant connecté au réseau LoRa par l'intermédiaire d'une même interface de communication 114. Dans la Fig. 1, deux terminaux de type objet connecté 160A et 160B sont représentés. Les compteurs 120A-E et les terminaux 160A et 160B communiquent selon le protocole LoRaWAN. Dans la Fig. 1, chaque trame LoRa montante émise en mode multidiffusion par le terminal 160A est reçue par les compteurs 120B et 120C. Chaque trame LoRa montante émise en mode multidiffusion par le terminal 160B est reçue par le compteur 120D. 5 Chaque trame LoRa montante émise par un terminal est destinée à un serveur 150, dit serveur de réseau LoRa (« LoRa Network Server (LNS) » en terminologie anglo-saxonne) ou serveur LNS. Le serveur LNS 150 reçoit les trames LoRa montantes collectées par le concentrateur de données 110 et les traite. Placé entre chaque concentrateur de données 110 et le système HES 140 et le 10 serveur LNS 150, le système de la Fig. 1 comprend un système intermédiaire 130, dit système réseau de retransmission ou système FNS (« Forwarding Network Sei-ver» en terminologie anglo-saxonne). Chaque trame échangée entre chaque concentrateur de données 110 et le système HES 140 ou le serveur LNS 150 transite par le système FNS 130. 15 Pour permettre de relayer les informations transmises par les compteurs 120A-E à destination du système HES 140, chaque concentrateur de données 110 comporte en outre une interface 115 de communication avec un réseau de communication 103, auquel est aussi connecté le système FNS 130. Le système FNS 130 comporte ainsi une interface 115 de communication via le 20 réseau de communication 103 lui permettant de communiquer avec une pluralité de concentrateurs de données 110. Le réseau de communication 103 est préférentiellement un réseau de type IP (« Internet Protocol » en terminologie anglo-saxonne, tel que défini dans le document normatif kW. 791), tel que l'Internet. Dans un mode de réalisation, les communications entre chaque concentrateur de données 25 110 et le système FNS 130 utilisent des requêtes HTTP. Le système HES 140 et le serveur LNS 150 comportent ainsi une interface de communication 113 via un réseau de communication 102 leur permettant de communiquer avec le système FNS 130. Le système FNS 130 comporte ainsi une interface de communication 113 via le réseau de communication 102 lui permettant de 30 communiquer avec le système HES 140 et le serveur LNS 150. Le réseau de communication 102 est préférentiellement un réseau de type IP. Dans un mode de réalisation, les communications entre le système HES 140 (respectivement le serveur LNS 150) et le système FNS 130 utilisent des requêtes HTTP. Le système FNS 130 est donc relié à chaque concentrateur de données 110 par l'intermédiaire du réseau 103 et au serveur LNS 150 par l'intermédiaire du réseau 102. Dans le système de la Fig. 1, chaque compteur possédant une interface de 5 communication 114 implémente une passerelle LoRa et joue donc un rôle similaire à une passerelle LoRa dans un réseau LoRa classique vis-à-vis des terminaux. Toutefois, comme nous le verrons par la suite en relation avec les Figs. 2 et 4, pour éviter de surcharger le système de type AMA4 par des requêtes LoRa, toutes les requêtes LoRa montantes reçues par un compteur 120A-E ne sont pas remontées vers 10 le système FNS 130. Chaque entité du système de la Fig. 1, que ce soit un concentrateur de données 110, un compteur 120A-E, le système FNS 130, le système HES 140 et le serveur LNS 150, comprend un module de traitement 30 (non représenté) permettant à ces entités de contribuer à une mise en oeuvre de l'invention. 15 La Fig. 2 illustre schématiquement une représentation d'un réseau logique correspondant au réseau CPL mis en oeuvre sur le réseau électrique 100 illustré dans la Fig. 1. Comme nous l'avons évoqué en relation avec la Fig. 1, chaque compteur 120A-E est connecté à un concentrateur de données 110. Par contre, d'un point de vue 20 logique, certains compteurs, tels que les compteurs 120A et 120D sont connectés directement au concentrateur de données 110 alors que d'autres compteurs, tels que les compteurs 120B, 120C et 120E sont connectés indirectement au concentrateur de données 110 par l'intermédiaire d'un autre compteur. Ainsi, les compteurs 120A et 120D peuvent communiquer directement avec le concentrateur de données 110. Par 25 contre, chaque trame conforme au standard G3-PLC, appelée trame G3-PLC par la suite, émise par les compteurs 120B, 120C et 120E doit passer par le compteur 120A pour atteindre le concentrateur de données 110. Il se crée donc une hiérarchie parent/enfant entre certains compteurs. Par exemple, le compteur 120A est parent vis-à-vis des compteurs 120B, 120C et 120E, qui sont eux-mêmes enfants du compteur 30 120A. Comme nous l'avons vu en relation avec la Fig. 1, chaque trame LoRa montante émise par le terminal 160A est reçue par les compteurs 120B et 1 20C . Par conséquent, lorsqu'une trame LoRa montante est émise par le terminal 160A, celle-ci est reçue par le compteur 120B qui la relaie au compteur 120A et par le compteur 120C qui la relaie 10 lui aussi au compteur 120A La même trame LoRa montante est donc reçue deux fois par le compteur 120A. Dans un réseau LoRa classique, chaque passerelle LoRa recevant une trame LoRa montante, la relaie vers un serveur LNS avec lequel elle est connectée. Une passerelle LoRa ne se préoccupe pas de savoir si une ou plusieurs 5 autres passerelles LoRa ont relayé la même trame LoRa montante. Dans un réseau LoRa classique, une passerelle LoRa recevant une trame LoRa montante, n'a aucun moyen de savoir si cette trame LoRa montante a été reçue et relayée vers le serveur LNS par une autre passerelle LoRa. Comme on peut le voir dans la Fig. 2, la situation est différente lorsque la 10 passerelle Lora est intégrée dans un compteur tel que les compteurs 120A-E. En effet, certains compteurs, comme le compteur 120A, du fait de l'organisation suivant une hiérarchie parent/enfant des compteurs dans le système de type AMIM, reçoivent plusieurs fois la même trame. En analysant les trames LoRa montantes qu'il reçoit, un compteur peut savoir qu'il reçoit plusieurs fois la même trame LoRa montante. 15 La Fig. 3 illustre schématiquement un exemple d'architecture matérielle du module de traitement 30. Le module de traitement 30 comprend alors, reliés par un bus de communication 300: un processeur ou CPU 301 ; une mémoire vive RAM 302 ; une mémoire morte ROM 303 ; une unité de stockage ou un lecteur de support de stockage, tel qu'un 20 lecteur de cartes SD 304 ; un ensemble d'interfaces de communication 305 permettant au module de traitement 30 de communiquer avec d'autres entités du système de la Fig. 1. Lorsque le module de traitement 30 est compris dans un compteur 120A-E, l'ensemble d'interfaces de communication 305 comprend l'interface de 25 communication 111 vers le réseau CPL 101 et l'interface de communication 114 vers un réseau LPWAN. Lorsque le module de traitement 30 est compris dans un concentrateur de données 110, l'ensemble d'interfaces de communication 305 comprend l'interface de communication 111 vers le réseau CPL 101 et l'interface de communication 115 vers 30 le réseau de communication 103. Lorsque le module de traitement 30 est compris dans le système ENS 130, l'ensemble d'interfaces de communication 305 comprend Eintedace de communication 113 vers le réseau 102 et l'interface de communication 115 vers le réseau 103. 11 Lorsque le module de traitement 30 est compris dans le système HES 140, l'ensemble d'interfaces de communication 305 comprend l'interface de communication 113 vers le réseau 102. Lorsque le module de traitement 30 est compris dans le serveur LNS 150, 5 l'ensemble d'interfaces de communication 305 comprend l'interface de communication 113 vers le réseau 102. Lorsque le module de traitement 30 est compris dans un terminal 160A ou 160B, l'ensemble d'interfaces de communication 305 comprend l'interface de communication 114 vers le réseau LPWAN. 10 Le processeur 301 est capable d'exécuter des instructions chargées dans la RAM 302 à partir de la ROM 303, d'une mémoire externe (non représentée), d'un support de stockage, tel qu'une carte SD, ou d'un réseau de communication. Lorsque l'entité (Le. le concentrateur de données 110, un compteur 120A-E, le système FNS 130, le système HES 140, le serveur LNS 150, un terminal 160A ou 160B) est mise sous 15 tension, le processeur 301 est capable de lire de la RAM 302 des instructions et de les exécuter. Ces instructions forment un programme d'ordinateur causant la mise en oeuvre, par le processeur 301 d'un procédé décrit en relation avec la Fig. 4. Tout ou partie du procédé décrit en relation avec la Fig. 4 peut être implémenté sous forme logicielle par exécution d'un ensemble d'instructions par une machine 20 programmable, telle qu'un DSP (« Digital Signal Processor » en terminologie anglo- saxonne) ou un microcontrôleur, ou être implémenté sous forme matérielle par une machine ou un composant dédié, tel qu'un FPGA (« Field-Programmable Gate Array » en terminologie anglo-saxonne) ou un ASIC (« Application-Specific Integrated Circuit » en terminologie anglo-saxonne). 25 La Fig. 4 illustre schématiquement un exemple de mise en oeuvre dans un système de type AMIVI d'un procédé permettant d'acheminer des trames émises par des terminaux sur un réseau de type LPWAN. Dans la Fig. 4 nous prenons l'exemple d'une trame LoRa montante émise par le terminal 160A. Une mise en oeuvre similaire aurait été obtenue pour une trame LoRa 30 montante émise par le terminal 160B. Dans une étape 401, le module de traitement 30 du terminal 160A provoque un envoi d'une trame LoRa Montante. Cette trame LoRa montante est transmise en mode multidiffusion par l'intermédiaire de l'interface de communication 114 du terminal 12 160A. La trame LoRa montante comprend un identifiant du terminal 160A sous forme d'une adresse De widdr. Dans une étape 402, le module de traitement 30 du compteur 120B détecte une réception par le compteur 120B sur son interface de communication 114, de la trame 5 LoRa montante. Bien que ces deux trames soient identiques, par la suite nous appelons la trame LoRa montante lorsqu'elle est envoyée par le terminal 160A, trame émise et la trame LoRa montante lorsqu'elle est reçue par un compteur, par exemple ici le compteur 120B, trame reçue. 10 Dans une étape 403, afin de décider si la trame reçue par le compteur 120B doit être relayée, le module de traitement 30 du compteur 120B détermine si cette trame respecte un critère prédéterminé. Dans un mode de réalisation, dit mode non-temporisé, le critère prédéterminé consiste à sélectionner systématiquement la trame correspondant à ladite trame émise 15 reçue en premier par le compteur 120B. Dans un mode de réalisation, dit premier mode temporisé, lors de l'étape 403, le module de traitement 30 se met en attente pendant une période prédéterminée TEMPO suivant la première réception d'une trame correspondant à une même trame émise. La période prédéterminée TENWO est par exemple de « 200 » ms. Dans ce mode de 20 réalisation, le critère prédéterminé consiste à sélectionner aléatoirement une trame parmi les trames correspondant à ladite trame émise reçues par le compteur 120B pendant la période prédéterminée TEWO. Dans un mode de réalisation, dit deuxième mode temporisé, lors de l'étape 403, le module de traitement 30 se met en attente pendant la période prédéterminée 25 TEMPO suivant la première réception d'une trame correspondant à une même trame émise. Dans ce mode de réalisation, le critère prédéterminé consiste à sélectionner la trame offrant une meilleure qualité de réception parmi les trames correspondant à ladite trame émise reçues pendant la période prédéterminée TEM/-'0. Les trames qui ne correspondent pas au critère prédéterminé sont 30 systématiquement rej etées. Dans le cas de la Fig. 4, le compteur 120B ne reçoit qu'une fois la trame émise par le terminal 160A. Par conséquent, quel que soit le mode de réalisation, la seule trame reçue est sélectionnée pour être relayée. 13 Dans une étape 404, le module de traitement 30 du compteur 120B encapsule la trame reçue dans une trame G3-PLC et transmet cette trame G3-PLC en direction du concentrateur de données 110. Le compteur 120B transmet donc la trame 03-PLC au compteur 120A. La trame 03-PLC émise par le compteur 120B est appelée par la 5 suite première trame G3-PLC. La Fig. 5 illustre schématiquement une encapsulation d'une trame LoRa montante dans une trame 03-PLC. La trame représentée dans la Fig. 5 est donc une trame conforme au standard G3-PLC. Cette trame G3-PLC comprend dans une sous-partie 56, un entête G3-PLC, 10 dans une sous-partie 55, un entête 6LowPAN (Réseau local sans fil à faible puissance IPv6 : « IPv6 Low power Wireless Personal Area Networks » en terminologie anglo-saxonne), dans une sous-partie 54, un entête 1Pv6 (Protocole Internet version 6 : « Internet Protocol version 6 » en terminologie anglo-saxonne) et dans une sous-partie 53, un entête UDP (Protocole de datagram utilisateur : « User Datagram Protocol » en 15 terminologie anglo-saxonne). La trame G3-PLC comprend en outre, une première sous-partie 51 comprenant la trame LoRa montante encapsulée et une deuxième sous-partie 52. Les sous-parties 51 et 52 forment une partie utile de la trame G3-PLC. La deuxième sous-partie 52 est destinée à recevoir des identifiants de chaque compteur ayant reçu directement (i.e. à travers une interface réseau 114) la trame LoRa 20 encapsulée. Dans un mode de réalisation, chaque passerelle LoRa implémentée par un compteur possède une adresse IP (Protocole Internet : « Internet Protocol » en terminologie anglo-saxonne). L'identifiant d'un compteur ayant reçu la trame LoRa montante est dans ce cas, l'adresse IP de la passerelle LoRa implémentée par ce compteur. 25 Dans ces modes de réalisation, lors de l'étape 404, le compteur 120B stocke dans la sous-partie 52 l'identifiant du compteur 120B. Dans un mode de réalisation, en plus de stocker un identifiant de chaque compteur ayant reçu la trame LoRa montante, la sous-partie 52 stocke pour chaque compteur ayant reçu la trame LoRa montante, une information représentative d'une 30 qualité de réception de ladite trame LoRa montante par ledit compteur. L'information de qualité est par exemple un rapport signal sur bruit (« signal to noise ratio (SNR) » en terminologie anglo-saxonne) et/ou une indication sur la force du signal reçu (« received signal strength indication (RSSI) » en terminologie anglo-saxonne). 14 Dans ce mode de réalisation, la sous-partie 52 comprend une information représentative de la qualité de réception par le compteur 120B de la trame émise par le terminal 160A. Dans une étape 406, le module de traitement 30 du compteur 120C détecte une 5 réception par le compteur 120C sur son interface de communication 114, de la trame émise par le terminal 160k Dans une étape 407, le module de traitement 30 du compteur 120C applique une étape identique à l'étape 403. Le résultat de l'étape 407 est alors identique au résultat de l'étape 403, puisque le module de traitement 30 du compteur 120C sélectionne la 10 seule trame reçue et relaie cette trame lors de l'étape 408 en direction du concentrateur de données 110 dans une trame G3-PLC. La trame G3-PLC émise par le compteur 120C est appelée par la suite deuxième trame G3-PLC. La deuxième trame G3-PLC reprend le format de trame décrit en relation avec la Fig. 5. Dans la sous-partie 51, elle comprend la même trame LoRa montante que la 15 première trame G3-PLC. Dans la sous-partie 52, elle comprend l'identifiant du compteur 120C. Dans un mode de réalisation, la sous-partie 52 comprend aussi une information représentative d'une qualité de réception de ladite trame LoRa montante par le compteur 120C. Dans des étapes 405 et 409 le module de traitement 30 du compteur 120A reçoit 20 respectivement la première trame G3-PLC et la deuxième trame G3-PLC sur son interface de communication 111. Dans une étape 410, le module de traitement 30 du compteur 120A applique une étape identique aux étapes 403 et 407. Toutefois, alors que les étapes 403 et 407 ont été exécutées dans un contexte où les compteurs 120B et 120C ne recevaient chacun 25 qu'une trame correspondant à la trame émise, lors de l'étape 410, le compteur 120A reçoit deux trames correspondant à la trame émise. Dans le cas du mode non-temporisé, le module de traitement 30 du compteur 120A sélectionne lors d'une étape 411 la première trame reçue correspondant à la trame émise dès réception de cette trame. La trame reçue lors de l'étape 405 est donc 30 sélectionnée pour être relayée. Dans le cas du premier mode temporisé, le module de traitement 30 du compteur 120A sélectionne aléatoirement, lors de l'étape 411, une trame parmi les trames correspondant à la trame émise qu'il a reçue. Par exemple, le module de traitement 30 15 du compteur 120A, sélectionne la trame reçue lors de l'étape 405 (i.e. la première trame G3-PLC). Dans le cas du deuxième mode temporisé, le module de traitement 30 du compteur 120A sélectionne, lors de l'étape 411, la trame offrant la meilleure qualité 5 de réception parmi les trames correspondant à la trame émise qu'il a reçue. Pour ce faire, le module de traitement 30 du compteur 120A utilise les informations représentatives d'une qualité de réception contenues dans la sous-partie 52 de chaque trame G3-PLC reçue (i.e. la première et la deuxième trame G3-PLC). Par exemple, le module de traitement 30 du compteur 120A, sélectionne la trame reçue lors de l'étape 10 409 (i.e. la deuxième trame G3-PLC). Dans une étape 412, le module de traitement 30 du compteur 120A provoque le relai de la trame sélectionnée vers le concentrateur de données 110. La trame relayée respecte le format de trames décrit en relation avec la Fig. 5. Lors de l'étape 412, la trame relayée comprend la trame LoRa montante émise par le terminal 160A lors de 15 l'étape 401 dans sa sous-partie 51. Par ailleurs, lors de l'étape 412, la trame relayée comprend dans sa sous-partie 52, l'identifiant de chaque compteur ayant reçu directement la trame LoRa montante (ici cela correspond aux compteurs 120B et 120C). Dans un mode de réalisation, la sous-partie 52 comprend de plus, pour chaque compteur ayant reçu directement la trame LoRa montante émise par le terminal 160A, 20 une information représentative d'une qualité de réception de ladite trame par le compteur. Dans l'exemple de la Fig. 4, la trame G3-PLC relayée comprend une information représentative de la qualité de réception de la trame LoRa montante par le compteur 120B et une information représentative de la qualité de réception de la trame LoRa montante par le compteur 120C. 25 Dans une étape 413, le module de traitement 30 du concentrateur de données 110 détecte que le concentrateur de données 110 a reçu une trame G3-PLC. Lors de l'étape 413, la partie utile de la trame G3-PLC est extraite et encapsulée dans une trame HTTP. La Fig. 6 illustre schématiquement une encapsulation d'une trame LoRa 30 montante dans une trame HTTP. La trame HTTP comprend dans une sous-partie 66 par exemple un entête Ethernet, dans une sous-partie 65 un entête IP (LPv4 ou IPv6), dans une sous-partie 64 un entête TCP (protocole de contrôle de transmission : « transmission control protocol (TCP) » en terminologie anglo-saxonne) et dans une sous-partie 63 un entête HTTP. 16 On retrouve dans une partie utile de la trame HTTP la sous-partie 51 et la sous-partie 52 comportant notamment l'identifiant de chaque compteur ayant relayé la trame LoRa montante (c'est-à-dire comportant pour chaque compteur ayant relayé la trame LoRa montante, l'adresse IP de la passerelle LoRa implémentée par ledit compteur). 5 En variante, on peut utiliser le protocole TLS (« Transport Layer Security » en terminologie anglo-saxonne) avec HTTP, ce qui correspond à HTTPS (« Hyper Text Transfert Protocol Secure » en terminologie anglo-saxonne), de manière à transmettre de manière sécurisée. Dans une étape 414, le module de traitement 30 du concentrateur de donnée 110 10 transmet la trame HTTP en direction du système FNS 130. Le concentrateur de données 110 est classique. Il se contente de relayer la partie utile d'une trame G3-PLC dans une trame HTTP vers le système 130, sans se préoccuper du contenu de cette partie utile. Le concentrateur de données 110 ne sait pas faire une différence entre une partie utile contenant des données de métrologie 15 émanant d'un compteur ou des données conformes au protocole LoRaWAN. Lors d'une étape 415, le module de traitement 30 du système FNS 130 détecte que le système FNS 130 a reçu une trame HTTP. Lors de l'étape 415, le module de traitement 30 du système FNS 130 détermine pour la trame HTTP reçue, si la trame HTTP contient des données de métrologie émanant d'un compteur ou si elle contient 20 des données conformes au protocole LoRaWAN. Pour ce faire, le module de traitement 30 du système FNS 130 détermine si la partie utile de la trame HTTP contient des sous-parties 51 et 52. Lorsque la trame HTTP comprend des données de métrologie, la partie utile de la trame HTTP est extraite et encapsulée dans une nouvelle trame HTTP qui est 25 transmise en direction du système HES 140. Lorsque la trame HTTP comprend des sous-parties 51 et 52, le module de traitement 30 du système FNS 130 transmet les informations contenues dans la trame LoRa montante dans une trame HTTP au serveur LNS 150. Toutefois, le serveur LNS 150 est un serveur LNS classique destiné à fonctionner dans un réseau LoRa classique 30 et donc à recevoir des trames HTTP comprenant des trames LoRa montantes en provenance de passerelles LoRa classiques. Le système FNS 130 doit donc transmettre au serveur LNS 150 des trames HTTP conformes à ce qu'aurait transmis une passerelle LoRa classique. Pour ce faire, le système FNS 130 utilise un format d'encapsulation de données compris par tous les serveurs LNS utilisés actuellement 17 tel que le format JSON (Notation d'objet javascript, « JavaScript Object Notation » en terminologie anglo-saxonne) décrit dans le document « RFC7159 : The JavaScript Object Notation (JSON) Data Interchange Format ». Dans un mode de réalisation, la trame LoRa montante comprise dans la sous-partie 51 est encapsulée dans un 5 conteneur conforme au format JSON. Dans un autre mode de réalisation, les données comprises dans la trame LoRa montante comprise dans la sous-partie 51 sont extraites de la trame LoRa montante, représentée dans le format JSON et insérées dans la trame HTTP à transmettre au serveur LNS 150. Pour les deux modes de réalisation, nous dirons par la suite que la trame LoRa montante est encapsulée dans le format JSON. 10 Dans un réseau LoRa classique, une passerelle LoRa relayant une trame LoRa montante provenant d'un terminal vers un serveur LNS dans un trame HTTP, insère un identifiant permettant de la reconnaître, tel que son adresse IP, dans la trame HTTP. Lorsque plusieurs passerelles LoRa relaient une même trame LoRa montante vers un serveur LNS, le serveur LNS utilise l'identifiant de chaque passerelle LoRa 15 ayant effectué le relai pour désigner la passerelle LoRa devant relayer une trame LoRa descendante destinée au terminal à l'origine de la trame montante. Dans l'exemple de la Fig. 4, le système FNS 130 reçoit une trame HTTP comprenant, dans la sous-partie 51, une trame Lora montante, et dans la sous-partie 52, un identifiant de chaque compteur ayant reçu directement la trame LoRa montante 20 de la part du terminal 160A, c'est-à-dire un identifiant des compteurs 120B et 120C. Dans un mode de réalisation, la sous-partie 52 comprend aussi pour chaque compteur ayant reçu directement la trame LoRa montante, une information représentative de la qualité de réception de ladite trame LoRa montante par ledit compteur. Afin d'être conforme aux trames HTTP que transmettrait une passerelle LoRa 25 classique au serveur LNS 150, chaque trame HTTP générée par le système FNS 130 ne peut comprendre qu'un identifiant de compteur, cet identifiant étant compris par le serveur LNS 150 comme un identifiant de passerelle LoRa. Le module de traitement 30 du système FNS 130 choisit donc un des identifiants qu'il a reçus dans la sous-partie 52, ce qui revient à choisir le compteur possédant cet identifiant. 30 Dans un mode de réalisation, le module 30 du système FNS 130 choisit aléatoirement un identifiant parmi les identifiants reçu dans la sous-partie 51 de la trame HTTP reçue lors de l'étape 415. Dans un mode de réalisation, lorsque la sous-partie 52 comprend une information représentative de la qualité de réception pour chaque compteur ayant reçu 18 directement la trame LoRa montante, le module 30 du système FNS 130 choisit l'identifiant reçu dans la sous-partie 51 de la trame HTTP reçue lors de l'étape 415 correspondant à la meilleure information représentative de la qualité de réception. La Fig. 7 illustre schématiquement une encapsulation au format JSON d'une 5 trame LoRa montante dans une trame HTTP. On retrouve dans la trame HTTP représentée en Fig. 7, les sous-parties 63, 64, 65 et 66 déjà expliquées. La trame HTTP comprend de plus une sous-partie 71. La sous-partie 71 comprend la trame LoRa montante comprise dans la sous-partie 51 encapsulée dans le format JSON. Par ailleurs, la sous-partie 71 comprend l'identifiant 10 du compteur ayant reçu directement la trame LoRa montante. Comme nous l'avons vu plus haut, cet identifiant est l'adresse IP de la passerelle LoRa implémentée par ledit compteur. Dans l'exemple de la Fig. 4, cette trame LoRa montante est celle qui a été sélectionnée lors de l'étape 411. Dans une étape 416, le module de traitement du serveur LNS 150 détecte que le 15 serveur LNS 150 a reçu la trame HTTP émise lors de l'étape 415 et traite cette trame HTTP. Dans un réseau LoRa classique, les échanges de messages entre un terminal et un serveur LNS sont bidirectionnels. Un serveur LNS peut par exemple acquitter une trame LoRa montante. Pour ce faire, comme nous l'avons vu plus haut, si plusieurs 20 passerelles LoRa ont reçu une même trame LoRa montante, le serveur LNS doit désigner parmi les passerelles LoRa ayant reçu la trame LoRa montante, la passerelle LoRa à utiliser pour relayer une réponse au message contenu dans la trame LoRa montante. La réponse est transmise du serveur LNS à la passerelle LoRa désignée dans une requête HTTP, puis en point à point, de la passerelle LoRa désignée au 25 terminal dans une trame LoRa descendante conforme au protocole LoRaWAN. Dans le cadre de l'invention, la présence du système FNS 130 permet de masquer le passage de la trame LoRa montante par le système de type AlvIIVI au serveur LNS 150. Du point de vue du serveur LNS 150, la trame HTTP reçue lors de l'étape 416 a été transmise par une passerelle LoRa classique suite à une réception par 30 ladite passerelle LoRa classique d'une trame LoRa montante en provenance du terminal 160A. Le serveur LNS 150 ne sait pas que la trame LoRa montante a été reçue par au moins un compteur implémentant une passerelle LoRa. Le serveur LNS 150 réagit de la même manière à la réception de la trame HTTP par l'intermédiaire du système FNS 130 que s'il avait reçu cette trame HTTP de la part d'une passerelle 19 LoRa classique. Toutefois, du fait de la suppression des trames LoRa montantes dupliquées entre les compteurs et le système FNS 130, tout se passe comme si la trame LoRa montante transmise par le terminal 160A n'avait été relayée que par une seule passerelle LoRa. Du point de vue de serveur LNS 150, cette passerelle LoRa est 5 celle dont l'identifiant est indiquée dans la sous-partie 71 de la trame HTTP reçue lors de l'étape 416. Dans un mode de réalisation, le module de traitement 30 du serveur LNS 150 désigne le compteur dont l'identifiant figure dans la sous-partie 71 de la trame HTTP reçue lors de l'étape 416. A partir de cette désignation, chaque trame générée par le 10 serveur LNS 150 et destinée au terminal 160A, transitera par le compteur dont l'identifiant figure dans la sous-partie 71 de la trame HTTP reçue lors de l'étape 416. Par la suite, nous supposons que la trame LoRa montante émise lors de l'étape 401 par le terminal 160A est une trame de demande de connexion (« Join Request » en terminologie anglo-saxonne). Dans ce cas, le procédé décrit en relation avec la Fig. 4 15 est un début d'une procédure de connexion correspondant à une phase de demande de connexion. Lors de l'étape 416, le serveur LNS 150 reçoit donc dans la sous-partie 71 d'au moins une trame HTTP, une trame de demande de connexion. Suite à la réception de la trame de demande de connexion, le serveur LNS 150 20 répond par une trame de d'autorisation de connexion (« JOIN ACCEPT » en terminologie anglo-saxonne). La Fig. 11 illustre schématiquement une procédure d'autorisation de connexion. Dans une étape 1101, le module de traitement du serveur LNS 150 génère une trame LoRa descendante contenant une autorisation de connexion, dite trame 25 d'autorisation de connexion, destinée au dispositif 160A, encapsule la trame d'autorisation de connexion dans une trame HTTP dans le format JSON et provoque la transmission par le serveur LNS 150 de la trame HTTP au système FNS 130. La Fig. 8 illustre schématiquement une encapsulation d'une trame LoRa descendante dans une trame HTTP dans le format JSON. 30 On retrouve dans la trame HTTP de la Fig. 8, les sous-parties 63, 64, 65 et 66. Une sous-partie 81 comprend la trame d'autorisation de connexion et l'identifiant du compteur désigné encapsulée dans le format JSON. Dans l'exemple de la Fig. 11, il s'agit du compteur 120B. Par ailleurs, la sous-partie 81 comprend une date d'émission souhaitée de la trame LoRa descendante par le compteur désigné (Le. le compteur 20 120B), cette date étant elle aussi encodée au format JSON. Cette date d'émission est une date relative par rapport à une date de réception d'une trame LoRa montante par le compteur désigné. Dans une étape 1102, le système FNS 130 reçoit la trame HTTP encapsulant la 5 trame d'autorisation de connexion dans le format JSON. Lors de l'étape 1102, le module de traitement 30 du système FNS 130 extrait de la trame HTTP la trame d'autorisation de connexion, l'identifiant du compteur désigné et date d'émission souhaitée de la trame LoRa descendante. Le module de traitement 30 du système FNS 130 insère ensuite la trame d'autorisation de connexion, l'identifiant du compteur 10 désigné et la date d'émission souhaitée dans une nouvelle trame HTTP décrite ci- dessous en relation avec la Fig. 9. La Fig. 9 illustre schématiquement une encapsulation d'une trame LoRa descendante dans une trame HTTP. On retrouve dans la trame HTTP de la Fig. 8, les sous-parties 63, 64, 65 et 66. 15 La sous-partie 91 comprend la trame d'autorisation de connexion. Une sous-partie 92 comprend l'identifiant du compteur désigné et la date d'émission souhaitée de la trame LoRa descendante par le compteur désigné. Ainsi, alors que la trame HTTP générée par le serveur LNS 150 est une trame HTTP classique qu'une passerelle LoRa classique est capable de traiter, la trame 20 HTTP générée par le système FNS 130 est spécifiquement définie pour une transmission d'une trame LoRa descendante à un concentrateur de données. Lors de l'étape 1102, le système FNS 130 transmet la trame HTTP au concentrateur de données 110. Dans une étape 1103, le concentrateur de données 110 reçoit la trame HTTP. 25 Lors de l'étape 1103, le module de traitement 30 du concentrateur de données 110 extrait la partie utile de la trame HTTP (Le. les sous-parties 51 et 92) et forme une trame G3-PLC en utilisant cette partie utile. La Fig. 10 illustre schématiquement une encapsulation d'une trame LoRa descendante dans une trame G3-PLC. 30 On retrouve dans la trame G3-PLC, les sous-parties 53, 54, 55 et 56. La sous- partie 51 comprend la trame LoRa descendante. Une sous-partie 102 comprend la date d'émission souhaitée de la trame LoRa descendante par le compteur désigné indiquée dans la sous-partie 92. 21 Lors de l'étape 1103, le module de traitement 30 du concentrateur de données 110 lit l'adresse du compteur désigné dans la sous-partie 92 et détermine que pour atteindre le compteur désigné (i.e. le compteur 120B), il doit transmettre la trame G3- PLC qu'il a formée au compteur 120A. Le module de traitement 30 du concentrateur 5 de données 110 provoque ensuite l'envoi de la trame G3-PLC au compteur 120A. Dans une étape 1104, le compteur 120A reçoit la trame G3-PLC. Lors de l'étape 1104, le compteur 120A relaie cette trame en direction du compteur 120B. Dans une étape 1105, le module de traitement 30 du compteur 120B détecte que le compteur 120B a reçu la trame G3-PLC et extrait la trame LoRa descendante de la 10 trame G3-PLC. Le module de traitement 30 du compteur 120B se met en attente d'une réception d'une trame LoRa montante de la part du terminal 160A. Lorsque le module de traitement 30 du compteur 120B détecte une réception d'une trame LoRa montante, il note la date de réception de cette trame LoRa montante, ajoute la valeur de la date d'émission souhaitée contenu dans la trame G3-PLC reçue lors de l'étape 1105 à la 15 date de réception pour obtenir une date effective de transmission, et transmet la trame LoRa descendante au terminal 160A à la date effective de transmission ainsi calculée. Dans une étape 1106, le terminal 160A reçoit la trame LoRa descendante. Dans l'exemple des Figs. 4 et 11, la trame LoRa montante est une demande de connexion au réseau LoRa et la trame LoRa descendante est une autorisation de 20 connexion. Le procédé de la Figs. 4 et 11 fonctionnerait de la même manière si la trame LoRa montante émise par le terminal 160A avait été une trame contenant un message destiné au serveur LNS 150 et la trame LoRa descendante une trame d'acquittement de la trame LoRa montante. Jusque-là, nous avons supposé que les compteurs 120A-E sont strictement 25 identiques. Ainsi chaque compteur 120A-E comprend une interface possédant une interface de communication 114 et implémente une passerelle LoRa. Dans un mode de réalisation, tous les compteurs 120A-E implémentent une passerelle LoRa, mais ne comprennent pas nécessairement une interface de communication 114. Un compteur 120A-E peut donc implémenter une passerelle 30 LoRa sans pour autant être capable de recevoir ou transmettre des trames LoRa. Par exemple, dans ce mode de réalisation, le compteur 120A ne comprend pas d'interface de communication 114 mais implémente une passerelle LoRa ce qui lui permet d'exécuter notamment les étapes 405, 409, 410, 411, 412 et 1104. 22 Dans un mode de réalisation, certains compteurs ne comportent pas d'interface de communication 114 et n'implémentent pas de passerelle LoRa. Ces compteurs peuvent alors être des compteurs intermédiaires entre deux compteurs implémentant une passerelle LoRa. Ces compteurs ne font alors que relayer des trames G3-PLC, 5 sans se préoccuper du contenu de ces trames. Lorsque le système de communication comporte une pluralité de concentrateurs de données 110, il est possible que le système FNS 130 reçoive plusieurs trames HTTP encapsulant la même trame LoRa montante de la part de plusieurs concentrateurs de données 110 différents. Dans ce cas, les sous-parties 52 de chaque 10 trame HTTP reçue contiennent des informations représentatives d'ensembles de compteurs ayant reçu directement la trame LoRa montante différents. On peut en effet imaginer qu'une trame LoRa montante émise par le terminal 160A est reçue par les compteurs 120B, 120C et 120D, mais que les compteurs 120B et 120C sont rattachés à un premier concentrateur de données 110 alors que le compteur 120D est rattaché à 15 un deuxième concentrateur de données 110. Dans ce cas, le module de traitement 30 du système FNS 130 choisi une trame LoRa montante encapsulée dans la sous-partie 51 d'une des trames HTTP reçues lors de l' étape 415. Dans un mode de réalisation, la trame LoRa montante à relayer vers le serveur 20 LNS 150 est par exemple celle comprise dans la sous-partie 51 de la trame HTTP reçue en premier par le système FNS 130. Dans ce mode de réalisation, le module de traitement 30 du système FNS 130 choisit le compteur apparaissant en premier parmi les compteurs ayant un identifiant dans la sous-partie 52 de la trame HTTP reçue en premier lors de l'étape 415. 25 Dans un mode de réalisation, la trame LoRa montante à relayer vers le serveur LNS 150 est par exemple choisie aléatoirement. Dans ce mode de réalisation, le module de traitement 30 du système FNS 130 choisit aussi aléatoirement un compteur parmi les compteurs ayant un identifiant dans la sous-partie 52 d'une des trames HTTP reçues lors de l'étape 415. 30 Dans un autre mode de réalisation, la trame LoRa montante à relayer est celle comprise dans la trame HTTP comprenant dans sa sous-partie 52, la meilleure information de qualité de réception. Ce mode de réalisation revient à choisir la trame LoRa montante reçue avec la meilleure qualité de réception par un compteur. Dans ce 23 mode de réalisation, le module de traitement 30 du système FNS 130 choisit aussi le compteur associé à la meilleure information représentative de qualité. Dans un mode de réalisation, le choix du compteur désigné par le serveur LNS 150 peut être remis en cause par le système FNS 130. Ce mode de réalisation peut par 5 exemple être appliqué lorsque la sous-partie 52 de la trame HTTP reçue par le système FNS 130 comprend une pluralité d'identifiants de compteur, chaque identifiant de compteur étant associé à une information représentative de qualité de réception de la trame LoRa montante, mais que le module de traitement 30 du système FNS 130 n'a pas choisi l'identifiant du compteur devant figurer dans la trame HTTP destinée au 10 serveur LNS 150 sur la base desdites informations représentatives d'une qualité de réception. Dans ce cas, l'identifiant du compteur figurant dans la trame HTTP reçue par le serveur LNS 150 n'est pas forcément l'identifiant du compteur ayant reçu la trame LoRa montante avec la meilleure qualité. C'est toutefois ce compteur qui est choisi par le module de traitement 30 du serveur LNS 150, puisque seul son identifiant 15 figure dans la trame HTTP reçue par le serveur LNS 150. Ce cas peut se produire lorsque le système FNS 130 relaie la trame LoRa montante le plus rapidement possible vers le serveur LNS 150, sans attendre d'avoir analysé les informations de qualité contenues dans la sous partie 52. Dans ce mode de réalisation, lors de l'étape 1102, le module de traitement 30 du système FNS 130 détermine l'identifiant de 20 compteur correspondant à la meilleure information représentative d'une qualité de réception et insère l'identifiant déterminé dans la sous-partie 92 plutôt que l'identifiant REVENDICATIONS1) Dispositif permettant d'échanger des premières trames, dites trames LPWAN, entre un terminal et un serveur, ledit terminal étant adapté pour échanger des trames LPWAN avec au moins une passerelle, dite passerelle LPWAN, par l'intermédiaire d'un premier réseau sans fil à grande portée et à faible consommation d'énergie, et le serveur étant adapté pour échanger des trames LPWAN avec des passerelles LPWAN, chaque trame LPWAN échangée entre le terminal et le serveur devant transiter par au moins un compteur et un concentrateur de données compris dans un deuxième réseau de communication par courants porteurs en ligne et formant un système de gestion automatique de relevés d'une pluralité de compteurs électriques, dit système AMM, au moins un compteur dudit système AMM implémentant une passerelle LPWAN et comportant une interface de communication (114) lui permettant d'échanger des trames LPWAN avec ledit terminal par l'intermédiaire du premier réseau, caractérisé en ce que le dispositif est relié à chaque concentrateur de données (110) par l'intermédiaire d'un troisième réseau (103) et au serveur (150) par l'intermédiaire d'un quatrième réseau (102) et en ce que chaque trame LPWAN échangée entre ledit terminal (160A) et le serveur (150) transite par le dispositif (130), chaque trame LPWAN échangée entre le dispositif (130) et le serveur (150) est encapsulée dans une deuxième trame conforme à un format de trames que le serveur échangerait avec une passerelle LPWAN, et lorsqu'une trame LPWAN émise par le terminal est reçue directement par une pluralité de compteurs et par une pluralité de concentrateurs de données du deuxième réseau de sorte que le dispositif reçoit plusieurs copies de la trame LPWAN, le dispositif est adapté pour transmettre une seule copie de la trame LPWAN au serveur, ladite trame LPWAN étant associée dans la deuxième trame à une information représentative d'un des compteurs ayant reçu directement la trame LPWAN, choisi par le système intermédiaire suivant un critère prédéterminé. 2) Système de communication comprenant un terminal et un serveur, ledit terminal étant adapté pour échanger des trames LPWAN avec au moins une passerelle, dite passerelle LPWAN, par l'intermédiaire d'un premier réseau sans fil à grande portée et à faible consommation d'énergie, et le serveur étant adapté pour échanger des trames LPWAN avec des passerelles LPWAN, chaque trame échangée entre le terminal et le serveur devant transiter par un compteur et un concentrateur de 25 données compris dans un deuxième réseau de communication par courants porteurs en ligne d'un système de gestion automatique de relevés d'une pluralité de compteurs électriques (120A, 120B, 120C, 120D, 120E), dits compteurs, lesdits compteurs de la pluralité de compteurs étant rattachés à au moins un concentrateur de données (110) 5 via le deuxième réseau, au moins un compteur de la pluralité implémentant une passerelle LPWAN et comportant une interface de communication (114) lui permettant d'échanger des trames LPWAN avec ledit terminal par l'intermédiaire du premier réseau, caractérisé en ce que le système comprend un dispositif selon la revendication 1. 10 3) Procédé permettant d'échanger des premières trames, dites trames LPWAN, entre un terminal et un serveur, ledit terminal étant adapté pour échanger des trames LPWAN avec au moins une passerelle, dite passerelle LPWAN, par l'intermédiaire d'un premier réseau sans fil à grande portée et à faible consommation d'énergie, et le 15 serveur étant adapté pour échanger des trames LPWAN avec des passerelles LPWAN, chaque trame LPWAN échangée entre le terminal et le serveur devant transiter par au moins un compteur et un concentrateur de données reliés entre eux par un deuxième réseau de communication par courants porteurs en ligne et formant un système de gestion automatique de relevés d'une pluralité de compteurs électriques, au moins un 20 compteur implémente une passerelle LPWAN et comporte une interface de communication (114) lui permettant d'échanger des trames LPWAN avec ledit terminal par l'intermédiaire du premier réseau, caractérisé en ce que : le procédé est exécuté par un dispositif intermédiaire relié à chaque concentrateur de données (110) par l'intermédiaire d'un troisième réseau (103) et au 25 serveur (150) par l'intermédiaire d'un quatrième réseau (102) de sorte que chaque trame LPWAN échangée entre ledit terminal (160A) et le serveur (150) transite par le dispositif intermédiaire (130), chaque trame LPWAN échangée entre le dispositif intermédiaire (130) et le serveur (150) étant encapsulée dans une deuxième trame conforme à un format de trames que le serveur échangerait avec une passerelle 30 LPWAN, et comprend : recevoir plusieurs copies d'une même trame LPWAN émise par le terminal de la part d'une pluralité de concentrateurs de données, la trame LPWAN ayant été reçue directement par une pluralité de compteurs ; et, 26 transmettre une seule copie de la trame LPWAN au serveur, ladite trame LPWAN étant associée dans la deuxième trame à une information représentative d'un des compteurs ayant reçu directement la trame LPWAN, choisi par le système intermédiaire suivant un critère prédéterminé. 5 4) Procédé selon la revendication 3 caractérisé en ce que, le critère prédéterminé consiste à choisir la première copie de la trame LPWAN reçue ou aléatoirement une copie de la trame LPWAN ou une copie de la trame LPWAN reçue avec la meilleure qualité par un compteur du deuxième réseau. 10 5) Procédé selon la revendication 3 ou 4, caractérisé en ce que, lorsque suite à la transmission d'une trame LPWAN au serveur, la trame LPWAN ayant été reçue directement par une pluralité de compteurs, le dispositif intermédiaire reçoit une trame de réponse destinée au terminal de la part du serveur, le serveur ayant inséré dans la 15 trame de réponse un identifiant d'un compteur choisi par le serveur pour relayer ladite trame de réponse vers le terminal, le procédé comprend : déterminer le compteur la pluralité de compteurs ayant reçu la trame LPWAN avec la meilleure qualité ; et, insérer un identifiant du compteur déterminé dans la trame de réponse à la place 20 de l'identifiant inséré par le serveur. 6) Procédé selon la revendication 3, 4 ou 5 caractérisé en ce que, chaque trame LPWAN comprise dans une deuxième trame est encapsulée au format JSON. 25 7) Programme d'ordinateur, caractérisé en ce qu'il comprend des instructions pour mettre en oeuvre, par un dispositif, le procédé selon l'une des revendications 3 à 6 lorsque ledit programme est exécuté par un processeur dudit dispositif 8) Moyens de stockage, caractérisés en ce qu'ils stockent un programme 30 d'ordinateur comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon l'une des revendications 3 à 6 lorsque ledit programme est exécuté par un processeur dudit dispositif.