FR3079699A1 - Systeme de communication entre des objets connectes, en itinerance et leur reseau - Google Patents
Systeme de communication entre des objets connectes, en itinerance et leur reseau Download PDFInfo
- Publication number
- FR3079699A1 FR3079699A1 FR1852631A FR1852631A FR3079699A1 FR 3079699 A1 FR3079699 A1 FR 3079699A1 FR 1852631 A FR1852631 A FR 1852631A FR 1852631 A FR1852631 A FR 1852631A FR 3079699 A1 FR3079699 A1 FR 3079699A1
- Authority
- FR
- France
- Prior art keywords
- network
- server
- roaming
- address
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004891 communication Methods 0.000 title claims abstract description 16
- QVFWZNCVPCJQOP-UHFFFAOYSA-N chloralodol Chemical compound CC(O)(C)CC(C)OC(O)C(Cl)(Cl)Cl QVFWZNCVPCJQOP-UHFFFAOYSA-N 0.000 claims abstract description 37
- 230000005540 biological transmission Effects 0.000 description 8
- 230000004044 response Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 4
- 230000002457 bidirectional effect Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 238000005265 energy consumption Methods 0.000 description 2
- 238000000034 method Methods 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/562—Brokering proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Système de communication d'objets connectés en itinérance avec le réseau selon le standard LoRa. Le système comprend un réseau intermédiaire (LH) entre les réseaux-objets. Ce réseau intermédiaire est associé à chacun 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). Le serveur (fNS) du réseau visité vérifie l'adresse (joinEUI) de la requête de session de l'objet en itinérance 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 serveur (LH-DNS ) du nom de domaine du réseau intermédiaire (LH).
Description
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 courants.
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 itiné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 messages 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 fonctionnant selon le standard LoRa.
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 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 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,
- 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érie, attribuée par le constructeur et une adresse JoinEUI 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.
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 figure 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,
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 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 ont des accords de roaming mais tous les réseaux n’ont pas systématiquement 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 :
- 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 :
* 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 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 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 lui demander l’identité (NetlD) du serveur de réseau d’origine hNS; en réponse (4), il obtient l’identité (Home-NetlD) 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 5j avec l’adresse Home-NetlD comme 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 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 h JS (JoinServer) ; ce message contient la même 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.
A partir de cette communication, les échanges sont chiffré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 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 dynamique 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é coder la réponse Join-Accept et si celle-ci indique dans « Resuit » 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 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 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, 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 :
un réseau intermédiaire entre les réseaux-objets auxquels appartiennent 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, * 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 :
* 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, 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 domaine 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 intermé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 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 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 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 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 intermédiaire LH intercalé entre les réseaux qui sont tantôt visités par 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 intermédiaire Rnub 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), * 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 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 h JS (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 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 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 NetlD-Hub sans interroger le serveur de liaison h JS du réseau de l’objet (Home JS server) car il n'y a que l’adresse DevEUI et non pas l’adresse JoinEUI. fNS a un accord de roaming direct avec NetlD-Hub par hypothèse et peut donc lui envoyer des messages.
L’objet Ol, grâce au traducteur d’adressage TADNS (8 et 8j, fait sa requête 9) PRStart Request qui contient un PHYPayload avec la requête Join-Request contenant l’argument JoinEUI. Alors seulement (10 et 10'), le serveur de réseau LH-NS (NS Server LoRa Hub) peut adresser le serveur de liaison h JS (JoinServer Home) du réseau de destination h et lui envoyer une requête HomeNR Request (11) pour obtenir l’adresse NetlD dans la réponse (12).
* 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 (2j 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 JoinEUI 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 13j grâce à cette adresse NetlD et peut faire la requête (14) PRStart Request vers le serveur hNS (NS Server Home). Celui-ci interroge son serveur de liaison h JS (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 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
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 (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 transparent et n'effectue qu'un routage.
Références du standard LoRa et autres [1] LoRa Alliance, «LoraWAN VI. 1 spécification », 11 Oct 2017.
[2] LoraWAN « Backend interfaces 1.0 spécification», 11 Oct 2017. La spécification la plus pertinente pour le roaming.
[3] LoraWAN, « Régional 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
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.
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 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.
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.
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'abonné 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.
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.
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.I.e.5.0.O.O.O.JOINUIS.LORA-ALLIANCE.ORG qui permet de trouver l'adresse IP du JoinServer d'un objet.
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
PHYPayload = Physical Payload, copie du message d'entrée JoinRequest du Forwarding Network Server (fNS) ou du message renvoyé Join-Accept par le Home JoinServer
URL Uniform Resource Locator.
Claims (3)
- 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 appartiennent les objets (Ol), ce réseau intermédiaire associé à chacun 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é (JoinEUI) 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 (JoinEUI) 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 serveur (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 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 (JoinEUI) pour interroger le serveur de liaison (hJS) du réseau d’origine dans la PHYPayload qui contient l’adresse (JoinEUI) dans la 10 requête initiale.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1852631A FR3079699B1 (fr) | 2018-03-27 | 2018-03-27 | Systeme de communication entre des objets connectes, en itinerance et leur reseau |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1852631 | 2018-03-27 | ||
| FR1852631A FR3079699B1 (fr) | 2018-03-27 | 2018-03-27 | Systeme de communication entre des objets connectes, en itinerance et leur reseau |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3079699A1 true FR3079699A1 (fr) | 2019-10-04 |
| FR3079699B1 FR3079699B1 (fr) | 2020-04-03 |
Family
ID=63209478
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1852631A Active FR3079699B1 (fr) | 2018-03-27 | 2018-03-27 | Systeme de communication entre des objets connectes, en itinerance et leur reseau |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3079699B1 (fr) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106793005A (zh) * | 2016-11-14 | 2017-05-31 | 深圳市唯传科技有限公司 | 基于LoRa的物联网设备的漫游通信方法及系统 |
-
2018
- 2018-03-27 FR FR1852631A patent/FR3079699B1/fr active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106793005A (zh) * | 2016-11-14 | 2017-05-31 | 深圳市唯传科技有限公司 | 基于LoRa的物联网设备的漫游通信方法及系统 |
Non-Patent Citations (4)
| Title |
|---|
| A. YEGIN ET AL: "LoRaWAN Backend Interfaces 1.0 Specification", 11 October 2017 (2017-10-11), XP055532888, Retrieved from the Internet <URL:https://lora-alliance.org/sites/default/files/2018-04/lorawantm-backend-interfaces-v1.0.pdf> [retrieved on 20181211] * |
| DANNY DICKS: "Why mobile operators use clearinghouses and roaming hubs", 12 February 2011 (2011-02-12), XP055535272, Retrieved from the Internet <URL:http://innovationobservatory.com/content/why-mobile-operators-use-clearinghouses-an> [retrieved on 20181217] * |
| N SORNIN ET AL: "LoRaWAN(TM) 1.1 Specification", 11 October 2017 (2017-10-11), XP055532870, Retrieved from the Internet <URL:https://lora-alliance.org/sites/default/files/2018-04/lorawantm_specification_-v1.1.pdf> [retrieved on 20181211] * |
| STÉPHANE DELBRUEL ET AL: "FLIP: Federation support for Long range low power Internet of things Protocols", 21 December 2017 (2017-12-21), XP055533014, Retrieved from the Internet <URL:https://arxiv.org/pdf/1712.08221v1.pdf> [retrieved on 20181211] * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3079699B1 (fr) | 2020-04-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103339901B (zh) | 内容导向网络环境中的终端和中间节点以及终端和中间节点的通信方法 | |
| US9307039B2 (en) | Method, system, push client, and user equipment for service communication | |
| AU2004309859B2 (en) | Apparatus and method for routing multimedia messages between a user agent and multiple multimedia message service centers | |
| US7418485B2 (en) | System and method for addressing networked terminals via pseudonym translation | |
| EP1303109B1 (fr) | Résolution de noms virtuels de réseau | |
| FR2861934A1 (fr) | Procede et dispositif d'acces a un terminal serveur mobile d'un premier reseau de communication au moyen d'un terminal client d'un autre reseau de communication. | |
| EP3456031A1 (fr) | Procédé d'accès à un contenu hébergé sur un serveur selectionné en fonction de la localisation du terminal utilisateur | |
| FR2828978A1 (fr) | Procede de transmission de donnees d'un serveur d'un reseau prive virtuel a un noeud mobile | |
| Peterson et al. | Framework for content distribution network interconnection (CDNI) | |
| US20120203913A1 (en) | Method and system for federation of proxy-based and proxy-free communications systems | |
| Durand et al. | Resilient, crowd-sourced LPWAN infrastructure using blockchain | |
| Durand et al. | Decentralized LPWAN infrastructure using blockchain and digital signatures | |
| US6757734B1 (en) | Method of communication | |
| JP2004535743A (ja) | データベースにアクセスするためのドメインネーミングシステム（ｄｎｓ） | |
| EP2532147B1 (fr) | Procédé de génération d'une adresse SIP publique permanente associée à une identité privée sur un réseau IMS | |
| FR3079699A1 (fr) | Systeme de communication entre des objets connectes, en itinerance et leur reseau | |
| US20060023646A1 (en) | Method and apparatus for anonymous data transfers | |
| Souza et al. | Towards the scalability of a service-oriented PCE architecture for IoT scenarios | |
| Chandrashekar et al. | Service oriented internet | |
| US20100235540A1 (en) | Optimisation method and device in communication networks | |
| US20220201090A1 (en) | Over-the-top management in a communication network | |
| US20060023727A1 (en) | Method and apparatus for anonymous data transfers | |
| FR3023098A1 (fr) | Procede et systeme de traitement d'une demande de resolution d'un nom d'un serveur, emise par une application cliente sur un reseau de communication. | |
| CN113196722A (zh) | 获取与解析通信网络中的域名标识符相关的委托链的方法 | |
| Yu et al. | Standardization activities for future networks in ITU-T: A case study from Y. 3071: Data aware networking (Information Centric Networking)—Requirements and Capabilities |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20191004 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |
|
| PLFP | Fee payment |
Year of fee payment: 7 |