Product Version 4.2 - Software Release Notes

Product Version 4.2 - Software Release Notes


The scope of this document is to describe the release notes of the ThingPark Product Software v4.2.

  • Version 4.2 subcomponents versioning

  • Version 4.2 list of new introduced features (NFR’s) and release notes for all ThingPark software components

  • Issues Resolved for Customer Project/Customer Support

This document is also available as a PDF file in the attachment tab.

ThingPark Solution Architecture Description

The ThingPark set consists of three main key components:

  • ThingPark Wireless – OSS and core network

  • ThingPark Market

  • ThingPark X

ThingPark is a modular solution enabling NW Operators to deploy ThingPark Wireless only; with ThingPark Market; with ThingPark X, or all components together.

The System Management Platform (SMP) is a software layer, which serves all ThingPark platform modules such as the billing and the BPM engine.

Figure 1 - ThingPark Solution Architecture Description High Level Product Illustration

Please note that the modules above may be representing a physical server, a function, a service or a business support layer as part of the overall ThingPark solution and not necessarily a physical HW server

Subcomponents Versioning

ThingPark Market

Sub component versioning:

System Management (SMP)
Online Billing
Online Store
User Portal
Batch scripts on SMP executed by the crond.

ThingPark Wireless

Sub component versioning:

LoRa Network Server
Location solver
These tools generate the packing of the RF region file on the LRC to prepare the provisioning of the LRR
2.2.26 wirmaar 2.2.23 wirmav2 2.2.27 fclamp 2.2.38 fcpico
Base Station Software
Wireless OSS (Operator Manager / Connectivity Plan Manager)
Wireless OSS (Network Manager / Device Manager)
Supply Chain (Application sample)
Wireless Logger
Network Survey
Spectrum Analysis
LRC http provisioning interface
Batch scripts on TWA executed by the crond
Proxy and security for shellinabox

ThingPark System

Sub component versioning

NGINX configuration package for HTTP-proxy
NGINX configuration package for AS-Proxy
External ID update through a script
Activation tool for the Address Manager module
Initialize module like network Manager, Application manager

ThingPark X

Sub component versioning

Authentication Server
NGINX configuration package for VGSCL HTTP-proxy
NGINX configuration package for NSCL HTTP-proxy
LoRa driver tunnel API pre-processor on the VGSCL HTTP-proxy
Network Service Capability Layer Server
TPX HTTP-proxy (reverse proxy and load balancer)
Virtual Gateway Service Capability Layer Server
ONGBrowser Application
MongoDB Shard Configuration Server
MongoDB Replica Set Node Server
MongoDB routing service for Shard configuration
Datalogger Application
Datalogger SELinux policy
ThingPark X LoRa Driver
ThingPark X Tase2 Driver

ThingPark Enterprise

Sub component versioning s

ThingPark Enterprise GUI version
TP Enterprise Centos OS Version
Docker images for ThingPark Enterprise
Ufispace Base Station image version

Version 4.2 Newly Introduced Features (NFR’s)

NFR#232: ThingPark Marketplace Shared Suppliers for Centralized Marketplace

Feature Description

The purpose of this feature is to enable “Actility B2B Marketplace” Operator, hosted on Actility SaaS platform to declare a new notion of Shared Suppliers while other type of Operators can only declare dedicated Suppliers like the current behaviour and User experience before ThingPark v4.2.

Shared Suppliers are contracted by “B2B marketplace” Operator and are visible, to be enrolled, by all Operators declared on the Actility SaaS hosting platform and by all Operators which are declared on a distributed independent ThingPark platform.

The scope of NFR#232 is to allow the enrolment of Shared Suppliers by Operators declared on distributed independent ThingPark platforms. NFR#232 supports product Devices only – at this stage the notions of Applications and ThingPark X are excluded.

Here below an image of the global Shared Supplier solution:

Features Software Entities and Assumptions

Shared Suppliers may only be declared on a SaaS platform.

Shared Suppliers may interact only with a SaaS platform - distributed ThingPark platforms are “hidden” to Share Suppliers. Therefore:

  • A Shared Application only interacts with the SaaS platform

  • A Supply Chain process of a Shared Supplier only interacts with the SaaS platform

Feature Business and Technical Scoping

The phase one of the centralized Marketplace is limited to the notion of Devices and focuses on the following major features:

  • Shared Suppliers browsing

  • Shared Suppliers enrolment

  • B2B catalogue browsing

  • Offer creation

  • Device quantity retrieval

  • Order validation - shipping tariff and condition

  • Order creation - BPM workflows execution

  • Order histories

Architecture and Model

Here below is a high-level description of the Shared Suppliers deployment model:

  • Both Operators and the B2B Marketplace are hosted on the SaaS platform

  • Operators are deployed over a distributed platform and the B2B Marketplace on the SaaS platform – which is the scope of NFR#232

The communication in between the distributed platforms and the SaaS platform uses a private (tps2tps) SMP webservice API. This webservice API is dedicated to the use of this interconnection only and may not be set for any other external usage.

Here below an image of the global solution model:

Shared Supplier Workflows

The following technical and business workflows are introduced:

  • Boot - The distributed platform should have a communication channel with the SaaS platform. Respectively, the SaaS platform should have a communication with the Distributed platform.

  • Shared supplier enrolments -

    • Shared Suppliers browsing - the Operator can now list and view Shared Suppliers

    • Shared Suppliers enrolment - the Operator can now enrol a new Shared Supplier

    • B2B catalogue browsing - a vendor can now list products of a Shared Suppliers

  • Offers

    • Offer creation - a Vendor can now create an offer based on products of a Shared Supplier

    • Device quantity retrieval - a vendor can now retrieve the available quantities associated to a Device of a Shared Supplier.

  • Orders

    • Create order / shipping tariff and condition - a Vendor can now reference in an order a product of a Shared Supplier. A Vendor can now retrieve shipping tariffs and conditions associated to a Shared Supplier. A Vendor can now reference a shipping of a Supplier detail in an order.

    • BPM order workflows can now be executed on the SaaS platform e.g. Supplier User tasks, Supplier call backs which are initiated from the SaaS, etc.

      Please Note: Other processes are executed from the distributed platform.

    • Order histories - Operator and Vendor can retrieve order histories from the distributed platform. Shared Suppliers can retrieve order histories from the SaaS platform. Access to the Subscriber manager GUI is only available from the distributed platform.

  • LPWA Devices

    • Device provisioning / key encryptions and HSM integration - When a LPWA Device is provisioned from the Device Manager, the Device is provisioned from the distributed platform. When key encryptions apply (embedded encryption or HSM encryption), the encryption is executed from the distributed platform with distributed secret keys / distributed HSM.

    • Supply Chain integration / key encryptions and HSM integration - When a LPWA Device is provisioned from the Supply Chain of a Shared Supplier, the Device is provisioned from the SaaS platform. When key encryptions apply (embedded encryption or HSM encryption), the encryption is executed from the distributed platform with distributed secret keys / distributed HSM.

  • LPWA Base Stations – Base Station provisioning is processed from the distributed platform

ThingPark Applications Enhancements

To support the Shared Suppliers feature, the following ThingPark applications have been enhanced (only major changes are listed):

  • Operator Manager

    • The Operator will be able to verify the distributed platform connection to the Actility ThingPark SaaS platform. This option is only available (displayed) if a SaaS platform URL has been configured

    • The Shared Suppliers Operator, “B2B marketplace” Operator on the SaaS platform can view orders placed from distributed platforms and containing products from Shared Suppliers

  • Supplier Manager

    • A Shared Supplier can view orders placed from distributed platforms
  • Subscriber Manager

    • GUI enhancements to support asynchronous order creation
  • New Offer Activation Email templates

    • Templates have been enhanced to support new ordering status notifications

An example of a Shared Supplier order is displayed as follows:

Key Customer Benefits

This feature enables Actility Operators to enlarge their Marketplace capabilities by reaching new global IoT Suppliers offering through Actility Marketplace. It enables their local Vendor to bundle products both from local and global Suppliers hence be more competitive, innovative, win additional business and increase their revenues.

At the same time, ThingPark v4.2 proposes a transparent Offer bundling and ordering mechanism for Subscribers, making the entire on-boarding process easier out of the local Operator platform.

NFR#472: ThingPark Wireless Change of mapping service based on OpenStreetMap

Feature Description

Before ThingPark version 4.2 the mapping services were limited to Google Maps only. The scope of this NFR is to support an alternative mapping service based on OpenStreetMap in addition to Google Maps.

ThingPark v4.2 now proposes three distinct types of mapping services:

  • Google Maps that is the default ThingPark mapping services

  • OpenStreetMap implemented as part of this NFR using Leaflet JS API 1.0.3 ( ) and Nominatim search engine ( ).

  • No mapping services as already implemented in the scope of ThingPark v3.0.2 referenced in NFR426

To enable these mapping services two platform configuration levels are now available:

  • Administrator configuration level: defines the mapping services used when a web application is accessed as a module through SMP Backend

  • End User configuration level: defines the mapping services used when a web application is accessed through the User Portal or directly through ThingPark SSO

The following list describes the web applications and ThingPark Products that supports the new mapping functionality:

  • Network Manager Application - Yes

  • Device Manager Application - Yes

  • Wireless Logger Application - Yes

  • Network Survey – Yes

  • User Portal – Not in ThingPark Wireless v4.2

  • ThingPark X ONGBrowser – Not in ThingPark X v4.2

Typical Mapping Services Use Cases

Use Case 1: No internet access from ThingPark Operator network

In this use case, Administrators in a specific Operator NW (intranet) do not have internet access hence access to public mapping services is not possible.

Therefore, an OpenStreetMap Tile Server should be deployed within the Operator intranet to provide mapping services to Administrators. End Users can still benefit from Google Maps services.

In this use case, the following configuration is set:

  • Administrator level: OpenStreetMap service relies on local OpenStreetMap Tile Server

  • End Users level: Google Maps services relies on Operator’s API key

Use Case 2: alternative solution to Google Mapping services

In this use case, the Google Maps service is not operational, that is not available in the Operator’s NW as it might not be available national wide or the specific Operator requires to use an alternative solution for security or any other reason.

Contrary to the previous use case there is no internet access restriction. The optimal solution is to use public mapping services relying on OpenStreetMap such as Mapbox ( ). This public mapping service is used by both Administrators and End Users.

In this use case, the following configuration is set:

  • For both Administrator and End Users level: OpenStreetMap service relies on Operator’s Mapbox account (or any other OpenStreetMap provider)


As part of NFR#472, no OpenStreetMap Tile Server is delivered out of the box with ThingPark v4.2. OpenStreetMap Tile Server deployment guidelines can be provided by Actility. For more information please contact your Actility sales account manager or your technical manager.

Key Customer Benefits

This feature enables Operators to use different mapping services and removes the dependency on Google Maps services. This capability is essential for Operators, where the Google service is forbidden to use due to state regulations or if the Operator has security constraints and cannot ‘trust’ an external mapping services.

NFR#684: ThingPark Wireless Application (TWA) Redesign LRR ID Format, Length and Association

Feature Description

The current behaviour before ThingPark V4.2 was that the LRR ID (a 32-bit field) is uniquely to identify a LRR in the ThingPark platform. The LRR ID is statically associated to a Base Station and much depends on the specific Base Station vendor. This type of configuration and static association mechanism may eventually lead to LRR ID collisions and conflicts.

To solve this potential conflict, a Base Station will no longer be statically associated with a LRR ID rather than a unique LRR identifier to identify the Base Station among all ThingPark platforms. This field is called the LRR UUID .

The LRR UUID is composed of a vendor specific prefix followed by the Base Station identifier relatively to the vendor.

Please note that the previous Base Station provisioning and connection procedures are supported to handle cases where the Base Station has not yet upgrade with the latest LRR SW implementing NFR#684.

Feature Definitions

The following table gives a high-level description on the differences in between the association of a Base Station LRR ID before ThingPark v4.2 and after.

  • LRR ID

§ A LRR ID (32 bits) uniquely identifies a Base Station in ThingPark platform

§ LRR version < 2.2.20

A LRR ID is statically associated with the LRR and depends on the Base Station vendor. Such as:

o For Kerlink: extracted from its MAC address

o For Cisco: hash of Cisco S/N

o Etc.

§ LRR version >= 2.2.20

A LRR ID is dynamically associated with a Base Station (NFR#684)


§ A LRR UUID uniquely identifies a Base Station among all ThingPark platforms



o <LRR-OUI> is the IEEE OUI of the Base Station vendor (6 hexadecimal characters)

o <LRR-GID> is the Base Station identifier relatively to the vendor (allowed characters: [0-9][a-z]-_, maximum length: 256 characters)

§ For Kerlink: <LRR-GID> = full eth0 MAC address

§ For Cisco: <LRR-GID> = full Cisco S/N

§ Etc.

§ Please note that the LRR UUID may be forced through configuration file directly over the Base Station. For instance, to cope with the Kerlink duplicated MAC address problem.

Base Station Provisioning and Connection

The following new Base Station provisioning and connection procedures are applicable to LRR SW version >= 2.2.20.

The following image display the process of Base Station Provisioning where the Base Station is identified by a LRR UUID

Please note that in case of a Base Station migration into the LRR release >=2.2.20 the LRR UUID must be provisioned in the LRC before the LRR migration is being executed.

  • The LRC must know the LRR UUID in advance to accept the LRR connection after the migration

  • Therefore, the NFR also enables to generate the LRR UUID before executing the LRR migration procedure

LRR ID Dynamic Allocation

When a Base Station is provisioned using its LRR UUID, TWA allocates a free LRR ID to the Base Station. The high-level description of the process is the following:

  • The last generated LRR ID is retrieved from the DB and incremented. LRR ID initial value is 10000000.

  • If the LRR ID matches a reserved range (see below), the next unreserved LRR ID is chosen.

  • The Base Station is created using the generated LRR ID.

  • If the base Station creation fails because of the LRR ID already allocated, the entire procedure is retried in a limited number of attempts.

    The LRR ID ranges described below are currently reserved for static the LRR ID allocation in the LRR version \< 2.2.20. TWA does not use these ranges when allocating a new LRR ID to avoid any potential collisions.

  • Kerlink reserved LRR ID ranges:
  • 0802XXXX

  • 0804XXXX

  • 0805XXXX

  • 0806XXXX

  • 0808XXXX

  • 2900XXXX

  • 0B03XXXX

  • FF01XXXX

  • FF02XXXX

  • Cisco* reserved LRR ID ranges:

  • bc9eXXXX

  • 68XXXXXX

    Please note that this feature is not yet available for a Cisco type of Base Station. Please contact your Actility Technical contact point for more details.*

  • Multitech reserved LRR ID ranges:

  • 004aXXXX

  • 0011XXXX

  • Foxconn reserved LRR ID ranges:

  • 00XXXXXX – 0FXXXXXX (outdoor)

  • C0XXXXXX – CFXXXXXX (indoor) // Only 00XXXXXX and C0XXXXXX prefixes are currently in use

  • 16DCXXXX

  • Raspberry reserved LRR ID ranges:
    • No reserved ranges as the LRR ID is based on CPU ID

Network Manager Application Enhancements

The Network Manager Application GUI has been enhanced to support the provisioning and the allocation of the new LRR UUID.

If the Base Station allocation is set with LRR UUID, then

  • The “ID” field is now replaced with “LRR UUID” (mandatory text edit)

  • The “SMN” field has become optional

If the Base Station has been provisioned with LRR UUID, it means that the LRR UUID field could not be updated anymore:

If the Base Station has been provisioned with the LRR ID, the LRR UUID field can be later updated to enable future LRR migration to LRR SW version >= 2.2.20.

Key Customer Benefits

This feature strengthens, Actility OSS management capabilities by enabling an automatic and dynamic LRR unique identifier. It removes the possibility and probability of an internal ID collision and at the same time, eases the Base Station provisioning process by automating the process and by removing unnecessary provisioned user inputs.

NFR#721: ThingPark Wireless LRR/LRC Channel Configuration Enhancements

Feature Description

The purpose of this NFR is to set forward significant simplifications of the channel plan configuration, by centralizing most of the configuration parameters onto the RFregion file at LRC level.
Here below is a high-level summary over the introduced enhancements:

  • ThingPark Wireless RF Region mechanism is now extended to support the definition of US915 and AU915 RF Region configurations

  • There is no longer a distinction between US standard and US hybrid configurations

  • The LRC default installation process will now include the RF Region US915 and RF Region AU915 configuration files as defined in the LoRaWAN 1.0.2 regional parameters
  • These default RF Region files can be used to generate the TAR BALL, to be uploaded onto the Base Station
  • The Base Station (LRR) default installation will now include default configuration files for these two regions:
    • Channels_us915.ini

    • Channels_au915.ini

The uplink channel plan is removed from the lgw.ini and channels.ini

  • The RF Region data structure has now been extended with a new <ISMband> parameter. Please note that these enhancements mainly deal with the generation of the lgw.ini and channel.ini, therefore the ISM band regional parameter in the LRR.ini must still be pre-configured before the upload of the TAR ball for example [ism].band=us915 or [ism].band=au915. These parameters need to be set separately

Feature Limitations

The RF Tool can still generate symmetric configuration for radio board and for antennas only, as defined in NFR#682. Therefore, NFR#721 enhancement is limited for cases where the gateway uses a non-symmetric allocation on the radio boards or antennas. For instance, for a US Operator:

  • This enhancement maybe suitable for a pico-cell Base Stations

  • This enhancement may not be suitable for macro-cell Base Stations, that uses non-symmetric allocation on the radio boards and antennas. For macro-cell type of configurations, the TAR ball must still be generated manually on the LRC by an Administrator User. Once generated manually, the TAR ball can be used to upgrade the RF Region configuration on the macro-cell through the ThingPark standard processes, for instance through the Network Manager GUI or via a Web Service API.

Key Customer Benefits

This feature simplifies the LoRaWAN channel plan configurations, mainly for the US and AU regions, by centralizing most of the configuration parameters onto the RFregion file at LRC LRC level. Which in turn reduces the number of manual configuration processes done by the Administrator, reducing the probability of human errors and creates a seamless automatic integration process.

NFR#722: ThingPark User Portal End-User Management

Feature Description

The scope of this NFR is to allow the management of Subscriber End-Users via the ThingPark User Portal.

The following management functionalities will now be permitted:

  • Retrieve function (view) - retrieve the list of End Users and retrieve the attributes of a specific End User

  • Create function – create a new End User

  • Delete function – delete an End User

Here below is an image of an End-User Creation function dialogue:

Here below is an image of an End-User Retrieve / View function dialogue:

Feature Limitations

As all End Users share the same access rights (defined in the SMP), all End Users are permitted to List, Retrieve, Create and Delete other End Users, if they are associated to the same Subscriber account.

Key Customer Benefits

The User Portal is an after-sale self-care portal, acting as a single gateway to all purchased solutions within ThingPark. This feature extends its functionality to let Subscribers manage their organization independently to the Operator or the Vendor enabling more business and operational capabilities.

NFR#724: ThingPark Enterprise “In A Box” Early Availability v1

Feature Description

In this section, we will highlight and describe Actility new product offering ThingPark Enterprise Early Availability version 1.
ThingPark Enterprise is an Internet of Things (IoT) platform that allows to manage a LoRa® Network. ThingPark Enterprise Edition is a dedicated platform for companies to support their specific businesses.

ThingPark Enterprise “In-a-box” is a standalone deployment of the ThingPark Wireless solution on one single server, where HA is not required, on the enterprise premises, to manage a dedicated LoRa® network.

ThingPark Enterprise EA v1 is not a General Availability (GA) product offering and maybe offered to prospects and customers in a specific coordination with Actility sales on a case by case basis. For more information on the commercial offering, technical details, user guide or its roadmap please contact your Actility sales representative.
  • What Actility ThingPark Enterprise is*?

Please note that some items maybe future roadmap enhancements. The development, release, and timing are all subject to change.*

Business and Technical layers
Definition and Details
Commercial Offering
§ “In a Box” - ThingPark Wireless for Enterprise supports virtualized deployment on a single physical server
§ Reduced Upfront Costs - A Fully Centralized solution which in the future, the can manage multiple sites and therefore reduce upfront costs and TCO
§ Fast deployment - ThingPark Enterprise supports fast and agile deployment with virtualized components and pre-tested orchestration scripts
§ Highly Available - HA option includes second remote server installation with active-active operations, database replication and shared virtualized SAN (future item)
§ Available migration paths - ThingPark Enterprise Edition can be migrated to SaaS based platforms and Operator edition platforms (future item)
§ Set for specific usage
§ Can be set for private NW offering
§ Grants the following advantages:
§ Reduce RF interfaces and the number of collisions hence improve Quality of Service (QoS)
§ Enables a higher bitrate
§ Adapted to local spot coverage
§ Data may remain local
§ Dedicated radio planning
§ White spot coverage
§ Indoor coverage reinforcement
Business License Models
§ Simple and Self activation license models to enable the Enterprise to upgrade and even downgrade their capacity based on business and operational requirements.
§ License is restricted over software usage:
§ On a specific Hardware instance
§ For a limited number of activated Base Stations
§ For a limited number of activated Devices
§ For a limited period i.e. set with an expiration date
§ Primary target is a ThingPark Enterprise “In-a-box” offering the ThingPark Enterprise solution can also be deployed on the SaaS:
§ ThingPark Enterprise “In-a-box” deployment: On-customer premise LRR, LRC, OSS/BSS
§ ThingPark Enterprise “SaaS” deployment: On-customer premise LRR only
§ Sized for a specific capacity and hardware requirements
§ ThingPark Enterprise is built on top of an atomic Operating System and Docker
§ Each ThingPark component is deployed in a dedicated set of Docker container
§ ThingPark Enterprise uses Docker to limit the hardware resources used mainly the RAM
§ Actility Data Centre is the point to process software downloads and upgrades such as catalogues, Base Station firmware, SW upgrades, and so forth. and perform remote support activities
§ Simplified upgrade strategy using Docker mechanism - upgrades are applied by installing the version n+1, then by migrating data from version n to version n+1 and later deleting version n-2
§ Device Catalogue* - Device profile entities can no longer be directly created from the ThingPark Enterprise Admin GUI. Each instance version is predefined with a built-in catalogue of certified LoRa Devices. Only these Devices can be used with the ThingPark Enterprise version. To benefit from additional Devices, the Enterprise should:
§ Upload an updated list of certified LoRa devices from the Actility Data Centre.
§ Upgrade the Platform to version n+1, to benefit of an updated list of certified LoRa devices. Each time that a new ThingPark Enterprise version is built, the latest version includes the latest list of certified LoRa devices available at this specific time
§ Base Station Catalogue* - Base station profile entities can no longer be created from the ThingPark Enterprise Admin GUI. Each instance version is predefined with a built-in catalogue of certified Base Stations, each one associated with a certified LRR software version (for upgrade), and a certified Base Station ISO installation image to enable initial installations. Only these Base Stations and LRR software versions can be used with the ThingPark Enterprise version. To benefit from additional Base Stations, the Enterprise should:
§ Upload an updated list of certified Base Stations from the Actility Data Centre. The updated list may include new Base Stations, or may include latest version of LRR software for existing Base Stations.
§ Upgrade the Platform to version n+1, to benefit of an updated list of certified Base Stations. Each time that a new ThingPark Enterprise version is built, the latest version includes the latest list of certified Base Stations available at this specific time
§ Application Catalogue* - The list of applications is predefined in this initial ThingPark Enterprise version. To benefit from additional Applications the Enterprise should upgrade its Platform to a version n+1, to obtain an updated list of Applications
§ RF Region Catalogue* - RF Region profiles entities cannot be directly created from the ThingPark Enterprise Admin GUI. Each ThingPark Enterprise version is predefined with a built-in catalogue of certified RF Regions. Only these predefined RF Regions can be used with the ThingPark Enterprise version. For more RF Regions, the customer can:
§ Upload an updated list of predefined RF Regions from the Actility Data Centre
§ Upgrade the Platform to version n+1, to benefit of an updated list of predefined RF Regions. Each time that a new ThingPark Enterprise version is built, the latest version includes the latest list of RF Regions available at this specific time

* Please note that it may that not all ThingPark Wireless v4.2 Devices are certified in this ThingPark Enterprise version. A set of limited Base Stations, Applications and ISM / RF Region is available in ThingPark Enterprise v4.2. For more details please contact your Actility sales contact point.*
Data Models
§ Operator - Only one Operator is pre-defined. The operator configuration includes:
§ A pre-defined list of LoRaWAN settings
§ A pre-defined RF Region catalogue
§ A pre-defined Device catalogue
§ A pre-defined Base Station catalogue
§ A pre-defined, Applications catalogue
§ Subscriber - Only one Subscriber is pre-defined. The Subscriber represents the Enterprise. All Subscriber settings are pre-defined:
§ The subscription to the unique Offer (see Vendor model)
§ A default End User
§ Vendor - Only one Vendor is pre-defined with one single Offer. The Offer includes all Subscriber applications such as Device Manager, Network Manager, License Manager, Wireless Logger, RF Scan and Network Survey
§ Supplier - Only one Supplier is pre-defined with the relevant applications (see Vendor mode)
§ Network Partner - N/A. The Network Manager is integrated at the Subscriber level, to match the ThingPark Enterprise SaaS use case. In the ThingPark Enterprise SaaS, each enterprise is associated with a dedicated Subscriber
§ Connectivity Manager – Only one Connectivity Manager is pre-defined with one single Connectivity Plan type “unlimited”
As part of the overall solution different tools are available to operate the ThingPark Enterprise. Such as:
Global eco-system Dashboards and KPIs
§ Device Management
§ Base Station Management
§ Platform Management (via the Cockpit application please see below Operation and Maintenance section)
§ Alarm Management (future roadmap item)
§ SNMP alarms
§ Nagios infrastructure Monitoring
ThingPark Enterprise EA v1 has no support for UDRs creation. This functionality is a roadmap item.
Operation and Maintenance
The following procedures are available to the Enterprise Administrator
§ Platform Maintenance procedures
§ Platform troubleshooting procedures
§ Base Station Maintenance procedures
§ Base Station troubleshooting procedures
* Please note that several system administration actions are executed through the Cockpit Application. Cockpit is an easy-to-use, lightweight and simple yet powerful remote manager for GNU/Linux servers, it’s an interactive server administration user interface that offers a live Linux session via a web browser. Cockpit makes Linux discoverable thereby enabling system administrators to easily and reliably carry out tasks such as starting containers, managing storage, network configurations, log inspections coupled with several others. ThingPark Enterprise uses Cockpit for its platform installation, configuration, maintenance, monitoring and KPI, and so forth.
ThingPark Enterprise GUI is developed from scratch on a new Bootstrap Template Genius UI . Which enables a fast way to build modern administrator sites and dashboard for any browser or device. The advanced GUI is based on the following one single application basis –
Made for the non-advanced Enterprise users
§ Simple
§ GUI is ‘light’ and clear - limit useless text and decoration, avoid bad interpretations of links and icons
§ Fast
§ Ergonomic approach
§ Modular
§ Flexible
§ Designed for UX/UI best practices
§ Based on default configurations and preconfigured data models
UX (User Experience)
Actility ThingPark Enterprise UX is at the core of our Enterprise product. The UX is key for complex applications/site as users must be able to easily navigate the site and understand how to use it. Actility developed the Enterprise edition in such way to enable an interaction-rich experience to drive users back to the application as well as for those complex functions to become simpler and straight forward to use and function. The following guidelines were considered throughout the development of the ThingPark Enterprise Edition:
§ The site will be compatible with PCs and tablets
§ Content should ‘autofit’
§ The user is notified upon creation or update actions
§ Similar actions (and functionalities) are grouped together
§ Avoiding double click
§ Provide quick navigation from items list to item detail
§ Cross site consistency - re-usability and limited number of generic components
§ Provide inline field validation and notification
§ Deals with long backend requests
§ General options such as documentation (PDF) and support contact email are always available
§ Global search entry should always be available for the user e.g. I type in Device Friendly Name, or Device identifier such as DevEUI so the application will enter the Device § Management menu automatically for this specific Device
§ Anticipate user intent
§ When possible, help user predicting the value while typing
§ Use default values where applicable
§ Facilitate user choices
§ Avoid ambiguity
§ Limit number of choices
§ Provide contextual help
§ Support internationalization
§ Provide a way of indicating the user location within the website’ hierarchy
§ Consistent and Coherent style e.g. for different status of indicators
* Please note that some principals maybe future roadmap items
ThingPark Enterprise introduces the DX-API and DX-Bridge for simplification and the integration to Cloud Applications. DX API propose to ThingPark Enterprise the following features:
§ Simplified API for Device, Base Stations and Applications Provisioning
§ Use Defaults – less parameters to transfer and process
§ Limited and structured – list and document ThingPark Enterprise available API’s
§ A simplified authentication processes
§ Performs SMP backend authentication and authorization
§ Able to limit API actions only to authorized objects
§ DX is the single point of contact for the third-party applications:
§ HTTPS Generic
§ MyDevices
§ Azure
§ Watson Bluemix
Cloud Applications
Through its Administrator GUI ThingPark Enterprise offers and out-of-the-box activation and management of five Cloud Applications:
§ HTTPS Generic
§ MyDevices
§ Azure Watson Bluemix
These functions enable the association of Device routes into any Cloud Application with no additional effort from the Enterprise to develop a specific Cloud Application connector nor to maintain those connectors
On Boarding
ThingPark Enterprise is designed and thought in such way to enable a simple and fast Device, Base Station and Application on boarding. The process is built through user guided wizards with simplified user inputs and reduced number of user inputs
Innovative Product
ThingPark Enterprise is an innovative product. It is based on a design and development of a completely new product, conceptual changes in design of and the use of new components in the of established product

ThingPark Enterprise Appendix

Physical Layout

Base stations and the ThingPark Enterprise Admin GUI are connected through the local enterprise network. Links between the Base Stations and the ThingPark Enterprise Platform are secured over IPSEC. Links between the Admin GUI and the ThingPark Enterprise Platform are secured over HTTPS.

The Enterprise Application Server is a third party sub-system, e.g. MyDevice and Microsoft Azure, connected through the DX-API and DX-BRIDGE.
The Actility Data Centre is the midway point to process downloads such as catalogues, Base Stations firmware, SW upgrades, and so forth., and to perform remote support activities.
When a roaming agreement exists with a LoRa Operator, the Operator Data Centre is the midway point, to connect LoRa passive roaming toward/from the Operator LoRa network.
* Please note that Roaming is a ThingPark Enterprise roadmap item*

Standalone Deployment Server

ThingPark Enterprise uses Docker to limit the RAM footprint of the solution. Each ThingPark component is associated to a Docker container as highlighted in the following figure:

A container file system stores the execution environment of a ThingPark component. When a container is started, the container file system is initialized with the Docker image, and when the container is stopped, the container file system is lost.

ThingPark Enterprise Architecture

  • The implemented Architecture is displayed as follows:

Selected GUI Examples

  • The home page Dashboard image is displayed as follows:

  • The Base Station provisioning image is displayed as follows:

  • The specific Base Station Management image is displayed as follows:

  • The Application provisioning image is displayed as follows:

  • The specific Device management image is displayed as follows:

Key Customer Benefits*

ThingPark Enterprise is an Internet of Things (IoT) platform that allows to manage a LoRa® Network. ThingPark Enterprise Edition is a dedicated platform for companies to support their specific businesses.

How Actility ThingPark Enterprise offering helps Enterprises enable LoRaWAN IoT capabilities?
  • Security and privacy - Deploy ThingPark Enterprise in a local and in the future your own data centre. Single Sign On integration, robust and simplified permissions in software

  • Simple licensing model – Simplified licensing model enables at any moment to upgrade your capacity and quickly respond to business changes
  • World class support – Product and Eco-System documentation, support forms to contact Actility via a simple GUI access. Help is always available when it is needed most throughout using the Application
  • Compliance - Using highly regulated software, 3rd parties, GUI start up framework, LoRaWAN standards and more
  • Internationalization – Platform ready to be used by different languages in different regions
  • Flexibility and extensibility - product features extensible APIs for development of 3rd party’s applications
  • Cloud Based – For quick deployment the application can be available in a SaaS mode as well
  • Server Based - Deploy our software on your own server for extreme customization and on-site security
  • Actility Partners – Through Actility, engage with Actility Partners and System Integrators who specialize in IoT LoRaWAN enterprise deployments
Please note that some items maybe future roadmap enhancements. The development, release, and timing are all subject to change.*

NFR#758: ThingPark Wireless LRR/TWA Set Base Station Trace Level via the Network Manager Application

Feature Description

In some cases where the Base Station LRR SW makes too many flash writing, e.g. for writing log files, it may interfere the normal usage and behaviour of the LRR SW. To prevent such cases, the Network Manager application will enable and disable trace logging capabilities execution in a specific Base Station. The new functionality will also display the RAM disk usage level allocated for trace logging.
The LRR trace level can be set in a range of 0..3, where 0 is interpreted as no trace logging is activated. The trace level may be set to the current process execution only, in this case the trace level is automatically reset to 0 after a LRR restart or a reboot. It may also be set to persist to LRR restarts and reboots. Traces may be logged on the LRR SSD disk or through a RAM disk.

At any time, the user may be able to change the trace level or deactivated the trace logging.

  • The Network Manager will display the following:

  • Current trace level

  • If the RAM disk usage is activated or not
  • A timestamp of the trace activation or deactivation
A new Base Station alarm (112: Abnormal log activation) is triggered when abnormal trace level activation is detected:
  • Critical Alarm: trace level is set to 1, 2 or 3 when the RAM disk usage is not activated

  • Major Alarm: trace level is set to 1, 2 or 3 for more than one week when RAM disk usage is activated

Key Customer Benefits

This feature enables Network Partners to correctly operate their Base Stations in case of debugging and maintenance operations. It prevents potential cases where log files may damage and interfere a regular normal Base Station operation and enables better maintainability capabilities both for the Operators and Network Partners.

NFR#804: ThingPark Wireless Operator Search Fields

Feature Description

The scope of this enhancement is to allow Operator Users to find easily configured IoT network elements, namely Devices and Base Stations. Through the Operator Manager application an Operator User can now have the following experience:

  • A Device can now be searched by its DevEUI or DevAddr

  • A Base Station now can be searched by its LRR UUID or LRR ID

Depending on the specific Operator configuration the search context may be set to Local or Global:

  • Local scope: only Devices and Base Stations provisioned in the scope of the Operator are visible

  • Global scope: all Devices and Base Stations provisioned on the platform are visible

Local or Global search scope is an Operator parameter which enables Operators defined on a SaaS platform not to access network elements which are not provisioned in their network.

If a Base Station or a Device that belongs to another Operator and the search scope is set to Local: the search results are obfuscated with ******** except for the DevEUI and LRR UUID (correspondingly) column that contains the displayed text “Hidden (belongs to another Operator)”. This capability enables Operators to know that this specific element is already assigned (in-use) and cannot be provisioned on his specific instance.

The new Search capability is illustrated in the following capture:


  • Search by DevEUI, DevAddr, LRR UUID and LRR ID is a case insensitive

  • Search by prefix for DevEUI, DevAddr, LRR UUID and LRR ID is not supported

  • Search for Base Station by name is not implemented yet. This limitation will be solved in the scope of NFR#882

Key Customer Benefits

The search capability enabled a simple mechanism for Operator Users to globally search for network elements defined in their ThingPark platform.

NFR#830: ThingPark Wireless Enable a Join Server Solution without HSM

Feature Description

The behaviour and User experience before ThingPark v4.2 and as part of NFR#761, delivered in ThingPark v4.1, the HSM module was a mandatory element to be configured and implement in Join Server standalone mode. The main reason for this limitation was that the AS Key is required to encrypt the AppSKey in LRC-JS and the only solution to generate an AS Key was to use the HSM solution.
In the scope of NFR#830 we have uplift this limitation and allowed the Join Server in a standalone mode to be deployed without an HSM solution:
  • For Device creation - the AppKey is now encrypted with the LRC Cluster Key version of the Operator

  • For the AS Key generation - TWA generates the AS Key, instead of the HSM, and encrypts the AS Key with the LRC Cluster Key version of the Operator

    instead of the HSM Key version
  • The Join procedure is now fully executed by the LRC – the AppSKey is locally generated, encrypted with the AS Key and returned encrypted to the Network Server (NS)

Key Manager Application Enhancement

The Key Manager application is enhanced to grant the following new options:

  • Devices list is enhanced to differentiate Devices provisioned with HSM from Devices provisioned without an HSM

  • A Device can be provisioned without any HSM protection - in this case the

  • AppKey is encrypted with the LRC Cluster Key of the Operator

  • Devices can be imported without any HSM protection - in this case AppKeys are encrypted with the LRC Cluster Key of the Operator

  • AS Keys list is enhanced to differentiate AS Keys provisioned with HSM from AS Keys provisioned without an HSM
  • AS Key can be created without HSM protection - in this case AS Key is locally generated and encrypted with the LRC Cluster Key of the Operator.
    From the User experience point of view, the behaviour remains unchanged as the AS Key is returned encrypted with the RSA Public Key provided by the User

Key Customer Benefits

This feature enables Operators and their Customers to benefit from a complete Join Server solution without having the need to install an HSM solution. At the same time NFR#830 keeps in place the AS Key security requirements as instead of the HSM, TWA encrypts the AS Key with the LRC Cluster Key version of the Operator.

NFR#838: ThingPark Store v2

Feature Description

The purpose of this feature is to migrate ThingPark Store into Prestashop Version 1.6.  The major reasons to move into Prestashop Version 1.6 are as follows:

  • Introduce new and modernized UX/UI enhancements

  • Introduce new security patches and enhancements

  • Profit of its latest bug corrections fixes
  • Perform additional non-regression functional tests, to maximize ThingPark Store stability
  • Perform additional non-regression HA and scalability tests, to maximize ThingPark Store stability and performance
Here below are images from the ThingPark Store v2 based on the new Prestashop version.


No migration path is available from ThingPark Store v1 to ThingPark Store v2. A scratch installation is required to profit from the new Store v2 feature.

Key Customer Benefits

This feature enables Actility Marketplace Operators and Store Operators, to benefit from a new and refreshed version of the ThingPark Store. This version introduces a modernized UI/UX capabilities, enhanced security and stability capabilities as well as offer Operators an enhanced infrastructure to commercialize their IoT offering over the Marketplace.

NFR#880: ThingPark Wireless RX1 Delay Improvements

Feature Description

The behaviour and User experience before ThingPark v4.2 is that the LoRaWAN RX1 Delay is configured per RF Region only like in the following example:


This type of configuration does not permit to configure the RX1 Delay per specific Device types or a group of Device bundled by a Connectivity Plan.

A typical use case, will be in the case where a Device sends an uplink an AS, the AS would like to trigger a downlink in the very next RX1/RX2 windows of this specific uplink. The business case requires an immediate downlink message without the need to wait for another later uplink for the downlink to be sent to the Device. This maybe because of NW backhaul or AS latency too short to send
the downlink to the next RX1/RX2 window. To enable such functionality, it is required to support a different RX1/RX2 delays for a certain group of Devices e.g. per specific vertical market or for a specific B2B Subscriber use case.

Proposed Solution

The RX1 Delay parameter can now be configured from the following

  • The RF Region, an existing MACRxDelay1 parameter, that is mandatory

  • The Connectivity Plan, a new MinRx1Delay parameter, that is optional

  • The Device Profile, a new MinRx1Delay parameter, that is optional

The new MinRx1Delay is optional both in the Connectivity Plan and in the Device Profile. If set both in the CP and Device Profile, the value set in the CP takes precedence over the value set in the Device Profile.

The selection logic of the RX1 delay on a per-device basis is now implanted in the following manner:
If MinRx1Delay is not defined // nor in CP, nor in Device Profile
    Set RX1 delay = MACRxDelay1 // from RF Region
    RX1 delay = max (MACRxDelay1, MinRx1Delay) // max of CP / Device Profile or RF

Key Customer Benefits

This feature enables additional flexibility for Subscribers to manage their LoRaWAN Devices differently than those that are globally allocated to the same Operator and the same RF Region. This may be needed in cases such as to support a specific AS business requirements or specific NW configurations such as latency.

NFR#965: ThingPark Wireless Network Provider Wireless Logger Enhancements

Feature Description

This feature enables Network Provider to filter Wireless Logger Application records per Subscriber ID.

The Wireless Logger integrated at the Network Partner level will now support the following functionalities:
  • A new column of Subscriber ID (e.g. 100000021). The new column is added between the Local Timestamp column and the DevAddr column

  • A new Subscriber ID search criteria filtering. The new search criteria, is added after the LRC ID search criteria

  • The Subscriber ID is reported in when the User perform an export in CSV format

Please note that this enhancement, applies to the Network Provider Wireless Logger Application and not to a Subscriber Wireless Logger Application.
The new enhanced Application GUI is illustrated in the following capture:

Key Customer Benefits

This feature enables Network Partners to analyse Base Stations network data traffic per Subscribers. It enables to filter data per Subscriber ID and export the specific Subscriber report in CSV format for further data analysis.

Issues Resolved for Customer Project/Customer Support

This section lists the issues that are resolved in ThingPark 4.2

Release Version
Geoloc algo provisioning issues
Fields set to 0 in Device Profile GUI are set empty in the LRC
LRC considers MaxPower=14dBm for ADR V2
LRC doesn’t immediately send the channel mask to the device when ChMask=FF
MaxConcatenatedCommands in RFRegion doesn’t seem to be applied
Margin computed in LinkCheckAns not compliant with LoRaWAN 1.0
Wlogger DevAddr and DevEUI filtering fail to show
OTAA devices - RX delay issue when RFRegion configured with MACRxDelay1 different from the value configured in Device Profile
[CRM 763] Creation of Device profile unauthorized characters
TWA-Admin 5.6.18
Mantis 4848
Invalid downlink frame timestamp with packets coming -1s too soon
Mantis 4930
Core dumps on production platform
Mantis 5080
LRC CLI won’t display network provider id for online LRRs
Mantis 5106
[TWA] Battery expiration duration
Mantis 5119
Operator domain must not be editable
Mantis 4725
Operator domain must not be editable

About Actility

Actility is an industry leader in LPWAN (Low Power Wide Area) large scale infrastructure with ThingPark™, the new generation standard-based M2M communication platform. Actility’s ThingPark Wireless™ network provides long-range coverage for low-power sensors used in SmartCity, SmartBuilding and SmartFactory applications. Actility also provides the ThingPark X which provides
big data storage for sensor data and exposes sensor function through an open API allowing developers to provide vertical applications on top of rolled out sensors. To help vendors transform their sensors, Actility provides the ThingPark IoT platform which include embedded software solutions and cloud solutions to help devices connect to innovative applications. Via the ThingPark Market, an online marketplace engine dedicated to the IoT sensors, applications and network solutions, Actility enables the roll-out of new innovative IoT services for sensor vendors and network solution vendors. Actility is a founding member of the LoRa Alliance™: the largest, most powerful standards-based effort to enable the Internet of Things (IoT). Visit

    • Related Articles

    • Product Version 5.2 - Software Release Notes

            Versions Version  Date  Author Details  Rev1  2018-11-15  Actility  First Version  Rev2  2018-11-21  Actility  Addition of the following features: RDTP-7722, RDTP-7723 and RDTP-7746  Rev3  2019-03-04  Actility  Updated versioning (release 5.2 ...
    • Product Version 5.1 - Software Release Notes

      Scope The scope of this document is to describe the release notes of the ThingPark Wireless Product Software v5.1. Version 5.1 subcomponents versioning Version 5.1 list of new introduced features (User Stories) and release notes for all ThingPark ...
    • Product Version 6.0 - Software Release Notes

              Versions  Version Date Author Details Rev1 2019-07-25 Actility First Version. Rev2 2020-01-07 Actility - Addition of “Feature Interaction Matrix” for each feature. - Updated the Feature Activation details for LRC record/replay tools Rev3 ...
    • Product Version 4.3 - Software Release Notes

      Scope The scope of this document is to describe the release notes of the ThingPark Product Software v4.3. Version 4.3 subcomponents versioning Version 4.3 list of new introduced features (NFR’s) and release notes for all ThingPark software components ...
    • Product Version 5.0.1 - Software Release Notes

      Scope The scope of this document is to describe the release notes of the ThingPark Product Software v5.0.1. Version 5.0.1 subcomponents versioning Version 5.0.1 list of new introduced features (User Stories) and release notes for all ThingPark ...