New features specific to ThingPark Enterprise SaaS

Safe core network upgrade process using canary mode RDTP-8958

Prior to release 7.0: when a platform is upgraded from a version n to a version n+1, both network servers (also known as LRC in ThingPark architecture) in the high-availability core network cluster must be upgraded to the version n+1 at same time.

Starting release 7.0:

• When a platform is upgraded from a version n to a version n+1, only LRC2 (backup node) is upgraded to the version n+1, LRC1 (master node) remains on the version n.

• A proportion of the devices' traffic is steered towards LRC2. This ratio is controlled by the platform administrator, by defining a modulo factor to apply on DevAddr and DevEUI: for instance, modulo 2 would statistically switch half of the LoRaWAN® traffic to version n+1, modulo 4 would switch 25% and so on...

• The aim is to progressively switch LoRaWAN® traffic to version n+1 and monitor the system's KPIs and stability accordingly, before eventually upgrading the full LRC cluster to version n+1.

• In case of performance/stability degradation during the partial upgrade, LRC2 (backup node) shall be immediately rollbacked to version n.

note

The traffic redirection from LRC1 (master node, running on version n) to LRC2 (backup node, running on version n+1) is managed on LRC side without any impact on LRR end. In other words, LRC1 forwards LoRaWAN® traffic of canary devices to LRC2, without LRR being involved in traffic steering decision and regardless of which LRC node each LRR is connected to.

More details

In the illustrative flow chart diagrams below, the Base Station (LRR) is connected to LRC1 (master node) and the traffic ratio contributing to canary is set to 10% by the platform administrator (modulo 10):

Therefore, for a given device, the canary processing may not be symmetrical; for instance, the canary procedure may apply to UL/DL processing of a given device, but not to Join-Request for this same device.

Key customer benefits

Thanks to this feature, ThingPark customers and platform administrators have efficient mechanisms to safely upgrade the core network cluster while minimizing any risk of performance degradation on the datapath. With the partial upgrade of LRC cluster, leveraging ThingPark's state of the art High Availability architecture, any negative impact on network production is highly mitigated. Corrective actions are rapidly taken to rollback the core network upgrade if need be.

Feature activation

This feature is deactivated by default, activation remains under the responsibility of Actility's NetOps team.

As a prerequisite, the initial version (n) should already support canary mode, so n cannot be lower than version 7.0.

The overall process consists of activating canary mode for a defined period; then monitor network stability before deciding the next step: Either proceeding with the full upgrade of the LRC cluster (denoted "Commit" procedure) or rolling-back LRC2 to previous version (n) in case of performance degradation with version n+1.

note

While the ratio of devices contributing to canary mode is controlled by the platform administrator (assuming statistically-homogeneous repartition of DevEUI/DevAddr ranges within the Operator scope), the actual set of devices contributing to canary mode is meant to be random to provide unbiased / statistically-relevant assessment of the system's stability in version n+1.

Feature limitations

None.

Secure login using two-factor authentication

Starting release 7.0, all end-users must use two-factor authentication to login to ThingPark Enterprise SaaS.

More details

2-factor authentication is based on a one-time code generated by a mobile application, besides the end-user's password.

Key customer benefits

Keen to offer state of the art security to ThingPark users, multi-factor authentication mitigates the risk of unauthorized access to user accounts, for instance due to compromised passwords.

Feature activation

To configure 2-factor authentication for each end-user, upon the first connection of the user after upgrading to release 7.0, they must configure a one-time code as per the following example:

1. Users must install one of the following mobile applications to setup a mobile authentication framework. Both applications are available for Android (downloadable from Google Play Store) and iOS (downloadable from App Store) smartphones:

   • FreeOTP

   • Google Authenticator

2. Then the user should scan the QR code displayed in TPE login page.

3. The user shall then enter the one-time code generated by the application in TPE login page.

4. Next time the user will login to TPE, he/she will be asked to enter a one-time code to validate their login, using the same application linked to their account in step 1 above.

   

In case the user cannot generate the one-time code, he/she may reinitialize it through the password recovery process (Forgotten password).

Feature limitations

2-factor authentication cannot be selectively activated/deactivated for each TPE subscription: this is a global configuration applicable to all TPE subscriptions of each SaaS platform.

Infrastructure software upgrade RDTP-4764

The following components of ThingPark Enterprise SaaS infrastructure are upgraded in release 7.0. The component marked with * may be upgraded prior to TPW 7.0 software upgrade, to reduce the duration of the TPE SaaS 7.0 upgrade.

• Kafka*: upgrade from v1.0 to v2.4,

• MariaDB*: upgrade from 10.0.20 to 10.4.13,

• MongoDB*: upgrade from 3.4 to 4.2,

• Linux Operating System: upgrade from CentOS 6.x to CentOS 8.3.

  Note Actility is switching to AlmaLinux distribution as of TPE release 7.1.

More details

Key customer benefits

Thanks to the infrastructure upgrade, the system security and overall performance is enhanced.

Feature activation

Not applicable.

Feature limitations

None.