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 are progressively lifted by subsequent features:

• End-devices operating behind a relay must use class A + OTAA (Over-the-Air-Activation) modes.
• Among the relay-specific MAC commands defined in the LoRaWAN technical specification TS011, only the UpdateUplinkListReq/Ans, NotifyNewEndDeviceReq/Ans and CtrlUplinkListReq/Ans pairs are currently supported. Other MAC commands will be progressively supported in the next ThingPark releases.
• 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.

Explicit indication of UL/DL packets served via LoRaWAN relays RDTP-21151

Uplink and downlink packets exchanged between end-devices and the network via a LoRaWAN relay are displayed with a specific F symbol (F stands for "Forwarded).

More details

Examples: for uplink packets and for downlink packets forwarded by a relay.

Additionally, the relay identifier (relay's DevEUI) is explicitly displayed in a new column "Best Relay" in ThingPark Enterprise user interface (in the "Last 10 packets" widget of the device's detailed page) as well as in Wireless Logger application (through the "Relay ID" column).

Key customer benefits

Better user experience, allowing faster analysis of end-device behavior in relay mode.

Feature activation

This feature is automatically available starting ThingPark Enterprise 7.3.3.

Feature limitations

Not applicable.

Additional deployment use cases for LoRaWAN relays RDTP-22004 RDTP-21297

To address real-life deployment situations, the following use cases are now supported for LoRaWAN relays:

• OTAA end-devices joining the network under the coverage of multiple relays. In this case, the nearest relay to the end-device (denoted best-serving relay) is selected by the network server. Note that an end-device cannot be concurrently served by multiple relays to avoid WOR ACK collisions.
• OTAA end-devices served in hybrid coverage mode, with a mix of direct coverage (through conventional gateways) and via relay. In this case, the uplink packets received by conventional gateways + the best-serving relay are deduplicated by the network server; while the downlink packets may be sent to the end-device via both the best-serving gateway (over the device's RX1 or RX2 slot) and the best-serving relay (over RXR slot).
• Allow end-devices to be served in relay mode without initiating a new join cycle. Example of use cases:
  • A new relay is installed close to an existing end-device to improve its RF coverage.
  • A moving end-device enters the relay's coverage area.
  • Relay replacement, for instance due to hardware failure.
  The use cases described above leverage the automatic discovery mode supported by the LoRaWAN relay protocol, by which the relay notifies the network server of the presence of a new device through the NotifyNewEndDeviceReq MAC command.

More details

Key customer benefits

Thanks to the new features, it is now possible to operate an end-device under a mixed coverage of conventional gateways and relays. In case of such overlapping coverage, the delivery success rate of downlink packets is enhanced by leveraging RX1/RX2 slots of conventional gateways + RXR slot of the relay mode.

Additionally, thanks to the automatic discovery mechanisms, network administrators can now easily deploy new relays close to end-devices suffering from bad QoS without having to reset those end-devices.

Feature activation

The new use cases are automatically supported starting ThingPark Enterprise SaaS version 7.3.4 and self-hosted TPE 7.3.3.

Feature limitations

• The deployment use cases mentioned above are only addressed for Over the Air Activation (OTAA) mode. ABP activation mode will be addressed in a future release.
• When a new relay is deployed to enhance the radio coverage of an existing end-device that is already served by another relay, the end-device shall switch to the new relay only after initiating a new join cycle. This limitation is lifted with RDTP-21323.
• Due to a known limitation of the v1.0 LoRaWAN relay protocol, the automatic discovery mechanism based on NotifyNewEndDeviceReq MAC command does not work in case of DevAddr collision (that is to say, the same DevAddr is shared between several devices). Therefore, if the DevAddr included in the relay's notification is used by more than one DevEUI, the network server ignores the NotifyNewEndDeviceReq command.

LoRaWAN relays: seamless device switchover without reset RDTP-21323

This feature allows an end-device to switch from one relay to another without being reset, that is to say, no need to go back to the join state. This implies removing the device from the old relay and adding it to the new relay if the latter is the best-serving relay of the end-device.

More details

Here are some example use cases requiring dissociating the device from its current relay to associate it with a new relay:

1. The current relay is dead and has been replaced by another relay.

2. A moving device leaves the coverage of relay-1 to enter the coverage of relay-2.

3. Another relay has been installed closer to the device to offer better coverage and QoS.

Key customer benefits

Self-organizing networks, offering a better quality of service and seamless operability when end-devices are operated in relay mode.

Feature activation

The feature is automatically available for ThingPark platforms using release 7.3.5 or higher.

Feature limitations

Not applicable.

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.

Isolate Connections by domains RDTP-21377

Prior to release 7.3.3, when a TPE subscription is partitioned into several tenants through administrative domains, connections towards external applications were mandatorily cross-domain. This means that they are usable across all domains and accessible in read-only mode by non-administrator users.

Starting release 7.3.3, two types of connections are supported:

• Cross-domain connections (like before): these connections are not associated with any domain. Users having domain restrictions can only access cross-domain connections in read-only mode. Any confidential information is hidden in read-only mode, such as the URL and the custom headers of Basics HTTPS connections.
• Domain-specific connections (introduced by this feature): these connections are associated with one or several domains. Hence, they are only visible to authorized users whose domain restrictions match. Additionally, they can be associated only with devices belonging to those authorized users.

More details

The connection list is enhanced with a new "Domains" column as per the following example:

note

In self-hosted TPE, Node-Red connections are always cross-domain.

Key customer benefits

Thanks to this feature, TPE administrators can define tenant-specific connections toward external IoT applications to isolate the connections between their different tenants.

Feature activation

When a TPE platform partitioned by domains is upgraded to release 7.3.3, all the existing connections remain cross-domain for the sake of backward compatibility. A cross-domain connection is not associated with any domain.

To convert a cross-domain connection to domain-specific, users having write access to the connection can associate it with one or several domains from the connection dashboard on TPE GUI:

To add a new domain-specific connection:

• For TPX connections: only administrators or end-users having the "Device, Multicast Group and Connection managers" role without any domain restrictions can add TPX connections.
  caution

  After its creation in TPX IoT Flow GUI, the TPX connection is originally cross-domain; so the user must edit the newly-created connection in TPE GUI to associate it with domains.

• For Basic HTTPS connections: besides administrators, end-users having the "Device, Multicast Group and Connection managers" role may add Basic HTTPS connections and associate them with the appropriate domains, even if these users have domain restrictions. In this case, the domains associated with the connection must match the user's own domain restrictions.

Feature limitations

The implementation of this feature in TPE 7.3 has two limitations regarding TPX connections:

• Provisioning of new TPX connections is not authorized for users having domain restrictions.
• Users having domain restrictions cannot access TPX Iot Flow user interface: the button is greyed in the connection dashboard of the TPE user interface.

Support remote access for Basics Station gateways RDTP-18681

This feature allows network administrators using Basics Station packet forwarder to remotely access the Basics Station's local terminal to troubleshoot their gateways and run OSS commands as needed.

More details

Users can open a remote session from ThingPark's user interface, by opening the base station details then go to Advanced tab and click Open session.

Up to two remote sessions can be opened simultaneously. The session automatically closes after 10 minutes of inactivity.

The shell runs with the same Linux user as the Basics Station software itself.

note

Depending on the Basics Station software version running on the base station, the remote shell may not be available. In this case, the "Open session" button is disabled in ThingPark's user interface.

Key customer benefits

Easier troubleshooting of Basics Station problems and ability to execute OSS commands.

Feature activation

This feature is automatically available for ThingPark platforms using release 7.3.3 or higher.

Feature limitations

The following limitations apply in this release:

• The implementation of this feature is based on the remote shell (rmtsh) feature implemented by Semtech's reference Basics Station code. It may not work properly if the gateway manufacturer supports a different implementation than Semtech's reference one.

• Since this feature relies on Websockets, the proxies between the web browser and ThingPark must allow Websockets. Note that such proxy may close the session prematurely in case of inactivity.

UI/UX enhancements for Basics Station gateways RDTP-20905

This feature introduces the following enhancements for base stations running Basics Station packet forwarder:

• A GUI assistant to compute the ThingPark ID of the base station from the Station EUI or the Gateway-ID.
• All the GUI features not supported by Basics Station are now clearly deactivated or hidden.

More details

When adding a base station relying on Basics Station packet forwarder in ThingPark GUI:

• An explicit message indicates to the user that the selected base station model uses Semtech's Basics Station packet forwarder and displays the link toward Basics Station documentation.

• The "LRR-UUID" field (which is the ThingPark ID of the base station) is already prefilled with the prefix "0016C0-", which corresponds to the OUI part of the ThingPark UUID. The other part of the UUID can be computed from the station EUI or the gateway ID.

  

  

In the base station's detailed dashboard:

• The packet forwarder type is explicitly displayed in a new field "Packet Forwarder".
• An explicit indication is displayed in empty widgets when the related metrics are not supported/reported by Basics Station software, but only supported by the LRR packet forwarder.
• Additionally, the GUI buttons triggering remote OSS commands are disabled when they are not supported by Basics Station software, but only supported by the LRR packet forwarder.

Key customer benefits

Improved user experience using base stations running Basics Station packet forwarder.

Feature activation

This feature is automatically available for ThingPark platforms using release 7.3.3 or higher.

Feature limitations

Not applicable.

Support class B for Basics Station gateways RDTP-22167

This feature allows gateways using Basics Station packet forwarder to support LoRaWAN class B mode, through the transmission of periodic beacon signals + class B pingslots.

More details

Key customer benefits

Thanks to this enhancement, class B devices can be served by gateways using Basics Station packet forwarder.

Feature activation

To support class B, the transmission of beacon signals must be activated on the base station.

In the current release, the beacon activation must be done via OSS-API:

• Endpoint: PUT /partners/mine/bss/{bsUid}
• Parameter: activateBeaconTransmission (boolean, must be set to true, default is false).

Feature limitations

Activating the transmission of beacon signals on gateways using Basics Station packet forwarder is not currently supported by the user interface. You must use the OSS-API to activate beacons on the Basics Station gateways.

Support multicast for Basics Station gateways RDTP-22459

This feature allows gateways using Basics Station packet forwarder to support LoRaWAN multicast mode. The multicast mode is used to improve the downlink spectral efficiency, it is compatible with both class B and C modes.

To learn more about downlink multicast, see About multicast.

More details

Key customer benefits

Thanks to this enhancement, ThingPark customers operating gateways using Basics Station packet forwarder can leverage multicast mode to support additional use cases such as street lighting and firmware upgrade over the air (FUOTA).

Feature activation

See the user guide to learn more about how to setup and manage multicast groups.

Feature limitations

Not applicable.

Multi-language support of the user interface RDTP-22709

ThingPark Enterprise's user interface, including ThingPark X Iot-Flow, now supports multiple languages: English, French, Italian, Spanish, German and Japanese.

Additional languages can be added on demand.

More details

Key customer benefits

Enhanced user experience, displaying the ThingPark user interface in the user's preferred language.

Feature activation

This feature is supported since TPE SaaS release 7.3.6 and self-hosted TPE 7.3.4.

To change the default language, go to My Profile then select your preferred language.

Feature limitations

• Network Tools (Wireless Logger, Spectrum Analysis, Network Survey and Network Coverage) are currently supported in English only.

• The manufacturer description for base stations and devices, as well as the RF region description, is displayed only in English.

• System-generated emails, for instance for user activation or alarm notification, are sent only in English.