Brevet FR3079699A1 — publié le 20191004

Domaine de l'invention La présente invention se rapporte à un système de communication entre des objets connectés de type LoRa, en itinérance et leur réseau. Les objets connectés sont par exemple des véhicules, des containers ou des colis qui circulent et dont il faut suivre la trace ou connaître l'état physique à un instant donné. Etat de la technique A titre de remarque préliminaire, l'organisation des ré- seaux et des échanges de requête et de message étant toujours faite en terminologie anglo-saxonne, il n'est pas possible d'utiliser une terminologie systématiquement traduite qui serait illisible pour l'homme du métier. Cette terminologie sera donc utilisée dans toute la description avec autant que faire se peut des expressions traduites pour les termes cou- rants. Les objets connectés OL appartiennent à un réseau faisant partie d'un groupement de réseaux liés par des accords de roaming. Mais pour différentes raisons, tous les réseaux ne sont pas liés entre eux par des accords de roaming. Ainsi, lorsqu'un objet est en iti- nérance (roaming) et cherche à se connecter à son réseau, il envoie une requête qui n'aboutit que si le réseau visité a un accord de roaming avec le réseau de destination de la requête qui est le réseau d'origine de l'objet OL. Il existe un standard LoRa, particulièrement dédié à la communication entre des objets connectés et de leur réseau par une communication par radio pour des objets à faible consommation d'énergie. Le standard LoRa (Long Range Radio) est un standard très répandu de la technologique M2M, à faible consommation. Les objets communiquent par radio avec des passerelles qui transmettent les mes- sages par Internet vers le réseau de destination. Les réseaux d'objets connectés concernent tant des objets fixes que des objets mobiles. Pour élargir les possibilités, il existe des groupements de réseaux permettant dans une certaine mesure l'itinérance des objets ; un exemple de réalisation est le groupement de réseaux Alliance fonc- tionnant selon le standard LoRa. 2 Le roaming (itinérance) que le standard LoRa permet entre un réseau visité (avec des passerelles LoRa) et un serveur de réseau et des objets connectés appartenant à un réseau (réseau d'origine) nécessite un accord direct de roaming entre le réseau visité et le réseau 5 d'origine. Cela oblige tout opérateur de réseau d'objets mobiles tels qu'une flotte de camions ou un suivi de bagages, à faire un accord direct avec tous les réseaux susceptibles d'être visités, ce qui n'est pas toujours faisable économiquement. Les objets OL utilisant le standard LoRa sont répartis en 10 trois classes décrites dans le document [1] dont la communication né- cessite des sessions périodiques ou permanentes : classe A de faible consommation d'énergie avec une connexion périodique entre le serveur de liaison du réseau visité et le serveur du réseau d'origine, 15 classe B avec souvent une connexion pour envoyer un message dans une fenêtre de réception, classe C d'autonomie limitée, pouvant avoir un GPS pour la localisation précise, avec une connexion quasi permanente. Un objet OL a un code DevEUI qui est son identité de sé- 20 rie, attribuée par le constructeur et une adresse JoinEUl pour trouver son serveur d'authentification JS (un registre HLR-HSS 2G-3G-4G). L'objet OL reçoit également les clés Key et NwkKey (version Lora 1.0) pour chiffrer la transmission entre l'objet et le serveur réseau du réseau d'origine. 25 Le compteur DevNonce de l'objet évite que le message Join-Request soit rejoué frauduleusement par « un homme du milieu » : la requête JoinNonce du message (Join Server Home) évite qu'un homme du milieu rejoue un message « join-Accept ». La procédure d'établissement d'une session selon la fi- 30 gure 1 comporte deux étapes : 1) l'établissement de la session de connexion de l'objet (Start Session with the JoinServer) qui commence avec une requête Join-Request (1) dans laquelle le compteur DevNonce est incrémenté de 1 par l'objet, 3 2) la transmission bidirectionnelle de données chiffrées (encryptées) avec le serveur réseau auquel est relié le serveur applicatif (Application Data Session with the Application Server). L'établissement de la session LoRa selon la technique 5 connue sera décrit à l'aide de la figure 1 en utilisant la numérotation des requêtes. L'état de la technique sera décrit dans le cas d'un groupement de réseaux sous la dénomination Alliance et appliquant le standard LoRa pour les objets connectés. Dans ce groupement, les réseaux 10 ont des accords de roaming mais tous les réseaux n'ont pas systémati- quement des accords entre eux. Ainsi, en considérant l'organisation de ce groupement de réseaux dans le sens de la transmission à partir d'un objet par un réseau visité vers le réseau de destination : 15 le réseau f visité par l'objet OL a : * des passerelles, * un serveur de réseau (fNS), * un serveur de noms de domaines (fDNS), - le réseau d'origine h auquel appartient l'objet OL a : 20 * un serveur de réseau hNS, * un serveur de noms de domaines hDNS, * un serveur de liaison hJS, * un serveur applicatif hAS. Dans cette organisation, le serveur de liaison hJS est le 25 registre HLR-HSS qui authentifie une requête de session. L'établissement de la session se fait à travers le serveur fNS du réseau visité. Le serveur fNS vérifie que le nom de domaine contenu dans la requête correspond à un réseau de destination qui a un accord de roaming avec le réseau visité. Dans la négative, la requête est 30 rejetée dans l'état de l'art actuel. Dans l'affirmative, il transmet (2) la requête au serveur de domaine fDNS, dédié à ce roaming qui contient tous les noms de domaine des réseaux ayant un accord de roaming avec le réseau visité. Il obtient ainsi l'adresse IP du serveur de liaison hJS (JoinServer) et envoie une requête HomeNS Request à celui-ci (3) pour 35 lui demander l'identité (NetID) du serveur de réseau d'origine hNS; en 4 réponse (4), il obtient l'identité (Home-NetID) du serveur de réseau hNS desservant le serveur applicatif (Application Server) hAS. Pour établir ensuite la connexion avec le serveur hNS, le serveur fNS fait une deuxième requête DNS récursive (5 et 5') avec l'adresse Home-NetID comme 5 argument ; il obtient l'adresse IP du serveur réseau hNS. Les étapes 6) et 7) ne sont pas utilisées en « Passive Roaming » mais dans un autre mode appelé « Handover Roaming ». En 8), le serveur fNS envoie une demande PRStart Request au serveur réseau hNS. Il contient le comptage DevNonce+1 dans 10 la partie PHYPayload. Jusqu'au message 8) inclus, les messages de l'établissement de session ne sont pas chiffrés. En 9), le serveur hNS envoie une requête Join-Request au serveur de liaison hJS (JoinServer) ; ce message contient la même 15 charge (PHYPayload) que la requête PStart Request (8). La requête n'étant pas chiffrée, le serveur de liaison hJS peut vérifier que le compteur DevNonce reçu est supérieur de 1 au dernier compteur reçu. Si cela est le cas, il accepte en renvoyant une réponse 10) Join-Answer (succès) contenant l'état JoinNonce+1 vers le serveur hNs. 20 A partir de cette communication, les échanges sont chif- frés. Le serveur hNS répond (11) au serveur fNS par PRStart Answer « Succès » qui contient l'état JoinNonce+1. Les communications sont chiffrées symétriquement à partir de là par une clé NwkSKey que le 25 serveur réseau hNS a élaboré à partir de la clé NwkSKey (qu'il connaît pour l'objet) et les nouveaux états DevNonce+1 et JoinNonce+1 Le serveur hNS répond (12) par un accord Join-Accept à l'objet qui contient l'état JoinNonce+1 ainsi que l'argument DevAddr mis par le serveur fNS, adresse qui est l'équivalente d'une adresse IP dyna- 30 mique servant pour la transmission bidirectionnelle de la Figure 3. L'objet le reçoit ; il connaît son état DevNonce+1 et vérifie que le compteur JoinNonce reçu est bien incrémenté de 1 par rapport au dernier état JoinNonce gardé en mémoire. Ceci lui permet de calculer la même clé de chiffrement NwkSKey que le serveur hNS et donc dé- 5 coder la réponse Join-Accept et si celle-ci indique dans « Result » le succès, il établit la session. Il faut noter que les transactions ID sont destinées à permettre d'avoir plusieurs transmissions en parallèle pour un même 5 objet. But de l'invention Partant de cet état de la technique, l'invention a pour but de développer un système de communication d'objets connectés appartenant à un réseau et en itinérance dans des réseaux sans accord de 10 roaming direct, vers le réseau de l'objet et appliquant tous le standard LoRa. Exposé et avantages de l'invention A cet effet, la présente invention a pour objet un système de communication d'objets connectés en itinérance, avec leur réseau, 15 selon le standard LoRa, les réseaux-objets étant, selon le cas, le réseau d'origine d'un objet en itinérance ou le réseau visité par un objet d'un autre réseau, et le serveur de réseau ayant une fonction de serveur de réseau visité ou de serveur de réseau d'origine auquel appartient un objet. Le système comprend : 20 un réseau intermédiaire entre les réseaux-objets auxquels appar- tiennent les objets, ce réseau intermédiaire associé à chacun des réseaux-objets par un accord de roaming ayant : * un serveur de réseau, * un serveur de noms de domaine, 25 * un serveur de liaison ayant : * l'identité du serveur de noms de domaine de chaque ré- seau-objet, * l'identité du serveur de réseau de chaque réseau-objet, les réseaux objets ayant : 30 * chacun un serveur de réseau avec fonction de serveur de ré- seau visité avec la liste des accords de roaming, * un serveur d'adressage en interface entre le serveur de noms de domaine du réseau dans le serveur de réseau dans sa fonction, 6 le serveur du réseau visité vérifiant l'adresse de la requete de session de l'objet en itinérance dans ce réseau et si cette adresse n'est pas dans la liste des accords de roaming, il transmet au serveur d'adressage pour adresser la requête au serveur du nom de do- 5 maine du réseau intermédiaire. Selon une autre caractéristique avantageuse, le serveur de liaison du réseau intermédiaire répond directement au serveur du réseau visité sans interroger le serveur de liaison du visiteur. De façon avantageuse, le serveur réseau du réseau in- 10 termédiaire retrouve l'adresse pour interroger le serveur de liaison du réseau d'origine dans la PHYPayload qui contient l'adresse dans la requête initiale. Dessins La présente invention sera décrite ci-après de manière 15 plus détaillée à l'aide des dessins annexés dans lesquels : la figure 1 est un schéma de la transmission des requêtes à partir d'un réseau visité vers un réseau d'origine auquel appartient l'objet émetteur de la requête, selon l'état de la technique, la figure 2 est un schéma d'un système de communication entre les 20 objets connectés et leur réseau selon l'invention, la figure 3 est un schéma qui poursuit le schéma de la figure 2 pour la transmission du message selon l'invention. Description de modes de réalisation de l'invention Le système de communication entre les objets connectés 25 en itinérance et leur réseau d'origine est appliqué à un groupe de ré- seaux ayant des accords de roaming ne concernant pas tous les réseaux deux à deux. Le groupe de réseaux, tel que le groupe Alliance qui gère le DNS root pour le service LoRA, applique le standard LoRa pour les 30 communications des objets OL avec leur réseau d'origine. Les messages de signalisation sont empaquetés dans des requêtes et réponses HTTP ou HTTPs. Le système selon l'invention s'applique à un tel groupe de réseaux fonctionnant selon le standard LoRa et comprenant un réseau 35 intermédiaire LH intercalé entre les réseaux qui sont tantôt visités par 7 un objet connecté OL, tantôt celui auquel appartient l'objet OL. Le réseau LH est exploité en service par un acteur qui peut être différent de f et h. Le système selon l'invention se compose du réseau inter- 5 médiaire RHub relié par des accords de roaming avec tous les réseaux R du groupe et des composants dans tous les réseaux. Le réseau intermédiaire LH est un réseau de roaming virtuel (LoRa Hub operator) LH ayant : * un serveur de réseau LH-NS (NS server LoRa Hub), 10 * un serveur de liaison LH-JS (JS server LoRa Hub), * un serveur de nom de domaine LH-DNS (DNS LoRa Hub), un traducteur d'adressage TADNS dans chaque réseau d'opérateur R associé à son serveur de réseau fNS. Le serveur réseau fNS a une table contenant les accords de roaming pour la liaison directe avec le 15 réseau d'origine de l'objet OL. Si à la réception d'une requête, le serveur fNS constate que le serveur de liaison hJS (JoinServer) transmis par la requête de l'objet OL ne se trouve pas sur la liste, le traducteur d'adresse TADNS remplace la requête DNS par l'adresse du serveur de liaison du réseau 20 intermédiaire DNS-Rinter par JoinEUI.LoRa Hub Le serveur LH-JS et le serveur LH-NS du réseau intermédiaire LH se comportent vis-à-vis du serveur fNS comme ceux d'un partenaire de roaming direct. Ils se comportent vis-à-vis des réseaux 25 comme les serveurs fNS d'un réseau visité avec lequel il y a un accord direct. Comme cela apparaît à la figure 2, quand le réseau intermédiaire LH reçoit la requête 3) HomeNSstart, il répond directement (7) avec son adresse NetID-Hub sans interroger le serveur de liaison 30 hJS du réseau de l'objet (Home JS server) car il n'y a que l'adresse De- vEUI et non pas l'adresse JoinEUI. fNS a un accord de roaming direct avec NetID-Hub par hypothèse et peut donc lui envoyer des messages. L'objet OL, grâce au traducteur d'adressage TADNS (8 et 8'), fait sa requête 9) PRStart Request qui contient un PHYPayload avec 35 la requête Join-Request contenant l'argument JoinEUI. Alors seulement 8 (10 et 10'), le serveur de réseau LH-NS (NS Server LoRa Hub) peut adresser le serveur de liaison hJS (JoinServer Home) du réseau de destination h et lui envoyer une requête HomeNR Request (11) pour obtenir l'adresse NetID dans la réponse (12). 5 * Une alternative moins générale (il faut que le réseau intermédiaire LH dispose d'un grand nombre d'adresses IP) est que le réseau LH retourne en (2') une de ses adresses IP « virtuelles » spécifiquement affectée à un réseau LoRa à la requête DNS JoinEUI.LoraHub (2) et se serve de l'adresse IP destination reçue, avec une table IP -> Joi- 10 nEUI pour retrouver le réseau d'origine. Puis le serveur réseau LH-NS (NS Server LoRa Hub) obtient l'adresse IP du serveur réseau hNS (NS Server Home) (13 et 13') grâce à cette adresse NetID et peut faire la requête (14) PRStart Request vers le serveur hNS (NS Server Home). Celui-ci interroge son serveur de 15 liaison hJS (JS Join Server Home) (15) : la réponse (16) permet de ré- pondre (17) avec un message PRStart Answer au serveur de réseau LHNS (NS Server LoRa). Celui-ci peut répondre (18) avec une réponse PRStart Answer (18) à la requête 9) du serveur fNS du réseau visité. La réponse 20 est chiffrée avec la clé NwkSkey calculée par le réseau d'origine R4 (ré- seau de destination) (Home Lora Network). La réponse (19) Join-Accept à l'objet en itinérance virtuelle est elle aussi chiffrée avec cette clé. Détails 25 Plusieurs objets de réseaux différents en session virtuelle avec le réseau intermédiaire LH pourraient utiliser la même identité de transaction ID. Pour éviter les collisions, le réseau intermédiaire LH remplace dans les deux sens l'adresse de la transaction ID par des adresses de transaction AliasID qu'il génère et utilise dans les échanges 30 (11) et (14) faisant la traduction inverse de (12) et (17). Pour la transmission bidirectionnelle (figure 3), les données passent à travers le serveur réseau intermédiaire LH (NS server Hub) et sont toujours chiffrées de bout en bout entre l'objet et le serveur réseau LH (NS server hNS) car le réseau intermédiaire LH est transpa- 35 rent et n'effectue qu'un routage. 9 Références du standard LoRa et autres [1] LoRa Alliance, «LoraWAN V1.1 specification », 11 Oct 2017. [2] LoraWAN « Backend interfaces 1.0 specification », 11 Oct 2017. La spécification la plus pertinente pour le roaming. 5 [3] LoraWAN, « Regional Parameters 1.1 »,11 Oct 1017. [4] A.Henry-Labordère, «Virtual Raoming Systems for GSM, GPRS and UMTS », Wiley, 2009; Un autre exemple d'itinérance virtuelle dans le cas de la signalisation SS7. [5] A.Henry-Labordère, « Virtual Roaming Data Services and 10 Seamless Techology Change », Rivers Publishers, 2014; un autre exemple d'itinérance virtuelle dans le cas du GTP pour le trafic de données en roaming. 15 10 GLOSSAIRE Application Server(AS) Serveur Applicatif relié à un serveur réseau qui lui offre le réseau d'accès radio LoRa. Le protocole entre les serveurs AS 5 et NS n'est pas normalisé par le standard LoRa. DevAddr Identité allouée dynamiquement à l'objet par le serveur fNS (Forwarding Network Server) du réseau visité analogue à une adresse IP dynamique. 10 HLR Home Location Register : Registre de Localisation des abonnés mobiles. Un peu similaire au JoinServer LoRa pour l'authentification mais LoRa est très frustre par rapport à l'authentification 3G-4G ou même 2G. 15 HPLMN "Home Public Mobile Network", le réseau de l'abonné « objet » auquel est relié le serveur applicatif « Application Server » IMSI "International Mobile Subscriber Identity": numéro d'abon- 20 né dans la carte SIM 2G,3G,4G, complètement indépendant du MSISDN de l'abonné. Comprend le MCC-MNC du réseau visiteur (pas d'u tout l'équivalent du DevEUI de l'objet LoRa donc qui s'apparente à l'addresse MAC attribuée par le constructeur de l'objet. 25 DNS serveur de noms de domaine. La requête permet d'obtenir l'adresse IP d'un serveur en interrogeant récursivement le serveur DNS racine (« root ») qui est ici le serveur LoRa Aliance, puis le serveur de noms de domaine DNS du réseau Home. 30 Domain Name : De la forme par exemple de mms.mnc094.mcc208, cela représente une hiérarchiser de nom de serveurs dont les DNS peuvent être interrogés récursivement en partant du dernier nom. Autre exemple f.2.0.0.0.0.0.0.0.1.e.5.0.0.0.0.JOINUIS.LORA-ALLIANCE.ORG qui permet de trouver l'adresse IP du JoinServer d'un objet. 35 LoRa Long Range Radio MSISDN Numéro de mobile habituel dans les réseaux 2G,3G,4G. Payload = charge utile ou cargaison. Message inséré dans un transport par un des messages du protocole LoRa 11 PHYPayload = Physical Payload, copie du message d'entrée JoinRequest du Forwarding Network Server (fNS) REVENDICATIONS1°) Système de communication d'objets connectés en itinérance, avec leur réseau, selon le standard LoRa, - les réseaux-objets étant, selon le cas, le réseau d'origine d'un objet en itinérance ou le réseau visité par un objet d'un autre réseau, et le serveur de réseau (NS) ayant une fonction de serveur (fNS) de réseau visité ou de serveur (hNS) de réseau d'origine auquel appartient un objet, système caractérisé en ce qu'il comprend : un réseau intermédiaire (LH) entre les réseaux-objets auxquels ap- partiennent les objets (OL), ce réseau intermédiaire associé à cha- cun des réseaux-objets par un accord de roaming ayant : * un serveur de réseau (LH-NS), * un serveur de noms de domaine (LH-DNS), * un serveur de liaison (LH-JS) ayant : * l'identité (JoinEUl) du serveur de noms de domaine (hDNS) de chaque réseau-objet, * l'identité (DevEUI) du serveur de réseau (hNS) de chaque réseau-objet, les réseaux objets ayant : * chacun un serveur de réseau avec fonction (fNS) de serveur de réseau visité avec la liste des accords de roaming, * un serveur d'adressage (TADNS) en interface entre le serveur de noms de domaine (DNS) du réseau dans le serveur de ré- seau dans sa fonction (fNS), le serveur (fNS) du réseau visité vérifiant l'adresse (JoinEUl) de la requete de session de l'objet en itinérance dans ce réseau et si cette adresse n'est pas dans la liste des accords de roaming, il transmet au serveur d'adressage (TADNS) pour adresser la requête au ser- veur (LH-DNS) du nom de domaine du réseau intermédiaire (LH). 2°) Système de communication selon les revendications 1 et 2, caractérisé en ce que 13 le serveur de liaison (LH-JS) du réseau intermédiaire (LH) répond directement au serveur (fNS) du réseau visité sans interroger le serveur de liaison (hJS) du visiteur (OL). 5 3°) Système de communication selon les revendications 1 et 2, caractérisé en ce que le serveur réseau (LH-NS) du réseau intermédiaire (LH) retrouve l'adresse (JoinEUl) pour interroger le serveur de liaison (hJS) du réseau d'origine dans la PHYPayload qui contient l'adresse (JoinEUl) dans la 10 requête initiale.