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

Itinérance passive RDTP-4710 RDTP-9402

L'itinérance passive permet à un capteur de maintenir sa session LoRaWAN® lorsqu'il s'éloigne de son réseau d'origine vers un réseau visité. Dans ce scénario, le visited (or forwarding) Network Server (fNS) relaie les trames LoRaWAN entre le capteur et le serving/home Network Server (sNS) conformément au diagramme suivant :

Plus de détails

La session MAC LoRaWAN® reste contrôlée par le home/serving Network Server, c.-à-d. que toutes les commandes MAC, l'ADR et les décisions de routage des downlinks sont gérées par le réseau d'origine. De plus, seul le home Network Server possède une interface avec le Application Server du capteur.

Pour plus de détails sur l'itinérance passive et ses flux de messages, veuillez vous référer aux Interfaces Backend LoRaWAN® v1.1 spécifications.

note

L'implémentation du Roaming Passif dans la version actuelle est basée sur le mode sans état, c'est-à-dire que le fNS ne garde aucun contexte de session des capteurs visiteurs. Grâce à sa simplicité, ce mode est compatible avec toutes les implémentations de network servers et offre donc une meilleure interopérabilité avec les network servers non-Actility.

Cas d'utilisation de l'itinérance

• Itinérance entrante signifie que les capteurs étrangers appartenant à vos partenaires d'itinérance convenus sont autorisés à être desservis par votre Réseau d'Accès Radio (RAN) pour router leurs paquets uplink/downlink LoRaWAN® vers/depuis leur réseau d'origine. En mode roaming-in, votre network server agit comme un forwarding Network Server (fNS).

• Roam-out signifie que vos propres Capteurs (provisionnés dans votre compte TPE) sont autorisés à roamer en dehors de votre zone de couverture RAN, tout en étant servis par des gateways fournies par vos partenaires d'itinérance convenus et en routant le trafic de vos Capteurs vers votre network server. En mode roaming-out , votre network server agit comme un serving/home Network Server (sNS/hNS).

  note

  Le cas d'utilisation roam-out nécessite d'assigner un NetID > 000001 à vos Capteurs en itinérance, puisque les NetID privés (000000 et 000001) ne prennent pas en charge le roaming-out.

ThingPark 7.0 supporte les cas d'utilisation d'itinérance suivants :

• Itinérance entrante uniquement : vous ouvrez votre RAN pour desservir des capteurs étrangers appartenant à vos partenaires d'itinérance convenus, en plus de vos propres capteurs.

  • L'itinérance entrante est utile pour atténuer les collisions/interférences RF, comme détaillé dans la section "Avantages-clés pour le client".

  • Ce cas d'utilisation ne nécessite pas de NetID dédié, vous pouvez donc utiliser le NetID privé=000001 mais cela implique que vos partenaires d'itinérance prennent également en charge la v1.1 de la spécification LoRaWAN® Backend Interfaces.

• Itinérance entrante + itinérance sortante : itinérance bidirectionnelle complète permettant aux capteurs étrangers (de partenaires convenus) d'entrer dans votre réseau tandis que vos propres capteurs peuvent être desservis par des passerelles étrangères appartenant à vos partenaires d'itinérance convenus.

  • Ce cas d'utilisation nécessite un NetID dédié : vous pouvez soit obtenir votre propre NetID auprès de l'Alliance LoRa, soit utiliser une partie du NetID d'Actility (NetID = 000002).

    note

    Les capteurs non-itinérants doivent utiliser NetID=000000, pour préserver l'ensemble du pool de DevAddr de votre NetID dédié aux capteurs en itinérance.

  • En utilisant une partie du NetID d'Actility=000002, vous exploiterez automatiquement les accords d'itinérance globaux d'Actility, vous épargnant l'effort de négocier des accords avec les différents opérateurs de réseau LoRaWAN®.

    note

    L'utilisation du NetID=000002 d'Actility implique également que vos partenaires d'itinérance prennent en charge la v1.1 de la spécification LoRaWAN® Backend Interfaces.

Notes

À moins que vos partenaires d'itinérance pairs ne prennent en charge la v1.1 de la spécification LoRaWAN® Backend Interfaces, la seule possibilité de roamer avec eux est d'utiliser votre propre NetID dédié (assigné par la LoRa Alliance), puisque la v1.0 de la spécification Backend Interfaces n'autorise pas l'utilisation de NetID partagés.

Les clients TPE qui ne sont ni intéressés par les modes d'itinérance entrante ni sortante doivent définir leur NetID à 000000.

L'itinérance dans ThingPark Enterprise est fournie uniquement via le hub ThingPark Exchange (TEX). Pour en savoir plus, voir Intégration avec ThingPark Exchange pour les cas d'utilisation d'itinérance et d'activation.

Voir Activation de la fonctionnalité pour plus de détails sur le processus d'activation global pour TPE SaaS et TPE auto-hébergé, y compris la sélection des modes d'itinérance cibles.

Une fois la fonctionnalité configurée globalement au niveau de l'abonnement TPE, l'interface graphique TPE permet d'activer/désactiver le mode itinérance sortante individuellement pour chaque capteur :

• Lors de la création unitaire de capteurs :

  

• Ou lors de l'importation massive de la liste des capteurs, en définissant les fonctionnalités avec valeur ajoutée associées à chaque capteur dans la colonne "H". La colonne "Features" supporte une liste de fonctionnalités séparées par des virgules parmi les options "NetworkGeolocation" et "PassiveRoaming".

• Mise à jour d'un capteur existant, via le widget de statut du capteur :

  

note

Le trafic itinérance sortante est affiché avec l'icône "PR" dans l'interface graphique de TPE dans le widget "10 derniers paquets" du capteur et le widget "25 derniers paquets" de connexion.

Impact du Wireless Logger

L'application WLogger affiche à la fois le trafic d'itinérance entrante et sortante.

L'icône du paquet est mise à jour pour les paquets uplink/downlink d'itinérance passive :

• « fPR » est affiché pour les paquets uplink/downlink routés par TPE pour les capteurs étrangers (trafic d'itinérance entrante). Dans ce rôle, TPE agit comme un forwarding network server.

• « sPR » est affiché pour les paquets uplink/downlink des capteurs d'origine desservis par des passerelles étrangères appartenant à des partenaires d'itinérance (trafic d'itinérance sortante). Dans ce rôle, TPE agit comme un serving network server.

Rapport aux serveurs d'application

Pour le trafic d'itinérance sortante, les métadonnées rapportées aux serveurs d'application sont enrichies avec les informations supplémentaires suivantes :

• Un indicateur permettant d'indiquer que le paquet a été transféré (uplink) ou délivré (downlink) via un réseau d'itinérance tiers, dont la gateway a été élue comme la "best serving gateway" par le serving Network Server (sNS).

• Le NetID de cet opérateur d'itinérance tiers (forwarding Network Server).

Les nouveaux champs ajoutés aux rapports de liaisons uplink et les_rapports_de_sent_indication downlink sont :

• Itinérance: Indique le type d'itinérance. Ce champ est réglé à 1 uniquement lorsque le cadre uplink/downlink LoRaWAN® a été transmis depuis/vers le capteur via un réseau étranger et que le sNS a sélectionné cette passerelle étrangère comme meilleure passerelle desservante.

• ForwardingNetID: Le NetID du serveur NS de transmission. Ce champ est rempli uniquement lorsque "itinérance" = 1.

• ForwardingNSID: Le NSID du NS de transmission. Ce champ est rempli uniquement lorsque "itinérance" = 1 et que l'interface d'itinérance utilise la version 1.1 du protocole Backend LoRaWAN®.

Segmentation du trafic

Une autre amélioration apportée par cette fonctionnalité est la segmentation du trafic entre les différents abonnements TPE dans un environnement SaaS multi-locataire : À partir de la version 7.0, la segmentation est appliquée à l'échelle de l'abonnement, ce qui signifie que les capteurs de l'abonnement A de TPE ne doivent être desservis que par les passerelles de l'abonnement A, sauf dans les cas suivants :

• Il y a un accord de libre parcours valide entre l'Abonnement-A et l'Abonnement-B.

• Les capteurs de l'Abonnement-A et les passerelles de l'Abonnement-B utilisent le même NetID dédié (NetID différent de 000000 et 000001). Dans ce cas, le trafic réseau entre les abonnements A et B (par exemple en partageant le NetID 000002 d'Actility) n'est pas segmenté car ils sont considérés comme faisant partie du même réseau. Cette règle ne s'applique pas si les abonnements A et B utilisent le NetID privé 000000 ou 000001.

• Les abonnements A et B sont explicitement configurés pour utiliser le même Segregation-ID dans l'interface graphique Device Manager / Network Manager. Ce cas d'utilisation serait pertinent pour les clients ThingPark-Embedded gérant plusieurs abonnements au sein de la même plateforme TPE SaaS et souhaitant partager la couverture de leurs passerelles entre leurs différents abonnements.

Principaux avantages pour les clients

La fonctionnalité d'itinérance passive est cruciale pour :

• Maximiser la couverture LoRaWAN® grâce à des réseaux collaboratifs, en exploitant les Réseaux d'Accès Radio (RAN) déployés par vos partenaires d'itinérance au lieu de se fier uniquement à la couverture de votre propre RAN. L'itinérance passive offre un excellent compromis entre le coût de déploiement du réseau et la QoS de bout en bout pour atteindre les meilleures performances tout en minimisant la décharge de la batterie du capteur et en optimisant les ressources de l'interface aérienne.

• Améliorer la compatibilité LoRaWAN® avec les cas d'utilisation de mobilité : les capteurs finaux peuvent quitter sans problème leur réseau d'origine sans perdre leur connectivité LoRaWAN®.

• Minimiser la collision et l'interférence RF causées à vos passerelles par des capteurs étrangers, en ouvrant le cas d'utilisation "itinérance entrante" : En acheminant les trames uplink déjà reçues par vos passerelles vers le réseau d'origine du capteur étranger, l'itinérance entrante améliore la diversité macro RF et réduit le temps sur l'air du capteur étranger (à travers un facteur d'étalement réduit/une vitesse de données plus rapide et un nombre inférieur de répétitions) et d'un abaissement de la TxPower uplink.

note

Le Roaming Passif a un avantage significatif sur le Roaming de Changement de Cellule en ce qu'il est entièrement transparent pour la version LoRaWAN® des capteurs de terminaison; par conséquent, le roaming passif est entièrement conforme aux capteurs version 1.0.x. De plus, l'itinérance passive exploite pleinement le concept de diversité macro RF en permettant au même capteur d'être desservi par un mélange de passerelles appartenant à différents partenaires d'itinérance.

Un autre avantage de cette fonctionnalité est la segmentation améliorée du trafic entre les différents abonnements TPE SaaS partageant la même plateforme régionale.

Activation de la fonctionnalité

Côté TPE, l'itinérance passive est désactivée par défaut.

Pour TPE auto-hébergé :

• L'activation/désactivation de la fonctionnalité à l'échelle de la plateforme est gérée dans Cockpit, sous "Configuration TPE" > "Configuration LoRa" > champ "Itinérance/Activation".

  note

  Ce champ est également utilisé pour l'activation des capteurs OTA sur le Service d'Activation ThingPark, comme expliqué dans Intégration avec le service d'Activation ThingPark (TPA) RDTP-3381.

• L'administrateur de la plateforme doit ensuite définir le NetID LoRaWAN® en fonction des cas d'utilisation itinérance entrante/sortante cibles décrits dans la section "Description des fonctionnalités".

  Le NetID est composé de 6 chiffres hexadécimaux (sans distinction de majuscules/minuscules) restreints à la liste suivante dans la version 7.0 de TPE :

  • 000000 (NetID privé 0) - interdit si l'itinérance sortante est activée

  • 000001 (NetID privé 1) - interdit si l'itinérance sortante est activée

  • 000002-00003F (type de NetID dédié 0)

  • 600000-7FFFFF (type de NetID dédié 3)

  • C00000-DFFFFF (type de NetID dédié 6)

    note

    À partir de la version 7.0 (grâce à RDTP-9402), l'administrateur de la plateforme TPE auto-hébergée peut changer à tout moment le NetID, mais le DevAddr correspondant des capteurs OTA ne changera qu'après la prochaine demande Join initiée par ces capteurs OTA après avoir modifié le NetID dans le cockpit.

    note

    Les administrateurs de TPE auto-hébergé peuvent configurer, dans Cockpit, des plages de DevAddr spécifiques pour chaque plateforme, de sorte que le même NetID dédié soit réutilisé sur plusieurs plateformes. Cela est aussi connu sous le nom de subnetting du NetID, où chaque plateforme se voit attribuer un pool distinct de valeurs DevAddr au sein du NetID plus large.

• L'administrateur doit également configurer les détails du compte ThingPark Exchange, basés sur les informations fournies par Actility.

  note

  Le NSID est fourni par l'équipe NetOps d'Actility, il doit être unique pour la plateforme TPE auto-hébergée.

  

• Ensuite, l'itinérance sortante peut être activée/désactivée par capteur dans l'interface graphique de TPE.

Pour TPE SaaS :

• L'itinérance passive est désactivée par défaut, puisque le NetID par défaut est réglé à 000000 une fois que les plateformes SaaS régionales sont migrées vers la version 7.0.

• Pour activer l'itinérance, l'équipe de support Actility doit configurer votre abonnement dans les interfaces graphiques Network Manager et Device Manager :

  • Dans les paramètres du Network Manager, réglez le NetID de la passerelle d'abonnement :

    

    • Pour activer le mode "itinérance entrante uniquement", réglez le NetID de la passerelle à = 000001 si vous ne possédez pas de NetID dédié.

    • Pour activer le mode "itinérance entrante + itinérance sortante", réglez le NetID de la passerelle au NetID dédié souhaité (c'est-à-dire différent des NetIDs privés 000000 ou 000001).

  • Dans les paramètres du Device Manager, réglez le NSID de l'abonnement ainsi que le NetID pour les capteurs non-itinérants et itinérants, comme indiqué sur la capture d'écran suivante :

    

    • Pour activer le mode "itinérance entrante + itinérance sortante", réglez le "NetID des capteurs itinérants" au NetID dédié souhaité, laissez le "NetID des capteurs non-itinérants" vide, pour qu'il garde le paramètre par défaut = 000000.

    • Pour le mode "itinérance entrante uniquement", laissez le "NetID des capteurs itinérants" vide, pour qu'il garde le paramètre par défaut = 000000, car le cas d'utilisation de l'itinérance sortante est désactivé.

      note

      Toute modification des paramètres NetID/NSID doit être suivie d'un reprovisionnement complet des objets associés à l'abonnement impacté. Le reprovisionnement complet ne peut être géré que par l'administrateur de la plateforme, alors vous devez contacter l'équipe de support Actility pour accomplir cette tâche.

      Ensuite, l'itinérance sortante peut être activée/désactivée par capteur dans l'interface graphique de TPE.

Important

Outre l'activation de l'itinérance dans TPE, un Network Server doit être déclaré dans ThingPark Exchange (TEX) pour votre abonnement TPE. Vos accords d'itinérance avec vos network servers pairs doivent également être configurés directement dans TEX. Pour en savoir plus, voir Intégration avec ThingPark Exchange pour les cas d'utilisation d'itinérance et d'activation.

Limitations de la fonctionnalité

Dans la version actuelle, les clients TPE utilisant une partie du NetID d'Actility (= 000002) ne peuvent pas négocier librement leurs propres accords d'itinérance, ils héritent du jeu global d'accords d'itinérance d'Actility. De plus, le même pool de DevAddr s'applique à tous les abonnements TPE SaaS utilisant le NetID 000002 au sein d'une plateforme régionale TPE SaaS donnée.

Intégration avec le service d'Activation ThingPark (TPA) RDTP-3381

ThingPark Activation (TPA) est un service géré par Actility offrant une activation sécurisée aux capteurs OTA LoRaWAN® via un serveur de Join sécurisé (JS). Toutes les clés LoRaWAN® sont sécurisées par un module de sécurité matériel (HSM) intégré au service TPA.

Plus de détails

Un processus typique d'activation de capteur OTA consiste en les étapes suivantes :

Étape	Description
#1 - Pré-commissionnement	Le fabricant du capteur importe les informations du capteur (DevEUI, JoinEUI, AppKey, NwkKey (pour les capteurs LoRaWAN® 1.1)) dans TPA. Lors du pré-commissionnement réussi, le fabricant du capteur obtient un jeton de propriété de TPA pour agir comme preuve de possession de ce DevEUI. Le fabricant de capteurs doit communiquer ce jeton de propriété à l'acheteur/propriétaire du capteur ; par exemple, en l'incluant dans le QR code standard spécifié par la LoRa Alliance. À ce stade, le capteur est dit "générique", ce qui signifie qu'il n'est pas encore personnalisé pour (ni associé à) un Network Server LoRaWAN® (NS).
#2 - Mise en service	Lorsqu'un abonné de ThingPark achète ce capteur générique, les deux tâches suivantes doivent être effectuées pour compléter l'étape de mise en service du capteur : Configurer le capteur dans ThingPark Enterprise en fournissant le DevEUI, JoinEUI et en sélectionnant l'option « Join Server externe ». Revendiquer la propriété du capteur dans TPA, en présentant le jeton de propriétaire et en définissant le Home NetID. La procédure de revendication est automatiquement gérée par ThingPark Enterprise envers ThingPark Activation’s Key Manager application sans que l'utilisateur ait à se connecter à TPA et à réclamer manuellement le capteur. À la fin de l'étape de mise en service, le join Server (ThingPark Activation) est prêt à gérer les Join Requests transférées par le home Network Server (NS) pour ce capteur
#3 - Activation	Lorsqu'un capteur OTA mis en service est alimenté, il envoie un message Join Request qui est dirigé vers le Join Server (JS) compétent, identifié par son JoinEUI. Le JS traite la demande et génère un Join Answer. À la fin de cette étape d'activation par voie aérienne, le capteur doit générer ses clés de session MAC et maintenir une session LoRaWAN® sécurisée avec le réseau.

Ce processus en trois étapes est illustré par le schéma suivant :

Le diagramme suivant montre les différents états d'un capteur OTA pendant son cycle de vie, tel que spécifié par LoRaWAN® Backend Interfaces :

Dans l'interface ThingPark Enterprise, l'utilisateur doit provisionner le capteur avec l'option Activation mode = "Over-the-Air Activation (OTAA) with external Join Server" et définir le Owner-token, comme dans cet exemple :

Une fois le capteur provisionné dans TPE, la procédure de revendication est automatiquement déclenchée vers TPA, basée sur le Owner-token fourni par l'utilisateur.

Si la procédure de revendication échoue pour une raison quelconque (par exemple, le capteur n'a pas été pré-commissionné sur TPA, le capteur est déjà réclamé, Owner-token est invalide...), la création de capteur dans ThingPark Enterprise doit échouer avec l'erreur suivante :

Cette procédure de revendication automatique s'applique aussi bien aux cas d'utilisation de création de capteur unitaire qu'aux importations en masse.

Lorsque le capteur est supprimé de ThingPark Enterprise, une demande d'annulation de réclamation est automatiquement enclenchée vers TPA Key Manager si le capteur a été déjà commissionné sur TPA.

note

Dans le but de simplifier l'intégration avec des serveurs d'application de tiers Les payloads uplink des capteurs sont décryptés par ThingPark Enterprise (en utilisant AppSKey) avant d'être transmis à AS. De la même manière, AS doit envoyer le payload downlink décrypté à TPE, déléguant la tâche de chiffrement au Network Server TPE.

Avantages clés pour les clients

Le service ThingPark Activation offre un moyen sécurisé d'activer les capteurs OTA :

• Stockage sécurisé des clés racine LoRaWAN® via un module de sécurité matérielle (HSM) : Le HSM est auto-protégé et garantit que, indépendamment de l' emplacement ou du propriétaire de l'hébergement, les données protégées par le HSM sont aussi sûres que si elles étaient hébergées par un tiers de confiance. Le HSM garantit aussi que si une plateforme d'hébergement est compromise, par exemple accédée par des pirates non autorisés, les données protégées sont toujours sûres. En cas d'attaque physique, un HSM se détruira avant de libérer les données protégées. Typiquement, un HSM ne libérera ses données secrètes que lorsqu'une série de (deux ou plus) cartes à puce est fournie.

  Les HSMs représentent l'état de l'art dans la protection des données secrètes. Ils sont utilisés par des banques dans le monde entier pour conserver les secrets racine des cartes intelligentes.

• L'utilisation d'un service d'activation sécurisée simplifie et sécurise de manière significative le processus d'échange entre les fabricants de capteurs et les propriétaires de capteurs : au lieu de partager de manière peu fiable les clés racine LoRaWAN® (AppKey dans LoRaWAN® 1.0.x) en texte clair, les clés racine sont provisionnées en toute sécurité par le fabricant de capteur dans le Join Server et ne doivent pas être directement partagées avec le propriétaire du capteur. Seul le Owner-token est alors communiqué au capteur, en tant que preuve de propriété pendant la processus de réclamation.

  De plus, les AppKeys ne peuvent pas être imprimés sur les QR codes (pour raisons de sécurité), tandis que les Owner-tokens sont déjà présents dans le QR code standard défini par la LoRa Alliance. L'utilisation de QR codes standard simplifie considérablement le processus d'onboarding du capteur.

• L'activation OTA d'un capteur hors de son réseau d'origine, c'est-à-dire un capteur envoyant un Join Request via un réseau LoRaWAN® étranger, ne peut être supportée que lorsque l'activation du capteur est gérée par un Join Server central (par opposition à l'approche combinée NS-JS).

Activation de la fonctionnalité

L'activation de cette fonction nécessite les actions suivantes :

• Côté ThingPark Enterprise (TPE) : un compte TEX est requis et NSID doit être alloué par Actility NetOps.

  • Pour le TPE auto-hébergé, l'activation de la fonction est gérée par Cockpit, sous "Configuration TPE" > "Configuration LoRa" > champ "Itinérance/Activation"

    Note Ce champ est également utilisé pour la configuration de l'itinérance, comme expliqué dans Itinérance passive (RDTP-4710 et RDTP-9402).

    

  • Pour le TPE SaaS, le compte TEX est directement configuré par l'équipe Actility NetOps, avec un NSID global à l'échelle de la plateforme.

• Côté ThingPark Exchange (TEX) :

  • Pour le TPE SaaS : chaque instance TPE SaaS utilisant un NetID dédié doit être déclaré sur TEX en tant que Network Server. Cette déclaration est faite par l'équipe Actility NetOps. Les instances TPE SaaS utilisant le NetID privé 0 ou 1 doivent réutiliser le compte Network Server d'Actility sur TEX.

  • Pour les TPE auto-hébergés : chaque instance TPE auto-hébergée utilisant des services TPA (quel que soit le NetID) doit être déclarée comme Network Server distinct sur TEX. Cette déclaration est réalisée par l'équipe Actility NetOps.

    Pour en savoir plus sur l'intégration TPE avec TEX, consultez Integration with ThingPark Exchange for roaming and activation use-cases.

Cette fonctionnalité nécessite une version 1.2.0 ou supérieure de ThingPark Exchange.

Note Les plateformes TPE auto-hébergées doivent avoir accès à Internet pour se connecter avec ThingPark Exchange.

Une fois que l'instance de ThingPark Enterprise est connectée avec succès à ThingPark Activation, via le hub ThingPark Exchange, l'activation de cette fonction est gérée par capteur à partir de l'interface utilisateur de TPE : lors de la création de capteur, utilisez l'option Mode d'activation = "Over-the-Air Activation (OTAA) avec Join Server externe" et définissez le Owner-token fourni par le fabricant de capteur (ou scanné via le format standard de QR code de la LoRa Alliance).

Limitations de la fonctionnalité

Par défaut, cette fonctionnalité considère que les serveurs d'application continuent de déléguer l'étape de chiffrement/déchiffrement du payload au Network Server de ThingPark. Si l'utilisateur souhaite activer le mode de chiffrement de bout en bout du payload entre le capteur et l'application server, il doit associer ses capteurs à une Application Server Transport Key (ASTK) dans le Key Manager de TPA (cette action n'est pas actuellement supportée via l'UI de TPE).

Integration with ThingPark Exchange for roaming and activation use-cases

Les fonctions d'itinérance et d'activation OTA LoRaWAN® nécessitent que les Network Servers (NS) et les Join Servers (JS) soient configurés afin qu'ils puissent traiter les messages entrants de leurs pairs et les acheminer vers leurs destinations respectives en fonction des accords d'itinérance. Les paramètres de configuration incluent des URI ou adresses IP correspondant aux JoinEUIs et NetIDs, des règles de pare-feu (par ex., autorisant des connexions TCP entrantes depuis certaines adresses IP), des identifiants d'authentification HTTP, des politiques d'itinérance LoRaWAN® (par ex., autorisant le Passive Roaming, les capteurs itinérants entrants, etc.), des Usage Data Records (UDRs)...etc.

À mesure que le nombre de nœuds (NS, JS) impliqués dans l'itinérance augmente, il devient difficile de gérer et de maintenir la configuration et la tenue de registres qui augmentent de façon exponentielle entre pairs.

Un hub d'itinérance aide à transformer l'interconnexion entre plusieurs NS/JS d'une topologie en maille à une topologie en étoile en s'insérant entre deux nœuds. Ce changement de topologie réduit la complexité de gestion de l'itinérance de O(n2) à O(n).

Sans topologie en étoile, une interconnexion directe serait requise entre chaque deux nœuds Network Server ou Join Server, selon le schéma illustratif suivant :

Alors qu'un hub centralisé offre une topologie en étoile pour minimiser le nombre d'interconnexions et simplifier ainsi radicalement la configuration du backend au sein de l'entreprise. Ceci est illustré par le schéma suivant :

ThingPark Exchange (TEX) est l'état de l'art des hubs d'itinérance, fournissant une topologie en étoile pour interconnecter les Network Servers et les Join Servers et soutenir les flux d'itinérance et d'activation des capteurs LoRaWAN®.

Plus de détails

Pour offrir une intégration transparente entre ThingPark Enterprise et ThingPark Exchange, une interface de plan de contrôle est supportée entre le TPE Network Server (également connu sous le nom de LRC) et ThingPark Exchange (TEX). Cette interface interne ThingPark permet à TEX de mettre à jour dynamiquement la configuration du LRC TPE de ses pairs NS et JS. En d'autres termes, configurer les accords d'itinérance entre votre network server et les network servers pairs, autant qu'ajouter des join servers à la portée de votre network server, est entièrement contrôlé depuis ThingPark Exchange. Ensuite, TEX envoie automatiquement au LRC la configuration technique à jour relative à chaque Network Server / Join Server pair, tels que les profils de routage, les identifiants de sécurité, la version du protocole Backend supportée par le nœud pair...

De plus, cette interface de contrôle entre TPE et TEX permet la synchronisation en bande - via TEX - des plans de canaux RF de NS en transfert (également connus sous le nom de RF Regions) avec ses nœuds NS pairs partageant un accord d'itinérance. Cette synchronisation est essentielle pour garantir que chaque NS soit informé du plan de canal (RF Region) utilisé par les gateways appartenant à son pair d'itinérance (forwarding NS), car un décalage de canal entraînera une perte de paquets uplink pour les capteurs en roam-out.

• Pour le TPE SaaS, l'exportation des RF Regions et le téléchargement sur TEX sont directement gérés par l'équipe NetOps d'Actility.

• Pour les TPE auto-hébergés, pour réaliser cette synchronisation des RF Regions, les gestionnaires TPE doivent exporter leurs configurations RF Region pertinentes à partir de Cockpit et les partager avec Actility pour qu'elles soient téléchargées sur TEX en tant elements RFParamSet.

Améliorations apportées par cette fonctionnalité pour Cockpit des TPE auto-hébergés :

Cockpit est enrichi pour supporter un nouveau menu "TEX operations", sous le panneau "TPE Services" :

• Synchronisation TEX : permet de vérifier l'état de synchronisation entre TPE et TEX.

• Exporter les RF Regions : exporter un fichier tgz contenant toutes les RF Regions correspondant aux bande(s) ISM configurée(s).

  note

  Le menu de maintenance est renommé "opérations de cluster TPE".

Principaux avantages pour les clients

ThingPark Exchange (TEX) offre les avantages suivants :

• Intégration facile et évolutive entre les nœuds backend LoRaWAN® (Network Servers et Join Servers) : grâce à sa topologie en étoile, ThingPark Exchange fournit un seul profil de routage pour le trafic sortant de chaque nœud backend afin d'éviter de définir des profils de routage point à point entre les différents nœuds backend de l'écosystème LoRaWAN®.

• Configurabilité améliorée, grâce à l'interface de contrôle TPE-TEX.

• Contrôle de politique centralisé et extensible.

• Bouclier de sécurité contre les nœuds de peering NS/JS.

• Capacités de facturation et de surveillance : UDRs, statistiques de trafic, tableaux de bord...etc.

Activation de la fonctionnalité

La connexion d'une instance ThingPark Enterprise SaaS avec ThingPark Exchange (TEX) est entièrement sous contrôle de l'équipe Actility NetOps. Cela inclut les tâches suivantes :

• Attribution d'un NSID (Network Server ID) globalement unique à chaque abonnement TPE SaaS utilisant un NetID dédié > 000001.

• Côté TEX :

  • Déclarez le Network Server correspondant à cet abonnement TPE dans TEX, avec toutes les informations techniques sur ce Network Server : NSID, NetID, identifiants d'authentification mutuelle LRC-TEX, RF Regions applicable (également connus sous le nom de RFParamSets dans TEX)...

  • Configurez les accords d'itinérance de ce Network Server avec d'autres réseaux.

  • Associez ce Network Server avec des Join Servers partenaires, pour servir l'utilisation d'activation de capteur OTA.

• Côté TPE SaaS :

  • Configurez la table O du LRC avec le NetID dédié et les identifiants TEX de l'abonnement TPE.

  • Configurez l'NSID et le NetID de l'abonnement TPE dans les interfaces utilisateur Gestionnaire de périphériques/Gestionnaire de réseau, comme décrit dans Itinérance passive RDTP-4710 RDTP-9402.

La connexion d'une plateforme ThingPark Enterprise auto-hébergée avec ThingPark Exchange (TEX) nécessite les tâches suivantes :

• Prérequis Le serveur ThingPark Enterprise auto-hébergé doit disposer d'un accès à Internet pour se connecter avec ThingPark Exchange.

• L'équipe Actility NetOps doit assigner un NSID globalement unique à chaque plateforme TPE auto-hébergée.

• L'administrateur TPE auto-hébergé doit communiquer les informations suivantes à l'équipe Actility NetOps :

  • NetID

  • URL(s) TPE

  • RF Regions pertinentes (également connues sous le nom RFParamSet(s) dans TEX) que TEX partagera avec les NS pairs.

  • Sous-réseaux NetID dédiés / pools DevAddr, pertinents uniquement dans le cas où le même NetID dédié (> 000001) est réutilisé sur plusieurs plateformes TPE auto-hébergées avec un pool DevAddr distinct par plateforme.

• Ensuite, l'équipe Actility NetOps doit effectuer les opérations suivantes dans TEX :

  • Déclarez le Network Server correspondant à cet abonnement TPE dans TEX, avec toutes les informations techniques : NSID, NetID, identifiants d'authentification mutuelle LRC-TEX, RF Regions applicables (RFParamSets), sous-réseau ID, URL(s) TPE...

  • Configurez les accords d'itinérance de ce Network Server avec d'autres réseaux.

  • Associez ce Network Server avec des Join Servers partenaires, pour servir l'utilisation d'activation de capteur OTA.

• Enfin, l'équipe Actility NetOps doit communiquer les informations suivantes avec l'administrateur du TPE auto-hébergé qui doit les configurer dans Cockpit, comme expliqué dans la section activation de la fonctionnalité de Itinérance passive RDTP-4710 RDTP-9402 et Integration with ThingPark Activation (TPA) service RDTP-3381 :

  • Le NSID attribué
  • URL TEX
  • Identifiants HTTP (c'est-à-dire, identifiants d'authentification mutuelle LRC-TEX)

Cette fonctionnalité nécessite une version 1.2.0 ou supérieure de ThingPark Exchange.

Limitations de la fonctionnalité

Aucune.

Downlink multicast RDTP-9925

Le multicast est une fonctionnalité cruciale pour la transmission en downlink ; il permet d'envoyer la même trame de downlink à de nombreux Capteurs en même temps. Ceci est particulièrement intéressant pour les capteurs de classe B et de classe C agissant comme actionneurs, où le serveur d'application peut contrôler de nombreux Capteurs en envoyant une seule trame de downlink (par exemple, allumer/éteindre des lampadaires ou des compteurs de gaz, etc.).

La fonction multicast optimise considérablement la capacité downlink et évite la surcharge des ressources de l'interface aérienne pour de nombreux cas d'utilisation de classes B/C. De plus, le multicast est une fonctionnalité obligatoire pour supporter la Mise à jour de Firmware Over the Air (également connue sous le nom de FUOTA).

Plus de détails

Comment fonctionne le multicast

Pour supporter le multicast, un capteur doit être configuré avec une DevAddr multicast, une NwkSKey multicast et une AppSKey multicast en plus de sa DevAddr unicast/clefs de session.

Alors que les DevAddr/session keys unicast sont distincts pour chaque capteur, les DevAddr/session keys multicast doivent être les mêmes pour tous les capteurs appartenant au même groupe multicast. Par conséquent, un groupe multicast se compose d'un capteur "virtuel" avec un DevAddr, NwkSKey et AppSKey.

Les capteurs doivent surveiller à la fois les adresses unicast et multicast.

Il existe deux manières de configurer les capteurs avec les DevAddr/session keys du groupe multicast :

1. Soit via une configuration personnalisée intégrée dans la pile du capteur qui est analogue à l'utilisation du mode ABP pour le multicast, même si le capteur utilise le mode OTA pour l'unicast.

2. Ou en utilisant une configuration par liaison radio via des messages de configuration de couche d'application, comme serait spécifié par la LoRa Alliance.

Du point de vue ThingPark, le network server (LRC) ne connaît pas la correspondance entre le capteur multicast "virtuel" et les capteurs "réels" qui y sont associés. La figure suivante illustre le flux de transmission downlink de bout en bout :

Pour supporter le multicast, les capteurs doivent utiliser soit le mode classe B soit le mode classe C. Les Capteurs natifs de classe A peuvent encore utiliser le multicast s'ils sont configurés au niveau applicatif pour passer en classe B ou C pendant la période de planification de la session multicast. Pour plus de détails, voir la Spécification de configuration du Multicast à distance LoRaWAN® v1.0.0.

Transmission de paquets downlink en mode multicast :

Comme spécifiquement énoncé par LoRaWAN, les trames multicast en downlink utilisent le mode "non confirmé", et n'incluent aucune commande MAC.

• Session multicast en classe B : Pour une session multicast en classe B, les capteurs écoutez l'adresse multicast sur des créneaux horaires spécifiques qui ne sont pas nécessairement les mêmes que les créneaux horaires ping unicast. La périodicité des créneaux horaires ping multicast est directement provisionnée dans le groupe multicast, avec la taux de données des créneaux horaires ping multicast et la fréquence de canal.

  Comme l'opération de classe B implique que les LRR soient parfaitement synchronisées par le GPS, une trame multicast en downlink peut être transmise en toute sécurité de manière synchrone sur tous les LRR sans risque de collision, en tirant parti de l'effet d'interférence constructive qui est déjà le cas pour la transmission synchronisée des signaux de beacon.

  Remarque Dans le cas où la passerelle LRR ne peut pas transmettre la trame multicast sur le pingslot programmé, elle retente automatiquement la transmission sur les pingslots disponibles restants durant les périodes de beacon en cours et suivantes (comme en mode unicast) avant d'envoyer une indication d'échec au network server LRC.

• Session multicast en classe C : Pour une session multicast en classe C, les capteurs doivent utiliser le même taux de données RX2 et la même fréquence pour les modes unicast et multicast. La fréquence du multicast et le taux de données sont configurés dans le groupe multicast.

  Pour éviter les collisions radio entre les différentes bases LRR participant à la même session multicast, le réseau LRC applique un algorithme d'évitement de collision comme illustré par le schéma suivant :

  

• Pour tous les LRR synchronisés GPS (passerelles vertes dans la figure ci-dessus) : Le LRC planifie une transmission simultanée comme pour les capteurs de classe B => Des transmissions parfaitement synchronisées (avec une précision de +/- 1 μs) atténuent le risque de collision.

• Pour d'autres LRRs (non synchronisés GPS), le LRC utilise un algorithme de cluster pour regrouper les LRRs suffisamment espacés dans le même cluster, tandis que les LRRs voisins sont placés dans des clusters distincts. La distance minimale requise entre deux LRRs pour partager le même cluster est définie comme "Distance de collision évitée Classe C" et est fixée à 7 Km.

  Le network server LRC planifie la transmission multicast séquentiellement pour chaque cluster : tous les LRR au sein du même cluster transmettent leurs trames multicast downlink en même temps (l'interférence est atténuée par la distance séparant ces passerelles LRR) tandis que les transmissions multicast sur des clusters distincts ne se chevauchent pas dans le temps afin d'éviter les collisions. Ce cas est illustré par les passerelles orange dans la figure ci-dessus.

  note

  Dans le cas où l'emplacement du LRR n'est pas provisionné dans ThingPark (passerelles bleues dans la figure ci-dessus), le LRC considère chaque LRR comme un cluster séparé.

Dans le cas où la première transmission planifiée par le LRC échoue pour certains LRRs (éventuellement après que le LRR ait réessayé la transmission de façon autonome avant d'abandonner), le LRC réessaiera la transmission de la trame multicast jusqu'à ce que le nombre maximum d'essais soit atteint (fixé à 3 essais dans TPE).

La figure suivante illustre le schéma de retransmission utilisé par le network server LRC pour les trames multicast :

Rapports de synthèse multicast

Le network server LRC retourne l'état de transmission de chaque trame multicast au Application Server, dans des Multicast Summary Reports. Pour en savoir plus, voir le Guide du Développeur d’Interface Tunnel LRC-AS.

L’état de transmission des paquets multicast est également affiché dans l'interface utilisateur de TPE dans le tableau de bord du Groupe Multicast, avec la légende de couleur suivante :

• Downlink entièrement envoyé

• Downlink partiellement envoyé (envoyé avec succès sur ≥80% des passerelles LRR ciblées)

• Downlink partiellement envoyé (envoyé avec succès sur ≥30% et <80% des passerelles LRR ciblées)

• Downlink partiellement envoyé (envoyé avec succès sur <30% des passerelles LRR ciblées).

  

Configuration Multicast

Pour configurer le multicast, un Groupe Multicast doit être créé dans ThingPark Enterprise. Pour en savoir plus sur la création d'un Groupe Multicast, voir la section Activation de la fonctionnalité.

Principaux avantages clients

La fonction multicast apporte des avantages majeurs aux clients de ThingPark, elle permet un support efficace des cas d'utilisation suivants tout en minimisant la congestion radio et en optimisant les ressources de l'interface radio downlink :

• Mise à jour du Firmware Over the Air (FUOTA) : Ce service permet aux serveurs d'applications (par exemple, le Serveur Multicast Fiable d'Actility) de mettre à jour le firmware du capteur et/ou la pile LoRaWAN® par voie aérienne. Puisque le même contenu est valide pour un groupe de capteurs, il est inefficace/impratique d'utiliser le mode unicast pour de telles campagnes de mise à jour.

• Reconfiguration Massive de Capteur : Reconfiguration automatisée d'un groupe de capteurs par voie aérienne.

• Cas d'utilisation de l'éclairage public : Action synchronisée sur un groupe de capteurs, typiquement l'allumage/extinction des lampadaires.

• Cas d'usage de comptage : En cas d'urgence, les actionneurs électriques / gaz / eau peuvent interrompre la distribution de manière fiable avec un délai minimal. Le multicast peut être utilisé pour activer ces actionneurs une fois l'urgence terminée.

Activation de la fonctionnalité

Les utilisateurs de TPE peuvent créer de nouveaux Groupes Multicast depuis le panneau "Gérer" à gauche, puis "Groupes Multicast" > Créer.

Ensuite, l'utilisateur doit remplir les informations du Groupe Multicast ainsi que la configuration RF - selon la classe multicast cible (B ou C) - et associer le groupe à une ou plusieurs connexions d'application.

note

Chaque Groupe Multicast doit être associé à au moins une étiquette de passerelle, pour définir les passerelles éligibles pour router les paquets multicast downlink pour ce groupe. Si plusieurs étiquettes sont sélectionnées, l'union de toutes les passerelles appartenant à ces étiquettes constituera la liste des passerelles multicast.

note

Le débit et la fréquence du canal proposés par l'interface utilisateur sont hérités de la configuration de la RF region des passerelles associées au Groupe Multicast (via les étiquettes de passerelle).

Limitations de la fonctionnalité

Les payloads multicast ne peuvent pas être automatiquement décodés dans l'application Wireless Logger car il n'y a pas de métadonnées de profil de capteur / driver associées aux Groupes Multicast.

Provisionnement de capteur par code QR RDTP-12749

La LoRa Alliance™ définit une étiquette standard d'embarquement des capteurs pour simplifier l'étape de provisionnement des capteurs. Cette étiquette est généralement imprimée comme un code QR sur un autocollant collé sur le capteur.

Plus de détails

Le contenu de l'étiquette inclut les éléments d'information obligatoires suivants :

• DevEUI : identifiant unique du capteur (8 octets),

• JoinEUI : identifiant unique du Serveur Join LoRaWAN® où le capteur a été pré-commissionné (8 octets),

• ProfileID : identifiant du profil du capteur à être associé au capteur. ProfileID se compose d'un VendorID (attribué par la LoRa Alliance pour chaque fabricant de capteurs) + un VendorProfileID (attribué par le fabricant de capteurs, chaque VendorProfileID devrait être distinct pour des capteurs ayant des Profils de Capteur ou des encodages de payload différents).

L'étiquette peut également inclure le jeton de propriétaire comme élément optionnel. Cet élément est pertinent lorsque les capteurs sont pré-commissionnés sur un Serveur Join externe par le fabricant de capteurs. Il est ensuite utilisé par le propriétaire du capteur comme preuve de possession physique lors de l'étape de provisionnement dans TPE. Pour en savoir plus sur les jetons de propriétaire et le processus de pré-commissionnement, voir Intégration avec le service ThingPark Activation (TPA) RDTP-3381.

Pour obtenir des informations détaillées sur la spécification technique de la LoRa-Alliance, voir https://lora-alliance.org/resource_hub/tr005-lorawan-device-identification-qr-codes/.

Impact sur l'Interface Utilisateur de ThingPark Enterprise

La page de création de capteur est améliorée pour offrir aux utilisateurs le choix de créer un capteur en utilisant une étiquette d'embarquement ou manuellement (la création manuelle étant l'approche supportée dans les versions précédentes).

Pour créer un capteur en utilisant une étiquette d'embarquement, les utilisateurs peuvent soit :

• Utiliser un scanner de code QR physique connecté au PC/tablette de l'utilisateur.

• Cliquez sur le bouton de la caméra pour ouvrir le scanner de QR code de la caméra. Cette option est particulièrement pertinente pour les utilisateurs de tablettes.

• Copier/coller un QR code dans la barre de texte.

Lors du scan d'un code QR valide, le formulaire de création de capteur se remplit automatiquement avec toutes les données extraites de l'étiquette d'embarquement correspondante. Le modèle de capteur est automatiquement rempli s'il y a une correspondance un-à-un entre l'ID de Profil lu à partir du code QR et l'ID de Profil de Capteur disponible dans le catalogue ThingPark. Dans le cas où plusieurs profils correspondent à l'ID de Profil de l'étiquette d'embarquement, l'utilisateur doit sélectionner manuellement le bon modèle.

note

Dans la version 7.0, le capteur peut encore être créé manuellement en sélectionnant un fabricant de capteur, puis l'utilisateur est dirigé vers le formulaire de création de capteur régulier.

Lorsque l'utilisateur souhaite provisionner plusieurs capteurs à la chaîne en scannant leurs codes QR, la création en chaîne nécessite un nombre minimal de clics grâce à l'option "Create another" :

• Le nom du capteur est défini par défaut sur le DevEUI, mais l'utilisateur peut le modifier selon les besoins.

• Chaque fois que pertinent, les informations saisies lors de l'étape de création d'un capteur sont réutilisées comme paramètre par défaut (prérempli dans le formulaire de création) pour les capteurs suivants. Cela est valable pour le mode d'activation, la liste des Connexions associées au capteur, les informations supplémentaires, ainsi que son mode d'emplacement et sa position.

Impact sur l'import en masse de capteurs

Les étiquettes d'embarquement peuvent également être utilisées pour l'import en masse de capteurs OTAA. L'étiquette d'embarquement doit être fournie dans la colonne B (DevEUI), auquel cas les colonnes D, E, F et Y deviennent facultatives. Si l'une de ces colonnes facultatives est remplie dans le fichier d'import csv, sa valeur prend le pas sur les informations correspondantes incluses dans l'étiquette d'embarquement.

Avantages clés pour les clients

Cette fonctionnalité simplifie considérablement le processus d'embarquement des capteurs pour les utilisateurs de TPE en scannant des codes QR standard LoRaWAN au lieu de taper de longues chaînes hexadécimales.

De plus, grâce à cette fonctionnalité, le scan d'un code QR permet la correspondance automatique de chaque capteur avec son Profil de Capteur ThingPark.

Elle améliore également l'expérience utilisateur lors de la création de capteurs à la chaîne, via l'option "Create another".

Activation de la fonctionnalité

Cette fonctionnalité est disponible automatiquement dans la version 7.0.

Le scan du code QR peut être effectué via la caméra de l'utilisateur (essentiellement pertinent pour les utilisateurs de tablettes) ou via un scanner de code QR connecté au PC de l'utilisateur.

Seuls les tags d'onboarding standardisés LoRaWAN sont supportés par cette fonctionnalité. Les codes QR propriétaires ne sont pas interprétés par ThingPark Enterprise.

Limitations de la fonction

Aucune.

[UI/UX]: Marquage de capteurs et de passerelles RDTP-2274

À partir de la version 7.0, les utilisateurs de ThingPark Enterprise peuvent associer une ou plusieurs étiquettes à chaque capteur ou passerelle.

• Les étiquettes de capteurs sont reportées aux Serveurs d'Application.
• Les étiquettes de passerelles sont nécessaires pour configurer les groupes multicast.

Plus de détails

Les étiquettes sont sensibles à la casse et la longueur maximale des étiquettes est de 40 caractères. Les caractères autorisés sont [0-9][a-z][A-Z]@-_#&:\s.

L'interface utilisateur de TPE offre plusieurs façons d'étiqueter les capteurs ou les passerelles :

• Soit depuis la vue en liste, en sélectionnant les objets à étiqueter et en cliquant sur le bouton d'étiquetage :

  

  Dans la vue en liste, l'étiquetage unitaire de capteur ou de passerelle est également possible via l'action "tag" accessible par l'icône dans la dernière colonne de la liste.

• Ou depuis la vue cartographique, en étiquetant ou désétiquetant les objets affichés sur la carte. Cette option est pratique pour définir des étiquettes basées sur la géographie.

• Ou étiqueter individuellement un capteur ou une passerelle depuis le tableau de bord de l'objet détaillé :

  

Lorsque disponibles, les étiquettes sont affichées dans l'application Wireless Logger (dans le panneau extensible).

Principaux bénéfices pour les clients

Les étiquettes peuvent être très utiles pour répondre aux cas d'utilisation suivants :

• Définissez des tags administratifs pour simplifier la gestion de flotte de l'utilisateur, par exemple pour grouper facilement des objets et récupérer la liste des capteurs ou des passerelles via des options de filtrage par tags.

• Des étiquettes spécifiques sur les passerelles pour les faire contribuer à la transmission des paquets multicast downlink. Pour en savoir plus sur le multicast, voir Multicast downlink RDTP-9925.

• Mettre en œuvre un routage basé sur les étiquettes pour le trafic de capteur vers le Serveur d'Application, ainsi qu'un traitement dissocié des paquets de capteur uplink selon la fonction de mesure du capteur.

Activation de la fonctionnalité

Cette fonctionnalité est disponible automatiquement dans la version 7.0 de ThingPark Enterprise.

Limitations de la fonction

Aucune.

[UI/UX]: Capacités de filtrage et de tri améliorées RDTP-11832

La version 7.0 de TPE apporte plusieurs améliorations à la vue liste des capteurs et des passerelles :

• Les utilisateurs peuvent filtrer la liste des capteurs ou des passerelles selon un ou plusieurs critères :

  • Pour les capteurs : par nom ou identifiant (DevEUI ou DevAddr), par état de santé, par niveau de batterie connu le plus récent, par étiquettes associées ou par gravité minimale des alarmes actives - mais non acquittées).

    

  • Pour les passerelles : par nom ou identifiant (LRR-UUID ou LRR-ID), par état de santé, par version de logiciel LRR, par étiquettes associées, par RF region ou par gravité minimale des alarmes actives - mais non acquittées).

    

• Le nombre total d'objets (capteurs ou passerelles) dans la liste (filtrée) est affiché, même lorsque la liste est paginée.

• La taille de la page est configurable, ainsi que le numéro de page pour que les utilisateurs puissent naviguer librement entre les pages sans avoir à les parcourir une par une.

• De nouvelles colonnes sont maintenant disponibles (par exemple, date de création de l'objet, alarmes actives, étiquettes...). L'affichage par défaut montre les colonnes les plus pertinentes, mais les utilisateurs peuvent facilement choisir quelles colonnes afficher ou masquer.

• La liste peut être triée de manière ascendante ou descendante, par exemple par le nom de l'objet, la date de création, le dernier timestamp uplink ou downlink, le PER ou le SF du capteur...

• Possibilité d'exporter la liste complète (filtrée) au format csv, y compris les colonnes masquées dans l'interface graphique :

  

De plus, à partir de la version 7.0, les utilisateurs peuvent copier/coller le DevEUI/DevAddr ou LRR-ID avec des traits d'union entre l'interface utilisateur de TPE et Wireless Logger sans avoir à supprimer les traits d'union.

Plus de détails

Avantages clés pour les clients

Amélioration de l'expérience utilisateur en repérant facilement les capteurs ou passerelles défaillants grâce à des actions de filtrage et de tri pertinentes.

Activation de la fonction

Cette fonctionnalité est disponible automatiquement dans la version 7.0 de ThingPark Enterprise.

Limitations de la fonctionnalité

La taille d'exportation du fichier csv est limitée à un maximum de 50 000 objets (capteurs ou passerelles).

[UI/UX]: Vue cartographique des listes de capteurs et de passerelles RDTP-11831

En plus de la vue en liste tabulée des passerelles et des capteurs, ThingPark Enterprise 7.0 offre une vue cartographique pour afficher et rechercher des capteurs ou des passerelles sur une carte.

Plus de détails

De plus, les utilisateurs peuvent repérer une zone géographique et rechercher les capteurs ou les passerelles dans cette zone.

Le côté gauche de la carte affiche la liste paginée des capteurs ou des passerelles. Il affiche également un court résumé des capteurs ou passerelles individuels lorsque les utilisateurs cliquent sur cet objet spécifique.

La vue cartographique peut être affichée en mode plein écran.

Principaux bénéfices pour les clients

Grâce à cette fonctionnalité, les utilisateurs de ThingPark Enterprise peuvent facilement visualiser tous leurs capteurs ou leurs passerelles sur le même écran cartographique.

Elle améliore l'expérience utilisateur en offrant un moyen simple d'évaluer la densité de capteurs et de passerelles sur la carte et de définir de potentiels points de mauvaise couverture, par exemple en raison du manque de passerelles dans chaque zone.

Avec la vue cartographique, les utilisateurs ont un moyen facile d'étiqueter les capteurs ou les passerelles en fonction de leur emplacement géographique.

Activation de la fonction

Cette fonctionnalité est disponible automatiquement dans la version 7.0 de ThingPark Enterprise.

Cependant, elle ne peut être utilisée que si un service de carte valide a été configuré par l'administrateur de la plateforme. ThingPark Enterprise supporte les options de carte suivantes :

• Google maps
• Open Street Maps
• Baidu maps

Limites des fonctionnalités

Le regroupement des passerelles ou des capteurs sur la carte - lorsque le nombre d'objets à afficher est trop important - est uniquement disponible à partir de la version 7.1 de ThingPark Enterprise.

[UI/UX]: Représentation améliorée de l'état de connexion RDTP-12952

Avant la version 7.0, le statut coloré associé à chaque Application (rebaptisé Connexion dans TPE 7.0) dans la liste affichait uniquement l'état d'activation de chaque connexion : vert lorsque la connexion est activée, orange lorsqu'elle est désactivée.

À partir de la version 7.0, la puce colorée affichée à côté du logo de chaque Application/Connexion dans la liste montre l'état de santé actuel de la Connexion, combinant l'état d'activation avec l'état de déploiement (pertinent pour le type de connexions IoT Flow TPX).

Plus de détails

• ACTIF : la Connexion est active, tout est en ordre
• INIT : état transitoire
• ERREUR : état anormal
• DÉSACTIVÉ : la Connexion est désactivée par l'utilisateur

Pour le type de connexions TPX, un survol de la souris fournit à l'utilisateur une info-bulle sur l'état actuel de la connexion IoT Flow.

note

Si la Connexion a été suspendue par le système en raison de l'expiration de la licence TPE, elle apparaît avec le statut "DÉSACTIVÉ" dans l'UI. Pour en savoir plus sur la suspension des Connexions en raison de l'expiration de la licence, voir Améliorations de la gestion des licences RDTP-12789.

De plus, l'état de santé de chaque Connexion est affiché dans les détails de la Connexion :

Principaux avantages pour le client

Cette amélioration offre aux utilisateurs de ThingPark Enterprise une représentation plus complète de l'état de santé réel de chaque Connexion, au lieu de ne référencer que son état d'activation.

Activation de la fonctionnalité

Cette amélioration est directement disponible une fois que la plateforme ThingPark Enterprise est mise à niveau vers la version 7.0 ou supérieure.

Limitations de la fonction

Aucune.

[UI/UX] Présentation améliorée des différents types de connexions d'application RDTP-16525

À partir de la version 7.0, les connexions vers les Serveurs d'Applications externes (AS) sont présentées en 3 catégories :

• Connexions ThingPark X IoT Flow, tirant parti d'un riche ensemble de connecteurs cloud ainsi que de connecteurs généraux MQTT et HTTPS. TPX IoT Flow intègre également un moteur de driver pour fournir des payloads uplink décodés/prêts à l'emploi à l'AS.

• Connexions HTTPS de base, utilisant l'interface tunnel LRC-AS. Il s'agit du type hérité de connexions en mode direct entre le network server et l'AS, contrairement à la connexion HTTPS fournie par ThingPark X IoT Flow. Les payloads sont échangés avec l'AS au format brut/codé, contrairement aux capacités de décodage de payloads offertes par TPX IoT Flow.

• Connexion Node-RED, uniquement pertinente pour TPE auto-hébergé. Elle peut être utilisée comme une alternative à TPX IoT Flow pour les déploiements limités en ressources avec des ressources CPU/RAM limitées.

Plus de détails

De plus, dans TPE 7.0, "Applications" sont renommées "Connexions" pour davantage de cohérence entre les interfaces utilisateur TPE et TPX.

note

Toutes les connexions d'application existantes AWS, Azure, IBM, MQTT et ThingWorx sont maintenant affichées comme des connexions TPX avec le logo TPX.

Principaux avantages pour le client

Les options de connexion ThingPark X IoT Flow sont mieux présentées dans cette version, harmonisant l'expérience utilisateur pour les connexions AWS, Azure, MQTT, Watson et ThingWorx créées par les utilisateurs avant la version 6.1.5 de TPE.

Activation de la fonctionnalité

Cette amélioration est automatiquement disponible dans la version 7.0 de ThingPark Enterprise.

Limites des fonctionnalités

Aucune.

Améliorations de la gestion des licences RDTP-12789

La portée de cette fonctionnalité est de mettre à jour le cadre de licences de TPE SaaS pour l'aligner avec le TPE auto-hébergé.

À partir de la version 7.0, la licence d'abonnement TPE SaaS repose sur un fichier de licence automatiquement téléchargé par Actility Central sur la plate-forme TPE SaaS, une fois que le partenaire crée l'abonnement/transaction dans Actility Central.

Ainsi, chaque abonnement TPE SaaS est désormais associé à une date d'expiration de la licence, comme TPE auto-hébergé.

Plus de détails

Pour les deux TPE SaaS et TPE auto-hébergés, une fois que la licence a expiré, l'IUG de l'administration TPE et DX-API passent en mode lecture seule, c'est-à-dire que ni des nouveaux capteurs/capteurs de base/connexions ne peuvent être ajoutés ni des objets existants mis à jour.

À la fin de la période de grâce (actuellement fixée à 6 mois) suivant l'expiration de la licence, le trafic vers les serveurs d'application externes est stoppé, c'est-à-dire que les paquets uplink ne sont plus transmis à AS et les paquets downlink ne sont plus acceptés de AS.

Des messages d'avertissement sont affichés dans l'IUG TPE pour alerter l'utilisateur sur l'expiration de la licence. Par défaut, le premier avertissement s'affiche dans l'IUG 30 jours avant la date d'expiration de la licence.

De plus, à partir de TPE 7.0, le nombre de capteurs et/ou de passerelles accordés peut être "illimité", ceci est entièrement contrôlé par le fichier de licence généré par Actility Central lors de la création/mise à jour/renouvellement de l'abonnement.

Principaux avantages pour les clients

Cette fonctionnalité offre plusieurs améliorations :

• Automatisation de la création/mise à jour de l'abonnement TPE SaaS via Actility Central, supprimant les actions manuelles exécutées par l'équipe opérationnelle d'Actility pour créer/configurer manuellement chaque abonnement TPE SaaS via le Gestionnaire des capteurs et les interfaces en ligne de commande.

• Notification de l'utilisateur dans l'IUG TPE concernant l'expiration de la licence, via des messages d'avertissement.

• Modèle de licence cohérent, offrant des mécanismes de compréhension pour encourager les clients finaux à renouveler leurs abonnements : Les abonnements expirés n'exercent pas les paquets vers/depuis les serveurs d'applications après la fin de la période de grâce.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement activée dans le TPE auto-hébergé, à partir de la version 7.0.

Pour TPE SaaS, les actions suivantes doivent être menées par l'équipe opérationnelle d'Actility, lors de la mise à niveau de chaque plate-forme SaaS vers la version 7.0 :

1. Assurez-vous que les nouveaux plans de connectivité et les options d'application nécessaires dans la version 7.0 ont déjà été créés ; sinon, ils doivent être créés manuellement. Plus de détails sur cette tâche sont inclus dans le document interne "ref-tpw7.1-tpe-offer-data-modeling".

2. Mettre à jour les fournisseurs TPE existants, en ajoutant les nouvelles offres TPE SaaS. Pour effectuer cette tâche, l'équipe Actility doit utiliser le "script de mise à jour des fournisseurs" tel que décrit dans cette technote interne.

3. Mettre à jour la version TPE SaaS à "7.0" dans Actility Central et utiliser l'API Centrale pour générer et télécharger les fichiers de licence des abonnements TPE SaaS existants liés à cette plate-forme SaaS spécifique.

4. Migrer les abonnements TPE SaaS existants vers le nouveau mode de licence, via le script de migration fourni dans cette technote interne.

Important

À la fin de cette étape de migration :

• Les abonnements TPE SaaS ayant expiré depuis moins de 6 mois seront automatiquement passés en mode lecture seule, jusqu'à ce que leur licence soit renouvelée dans Actility Central.

• Tous les abonnements TPE SaaS ayant déjà expiré depuis plus de 6 mois devront automatiquement être basculés en mode lecture seule et arrêter d'échanger des paquets uplink/downlink avec les serveurs d'applications jusqu'à ce que leur licence soit renouvelée dans Actility Central.

Limitations de la fonction

Aucune.

Afficher les indicateurs de backhaul cellulaire (3G/4G) et WiFi (RDTP-2420 et RDTP-12898)

Cette fonctionnalité fournit aux administrateurs ThingPark Base Station des informations spécifiques liées aux types de backhaul cellulaire (3G ou 4G) et WiFi entre la passerelle et le network server cœur (également connu sous le nom de LRC).

Plus de détails

Cette information est rapportée par le LRR de la passerelle et affichée par l'interface utilisateur TPE dans le widget "Réseaux" sous chaque passerelle.

• Pour le backhaul cellulaire, l'IUG fournit les informations suivantes par rapport aux versions précédentes :

  • Nom de l'opérateur Cellulaire et technologie de réseau ("3G" ou "4G")

  • Puissance du signal reçu :

    • Si la technologie de réseau est "3G", elle se réfère au RSCP (Reference Signal Code Power), cliquez sur ici pour obtenir une définition détaillée.

    • Si la technologie de réseau est "4G", elle se réfère au RSRP (Reference Signal Received Power), cliquez sur ici pour obtenir une définition détaillée.

      La force du signal cellulaire est représentée par des barres RSCP/RSRP, la couleur dépend de la dernière valeur moyenne rapportée par la passerelle (moyenne calculée sur 10 échantillons de mesure) :

	3G	4G
5 barres vertes	RSCP ≥ -60 dBm	RSRP ≥ -80 dBm
4 barres vertes	-60 > RSCP ≥ -75	-80 > RSRP ≥ -90
3 barres oranges	-75 > RSCP ≥ -85	-90 > RSRP ≥ -100
2 barres oranges	-85 > RSCP ≥ -95	-100 > RSRP ≥ -110
1 barre rouge	-95 > RSCP ≥ -120	-110 > RSRP ≥ -120
0 barre	RSCP < -120 dBm	RSRP < -120 dBm

• Pour le backhaul WiFi, l'IUG fournit les informations suivantes (non supportées dans les versions précédentes) :

  • Adresse IP

  • Trafic total : volume cumulé de données transmises et reçues par cette interface

  • Latence aller-retour : temps moyen de ping aller-retour pour cette interface.

  • Réseau : SSID WiFi + force du signal Wi-Fi, représentée par des barres de l'indicateur de force du signal reçu (RSSI), la couleur dépend de la dernière valeur moyenne RSSI rapportée par la passerelle (moyenne calculée sur 10 échantillons de mesure) :

    • 4 barres vertes : RSSI ≥ -50 dBm

    • 3 barres vertes : -50 dBm > RSSI ≥ -60 dBm

    • 2 barres oranges : -60 dBm > RSSI ≥ -70 dBm

    • 1 barre orange : -70 dBm > RSSI ≥ -80 dBm

    • Aucune barre : RSSI < -80 dBm

Les indicateurs cellulaires supplémentaires seront supportés par l'IUG TPE dans la version 7.1 : IMEI, IMSI, ICCID, RSSI, Ec/Io (réseau 3G) ainsi que RSSI, RSRQ et SINR (réseau 4G).

La définition de l'état de l'interface cellulaire est également améliorée par cette fonctionnalité :

• Up and Used: L'interface cellulaire est opérationnelle et utilisée activement pour connecter la passerelle avec le réseau central.

• Prêt/En secours : l'interface cellulaire est prête à être utilisée comme interface secondaire (de secours) en cas de défaillance de l'interface principale.

• Service interrompu : Le modem cellulaire est activé mais le réseau est inactif.

• Aucune IP : Le modem cellulaire ne peut obtenir une adresse IP valide du réseau mobile.

• Inscription échouée : Le modem cellulaire n'a pas réussi à s'attacher/s'inscrire au réseau mobile.

• Désactivé : Le modem cellulaire est actuellement désactivé (non démarré).

note

La définition de l'état de l'interface ethernet a également été améliorée dans la version 7.0, pour plus de cohérence avec les autres types d'interfaces : les mêmes définitions s'appliquent à l'interface ethernet, à l'exception de "Inscription échouée" qui est remplacé par "Lien inactif".

Les états de l'interface Wi-Fi sont définis comme suit :

• Up and Used: L'interface Wi-Fi est opérationnelle et utilisée activement pour connecter la passerelle avec le réseau central.

• Prêt/En secours : l'interface Wi-Fi est prête à être utilisée comme interface secondaire (de secours) en cas de défaillance de l'interface principale.

• Service interrompu : Le modem Wi-Fi est activé mais le réseau est inactif.

• Aucune IP : Le modem Wi-Fi ne peut obtenir une adresse IP valide du point d'accès.

• Pas de signal : Le modem Wi-Fi ne peut pas scanner un SSID valide ou il n'y a pas de signal RF valide.

• Désactivé : Le modem Wi-Fi est actuellement désactivé (non démarré).

Principaux avantages pour les clients

Grâce à cette fonctionnalité, les administrateurs de réseau ThingPark peuvent facilement surveiller la connectivité backhaul sur les modems cellulaires 3G/4G ou WiFi et prendre les actions correctives appropriées en cas de problème de qualité (par exemple, réception de signal RF trop faible, problème d'enregistrement réseau, problèmes d'authentification, etc.).

Activation de la fonctionnalité

Cette fonctionnalité est activée par défaut pour toute passerelle prenant en charge une connectivité backhaul cellulaire et/ou WiFi et en la configurant soit comme interface réseau primaire soit comme interface réseau secondaire. Pour la liaison fibre optique cellulaire, la passerelle doit être équipée d'une carte SIM 3G/4G valide.

note

Cette fonctionnalité nécessite la version 2.8.11 ou supérieure du LRR.

Limites des fonctionnalités

Aucune.

[Connexions HTTPS de base] : Statut de transmission des paquets uplink vers AS RDTP-13837

La portée de cette nouvelle fonctionnalité est d'afficher dans l'IUG TPE et le Wireless Logger le statut de transmission des rapports envoyés par le Network server LRC aux serveurs d'application tiers (AS) via l'interface tunnel HTTPS.

Plus de détails

Un rapport peut ne pas être envoyé avec succès à un AS pour deux raisons :

• La livraison à une destination AS a échoué : par exemple, en raison d'une erreur HTTP, d'une erreur réseau, d'une erreur DNS, etc.

• La transmission du rapport est abandonnée par le LRC parce que l'AS est soit en état "Surcharge" soit "Liste noire". Les profils de routage peuvent tomber dans cet état lorsqu'ils ont consommé trop de gestionnaires. Un gestionnaire est requis pour transmettre un rapport à la destination AS. Étant donné que les gestionnaires sont une ressource limitée, le LRC met en œuvre un mécanisme de protection contre les destinations AS non réactives/très lentes qui consomment trop de gestionnaires.

Avant la version 7.0, lorsqu'un rapport échoue à être envoyé à un AS, aucune information n'est rapportée à l'utilisateur.

À partir de la version 7.0, l'utilisateur peut voir le statut de transmission dans l'IUG TPE ainsi que dans l'application Wireless Logger. Ce statut est disponible pour tous les rapports envoyés par le LRC aux AS tiers via l'interface tunnel HTTPS :

• Rapports de trame uplink (DevEUI_uplink)

• Rapports de trame downlink envoyés (DevEUI_downlink_Sent)

• Rapports de résumé multicast (DevEUI_multicast_summary)

• Rapports de localisation des capteurs (DevEUI_location)

• Rapports de notification des capteurs (DevEUI_notification)

Pour en savoir plus sur ces rapports, consultez le Guide du développeur d'interface Tunnel LRC-AS.

Statut de livraison dans l'IUG ThingPark Enterprise

Sur le tableau de bord des connexions, dans le widget "25 derniers paquets", une nouvelle colonne "Livraison à l'application" est ajoutée pour afficher le statut de transmission des rapports uplink envoyés aux serveurs d'application.

note

Cette colonne est disponible uniquement pour les types de connexions HTTPS de base.

Statut de livraison dans l'application WLogger

Cette fonctionnalité apporte les changements suivants à l'affichage des paquets dans WLogger :

• L'icône de l'uplink est améliorée pour afficher l'erreur de livraison AS. Si un rapport échoue à être livré à un AS, l'icône × est affichée à la place de . Pour l'itinérance uplink passive, ×PR est affiché.

• Pour tous les types de paquets/rapports, le panneau d'expansion est enrichi d'un nouveau tableau : Le statut de livraison et les erreurs de transmission à toutes les destinations AS ciblées est affiché, selon l'exemple illustratif suivant.

  • Un statut de transmission global est affiché en parallèle au statut de chaque destination AS individuelle (URL).

  • Chaque fois que cela est pertinent pour une destination AS donnée (URL), un message d'erreur est fourni à des fins de débuggage : En cas d'erreur HTTP par exemple, le message serait "Code d'erreur Erreur HTTP". Si l'erreur n'est pas causée par le serveur d'application, le message serait "Erreur interne du réseau server".

    

Principaux avantages pour les clients

Cette fonctionnalité fournit aux utilisateurs de ThingPark Enterprise des informations en temps réel sur le statut de livraison des rapports réseau vers les serveurs d'application tiers. Cette information est très utile pour débugger les problèmes de livraison à AS et prendre les actions correctives appropriées par les développeurs AS en cas de comportement AS trop lent / occasionnellement en liste noire.

Activation de la fonctionnalité

Cette fonctionnalité est activée automatiquement lors de la mise à niveau du système vers la version 7.0.

Limites des fonctionnalités

La portée de cette fonctionnalité est limitée aux serveurs d'application utilisant le protocole HTTPS de base sur l'interface tunnel LRC-AS. Elle ne couvre pas les connecteurs TPX (Azure, AWS, MQTT générique, HTTPS...) offert par ThingPark X IoT Flow.

Accès rapide au marché ThingPark depuis l'IUG TPE RDTP-7922

Un nouveau bouton "Marketplace" est ajouté dans la bannière supérieure, à côté de l'espace de recherche :

Il permet aux utilisateurs de naviguer vers le ThingPark Marketplace pour acheter des objets IoT.

Plus de détails

Principaux avantages pour les clients

Expérience utilisateur améliorée pour naviguer directement vers ThingPark Market lorsque les utilisateurs souhaitent acheter des objets IoT, allant des accessoires aux capteurs ou passerelles jusqu'aux kits de solutions complètes.

À travers ThingPark Market, les utilisateurs peuvent facilement consulter les offres disponibles pour chaque secteur vertical IoT :

Activation de la fonctionnalité

Cette fonctionnalité est activée par défaut dans la version 7.0.

Elle peut être désactivée par le partenaire ThingPark Enterprise :

• Pour le TPE auto-hébergé : l'URL du Marketplace est configurable dans le Tableau de bord TPE, sous le panneau de configuration TPE > Configuration du service ThingPark > Paramètres de proxy.

  

• Pour TPE SaaS : chaque partenaire ayant un rôle de fournisseur peut activer ou d�ésactiver l'affichage de l'URL du marketplace pour les abonnements TPE sous-jacents.

  

Limitations de la fonctionnalité

Aucune.

Support LoRaWAN® 1.0.4 RDTP-14248

À partir de la release 7.0, LoRaWAN® 1.0.4 est officiellement supporté par ThingPark. Vous pouvez télécharger la spécification LoRaWAN® 1.0.4 sur le site de la LoRa Alliance.

Plus de détails

Les principales modifications liées à LoRaWAN® 1.0.4 sont :

• Modifications ADR :

  • Une nouvelle valeur (0xF, décimal 15) a été introduite dans les champs TXPower et DataRate pour représenter un paramètre "peu importe". Ainsi, si le capteur désactive le bit ADR dans l'entête de trame uplink (ADR-bit = 0), même si le réseau peut toujours envoyer des commandes LinkADRReq pour mettre à jour le masque des canaux, il utilise la valeur 0xF pour TXPower et DataRate pour permettre au capteur de conserver ses paramètres actuels pour ces champs.

  • Une nouvelle définition du bit ADR des trames DL : Quand le capteur remarque que le réseau a désactivé le bit ADR dans les trames DL, il comprend que le réseau est incapable de contrôler son ADR uplink. Ainsi, le capteur peut désactiver l'ADR contrôlé par le réseau en mettant ADR-bit = 0 dans les trames UL.

    Ainsi, à partir de la version 7.0, le network server définit le bit ADR des downlinks à 1 par défaut, sauf si la commande LinkADRReq n'est pas activée dans le profil de capteur.

Avantages clés pour le client

Cette fonctionnalité permet aux utilisateurs de ThingPark d'intégrer les capteurs les plus récents dans leurs réseaux, en tirant parti de la dernière version LoRaWAN® 1.0.4 émise par la LoRa Alliance.

LoRaWAN® 1.0.4 contient un ensemble de clarifications et d'améliorations de sécurité à la couche MAC comme :

• Interdiction de la réinitialisation du compteur de trames pour les capteurs ABP

• Renforcement de la sécurité pendant la procédure Join des capteurs OTA, grâce à l'application stricte des DevNonce/JoinNonce basés sur des compteurs

• Diverses clarifications sur le comportement des capteurs pour éviter les imperfections d'implémentation.

Activation de la fonctionnalité

Cette fonctionnalité est disponible une fois la plateforme mise à jour vers la version 7.0.

Pour provisionner des capteurs LoRaWAN® 1.0.4 dans ThingPark, l'abonné doit les associer à un profil prenant en charge LoRaWAN® 1.0.4.

note

Le catalogue de profils de capteur d'Actility a été enrichi de nouveaux profils de capteur génériques associés à LoRaWAN® 1.0.4.

Limites des fonctionnalités

LoRaWAN® 1.0.4 a apporté quelques changements de terminologie par rapport aux versions précédentes de LoRaWAN® :

• MType est renommé Ftype

• Dans le payload de DevStatusAns, le champ Margin est renommé RadioStatus

• [Classe C] : la fenêtre RX2 étendue est renommée RXC.

Certains de ces champs sont affichés dans l'application Wireless Logger mais la terminologie pré-1.0.4 s'applique toujours dans la version 7.0.

Support des interfaces backend LoRaWAN® 1.1 RDTP-11369

La spécification LoRaWAN® backend interfaces définit une interface standard pour échanger des messages entre Network Servers, afin de supporter l'itinérance entre réseaux d'origine et réseaux visités. Il définit également une interface de plan de données standard entre les network servers et les join servers, pour supporter le flux d'activation des capteurs OTA.

Dans la release 7.0, les Network Servers et Join Servers ThingPark prennent en charge la dernière spécification officielle LoRaWAN® backend interfaces v1.1 en plus de la v1.0 initialement supportée par les releases précédentes.

Plus de détails

Vous pouvez télécharger la dernière spécification des interfaces backend LoRaWAN® v1.1.0 sur le site de la LoRa Alliance.

Voici quelques changements apportés par Backend Interfaces v1.1 par rapport à v1.0 (liste non exhaustive) :

• Support de la géolocalisation réseau pour les capteurs en itinérance (pour en savoir plus, voir Geolocation in passive roaming RDTP-5820).

• Codes de résultat supplémentaires sur les interfaces NS-NS et NS-JS, par exemple pour indiquer des situations de rejeu de trames...

• Gestion améliorée de la duplication des trames uplink sur le NS desservant, via le drapeau explicite "DupUL".

• Support d'une identification alternative des NS par "NSID", en plus du NetID.

• Ajout d'un message PRStartNotif (pour signaler l'état de transmission de JoinAccept' au NS desservant/d'origine) et d'un message ErrorNotif` (notification d'erreur de messages de réponse invalides).

• Clarification de RFRegion et nouveau RFParamSetID (utile pour supporter plusieurs RF Regions par forwarding NS, différenciées par leur ID).

• Rapport du NS desservant sur l'identifiant unique du capteur (DevEUI) à NS de transfert dans le PRStartAns (en cas de réussite).

Les versions v1.0 et v1.1 de la spécification LoRaWAN® Backend Interfaces restent supportées à partir de la release 7.0, ce qui garantit la compatibilité descendante avec les fournisseurs NS/JS tiers qui n'ont pas encore adopté la v1.1.

Principaux avantages pour les clients

Grâce au support de LoRaWAN® Backend Interfaces v1.1, ThingPark supporte des cas d'utilisation d'itinérance/activation supplémentaires à partir de la release 7.0 :

• Itinérance pour les réseaux utilisant un NetID partagé (avec NetID > 1); dans ce cas, le routage des messages d'itinérance vers/depuis ces réseaux devient basé sur NSID (identifiant NS unique par plateforme ThingPark cœur de réseau) plutôt que sur le NetID partagé.

• Itinérance en entrée pour les réseaux utilisant un NetID privé (0 ou 1), ce qui signifie qu'un réseau LoRaWAN® utilisant NetID 0 ou 1 peut toujours transférer des trames UL de capteurs étrangers vers leur réseau d'origine si ce dernier a un NetID dédié > 1.

• Activation des capteurs OTA sur les Join Servers externes, lorsque le réseau d'origine utilise NetID 0, 1 ou un autre NetID partagé.

De plus, cette nouvelle fonctionnalité permet de mettre en œuvre des politiques de facturation basées sur les capteurs, car fNS connaît le DevEUI de chaque capteur en visite.

Activation de la fonctionnalité

L'utilisation de la v1.1 du protocole Backend Interface exige que les deux parties, émettrice et réceptrice, prennent en charge cette version. Si au moins une des parties ne supporte pas la v1.1, le protocole de communication devra utiliser la v1.0. ThingPark Exchange (TEX) propage la version du protocole de chaque pair NS/JS au Network Server d'origine.

De plus, pour activer l'utilisation de la v1.1, chaque LRC Network Server devrait être associé à un NSID unique, assigné par l'équipe Actility NetOps.

• Pour TPE SaaS : NSID est directement configuré par l'équipe NetOps d'Actility, en même temps que la version du protocole backend, dans le tableau Operateur de LRC (table O).

• Pour TPE auto-hébergé : NSID est configuré par l'administrateur ThingPark Enterprise ou l'intégrateur système, sous Configuration TPE > Configuration LoRa > Configuration TEX.

Limites des fonctionnalités

Aucune.

Géolocalisation en itinérance passive RDTP-5820

La spécification LoRaWAN® Backend Interface v1.1 a introduit le support du cas d'utilisation de géolocalisation réseau pour les capteurs en itinérance, via l'amendement des métadonnées uplink envoyées par les forwarding network servers (fNS) avec des informations spécifiques à la géolocalisation. Pour en savoir plus sur l'Interface Backend LoRaWAN® v1.1, voir TS002-1.1.0 Interfaces Backend LoRaWAN®.

Les métadonnées uplink spécifiques à la géolocalisation incluent l'AntennaID, le Fine timestamp (un timestamp haute résolution avec précision nanoseconde) et l'altitude de la passerelle en plus d'autres informations de la passerelle telles que sa longitude/latitude.

Plus de détails

Principaux avantages pour le client

Cette fonctionnalité étend les cas d'utilisation supportés en mode passive roaming, en permettant au serving NS (sNS) de tirer parti de la RF macro diversity (c'est-à-dire la capacité de recevoir la même trame uplink LoRaWAN® via plusieurs gateways) offerte par les fNS dans leur offre de géolocalisation réseau.

• En cas de superposition/couverture complémentaire entre les propres passerelles du réseau d'origine et celles des partenaires en itinérance : grâce à cette fonctionnalité, sNS peut s'appuyer sur la couverture combinée des passerelles d'origine + étrangères pour améliorer la précision de la résolution de position sans déployer de nouvelles passerelles.

• S'il n'y a pas de chevauchement de couverture entre sNS et fNS : cette fonctionnalité permet aux administrateurs réseau de sNS de continuer à offrir des services de géolocalisation réseau même lorsque leurs capteurs s'égarent loin du réseau d'origine, garantissant la continuité du service à valeur ajoutée pour ces capteurs en itinérance.

Activation de la fonctionnalité

Pour utiliser cette fonctionnalité, les forwarding network servers (fNS) et serving network servers (sNS) doivent être configurés pour utiliser les interfaces backend LoRaWAN® v1.1 (pour en savoir plus, voir Support des interfaces backend LoRaWAN® 1.1 RDTP-11369.

De plus, les fonctionnalités d'itinérance et de géolocalisation réseau doivent être activées pour les capteurs en question.

Limites des fonctionnalités

Dans la version actuelle, la résolution de l'emplacement du capteur est effectuée par le réseau d'origine du capteur (sNS, Network Server de service). L'autre mode défini par la spécification LoRaWAN® (permettant au forwarding NS de calculer directement la résolution de localisation et de l'envoyer au sNS) n'est pas supporté dans cette release de ThingPark.

[UI/UX] : Importation simplifiée des capteurs en masse RDTP-8481

Lors de la création de capteurs par importation en masse dans l'interface TPE GUI, l'ID du modèle de capteur de chaque capteur créé doit être spécifié dans le fichier CSV.

• Avant la version 7.0, les utilisateurs peuvent trouver l'information de l'ID du modèle en recherchant le modèle dans l'interface GUI (sous la page de création de capteur ou dans le dashboard de gestion des capteurs), l'ID du modèle est affiché dans le menu déroulant du modèle de capteur.

• Avec cette amélioration de la version 7.0, l'utilisateur de TPE peut télécharger un fichier CSV contenant la liste des ID de modèles de capteurs depuis l'interface GUI. Le fichier est appelé "Liste des Modèles" :

  

  -> Seuls les modèles de capteur compatibles avec les bandes ISM configurées sont présents dans cette liste.

Plus de détails

Principaux avantages pour le client

Expérience utilisateur améliorée pour l'importation en masse de capteurs.

Activation de la fonctionnalité

Non applicable.

Limites des fonctionnalités

Aucune.

[UI/UX] : Expérience améliorée de connexion/authentification (RDTP-6894 et RDTP-10501)

À partir de la version TPE 7.0, le portail GUI de TPE et l'interface GUI de Wireless Logger utilisent des flux d'authentification Open ID Connect, basés sur le protocole OAuth2.

Plus de détails

Principaux avantages pour le client

Expérience utilisateur améliorée pour la connexion/déconnexion et la gestion des sessions.

Activation de la fonctionnalité

Cette amélioration est automatiquement disponible après la mise à niveau vers la version 7.0.

Limites des fonctionnalités

Aucune.