Skip to main content

New features

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

LoRaWAN relays (PoC) RDTP-18706 RDTP-20376​

A LoRaWAN relay is a device that forwards to the network uplink LoRaWAN frames received from trusted end-devices, by encapsulating them in its own frame payloads. Likewise, the relay receives encapsulated downlink frames from the network and forwards them to the appropriate end-devices after decapsulation.

LoRaWAN relays have a similar architecture to conventional LoRaWAN end-devices, with the addition that they support the Relay Protocol specified by the LoRa Alliance in TS011.

The main characteristics of a relay are:

  • Battery-powered
  • A relay can securely serve up to 16 end-devices.
  • Like any conventional device, a relay can use any LoRaWAN class (class A, B, C) and can use either OTAA or ABP activation modes.

caution

For end-devices to operate in relay mode, they must support the Relay Protocol specified by TS011 in their MAC stack, besides the standard LoRaWAN protocol.

To learn more about this feature, see Using LoRaWAN relays.

More details

Thanks to RDTP-20376, the content of relay-specific data is displayed in decoded format in Wireless Logger. This applies to:

  • The UpdateUplinkListReq/Ans MAC commands (exchanged between the network server and the relay to add a new end-device to the trusted list).
  • The ForwardUplinkReq (encapsulating uplink packets from end-devices) and ForwardDownlinkReq (encapsulating downlink packets towards end-devices). Those packets are always sent on Fport 226 (relay-specific port).

Key customer benefits​

LoRaWAN relays allow covering white spots with minimal cost, reducing the overall infrastructure CAPEX. They offer a reliable (and low-cost) solution to cover hard-to-reach sensors (e.g. located deep indoors or in basements) especially for smart metering use cases; eliminating the need to do costly drive-by operations to collect meter readings in white spots.

Moreover, from operational standpoint, relays are particularly useful in zones where it is not possible/practical to add pico or nano gateways, e.g. due to lack of power supply or backhaul facilities. Indeed, unlike conventional gateways, relays are battery-powered and use LoRaWAN's radio interface as backhaul solution.

Feature activation​

In the current release, a relay is provisioned in ThingPark like a normal device, following the conventional provisioning process described in the user guide.

note

In ThingPark 7.3, there is no special configuration required to allow a provisioned device to act as relay.

Feature limitations​

The PoC implementation has the following limitations that will be progressively lifted in upcoming ThingPark versions:

  • End-devices operating behind a relay must use class A + OTAA (Over-the-Air-Activation) modes. ABP activation mode will be supported in the next release. The end-device must complete its JOIN procedure through the relay.
  • Among the relay-specific MAC commands defined in the LoRaWAN technical specification TS011, the only pair supported in this release is UpdateUplinkListReq/Ans. Other MAC commands will be supported in the future.
  • Since the MAC command pair RelayConfReq/Ans is not yet supported, the relay mode must be locally activated in devices acting as relays.
  • Only the default WOR channel is supported since the MAC commands required to configure a second WOR channel are not yet supported in this release.

Alarm notification via IoT Flow connections RDTP-5254​

In previous releases, Base Station and Device alarms were notified to external parties either by email (both TPE SaaS and Self-hosted) or through SNMP traps (self-hosted TPE only).

Starting release 7.3, in addition to SNMP traps and emails, Base Station and Device alarms can now be reported via ThingPark X IoT Flow connections. ThingPark X IoT-Flow supports a wide range of professionally-supported cloud connectors towards the leading IoT platforms: AWS, Azure, ThingWorx, Thingsboard, Cumulocity, Yandex, Google... IoT-Flow also supports MQTT, HTTPS and AMQP protocols to setup any general-purpose connection towards third-party Application Servers.

More details

Example of the JSON documents reported through ThingPark X Iot-Flow

{
  "DevEUI_alarm": {
    "ID": 4,
    "State": 1,
    "CreationTime": "2020-09-09T18:14:56.49+02:00",
    "LastUpdateTime": "2020-09-09T18:25:24.49+02:00",
    "Occurrence": 1,
    "Acked": 0,
    "AddInfo1": "69",
    "DevEUI": "0018B20000001156",
    "CustomerID": "199983788",
    "CustomerData": {
      "loc": {
        "lat": "43.58081",
        "lon": "1.4421667"
      },
      "tags": [
        "tag1",
        "tag2"
      ],
      "doms": [
        {
          "n": "France/Paris",
          "g": "Site"
        },
        {
          "n": "Location",
          "g": "Vertical"
        }
      ],
      "name": "My device 1"
    }
  }
}
{
  "BS_alarm": {
    "ID": 102,
    "State": 1,
    "CreationTime": "2022-12-05T19:57:02Z",
    "LastUpdateTime": "2022-12-05T19:57:06Z",
    "Occurrence": 1,
    "Acked": false,
    "AddInfo1": "1",
    "LrrID": "100001C2",
    "PartnerID": "1100033327",
    "CustomerID": "1100033327",
    "BaseStationData": {
      "name": "My base station 1"
    }
  }
}

In ThingPark Enterprise user interface, since a base station may now be associated with one or several connections (for sake of BS alarm reporting), a new tab "Associated base stations" is now available in the detailed TPX Connection dashboard, similar to the "Associated devices" tab.

note

In self-hosted ThingPark Enterprise, besides TPX Connections, alarms can be also notified through the Node-RED connection.

Key customer benefits​

Thanks to this feature, ThingPark administrators can leverage the ThingPark X IoT-Flow connections to send alarms to their NOC/supervision systems. Additionally, ThingPark end-users can enrich the integration of their business applications with ThingPark by pushing device alarms on the same data-path as regular applicative uplink reports.

From the rich set of connectors supported by ThingPark X Iot-Flow, customers can choose broker-based connector types like MQTT or Kafka to implement publish/subscribe mechanisms for alarm notifications instead of periodic polling on ThingPark APIs.

Feature activation​

The feature is deactivated by default.

It can be activated through the ThingPark Enterprise user interface:

  • At TPX Connection level: activate alarm reporting for Devices and/or Base Stations:

  • At Device level: Associate your target TPX Connection(s) with your devices, if not already associated.

  • At Base Station level: Associate your target TPX Connection(s) with your base stations, from the "Advanced" tab, "Alarms Settings" widget:

Feature limitations​

Reporting of Device and/or Base Station alarms over "Basic HTTP" type of connections is not supported.

Simplified integration with ThingPark APIs RDTP-16597​

As an end-user having a ThingPark Enterprise subscription:

  • Prior to release 7.3, the only REST API available to manage ThingPark resources is the DX-API.
  • Starting release 7.3, besides DX-API, end-users can access the complete set of ThingPark APIs (also known as OSS-API). The user may leverage both OSS & DX APIs through a unified authentication flow, based on Service Accounts created by the TPE administrator.
Important note

OSS-API is the recommended API for all ThingPark users, DX-API becomes legacy starting release 7.3.

OSS-API endpoints are significantly richer than DX-API, allowing customers to fully exploit the latest improvements brought in each ThingPark release.

More details

Main changes:

  1. Support of Service Accounts to access OSS/DX APIs: Service Accounts rely on the "client credentials flow" defined by OAuth V2 OpenID Connect standard, i.e. each Service Account is associated with a client-ID and a client-secret.

  2. A new OAuth2 authentication flow for DX-CORE, based on Service Accounts : This new flow is directly managed by ThingPark's built-in Identity Provider, instead of using DX-AMIN. To learn more, check-out the DX-CORE documentation.

    note

    The legacy DX-CORE authentication flow through DX-ADMIN is now deprecated.

    The use of the new authentication flow is strongly recommended, although it remains optional in release 7.3 to maintain backward compatibility with legacy authentication flows used by some customer applications.

To learn more about OSS-API, see the OSS-API swagger documentation.

Key customer benefits​

Thanks to this feature, end-users can now access the most complete set of endpoints provided by OSS-API, instead of relying on the legacy DX-CORE API. OSS-API is the recommended API for end-users, administrators and application developers integrating ThingPark with their business applications.

Additionally, users have a single/unified authentication flow to access both DX and OSS APIs; i.e. once authenticated, the user has access to any endpoint from both OSS-API and DX-CORE using the same OAuth v2 access token.

Feature activation​

Creating and managing Service Accounts can be done by TPE administrators from the TPE User Interface.

Feature limitations​

Not applicable.

Improved monitoring of the OTA activation procedure RDTP-19333​

This feature enhances the monitoring of the Over-the-Air Activation, also known as "join" procedure:

  1. A new device alarm “join loop detected” (alarm number 017) is raised by the network in case an OTAA device sends a series of successful Join-Requests (answered by Join-Accepts) without sending regular uplink frames. The alarm severity depends on the count of consecutive join attempts. To learn more about this new alarm, see the user guide.

  2. More comprehensive transitions between the device health states, to reflect the successful completion of the "join" procedure.

More details

  • Prior to release 7.3: the OTAA device's health state becomes "Active" once the network receives the first valid Join-Request message from this device.

  • Starting release 7.3: in order to better reflect problems occurring during the "join" procedure, the device's health state becomes "Active" only upon reception of the first valid regular uplink packet (after the transmission of the Join-Accept by the network). Accordingly, a device entering a Join-Request/Join-Accept loop remains in the "Initialization" state.

    The following diagram illustrates the state transitions starting release 7.3:

    note

    A previously-active OTAA device reverts back to "Initialization" state when it sends a new Join-Request message to the network.

Key customer benefits​

Thanks to this feature, ThingPark Device Managers can quickly identify and fix OTAA devices having problems to successfully complete their activation process. This may be the case of misbehaving devices (due to device bug), devices unable to receive downlink packets due to RF coverage issues or even devices with an almost-empty battery.

Feature activation​

This feature is automatically available in ThingPark 7.3.

Feature limitations​

Not applicable.

Suspension of the device connectivity RDTP-2308​

Prior to release 7.3, it was not possible to temporarily suspend the connectivity of a specific device without completely deleting it.

Starting release 7.3, it is possible to suspend and resume the connectivity of any device by the device manager.

More details

When a device is suspended, the network automatically sends the DutyCycleReq MAC command to the device, to configure its transmission duty cycle to the lowest value. This mechanism has two benefits:

  • Minimize the pollution impact of the suspended device on the radio interface
  • Preserve the device battery while its connectivity with the network is temporarily suspended.

By default, the maximum uplink duty cycle sent to suspended devices in the DutyCycleReq MAC command is set to 0.00305%.

note

A suspended device may be resumed at any time without requiring it to initiate a new "join" procedure. When a suspended device is resumed, the network sends another DutyCycleReq MAC command to reconfigure the device with the normal duty cycle.

Key customer benefits​

Thanks to this feature, ThingPark device managers can properly suspend the network connectivity for their selected devices, while preserving their battery lifetime and limiting the interference impact caused those suspended devices to the radio interface.

Feature activation​

Devices may be suspended through the ThingPark Enterprise user interface:

  • In the detailed Device dashboard:

  • From the device list view:

The same applies to resuming a suspended device.

Feature limitations​

Not applicable.

[Wireless Logger] Display Join-Accept messages in decoded format RDTP-15298​

In previous releases, the Join-Accept message was displayed in Wireless Logger in encrypted format, like it is sent over the air to the end-device (i.e. encrypted by the device's AppKey).

Starting ThingPark 7.3, Wireless Logger displays Join-Accept packets in decrypted/decoded format.

More details
Note

For roaming-in devices, since the visited network cannot decrypt the Join Accept, the Wireless Logger of visited network does not display the raw MAC content of the Join-Accept message.

Key customer benefits​

Easier troubleshooting of join-related problems:

  • Device managers can verify which configuration is sent by the network to the device.
  • If the device manager knows the device's secret key (AppKey), they can derive the LoRaWAN session keys from the Join-Request and Join-Accept contents. This could be useful for debug purposes.

Feature activation​

This feature is automatically activated for ThingPark 7.3 platforms.

Nevertheless, all the Join-Accept messages sent before the upgrade to release 7.3 remain displayed in encrypted format by Wireless Logger.

Feature limitations​

For devices activated over an external Join Server, since the home Network Server cannot know the JoinNonce and the MIC fields included in the Join-Accept message, Wireless Logger displays FFFFFF and FFFFFFFF respectively for these fields.

[Wireless Logger] More comprehensive icons/colors RDTP-18975​

This feature brings a remake of Wireless Logger icons and colors to improve the user experience.

Uplink packets use the icon while downlink packets use the icon.

More details

Icons are enriched to represent the most useful status of each packet and save analysis time for Wireless Logger users.

  • For uplink packets:
    • Late packets (buffered by the base station) are displayed with the letter L in their icons.
    • Packets using passive roaming are displayed with the letter R in their icons.
    • For devices associated with basic HTTP application servers, delivery failure to one or several destinations is represented with a colored dot.
  • For downlink packets:
    • Multicast packets are displayed with the letter M in their icons.
    • Packets using passive roaming are displayed with the letter R in their icons.
    • Downlink packets sent in response to repeated uplink frames use a special icon:
    • Downlink packets not effectively sent by the base stations are represented by a red dot.

Hovering over each icon displays a short description of its significance. To learn more, see the Wireless Logger user guide.

Key customer benefits​

Better user experience and faster identification of problematic behaviors.

Feature activation​

This feature is automatically available starting release 7.3.

Feature limitations​

Not applicable.

New color conventions for UL/DL packets in Network Manager RDTP-19585​

Instead of using green and orange colors for uplink and downlink graphs respectively, new color conventions are used as of release 7.3, to avoid misinterpreting green as good and orange as a warning.

More details

Additionally, the color legend of RF metrics (SF, ESP, SNR, RSSI) is updated based on a diverging palette (ranging from green to red) to better represent the metric's value.

Key customer benefits​

More intuitive user interface.

Feature activation​

This feature is automatically available starting release 7.3.

Feature limitations​

Not applicable.

Configuration of the motion indicator for each device RDTP-14093​

Starting release 7.3, the motion indicator of each device can be customized, independently from the activation status of the network geolocation feature.

The motion indicator defines the device's mobility profile: near static, walking speed, bike speed, vehicle speed or random.

More details

ThingPark's core network needs to know the motion indicator of each device in order to adapt its algorithms accordingly:

  • Adjust the Kalman filter configuration used by ThingPark's LocSolver for TDoA/RSSI geolocation.
  • Adapt the sliding window size used by the network server's radio algorithms for the selection of which base station is best for routing the downlink packets to each device. This selection also affects the optimum RF Region configuration for each device, since the device inherits the RF Region configuration of its downlink best-LRR.

Key customer benefits​

Thanks to this feature, the network server can efficiently select the optimum base station for downlink traffic routing when the device is covered by several base stations, according to the device's mobility profile:

  • For stationary devices (associated with "near static" motion indicator), the selection algorithm relies on long-term averaging of the RF metrics of each base station, to make the best decision for each individual device.
  • For moving devices (motion indicator is different from "near static"), longer-term average of the reception history cannot be reliable. Therefore, the sliding window size is set to 1 (i.e. only the last packet) for those devices.

Feature activation​

This feature is automatically available starting release 7.3.

By default, the motion indicator of each device is inherited from the setting of its model profile; but the user may change it at any time either during the initial creation step or by updating existing devices.

Feature limitations​

Not applicable.

Enrichment of the device dashboard RDTP-16775 RDTP-16536​

Starting release 7.3, the detailed dashboard of each device is enriched to provide additional RF metrics and simplify daily Operation & Maintenance tasks.

More details

  • In the "Status" widget, the following RF metrics are added:

    • Average SNR, averaged over the last 5 uplink packets.
    • Average ESP (Estimated Signal Power), averaged over the last 10 uplink packets.
    • Long-term PER (Packet Error Rate), computed over the last 50 distinct uplink packets.
    • Instant PER (Packet Error Rate), computed over the 2 last distinct uplink packets.

  • In the "Radio Traffic History" widget:

    • The daily/hourly count of late uplink packets is displayed besides on-time uplinks.

  • In the "Radio Statistics" widget:

    • The previously-called PER tab is now renamed "Received / lost" and shows the hourly/daily repartition of received vs. lost uplink packets.

    • It is now possible to show the daily/hourly average of SNR/RSSI/ESP metrics for a specific base station. By default, "any" means that metrics consider the best received packet regardless of the base station receiving it.

Key customer benefits​

Thanks to the additional RF metrics, ThingPark Enterprise users have more insight on the performance of each device, including a more comprehensive representation of the uplink packet loss. Hence, this feature contributes to reducing the supervision & troubleshooting efforts spent by ThingPark device managers.

Feature activation​

This feature is automatically available starting release 7.3.

Feature limitations​

The count of lost uplink packets is not available for the period running a software version earlier than 7.3. Therefore, the “Received / Lost” graph is empty for the period before the software upgrade.

Report to AS the count of missing UL packets RDTP-20502​

As seen from the previous feature, it is now possible to clearly identify the count of missing uplink packets in ThingPark Enterprise user interface. Additionally, RDTP-20502 adds this same capability in the uplink frame reports sent by the network server to customer's application servers.

More details

A new attribute LostUplinksAS is added in the Uplink Frame Reports. It represents the count of lost uplink frames for this device, since the last UL report to AS.

  • When LostUplinksAS > 0: some uplink frames have been lost and the field provides the number of those lost frames.
  • When LostUplinksAS = 0: no uplink frames have been lost since the last report for this device.
  • When LostUplinksAS < 0: some uplink frames were initially thought by the network to be lost. but were finally received late (due to backhaul connection issues between the base station and the core network). Such late frames were reported with a positive count in the LostUplinksAS of a previous report. Hence, they are reported again with a negative count to allow AS to easily fix the aggregated count over the required aggregation window by summing the values of all the LostUplinksAS received in this same window.

To learn more about this new attribute, see the detailed description of Uplink Frame Reports (DevEUI_uplink) in the description of the LRC to AS tunnel API.

Key customer benefits​

Simplified integration with customer's application servers.

Feature activation​

This feature is activated by default, it does not require any specific activation procedure. For self-hosted deployments, the feature is available starting release 7.3.1.

Feature limitations​

Not applicable.

UI/UX enhancements RDTP-16693​

This feature brings several enhancements to the ThingPark Enterprise user interface, thus enhancing the user experience.

More details

The following enhancements are available starting ThingPark Enterprise release 7.3.2:

  • Ability to open several resources (Base Stations, Devices, Multicast Groups, Connections, Domains, Domain Groups, User Accounts, Service Accounts etc.) at once in several browser tabs to compare them and analyze their differences.

    • From the list view, hovering on the resource's link displays a popup "Open in a new tab", as in the following screenshot. Additionally, the standard browser’s behavior remains applicable, such as right click then “Open link in new tab” or control-left click…

    • The title of the page allows to identify which page is currently opened.

  • The left menu is reworked to simplify navigation between the different resources:

    • The "List" and "Create" entries on the left menu are removed. Clicking on the resource type directly displays the list view, where new buttons allow adding resources or importing devices in bulk.
    • Enhanced accessibility of the Network Tools: Wireless Logger, Spectrum Analysis and Network Survey. These tools were previously positioned under "Operating Management" in the left menu, now they become easily accessible under "Network Tools".

  • The license information is now moved to the Settings page and becomes only accessible to administrators. Additionally, the content of the License widget is enriched to show the remaining base station and device credits besides the maximum limit.

Key customer benefits​

UI/UX enhancement, as detailed in previous section.

Feature activation​

This feature is automatically available starting TPE SaaS 7.3.2 and self-hosted TPE 7.3.1.

Feature limitations​

N/A.

Copyright © 2023 Actility
On this page