[EDITION ABONNES] Mi-octobre, l’alliance LoRa, qui promeut l’usage du standard ouvert LoRaWAN par les réseaux IoT longue portée et basse consommation (LPWAN), a publié la spécification LoRaWAN 1.1 qui se distingue surtout par la prise en charge et la gestion de l’itinérance (ou roaming) entre différents réseaux. ...

L’annonce n’est pas anodine car le roaming est essentiel lorsque les objets ne s’arrêtent pas aux frontières, l’exemple évident étant celui des bagagistes travaillant sur des vols internationaux. Ils permettent à un opérateur couvrant un pays en particulier de s’appuyer à l’étranger sur des réseaux déployés par d’autres opérateurs à l’instar de la situation qui prévaut en téléphonie mobile. (A cet égard, les standards NB-IoT et LTE-M, issus du monde de la téléphonie mobile, prennent en charge le roaming de façon inhérente, un avantage que leurs promoteurs mettent en avant.)

Au sein de l’écosystème LoRa, l’opérateur français Objenious a été le premier à signer des accords de roaming, d’abord avec l’américain Senet, puis avec l’allemand Digimondo et avec le belge Proximus. De son côté, Orange s’est engagé dès le mois de juin 2017 à tester l’itinérance avant la fin de l’année.

Dans le détail, la spécification LoRaWAN 1.1 prend en charge le roaming avec transfert du contrôle de l’objet ou de l’équipement connecté d’un réseau LoRaWAN à un autre. Il est à noter à cet égard que des versions précédentes de la spécification autorisaient déjà le roaming « passif », totalement transparent pour le nœud d’extrémité.

La disponibilité de la version LoRaWAN 1.1 va de pair avec celle de la spécification LoRaWAN Backend Interfaces 1.0. Cette dernière introduit en effet la notion de serveur d’activation (Join Server) au niveau de l’infrastructure réseau LoRaWAN qui peut désormais se scinder en trois entités distinctes : le serveur réseau (NS), le serveur d’application (AS) et donc le serveur d’activation (JS). C’est ce dernier qui est désormais identifié comme l’entité qui stocke dans le réseau les identifiants d’un objet connecté (y compris les clés racines). Le Join Server peut dès lors être administré par un tiers indépendant des infrastructures réseau auxquelles l’objet va être amené à se connecter. Cette procédure permet aux réseaux de se décharger de la procédure d’authentification au bénéfice d’un système spécifique qui peut également être géré par une tierce partie.

Du fait de l’existence d’un serveur d’activation JS tiers, un objet pourra donc être fabriqué sans avoir à être personnalisé pour les réseaux auxquels il va finalement se connecter (avec les clés d’activation inscrites en dur dans ledit objet). En mode over-the-air, l’objet pourra envoyer au serveur JS ce qu’on appelle un join request contenant des clés d’activation globales. Le serveur répondra par un join accept et l’objet décryptera les clés de sécurité de ce join accept. En utilisant un Join Server qui se charge de toutes les activations, il sera désormais possible d’autoriser la communication des objets vers différents réseaux LoRa de façon beaucoup plus simple et fluide.

Selon l’alliance LoRa, les spécifications LoRaWAN 1.1 et LoRaWAN BI 1.0 offrent des améliorations fonctionnelles importantes pour les utilisateurs en termes d’interopérabilité et de couverture réseau. La prise en charge du roaming ouvre la voie à des déploiements de grand envergure, les fabricants étant désormais certains que leurs produits compatibles LoRaWAN pourront potentiellement fonctionner partout dans le monde. D’autre part, la spécification Backend Interfaces fournit les protocoles nécessaires à l’interconnexion de serveurs dotés de rôles différents (contrôle de la couche MAC, authentification de nœuds d’extrémité, applications) au sein de l’infrastructure. « En scindant ces serveurs, nous permettons aux opérateurs de choisir des fournisseurs différents pour chaque élément de la chaîne de valeur, ce qui ne peut que renforcer l’écosystème », conclut l’organisme industriel.