New features specific to Self-hosted
Logo customization RDTP-17446
Starting release 7.2, self-hosted TPE administrators may use a custom logo instead of the default Actility logo.
More details
This custom logo shall be displayed by the TPE GUI, in the login page and in the top menu of the user interface after login.
Note "ThingPark Enterprise" logo replaces "Actility" logo on Cockpit's login page as well as DX-API documentation.
Key customer benefits
Thanks to this feature, ThingPark Enterprise distributors can white-label self-hosted TPE product.
Additionally, end-customers could display their own logo instead of Actility.
Feature activation
This feature is automatically available after the platform upgrade to release 7.2.
To change the default Actility logo, the platform administration should go to Cockpit > TPE Configuration > Logo:
Then click 
to change the
current logo.
Note The image should be in PNG format and its size must not exceed 50 kB. The recommended size is 300 x 100 pixels.
Feature limitations
None.
Increase the maximum number of authorized TPX connections RDTP-17463
Prior to release 7.2, the maximum number of TPX connectors (using IoT Flow engine) is limited to 5 for each self-hosted TPE platform.
Starting release 7.2, this limit becomes configurable in Cockpit.
More details
Note As each connection consumes hardware resources (CPU, RAM), this value should be set carefully in accordance with the platform's sizing profile. The recommended limit for each sizing profile:
-
Small (S): maximum 5 TPX connections
-
Medium (M) and Large (L): maximum 10 TPX connections
-
Extra-Large (XL) or higher: maximum 20 TPX connections.
A warning message is displayed in Cockpit if the platform administrator sets a value higher than the recommendation listed above.
To learn more about the different self-hosted TPE sizing profiles, see Sizing hardware on a self-hosted ThingPark Enterprise platform.
Key customer benefits
This feature brings additional configuration flexibility, allowing TPE administrators deploying large Self-hosted instances to leverage > 5 TPX connections towards their Application Servers.
Feature activation
This feature is automatically available after the platform upgrade to release 7.2.
The recommended limit for each hardware sizing profile is set by default (see Feature description section), it may be changed by the administrator through the parameter "Maximum IoT Flow connections", under TPE Configuration > Advanced settings.
Allowed range: [1, 30].
Note This field is displayed only when the IoT Flow feature is enabled under TPE Configuration > Feature settings.
Feature limitations
None.
Support Basics Station packet forwarder RDTP-18394
The support of Semtech's Basics Station packet forwarder in ThingPark, besides LRR packet forwarder, was already brought by ThingPark release 7.1. However, this feature was only available to TPE SaaS in release 7.1, due to some restrictions specific to Self-hosted deployments.
The scope of this enhancement is to lift the limitations related to Self-hosted deployments in release 7.2. Accordingly, gateways using Semtech's Basics Station packet forwarder can successfully connect to Self-hosted ThingPark Enterprise starting release 7.2.
More details
To learn more about using Basics Station in ThingPark, see the related release notes in TPE 7.1.
Note The minimal supported version of LoRa Basics™ station is 2.0.4.
Key customer benefits
Thanks to this feature, ThingPark users may easily connect their gateways to the ThingPark slef-hosted platform without waiting for the corresponding gateway manufacturers to integrate with ThingPark Long Range Relay (LRR).
While the LRR's advanced packet forwarder is highly superior to Basics Station (this latter only offers the basic functions as its name tells), the ThingPark's ability to openly integrate with all gateway models without exclusion lifts any potential entry-level barrier to adopting ThingPark.
Accordingly, ThingPark users may kick-off their ThingPark journey with any gateway model using either LRR or Basics Station, then switch to LRR packet forwarder for their industrial deployment.
Feature activation
This feature is deactivated by default in self-hosted TPE.
To activate the use of Basics Station, the platform administrator must enable it through Cockpit:
To learn more about Basics Station requirements for self-hosted TPE server, including port-opening prerequisites and HTTP hostname configuration, see Self-hosted TPE Administration guide.
Connecting a LoRa Basics™ station gateway to ThingPark
To connect a gateway using Basics Station to ThingPark, the following steps are required:
-
Install Basics Station packet forwarder on the gateway if it is not already present.
-
Configure the network interfaces of your gateway.
Note Unlike the LRR's SUPLOG offering a GUI to configure your network interfaces, Basics Station does not provide any such native terminal, so you should rely on the CLI commands provided by the gateway manufacturer to complete this configuration if the manufacturer does not support a GUI to do such configuration.
-
Configure the Basics Station, as explained in this topic of the user guide.
-
Provision your gateway in ThingPark Enterprise GUI, as explained here.
Feature limitations
Same limitations as described in TPE 7.1 release notes.
Additionally, the following limitations are specific to self-hosted TPE:
- Placing a reverse proxy (API gateway / WAF, etc.) in the Basics station to LNS flow is not possible because SSL client authenticate is used. As this authentication is part of the SSL handshake, the reverse proxy will not be able to terminate SSL.
Platform footprint optimization RDTP-17462
The scope of this feature is to optimize the self-hosted TPE hardware sizing requirements, especially RAM and CPU, thanks to the following technical enhancements:
-
Optimized aggregation of hourly/daily Base Station traffic.
-
Leverage of SSD disk performances to reduce RAM footprint requirements without compromising the overall system's performance.
More details
The new sizing requirements were validated by R&D benchmark tests simulating the peak supported traffic load for each sizing profile.
As an example, here is a comparison of the sizing requirements in self-hosted TPE 6.1 and 7.2, for Small (S) and Medium (M) profiles in VM-based deployment model (without Kubernetes):
| Small (S) Profile | TPE 6.1/7.1 | TPE 7.2 | Delta | |
|---|---|---|---|---|
| RAM (GB) | 15 | 7.5 | -7.5 (-50%) | |
| CPU | Minimum CPU score (2) | 22,000 | 16,000 | -6,000 (-27%) |
| Minimum CPU mark (indicative) (3) | 2,760 | 2,280 | -480 (-17%) | |
| Disk IOPS (write/s) | Average | N/A (1) | 45 | |
| Peak | 100 | 100 | = | |
| Disk IOPS (read/s) | Average | N/A (1) | 20 | |
| Peak | N/A (1) | 500 | ||
| Storage size (GB) (4) | 90 | 90 | = |
| Medium (M) Profile | TPE 6.1/7.1 | TPE 7.2 | Delta | |
|---|---|---|---|---|
| RAM (GB) | 22 | 12 | -10 (-45%) | |
| CPU | Minimum CPU score (2) | 30,000 | 23,000 | -7,000 (-23%) |
| Minimum CPU mark (indicative) (3) | 3,400 | 2,840 | -560 (-16%) | |
| Disk IOPS (write/s) | Average | N/A (1) | 60 | |
| Peak | 200 | 200 | = | |
| Disk IOPS (read/s) | Average | N/A (1) | 30 | |
| Peak | N/A (1) | 1000 | ||
| Storage size (GB) (4) | 110 | 110 | = |
(1) Not specified in self-hosted TPE 6.1/7.1 recommendations.
(2) CPU score can be assessed through ThingPark HW benchmark script, included in self-hosted TPE image distribution.
(3) Indicative CPU mark refers to the PassMark "Average CPU Mark" referenced by https://www.cpubenchmark.net/. This value is given as an indication to the range of CPU models required on standalone appliance for each platform sizing segment, the definite CPU sizing must be validated against ThingPark's min CPU score assessed through the HW benchmark script.
(4) Refers to available storage space. For instance, if RAID1 is used for a Small Segment, the platform must have two disks of 90GB each.
The complete set of hardware sizing requirements for self-hosted TPE 7.2 can be found at Sizing hardware on a self-hosted ThingPark Enterprise platform.
Key customer benefits
This improvement is part of the continuous optimization of the TPE footprint reduction for Self-hosted deployments. It brings major Total Cost of Ownership (TCO) gains to customers deploying ThingPark Enterprise on-premise.
The reduction of platform hosting costs is even more interesting when self-hosted TPE is deployed on private clouds, since it yields recurrent/OPEX savings.
Feature activation
This feature is automatically available after the platform upgrade to release 7.2.
Feature limitations
None.
Personalization of the URL lifespan related to system-generated emails RDTP-17611
Prior to release 7.2, the URL lifespan associated to the account activation email was hardcoded to 15 minutes.
Starting release 7.2, this lifespan becomes configurable in Cockpit.
More details
The following new fields are added in Cockpit:
-
User-initiated action lifespan (default = 15 minutes): Maximum time (in minutes) before an action request - notified to the user by email - expires, i.e., the URL included in the email becomes invalid. This parameter addresses the user's response to an action initiated by the user himself, e.g., forgotten password. Therefore, this lifespan is recommended to be short because it is expected that the user would quickly react to self-initiated actions.
-
Admin-initiated action lifespan (default = 60 minutes): Maximum time (in minutes) before an action request - notified to the user by email - expires, i.e., the URL included in the email becomes invalid. This parameter addresses the user's response to an action initiated by the administrator, e.g., account creation. Therefore, this lifespan is recommended to be long to allow admins to send e-mails for users that are currently offline.
Key customer benefits
Enhanced configurability and flexibility.
Feature activation
The lifetime configuration is added in the "Mail settings" section of the TPE Configuration of Cockpit.
Feature limitations
None.
Personalization of the traffic retention period RDTP-18577
Prior to release 7.2, the traffic history's retention period was fixed to 15 days for all the sizing segments. This retention period was not configurable by the self-hosted TPE administrator. Hence, it was not possible to retrieve the history of UL/DL packets older than 15 days.
Starting release 7.2, the retention period becomes configurable in Cockpit, it may be extended to 90 days for all sizing profiles.
More details
To personalize this configuration, a new field is added in Cockpit, see "Feature activation" section to learn more about configuring this new parameter.
Wireless Logger application offers the ability to export UL/DL packets in CSV format. The maximum number of exported packets now depends on the retention period configured by the administrator:
Maximum size of the CSV export is
10000 × (<traffic history retention period> / 15), for instance:
-
10,000 for 15 days
-
60,000 for 90 days.
Warning Extending the retention period beyond 15 days shall consume more hardware resources (RAM, Disk space); hence, it impacts the hardware sizing requirements.
TPE slef-hosted storage size is impacted by the traffic history retention period:
| Segment | Storage size for 15 days history | Storage size for 90 days history |
|---|---|---|
| Small (S) | 90 GB | 110 GB |
| Medium (M) | 110 GB | 190 GB |
| Large (L) | 130 GB | 290 GB |
| Extra-large (XL) | 170 GB | 540 GB |
| Double extra-large (XXL) | 520 GB | 2,620 GB |
Please contact your support team before changing the default retention period, to ensure your platform has the right hardware sizing level.
Key customer benefits
Thanks to this feature, self-hosted TPE platform administrators can extend the retention period of the LoRaWAN® traffic history and export their history for more than the last 15 days.
This enhancement is particularly interesting for countries where local regulations imply a minimum retention period, for instance 90 days for NBTC regulator in Thailand.
Additionally, the extended traffic history could be useful for traffic monitoring and advanced troubleshooting activities.
Feature activation
This feature is automatically available after the platform upgrade to release 7.2, but the default retention period remains 15 days.
To personalize the configuration, the platform administrator should configure the "Traffic history retention period" parameter in Cockpit, under "TPE Configuration" > "Advanced settings".
This parameter configures the retention period of LoRaWAN® uplink and downlink packets, expressed in days. Possible values are 15...90 days. The default value (15 days) is enough for a normal usage of ThingPark Enterprise.
Warning Extending the default value consumes hardware resources (RAM, Disk space), please contact your support team before any change.
Note This field is displayed for all sizing segments except extra-small, where the retention period is fixed to 7 days due to limited computation resources.
Feature limitations
None.