New features common to ThingPark Enterprise SaaS and Self-hosted

Base Station Management: UI/UX enhancements

TPE release 7.1 brings significant UI/UX enhancements to TPE Network Administrators and Base Station Managers.

More details

The main enhancements are listed hereafter:

• Better organization of Base Station widgets in tabs, with the Basic View tab gathering all the necessary information about the BS: its provisioning information, status indicators, location, main radio and backhaul graphs, system load indicators...

• Enrichment of the RF statistics RDTP-12943

  • Basic View tab includes the main RF widget "Radio Traffic History". Other detailed statistics are now displayed in a separate tab RF Statistics.

  • Radio Traffic History now shows the volume of uplink late frames (i.e., queued by the BS due to backhaul disconnection)

  • New time series graph for Estimated Signal Power (ESP), in the widget Signal Strength and Noise.

    note

    ESP is an estimate of the LoRaWAN® useful signal power received by the BS excluding the background noise, whereas RSSI aggregates the received power of both the useful signal and background noise.

  • Display of the scope/usage of each RF logical channel, i.e., whether it is used for uplink, downlink RX1 or RX2, class B beacon or pingslot.

  • A new dedicated widget for Duty Cycle statistics.

  • Raw counters aggregating specific events related to uplink reception, downlink transmission as well as LoRa Modem event. These counters are aggregated over a measurement period controlled by the user (i.e., the measurement period may be reinitialized at any time from TPE GUI, through the "Reset indicators" button).

    

• Enrichment of the backhaul statistics RDTP-12573:

  • Basic View tab includes the main backhaul widgets "Interfaces" (previously called "Networks") + "Backhaul traffic with Network Server". Other detailed statistics are now displayed in a separate tab Backhaul Statistics.

  • New widgets added to detailed indicators for each network interface (TX/RX throughput, traffic volume, round trip delay...) as well as backhaul statistics between the BS and each Network Server node:

    

    

    note

    Statistics are aggregated over the reporting period, this period could be reinitialized by the user by clicking "Reset indicators" icon.

     

    

    

    

• Advanced antenna management RDTP-12577:

  • Depending on the number of antennas configured in the BS profile, the user can configure the antenna details in a new tab Antennas.

  • Additionally, TPE users can now configure the antenna gain and cable loss directly from the GUI, under the antenna details.

  • Among the antenna details available for each antenna, the user may fill additional administrative information that could be useful to further debug any potential RF issues, such as the distance between the LoRaWAN® RF antenna and surrounding antennas in case several antennas from different technologies are collocated. The user may also add images illustrating the installation environment and antenna positioning.

• Advanced BS administration/configuration RDTP-12949:

  • " Security" and "Low Uplink Activity Alarm Settings" widgets are moved to the Advanced tab, together with the

  • New administrative commands:

    • Restart LRR Process: restart only the applicative packet forwarder, so it is faster than the full BS reboot

    • Start/Stop Downlink, to enable/disable downlink transmission mode.

  • Advanced configuration:

    • New option to enable/disable "RX2 Optimization" feature, which allows smart selection of the downlink RX slot (RX1 or RX2) to maximize the downlink reception probability and optimize the downlink radio capacity of the BS.

      note

      This feature was activated by default prior to release 7.1.

    • The fine timestamp decryption key settings are now managed in the Advanced tab. This configuration is only required when TDoA network geolocation feature is activated.

• RF scan enhancements RDTP-12951:

  • Possibility to set the RF scan modalities in case the default settings do not meet the user's expectations. Configurable settings include start/stop frequencies and the scan step.

• Show "Served Devices" of each Base Station RDTP-13716:

  • Objectif: show and export the list of devices served by each Base Station, either as their best-serving gateway or among the three best-servers.

    This information is show in a new widget "Served Devices" available in the Basic View tab.

    note

    Roaming (i.e., foreign) devices are not listed in this new widget.

  • Devices are also shown on map if they have valid coordinates.

    

• Updated BS marker on map RDTP-16386:

  • A Base Station is now represented by a    marker.

  • The marker color reflects the BS health state.

• Enhanced presentation of Base Station's detailed page:

  • The BS name is displayed in the page's title, together with an icon showing the author and date of the last update on this BS.

  • New icon added on the top right of the page to duplicate a BS.

  • The "Remove Base Station" button existing in previous releases is now replaced by the top right icon .

  • The link to download the BS image is now presented by the icon on the top right of the page.

  • Easier modification of editable fields, by directly clicking the field instead of clicking a button. Editable fields are displayed with grey background.

Key customer benefits

The feature brings significant improvement to ThingPark Enterprise Network Administrators and Base Station Managers. The improvement extends far beyond the user interface to enhance the overall user experience and provide enriched functionalities related to day-to-day supervision and maintenance tasks.

More details about the enhancements are described in the "Feature Description" section.

Feature activation

The enhancements listed above are activated by default, they cannot be deactivated.

Feature limitations

None.

Device Management: UI/UX enhancements

Starting release 7.1, the Device's detailed page is enhanced as follows:

• The Device name is displayed in the page's title, together with an icon showing the author and date of the last update on this device.

• New icon added on the top right of the page to duplicate a BS.

• The "Remove device" button existing in previous releases is now replaced by the top right icon .

• The "Send Downlink" button existing in previous releases is now replaced by the icon on the top right of the page.

• The Device is now represented by a marker on map. The marker color reflects the BS health state.

• Easier modification of editable fields, by directly clicking the field instead of clicking a button. Editable fields are displayed with grey background.

More details

Key customer benefits

Improved user experience, ensuring coherency between Device and Base Station's UI ergonomics.

 

Feature activation

The enhancements listed above are activated by default, they cannot be deactivated.

 

Feature limitations

None.

Enrichment of TPX IoT Flow Connector list

ThingPark Enterprise 7.1 comes with a new version of ThingPark-X IoT Flow v1.6.

This new Iot Flow version brings additional connectors:

• Ginjer, enabling devices to use the https://www.ginjer.io application platform. To learn more, see the Ginjer connector documentation.

• Azure Event Hubs, allowing to send uplinks to Azure Event Hubs without using Azure IoT Hub.

• Microsoft Teams, it allows sending uplinks to Microsoft Teams. The user needs to provide their Webhook, and the uplinks are displayed on their channel.

• ThingsBoard, enabling devices to use the https://www.ThingsBoard.io application platform.

• Modbus (self-hosted TPE only), this new connector supports the use of Modbus by implementing an embedded Modbus slave, collecting uplinks and mapping application payload values to registers according to the configured rules. To learn more, see the Modbus connector documentation.

  note

  To support Modbus server mode on self-hosted TPE, inbound flows whitelist the ports 502-507 when TPX Iot-Flow service is running on self-hosted TPE.

• OPC-UA (self-hosted TPE only), this new connector supports the use of OPC-UA by implementing an embedded OPC-UA server, collecting uplinks and mapping application payload values to the configured registers. Device and gateway statuses are also exposed on this OCP-UA server. To learn more, see the OPC-UA connector documentation.

  note

  To support OPC-UA connector on self-hosted TPE, inbound flows whitelist the ports 4840-4845 when TPX Iot-Flow service is running on self-hosted TPE.

More details

Key customer benefits

The new connectors offer richer and seamless integration with more and more IoT application platforms (such as Ginjer and ThingsBoard).

Moreover, supporting the Modbus and OPC-UA connectors - widely used in industrial IoT deployments – unlocks additional integration use-cases in the industrial IoT market and reduces the overall cost of TPE integration with business applications in such scenarii.

Feature activation

The new connectors are directly available upon migration of the ThingPark Enterprise platform to release 7.1.

Feature limitations

Modbus and OPC-UA connectors are only available for self-hosted TPE, not relevant for TPE SaaS. Additionally, these two connectors are released in beta version, awaiting consolidated field feedback from early adopters.

Support Semtech's Basics Station packet forwarder RDTP-9946 RDTP-16927

Prior to release 7.1, only gateways using LRR packet forwarder can connect to ThingPark's core network.

Starting release 7.1, besides gateways using LRR, any gateway using Basics Station packet forwarder may connection to ThingPark's core network.

More details

To learn more about Basics Station packet forwarder, see the LoRa Basics™ Station documentation.

The ThingPark integration with Basics Station adds two new components to the ThingPark infrastructure:

• LNS bridge: mediator between the Basics Station protocol and the LRC core network.

• Configuration & Update Server, also known as CUPS.

note

The implementation of this protocol in ThingPark release 7.1 is limited to initial access and configuration. Updating the Basics Station software through CUPS is out of scope of this release.

The BS to core network backhaul link is secured through TLS.

Key customer benefits

Thanks to this new feature, ThingPark users may easily connect their gateways to the ThingPark 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 the 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. To learn more about Basics Station limitations, see "Feature limitations" section.

Feature activation

To connect a gateway using Basics Station to ThingPark, the following steps are required:

1. Install Basics Station packet forwarder on the gateway if it is not already present.

2. 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.

1. Configure the Basics Station: three files should be configured:

   • cups.uri, this is a text file containing the address of the CUPS server. The configuration depends on the target ThingPark platform. For instance, for Community Platform, set https://community.thingpark.io:443.

   • cups.trust, this is a binary file containing the certificate of the CA for the CUPS server in DER format. The configuration depends on the target ThingPark platform. For instance, for Community Platform, set:

     # wget https://www.amazontrust.com/repository/AmazonRootCA1.cer
     # mv ./AmazonRootCA1.cer cups.trust

   • station.conf, this is a text file in JSON format, it contains the configuration settings of the Basics Station. Most of the file content should be provided by the gateway manufacturer, but you should at least update the antenna_gain and log_level parameters (the latter should be set to CRITICAL if your logs are stored in SSD).

2. Provision your gateway in ThingPark Enterprise GUI:

   • Use the Generic Manufacturer

     

   • Then select the "Basics Station packet forwarder" Model

   • Set the LRR-UUID as 0016C0-xxxxxxxxxxxxxxxx

     • xxxxxxxxxxxxxxxx being the gateway ID provided by the manufacturer, often built based on a hardware reference like the MAC address.

     • To retrieve the gateway ID, you may get the station EUI from the logs: this is an ID6 (see https://doc.sm.tc/station/glossary.html)

     • In the following example :

       

       • station EUI: 8:ff:fe4a:bc32

       • 4 groups of 16-bit blocks: 0008:00ff:fe4a:bc32

       • gateway ID: 000800FFFE4ABC32

       • LRR-UUID: 0016C0-000800FFFE4ABC32

   • IPSec (X509) must be Enabled, this will generate certificates that will be provided by the CUPS server to the Basics Station in order to connect to ThingPark core network.

   • Set the target RF Region according to your ISM band and target channel plan, like for any conventional gateway using LRR packet forwarder.

     

Once the gateway successfully retrieves its security certificate, it shall connect to the ThingPark core network, and the related connection status shall be reflected in TPE GUI.

Feature limitations

The Basics Station packet forwarder has the following limitations compared to ThingPark Long Range Relay (LRR):

• Basics Station uses JSON data encoding, which is not efficient from data consumption standpoint for cellular and satellite backhaul use-cases. ThingPark LRR uses an efficient binary encoding protocol, so it is significantly more compact / bandwidth efficient.

• Uplink packets buffered by the Basics Station during BS to core network backhaul disconnection are not flagged "Late", so there is no simple way to identify them with respect to uplink packets reported on-time, especially if the BS is not properly time-synchronized.

• Basics Station does not provide any native support to network interface features such as automatic interface failover mechanisms. Those mechanisms are natively supported by LRR.

• Basics Station does not provide transmission indication with appropriate error cause upon failing to transmit a downlink packet. Hence, a generic error cause "A6 : « Transmission timeout»"  is reported by ThingPark when DL transmission fails on a gateway using Basics Station packet forwarder.

  note

  LRR provides a wide range of transmission error causes (LBT, modem busy, transmission timeout...).

• Unlike LRR, Basics Station does not provide periodic radio/backhaul/system reports to the core network. Due to this limitation, the following Network Manager widgets do not show any data for Base Stations using Basics Station packet forwarder:

  • "Interfaces", "Backhaul Traffic with Network Server" and "System Load" widgets under the Basic View tab.

  • "Counters" widget under RF Statistics tab.

  • All widgets of the Backhaul Statistics tab, except the connection status information.

• Basics Station does not support administration & maintenance commands such as reboot/restart, remote access, radio start/stop, backup/restore. Accordingly, all the administrative commands present in the Advanced tab of Network Manager application cannot be used for Basics Station (all are supported by LRR).

• Basics Station does not support any command to remotely set the antenna gain and cable loss, hence this information must be directly set by the gateway administrator in the local station.conf file of the Basics Station software.

• Basics Station does not report the GPS location of the gateway, whereas LRR does. Hence, only administrative location mode is supported for BS running Basics Station packet forwarder.

• Basics Station only reports limited uplink metadata, for instance, it neither reports the fine timestamp state/precision nor the frequency offset. These metadata are interesting for TDoA network geolocation, they are all reported by LRR packet forwarder.

• Basics Station does not support  IPSec, only TLS is supported. LRR supports both IPSec and TLS security modes.

While Basics Station supports LoRaWAN® class B mode, the current integration with ThingPark only covers unicast mode for class A & C devices. Additionally, gateways using v2 reference design are out of scope of the current release.

note

This feature is currently available only for TPE SaaS, it is currently in restriction for self-hosted TPE. This limitation will be lifted as soon as PoC feedback on SaaS is consolidated.

Enhanced alarm notification by email

Prior to release 7.1, TPE users subscribe to get device and/or base station alarms by email. Once subscribed, they are notified about all the active alarms being raised regardless of their severity state, i.e., they cannot request email notification only for critical alarms.

Starting release 7.1, the configuration of email notifications is enhanced to allow TPE users to subscribe only for alarms ≥ a given severity state N.

note

N refers to the minimum severity state, it may be "Critical", "Major", "Minor", "Warning" or "Indeterminate".

More details

With this enhancement in TPE 7.1, when subscribing to the state N, the user receives an email notification in any of the following cases:

• An alarm is created with a state ≥ N.

• The state of an alarm (acked or not) increases, and the new state ≥ N.

• The state of a not-acked alarm decreases and the original state ≥ N (e.g., the alarm has been cleared).

Example When the user subscribes to alarm state "Major", an email notification is sent for any alarm created/updated with state ≥ Major, i.e., alarms raised in Critical state (or not-acked alarms updating their states from minor to critical) are also notified without being explicitly subscribed by the user/admin.

Impact to TPE GUI

The new configuration may be directly done from TPE GUI, through the Settings panel on the left menu > Alarms widget:

Key customer benefits

Increased flexibility in configuring alarm notification by emails, allowing TPE users to focus only on high severity alarms if needed.

Feature activation

This enhancement is automatically available after the upgrade to release 7.1.

For sake of backward compatibility, for all the TPE subscriptions already configured with email notification in their account, all the configured email destinations are now associated with the Indeterminate state so that users continue to receive notification for all alarms whatever their severity.

Feature limitations

None.

Support custom HTTP headers for Basic HTTP connections RDTP-7558

This feature allows the customization of HTTP headers in requests from LRC to AS on tunnel interface, also known as Basic HTTP type of connections:

• Starting release 7.1, ThingPark users may define up to 5 custom HTTP headers for their Basic HTTP connections.

• Each custom HTTP header is statically defined in TPE administration GUI, as a string (e.g., Authorization: Bearer AbCdEf123456).

• When such custom HTTP headers are defined in the Connection configuration, the LRC network server reports these custom HTTP headers on all outgoing HTTP requests over the LRC-AS tunnel interface towards external Application Servers using HTTP protocol.

  

note

A maximum of 5 custom HTTP headers can be defined. The maximum length of an HTTP header (name + value) is 510 characters.

More details

Each custom HTTP header is composed of two fields:

1. Header name:

   • Regex is aligned with RFC 7230: \^(\[!#\$%&'\*+\\-.\^\|~\w])+$`

   • Forbidden names: "Accept", "Host", "User-Agent", "Content-Length", "Content-Type", "Expect" and "Proxy-Authorization".

   • A given header name can be configured only once (case insensitive).

2. Header value: Regex is aligned with RFC 7230, i.e., \^(\[\x21-\x7e\]((\[ \t\])+\[\x21-\x7e\])?)+\$

Specific consideration for the "Authorization" header:

• "Authorization" header may be explicitly defined as a custom HTTP header, but it may also be implicitly generated by the LRC when the destination URL contains a login/password (for example http://username:password@application.com).

• When both are defined, the LRC gives a precedence to the login/password defined in the URL.

Key customer benefits

This feature offers additional flexibility to application developers, allowing easier integration with third party Application Servers using HTTPS protocol.

Thanks to this feature, ThingPark Subscribers can add custom fields to the HTTP header sent by LRC Network Server to external Application Servers. Custom headers may be useful in many use-cases such as additional security/authentication, through the "Authorization" header.

Feature activation

This feature is directly available after the TPE platform is upgraded to release 7.1.

To activate the use of custom HTTP headers, the user must explicitly set them in TPE GUI.

Feature limitations

Only static headers are supported. Additionally, headers cannot be customized device-wise, i.e., the same header is used for all devices associated with a given AS Connection.

[ADRv3]: Quickly rescue link budget in case of sudden degradation RDTP-848

Starting release 7.1, as soon as the LRC Network Server detects an increase of the device's instantaneous packet error rate (also known as short-term PER) beyond a configurable threshold, it triggers a new "rescue" (or recovery) mode to enforce a conservative combination of:

• TxPower (typically the maximum allowed by the local regulation and the device's hardware capability)

• + Spreading Factor (typically SF10 or higher, to maximize the base station's chances to successfully demodulate the uplink frames, thanks to the better Rx sensitivity of lower data rates/higher SF)

• + number of repetitions (to offer both frequency and time diversity).

More details

Example LRC receives FCntUp # 50 from a given device, then the next received uplink frame has FCntUp # 60 -> instantaneous packet error rate = 9/11 (i.e., 9 lost over 11 sent by the device) = 0.8181 (81.81%) > Max_Short_Term_PER (0.8 by default) -> trigger rescue ADR mode -> LRC sends LinkADRReq with:

• TxPower=0 (i.e., max power/EIRP)

• DataRate = 0 (SF12)

• NbTrans= 3 (3 transmission per individual UL frame).

note

The recovery TxPower/SF/NbTrans are configurable in RF Region, as described in "Feature Activation" section.

After the device applies the recovery ADR command, the normal ADRv3 state machines remain applicable, trying to find the best combination of TxPower/SF/NbTrans for this device according to its current RF reception conditions, rather than permanently staying on max TxPower, max SF and 3 transmissions per uplink packet.

Key customer benefits

Better reactivity in case of sudden degradation of the RF reception conditions, e.g., in the following situations:

• Temporary outage of the device's best-serving base station, yielding strong degradation of the RF link budget and increased pathloss to reach farther base stations.

• A device was moved from one location to another without resetting the ADR-bit to 0 in the LoRaWAN® MAC header of the uplink packets, with uplink reception conditions being more difficult in the new location.

Feature activation

This enhancement is automatically available in release 7.1.

New RF Region parameters are added to control this new behavior:

• Max_Short_Term_PER: This parameter defines the maximum instantaneous/short-term packet error rate detected by the LRC Network Server before triggering the RF rescue mechanism.

  • Default = 0.8 (i.e., 80%), which means that the rescue mechanism is triggered as soon as more than 8 consecutive uplink frames are lost for a given device.

• RecoverySF: Spreading Factor requested by ADRv3 to speed-up the RF recovery process, it is notified in the rescue LinkADRReq MAC command sent to the device.

  • Default value: SF12.

  • It must be explicitly set ≤ SF10 in ISM bands not supporting SF11/SF12, e.g., US915 RF Regions or AS923 countries enforcing uplink dwell time = 400ms.

    note

    This is already the case for RF Region catalog, starting v1.5.0.

• RecoveryNbTrans: number of transmission copies of each uplink frame counter requested by ADRv3 to speed-up the RF recovery process, it is notified in the rescue LinkADRReq MAC command sent to the device.

  • Default value: 3.

• RecoveryTxPower: device's transmission power requested by ADRv3 to speed-up the RF recovery process, it is notified in the rescue LinkADRReq MAC command sent to the device.

  • Default value: equal to MaxEIRP/MaxPower.

note

RecoverySF, RecoveryNbTrans and RecoveryTxPower are also used by the feature Support mobile base stations providing temporary RF coverage RDTP-13613.

Feature limitations

None.

Support mobile base stations providing temporary RF coverage RDTP-13613

Starting release 7.1, a base station may be associated with one of the three following types of RF coverage:

• Permanent (default setting): the BS provides permanent RF coverage to surrounding devices. Accordingly:

  • Uplink packet reception through this BS is considered in ADR decisions.

  • This BS may be used to route downlink packets for all device classes A/B/C, using the same algorithm as previous releases.

    note

    This is the setting used for all base stations after the upgrade to TP7.1, for sake of backward compatibility with previous releases.

• Temporary and mobile: the base station does not have a fixed location; it provides temporary RF coverage to surrounding devices. This is typically used for the walk-by or drive-by use cases. Accordingly:

  • If the same uplink packet is received through both permanent and temporary base stations, the reception through the temporary BS does not impact ADR decisions. The temporary BS is not eligible for routing of DL traffic either.

  • Otherwise, if the uplink packet is received only through the temporary BS, the device is assumed to be out-of-coverage of the permanent base stations with its current data rate/TxPower/number of repetitions. Hence, the network triggers the RF recovery mode for this device, by sending a LinkADRReq MAC command requesting the device to use the RecoverySF (set by default to the highest allowed SF), RecoveryTxPower (set by default to the max allowed TxPower) and RecoveryNbTrans (set to 3 transmissions by default).

    note

    The nominal ADR algorithms are deactivated during this recovery mode.

  • This BS may be used to route downlink packets for class A devices only, since there is no guarantee that this moving BS will remain within the device's vicinity in class B/C modes.

• Temporary and stationary: the base station has a static location for a period of several days, up to a few weeks, but it does not provide permanent RF coverage. This is typically the case of seasonal gateways deployed to temporarily boost the RF coverage/capacity during specific events.

  • The same UL/DL processing described in "temporary and mobile" mode applies for this "temporary and stationary" mode, with only one difference: This BS may be used to route downlink packets for class B/C devices besides class A.

    note

    This BS must be switched to "temporary and moving" once it leaves its temporary location, to avoid losing DL class B/C packets.

More details

Key customer benefits

Thanks to this feature, the Radio Access Network (RAN) administrators can deploy base stations providing temporary RF coverage without jeopardizing the longer-term radio operation of surrounding devices.

• This is particularly useful for drive-by or walk-by use cases to retrieve sensor measurements in hard-to-cover locations such as water meters located in basements.

• Moreover, in special deployment scenarii where LoRaWAN® coverage is missing or very poor, temporary coverage would be established by lifting a base station up in the air with a drone.

• Additionally, mobile gateways could be used to rescue the RF coverage of devices that initially use aggressive ADR settings (e.g., SF7 with power reduction) while the current RAN layout requires those devices to use higher SF/TxPower.

  Example The best serving gateway of some devices goes in outage while those devices currently use SF7. To allow surrounding base stations to serve those devices, the RAN administrator may deploy a temporary BS to capture the SF7 traffic of those devices while switching them to higher SF/TxPower/NbTrans through the RF recovery mode.

Feature activation

This feature is automatically available after the platform upgrade to release 7.1.

After the upgrade, all the base stations are automatically configured with "permanent" RF coverage type.

A new parameter is added in TPE Administration GUI to indicate the RF coverage type of each base station. The base station administrator may change the RF Coverage type at any time, under the base station's detailed dashboard > Advanced tab > Configuration widget.

The RF recovery mode described in the "Feature description" section is controlled by three RF Region parameters:

• RecoverySF: Spreading Factor requested by the network when the device is only reachable by temporary base stations. It is notified in the rescue LinkADRReq MAC command sent to the device via the temporary BS.

  • Default value: SF12.

  • It must be explicitly set ≤ SF10 in ISM bands not supporting SF11/SF12, e.g., US915 RF Regions or AS923 countries enforcing uplink dwell time = 400ms.

    note

    This is already the case for RF Region catalog, starting v1.5.0.

• RecoveryNbTrans: number of transmission copies of each uplink frame, requested by the network when the device is only reachable by temporary base stations. It is notified in the rescue LinkADRReq MAC command sent to the device via the temporary BS.

  • Default value: 3.

• RecoveryTxPower: device's transmission power requested by the network when the device is only reachable by temporary base stations. It is notified in the rescue LinkADRReq MAC command sent to the device via the temporary BS.

  • Default value: equal to MaxEIRP/MaxPower.

note

RecoverySF, RecoveryNbTrans and RecoveryTxPower are also used by the feature  [ADRv3]: Quickly rescue link budget in case of sudden degradation RDTP-848.

Feature limitations

Base stations associated with either "Temporary and mobile" or "Temporary and stationary" types cannot contribute to passive roaming. This limitation is due to the absence of the "temporary BS" notion from the LoRaWAN® Backend Interfaces specification.

Update downlink scheduling priorities as per LoRaWAN® 1.0.4 RDTP-16249

Prior to release 7.1, in case the maximum downlink MAC payload size does not allow accommodating both applicative payload and MAC commands, the priority was given to applicative payload.

Starting release 7.1, and following the LoRaWAN® 1.0.4 specification, priority is given to DL MAC commands over DL applicative payload, as per the following priority ordering extracted from LoRaWAN® 1.0.4 specification (table 15):

More details

To learn more about LoRaWAN® 1.0.4 specification, see the LoRa Alliance resource hub.

Key customer benefits

• Full alignment with the latest LoRaWAN® specification.

• Faster transmission of crucial MAC commands required for optimum operation of the device's MAC layer, e.g., configure dwell time settings for AS923, update Channel Mask for US915, switch the device to lower data rate with ADR algorithm to mitigate packet loss...

Feature activation

This feature is automatically activated for all LoRaWAN® devices in release 7.1, it cannot be deactivated.

Feature limitations

None.