New features

This page cumulates all the new ThingPark Enterprise features brought by the different 8.0.x software releases. See the 8.0 changelog to know more about the split of those features per maintenance release.

The features described in this page are common to SaaS and Self-hosted ThingPark Enterprise products.

Enriched configuration of Basic HTTPS connections RDTP-11863

The following enhancements are added to basic HTTPS type of connections towards external application servers:

• Each connection may be configured with several destination URLs. When this is the case, the routing strategy can be defined as one of the following options:

  • Sequential: The packet is transmitted to the first destination of the ordered list, then it is attempted on the following URLs only in case of transmission failure on the preceding URL of the ordered list.
  • Blast: each uplink packet is sent to all the destination URLs.

• Support port-based routing, allowing to route uplink traffic according to the LoRaWAN Fport included in the uplink packet. This feature offers segregated routing/processing of the LoRaWAN traffic by multiple applications.

• The maximum timestamp deviation for tunnel interface authentication now is configurable in the user interface. This parameter defines the maximum allowed deviation between the timestamp set by the application when the downlink request is generated, and the time of reception of the downlink request by the network server.

• The URL used to send downlink packets to this connection is now displayed in the detailed page of each basic HTTPS connection.

More details

Key customer benefits

Enhanced user experience + additional flexibility using HTTPS connections.

Feature activation

This feature is automatically available after the upgrade to release 8.0.

HTTPS connections created from previous releases remain unchanged after the upgrade. It is up to the Connection manager to manually edit the connection details if they want to add several destinations or support port-based routing.

Feature limitations

Not applicable.

Improved monitoring of the device's battery history RDTP-17339

Prior to release 8.0: the user interface displays only the last reported battery level for each LoRaWAN device.

Starting release 8.0: in addition to the last reported battery level, the following information is available in the user interface, for battery-powered LoRaWAN devices:

• The estimated delay until the battery should be recharged/replaced.

  

• The date when the battery was recharged/replaced.

• The battery usage history graphs over the last 3 months, 6 months and 1 year.

More details

Key customer benefits

Improved monitoring of battery-powered devices, including the ability to estimate the remaining battery lifetime by extrapolating the history of reported battery levels.

Feature activation

This feature is automatically available after upgrading to release 8.0.

Feature limitations

Not applicable.

Device management UI/UX enhancements RDTP-16304

Release 8.0 brings the following UI/UX enhancements regarding the device management aspects:

• Adding devices without connections: It is now possible to add new devices or multicast groups without associating them with any Connection.

• Enhancements related to sending downlink packets: It is now possible to send encrypted downlink payloads, which is relevant for devices configured with the end-to-end encryption mode and AppSKey is only known to the Application Server. In this case, the downlink frame counter must be entered by the user in addition to the encrypted payload and the frame port.

  Additionally, the "Send downlink" feature is enhanced to allow sending downlink packets in confirmed mode (that is to say, requesting an acknowledgement from the device) as well as flushing the downlink queue for class A devices.

  

• Multicast groups: AppSKey is now optional when adding new multicast groups.

More details

Key customer benefits

Enhanced user experience and improved operational efficiency:

• Test devices may be added to the system without associating them with any connection. This enhancement removes the need to create a dummy connection if the device is temporarily dissociated from all the real connections.

• Additional options are now supported when users send downlink packets through the user interface.

Feature activation

This feature is automatically available after the upgrade to release 8.0.

Feature limitations

It is currently not possible to send encrypted downlink payloads to a multicast group created without AppSKey.

Enhanced MongoDB replication model RDTP-19911

Prior to release 8.0, the high availability architecture of the MongoDB cluster was based on the Primary/Secondary/Arbiter (PSA) architecture, running a MongoDB version older than 7.0.

Starting release 8.0, MongoDB is upgraded to version 7.0 and the architecture now uses the Primary/Secondary/Secondary (PSS) mode recommended by MongoDB. To learn more, see the MongoDB article about Three member replica sets.

More details

Note for self-hosted deployments

To convert an arbiter node into a secondary replica node, the additional computational resources are greatly optimized thanks to the new MongoDB data model brought by RDTP-21050 in this same ThingPark release.

Key customer benefits

Enhanced high availability with zero-touch recovery in case of node outage:

• Improved security/resilience: Data remains replicated over 2 nodes when the third node becomes unavailable. This is not the case of PSA mode if the primary or the secondary node disappears, since the arbiter node cannot host data.

• PSS mode offers better cluster performance than PSA: to learn more, see Performance issues with PSA replica sets.

  note

  Earlier ThingPark releases allowed mitigating this performance issue with the parameter enableMajorityReadConcern, which is no longer supported by MongoDB starting v5.0; constituting another strong driver to abandon the PSA architecture with the use of MongoDB v7.0.

Feature activation

The migration to MongoDB 7 + cluster reconfiguration to PSS mode is executed during the migration to release 8.0.

Important prerequisite

Self-hosted deployments using high availability architecture must ensure that the sizing of the third node (previously used as an arbiter) meets the requirements described in the Sizing hardware.

Feature limitations

Not applicable.

Allow managing domains, user accounts and service accounts through API RDTP-19650

Prior to release 8.0: managing domains, user accounts and service accounts is only possible through the user interface.

Starting release 8.0: besides the user interface, it is now possible to manage domains, user accounts and service accounts through the OSS API.
To learn more about the new API, see Subscriber administration.

More details

Key customer benefits

This feature offers the following benefits to ThingPark Enterprise administrators:

• Better integration with the customer's business applications.
• Better experience, allowing bulk management through API scripts.

Feature activation

This feature is automatically available after upgrading to release 8.0.

Feature limitations

Not applicable.

Use of distroless containers RDTP-22478

Distroless containers are a minimalist approach to building Docker containers, where only the essential files required to run an application are included. This contrasts with traditional containers that often include a full Linux distribution with many extra packages and utilities.

More details

Key customer benefits

Using distroless containers offers a wide range of benefits:

• Improved security: with fewer components and libraries, the attack surface of the container is drastically reduced, limiting the potential vulnerabilities that could be exploited by attackers. This improves security as there are fewer opportunities for vulnerabilities within the image, reducing the risk of malicious code being injected or security breaches. Since there are fewer components, there’s less to maintain or update in the container, and fewer packages needing to be patched for security vulnerabilities.

• Smaller image size, by removing unnecessary libraries, binaries, and tools found in a full Linux distribution. This means faster pull and push times, reduced storage needs, and more efficient use of bandwidth.

• Performance optimization: by stripping down everything except what is needed for the application, resource consumption is minimized. Hence, containers become more efficient, requiring less memory and CPU and offering faster startup times.

Feature activation

This feature is automatically available in ThingPark 8.0.

Feature limitations

In release 8.0, applications that could not use distroless mode for whatever technical constraints use the debian-slim mode instead, which is still better than the traditional container mode.

OS upgrade to AlmaLinux 9 RDTP-21595

To improve the system security, the operating system is upgraded from AlmaLinux 8.9 to AlmaLinux 9.4 in ThingPark 8.0.

More details

Key customer benefits

Security enhancement, onboarding the latest patches to ensure the utmost system protection.

Feature activation

The OS upgrade is executed during the upgrade to ThingPark 8.0.

Feature limitations

Not applicable.

LRR support password personalization from the GUI RDTP-22321

Prior to release 8.0:

• The default password of the LRR support account can only be changed from the local console (also known as Suplog), for LRR version 2.8.39 onwards.

• If the support password is changed locally via Suplog, the user is asked to enter its new password every time they want to open a remote session to the LRR from the ThingPark user interface.

Starting release 8.0:

• The BS manager may personalize the support password during the BS provisioning step on the user interface:

  

• Additionally, the BS manager may change the current support password at any time, either by API or from the Advanced tab of the base station's detailed page:

  

• Whenever the password is changed from the BS management interface (or by API), the new password is automatically stored by the back-office so that the user is not requested to enter it again every time a new remote session is initiated.

More details

Key customer benefits

Besides the security enhancement brought by the ability to personalize the default password of the LRR support account, this feature brings operational gains to ThingPark base station managers:

• Users may change passwords in bulk for all their base stations, through API scripts.
• The personalized password is memorized by the system, enhancing the overall user experience during remote access.

Feature activation

This feature is automatically supported for base stations running the LRR packet forwarder with starting version 2.8.39. It is not supported for base stations running Basics Station packet forwarder.

Feature limitations

When restoring an LRR backup, the support password in use at the time of the backup is restored. In this case, the password stored on the server may be no longer valid and must be manually entered by the user when opening a remote session from the user interface.