Nouvelles fonctionnalités

Cette page cumule toutes les nouvelles fonctionnalités de ThingPark Enterprise apportées par les différentes versions logicielles 7.3.x. Voir le changelog 7.3 pour en savoir plus sur la répartition de ces fonctionnalités par version de maintenance.

Les fonctionnalités décrites sur cette page sont communes aux produits SaaS et TPE auto-hébergé.

Relais LoRaWAN (PoC) RDTP-18706 RDTP-20376

Un relais LoRaWAN est un capteur qui relaie vers le réseau les trames uplink LoRaWAN reçues de capteurs de confiance, en les encapsulant dans les Payload de ses propres trames. De même, le relais reçoit des trames downlink encapsulées du réseau et les transmet aux capteurs finaux appropriés après décapsulation.

Les relais LoRaWAN ont une architecture similaire à celle des capteurs LoRaWAN conventionnels, avec en plus le support du protocole Relay spécifié par la LoRa Alliance dans TS011.

Les principales caractéristiques d’un relais sont :

• Alimenté par batterie
• Un relais peut sécuriser jusqu'à 16 capteurs finaux.
• Comme tout capteur conventionnel, un relais peut utiliser n’importe quelle classe LoRaWAN (classe A, B, C) et peut utiliser soit des modes d'activation OTAA ou ABP.

prudence

Pour que les capteurs fonctionnent en mode relais, ils doivent supporter le protocole Relay spécifié par TS011 dans leur pile MAC, en plus du protocole LoRaWAN standard.

Pour en savoir plus sur cette fonctionnalité, voir Utiliser les relais LoRaWAN.

Plus de détails

Grâce à RDTP-20376, le contenu des données spécifiques au relais est affiché au format décodé dans le Wireless Logger. Cela s’applique à :

• Les commandes MAC UpdateUplinkListReq/Ans (échangées entre le network server et le relais pour ajouter un nouveau capteur final à la liste de confiance).
• Les commandes ForwardUplinkReq (encapsulant des paquets uplink des capteurs) et ForwardDownlinkReq (encapsulant des paquets downlink vers les capteurs). Ces paquets sont toujours envoyés sur Fport 226 (port spécifique au relais).

Principaux avantages pour les clients

Les relais LoRaWAN permettent de couvrir les zones blanches à moindre coût, réduisant le CAPEX global de l'infrastructure. Ils offrent une solution fiable (et à faible coût) pour couvrir des capteurs difficiles à atteindre (par exemple situés profondément à l'intérieur ou dans des sous-sols), en particulier pour les cas d'utilisation de télémesure intelligente ; éliminant la nécessité de faire des opérations de récupération coûteuses pour collecter les relevés de compteurs dans les zones blanches.

De plus, d’un point de vue opérationnel, les relais sont particulièrement utiles dans les zones où il n’est pas possible/pratique d’ajouter des pico ou nano passerelles, par exemple en raison de l’absence d'alimentation électrique ou d’installations de retour. En effet, contrairement aux passerelles conventionnelles, les relais sont alimentés par batterie et utilisent l'interface radio de LoRaWAN comme solution de retour.

Activation de la fonctionnalité

Dans la version actuelle, un relais est provisionné dans ThingPark comme un capteur normal, suivant le processus de provisionnement conventionnel décrit dans le guide de l'utilisateur.

note

Dans ThingPark 7.3, aucune configuration spéciale n'est requise pour permettre à un capteur provisionné d'agir en tant que relais.

Limitations de la fonctionnalité

The PoC implementation has the following limitations that are progressively lifted by subsequent features:

• Les capteurs opérant derrière un relais doivent utiliser les modes classe A + OTAA (Activation Over-the-Air).
• Parmi les commandes MAC propres aux relais définies dans la spécification technique LoRaWAN TS011, seules les paires UpdateUplinkListReq/Ans, NotifyNewEndDeviceReq/Ans et CtrlUplinkListReq/Ans sont actuellement supportées. D'autres commandes MAC seront progressivement supportées dans les prochaines versions de ThingPark.
• Étant donné que la paire de commandes MAC RelayConfReq/Ans n'est pas encore supportée, le mode relais doit être activé localement dans les capteurs agissant comme relais.
• Seul le canal WOR par défaut est supporté, car les commandes MAC nécessaires pour configurer un second canal WOR ne sont pas encore supportées dans cette version.

Indication explicite des paquets UL/DL servis via des relais LoRaWAN RDTP-21151

Les paquets uplink et downlink échangés entre les capteurs et le réseau via un relais LoRaWAN sont affichés avec un symbole F spécifique (F signifie « Forwarded »).

Plus de détails

Exemples : pour les paquets uplink et pour les paquets downlink transmis par un relais.

De plus, l'identifiant du relais (DevEUI du relais) est affiché explicitement dans une nouvelle colonne "Meilleur Relais" dans l'interface utilisateur de ThingPark Enterprise (dans le widget "10 derniers paquets" de la page détail du capteur) ainsi que dans l'application Wireless Logger (via la colonne "ID du Relais").

Avantages clés pour les clients

Meilleure expérience utilisateur, permettant une analyse plus rapide du comportement des capteurs en mode relais.

Activation de la fonctionnalité

Cette fonctionnalité est disponible automatiquement à partir de ThingPark Enterprise 7.3.3.

Limitations de la fonctionnalité

Non applicable.

Cas d'utilisation supplémentaires pour les relais LoRaWAN RDTP-22004 RDTP-21297

Pour répondre aux situations de déploiement réelles, les cas d'utilisation suivants sont désormais supportés pour les relais LoRaWAN :

• Des capteurs OTAA rejoignant le réseau sous la couverture de plusieurs relais. Dans ce cas, le relais le plus proche du capteur final (désigné best-serving relay) est sélectionné par le network server. Notez qu'un capteur final ne peut pas être desservi simultanément par plusieurs relais afin d'éviter des collisions d'ACK WOR.
• Des capteurs OTAA desservis en mode de couverture hybride, avec un mélange de couverture directe (via des passerelles conventionnelles) et via relais. Dans ce cas, les paquets uplink reçus par les passerelles conventionnelles et par le best-serving relay sont dédupliqués par le network server ; tandis que les paquets downlink peuvent être envoyés au capteur final via les deux : la best-serving gateway (sur la fenêtre RX1 ou RX2 du capteur) et la best-serving relay (sur la fenêtre RXR).
• Permettre aux capteurs d'être servis en mode relais sans initier un nouveau cycle de join. Exemple de cas d'utilisation :
  • Un nouveau relais est installé à proximité d'un capteur existant pour améliorer sa couverture RF.
  • Un capteur final mobile entre dans la zone de couverture du relais.
  • Remplacement de relais, par exemple en raison d'une panne matérielle. Les cas d'utilisation décrits ci-dessus exploitent le mode de découverte automatique supporté par le protocole de relais LoRaWAN, par lequel le relais notifie le network server de la présence d'un nouveau capteur via la commande MAC NotifyNewEndDeviceReq.

Plus de détails

Principaux avantages pour les clients

Grâce aux nouvelles fonctionnalités, il est désormais possible d'exploiter un capteur final sous une couverture mixte de passerelles conventionnelles et de relais. En cas de telle couverture superposée, le taux de réussite de livraison des paquets downlink est amélioré en exploitant les créneaux RX1/RX2 des passerelles conventionnelles + le créneau RXR du mode relais.

De plus, grâce aux mécanismes de découverte automatique, les administrateurs réseau peuvent maintenant déployer facilement de nouveaux relais à proximité des capteurs finaux souffrant d'une mauvaise QoS sans avoir à réinitialiser ces capteurs finaux.

Activation de la fonctionnalité

Les nouveaux cas d'utilisation sont automatiquement supportés à partir de ThingPark Enterprise version SaaS 7.3.4 et TPE auto-hébergé 7.3.3.

Limitations de la fonctionnalité

• Les cas d'utilisation de déploiement mentionnés ci-dessus ne sont traités que pour le mode Activation Over the Air (OTAA). Le mode d'activation ABP sera traité dans une future version.
• Lorsqu'un nouveau relais est déployé pour améliorer la couverture radio d'un capteur existant déjà desservi par un autre relais, le capteur doit passer au nouveau relais uniquement après avoir initié un nouveau cycle de join. Cette limitation est levée avec RDTP-21323.
• En raison d'une limitation connue du protocole de relais LoRaWAN v1.0, le mécanisme de découverte automatique basé sur la commande MAC NotifyNewEndDeviceReq ne fonctionne pas en cas de collision de DevAddr (c'est-à-dire lorsque le même DevAddr est partagé entre plusieurs capteurs). Par conséquent, si le DevAddr inclus dans la notification du relais est utilisé par plus d'un DevEUI, le network server ignore la commande NotifyNewEndDeviceReq.

Relais LoRaWAN : basculement transparent de capteur sans réinitialisation RDTP-21323

Cette fonctionnalité permet à un capteur de passer d'un relais à un autre sans être réinitialisé, c'est-à-dire, sans avoir besoin de revenir à l'état de join. Cela implique de supprimer le capteur de l'ancien relais et de l'ajouter au nouveau relais si ce dernier est le best-serving relay du capteur final.

Plus de détails

Voici quelques exemples de cas d'utilisation nécessitant de dissocier le capteur de son relais actuel pour l'associer à un nouveau relais :

1. Le relais actuel est hors service et a été remplacé par un autre relais.

2. Un capteur en mouvement quitte la couverture du relais-1 pour entrer dans la couverture du relais-2.

3. Un autre relais a été installé plus près du capteur pour offrir une meilleure couverture et une meilleure QoS.

Principaux avantages clients

Réseaux auto-organisés, offrant une meilleure qualité de service et une opérabilité fluide lorsque les capteurs sont utilisés en mode relais.

Activation de la fonctionnalité

La fonctionnalité est disponible automatiquement pour les plateformes ThingPark utilisant la version 7.3.5 ou supérieure.

Limitations de la fonctionnalité

Non applicable.

Notification d'alarme via les connexions IoT Flow RDTP-5254

Dans les versions précédentes, les alarmes de Passerelle et de Capteur étaient notifiées à des parties externes soit par email (à la fois TPE SaaS et auto-hébergé) ou par le biais de pièges SNMP (TPE auto-hébergé uniquement).

À partir de la version 7.3, en plus des pièges SNMP et des e-mails, les alarmes de Passerelle et de Capteur peuvent maintenant être signalées via les connexions "ThingPark X IoT Flow". ThingPark X IoT-Flow supporte une large gamme de connecteurs cloud professionnellement supportés vers les principales plateformes IoT : AWS, Azure, ThingWorx, Thingsboard, Cumulocity, Yandex, Google... IoT-Flow prend également en charge les protocoles MQTT, HTTPS et AMQP pour configurer toute connexion à usage général vers des serveurs d'applications tiers.

Plus de détails

Exemple des documents JSON signalés via ThingPark X IoT-Flow

{
  "DevEUI_alarm": {
    "ID": 4,
    "State": 1,
    "CreationTime": "2020-09-09T18:14:56.49+02:00",
    "LastUpdateTime": "2020-09-09T18:25:24.49+02:00",
    "Occurrence": 1,
    "Acked": 0,
    "AddInfo1": "69",
    "DevEUI": "0018B20000001156",
    "CustomerID": "199983788",
    "CustomerData": {
      "loc": {
        "lat": "43.58081",
        "lon": "1.4421667"
      },
      "tags": [
        "tag1",
        "tag2"
      ],
      "doms": [
        {
          "n": "France/Paris",
          "g": "Site"
        },
        {
          "n": "Location",
          "g": "Vertical"
        }
      ],
      "name": "My device 1"
    }
  }
}

{
  "BS_alarm": {
    "ID": 102,
    "State": 1,
    "CreationTime": "2022-12-05T19:57:02Z",
    "LastUpdateTime": "2022-12-05T19:57:06Z",
    "Occurrence": 1,
    "Acked": false,
    "AddInfo1": "1",
    "LrrID": "100001C2",
    "PartnerID": "1100033327",
    "CustomerID": "1100033327",
    "BaseStationData": {
      "name": "My base station 1"
    }
  }
}

Dans l'interface utilisateur de ThingPark Enterprise, puisqu'une passerelle peut maintenant être associée à une ou plusieurs connexions (pour le rapport d'alarmes BS), un nouvel onglet "Passerelles associées" est à présent disponible dans le tableau de bord détaillé "Connexion TPX", similaire à l'onglet "Capteurs associés".

note

Dans TPE auto-hébergé ThingPark Enterprise, en plus des connexions TPX, les alertes peuvent également être notifiées via la connexion Node-RED.

Avantages clés pour les clients

Grâce à cette fonctionnalité, les administrateurs ThingPark peuvent exploiter les connexions ThingPark X IoT-Flow pour envoyer des alarmes à leurs systèmes de supervision/NOC. De plus, les utilisateurs ThingPark peuvent enrichir l'intégration de leurs applications métiers avec ThingPark en poussant les alarmes des capteurs sur le même chemin de données que les rapports uplink applicatifs réguliers.

Parmi l'ensemble riche de connecteurs supportés par ThingPark X Iot-Flow, les clients peuvent choisir des connecteurs de type broker tels que MQTT ou Kafka pour implémenter des mécanismes publish/subscribe pour les notifications d'alarme au lieu d'interroger périodiquement les API ThingPark.

Activation de la fonctionnalité

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

Il peut être activé via l’interface utilisateur de ThingPark Enterprise :

• Au niveau de la connexion TPX : activer le rapport d'alarme pour les capteurs et/ou les passerelles:

  

• Au niveau du capteur : Associez vos connexion(s) TPX cibles à vos capteurs, si elles ne sont pas déjà associées.

• Au niveau de la passerelle: Associez votre (vos) connexion(s) TPX cible(s) à vos passerelles, depuis l'onglet "Avancé", le widget "Paramètres des alarmes".

  

Limitations de la fonction

Le signalement des alarmes de capteur et/ou de passerelle via des connexions de type "Basic HTTP" n'est pas supporté.

Intégration simplifiée avec les API ThingPark RDTP-16597

En tant qu'utilisateur disposant d'un abonnement ThingPark Enterprise :

• Avant la version 7.3, la seule API REST disponible pour gérer les ressources ThingPark était le DX-API.
• À partir de la version 7.3, en plus du DX-API, les utilisateurs peuvent accéder au jeu complet d’APIs ThingPark (également connu sous le nom de OSS-API). L’utilisateur peut tirer parti à la fois des APIs OSS & DX via un flux d’authentification unifié, basé sur les Comptes de Service créés par l’administrateur TPE.

Note importante

OSS-API est l'API recommandée pour tous les utilisateurs de ThingPark, DX-API devient obsolète à partir de la version 7.3.

Les points de terminaison de l’OSS-API sont nettement plus riches que ceux du DX-API, permettant aux clients de profiter pleinement des dernières améliorations apportées à chaque version de ThingPark.

Plus de détails

Principaux changements :

1. Support des comptes de service pour accéder aux API OSS/DX : Les comptes de service reposent sur le "flux de crédentiel client" défini par la norme OpenID Connect OAuth V2, c'est-à-dire que chaque compte de service est associé à un identifiant client et à un secret client.

2. Un nouveau flux d'authentification OAuth2 pour DX-CORE, basé sur les comptes de service : Ce nouveau flux est géré directement par le fournisseur d'identité intégré de ThingPark, au lieu d'utiliser DX-AMIN. Pour en savoir plus, consultez la documentation DX-CORE.

note

Le flux d'authentification DX-CORE hérité via DX-ADMIN est maintenant obsolète.

L'utilisation du nouveau flux d'authentification est fortement recommandée, bien qu'elle reste optionnelle dans la version 7.3 afin de maintenir la compatibilité ascendante avec les flux d'authentification hérités utilisés par certaines applications client.

Pour en savoir plus sur l'OSS-API, consultez la documentation Swagger OSS-API.

Principaux bénéfices pour les clients

Grâce à cette fonctionnalité, les utilisateurs peuvent désormais accéder au plus vaste ensemble de points de terminaison fournis par l'OSS-API, au lieu de se fier à l'API legacy DX-CORE. OSS-API est l'API recommandée pour les utilisateurs, les administrateurs et les développeurs d'applications intégrant ThingPark avec leurs applications métier.

De plus, les utilisateurs ont un flux d'authentification unique pour accéder à la fois aux APIs DX et OSS; c'est-à-dire qu'une fois authentifié, l'utilisateur a accès à tout point de terminaison, qu'il provienne de l'OSS-API ou du DX-CORE et ce, en utilisant le même jeton d'accès OAuth v2.

Activation de la fonction

La création et la gestion des comptes de service peuvent être effectuées par les administrateurs TPE depuis l'interface utilisateur TPE.

Limitations de la fonction

Non applicable.

Amélioration de la surveillance de la procédure d'activation OTA RDTP-19333

Cette fonctionnalité améliore la surveillance de l'Over-the-Air Activation, également connue sous le nom de "join" procédure :

1. Une nouvelle alarme de capteur "boucle de Join détectée" (numéro d'alarme 017) est déclenchée par le réseau au cas où un capteur OTAA enverrait une série de Join-Requests réussies (répondues par Join-Accepts) sans envoyer de trames uplink régulières. La gravité de l'alarme dépend du nombre de tentatives de join consécutives. Pour en savoir plus sur cette nouvelle alarme, consultez le guide de l'utilisateur.

2. Transitions plus complètes entre les états de santé du capteur, pour refléter l'achèvement réussi de la "join" procédure.

Plus de détails

• Avant la version 7.3 : l'état de santé du capteur OTAA devient "Active" une fois que le réseau reçoit le premier message Join-Request valide provenant de ce capteur.

• À partir de la version 7.3 : afin de mieux refléter les problèmes survenant pendant la "join" procédure, l'état de santé du capteur devient "Actif" uniquement à la réception du premier paquet uplink régulier valide (après la transmission du Join-Accept par le réseau). En conséquence, un capteur entrant dans une boucle Join-Request/Join-Accept reste dans l'état "Initialisation".

  Le diagramme suivant illustre les transitions d'état à partir de la version 7.3 :

  note

  Un capteur OTAA auparavant actif revient à l'état "Initialization" lorsqu'il envoie un nouveau message Join-Request au réseau.

Avantages clés pour les clients

Grâce à cette fonctionnalité, les gestionnaires de Capteur ThingPark peuvent identifier et résoudre rapidement les capteurs OTAA rencontrant des difficultés pour mener à bien leur processus d'activation. Cela peut être le cas de capteurs dysfonctionnants (en raison d'un bug du capteur), de capteurs incapables de recevoir des paquets de downlink en raison de problèmes de couverture RF ou même de capteurs avec une batterie presque vide.

Activation de la fonction

Cette fonctionnalité est automatiquement disponible dans ThingPark 7.3.

Limitations de la fonctionnalité

Non applicable.

Suspension de la connectivité du capteur RDTP-2308

Avant la version 7.3, il n'était pas possible de suspendre temporairement la connectivité d'un capteur spécifique sans le supprimer complètement.

À partir de la version 7.3, il est possible de suspendre et de reprendre la connectivité de tout capteur par le gestionnaire de capteurs.

Plus de détails

Lorsqu'un capteur est suspendu, le réseau envoie automatiquement la commande MAC DutyCycleReq au capteur, pour configurer son rapport cyclique de transmission à la valeur la plus basse. Ce mécanisme a deux avantages :

• Minimiser l'impact polluant du capteur suspendu sur l'interface radio.
• Préserver la batterie du capteur pendant que sa connectivité avec le réseau est temporairement suspendue.

Par défaut, le rapport cyclique maximum uplink envoyé aux capteurs suspendus dans la commande MAC DutyCycleReq est fixé à 0,00305%.

note

Un capteur suspendu peut être repris à tout moment sans avoir besoin d'initier une nouvelle "join" procédure. Lorsqu'un capteur suspendu est repris, le réseau envoie une autre commande MAC DutyCycleReq pour reconfigurer le capteur avec le rapport cyclique normal.

Principaux bénéfices pour les clients

Grâce à cette fonctionnalité, les gestionnaires de capteur ThingPark peuvent suspendre correctement la connectivité au réseau pour leurs capteurs sélectionnés, tout en préservant leur durée de vie de la batterie et en limitant l'impact des interférences causées par ceux capteurs suspendus sur l'interface radio.

Activation de la fonctionnalité

Les Capteurs peuvent être suspendus via l'interface utilisateur de ThingPark Enterprise :

• Dans le tableau de bord détaillé du capteur :

• Depuis la vue en liste des capteurs :

Il en va de même pour la reprise d'un capteur suspendu.

Limites des fonctionnalités

Non applicable.

[Wireless Logger] Affichage des messages Join-Accept au format décodé RDTP-15298

Dans les versions précédentes, le message Join-Accept était affiché dans le Wireless Logger en format crypté, tel qu'il est envoyé par voie aérienne vers le capteur final (c'est-à-dire chiffré par l'AppKey du capteur).

À partir de ThingPark 7.3, le Wireless Logger affiche les paquets Join-Accept sous format décrypté/décodé.

Plus de détails

Remarque

Pour les capteurs en itinérance, comme le réseau visité ne peut pas décrypter le Join Accept, le Wireless Logger de ce même réseau ne peut pas afficher le contenu brut MAC du message Join-Accept.

Principaux avantages pour le client

Résolution des problèmes liés au join facilitée :

• Les gestionnaires de capteur peuvent vérifier quelle configuration est envoyée par le réseau au capteur.
• Si le gestionnaire de capteur connaît la clé secrète du capteur (AppKey), il peut dériver les clés de session LoRaWAN à partir des contenus Join-Request et Join-Accept. Cela peut être utile à des fins de débuggage.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement activée pour les plateformes ThingPark 7.3.

Néanmoins, tous les messages Join-Accept envoyés avant la mise à niveau vers la version 7.3 restent affichés au format crypté par Wireless Logger.

Limitations de la fonction

Pour les capteurs activés via un Join Server externe, comme le Network Server d'origine ne peut pas connaître les champs JoinNonce et MIC inclus dans le message Join-Accept, Wireless Logger affiche respectivement FFFFFF et FFFFFFFF pour ces champs.

[Wireless Logger] Icones/couleurs plus compréhensibles RDTP-18975

Cette fonctionnalité propose une refonte des icônes et couleurs du Wireless Logger pour améliorer l'expérience utilisateur.

Les paquets uplink utilisent l'icône tandis que les paquets downlink utilisent l'icône .

Plus de détails

Les icônes sont enrichies pour représenter l'état le plus utile de chaque paquet et économiser du temps d'analyse pour les utilisateurs de Wireless Logger.

• Pour les paquets en uplink :
  • Les paquets tardifs (mis en tampon par la passerelle) sont affichés avec la lettre L sur leurs icônes.
  • Les paquets utilisant l'itinérance passive sont affichés avec la lettre R sur leurs icônes.
  • Pour les capteurs associés à des serveurs d'applications HTTP de base, l'échec de livraison à un ou plusieurs destinataires est représenté par un point coloré.
• Pour les paquets en downlink :
  • Les paquets multicast sont affichés avec la lettre M sur leurs icônes.
  • Les paquets utilisant l'itinérance passive sont affichés avec la lettre R sur leurs icônes.
  • Les paquets downlink envoyés en réponse à des trames uplink répétées utilisent une icône spéciale :
  • Les paquets downlink non effectivement envoyés par les passerelles sont représentés par un point rouge.

Survoler chaque icône affiche une courte description de sa signification. Pour en savoir plus, consultez le guide utilisateur de Wireless Logger.

Principaux avantages pour le client

Meilleure expérience utilisateur et identification plus rapide des comportements problématiques.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible à partir de la version 7.3.

Limites des fonctionnalités

Non applicable.

Nouvelles conventions de couleur pour les paquets UL/DL dans le Network Manager RDTP-19585

Au lieu d'utiliser les couleurs vert et orange pour les graphiques uplink et downlink respectivement, de nouvelles conventions couleur sont utilisées à partir de la version 7.3, afin d'éviter de mal interpréter le vert comme bon et l'orange comme avertissement.

Plus de détails

De plus, la légende colorée des métriques RF (SF, ESP, SNR, RSSI) est mise à jour selon une palette divergente (allant du vert au rouge) pour mieux représenter la valeur de la métrique.

Principaux avantages pour les clients

Interface utilisateur plus intuitive.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible à partir de la version 7.3.

Limitations de la fonction

Non applicable.

Configuration de l'indicateur de mouvement pour chaque capteur RDTP-14093

À partir de la version 7.3, l'indicateur de mouvement de chaque capteur peut être personnalisé, indépendamment de l'état d'activation de la fonctionnalité de géolocalisation du réseau.

L'indicateur de mouvement définit le profil de mobilité du capteur : quasi-statique, vitesse de marche, vitesse à vélo, vitesse de véhicule ou aléatoire.

Plus de détails

Le réseau central de ThingPark doit connaître l'indicateur de mouvement de chaque capteur afin d'adapter ses algorithmes en conséquence :

• Ajustez la configuration du filtre de Kalman utilisé par le LocSolver de ThingPark pour la géolocalisation TDoA/RSSI.
• Adapter la taille de la fenêtre glissante utilisée par les algorithmes radio du network server pour la sélection de la passerelle la mieux adaptée au routage des paquets downlink vers chaque capteur. Cette sélection affecte également la configuration optimale de la RF region pour chaque capteur, car le capteur hérite de la configuration de la RF region de sa meilleure passerelle en downlink.

Principaux avantages pour les clients

Grâce à cette fonctionnalité, le network server peut sélectionner efficacement la passerelle optimale pour le routage du trafic downlink lorsque le capteur est couvert par plusieurs passerelles, en fonction du profil de mobilité du capteur :

• Pour les capteurs stationnaires (associés à un indicateur de mouvement "près de statique"), l'algorithme de sélection se base sur une moyenne à long terme des métriques RF de chaque passerelle, pour prendre la meilleure décision pour chaque capteur individuel.
• Pour les capteurs en mouvement (indicateur de mouvement différent de "près de statique"), la moyenne à long terme de l'historique de réception ne peut être fiable. Par conséquent, la taille de la fenêtre glissante est fixée à 1 (c'est-à-dire uniquement le dernier paquet) pour ces capteurs.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible à partir de la version 7.3.

Par défaut, l'indicateur de mouvement de chaque capteur est hérité de la configuration de son profil modèle ; mais l'utilisateur peut le modifier à tout moment soit lors de l'étape de création initiale, soit en mettant à jour les capteurs existants.

Limites des fonctionnalités

Non applicable.

Enrichissement du tableau de bord des capteurs RDTP-16775 RDTP-16536

À partir de la version 7.3, le tableau de bord détaillé de chaque capteur est enrichi pour fournir des métriques RF supplémentaires et simplifier les tâches quotidiennes d'Opération & Maintenance.

Plus de détails

• Dans le widget "Statut", les métriques RF suivantes sont ajoutées :

  • SNR moyen, moyenné sur les 5 derniers paquets en uplink.
  • ESP moyen (Puissance de Signal Estimée), moyenné sur les 10 derniers paquets en uplink.
  • PER (Taux d'Erreur de Paquet) à long terme, calculé sur les 50 derniers paquets uplink distincts.
  • PER instantané (Taux d'Erreur de Paquet), calculé sur les 2 derniers paquets uplink distincts.

  

• Dans le widget "Historique du trafic radio" :

  • Le nombre quotidien/horaire de paquets uplink tardifs est affiché à côté des uplinks à l'heure.

• Dans le widget "Statistiques radio" :

  • L'onglet appelé précédemment PER est désormais renommé "Reçu / perdu" et montre la répartition horaire/quotidienne des paquets uplink reçus vs. perdus.

    

  • Il est désormais possible d'afficher la moyenne quotidienne/horaire des métriques SNR/RSSI/ESP pour une passerelle spécifique. Par défaut, "n'importe lequel" signifie que les métriques considèrent le meilleur paquet reçu, quel que soit la passerelle le recevant.

Principaux avantages pour les clients

Grâce aux métriques RF supplémentaires, les utilisateurs de ThingPark Enterprise ont plus d'informations sur les performances de chaque capteur, y compris une représentation plus complète de la perte des paquets uplink. Ainsi, cette fonctionnalité contribue à réduire les efforts de supervision et de dépannage réalisés par les gestionnaires de capteurs ThingPark.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible à partir de la version 7.3.

Limites des fonctionnalités

Le comptage des paquets uplink perdus n'est pas disponible pour la durée d'exécution d'une version logiciel antérieure à 7.3. Par conséquent, le graphique « Reçus / Perdus » est vide pour la période avant la mise à jour logicielle.

Rapport à AS du nombre de paquets UL manquants RDTP-20502

Comme indiqué dans la fonctionnalité précédente, il est désormais possible d'identifier clairement le nombre de paquets uplink manquants dans l'interface utilisateur de ThingPark Enterprise. De plus, RDTP-20502 ajoute cette même capacité dans les rapports de trames uplink envoyés par le network server aux serveurs d'applications des clients.

Plus de détails

Un nouvel attribut LostUplinksAS est ajouté dans les Rapports de Trames Uplink. Il représente le nombre de trames uplink perdues pour ce capteur, depuis le dernier rapport UL à AS.

• Lorsque LostUplinksAS > 0 : certaines trames uplink ont été perdues et le champ fournit le nombre de ces trames perdues.
• Lorsque LostUplinksAS = 0 : aucune trame uplink n'a été perdue depuis le dernier rapport pour ce capteur.
• Lorsque LostUplinksAS < 0 : certaines trames uplink étaient initialement pensées perdues par le réseau mais ont finalement été reçues tardivement (en raison de problèmes de connexion dorsale entre la passerelle et le réseau central). Ces trames tardives ont été signalées avec un nombre positif dans le LostUplinksAS d'un rapport précédent. Ainsi, elles sont de nouveau signalées avec un nombre négatif pour permettre à AS de corriger facilement le compte agrégé sur la fenêtre d'agrégation requise en additionnant les valeurs de tous les LostUplinksAS reçus dans cette même fenêtre.

Pour en savoir plus sur ce nouvel attribut, consultez la description détaillée des Rapports de Trame Uplink (DevEUI_uplink) dans la description de l'API du tunnel LRC à AS .

Principaux avantages pour les clients

Intégration simplifiée avec les serveurs d'applications des clients.

Activation de la fonctionnalité

Cette fonctionnalité est activée par défaut, elle ne nécessite aucune procédure d'activation spécifique. Pour les déploiements auto-hébergés, la fonctionnalité est disponible à partir de la version 7.3.1.

Limitations de la fonctionnalité

Non applicable.

Améliorations UI/UX RDTP-16693

Cette fonctionnalité apporte plusieurs améliorations à l'interface utilisateur de ThingPark Enterprise, améliorant ainsi l'expérience utilisateur.

Plus de détails

Les améliorations suivantes sont disponibles à partir de la version 7.3.2 de ThingPark Enterprise :

• Possibilité d'ouvrir plusieurs ressources (Passerelles, Capteurs, Groupes de Multicast, Connexions, Domaines, Groupes de Domaines, Comptes Utilisateurs, Comptes de Service etc.) à la fois dans plusieurs onglets du navigateur pour les comparer et analyser leurs différences.

  • Depuis la vue de liste, survoler le lien de la ressource affiche un popup "Ouvrir dans un nouvel onglet", comme dans la capture d'écran suivante. De plus, le comportement standard du navigateur reste applicable, comme clic droit puis “Ouvrir le lien dans un nouvel onglet” ou contrôle-clic gauche…
  • Le titre de la page permet d'identifier quelle page est actuellement ouverte.

• Le menu de gauche est retravaillé pour simplifier la navigation entre les différentes ressources :

  • Les entrées "Liste" et "Créer" du menu de gauche sont supprimées. Cliquer sur le type de ressource affiche directement la vue de liste, où de nouveaux boutons permettent d'ajouter des ressources ou d'importer les capteurs en vrac.
  • Accessibilité améliorée des Network Tools : Wireless Logger, Spectrum Analysis et Network Survey. Ces outils étaient auparavant positionnés sous "Gestion Opérationnelle" dans le menu de gauche, maintenant ils deviennent facilement accessibles sous "Outils Réseau".

• Les informations sur la licence sont maintenant transférées à la page Paramètres et ne sont accessibles qu'aux administrateurs. De plus, le contenu du widget Licence est enrichi pour montrer les crédits de passerelles et de capteurs restants à côté de la limite maximale.

Avantages clés pour le client

Amélioration de l'interface utilisateur/expérience utilisateur, comme détaillé dans la section précédente.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible à partir de TPE SaaS 7.3.2 et TPE auto-hébergé 7.3.1.

Limites des fonctionnalités

N/A.

Isoler les connexions par domaines RDTP-21377

Avant la version 7.3.3, lorsqu'un abonnement TPE est partitionné en plusieurs locataires via domaines administratifs, les connexions vers les applications externes étaient obligatoirement inter-domaines. Cela signifie qu'elles sont utilisables dans tous les domaines et accessibles en mode lecture seule par les utilisateurs non-administrateurs.

À partir de la version 7.3.3, deux types de connexions sont supportés :

• Connexions inter-domaines (comme avant) : ces connexions ne sont associées à aucun domaine. Les utilisateurs ayant des restrictions de domaine ne peuvent accéder qu'aux connexions inter-domaines en mode lecture seule. Toute information confidentielle est masquée en mode lecture seule, comme l'URL et les en-têtes personnalisés des connexions HTTPS de base.
• Connexions spécifiques au domaine (introduites par cette fonctionnalité) : ces connexions sont associées à un ou plusieurs domaines. Par conséquent, elles ne sont visibles que par les utilisateurs autorisés dont les restrictions de domaine correspondent. De plus, elles ne peuvent être associées qu'à des capteurs appartenant à ces utilisateurs autorisés.

Plus de détails

La liste des connexions est enrichie d'une nouvelle colonne "Domaines" selon l'exemple suivant :

note

Dans TPE auto-hébergé, les connexions Node-RED sont toujours inter-domaines.

Principaux avantages pour les clients

Grâce à cette fonctionnalité, les administrateurs TPE peuvent définir des connexions spécifiques aux locataires vers des applications IoT externes pour isoler les connexions entre leurs différents locataires.

Activation de la fonctionnalité

Lorsqu'une plateforme TPE partitionnée par domaines est mise à niveau vers la version 7.3.3, toutes les connexions existantes restent inter-domaines pour des raisons de compatibilité descendante. Une connexion inter-domaine n'est associée à aucun domaine.

Pour convertir une connexion inter-domaine en connexion spécifique au domaine, les utilisateurs ayant un accès en écriture à la connexion peuvent l'associer à un ou plusieurs domaines depuis le tableau de bord de connexion sur l'interface utilisateur TPE :

Pour ajouter une nouvelle connexion spécifique au domaine :

• Pour les connexions TPX : seuls les administrateurs ou utilisateurs ayant le rôle "Gestionnaires de Capteurs, Groupes Multicast et Connexions" sans restrictions de domaine peuvent ajouter des connexions TPX.

  prudence

  Après sa création dans l'interface utilisateur TPX IoT Flow, la connexion TPX est à l'origine inter-domaine ; donc l'utilisateur doit éditer la connexion nouvellement créée dans l'interface utilisateur TPE pour l'associer à des domaines.

• Pour les connexions HTTPS de base : en plus des administrateurs, les utilisateurs ayant le rôle de "Capteur, Groupe Multicast et gestionnaires de Connexion" peuvent ajouter des connexions HTTPS de base et les associer aux domaines appropriés, même si ces utilisateurs ont des restrictions de domaine. Dans ce cas, les domaines associés à la connexion doivent correspondre aux restrictions de domaine propres à l'utilisateur.

Limites des fonctionnalités

La mise en œuvre de cette fonctionnalité dans TPE 7.3 présente deux limitations concernant les connexions TPX :

• La provision de nouvelles connexions TPX n'est pas autorisée pour les utilisateurs ayant des restrictions de domaine.
• Les utilisateurs ayant des restrictions de domaine ne peuvent pas accéder à l'interface utilisateur de TPX Iot Flow : le bouton est grisé dans le tableau de bord des connexions de l'interface utilisateur TPE.

Support d'accès à distance pour les passerelles Basics Station RDTP-18681

Cette fonctionnalité permet aux administrateurs de réseau utilisant le transfert de paquet Basics Station d'accéder à distance au terminal local de la Basics Station pour dépanner leurs passerelles et exécuter des commandes OSS au besoin.

Plus de détails

Les utilisateurs peuvent ouvrir une session à distance à partir de l'interface utilisateur de ThingPark, en ouvrant les détails de la passerelle, puis aller dans l'onglet Avancé et cliquer sur Ouvrir une session.

Jusqu'à deux sessions à distance peuvent être ouvertes simultanément. La session se ferme automatiquement après 10 minutes d'inactivité.

La session s'exécute avec le même utilisateur Linux que le logiciel Basics Station lui-même.

note

En fonction de la version du logiciel Basics Station s'exécutant sur la passerelle, le shell à distance peut ne pas être disponible. Dans ce cas, le bouton "Ouvrir une session" est désactivé dans l'interface utilisateur de ThingPark.

Principaux avantages pour le client

Facilité de dépannage des problèmes Basics Station et possibilité d'exécuter des commandes OSS.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible pour les plateformes ThingPark utilisant la version 7.3.3 ou supérieure.

Limites des fonctionnalités

Les limitations suivantes s'appliquent dans cette version :

• La mise en œuvre de cette fonctionnalité est basée sur la fonction de shell à distance (rmtsh) implémentée par le code de référence Basics Station de Semtech. Cela peut ne pas fonctionner correctement si le fabricant de la passerelle implémente une version différente de la référence de Semtech.

• Étant donné que cette fonctionnalité repose sur les Websockets, les proxys entre le navigateur Web et ThingPark doivent autoriser les Websockets. Notez qu'un tel proxy peut fermer la session prématurément en cas d'inactivité.

Améliorations UI/UX pour les bases Stations Basics RDTP-20905

Cette fonctionnalité introduit les améliorations suivantes pour les bases Stations exécutant le transfert de paquet Basics Station :

• Un assistant GUI pour calculer l'ID ThingPark de la base Station à partir du Station EUI ou du Gateway-ID.
• Toutes les fonctionnalités GUI non supportées par Basics Station sont désormais clairement désactivées ou masquées.

Plus de détails

Lors de l'ajout d'une base Station reposant sur Basics Station dans ThingPark GUI :

• Un message explicite indique à l'utilisateur que le modèle de base Station sélectionné utilise le transfert de paquet Basics Station et affiche le lien vers la documentation Basics Station.

• Le champ « LRR-UUID » (qui est l'ID ThingPark de la base Station) est déjà prérempli avec le préfix « 0016C0- », qui correspond à la partie OUI du UUID de ThingPark. L'autre partie de l'UUID peut être calculée à partir du station EUI ou du gateway ID.

  

  

Dans le tableau de bord détaillé de la base Station :

• Le type de forwarder de paquet est explicitement affiché dans un nouveau champ "Forwarder de Paquet".
• Une indication explicite s'affiche dans les widgets vides lorsque les métriques concernées ne sont pas supportées/rapportées par le logiciel Basics Station, mais uniquement par le packet forwarder LRR.
• De plus, les boutons GUI déclenchant des commandes OSS distantes sont désactivés lorsque ils ne sont pas supportés par le logiciel Basics Station, mais uniquement par le forwarder de paquets LRR.

Principaux avantages pour le client

Amélioration de l'expérience utilisateur avec les bases Stations exécutant le transfer de paquet Basics Station.

Activation de la fonctionnalité

Cette fonctionnalité est automatiquement disponible pour les plateformes ThingPark utilisant la version 7.3.3 ou supérieure.

Limites des fonctionnalités

Non applicable.

Support de la classe B pour les passerelles Basics Station RDTP-22167

Cette fonctionnalité permet aux passerelles utilisant le packet forwarder Basics Station de supporter le mode LoRaWAN classe B, via l'émission de signaux de beacon périodiques + des pingslots de classe B.

Plus de détails

Principaux avantages pour le client

Grâce à cette amélioration, les capteurs de classe B peuvent être desservis par des passerelles utilisant le packet forwarder Basics Station.

Activation de la fonctionnalité

Pour supporter la classe B, l'émission des signaux de beacon doit être activée sur la passerelle.

Dans la version actuelle, l'activation du beacon doit se faire via l'OSS-API :

• Endpoint: PUT /partners/mine/bss/{bsUid}
• Parameter: activateBeaconTransmission (boolean, must be set to true, default is false).

Limites des fonctionnalités

L'activation de la transmission des signaux de beacon sur les passerelles utilisant le forwarder de paquet Basics Station n'est pas encore supportée par l'interface utilisateur. Vous devez utiliser l'OSS-API pour activer les beacons sur les passerelles Basics Station.

Support multicast pour les passerelles Basics Station RDTP-22459

Cette fonctionnalité permet aux passerelles utilisant le forwarder de paquet Basics Station de prendre le support du mode multicast LoRaWAN. Le mode multicast est utilisé pour améliorer l'efficacité spectrale en downlink, il est compatible avec les modes de classe B et C.

Pour en savoir plus sur le multicast en downlink, consultez À propos du multicast.

Plus de détails

Principaux avantages pour le client

Grâce à cette amélioration, les clients ThingPark exploitant des passerelles utilisant le packet forwarder Basics Station peuvent tirer parti du mode multicast pour supporter des cas d'utilisation supplémentaires tels que l'éclairage public et la mise à jour du firmware par voie hertzienne (FUOTA).

Activation de la fonctionnalité

Voir le guide d'utilisation pour en savoir plus sur la configuration et la gestion des groupes multicast.

Limites des fonctionnalités

Non applicable.

Support multi-langue de l'interface utilisateur RDTP-22709

L'interface utilisateur de ThingPark Enterprise, y compris ThingPark X Iot-Flow, prend désormais en charge plusieurs langues : anglais, français, italien, espagnol, allemand et japonais.

Des langues supplémentaires peuvent être ajoutées sur demande.

Plus de détails

Principaux avantages pour le client

Amélioration de l'expérience utilisateur, affichant l'interface utilisateur de ThingPark dans la langue préférée de l'utilisateur.

Activation de la fonctionnalité

Cette fonctionnalité est supportée depuis la version SaaS TPE 7.3.6 et TPE auto-hébergé 7.3.4.

Pour changer la langue par défaut, allez dans Mon Profil puis sélectionnez votre langue préférée.

Limites des fonctionnalités

• Les outils réseau (Wireless Logger, Spectrum Analysis, Network Survey et Network Coverage) ne sont actuellement supportés qu'en anglais.

• La description du fabricant pour les passerelles et les capteurs, ainsi que la description de la RF region, est affichée uniquement en anglais.

• Les e-mails générés par le système, par exemple pour l'activation d'utilisateur ou la notification d'alarme, sont envoyés uniquement en anglais.