New features common to SaaS and Self-hosted

Multi-tenancy within the same subscription RDTP-8479

Prior to release 7.2, the user permissions supported in ThingPark Enterprise do not allow partitioning the TPE subscription across multiple tenants. In other words, all the resources (devices, base stations and multicast groups) are visible to all users, the write-access being defined by the user's role. Nevertheless, supporting multi-tenancy in TPE SaaS may be fulfilled through the multi-TPE-subscription model.

Starting release 7.2, the same TPE subscription may be partitioned to serve multiple tenants, allowing full segregation of the user permissions. This segregation is managed through the notion of administrative Domains.

Important Note

Regardless of the user permissions' segregation through administrative Domains, every Base Station operating under the TPE subscription continues to serve LoRaWAN® traffic from any device under this same subscription without any exclusion.

The same thing applies to Connections towards Application Servers: any Connection can serve any device because Connections remain cross-domain, i.e., TPE-subscription-wide. Nevertheless, non-administrators having Domain Restrictions have ready-only access to Connections.

More details

Feature impact, as an Administrator

With this new multi-tenancy feature, TPE users having the "Administrator" role can perform the following tasks. These tasks are described in the recommended order they should be executed by the Administrator to activate this new feature.

1. Create administrative Domains to segregate user permission within their TPE subscription, via the left panel: Manage > Domains > Create.

   

   • Each Domain belongs to a Domain Group. A Domain Group defines a segregation scope. All the Domains grouped under the same scope are mutually exclusive to avoid segregation conflicts, i.e., a given resource (device, base station or multicast group) cannot be associated with more than one Domain from the same group. For instance, a device cannot be associated to both Domains "France" and "Germany" that are grouped under the same Domain Group "Geography".

     Note Each Domain Group may be assigned a distinct color to be easily identifiable in the GUI.

   • Multiple segregation scopes (expressed as Domain Groups) are allowed within the same TPE subscription. For instance, segregating permissions by Geography and/or Use-case scopes, as shown in the following example:

     

   • Administrators may define hierarchical domains to support hierarchical access within their organization. Example EMEA/France, EMEA/Germany, EMEA/United-Kingdom, EMEA/France/Paris...

2. Associate base stations, devices, and multicast groups with Domains during initial provisioning (unitary creation or bulk import) or by updating an existing resource. Existing resources can be easily associated with Domains through the list/map views, thanks to the new "domain association" button at the top-right of the list/map:

   

   

   Note

   The same resource may be associated with multiple Domains belonging to distinct Domain Groups, but assigning several Domains from the same group to one resource is not allowed.

   Important Note

   Tags and Domains are 2 distinct attributes supported by devices and base stations. The main differences are summarized in the following table:

   	Tags	Domains
   Usage	Like free-text stickers, essentially used for resource categorization and filtering. Additionally, Base Station tags may be used for Multicast purposes. Device tags are reported to Application Servers to allow segregated traffic processing.	User permission management. Note The Domains associated with each device are also reported to Application Servers.
   Who can assign it?	Freely assigned by Administrators and non-administrators having write access to the resource in question.	Only pre-defined Domains (created by an Administrator) can be associated with resources. While Admins can associate a resource with any Domain (except assigning several Domains from the same group), non-admins can only assign Domains in accordance with their own Domain Restrictions.
   Can be used for permission management?	No, because tag addition/removal is freely opened for non-administrators so it cannot be controlled by Admins.	Yes, because Domains are strictly controlled by Administrators.

3. Associate non-administrator end users with Domain Restrictions to restrict their access to resources (devices, base stations and multicast groups).

   • A Domain Restriction may consist of a full Domain or a Domain prefix. This latter is useful for hierarchical permission management. Example The following user configuration allows the user to access resources associated to EMEA region, including EMEA/France/Paris, EMEA/Germany and EMEA/United-Kingdom Domains:

     

• "Domain Restrictions" field may consist of several Domains (or Domain prefixes), but they must belong to distinct Domain Groups.

• For each Domain Group represented by the "Domain Restrictions" field, only the resources matching the related Domain can be accessed by the user. Not representing a Domain Group in the user's Domain Restrictions means that the user does not have any permission restriction for this group. Here are some examples reusing the Domain definitions described above:

  • Example 1: A user having "Domain Restrictions" = "EMEA/United-Kingdom" AND "Asset Tracking" can only access resources associated with at least "EMEA/United-Kingdom" AND "Asset Tracking" Domains.

  • Example 2: A user having "Domain Restrictions" = "EMEA/United-Kingdom" can access resources associated with at least "EMEA/United-Kingdom", whatever their Domain assignment (or not) from the Use-case Domain Group, since this user has no restriction regarding the Use-case group.

  Note

  To delete a Domain by an Administrator, it must be deactivated first to prevent associating it with new resources. Then, it can be deleted only when it is not associated with any resource/user.

  Important Note

  Once at least one Domain is defined by the Administrator, the following tasks become restricted to Administrators, they cannot be executed by non-admin users:

• Creating/editing/deleting a Connection towards Application Servers. Non-admins can view existing Connections in read-only mode without being able to edit them, the traffic information displayed in the Connection page is filtered to match the user's Domain Restrictions.

• [Self-hosted TPE specific] Managing Service Accounts, they are not visible to non-admins.

Note

Administrators, by definition, do not have any Domain Restriction; therefore, they have a global view on the TPE subscription, but they may use the list-filtering function to focus on resources belonging to a specific Domain.

Feature impact, as a non-administrator

If a non-administrator user does not have any Domain Restriction, they can access all resources without any restriction and freely associate them with Domains, as described above for Administrators.

Once Domain Restrictions are defined for a non-administrator user, the system will restrict their access rights as follows:

• Only access resources matching their own Domain Restrictions. For all those resources, the user can access the related traffic (through the last 10 (or 25) packets widgets or from Wireless Logger) as well as the related alarms.

Note

The access right (read-only or read/write) on accessible resources depends on the user's role, i.e., viewer vs. device manager vs. base station manager.

• Create new resources and associate them with Domains matching the user's Domain Restrictions.

  

• Add or remove Domains to existing resources if the user's Domain Restrictions will remain fulfilled before and after the update.

• Access Connections in read-only mode, but access to ThingPark X IoT Flow GUI is prohibited.

Key customer benefits

Thanks to this feature, ThingPark Enterprise customers can operate several tenants within the same TPE subscription. Each tenant would have access to resources (devices, base stations, multicast groups) bound to their perimeter.

This feature was designed in a versatile way to address a wide variety of use-cases, where tenants may be segregated based on several segregation scopes.

• Different tenants could be fully isolated from each other. For instance:

  • Users and resources belonging to deployment-site-A may be fully isolated from those belonging to deployment-site-B, by defining administrative Domains grouped by "Geography" (or "Location").

  • Similarly, a Solution Provider may segregate/isolate their different end-customers by defining a Domain Group "Customers" and creating a domain for each tenant customer.

  • Also, the TPE administrator may want to split administrative permissions by vertical use-case, e.g., isolate "Smart building" team from "Asset tracking" team.

• Mixing and matching multiple segregation scopes is fully supported.

• Hierarchical organizations are also supported, thanks to Domain prefixing.

Feature activation

This feature is automatically available after the platform upgrade to release 7.2.

See "Feature description" section to learn more about defining administrative Domains, associating them with devices, base stations and/or multicast groups, as well as defining Domain Restrictions to individual non-admin user accounts.

Note about backward compatibility

When the platform is upgraded to release 7.2 from a previous release, since administrative Domains have not been created yet, the same permissions as before remain applicable. Additionally, if no Domain has been defined by the Administrator, all the domain-specific additions on devices/base stations/multicast groups and user accounts are masked in the GUI.

Feature limitations

The implementation of this feature in release 7.2 has the following limitations:

• The Domain Group and Domain names cannot be updated after creation. In case of typing error, the Domain Group (or the Domain itself) should be deleted then recreated.

• The maximum number of levels in Domain name hierarchy is 5. For instance, to represent a geographical hierarchy, 5 levels could be defined at maximum, like Region/Country/State/City/Site.

• The following resources/functions are cross-domain, i.e., they are accessible/usable for all the domains without segregation:

  • Connections towards Application Servers

  • Custom payload Drivers

  • TPE license, i.e., it is not possible to define a quota per Domain

  • Network Survey and Spectrum Analysis tools

  • The "News" widget under "Dashboard" panel

  • End users' roles, i.e., a user cannot be Base Station Manager in domain 1 and Viewer only in domain 2.

• All devices imported during a given bulk-import operation must be associated with the same Domain(s). You may use several operations (csv import files) to import devices over different Domains, but each operation should have the same Domain association.

• It is currently not possible to define 2 Domains from the same Domain Group in the user's Domain Restrictions. This limitation will be lifted in a future ThingPark release.

• After activating the feature, non-admins having Domain Restrictions can see LoRaWAN® traffic transmitted only after the resource's association with the Domain(s), in Wireless Logger, Last 10 (or 25) packets widgets etc.

Device migration from TPE-All-in-One to standard TPE RDTP-16248

This scope of this feature is to allow a ThingPark Enterprise All-in-One (TAO) customer to seamlessly migrate their devices towards a full-edition TPE subscription. "Seamless" migration means that network contexts of active devices are moved from one platform to another without physically resetting those devices.

More details

This migration is executed via a 3-step approach:

1. Generate a "Migration Key" from the GUI of the target TPE subscription, under Operating Management > "Migrate from ThingPark Enterprise All-in-One" widget. Save this key to upload it to your TPE-All-in-One GUI in step #2.

   

2. Export device contexts from TPE-All-in-One, under "Advanced Management" > Export. You must provide the "Migration Key" retrieved from TPE in the previous step.

   

3. On the TPE GUI, import your "export-YYYY-MM-DD.taodevices" file to ThingPark Enterprise GUI, through the "Operating Management" tab:

   

   Note

   During this step, you will be requested to associate your imported devices with one or several Connections towards external Application Servers. So, those Connections must be setup prior to the import process.

At the end of the migration operation, all the devices should seamlessly work on the ThingPark Enterprise platform.

To learn more about this migration procedure and its prerequisites, see ThingPark Enterprise All-in-One documentation.

Key customer benefits

Thanks to this feature, ThingPark Enterprise All-in-One (TAO) customers can safely upgrade their subscription to use the full-edition ThingPark Enterprise, either in SaaS or Self-hosted deployment models. This smooth and seamless migration path enables those TAO customers to scale up their deployments from a single autonomous gateway model towards a scalable multi-gateway highly-available architecture. Additionally, upgrading to full-edition ThingPark Enterprise unlocks many features such as leveraging ThingPark X IoT Flow, RF macro diversity, Operational tools (Wireless Logger, Network Survey, Spectrum Analysis), Network Geolocation...

The migration procedure is secured through a migration key generated by the target TPE subscription. The migration key is an RSA public key used to encrypt devices keys that must remain confidential. The encrypted data can only be decrypted by the target TPE server.

Feature activation

This feature is automatically available after the platform upgrade to release 7.2.

Feature limitations

The Application configuration in TPE-All-in-One (via Node-Red) is not automatically imported in the target TPE subscription: hence, the Channel Partner (or System Integrator) should manually configure the Connection towards external Application Servers, either through TPX IoT Flow or use a Basic HTTP connector.

Reminder Self-hosted TPE supports Node-Red type of Connections, but this is not supported by TPE SaaS.

Enhanced management of BS security certificates RDTP-7689 RDTP-16889

Starting release 7.2, the base station certificate renewal mechanism is automated by the system: X.509 certificate is automatically regenerated few days (6 by default) before expiration.

More details

Additionally, this feature brings several UI/UX enhancements to the BS security management in Network Manager.

• A new column "Certificate" is added to the Base Station list, showing the certificate status: expired, valid (with the expiration date)... This new column is hidden by default.

  

• "Expired": The generation of the BS certificate is enabled, and the certificate has expired. The expiration date is displayed on mouse over and added in parentheses in the CSV export file.

• "Expiration in <duration>": The generation of the BS certificate is enabled, and the certificate is valid. The expiration date is displayed on mouse over and added in parentheses in the CSV export file.

• "Not generated": The generation of the BS certificate is disabled, and the base station has an LRR UUID.

• "Retrieving information...": The BS has an LRR UUID, but the status of its certificate is not yet available in the list.

• A new filtering criterion of the BS list, by Certificate status.

  

• In the Base Station's detailed page > Advanced tab > Security widget, the certificate expiration date is displayed if it is known by the backend system, otherwise the certificate generation date displayed.

  

  Note To handle exceptional situations, Network Administrators may manually generate X.509 certificates after expiration. This action will automatically revoke the current X.509 certificate before generating a new one.

• More comprehensive UX during BS creation:

  • The security-related fields are now grouped in a new section "Security".

  • The field "IPSec (X.509) for base station to TPE connection" is replaced by a checkbox "Generate base station certificate". Activating this option shall automatically generate an X.509 certificate for this base station, regardless of the effective activation state of IPSec/TLS security on the base station end.

  • The field "Public key" is displayed only when the use of Public Key authentication is enabled by the platform administrator.

Note

This feature does not change the recommended procedure that a Network Administrator should apply in case of a stolen BS or X.509 certificate corruption, reminded hereafter:

• In case of a stolen/compromised base station, it must be deleted from ThingPark system.

• In case of a stolen X.509 certificate:

  • From the LRR SUPLOG: the RSA public/private key pair must be regenerated.

  • From TPE GUI, update the RSA public key to use the newly generated one.

  • From TPE GUI, regenerate the X.509 certificate (this action will automatically invalidate/revoke the previous (compromised) certificate.

This feature requires LRR version 2.4.73 or higher, to support the automatic download of the X.509 certificate by the LRR before its expiration.

Key customer benefits

The feature brings significant operational + UI/UX enhancements of the BS certificate management process, including automatic renewal before expiration.

Feature activation

This feature is available upon migration to release 7.2.

Feature limitations

None.

Deduplication of late uplink packets before transmission to AS RDTP-5011

Prior to release 7.2, late uplink frames were sent to AS without being deduplicated.

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

• In case the LRC receives several copies of the same uplink packet that is flagged "late" by the LRR base station(s), only one copy of such packet (identified by its FCntUp) is reported to Application Sever. This deduplication also applies when a base station - recovering from temporary backhaul disconnection - forwards a late UL frame that had already been forwarded on-time through another base station having stable backhaul connection.

• Additionally, an optional time-to-live is defined system-wide to determine if LRC should report too old late uplink packets to Application Servers. See Feature Activation section to learn more about configuring this option.

More details

Note

In all cases, even if too-old packets are not reported to AS, they are still visible reported to TWA backend and visible in Wireless Logger.

Key customer benefits

Thanks to this new feature, Application Servers now receive only one copy of each uplink frame within the defined TTL window (which by default is set to infinite), even if some of these packets arrive late (e.g., due to buffering in a base station that temporarily lost its backhaul connection): there is no longer a need to manage deduplication on AS side.

Consequently, besides the simplified processing on AS side, this feature avoids overloading the connection towards external AS while the system is recovering from a major backhaul outage situation, i.e., purging the queued/late packets.

Feature activation

The feature is activated by default.

To deactivate it, set [deduplateul].enable=0 in the custom lrc.ini file of the LRC subsystem.

New LRC-wide settings:

• [deduplateul].max-fcntup-history: Max number of entries in UL packets history.

  • Default = 50.

  • Each entry may correspond to a FCntUp range, defined by a pair of FCntUp at the start and the end of the range in question.

• [deduplateul].late-time-to-live, time to live (in seconds) to report a late packet to AS.

  • Default = 0, meaning that all late packets are reported – after being deduplicated – regardless of their age.

  • When set to x ( x > 0), the LATE packet is reported to AS only if it has been queued for less than x seconds by the system, the reference time being the LRR timestamp of the UL packet.

Feature limitations

None.

TLS enhancements for secure LRR-LRC backhaul RDTP-17091 RDTP-5248

The following enhancements are supported in LRR packet forwarder when the backhaul between the base station and the core network is secured via TLS:

• Automatic renewal of the base station's X.509 certificate, few days before its expiration (or when it has already expired).

• Ability to activate TLS from SUPLOG, or switch between TLS and IPSec security modes.

More details

Key customer benefits

Improved base station operability and configurability under TLS mode.

Feature activation

To activate TLS from SUPLOG, user should navigate to System Configuration > Backhaul.

Since all the destinations are set towards the local host in TLS mode, the LRC and SFTP download/upload addresses become automatically set by the inherent TLS configuration.

Note

When TLS is activated, SFTP must be used since TLS does not support FTP.

This feature is supported from LRR 2.8.20 onwards. Since all the impacts are on LRR side (no impact on backend/core network), it can safely operate with earlier ThingPark versions, provided that LRR version is 2.8.20 or higher.

Feature limitations

None.

Support NetID subnetting RDTP-15106

Prior to release 7.2,  to support roaming, the same NetID cannot be shared across several ThingPark platforms. This rule does not apply to NetIDs 0 and 1, because roaming-out is not supported on those private NetIDs by definition.

Starting release 7.2, roaming becomes possible while sharing the same dedicated NetID (higher than NetID 0x000001) across different ThingPark platforms, thanks to a virtual NetID/NwkID subnetting.

When a given NetID (for instance Actility's NetID 0x000002) is split into several subnets, a distinct DevAddr block must be assigned to each LRC cluster, so that backend traffic can be properly routed to/from peer Network Servers via ThingPark Exchange.

More details

Note

This feature requires the support of LoRaWAN® Backend Interfaces v1.1 and ThingPark Exchange (TEX) version 1.2 onwards.

Key customer benefits

Thanks to this feature, the same NetID may be shared across several ThingPark platforms, with a distinct DevAddr block assigned to each platform.

This is particularly interesting for TPE SaaS & Self-hosted deployments where:

• Different customers using Actility's regional TPE SaaS datacenters can leverage Actility's global roaming agreements (using Actility's NetID 0x000002) to connect with peer public and private LoRaWAN® networks across the world.

• Large self-hosted TPE deployments made up of multiple edge platforms can share the same dedicated NetID, while assigning a subnet to each individual self-hosted TPE platform.

Feature activation

This feature is deactivated by default.

To activate it, each SaaS platform should be assigned a distinct DevAddr block in the LRC table O. This configuration is done by Actility NetOps team for each regional SaaS platform.

For self-hosted TPE, the feature can be activated by allocating a DevAddr subnet in Cockpit. To learn more, see TPE Administration and Troubleshooting guide.

Feature limitations

NetID subnetting remains platform-wide, i.e., different tenants using the same NetID in the same platform cannot have different subnets (DevAddr blocks) assigned to each tenant.

Enhanced reporting of passive roaming metadata to AS/WLogger RDTP-14913

Starting TP7.2, the following additional metadata is reported by sNS to Application Servers, in passive roaming context:

• Instead of reporting a virtual GWID (common to all gateways of a given fNS), sNS now reports the real fNS gateway-ID to AS. This information is also displayed in Wireless Logger.

  Note

  In case the real GWID is not reported by fNS, sNS reports the virtual (internal) GWID like in TP7.1.

• Additionally, sNS reports to AS (and WLogger) the real gateway count, counting the reception of the UL frame through both home & roaming gateways within the sNS's deduplication window.

• Last but not least, the NetID and NSID of each fNS partner are also reported to AS starting TP7.2.

More details

Key customer benefits

This feature provides sNS network operators with valuable information to analyze and troubleshoot their passive roaming traffic:

• Reporting the real GWID instead of the virtual GWID allows sNS Operators to better troubleshoot passive roaming coverage issues with their fNS peers.

• Additional passive roaming metrics provided by this feature make the UL metadata more comprehensive, especially in case of reception of the same UL packet across several gateways belonging to different network operators.

Feature activation

This feature is automatically available after the platform upgrade to release 7.2. It only applies to serving Network Server (sNS) operators having activated the roaming-out use case, i.e., having devices roaming out to foreign networks.

Feature limitations

None.

Keep sNS's optimized radio parameters for roaming-out devices RDTP-15099

For proper passive roaming operation, sNS must know the fNS RF Region(s) to notify the roaming-out devices which RF channel plan should be used while roaming to fNS network.

TPE 7.1 introduced an automatic synchronization mechanism through TEX: each NS publishes their RF Regions on TEX, then TEX distributes those RF Regions to all sNS having roaming agreement with each fNS. To learn more about this automatic approach, see Integration with ThingPark Exchange for roaming and activation use cases.

Starting release 7.2, to avoid forcing sNS to use the fNS RF Region without any modification, sNS can now merge the relevant information from fNS RF Region with its own sNS "roaming-generic" RF Region:

• LRC supports a "roaming-generic" RF Region for each sNS operator and automatically copies the RF Region attributes present in this "roaming-generic" file into the RFregion of each fNS (coming from TEX).

• In TP7.2, LRC includes a default RF Region roaming template for each ISM band, denoted ALL-<ISM band>-DEFAULT-RFREGION-TEMPLATE. The default templates embed the recommended parameters for ThingPark's radio algorithms such as ADRv3, RX1/RX2 configuration, best-LRR selection, RX2 Optimization...

More details

Key customer benefits

Thanks to this feature, sNS network operators can easily use their optimized radio parameters for ADRv3, RX2 Optimization, NFR924 (etc..), even when their devices roam-out on other networks.

Feature activation

This feature is automatically available in ThingPark Enterprise 7.2.

Feature limitations

None.

Harmonized date/time formatting RDTP-2553

Starting release 7.2, the date/time formatting used by ThingPark Enterprise & Wireless Logger GUIs is changed as follows:

• Date format is YYYY-MM-DD, example: 2022-04-28.

• A relative date is displayed when applicable, e.g. Today, Yesterday.

• Time format is hh:mm:ss[.s] in 24-hour format, milliseconds are optional. Example: 12:00:32.214.

More details

Key customer benefits

Standard and more comprehensive representation of the date/time formats in GUI (including csv exports).

Feature activation

This feature is automatically available after the platform upgrade to release 7.2.

Feature limitations

None.

Enhanced LRC scalability to process millions of UL late packets RDTP-14605

This feature introduces a new flow control mechanism on the LRC core network to improve its capacity to handle millions of uplink late packets caused by temporary disconnection of the link between gateways and the core network.

More details

In this new mechanism, late uplink packets are stored by the LRC in Kafka until they can be processed. A new LRC thread is supported by this feature to read late UL packets from Kafka and dispatch them on the other LoRa threads.

Main considerations:

• Non-late uplink packets are prioritized over late packets. This is typically needed for class A devices when the UL packet needs to be timely answered by a DL packet over RX1/RX2 slots. For late UL packets, RX1/RX2 slots are already gone.

• Processing of late UL packets by the LRC core network must avoid flooding the customer's Application Servers.

Key customer benefits

Thanks to this feature, ThingPark system can absorb millions of late uplink packets being dequeued by LRR base stations after temporary gateway to core network backhaul outage.

Examples of supported scenarii:

• Global backhaul network outage between BS and core network (e.g., 3G/4G outage), disconnecting several thousands of gateways during a few hours.

• Core network issue (e.g., datacenter issue without core network geo-redundancy), disconnecting all the gateways of the platform (up to 50K gateways) for a few minutes.

In both examples, assuming that the ThingPark platform runs at its maximum E2E capacity of 1500 messages/sec, a few millions of uplink frames will be dequeued by gateways and need to be seamlessly & reliably processed by the core network.

Additionally, the flow control mechanisms brought by this feature guarantee that Application Servers do not get flooded/overloaded by too many late uplink frames after the service's recovery.

Feature activation

This enhancement is activated by default after the platform's upgrade to release 7.2.

To deactivate it, set [kafkalateul].enable=0 in custom lrc.ini file.

Feature limitations

None.

Support up to 200 devices sharing the same DevAddr RDTP-19004

Prior to release 7.2, the maximum number of devices sharing the same DevAddr is limited to 20.

Starting TP7.2, the LRC can serve up to 200 devices sharing the same DevAddr without negative impact on system performances, thanks to the optimized DevAddr collision management introduced by this feature.

More details

Key customer benefits

Thanks to this feature, ThingPark Subscribers can deploy many more devices (x10) using dedicated NetIDs that have small DevAddr ranges (e.g., type-6 NetID).

Example (for a type-6 NetID)

• Maximum number of devices in TP7.1: 2^10 * 20 = 20 480 devices.

• Maximum number of devices in TP7.2: 2^10 * 200 = 204 800 devices.

Additionally, deployments of more than 20 ABP devices sharing the same DevAddr becomes possible with this feature.

Feature activation

This enhancement is deactivated by default. To configure the maximum number of devices sharing the same DevAddr, the following systemwide parameter should be configured in lrc.ini:

[fdb]
        maxDevEUIPerDevAddr (default = 20)

Note This parameter must be carefully configured according to each self-hosted TPE platform sizing segment.

Feature limitations

This optimization is limited to LoRaWAN® 1.0.x devices, LoRaWAN® 1.1 devices are out of scope.

Additionally, the maximum supported UL traffic load (in messages/sec) shall depend on the DevAddr collision probability:

• The current TPE SaaS limit of 1500 UL/sec + 300 DL/sec considers no more than 10 device collisions per DevAddr.

• In the worst case scenario of 100% DevAddr collision probability between 200 devices, the maximum supported traffic load should be limited to 150 UL/sec + 30 DL/sec.

Support type-7 NetID blocks RDTP-18143

Starting release 7.2, ThingPark administrators can use type-7 NetID assigned by the LoRa Alliance, besides other conventional NetIDs 0...6.

More details

To learn more about NetID types, see LoRaWAN® Backend Interfaces specification.

Type-7 NetID are typically assigned by the LoRa Alliance in blocks of 16 or 32 contiguous individual NetIDs.

Note

The notion of NetID block, introduced in TP 7.2, is not restricted to type-7 NetIDs: it may be also used for other types, provided that all the NetIDs within the block are contiguous.

To support NetID blocks in ThingPark, the NetID configuration is enhanced to reference a primary NetID + a DevAddr subnet:

• The primary NetID is the first NetID of the block, i.e., the NetID having the lowest hexadecimal value in the contiguous block. This primary NetID is the one used over backend interfaces for roaming (with peer NS) and OTA activation (with peer JS) flows. Additionally, only the primary NetID is reported to AS and displayed in WLogger for UL/DL packets exchanged via passive roaming.

• The DevAddr subnet defines the size the contiguous block.

Example The FE0010/20 DevAddr subnet expresses the FE0010-FE001F pool of DevADDRs that is a superset associated to a block of 16 contiguous type -7 NetIDs.

Note

All the NetIDs in the block are used in the DevAddr allocation process, thanks to the DevAddr subnet (also known as DevAddr pool).

Key customer benefits

Type-7 NetIDs can be assigned by LoRa Alliance to any LoRaWAN® operator, without necessarily being a LoRa-Alliance member. Hence, the support of type-7 NetIDs in ThingPark greatly simplifies the NetID acquisition process for Operators willing to use roaming services.

Feature activation

The configuration of an individual type-7 NetID (i.e., not a block of contiguous NetIDs) remains unchanged compared to type 0/3/6 NetIDs supported from previous releases.

To configure a type-7 NetID block (also works for other NetID types), the platform administrator needs to:

• Configure the primary NetID of the block, by applying the same conventional process as configuring an individual NetID, e.g., from Cockpit for self-hosted TPE.

• Configure the DevAddr subnet, aka DevAddr pool block.

For self-hosted TPE, the platform administrator only needs to configure the primary NetID and the NetID block size in Cockpit. Then the DevAddr subnet will be derived accordingly by the system and displayed in Cockpit. To learn more, see TPE Administration and Troubleshooting guide.

Here is an example for a type-7 block of 16 contiguous NetIDs starting from NetID 0xE0 00 50 till NetID 0xE0 00 5F:

• Primary NetID shall be 0xE0 00 50.

• DevAddr subnet (aka DevAddr pool block) shall be 0xFE0028/21, as per the following illustration:

  • For the first NetID of the block (E0 00 50), the DevAddr subnet as per Backend Interfaces is 0xFE00280/25: 0xFE (type prefix) + 0b 0 0000 0000 0101 0000 (17LSB) → 0b1111 1110 0000 0000 0010 1000 0000/25.

  • Likewise, for the last NetID of the block (E0 00 5F), the DevAddr subnet as per Backend Interfaces is 0xFE002F8/25: 0xFE (type prefix) + 0b 0 0000 0000 0101 1111 (17LSB) → 0b1111 1110 0000 0000 0010 1111 1000/25.

  DevAddr subnet for the aggregated block of 16 NetIDs shall be FE0028/21

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

Feature limitations

The current implementation has the following limitations, all of them will be lifted in a future ThingPark release.

• Some blocks of 32 type-7 NetIDs (e.g., E00010, E00030, E00050, E00070...) yield non-contiguous DevAddr subnets; hence only a DevAddr subnet corresponding to a 16-NetID block can be configured in ThingPark to allocate DevAddr to OTAA devices.

• If an OTAA device is activated over a third-party external Join Server (JS), and the device's home network server uses a NetID block (type-7 or not), the exact device NetID within the block may not be known to this JS – only the primary NetID would be known. Hence, the NetID sent to the device in the Join-Accept may not match the NwkID part of the assigned DevAddr.

Note

This limitation does NOT apply to ThingPark Activation service (TPA), since the exact device NetID is derived by TPA from the allocated DevAddr block, regardless of the primary NetID initially set during the automatic claim process.

Enhanced configurability of alarm notification emails RDTP-18480

Prior to release 7.2, an administrator may define the list of email recipients for devices and base station alarms through the Settings panel, by directly providing the email address in a free-text field.

Starting release 7.2, the configuration of email recipients for device and base station alarms is enhanced as follows:

• An administrator of the TPE subscription can activate/deactivate email notifications for device and/or base station alarms (with a given minimal severity) for any user account.

• An end-user without administrator role can activate/deactivate email notifications for device and/or base station alarms (with a given minimal severity) for their own account.

• An administrator of the TPE subscription can additionally define free-text emails (not linked to existing user accounts) as email alarm recipients, through the "Settings" panel > "Alarms" widget.

More details

Here is an example of the email notification widget added to the User profile page.

Key customer benefits

This feature improves the user/administrator's experience during the configuration of email recipient list for device and base station alarms.

• Thanks to this enhancement, self opt-in/out by non-administrators becomes possible, without requesting administrator's help.

• Administrators can easily map email recipient to user accounts, without losing the possibility to define free emails to send alarm emails to third party monitoring systems.

Feature activation

This feature is automatically available after the platform upgrade to release 7.2.

Free email addresses registered for alarm notifications and matching existing users' email addresses are automatically migrated by the system to the new framework, i.e., the related settings are directly visible under each User's profile.

Feature limitations

Domain restrictions do not apply to free email addresses configured by administrators under "Settings" > "Alarms". In other words, all the alarms matching the minimum severity will be notified by email to the recipients regardless of the domain assignments related to the underlying devices or base stations.

To learn more about administrative domains and domain restrictions, see Multi-tenancy within the same subscription (RDTP-8479).