Scope

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
  

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:

ThingPark Wireless

Sub component versioning:

ThingPark System

Sub component versioning

ThingPark X

Sub component versioning

ThingPark Enterprise

Sub component versioning s

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 https://www.openstreetmap.org/ 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 ( http://leafletjs.com ) and Nominatim search engine ( http://nominatim.openstreetmap.org ).
  

• 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 ( https://www.mapbox.com ). 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)
  

Limitations

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.

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:
  

• Cisco* reserved LRR ID ranges:
  

• Multitech reserved LRR ID ranges:
  
  
  

• Foxconn reserved LRR ID ranges:
  

• 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:

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

• 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 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:

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

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.

• What Actility ThingPark Enterprise is*?
  

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.

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.

• 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
  

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

Feature Description

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
  

• 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
  

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.

Limitations

• 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

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

Feature Description

• 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
  

Limitations

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.

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.

Key Customer Benefits

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.

• 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

Issues Resolved for Customer Project/Customer Support

About Actility