New features

This page cumulates all the new ThingPark Enterprise features brought by the different 8.1.x software releases. See the 8.1 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.

Embed virtual device probe in base stations RDTP-3399

Starting release 8.1, base station managers may enable RF probes on their base stations. An RF probe acts as a virtual device embedded in a base station, making the BS act as a device and send periodic uplink frames that are received by surrounding base stations.

The goal of these uplink frames is to test the RF quality of the LoRaWAN network and detect any potential RF disfunction on either the transmitting or the receiving base station(s). The deterministic nature of the RF probe traffic makes it easier to identify radio issues without being impacted by the randomness of the LoRaWAN traffic generated by real devices.

RF probe details are visible on the user interface, in the RF probe tab of the base station details.

Additionally, the RF probe traffic is visible in Wireless Logger, by selecting LoRaWAN RF probes from the top right of the screen.

More details

• The subscriber sees the traffic sent by his RF probes, received by any LoRaWAN base station without any restriction. If the authenticated user has domain restrictions, the traffic is visible only for RF probes matching his domain restrictions.

• The subscriber does not see the RF probe traffic from foreign base stations, even when received on the subscriber's own base stations.

RF probes have the following characteristics:

• The virtual device associated with each RF probe uses the ABP mode in class A without any downlink traffic and no MAC commands.

• The DevEUI, DevAddr and security keys of each probe are automatically assigned by ThingPark.

  note

  To easily identify the DevEUI corresponding to each base station, the probe DevEUI is prefixed by F0-3D-29-01 followed by the LRR-ID of the base station.

  Example: For a base station having LRR-ID 10-00-47-30, the probe's DevEUI is F0-3D-29-01-10-00-47-30.

• Uplink traffic uses the unconfirmed mode. The frame payload includes the LRR-ID of the emitting base station.

• Aspects of the uplink packets sent by each RF probe (configurable at RF Region level):

  Aspect	RF Region parameter	Default setting
  Periodicity	probeInterval	1 packet every 24 hours
  Tx Power	probeTxPower	set to the maximum allowed end-device EIRP in the country of operation (for instance, 16dBm in EU868)
  Data Rate	SF range is configurable by probeSFmin and probeSFmax	random selection from the allowed data rates (spreading factors) used by ThingPark ADR
  Logical Channels	Channel Mask is configurable by probeChannelMask	random selection from the list of activated RF channels
  LoRaWAN FPort	probeFPort	1

  note

  When the BS has several RF antennas, packets are sent over the different antennas using a round-robin algorithm.

Key customer benefits

Thanks to this feature, base station managers can proactively check the RF transmission/reception quality of their LoRaWAN network without deploying physical RF probes.

1. Detect RF problems

   • Identify RF transmission issues on a given base station, when the quality of reception of its own probes by all its neighbor base stations gets degraded.

   • Identify RF reception issues on a give base station, when the quality of reception of all the RF probes transmitted by its neighbor base stations gets degraded.

   In either case, the degradation may be sudden (for instance, due to hardware failure) or progressive (for instance, due to environmental or aging factors).

2. Assess & improve network geolocation accuracy

   Sending periodic uplink packets from known geographic locations allows assessing the accuracy of the network geolocation feature, by comparing the derived location (estimated by the network) with the real location of the emitting BS; then fine-tune the geolocation algorithm accordingly.

3. In-depth network troubleshooting

   RF probes help diagnosing connectivity issues between base stations and the ThingPark core network. For instance, if a BS is disconnected from the core network but still sends RF probes that are well received by its neighbors, this indicates that the LRR application is still running properly on the base station, ruling out power failure or hardware crash issues and pointing out most-likely to a backhaul connection issue.

Feature activation

This feature is deactivated by default.

To activate RF probe on a given base station, go to the base station's detailed page, then RF probe tab then click ENABLE RF PROBE.

Once activated, the base station manager can associate the RF probe with one or several Connections where uplink packets should be sent to external Application Servers.

Feature limitations

This feature is supported only for base stations using ThingPark LRR packet forwarder (LRR version 2.8.36 or higher). It is not supported by Basics Station packet forwarder.

User action logs (audit trail) RDTP-15326 RDTP-24685

User action logs (also known as audit trail) are generated for all write operations and login/logout operations performed by user accounts and service accounts associated with the subscription. They allow tracking the following actions on all the relevant ThingPark resources:

• Login/logout, including errors
• Resource creation, including administrative commands created on existing resources, such as rebooting or upgrading a base station or updating its RF Region
• Resource update
• Resource deletion

A resource may be a Device, a Base Station, a Connection, a Multicast Group, a Subscription Configuration (for example a Domain), a User Account or a Service Account. The exact nature of the creation/update action is described in the httpRequestContent column of the exported csv file.

note

User accounts are identified by their email address, whereas Service accounts are identified by their Client ID.

User action logs are accessible only by users having the Administrator role. They can be directly downloaded from the user interface, under the Administration menu.

More details

Key customer benefits

This feature enhances both the security and the operability of ThingPark Enterprise.

1. Security & Compliance

   • Track user behavior: Helps detect unauthorized access or suspicious activity.
   • Supports compliance: Meets regulatory requirements (e.g., GDPR, HIPAA, ISO 27001).
   • Accountability: Clearly attributes actions to specific users or devices.

2. Operational Transparency

   • Clear history of changes: See who did what, when, and how — across devices or systems.
   • Debugging & troubleshooting: Simplifies root cause analysis when issues arise.
   • Reduces downtime: Faster diagnosis of system failures or misconfigurations.

3. Product Improvement & Support

   • Better customer support: Logs help replicate and resolve user-reported issues.
   • Data integrity assurance: Logs can show the system behaved correctly in key scenarios.

Feature activation

This feature is automatically available in release 8.1.

To export the user action logs from the user interface, click Administration from the left menu, then Control Panel, then go to USER ACTION LOG widget. Optionally set your filters to restrict the exported logs as needed.

Feature limitations

The following actions are not logged in the current release:

• Write operations on TPX IoT-Flow resources
• Token creation via the legacy DX-ADMIN API

UI/UX enhancements of the Device's Last 10 packets widget RDTP-19954 RDTP-24390 RDTP-13714

The "Last 10 packets" widget, available in the detailed page of each device, is significantly enhanced in release 8.1. It is now called Packet History.

• The last 10 MAC commands become accessible in this widget, even if they are not part of the most-recent 10 packets. They are displayed in decoded format.

  

• The MAC header of each packet is displayed in decoded format, allowing to easily check the ACK and ADR flags (among others). Additional details about each packet are also available such as the logical channel, RF frequency and the downlink delivery status.

  

• Live updates with auto-refresh every 10 seconds, removing the need for manual refresh.

  

• Clicking Show more directly sends the user to WLogger with the right DevEUI filter.

More details

Key customer benefits

Enhanced user experience for monitoring and troubleshooting device performances.

Feature activation

These improvements are automatically available after the upgrade to release 8.1.

Feature limitations

Not applicable.

Enrich the base station list with the RF Region of each BS RDTP-23646

Starting release 8.1, the RF Region of each base station is available as a new column of the list view and is also present in the exportable csv file.

More details

Key customer benefits

Enhanced UI/UX, allowing base station managers to easily audit the RF Region setting of their base stations and quickly identify any potential misconfiguration.

This feature may be particularly interesting for deployments involving multiple ISM bands or deployments having a mix of 8-channel and 16-channel base stations.

Feature activation

The new column is hidden by default to limit the table size. To show the RF Region column, the user should tick the RF Region checkbox as illustrated below:

The choice of columns to display is stored in the browser cache so the user does not need to set their preference again every time they login.

Feature limitations

Not applicable.

Display the remaining device/BS license in the Dashboard RDTP-21133

To allow non-administrators to know how many device and/or base station credits are still left in the current license, the count of remaining devices and base stations is now displayed in the main Dashboard, as illustrated by the following example:

More details

Key customer benefits

Enhanced user experience for non-administrators who cannot access the license details in the Control Panel page.

Feature activation

This feature is automatically activated in release 8.1.

Feature limitations

Not applicable.

Support downlink packet repetition in Multicast mode RDTP-24172

To improve the reception success rate of downlink multicast packets, the Application Server may need to send a given multicast payload several times with the same frame counter.

This capability is possible starting release 8.1, whereby AS may set a new query parameter repeated in the LRC-AS tunnel interface downlink API. When repeated =1 in the downlink POST request for a multicast group, the network server sends the downlink packet with the same frame counter that was used in the previous transmission to that multicast group.

note

It is the AS responsibility to repeat multicast frames via individual POST requests, the network server does not autonomously trigger such repetitions.

More details

Key customer benefits

Thanks to this feature, Application Servers sending multicast packets through the LRC-AS tunnel interface can leverage frame repetition to maximize the chances of conveying their payload to end-devices participating to a multicast group. As the different copies of the same multicast payload are associated with the same LoRaWAN frame counter, end-devices shall easily reject duplicate frames.

Feature activation

This feature is automatically available in release 8.1, but multicast repetitions are disabled by default. The repetition is explicitly requested by AS by setting the repeated query parameter to 1 (default value = 0).

To learn more about using this feature in LRC-AS tunnel interface API, see Downlink API V2.

Feature limitations

This feature is only supported over the LRC-AS tunnel interface V2 API: sending downlink multicast packets from the user interface or via TPX IoT Flow connections does not currently support repetitions.