Nouvelles fonctionnalités communes à SaaS et ThingPark Enterprise auto-hébergé

Multi-propriétés au sein du même abonnement RDTP-8479

Avant la version 7.2, les permissions utilisateur supportées dans ThingPark Enterprise ne permettent pas de partitionner l'abonnement TPE entre plusieurs locataires. En d'autres termes, toutes les ressources (capteurs, passerelles et groupes multicast) sont visibles pour tous les utilisateurs, l'accès en écriture étant défini par le rôle de l'utilisateur. Néanmoins, le support de la multi-propriété dans TPE SaaS peut être accompli à travers le modèle multi-abonnement TPE.

À partir de la version 7.2, le même abonnement TPE peut être partitionné pour servir plusieurs locataires, permettant une pleine séparation des autorisations utilisateur. Cette séparation est gérée grâce à la notion de Domaines administratifs.

Note Importante

Indépendamment de la séparation des permissions utilisateurs à travers les domaines administratifs, chaque passerelle opérant sous l'abonnement TPE continue de distribuer le trafic LoRaWAN® de tout capteur sous cet abonnement, sans aucune exclusion.

La même chose s'applique aux connexions vers les serveurs d'applications : toute connexion peut servir tout capteur car les connexions restent inter-domaines, c'est-à-dire sur toute l'abonnement TPE. Néanmoins, les non-administrateurs ayant des restrictions de domaine ont un accès en lecture seule aux connexions.

Plus de détails

Impact de la fonction, en tant qu'administrateur

Avec cette nouvelle fonction de multi-locataire, les utilisateurs TPE ayant le rôle "Administrateur" peuvent effectuer les tâches suivantes. Ces tâches sont décrites dans l'ordre recommandé qu'elles devraient être exécutées par l'administrateur pour activer cette nouvelle fonction.

1. Créer des domaines administratifs pour séparer les autorisations utilisateurs à l'intérieur de leur abonnement TPE, via le panneau de gauche : Gérer > Domaines > Créer.

   

   • Chaque domaine appartient à un groupe de domaines. Un groupe de domaines définit un périmètre de ségrégation. Tous les domaines regroupés sous le même cadre sont mutuellement exclusifs pour éviter les conflits de ségrégation, c'est-à-dire qu'une ressource donnée (capteur, passerelle ou groupe multicast) ne peut être associée à plus d'un domaine du même groupe. Par exemple, un capteur ne peut pas être associé à la fois aux domaines "France" et "Allemagne" qui sont regroupés sous le même groupe de domaines "Géographie".

     Remarque Chaque groupe de domaines peut se voir attribuer une couleur distincte pour être facilement identifiable dans l'interface utilisateur.

   • Plusieurs périmètres de ségrégation (exprimés en groupes de domaines) sont autorisés dans le même abonnement TPE. Par exemple, séparer les autorisations par Géographie et/ou par cas d'usage, comme montré dans l'exemple suivant :

     

   • Les administrateurs peuvent définir des domaines hiérarchiques pour supporter un accès hiérarchique au sein de leur organisation. Exemple EMEA/France, EMEA/Allemagne, EMEA/Royaume-Uni, EMEA/France/Paris...

2. Associer des passerelles, capteurs et groupes multicast avec des domaines lors de l'approvisionnement initial (création unitaire ou importation en masse) ou en mettant à jour une ressource existante. Les ressources existantes peuvent être facilement associées à des domaines via les vues liste/carte, grâce au nouveau bouton "association domaine" en haut à droite de la liste/carte :

   

   

   Note

   La même ressource peut être associée à plusieurs Domaines appartenant à des Groupes de Domaines distincts, mais l'affectation de plusieurs Domaines d'un même groupe à une ressource n'est pas autorisée.

   Important Note

   Les Etiquettes et les Domaines sont deux attributs distincts supportés par les capteurs et les passerelles. Les principales différences sont résumées dans le tableau suivant :

   	Étiquettes	Domaines
   Utilisation	Comme des étiquettes de texte libre, essentiellement utilisées pour la catégorisation et le filtrage des ressources. De plus, les tags des passerelles peuvent être utilisés à des fins multicast. Les étiquettes des capteurs sont signalées aux serveurs d'applications pour permettre un traitement de trafic séparé.	Gestion des permissions utilisateur. Note Les domaines associés à chaque capteur sont également signalés aux serveurs d'applications.
   Qui peut les attribuer ?	Librement attribuées par les administrateurs et non-administrateurs ayant accès en écriture à la ressource en question.	Seuls les domaines prédéfinis (créés par un administrateur) peuvent être associés à des ressources. Tandis que les administrateurs peuvent associer une ressource à n'importe quel domaine (sauf assigner plusieurs domaines du même groupe), les non-administrateurs peuvent uniquement assigner des domaines en conformité avec leurs propres restrictions de domaine.
   Peut être utilisé pour la gestion des autorisations ?	Non, car l'ajout/suppression de tag est librement ouvert aux non-administrateurs ce qui ne peut être contrôlé par les administrateurs.	Oui, car les domaines sont strictement contrôlés par les administrateurs.

3. Associer des utilisateurs non-administrateurs à des restrictions de domaine pour restreindre leur accès aux ressources (capteurs, passerelles et groupes multicast).

   • Une restriction de domaine peut consister en un domaine complet ou un préfixe de domaine. Ce dernier est utile pour la gestion hiérarchique des permissions. Exemple La configuration utilisateur suivante permet à l'utilisateur d'accéder aux ressources associées à la région EMEA, y compris EMEA/France/Paris, EMEA/Allemagne et EMEA/Royaume-Uni :

     

• Le champ "Restrictions de domaine" peut comprendre plusieurs domaines (ou préfixes de domaine), mais ils doivent appartenir à des groupes de domaines distincts.

• Pour chaque groupe de domaines représenté par le champ "Restrictions de domaine", seules les ressources correspondant au domaine concerné peuvent être accessibles par l'utilisateur. Ne pas représenter un groupe de domaines dans les Restrictions de domaine de l'utilisateur signifie que l'utilisateur n'a aucune restriction de permission pour ce groupe. Voici quelques exemples réutilisant les définitions de domaine décrites ci-dessus :

  • Exemple 1 : Un utilisateur ayant "Restrictions de domaine" = "EMEA/Royaume-Uni" ET "Suivi des actifs" ne peut accéder qu'aux ressources associées aux au moins "EMEA/Royaume-Uni" ET aux domaines "Suivi des actifs".

  • Exemple 2 : Un utilisateur ayant "Restrictions de domaine" = "EMEA/Royaume-Uni" peut accéder aux ressources associées aux au moins EMEA/Royaume-Uni, quelle que soit leur affectation de domaine (ou non) du groupe de domaines du cas d'utilisation, car cet utilisateur n'a aucune restriction concernant le groupe de cas d'utilisation.

  Note

  Pour supprimer un Domaine par un Administrateur, il doit d'abord être désactivé pour empêcher son association avec de nouvelles ressources. Ensuite, il peut être supprimé uniquement lorsqu'il n'est associé à aucune ressource/utilisateur.

  Important Note

  Une fois qu'au moins un Domaine est défini par l’Administrateur, les tâches suivantes deviennent restreintes aux Administrateurs, elles ne peuvent pas être exécutées par des utilisateurs non-admins :

• Création/édition/suppression d'une connexion vers des serveurs d'application. Les non-administrateurs peuvent consulter les connexions existantes en mode lecture seule sans pouvoir les modifier, les informations sur le trafic affichées dans la page de connexion sont filtrées pour correspondre aux restrictions de domaine de l'utilisateur.

• [Spécifique TPE auto-hébergé] Gestion des comptes de service, ils ne sont pas visibles pour les non-admins.

Remarque

Les administrateurs, par définition, n'ont aucune restriction de domaine ; par conséquent, ils ont une vue globale sur l'abonnement TPE, mais ils peuvent utiliser la fonction de filtrage de la liste pour se concentrer sur les ressources appartenant à un domaine spécifique.

Impact de la fonction, en tant que non-administrateur

Si un non-administrateur n'a aucune restriction de domaine, il peut accéder à toutes les ressources sans aucune restriction et les associer librement aux domaines, comme décrit ci-dessus pour les administrateurs.

Une fois que des restrictions de domaine sont définies pour un non-administrateur, le système limitera ses droits d'accès comme suit :

• Accéder uniquement aux ressources correspondant à leurs propres restrictions de domaine. Pour toutes ces ressources, l'utilisateur peut accéder aux informations de trafic associées (via les widgets des 10 (ou 25) derniers paquets ou depuis le Wireless Logger) ainsi qu'aux alarmes associées.

Remarque

Le droit d'accès (lecture seule ou lecture/écriture) aux ressources accessibles dépend du rôle de l'utilisateur, c'est-à-dire, spectateur vs. gestionnaire des capteurs vs. gestionnaire des passerelles.

• Créer de nouvelles ressources et les associer à des domaines correspondant aux restrictions de domaine de l'utilisateur.

  

• Ajouter ou supprimer des domaines aux ressources existantes si les restrictions de domaine de l'utilisateur restent respectées avant et après l'actualisation.

• Accéder aux connexions en mode lecture seule, mais l'accès à l'interface graphique ThingPark X IoT Flow est interdit.

Principaux avantages pour les clients

Grâce à cette fonction, les clients ThingPark Enterprise peuvent faire fonctionner plusieurs locataires au sein du même abonnement TPE. Chaque locataire aurait accès aux ressources (capteurs, passerelles, groupes multicast) liées à leur périmètre.

Cette fonction a été conçue de manière polyvalente pour répondre à une grande variété de cas d'utilisation, où les locataires peuvent être séparés selon plusieurs périmètres de ségrégation.

• Les différents locataires peuvent être totalement isolés les uns des autres. Par exemple :

  • Les utilisateurs et les ressources appartenant au site de déploiement A peuvent être complètement isolés de ceux appartenant au site de déploiement B, en définissant des domaines administratifs regroupés par "Géographie" (ou "Localisation").

  • De même, un fournisseur de solutions peut séparer/isolater ses différents clients finaux en définissant un groupe de domaine "Clients" et en créant un domaine pour chaque client locataire.

  • Aussi, l'administrateur TPE peut déposer des autorisations administratives par cas d'utilisation vertical, par exemple, isoler l'équipe "Bâtiment intelligent" de l'équipe "Suivi des actifs".

• Le mélange et la correspondance de multiples périmètres de ségrégation est entièrement supporté.

• Les organisations hiérarchiques sont également supportées, grâce au préfixage de Domaine.

Activation de la fonctionnalité

Cette fonction est automatiquement disponible après la mise à niveau de la plateforme à la version 7.2.

Voir la section « Description des fonctionnalités » pour en savoir plus sur la définition des domaines administratifs, leur association avec des capteurs, passerelles et/ou groupes multicast, ainsi que la définition des restrictions de domaine pour des comptes d'utilisateurs individuels non-admin.

Remarque sur la compatibilité descendante

Lorsque la plateforme est mise à niveau vers la version 7.2 par rapport à une version précédente, puisque les domaines administratifs n'ont pas encore été créés, les mêmes permissions que précédemment restent applicables. De plus, si aucun domaine n'a été défini par l'administrateur, toutes les additions spécifiques au domaine sur les capteurs/passerelles/groupes multicast et les comptes utilisateurs sont masquées dans l'interface graphique.

Limitations de la fonctionnalité

La mise en œuvre de cette fonction dans la version 7.2 présente les limitations suivantes :

• Le nom du groupe de domaines et du domaine ne peut pas être mis à jour après création. En cas d'erreur de frappe, le groupe de domaines (ou le domaine lui-même) doit être supprimé puis recréé.

• Le nombre maximal de niveaux dans la hiérarchie des noms de domaine est de 5. Par exemple, pour représenter une hiérarchie géographique, un maximum de 5 niveaux pourraient être définis, comme Région/Pays/État/Ville/Site.

• Les ressources/fonctions suivantes sont inter-domaines, c'est-à-dire accessibles/utilisables pour tous les domaines sans ségrégation :

  • Connexions vers les serveurs d'application.

  • Drivers de payload personnalisés

  • Licence TPE, c'est-à-dire qu'il n'est pas possible de définir un quota par domaine.

  • Outils Network Survey et Spectrum Analysis

  • Le widget "Actualités" sous le panneau "Tableau de bord".

  • Les rôles des utilisateurs, c'est-à-dire qu'un utilisateur ne peut pas être gestionnaire de passerelle dans le domaine 1 et seulement visualisateur dans le domaine 2.

• Tous les capteurs importés lors d'une opération d'importation en masse donnée doivent être associés au(x) même(s) domaine(s). Vous pouvez utiliser plusieurs opérations (fichiers d'importation csv) pour importer des capteurs sur différents domaines, mais chaque opération devrait avoir la même association de domaine.

• Il n'est actuellement pas possible de définir 2 Domaines du même Groupe de Domaines dans les restrictions de Domaine de l'utilisateur. Cette limitation sera levée dans une future version de ThingPark.

• Après l'activation de la fonctionnalité, les non-administrateurs ayant des restrictions de Domaine peuvent voir le trafic LoRaWAN® transmis uniquement après l'association de la ressource avec les Domaines, dans Wireless Logger, les widgets "10 (ou 25) derniers paquets", etc.

Migration de capteur de TPE-Tout-en-un vers le TPE standard RDTP-16248

L'objectif de cette fonctionnalité est de permettre à un client ThingPark Enterprise Tout-en-un (TAO) de migrer facilement ses capteurs vers un abonnement TPE en version complète. La migration "transparente" signifie que les contextes réseau des capteurs actifs sont transférés d'une plateforme à une autre sans réinitialiser physiquement ces capteurs.

Plus de détails

Cette fonctionnalité est automatiquement disponible après la mise à jour de la plate-forme à la version 7.2.

1. Générer une "Clé de migration" à partir de l'interface graphique de l'abonnement TPE cible, sous Gestion opérationnelle > "Migrer depuis ThingPark Enterprise All-in-One" widget. Enregistrez cette clé pour la télécharger sur votre interface graphique TPE-All-in-One à l'étape #2.

   

2. Exporter les contextes de capteur depuis TPE-Tout-en-un, sous « Gestion avancée » > Exporter. Vous devez fournir la "Clé de migration" récupérée de TPE à l'étape précédente.

   

3. Sur l'interface graphique TPE, importez votre fichier "export-YYYY-MM-DD.taodevices" dans l'interface graphique de ThingPark Enterprise, via l'onglet "Gestion opérationnelle" :

   

   Note

   Lors de cette étape, il vous sera demandé d'associer vos capteurs importés avec une ou plusieurs Connexions vers des serveurs d'application externes. Ainsi, ces Connexions doivent être configurées avant le processus d'importation.

À la fin de l'opération de migration, tous les capteurs devraient fonctionner de manière transparente sur la plateforme ThingPark Enterprise.

Pour en savoir plus sur cette procédure de migration et ses prérequis, consultez la documentation de ThingPark Enterprise All-in-one.

Avantages clés pour les clients

Grâce à cette fonctionnalité, les clients ThingPark Enterprise All-in-one (TAO) peuvent mettre à niveau en toute sécurité leur abonnement pour utiliser l'édition complète de ThingPark Enterprise, que ce soit dans des modèles de déploiement SaaS ou auto-hébergés. Cette voie de migration fluide et transparente permet à ces clients TAO d'élargir leurs déploiements d'un modèle de passerelle autonome vers une architecture multi-passerelles évolutive et hautement disponible. De plus, la mise à niveau vers l'édition complète de ThingPark Enterprise débloque de nombreuses fonctionnalités telles que l'exploitation de ThingPark X IoT Flow, la diversité macro RF, les outils opérationnels (Wireless Logger, Network Survey, Spectrum Analysis), Géolocalisation réseau...

La procédure de migration est sécurisée par une clé de migration générée par l'abonnement TPE cible. La clé de migration est une clé publique RSA utilisée pour chiffrer les clés des capteurs qui doivent rester confidentielles. Les données chiffrées ne peuvent être déchiffrées que par le serveur TPE cible.

Activation de la fonctionnalité

Cette fonction est automatiquement disponible après la mise à niveau de la plateforme à la version 7.2.

Limitations de la fonctionnalité

La configuration de l'application dans TPE-All-in-One (via Node-Red) n'est pas automatiquement importée dans l'abonnement TPE cible : par conséquent, le partenaire de canal (ou l'intégrateur système) doit configurer manuellement la connexion vers les serveurs d'applications externes, soit via TPX IoT Flow ou utiliser un connecteur HTTP basique.

Rappel Le TPE auto-hébergé supporte les connexions de type Node-Red, mais ceci n'est pas supporté par le TPE SaaS.

Amélioration de la gestion des certificats de sécurité des passerelles RDTP-7689 RDTP-16889

À partir de la version 7.2, le mécanisme de renouvellement des certificats de la passerelle est automatisé par le système : le certificat X.509 est automatiquement régénéré quelques jours (6 par défaut) avant l'expiration.

Plus de détails

De plus, cette fonctionnalité apporte plusieurs améliorations UI/UX à la gestion de la sécurité des passerelles dans le Gestionnaire de réseau.

• Une nouvelle colonne "Certificat" est ajoutée à la liste des passerelles, indiquant le statut du certificat : expiré, valide (avec la date d'expiration)... Cette nouvelle colonne est masquée par défaut.

  

• "Expiré" : La génération du certificat de la passerelle est activée, et le certificat a expiré. La date d'expiration s'affiche au survol de la souris et est ajoutée entre parenthèses dans le fichier d'export CSV.

• "Expiration dans <durée>" : La génération du certificat de la passerelle est activée, et le certificat est valide. La date d'expiration s'affiche au survol de la souris et est ajoutée entre parenthèses dans le fichier d'export CSV.

• "Non généré": La génération du certificat est désactivée, et la passerelle a un LRR-UUID.

• "Récupération des informations...": La passerelle a un LRR UUID, mais l'état de son certificat n'est pas encore disponible dans la liste.

• Nouveau critère de filtrage de la liste des BS, par statut de certificat.

  

• Sur la page détaillée de la passerelle > onglet Avancé > widget Sécurité, la date d'expiration du certificat est affichée si elle est connue par le système backend, sinon la date de génération du certificat affichée.

  

  Note Pour gérer les situations exceptionnelles, les administrateurs réseau peuvent générer manuellement des certificats X.509 après expiration. Cette action révoquera automatiquement le certificat X.509 actuel avant d'en générer un nouveau.

• Encore plus d'ergonomie lors de la création de la passerelle :

  • Les champs liés à la sécurité sont maintenant regroupés dans une nouvelle section "Sécurité".

  • Le champ "IPSec (X.509) pour la connexion entre la passerelle et TPE" est remplacé par une case à cocher "Générer le certificat de la passerelle". Activer cette option générera automatiquement un certificat X.509 pour cette passerelle, indépendamment de l'état actuel d'activation de la sécurité IPSec/TLS du côté passerelle.

  • Le champ "Clé publique" est affiché uniquement lorsque l'authentification par clé publique est activée par l'administrateur de la plateforme.

Remarque

Cette fonctionnalité ne modifie pas la procédure recommandée qu'un Administrateur Réseau doit appliquer en cas de vol d'une passerelle ou de corruption d'un certificat X.509, rappelée ci-après :

• En cas de vol/compromission d'une passerelle, elle doit être supprimée du système ThingPark.

• En cas de vol d'un certificat X.509 :

  • Depuis le LRR SUPLOG : la paire de clés publique/privée RSA doit être régénérée.

  • Depuis l'interface graphique TPE, mettez à jour la clé publique RSA pour utiliser la nouvelle générée.

  • Depuis l'interface graphique TPE, régénérez le certificat X.509 (cette action invalidera/révoquera automatiquement le certificat précédent (compromis).

Cette fonction nécessite la version LRR 2.4.73 ou supérieure, pour supporter le téléchargement automatique du certificat X.509 par le LRR avant son expiration.

Principaux avantages pour les clients

La fonctionnalité apporte d'importantes améliorations opérationnelles et UI/UX au processus de gestion des certificats des passerelles, y compris le renouvellement automatique avant expiration.

Activation de la fonctionnalité

Cette fonctionnalité est disponible lors de la migration vers la version 7.2.

Limitations de la fonctionnalité

Aucune.

Déduplication des paquets uplink tardifs avant transmission à AS RDTP-5011

Avant la sortie 7.2, les trames uplink tardives étaient envoyées à AS sans être dédupliquées.

Starting release 7.2, the reporting of UL frames to AS is enhanced:

• Dans le cas où le LRC reçoit plusieurs copies du même paquet uplink qui est marqué "en retard" par les passerelles LRR, seule une copie de ce paquet (identifiée par son FCntUp) est signalée au serveur d'application. Cette déduplication s'applique également lorsqu'une passerelle - se remettant d'une déconnexion temporaire du backhaul - transmet une trame UL en retard qui a déjà été transmise à temps via une autre passerelle avec une connexion backhaul stable.

• De plus, un délai de vie optionnel est défini à l'échelle du système pour déterminer si le LRC doit signaler aux serveurs d'application des paquets uplink trop anciens en retard. Consultez la section d'activation de la fonctionnalité pour en savoir plus sur la configuration de cette option.

Plus de détails

Remarque

Dans tous les cas, même si des paquets trop anciens ne sont pas signalés aux AS, ils sont encore visibles signalés au backend TWA et visibles dans Wireless Logger.

Principaux avantages clients

Grâce à cette nouvelle fonctionnalité, les serveurs d'applications reçoivent désormais une seule copie de chaque trame uplink dans la fenêtre TTL définie (qui par défaut est réglée sur infini), même si certains de ces paquets arrivent en retard (par exemple, en raison de la mise en tampon dans une passerelle ayant temporairement perdu sa connexion backhaul) : il n'est plus nécessaire de gérer la déduplication du côté AS.

Par conséquent, en plus du traitement simplifié du côté AS, cette fonctionnalité évite de surcharger la connexion vers des AS externes lorsque le système se remet d'une situation de panne majeure du backhaul, c'est-à-dire, purgeant les paquets en file d'attente/en retard.

Activation de la fonctionnalité

La fonctionnalité est activée par défaut.

Pour le désactiver, définissez [deduplateul].enable=0 dans le fichier lrc.ini personnalisé du sous-système LRC.

Nouveaux paramètres à l'échelle du LRC :

• [deduplateul].max-fcntup-history : Nombre maximal d'entrées dans l'historique des paquets UL.

  • Défaut = 50.

  • Chaque entrée peut correspondre à une plage FCntUp, définie par une paire de FCntUp au début et à la fin de la plage en question.

• [deduplateul].late-time-to-live, délai de vie (en secondes) pour signaler un paquet en retard à l'AS.

  • Défaut = 0, ce qui signifie que tous les paquets en retard sont signalés - après déduplication - quels que soient leur âge.

  • Lorsqu'il est réglé sur x (x > 0), le paquet LATE est signalé à l'AS uniquement s'il a été mis en file d'attente pendant moins de x secondes par le système, le temps de référence étant le horodatage LRR du paquet UL.

Limitations de la fonctionnalité

Aucune.

Améliorations TLS pour un backhaul sécurisé LRR-LRC RDTP-17091 RDTP-5248

Les améliorations suivantes sont supportées dans LRR packet forwarder lorsque le backhaul entre la passerelle et le Cœur de réseau est sécurisé via TLS :

• Renouvellement automatique du certificat X.509 de la passerelle quelques jours avant son expiration (ou lorsqu'il a déjà expiré).

• Capacité d'activer TLS depuis SUPLOG, ou de passer entre les modes de sécurité TLS et IPSec.

Plus de détails

Avantages clés pour les clients

Improved base station operability and configurability under TLS mode.

Activation de la fonctionnalité

Pour activer TLS depuis SUPLOG, l'utilisateur doit naviguer vers Configuration Système > Backhaul.

Puisque toutes les destinations sont réglées vers l'hôte local en mode TLS, les adresses de téléchargement/téléversement SFTP et LRC deviennent automatiquement définies par la configuration TLS inhérente.

Remarque

Lorsque TLS est activé, SFTP doit être utilisé car TLS ne supporte pas FTP.

Cette fonctionnalité est supportée à partir de LRR 2.8.20. Puisque tous les impacts se situent sur le côté LRR (pas d'impact sur le réseau backend/cœur), il peut fonctionner en toute sécurité avec les versions antérieures de ThingPark, à condition que la version LRR soit 2.8.20 ou supérieure.

Limitations de la fonction

Aucune.

Support du sous-réseautage de NetID RDTP-15106

Avant la version 7.2, pour supporter l'itinérance, le même NetID ne peut pas être partagé entre plusieurs plateformes ThingPark. Cette règle ne s'applique pas aux NetID 0 et 1, car l'itinérance sortante n'est pas supportée sur ces NetID privés par définition.

À partir de la version 7.2, l'itinérance devient possible tout en partageant le même NetID dédié (supérieur au NetID 0x000001) sur différentes plateformes ThingPark, grâce à un sous-réseau virtuel NetID/NwkID.

Lorsqu'un NetID donné (par exemple le NetID d'Actility �x000002) est divisé en plusieurs sous-réseaux, un bloc DevAddr distinct doit être attribué à chaque cluster LRC, afin que le trafic backend puisse être correctement acheminé vers/depuis les network servers pairs via ThingPark Exchange.

Plus de détails

Remarque

Cette fonctionnalité nécessite le support des Interfaces Backend LoRaWAN® v1.1 et ThingPark Exchange (TEX) version 1.2 et suivantes.

Principaux bénéfices pour les clients

Grâce à cette fonction, le même NetID peut être partagé entre plusieurs plateformes ThingPark, un bloc DevAddr distinct étant attribué à chaque plateforme.

Ceci est particulièrement intéressant pour les déploiements TPE SaaS et auto-hébergés où :

• Différents clients utilisant les centres de données régionaux TPE SaaS d'Actility peuvent tirer parti des accords d'itinérance globale d'Actility (en utilisant le NetID d'Actility 0x000002) pour se connecter avec des réseaux LoRaWAN® publics et privés pairs dans le monde entier.

• Les grands déploiements de TPE auto-hébergés composés de multiples plateformes edge peuvent partager le même NetID dédié, tout en attribuant un sous-réseau à chaque plateforme TPE auto-hébergée.

Activation de la fonction

Cette fonctionnalité est désactivée par défaut.

Pour l'activer, chaque plateforme SaaS doit se voir attribuer un bloc DevAddr distinct dans le tableau LRC O. Cette configuration est effectuée par l'équipe Actility NetOps pour chaque plateforme SaaS régionale.

Pour TPE auto-hébergé, la fonctionnalité peut être activée en allouant un sous-réseau DevAddr dans Cockpit. Pour en savoir plus, consultez le Guide d'administration et de dépannage de TPE.

Limitations de la fonction

Le sous-réseautage NetID reste à l'échelle de la plateforme, c'est-à-dire que les différents locataires utilisant le même NetID dans la même plateforme ne peuvent pas avoir de sous-réseaux différents (blocs DevAddr) attribués à chaque locataire.

Rapport enrichi des métadonnées d'itinérance passive vers AS/WLogger RDTP-14913

À partir de TP7.2, les métadonnées supplémentaires suivantes sont rapportées par sNS aux serveurs d'application, dans un contexte d'itinérance passive :

• Au lieu de rapporter un GWID virtuel (commun à toutes les passerelles d'un fNS donné), sNS rapporte maintenant l'ID passerelle fNS réel à l'AS. Cette information est également affichée dans Wireless Logger.

  Note

  En cas où le vrai GWID n'est pas reporté par fNS, sNS rapporte le GWID virtuel (interne) comme dans TP7.1.

• De plus, sNS rapporte à l'AS (et WLogger) le nombre réel de passerelles, comptant la réception de la trame UL via les passerelles domestiques et d'itinérance dans la fenêtre de déduplication du sNS.

• Enfin, le NetID et l'NSID de chaque partenaire fNS sont également rapportés à l'AS à partir de TP7.2.

Plus de détails

Avantages clés pour les clients

Cette fonctionnalité fournit aux opérateurs de réseau sNS des informations précieuses pour analyser et résoudre leur trafic d'itinérance passive:

• Le rapport de l'ID passerelle réel au lieu de l'ID passerelle virtuel permet aux opérateurs sNS de mieux résoudre les problèmes de couverture de l'itinérance passive avec leurs homologues fNS.

• Les métriques supplémentaires d'itinérance passive fournies par cette fonctionnalité rendent les métadonnées UL plus complètes, surtout en cas de réception du même paquet UL par plusieurs passerelles appartenant à différents opérateurs de réseau.

Activation de la fonction

Cette fonction est automatiquement disponible après la mise à niveau de la plateforme à la version 7.2. Elle ne s'applique qu'aux opérateurs du serving Network Server (sNS) ayant activé le cas d'utilisation d'itinérance sortante, c'est-à-dire ayant des capteurs en itinérance sortante vers des réseaux étrangers.

Limitations de la fonctionnalité

Aucune.

Conserver les paramètres radio optimisés du sNS pour les capteurs en itinérance sortante RDTP-15099

Pour un fonctionnement correct de l'itinérance passive, le sNS doit connaître la/les RF Region(s) du fNS afin d'indiquer aux capteurs en itinérance sortante quel plan de canaux RF doit être utilisé lors de l'itinérance vers le réseau fNS.

TPE 7.1 a introduit un mécanisme de synchronisation automatique via TEX : chaque NS publie ses RF regions sur TEX, puis TEX distribue ces RF regions à tous les sNS ayant un accord d'itinérance avec chaque fNS. Pour en savoir plus sur cette approche automatique, consultez Intégration avec ThingPark Exchange pour les cas d'utilisation d'itinérance et d'activation.

À partir de la version 7.2, pour éviter d'obliger sNS à utiliser la RF region de fNS sans aucune modification, sNS peut désormais fusionner les informations pertinentes de la RF region de fNS avec sa propre RF region "roaming-generic":

• LRC supporte une RF Region « roaming-generic » pour chaque opérateur sNS et copie automatiquement les attributs de RF Region présents dans ce fichier « roaming-generic » dans le RFregion de chaque fNS (provenant de TEX).

• Dans TP7.2, LRC inclut un modèle itinérance RF Region par défaut pour chaque bande ISM, noté ALL-<ISM band>-DEFAULT-RFREGION-TEMPLATE. Les modèles par défaut intègrent les paramètres recommandés pour les algorithmes radio de ThingPark tels que ADRv3, configuration RX1/RX2, sélection best-LRR, optimisation RX2...

Plus de détails

Principaux bénéfices pour les clients

Grâce à cette fonctionnalité, les opérateurs de réseau sNS peuvent facilement utiliser leurs paramètres radio optimisés pour ADRv3, RX2 Optimization, NFR924 (etc..), même lorsque leurs capteurs se déplacent sur d'autres réseaux.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible dans ThingPark Enterprise 7.2.

Limites des fonctionnalités

Aucune.

Formatage harmonisé des dates/heures RDTP-2553

À partir de la version 7.2, le formatage de la date/heure utilisé par les interfaces graphiques de ThingPark Enterprise & Wireless Logger est modifié comme suit :

• Le format de date est AAAA-MM-JJ, exemple : 2022-04-28.

• Une date relative est affichée lorsque cela est applicable, par exemple Aujourd'hui, Hier.

• Le format d'heure est hh:mm:ss[.s] au format 24 heures, les millisecondes sont facultatives. Exemple : 12:00:32.214.

Plus de détails

Principaux avantages pour le client

Représentation standard et plus complète des formats date/heure dans l'interface graphique (y compris les exports csv).

Activation de la fonctionnalité

Cette fonction est automatiquement disponible après la mise à niveau de la plateforme à la version 7.2.

Limitations de la fonction

Aucune.

Scalabilité améliorée de LRC pour traiter des millions de paquets UL tardifs RDTP-14605

Cette fonction introduit un nouveau mécanisme de contrôle de flux sur le réseau central LRC pour améliorer sa capacité à gérer des millions de paquets uplink tardifs causés par une déconnexion temporaire du lien entre les passerelles et le réseau central.

Plus de détails

Dans ce nouveau mécanisme, des paquets uplink tardifs sont stockés par le LRC dans Kafka jusqu'à ce qu'ils puissent être traités. Cette fonctionnalité supporte un nouveau fil LRC pour lire les paquets UL tardifs depuis Kafka et les dispatcher sur les autres fils LoRa.

Considérations principales :

• Les paquets uplink non en retard sont priorisés par rapport aux paquets en retard. C'est généralement nécessaire pour les capteurs de classe A lorsque le paquet UL doit être répondu en temps voulu par un paquet DL sur les créneaux RX1/RX2. Pour les paquets UL tardifs, les créneaux RX1/RX2 sont déjà passés.

• Le traitement des paquets UL tardifs par le réseau central LRC doit éviter l'inondation des Serveurs d'Applications des clients.

Principaux avantages pour le client

Grâce à cette fonctionnalité, le système ThingPark peut absorber des millions de paquets uplink en retard étant décongestionnés par les passerelles LRR après une panne temporaire de la passerelle au réseau central.

Exemples de scénarios supportés :

• Panne globale du réseau de backhaul entre les passerelles et le réseau central (par exemple, panne 3G/4G), déconnectant plusieurs milliers de passerelles pendant quelques heures.

• Problème de réseau central (par exemple, problème de centre de données sans redondance géographique du réseau central), déconnectant tous les passerelles de la plateforme (jusqu'à 50 000 passerelles) pendant quelques minutes.

Dans les deux exemples, en supposant que la plateforme ThingPark fonctionne à sa capacité maximale de 1500 messages/s E2E, quelques millions de trames uplink seront traitées par les passerelles et devront être traitées de manière transparente et fiable par le réseau central.

De plus, les mécanismes de contrôle de flux apportés par cette fonction garantissent que les serveurs d'application ne soient pas surchargés par trop de trames uplink tardives après la reprise du service.

Activation de la fonctionnalité

Cette amélioration est activée par défaut après la mise à niveau de la plateforme vers la version 7.2.

Pour la désactiver, réglez [kafkalateul].enable=0 dans le fichier lrc.ini personnalisé.

Limites des fonctionnalités

Aucune.

Support jusqu'à 200 capteurs partageant la même DevAddr RDTP-19004

Avant la version 7.2, le nombre maximum de capteurs partageant le même DevAddr est limité à 20.

À partir de TP7.2, le LRC peut desservir jusqu'à 200 capteurs partageant le même DevAddr sans impact négatif sur les performances du système, grâce à la gestion optimisée des collisions DevAddr introduite par cette fonctionnalité.

Plus de détails

Principaux avantages pour les clients

Grâce à cette fonctionnalité, les abonnés ThingPark peuvent déployer beaucoup plus de capteurs (x10) en utilisant des NetIDs dédiés qui ont de petites plages DevAddr (par exemple, NetID de type 6).

Exemple (pour un NetID de type-6)

• Nombre maximum de capteurs dans TP7.1 : 2^10 * 20 = 20 480 capteurs.

• Nombre maximum de capteurs dans TP7.2 : 2^10 * 200 = 204 800 capteurs.

De plus, les déploiements de plus de 20 capteurs ABP partageant le même DevAddr deviennent possibles avec cette fonctionnalité.

Activation de la fonctionnalité

Cette amélioration est désactivée par défaut. Pour configurer le nombre maximum de capteurs partageant le même DevAddr, le paramètre systémique suivant doit être configuré dans lrc.ini :

[fdb]
        maxDevEUIPerDevAddr (default = 20)

Note Ce paramètre doit être configuré avec soin en fonction de chaque segment de dimensionnement de la plateforme TPE auto-hébergée.

Limitations de la fonction

Cette optimisation est limitée aux capteurs LoRaWAN® 1.0.x, les capteurs LoRaWAN® 1.1 étant hors de portée.

De plus, la charge maximale de trafic UL supportée (en messages/s) dépendra de la probabilité de collision de DevAddr :

• La limite actuelle de TPE SaaS de 1500 UL/sec + 300 DL/sec considère pas plus de 10 collisions de capteur par DevAddr.

• Dans le pire des cas d'une probabilité de collision DevAddr de 100 % entre 200 capteurs, la charge de trafic maximale supportée doit être limitée à 150 UL/sec + 30 DL/sec.

Support des blocs NetID de type-7 RDTP-18143

À partir de la version 7.2, les administrateurs ThingPark peuvent utiliser le NetID de type-7 attribué par la LoRa Alliance, en plus des autres NetID conventionnels 0...6.

Plus de détails

Pour en savoir plus sur les types de NetID, voir LoRaWAN® Backend Interfaces specification.

Les NetID de type-7 sont généralement attribués par la LoRa Alliance par blocs de 16 ou 32 NetIDs individuels continus.

Remarque

La notion de bloc NetID, introduite dans TP 7.2, n'est pas restreinte aux NetID de type-7 : elle peut également être utilisée pour d'autres types, à condition que tous les NetID du bloc soient continus.

Pour supporter les blocs NetID dans ThingPark, la configuration NetID est améliorée pour référencer un NetID principal + un sous-réseau DevAddr :

• Le NetID principal est le premier NetID du bloc, c'est-à-dire le NetID ayant la valeur hexadécimale la plus basse dans le bloc continu. Ce NetID principal est celui utilisé sur les interfaces de backend pour l'itinérance (avec un pair NS) et les flux d'activation par OTA (avec un pair JS). De plus, seul le NetID principal est signalé à AS et affiché dans WLogger pour les paquets UL/DL échangés via l'itinérance passive.

• Le sous-réseau DevAddr définit la taille du bloc continu.

Exemple Le sous-réseau DevAddr FE0010/20 exprime le pool de DevADDRs FE0010-FE001F qui est un sur-ensemble associé à un bloc de 16 NetID de type -7 contigus.

Remarque

Tous les NetID du bloc sont utilisés dans le processus d'allocation de DevAddr, grâce au sous-réseau DevAddr (également connu sous le nom de pool DevAddr).

Principaux avantages pour les clients

Les NetID de type-7 peuvent être attribués par la LoRa Alliance à tout opérateur LoRaWAN®, sans nécessairement être un membre de la LoRa-Alliance. Ainsi, le support des NetID de type-7 dans ThingPark simplifie grandement le processus d'acquisition de NetID pour les opérateurs souhaitant utiliser des services d'itinérance.

Activation de la fonctionnalité

La configuration d'un NetID de type-7 individuel (c'est-à-dire, pas un bloc de NetID contigus) reste inchangée par rapport aux NetID de type 0/3/6 supportés depuis les versions précédentes.

Pour configurer un bloc de NetID de type-7 (fonctionne également pour d'autres types de NetID), l'administrateur de la plateforme doit :

• Configurer le NetID principal du bloc en appliquant le même processus conventionnel que pour configurer un NetID individuel, par exemple, depuis Cockpit pour les TPE auto-hébergés.

• Configurer le sous-réseau DevAddr, alias bloc de pool DevAddr.

Pour TPE auto-hébergé, l'administrateur de la plateforme doit uniquement configurer le NetID principal et la taille du bloc NetID dans Cockpit. Ensuite, le sous-réseau DevAddr sera dérivé en conséquence par le système et affiché dans Cockpit. Pour en savoir plus, consultez Guide d'administration et de dépannage TPE.

Cette fonctionnalité est automatiquement disponible après la mise à jour de la plate-forme à la version 7.2.

Voici un exemple pour un bloc de type-7 de 16 NetID contigus commençant par NetID 0xE0 00 50 jusqu'à NetID 0xE0 00 5F :

• Le NetID principal doit être 0xE0 00 50.

• Le sous-réseau DevAddr (alias bloc de pool DevAddr) doit être 0xFE0028/21, selon l'illustration suivante :

  • Pour le premier NetID du bloc (E0 00 50), le sous-réseau DevAddr selon les interfaces de backend est 0xFE00280/25 : 0xFE (préfixe de type) + 0b 0 0000 0000 0101 0000 (17LSB) → 0b1111 1110 0000 0000 0010 1000 0000/25.

  • De même, pour le dernier NetID du bloc (E0 00 5F), le sous-réseau DevAddr selon les interfaces de backend est 0xFE002F8/25 : 0xFE (préfixe de type) + 0b 0 0000 0000 0101 1111 (17LSB) → 0b1111 1110 0000 0000 0010 1111 1000/25.

  Le sous-réseau DevAddr pour le bloc agrégé de 16 NetID doit être FE0028/21

  0b 1111 1110 0000 0000 0010 1000 0000/25
  0b 1111 1110 0000 0000 0010 1111 1000/25
  0x    F    E    0    0    2    1 /21

Limites des fonctionnalités

La mise en œuvre actuelle présente les limitations suivantes, toutes seront levées dans une future version de ThingPark :

• Certains blocs de 32 NetID de type-7 (par exemple, E00010, E00030, E00050, E00070...) produisent des sous-réseaux DevAddr non contigus ; par conséquent, seul un sous-réseau DevAddr correspondant à un bloc 16-NetID peut être configuré dans ThingPark pour allouer des DevAddr aux capteurs OTAA.

• Si un capteur OTAA est activé via un Join Server (JS) externe tiers, et que le network server d'origine du capteur utilise un bloc NetID (type-7 ou non), l'identifiant NetID exact du capteur au sein du bloc peut ne pas être connu de ce JS – seul le NetID principal serait connu. Par conséquent, le NetID envoyé au capteur dans le Join-Accept peut ne pas correspondre à la partie NwkID du DevAddr assigné.

Remarque

Cette limitation ne s'applique PAS au service d'activation ThingPark (TPA), car le NetID exact du capteur est dérivé par TPA à partir du bloc DevAddr alloué, indépendamment du NetID principal initialement défini lors du processus de réclamation automatique.

Configuration améliorée des e-mails de notification d'alarme RDTP-18480

Avant la version 7.2, un administrateur pouvait définir la liste des destinataires d'e-mails pour les alarmes des capteurs et des passerelles via le panneau des paramètres, en fournissant directement l'adresse e-mail dans un champ de texte libre.

À partir de la version 7.2, la configuration des destinataires d'e-mails pour les alarmes des capteurs et des passerelles est améliorée comme suit :

• Un administrateur de l'abonnement TPE peut activer/désactiver les notifications par email pour les alarmes de périphérique et/ou de passerelle (avec une gravité minimale donnée) pour tout compte utilisateur.

• Un utilisateur sans rôle d'administrateur peut activer/désactiver les notifications par e-mail pour les alarmes des capteurs et/ou des passerelles (avec une sévérité minimale donnée) pour son propre compte.

• Un administrateur de l'abonnement TPE peut également définir des e-mails en texte libre (non liés à des comptes utilisateurs existants) comme destinataires des alarmes par e-mail, via le panneau "Paramètres" > "Alarmes".

Plus de détails

Voici un exemple du widget de notification par e-mail ajouté à la page du profil utilisateur.

Principaux avantages pour les clients

Cette fonctionnalité améliore l'expérience des utilisateurs/administrateurs lors de la configuration de la liste des destinataires d'e-mails pour les alarmes des capteurs et des passerelles.

• Grâce à cette amélioration, l'auto-opt-in/out par des non-administrateurs devient possible, sans demander l'aide de l'administrateur.

• Les administrateurs peuvent facilement mapper les destinataires d'e-mails à des comptes utilisateurs, sans perdre la possibilité de définir des e-mails gratuits pour envoyer des e-mails d'alarme à des systèmes de surveillance tiers.

Activation de la fonctionnalité

Cette fonction est automatiquement disponible après la mise à niveau de la plateforme à la version 7.2.

Les adresses e-mail gratuites enregistrées pour les notifications d'alarme et correspondantes aux adresses e-mails des utilisateurs existants sont automatiquement migrées par le système vers le nouveau cadre, c'est-à-dire que les paramètres associés sont directement visibles sous le profil de chaque utilisateur.

Limites des fonctionnalités

Les restrictions de domaine ne s'appliquent pas aux adresses e-mail libres configurées par les administrateurs sous "Paramètres" > "Alarmes". En d'autres termes, toutes les alarmes correspondant à la sévérité minimale seront notifées par e-mail aux destinataires, quel que soit l'affectation de domaine liée aux capteurs ou passerelles sous-jacents.

Pour en savoir plus sur les domaines administratifs et les restrictions de domaine, consultez Multi-tenant dans le même abonnement (RDTP-8479).