New features specific to self-hosted deployments
This page cumulates all the new ThingPark Enterprise features brought by the different 8.0.x software releases, which are specific to self-hosted deployments (i.e. not applicable to SaaS). See the 8.0 changelog to know more about the split of those features per maintenance release.
Platform compaction RDTP-21050 RDTP-18325
The scope of these features is to rework the MongoDB data model to reduce its footprint and offer higher capacity for the existing self-hosted sizing profiles.
-
RDTP-21050 introduces the time series model. Thanks to this new data model, the MongoDB footprint is divided by three for a given target capacity.
-
RDTP-18325 optimizes the hourly/daily aggregation of the base station's system load and backhaul statistics.
More details
Key customer benefits
CAPEX/OPEX savings without compromising the system performance.
The gains brought by these enhancements are reflected in the sizing requirements by higher system capacity for each sizing profile, in terms of maximum number of devices, base stations and maximum number of packets/second.
This footprint reduction brings substantial savings to the platform's hosting cost, significantly reducing the total cost of ownership (TCO).
Feature activation
The features described above are automatically activated after upgrading to release 8.0.
However, to simplify the migration process and avoid too long service disruption during
the upgrade maintenance window, only the LoRaWAN traffic history of the last 7 days preceding
the upgrade is kept after upgrading.
Feature limitations
To optimize Wireless Logger's performances in the new MongoDB data model, starting release 8.0, users can see the traffic belonging to their own devices but they no longer see the roaming traffic forwarded by their gateways to their roaming partners, also known as fNS roaming traffic.
SNMP v3 for platform and service monitoring RDTP-23193
Starting TPE 8.0, platform administrators may choose between version 2 and version 3 of the Simple Network Management Protocol (SNMP) to monitor the TPE system and services:
- SNMP v2 offers basic network monitoring and management features.
- SNMP v3 provides additional advanced security with authentication and encryption. The configuration supports up to three users.
To learn more, see SNMP monitoring.
This feature is not relevant for self-hosted deployments over kubernetes, since the service monitoring is directly done from the kubernetes cluster.
More details
Key customer benefits
SNMP v3 is more secure than SNMP v2, as illustrated by the following table:
| Feature | SNMP v2 | SNMP v3 |
|---|---|---|
| Authentication | Community string | Username + HMAC |
| Encryption | No | Yes (AES) |
| Message Integrity | No | Yes |
| Access Control | Basic | Role-based |
Feature activation
System and service monitoring may use different SNMP version, if needed by the customer. For instance, it is possible to configure system monitoring to use SNMP v3 while keep SNMP v2 for service monitoring, or vise versa. To learn more, see SNMP monitoring.
Feature limitations
This feature does not impact device and base station alarm traps, which remain in SNMP v2.
Support BACnet protocol via Node-Red RDTP-23677
Starting self-hosted ThingPark Enterprise 8.0, a BACnet flow is natively embedded in Node-RED. It allows LoRaWAN sensors to automatically expose data inside a built-in BACnet server in a plug and play mode., leveraging the rich set of payload drivers offered by ThingPark.
The mapping of LoRaWAN sensor data into BACnet objects is fully automated, without any manual action from the user. Nevertheless, users may customize this automatic mapping to better fit their deployment constraints.
To learn more about using BACnet in self-hosted deployments, see Using BACnet.
More details
Key customer benefits
Thanks to this feature, ThingPark Enterprise users can integrate their self-hosted platforms with their building automation systems, leveraging the widely-used BACnet protocol with minimal operational efforts.
Feature activation
To use BACnet protocol, a Node-RED connection must first be defined as described in Adding a Node-RED connection. Then, the BACnet flow must be loaded in Node-RED as described in Using BACnet.
Feature limitations
-
In a high-availability deployments, the BACnet flow runs on the first node only. If this node fails for any reason, the BACnet flow will be interrupted until this node is operational. Nevertheless, uplink data is not lost while node-1 is down, thanks to the resilience offered by the internal highly-available kafka cluster.
-
Sending downlink commands to LoRaWAN devices over BACnet is not yet automated in this release.