Product Version 5.1 - Software Release Notes

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 software components
  • Issues Resolved for Customer Project/Customer Support

Versions


Version

Date

Author

Details

01

2018-06-11

Shmulik Solomon & Ramez Soss

First Version

02

2018-07-18

Ramez Soss

Update for Gate-3

03

2018-08-06

Mariya Tasmagambetova

Subcomponents update

04

2018-08-31 

Nicolas Jombart

Update subcomponents versions

05 

2018-09-03 

Ramez Soss

Update roaming configuration in section 4.2 to account for RDTP-7110  

06

2018-09-07  

Ramez Soss & Marie-Laure Ancelle

Minor updates to TPW screenshots

07  

2018-09-17  

Nicolas Jombart

Add known issue section  

Reference Documents


 

Documents

Author

01

ThingPark Product Functional Description

Actility

02

ThingPark Version 5.1 Integration Notes

Actility

03

LoRaWAN 1.1

LoRa Alliance

04

LoRaWAN-Backend-Interfaces-v1.0

LoRa Alliance

05

LoRaWANRegionalParametersv1.0.2rBaspublished_1939_1

LoRa Alliance

06

TP_Wireless_4.2_Performance_Benchmark_Report

Actility

07

TP_Wireless_5.1_Passive_Roaming_Configuration_Guide

Actility

08

TP_Wireless_Radio_Parameters_User_Guide

Actility

Acronyms and Definitions


Acronyms

Definitions

ABP

Activation By Personalization

ADR

Adaptive Data Rate

AES

Advanced Encryption Standard

AS

Application Server

BPM

Business Process Management

BSS

Billing Support Systems

CSP

Communication Service Provider

DC

Duty Cycle

End Device

A sensor or actuator

ESP

Estimated Signal Power

ETSI

European Telecommunications Standards Institute

HAN

Home Area Network

HSM

Hardware Security Module

IaaS

Infrastructure As A Service

IEC

International Electrotechnical Commission

IoT

Internet of Things

ISM

Industrial Scientific Medical

GSCL

Gateway Service Capability Layer

GTM

Go To Market

KPI

Key Performance Indicator

LC

Logical Channel

LoRaWAN™

Long Range Wide Area NW

LPWAN

Low Power Wide Area Network

LRC

Long Range Controller

LRR

Long Range Relay

MAC

Media Access Control

M2M

Machine-2-Machine

MTBF

Mean Time Before Failure

NAT

Network Address Translation

NW

Network

NSCL

Network Service Capability Layer. Also called RMS.

OBIX

Open Building Information Exchange

OSS

Operations Support Systems

OTA

Over The Air

PER

Packet Error Rate

PKI

Public Key Infrastructure

POC

Proof Of Concept

REST

Representational State Transfer

RF

Radio Frequency

RIT

Receiver Initiated Transmit

RSSI

Received Signal Strength Indicator

SaaS

Software as a Service

SF

Spreading Factor

SLRC

Secured LRC (VPN Concentrator)

SMP

System Management Platform

SMTP

Simple Mail Transfer Protocol

SNMP

Simple Network Management Protocol

SNR

Signal to Noise Ratio

SSH

Secure SHell

SSO

Single Sign On

TLS

Transport Layer Security

TWA

ThingPark Wireless Application

UNB

Ultra Narrow Band

VM

Virtual Machine

VPN

Virtual Private Network

WS

Web Service


ThingPark Solution Overview

The ThingPark set consists of four main key components:

  • ThingPark Wireless – Core network and OSS
  • ThingPark OS
  • ThingPark X
  • ThingPark Enterprise

The ThingPark platform is a  modular solution enabling Network Operators to:

  • Deploy LPWANs based on LoRaWAN™ or LTE with  ThingPark Wireless .
  • Manage, activate and monetize IoT bundles (device, connectivity and application) with  ThingPark OS .
  • Provide value-added data layer services, such as protocol drivers and storage with  ThingPark X .

ThingPark OSS acts as the central System Management Platform (SMP), enabling all other ThingPark platform modules with base capabilities such as subscriber management, centralized authentication and access rights, and workflow management.

ThingPark Enterprise is an Internet of Things (IoT) platform that manages private LoRa® Networks. The ThingPark Enterprise edition is used by companies to support their specific business.




Figure 1 - ThingPark Solution Architecture Description High Level Product Illustration 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 OS

Sub component versioning:

MODULE

NAME

DESCRIPTION

VERSION

BILLING

billing

Online Billing

3.4.1

LOCALES

smp-auth-gui-locales

Localization

1.0.2-1

LOCALES

smp-billing-locales

Localization

3.4.1

LOCALES

smp-dashboard-kpi-gui-locales

Localization

2.0.3-1

LOCALES

smp-locales

Localization

9.8.5

LOCALES

smp-portal-locales

Localization

6.2.4

LOCALES

smp-thingparkstore-locales

Localization

4.0.8

LOCALES

smp-tpe-gui-locales

Localization

4.8.7-1

LOCALES

smp-twa-admin-locales

Localization

8.4.3

LOCALES

smp-twa-locales

Localization

9.10.11

LOCALES

smp-wlogger-locales

Localization

6.8.2

PORTAL

portal

User Portal

6.2.4

SMP

smp

System Management

9.8.5

SMP

smp-drivers

SMP drivers (bpmn workflows)

9.8.5

SMP

smp-drivers-tools

SMP drivers (bpmn workflows)

1.2.16

SMP-CRONS

smp-crons

Batch scripts on SMP executed by the crond

4.2.1

STORE

store-prestashop

Online Store Prestashop Module

4.0.1

STORE

store-thingparkstore

Online Store

4.0.16

STORE

store-tpspayment

Online Store Payment Module

4.0.4

ThingPark Wireless

Sub component versioning:

MODULE

NAME

DESCRIPTION

VERSION

CATALOGS

base-station-profiles

Base Stations Catalog

1.2.0

CATALOGS

device-profiles

Devices Catalog

4.0.6

CATALOGS

rf-regions

RF Regions Catalog

1.0.3

KK_BROKER

acy-kafka

Actility kafka server package

1.1.1

KK_BROKER

kpi-sample

Custom kpi samples

2.2.2

KK_BROKER

twa-kpi-kafka-fix-syntax

Rewrite untyped json to typed JSON messages

DEPRECATED

LRC

lrc

LoRa Network Server

1.12.14

LRC

lrclibs

LoRa Network Server librairies

1.12.14

LRC-PROVISIONING

lrc.binding.http

LRC http provisioning interface

1.34.2

LRR

lrr

Base Station

2.2.77

NETWORK-SURVEY

nssa-network-survey

Network Survey

1.10.0

RFTOOL

rfregtool

Generation tool of the packing of the RF region file on the LRC to prepare the provisioning of the LRR

1.1.6

SHELLINABOX

shellinabox-proxy

Proxy and security for shellinabox

2.0.1

SOLVER

locsolver

Location solver

1.2.13

SPARK

acy-azkaban-customkpi-scheduling

Custom Kpi Scheduling Configuration

1.1.0

SPARK

acy-azkaban-kpi-scheduling

Predefined Kpi Scheduling Configuration

1.1.4

SPARK

acy-azkaban-solo-server

Azkaban Solo Scheduling Server

3.35.0

SPARK

spark-history-server

Spark History Server

2.2.0

SPARK

spark-master

Spark Master

2.2.0

SPARK

spark-worker

Spark Worker

2.2.0

SPARK

twa-spark-kpi-dependencies-v1

kpi application commons dependencies

1.2.1

SPARK

twa-spark-kpi1 :: twa-spark-kpi10

Generate kpis from 1 to 10 and product to Kafka

2.4.9

SPECTRUM-ANALYSIS

nssa-spectrum-analysis

Spectrum Analysis

2.2.2

TPO_CONF

tpo-conf-ansible

Server configuration automation

0.1.8

TWA

twa

Wireless OSS (Network Manager / Device Manager)

9.10.12

TWA

twa-dev

Consumption of OSS.DEV Kafka topic for MongoDB integration

1.0.5

TWA-ADMIN

wirelessAdmin

Wireless OSS (Operator Manager / Connectivity Plan Manager)

8.4.3

TWA-CRONS

twa-crons

Batch scripts on TWA executed by the crond

6.0.0

TWA-DASHBOARD

twa-dashboard-ws

Dashboard KPI server

2.2.4

TWA-DASHBOARD

twa-dashboard-ws-script

Dashboard KPI server tools

2.2.4

TWA-SUPPLY-CHAIN

twasupplier

Supply Chain (Application sample)

6.0.1

TWA-SUPPLY-CHAIN-CRONS

twasupplier-crons

Batch scripts on Supply Chain executed by the crond

1.0.0

TWA_KPI

twa-kpi-kafka

Consumption of KPIs in Kafka and import to MongoDB

2.4.6

WLOGGER

wlogger

Wireless Logger

6.8.2

ThingPark System

Sub component versioning:

MODULE

NAME

DESCRIPTION

VERSION

ALL

acyec

Actility PHP module to decrypt php files

1.0.0

ALL

maxscale-tools

Maxscale Tools (logrotate)

1.0.1

ALL

tpk-extra-tools

Tool to manage configuration files

1.4.4

ALL

wildfly-9.0.2

Wildfly version 9.0.2

final12

AS-PROXY

nginx-as-proxy-conf

NGINX configuration package for AS-Proxy

2.0.1

HTTP-PROXY

nginx-http-proxy-conf

NGINX configuration package for HTTP-proxy

8.0.3

MONGO

mongo-tools

MongoDB Tools Actility (logrotate)

1.4.6

MONGO

twa-kpi-mongo

TWA KPI mongo scripts for mongo database

2.4.7

MONGO

twa-mongo

TWA mongo scripts for mongo database

9.10.11

SQL

acy-liquibase

Actility SQL Upgrade engine based on LiquiBase

1.0.2

SQL

mysql-tools

Mysql Tools (script saveDatabase, restoreDatabase, logrotate)

1.2.2

SQL

smp-sql

SMP SQL scripts for SQL database

9.8.5

SQL

twa-sql

TWA SQL scripts for SQL database

9.10.11

TOOLS

tool-module-initialization

Initialize module like network Manager, Application manager

1.2.0

WEBAPP

smp-auth-gui

SMP Authentication GUI

1.0.2-1

WEBAPP

twa-dashboard-kpi-gui

Dashboard KPI GUI

2.0.3-1

Version 5.1 Newly Introduced Features (User Stories)

LoRaWAN Standard Alignment Features

LoRaWAN 1.1 MAC layer protocol

Feature Description

ThingPark Wireless/Enterprise release 5.1 introduces the support of LoRaWAN1.1 MAC-layer protocol, in compliance to [3].

All the mandatory functionalities required to successfully onboard LoRaWAN1.1 devices are introduced in this release, specifically:

  • Support of LoRaWAN1.1 JOIN procedures for OTA devices (RDTP-2213 and RDTP-4571):
  • Provisioning of LoRaWAN1.1 session keys for ABP devices (RDTP-3250): To onboard LoRaWAN1.1 ABP devices, ThingPark Device Manager allows provisioning of the following session keys: FNwkSIntKey, SNwkSIntKey, NwkSEncKey and AppSKey (optional). These keys are used the same way as OTAA devices, except that they are personalized during device manufacturing and are used along the device lifetime.
  • Encryption of all MAC commands (RDTP-2212): As mandated by LoRaWAN1.1, all the uplink and downlink MAC commands - whether sent in FOpts field (i.e. piggyback mode) or sent in FRMPayload space (Fport=0) MUST be encrypted by the NwkSEncKey. Nevertheless, to ease troubleshooting using WLogger tool, the MAC commands are sent in clear format (i.e. unencrypted) to TWA/WLogger.
  • Support of LoRaWAN1.1 frame authentication for both uplink and downlink frames (RDTP-2228): LoRaWAN1.1 protocol implies new rules to compute Message Integrity Code (MIC) for uplink and downlink messages. These are detailed by sections 4.4.1 (downlink MIC) and 4.4.2 (uplink MIC) of [3]. Uplink MIC is based on FNwkSIntKey + SNwkSIntKey whereas downlink MIC is based on SNwkSIntKey.
  • Support of LoRaWAN1.1 downlink frame counter management (RDTP-2229): LoRaWAN protocol splits the downlink frame counter management into two counters: NFCntDn (maintained by NS and used when downlink Fport = 0 or empty) and AFCntDn (maintained by AS and used when downlink Fport > 0).

In LoRaWAN1.1, the session keys are based on 2 root keys: AppKey (existing from LoRaWAN1.0) and NwkKey (new for LoRaWAN1.1). Based on these 2 root keys, the following network session keys are derived for each OTA device:

  • FNwkSIntKey (derived from NwkKey): Forwarding Network Session Integrity Key, may be shared by sNS to stateful fNS to allow partial MIC validation by fNS for a roaming device (note that this key is not known to fNS in stateless passive roaming mode).
  • SNwkSIntKey (derived from NwkKey): Serving Network Session Integrity Key, used by sNS to validate half of the MIC for uplink frames.
  • NwkSEncKey (derived from NwkKey): Network Session Encryption Key, used to encrypt all the MAC commands exchanged between the device and sNS.
  • AppSKey (derived from AppKey): Application Session Key, used to encrypt application payload.
  • JSIntKey (derived from NwkKey): Join Server Integrity Key, used to sign (MIC computation) JoinAccept messages.
  • JSEncKey (derived from NwkKey): Join Server Encryption Key, used to encrypt the JoinAccept triggered by a rejoin request (not relevant for TPW release 5.1, see “Feature Limitations” section).

These session keys are derived by LRC (or HSM if applicable) after each new join procedure.

To fully support JOIN procedures as per LoRaWAN1.1, ThingPark release 5.1 supports the RekeyInd/RekeyConf MAC command: To validate the JOIN procedure, the LRC waits for a RekeyInd command coming from the device and responds with a RekeyConf. The LRC ignores any UL frame sent after the Join Accept and before RekeyInd, for a LoRaWAN1.1 device.

In ThingPark release 5.1, LoRaWAN1.1 OTAA join procedures are supported for the following LRC deployment modes:

  • LRC combo mode (i.e. combined NS/JS functions in the same LRC server), both with and without SSM/HSM security modes.
  • LRC separate NS/JS mode (i.e. standalone JS functionality) with SSM/HSM security.

NOTE: To allow backward compatibility with Application Servers implementing both LoRaWAN 1.0 and 1.1, the following rule is maintained for LoRaWAN1.1 devices:

If AppKey is provisioned/known to LRC (i.e. in legacy mode without SSM/HSM), the LRC encrypts the downlink payload and hence it also manages AFCntDn. Otherwise, when AppKey is not known to LRC (typically in SSM/HSM security modes), both downlink frame encryption and AFCntDn management are handled by AS.

  • Support of necessary ADR modifications for LoRaWAN1.1 devices (RDTP-2230):

LoRaWAN1.1 introduces 3 modifications to uplink ADR:

  • ADR-bit of UL frames: A new value (0xF) is introduced in TxPower & DataRate tables to represent a "don't care" setting. The LRC uses this new value for TxPower & DataRate when it needs to send LinkADRReq command to configure the channel mask of the device.
  • ADR-bit of DL frames: According to section 4.3.1.1 of [3], if the LRC wants the device to use network-controlled ADR, it sets ADR-bit = 1 in downlink frames. Hence, starting release 5.1, the ADR-bit = 1 for all devices whose LinkADRReq command is enabled in the Device Profile settings.
  • Device response to an atomic LinkADRReq block (only valid for us915, au915 and cn470 ISM bands): A LoRaWAN1.1 device answers an atomic LinkADRReq block (made of several LinkADRReq commands) by sending a single LinkADRAns. This is not the case for LoRaWAN1.0 devices where the device sends an answer to each command in one uplink block response.

NOTE: Devices supporting LoRaWAN1.1 protocol should be associated with a specific Device Profile having MAC Major Version = 0 and MAC Minor Version = 10.

Key Customer Benefits

Thanks to the features described above, ThingPark customers can onboard LoRaWAN1.1 devices in their networks, leveraging all the advantages offered by this new MAC protocol:

  • Enhanced security:
    • Use of 2 different root keys (NwkKey and AppKey) in LoRaWAN1.1 instead of a single root key (AppKey) in LoRaWAN1.0
    • Use of separate network session keys for encryption and integrity
    • Strong protection against replay attacks, through improved MIC computation, use DevNonce & JoinNonce as never-wrapping counters

  • Enforced privacy:
  • AppKey provisioning in the Network Server is not mandatory anymore.
  • All MAC commands are encrypted.

Feature Activation  

The features described above are only applicable for LoRaWAN1.1 devices. These devices MUST be associated with a Device Profile whose MAC minor version = 10.


Feature Limitations

The LoRaWAN1.1 implementation in release 5.1 has the following limitation (will be lifted in future ThingPark releases):

  • For OTAA devices:
    • REJOIN procedures are not supported.
    • Only CFListType 0 is supported in release 5.1. Hence, CFList is only used for eu868, as923, kr920, in865, eu433, cn779 (not used for us915, au915, cn470).

  • For ABP devices: The ResetInd/ResetConf MAC commands are not supported.
  • For Class C devices: DevModeInd/DevModeConf MAC commands are not supported.
  • The ADRParamSetupReq/Ans MAC commands are not yet supported in release 5.1.

RDTP-4572: NS-JS interface alignment to Backend Interfaces specification 1.0

Feature Description

This feature implements the necessary alignments to the NS-JS interface to make it fully compatible with the LoRaWAN Backend Interface specification (for more details, please refer to [4]).

This feature is mainly relevant for LRC deployments where NS and JS functionalities are separated on different servers.

The <ForeignOperator> table should be configured on both sNS and standalone JS sides:

  • On sNS side, the ForeignOperator table defines the JS routing point (so that sNS can route the JoinReq message to the right JS).
  • On JS side, the ForeignOperator table defines the sNS routing point (so that JS can route the JoinAns message to the right sNS).

Additionally, sNS (respectively JS) should also be configured with TrustedOperator table to authorize incoming frames from JS (respectively sNS).

The following diagram illustrates the table configurations required on ThingPark sNS and standalone-JS sides:



Example for sNS configuration:
<ForeignOperator>

    <AppEUI>A34A34A341233434</AppEUI>                   // AppEUI is the key

    <ReceiverID>A34A34A341233434</ReceiverID>       // ReceiverID = AppEUI/JoinEUI

    <RoutingProfileJS>js-ope1</RoutingProfileJS>

</ForeignOperator>


NOTE: Used to route JoinReq.


 <TrustedOperator>

    <SenderID>A34A34A341233434</SenderID>             // SenderID is the key (= JS’s AppEUI)

 </TrustedOperator>


NOTE: Used to authorize JoinAns.

Example for JS configuration:

<ForeignOperator>

<ReceiverID>AA3434</ReceiverID> // ReceiverID is the key (= sNS NetID)

<RoutingProfileSNS>sns-ope1</RoutingProfileSNS>

</ForeignOperator>

NOTE: Used to route JoinAns.

 <TrustedOperator>

<SenderID>AA3434</SenderID> // SenderID is the key (= sNS NetID)

<User>operator1</User> // Only relevant for HTTP Digest authentication

<Password>pwd_generated_by_operator1</Password> // only for HTTP Digest authentication

 </TrustedOperator>

NOTE: Used to authorize JoinReq.

NOTE: ThingPark release 5.1 supports only the asynchronous mode for NS/JS interface. In this mode, the JoinAns is sent as a separate HTTPS Post (i.e. not included in the HTTP response of the JoinReq).


NS                                                JS

       POST JoinReq ------------>

      <-----------              200 OK


      <-----------             POST JoinAns

      200 OK             ------------>


Key Customer Benefits

This feature allows the ThingPark Operator to connect its Network Server (NS) to any third-party Join Server (JS), leveraging the standardized NS-JS interface (provided that this JS implements the HTTP asynchronous mode).

It also allows Actility’s JS to interoperate with any third-party NS, in the scope of the JSaaS offer (also known as Activation Service).


Feature Activation

This feature is activated as soon as the right configuration tables (TrustedOperator and ForeignOperator) are set in NS and JS sides after ThingPark upgrade to release 5.1.

This feature is only relevant when the LRC needs to communicate with an external JS, it has no impact for LRC combo-mode (i.e. both NS and JS functions are combined in the same LRC virtual machine).


Feature Limitations

In release 5.1, only asynchronous HTTP mode is supported between NS and JS, this means that third-party JS providers should use asynchronous mode.

Roaming Features

IMPORTANT NOTE:

Release 5.1 implies a configuration change of the roaming tables “RoamingOperator” and “TrustedOperator” due to the implementation of RDTP-4572 and RDTP-6122; this latter feature lifts the TPW5.0.1 limitation on roaming configuration in multi-operator environments.  Hence, thanks to RDTP-6122, the roaming configuration tables become fully independent for each ThingPark Operator NetID even if multiple operators share the same LRC (in SaaS mode).

  • RoamingOperator: This table is used by the LRC for all the outgoing messages related to passive roaming, namely PRStartReq and XmitDataAns messages sent by fNS as well as PRStartAns and XmitDataReq messages sent by sNS.

As of release 5.1, the attribute <NetID> MUST be replaced by <ReceiverID> in RoamingOperator tables.

Additionally, the file index MUST be Net_* <HomeNetID> -Net_ <PartnerNetID>* or  Net_* <HomeNetID> -Nwk_ <PartnerNwkID>* or  Net_* <HomeNetID> -App_ <Partner or JS AppEUI>*
NOTE:  PartnerNwkID in the filename should be set over 32 bits (8 Hexa characters) to accommodate NetID type 4,5,6 and 7 (RDTP-7110).


Example of RoamingOperator table structure:

cat Net_000002-Net_00000a // Home NS NetID (here the SenderID) = 000002

<?xml version="1.0" encoding="UTF-8"?>

<RoamingOperator xmlns=" http://uri.actility.com/lora ">

   <ReceiverID>00000a</ReceiverID>                                                                // ReceiverID = NetID of peer NS

   <NwkID>000a</NwkID>

   <AppEUI>a34a34a341234567</AppEUI>

   <RoutingProfileSNS>NetID_SNS_00000a</RoutingProfileSNS>

   <RoutingProfileFNS>NetID_FNS_00000a</RoutingProfileFNS>

   <RFRegionPRInterpretation>IsmBand</RFRegionPRInterpretation>      //RDTP-1676

</RoamingOperator>


NOTE: If HTTP basic authentication is used, the User/Password/KeyVersion fields should be directly set in the routing profile, not in the RoamingOperator table anymore.

  • TrustedOperator: This table is used by the LRC to authenticate all the incoming messages related to passive roaming, namely PRStartReq and XmitDataAns messages (sNS side) as well as PRStartAns and XmitDataReq messages (fNS side).

As of release 5.1, the attribute <NetID> MUST be replaced by <SenderID> in TrustedOperator tables.

Additionally, the file index MUST be Net_* <HomeNetID> -Net_ <PartnerNetID>* or  Net_* <HomeNetID> -App_ <JS_AppEUI>*

Example of TrustedOperator table structure:

cat Net_000002-Net_00000a // Home NS NetID (here the ReceiverID) = 000002

<TrustedOperator xmlns=" http://uri.actility.com/lora ">

   <SenderID>00000a</SenderID>

   <User>operator1</User>                                                 // optional entry, required for basic authentication

   <Password>pwd1</Password>                                       // optional, for basic authentication

   <KeyVersion>version1</KeyVersion>                            // optional, for basic authentication

</TrustedOperator>

For more details about passive roaming configuration, please refer to [7].

NOTE

The per-operator roaming configuration offered by RDTP-6122 refers to an operator as a distinct NetID (and  not as a ThingPark Operator).

Therefore, when several ThingPark Operators (each one identified with a dedicated operatorID) share a same NetID , these operators must share a common roaming agreement (i.e. common roaming/trusted operator tables).

If a ThingPark Operator (identified with a dedicated operatorID) needs to have a dedicated roaming agreement, this operator must have a dedicated, Type 0 or Type3 NetID (in this way it can have dedicated roaming/trusted operator tables).

RDTP-4575: Support of HomeNsReq/HomeNsAns

Feature Description

In release 5.0.1 , to support passive roaming activation (also known as activation away from home), in order for fNS to route the JoinReq message to the right sNS, a static configuration had to be applied in the RoamingOperator table of fNS. Therefore, the AppEUI (also known as JoinEUI in LoRaWAN1.1) is directly mapped to the sNS NetID / routing profile in fNS’s RoamingOperator table and the JoinReq is sent inside a PRStartReq message from fNS to sNS.


Example of fNS configuration in release 5.0.1 (used to route JoinReq to sNS):


cat App_a34a34a341234567

<?xml version="1.0" encoding="UTF-8"?>

<RoamingOperator xmlns=" http://uri.actility.com/lora ">

   <NetID>00000a</NetID>

   <NwkID>000a</NwkID>

   <AppEUI>a34a34a341234567</AppEUI>

   <RoutingProfileSNS>NetID_SNS_00000a</RoutingProfileSNS>

   <User>operator1</User>                                                 // optional entry, required for basic authentication

   <Password>server_password</Password>                   // optional, for basic authentication

   <KeyVersion>version1</KeyVersion>                            // optional, for basic authentication

</RoamingOperator>


In release 5.1 , this limitation is lifted to ensure full compatibility with Passive Roaming call flows defined in LoRaWAN Backend Interfaces specification [4]. Hence, rather than relying on direct mapping between AppEUI and sNS routing profile, RDTP-4575 implements HomeNsReq/HomeNsAns messages between fNS and JS – as per the following diagram:





HomeNsReq queries the sNS NetID of a given DevEUI, the answer is provided by HomeNsAns send by JS to fNS.

To support this call flow, the RoamingOperator tables in fNS need to configure a JS routing profile to route HomeNsReq message, as per the following example:


cat Net_000002-App_a34a34a341234567 // fNS NetID = 000002

<?xml version="1.0" encoding="UTF-8"?>

<RoamingOperator xmlns=" http://uri.actility.com/lora ">

   <ReceiverID>a34a34a341234567</ReceiverID>

   <AppEUI>a34a34a341234567</AppEUI>

   <RoutingProfileJS>js-ope1</RoutingProfileJS> // JS routing profile

</RoamingOperator>


NOTE: To maintain backward compatibility between release 5.0.1 and release 5.1, the LRC supports the following mechanism:

  • If fNS finds a valid RoutingProfileSNS point of contact matching the AppEUI/JoinEUI present in the JoinReq frame, it directly forwards the JoinReq to sNS inside PRStartReq message without sending HomeNsReq query to JS (same behavior as release 5.0.1).
  • Otherwise, if fNS doesn’t find a valid RoutingProfileSNS for this AppEUI/JoinEUI but finds a valid RoutingProfileJS point of contact, it sends a HomeNsReq query to JS as per the LoRaWAN call flow described above.

The following diagram illustrates how the different roaming tables (RoamingOperator, TrustedOperator and ForeignOperator) are used to route outgoing messages and authorize incoming messages between the different components of the LoRaWAN backend: fNS, sNS and JS.





Key Customer Benefits

Thanks to this feature, Passive Roaming Activation (also known as activation away from home) becomes fully compatible with LoRaWAN message flows.

Without this feature, Passive Roaming Activation is only possible when there is a direct/single mapping between AppEUI and sNS NetID; which is not necessarily the case when devices are pre-commissioned on generic Join Servers that do not belong to a specific Network Provider.

Hence, this feature makes Passive Roaming Activation fully compatible with generic device activation mode (for instance with JS-as-a-service deployment scenarios).


Feature Activation

To activate this HomeNSReq/HomeNSAns message exchange between fNS and JS, additional configuration settings should be applied to the RoamingOperator/TrustedOperator tables on fNS and JS sides.

fNS configuration: the network operator should create files in /home/actility/FDB_lora/ROp/ to map remote Join Server AppEUI (in this example a34a34a341234567) to a routing profile – as illustrated by example below:


cat Net_000002-App_a34a34a341234567 //fNS NetID = 000002 in this example

<?xml version="1.0" encoding="UTF-8"?>

<RoamingOperator xmlns=" http://uri.actility.com/lora ">

   <ReceiverID>a34a34a341234567</ReceiverID>

   <AppEUI>a34a34a341234567</AppEUI>

   <RoutingProfileJS>js-ope1</RoutingProfileJS>                                  // JS routing profile

</RoamingOperator>


NOTE: The example shown by the table above is used to route HomeNsReq from fNS to JS (defining the JS routing profile).

Then, the operator should add the corresponding JS routing profiles in /home/actility/FDB_lora/r/, as per the following example.


cat js-ope1

<?xml version="1.0" encoding="UTF-8"?>

<RoutingProfile xmlns=" http://uri.actility.com/lora ">

   <ID>js_ope1</ID>

   <Descs>

      <Desc Port="*"> http://10.100.31.100:8807 </Desc>

   </Descs>

   <User>operator1</User>                                                          // optional entry, required for basic authentication

   <Password>server_password</Password>                            // optional, for basic authentication

   <KeyVersion>version1</KeyVersion>                                     // optional, for basic authentication

</RoutingProfile>


To authorize fNS to receive HomeNsAns from JS, the network operator should create TrustedOperator tables in the LRC under /home/actility/FDB_lora/TrustedOp with a configuration like the example below should be added to fNS:

Example of TrustedOperator table structure:


cat Net_000002-App_a34a34a341234567 //fNS NetID = 000002 in this example

<TrustedOperator xmlns=" http://uri.actility.com/lora ">

   <SenderID>a34a34a341234567</SenderID>

   <User>operator1</User>                                                          // optional entry, required for basic authentication

   <Password>pwd1</Password>                                                // optional, for basic authentication

   <KeyVersion>version1</KeyVersion>                                     // optional, for basic authentication

</TrustedOperator>


NOTE: The example shown by the table above is used to authorize HomeNsAns from JS to fNS.


JS configuration:

Creation of RoamingOperator tables, indexed by NetID (used to route HomeNsAns)

<RoamingOperator>

    <ReceiverID>AA3535</ReceiverID> // ReceiverID = fNS NetID

    <RoutingProfileFNS>fns-ope2</RoutingProfileFNS>

</RoamingOperator>

Creation of TrustedOperator tables, indexed by NetID (used to authorize HomeNsReq)

 <TrustedOperator>

    <SenderID>AA3535</SenderID> // SenderID = fNS NetID

 </TrustedOperator>

Feature Limitations

Not applicable.


RDTP-4576: Support of wildcarded <RoamingOperator> on the fNS

Feature Description

In release 5.1, thanks to RDTP-4575, fNS can send HomeNsReq queries to JS to request the NetID of a given DevEUI. To route the HomeNsReq to the appropriate JS, the network operator must configure a RoamingOperator table for each AppEUI to define its routing profile.

This one-by-one configuration is quite manageable when the number of AppEUIs concerned by the operator’s roaming agreements are relatively limited. However, if there are hundreds of such AppEUIs to be configured on fNS side and these AppEUIs represent a single JS point of contact (e.g. case of JSaaS), it becomes impractical to define a RoamingOperator table for each AppEUI.

RDTP-4576 supports wildcarding of the RoamingOperator table for fNS-JS interface. Below is an example of a wildcarded RoamingOperator table to route HomeNsReq messages from fNS to JS:


cat Net_000002-APP_DEFAULT // fNS NetID = 000002 in this example

<?xml version="1.0" encoding="UTF-8"?>

<RoamingOperator xmlns=" http://uri.actility.com/lora ">

   <AppEUI>APP_DEFAULT</AppEUI>

                                                                                                                                                // ReceiverID is not set

   <RoutingProfileJS>js-ope1</RoutingProfileJS> // JS routing profile

</RoamingOperator>


When wildcarding is used, the LRC needs to know which Join Request messages can be locally handled (i.e. pointing to its local JS function) so that they are not routed to JSaaS but rather processed locally. Therefore, a RoamingOperator table should be configured by the operator to identify which AppEUIs are exempted from the wildcarding function; such table should not include any routing profile configuration – as per the following example

cat Net_000002-App_a34a34a341234999 //fNS NetID = 000002 in this example


<?xml version="1.0" encoding="UTF-8"?>

<RoamingOperator xmlns=" http://uri.actility.com/lora ">

   <AppEUI>a34a34a341234999</AppEUI>

</RoamingOperator>


Likewise, to authorize HomeNsAns from JSaaS, the SenderID of the TrustedOperator table can be wildcarded as per the following example:


cat Net_000002-APP_DEFAULT //fNS NetID = 000002 in this example

<TrustedOperator xmlns=" http://uri.actility.com/lora ">

   <SenderID>APP_DEFAULT</SenderID>

   <User>operator1</User>                                                    // mandatory entry, required for basic authentication

   <Password>pwd1</Password>                                          // mandatory, for basic authentication

   <KeyVersion>version1</KeyVersion>                               // mandatory, for basic authentication

</TrustedOperator>


NOTE: HTTP basic authentication is mandatory when TrustedOperator table is wildcarded.


Key Customer Benefits

This feature simplifies the roaming configuration between fNS and JSaaS.


Feature Activation

This feature is activated by special configuration in RoamingOperator and TrustedOperator tables on fNS side, as detailed in the feature description.


Feature Limitations

Not applicable.

Scalability Features

RDTP-2745: LRC multi-threading and performance improvement

Feature Description

Prior to release 5.1, the LRC processing consists of 2 threads:

  • lrc-main thread: handling the IEC-104 interface with LRRs (also known as RAN interface) + LoRaWAN processing.
  • lrc-lrn thread: handling the HTTP/HTTPS interfaces towards TWA, AS and peer-LRC. This thread is protected against non-responsive AS, thanks to RDTP-2874. For more details about LRC performance benchmark in previous releases, please refer to [6].

Therefore, the maximum LRC capacity expressed in messages/sec – aggregating both UL and DL LoRaWAN frames - is 220 messages/sec, yielding ~70% average vCPU load.


Starting release 5.1, thanks to RDTP-2745, the LRC becomes fully multi-threaded: Multithreading of the lrc-lrn + multithreading of the lrc-lora (new thread dedicated to the LoRaWAN processing) so that the working thread may use all VM vCPUs.

This feature brings substantial gains on LRC scalability, allowing the LRC to support up to 1500 messages/sec in release 5.1, assuming 16vCPU.


Please note, however, that the overall end-to-end capacity limit in release 5.1 is 1000 messages/sec; the bottleneck being on MongoDB side (but this limitation shall be lifted in release 5.2 thanks to MongoDB sharding feature.


NOTE: In release 5.1, the maximum number of LRR connections per LRC is 30K.


Key Customer Benefits

This feature brings substantial gain to LRC capacity, supporting LRC traffic load up to 1500 messages/sec (both UL and DL traffic combined) with 16vCPU; hence providing a > x6 capacity gain factor versus previous releases.

In addition to capacity gains, the full multithreading of lrc-lrn process (handling HTTP connections towards TWA/AS) has a significant positive impact on LRC performance stability.


Feature Activation

This feature is activated by default.

The number of threads allocated to lrc-lrn and lrc-lora processes is defined by system-wide parameters in lrc.ini, as follows:

[threads]

LoRa=4 // 4 threads by default for LoRaWAN processing

Lrn=4 // 4 threads by default for HTTP/HTTPS interface with TWA/AS/Peer LRC


Feature Limitations

Not applicable.

MAC Efficiency and Performance Optimization Features

RDTP-2924: Allow Forcing RX2 data rate in Multicast Connectivity Plan

Feature Description

In release 5.0.1, the RX2 data rate used for class C multicast is always derived from the RF Region configuration. This implementation had a known limitation with respect to NFR-749 (where the RX2 data rate of the  unicast device may be forced in the Connectivity Plan).


In release 5.1, RDTP-2924 allows setting the RX2 data rate in the multicast connectivity so that it can be used by the LRC instead of the RX2 data rate defined in the RF Region configuration.


Hence, this feature lifts the limitation introduced in release 5.0.1. It is particularly useful for devices using multicast and whose RX2 data rate is forced in the unicast connectivity plan. In this case, the unicast RX2 data rate is not necessarily that configured at RF Region level; and since Class C devices cannot use different RX2 data rates for unicast and multicast traffic, the same RX2 data rate should also be set in the multicast connectivity plan.


When defined, the “Force RX2 Data Rate” field in Connectivity Plan has precedence over “RX2DataRate” setting in RF Region for Class C multicast downlink transmission.


Key Customer Benefits

This feature lifts the limitation of release 5.0.1, allowing the Connectivity Supplier to configure a specific RX2 data rate in the connectivity plans for its class C devices implementing multicast feature.


Feature Activation

This feature is activated by setting “Force RX2 Data Rate” to a value within the Data Rate range allowed for the ISM Band in question (i.e. DataRate 0…5 for eu868, in865, as923, cn779, kr920, cn470 and eu433; DataRate 8…12 for us915 and au915).


WARNING: For proper operation in multicast mode, the same "Force RX2 Data Rate" value must be configured in unicast Connectivity Plans of all devices associated with the Multicast Group and this same value must also be set in the multicast Connectivity Plan associated with this same Multicast Group.


Feature Limitations

Not applicable.


RDTP-4623: ADRv3 is activated by default in Connectivity Plan

Feature Description

Starting release 5.1, ADRv3 is proposed by default in the Connectivity Plan. This rule applies to  new connectivity plans created after migration to release 5.1. Existing connectivity plans (created in previous ThingPark releases) are not impacted.


NOTE: Proposing ADRv3 by default in Connectivity Plans does not mean that ADRv2 cannot be selected. If still preferred by the network operator/ connectivity supplier, it is still possible to select ADRv2 for new connectivity plans until the operator becomes fully ready to roll-out ADRv3.


Key Customer Benefits

This feature promotes Actility’s recommended ADR algorithm (ADRv3) and leverage its capabilities to optimize uplink performances while optimizing battery consumption of end-devices.

The following table illustrates the main differences between ADR V2 and ADR V3:

ADR V2

ADR V3

SNR-based

Quality-based (PER and Overlap metrics)

End-device power consumption ++

End-device power consumption +++

Static repetition (predefined in RF Region + offset at Connectivity Plan level)

Dynamic repetition based on quality targets’ fulfillment

Uplink TxPower control \@ SF7 cannot be deactivated

It is possible to disable the ADR optimization of any TX parameter (SF, TX Power or Repetition) by setting Min value = Max value in Device Profile/Connectivity Plan

Static SNR margin (margin_db, applied on top of median SNR) needs to be manually tuned based on degree of coverage overlapping and target PER

No static SNR margin: SNR-related ADR decisions (to change SF or TX Power) are taken based on target quality metrics considering the whole SNR distribution (not just the median value)

Algorithm reactivity is controlled through “EstimationSlidingWindow” RF Region parameter

Algorithm reactivity is controlled through forgetting factor & hysteresis parameters at RF Region level

For more details about ADRv3, please refer to [8].


Feature Activation

Not applicable.


Feature Limitations

Not applicable.

OSS/Billing Features

RDTP-3365: RF Region Catalog

Feature Description

This feature introduces RF Region catalog for TPW operators.

Prior to release 5.1, RF Region management by the network operator had to go through the following steps (for more details, please refer to the release 5.0.1 of [8]):

  1. To create or update an RF Region configuration file, the network operator had to connect to the LRC to manually create/update the file under /home/actility/FDB_lora/RF Region.
  2. Then, call rfregtool to execute a script to generate the LRR configuration files (also known as tarballs) for each RF Region configuration.
  3. Finally, the operator/network provider associates a base station to a given RF Region configuration via TWA Network Manager application.

Release 5.1 drastically simplifies this RF Region management process:

  • Step #1 above becomes fully manageable from Operator Manager application:
    • The network operator has access to Actility’s default RF Region catalog, it can regularly update to the latest version (via Actility repository).
    • Moreover, the network operator can create its own RF Region configurations from Operator Manager GUI. Hence, each operator can maintain a list of custom RF Regions to complement the default RF Regions supplied in Actility catalog.

  • Step #2 above becomes transparent to the operator, as the RF Region provisioning is entirely managed by TWA who provisions the RF Region files into the LRC and execute rfregtool scripts.
  • Step #3 (LRR association with a given RF Region) becomes simpler: Instead of entering the RF RegionID in Network Manager GUI, the operator/network provider can select the target RF Region from a drop-down list – so this step becomes less prone to human errors/typing mistakes.

NOTE: RDTP-3365 also simplifies the LRR configuration process:

Starting release 5.1 and  LRR version 2.2.75 , the ISM band configuration on each base station is directly embedded in the LRR configuration tarballs generated by the LRC (inherited from the RF Region configuration). Hence, there is no need any more to manually configure the ISM band in lrr.ini file, as this parameter is now present in lgw.ini file pushed from the LRC to LRR.

With RDTP-3365, the Operator can perform the following tasks from Operator Manager Application:

  • In “RF regions” panel, the operator can manage its RF Region: i.e. search, create, update and delete an RF Region. Note that default RF Regions (from catalog) cannot be edited but can be cloned by the operator for subsequent update.




  • In “Catalogs” panel, the operator can manage the RF Region catalog. Two update methods are supported: Automatic and Manuel
    • The  Automatic mode allows the operator to access Actility’s catalog and update it from the GUI as illustrated by the following figure. Note that this mode also allows the operator to create custom RF Regions to complement Actility’s default ones.





  • The  Manual mode allows the operator to import its own RF Region catalog in lieu of Actility’s catalog (as illustrated by the following figure), but it cannot download Actility’s default catalog in manual mode.





The following RF Regions are included in the default catalog (available on Actility repository):

RF Region ISM band

Applicable countries (2-digits ISO country code)

RF Region ID

eu868

AE, AL, AD, AT, BE, BA, BG, CY, CZ, DE, DK, ES, EE, FR, FI, GB, HU, NL, HR, IT, IE, IR, IS, LB, LI, LT, LU, LV, MD, MK, MT, ME, PL, OM, PT, RO, RS, CH, SA, SK, SI, TR, ZA

EU868_8channels EU868_16Channels

 

RU

EU868_Russia

eu433

AD, AE, AL, AM, AT, AZ, BA, BD, BE, BG, BN, BY, CU, CY, CZ, DE, DK, DZ, EE, EG, ES, FR, FI, GB, GR, HK, HU, NL, HR, IE, IL, IR, IS, IT, KW, KZ, LB, LI, LK, LT, LU, LV, MA, MD, ME, MK, MM, MT, MY, NO, NZ, OM, PH, PL, PT, PY, QA, RO, RS, CH, SA, SG, SK, SI, TH, TN, TR, UA, UG, UZ, ZA

EU433

us915

AR, CA, CL, CO, EC, GT, JM, NI, NX, PA, US, UY

US915_72channels US915_First8channels

as923

JP

AS923_Japan_20mW_8Channels AS923_Japan_250mW_8channels AS923_Japan_20mW_15channels AS923_Japan_250mW_15channels

 

HK, TW

AS923_Taiwan_16channels

 

AU, BN, BO, CR, EC, MY, NZ, PA, PE, PY, SG, SV, TH, UY

AS923_8channels_922_924

 

AU, BN, BO, CR, EC, ID, KH, LA, NZ, PA, PE, PY, SG, SV, TH, UG, UY

AS923_8channels_923_925

 

BO, NZ, PA, SV, UY

AS923_8AsymChannels_4W

 

AU, CR, EC, PE

AS923_8AsymChannels_1W

au915

AU, BO, CL, DO, EC, GT, NZ, PA, PE, PG, PY, SV, UY

AU915_72channels AU915_First8Channels

kr920

KR

KR920_7SymChannels

cn779

CN

CN779_8channels

cn470

CN

CN470_First8channels

in865

IN

IN865_8Channels

Key Customer Benefits

RDTP-3365 brings significant operability gains to ThingPark network operators:

  • Simplification of the RF Region management process
  • Very easy update of the default catalog (provided by Actility), directly from TWA GUI. The operator is notified if a more recent version is available, to constantly keep its catalog up-to-date. Both manual and automatic updates are supported.
  • Full flexibility to define custom RF Regions from TWA GUI, which is quite useful for ThingPark Wireless SaaS operators.

Feature Activation

This feature is usable once the ThingPark network is upgraded to release 5.1. Actility’s RF Region catalog will be available immediately after the migration (if the automatic mode is configured by the administrator). Creation of custom RF Region by the network operator can be executed on demand.

To configure the RF Region catalog update mode (automatic or manual), the following command should be executed on TWA (replace  <operator domain> and  <operator ID> by the operator-specific information):


/home/actility/twa-scripts/operator_catalog_update_method.sh  domain> .thingpark.com/  <operator ID> catalogUpdateMethod=XXXXX repositoryBaseUri= https://repository-saas.thingpark.com catalogScopes=TPO

where XXXXX = MANUAL or AUTO.


There is no impact to RF Region configurations existing before the migration to release 5.1, however, these RF Regions will not be visible in Network Manager Application until they are manually created by the Operator in TWA Operator Manager.


Feature Limitations

The following limitations are applicable to the release 5.1 implementation of the RF Region catalog:

  • In release 5.1, the Operator Manager API does not verify the validity of each XML attribute when a custom RF Region is created/updated by the operator. This validation will be supported in TPW release 5.2 (RDTP-4587).
  • The list of RF Regions proposed during Base Station creation and Base Station update may contain RF Regions incompatible with the Base Station model. For instance, Ufispace Pico v1.5 supports only 8 channels, but RF Regions with > 8 channels may still be proposed by Network Manager (in this case, only the first 8 channels will be configured on the gateway).
  • Existing RF Regions deployed on LRC before the migration to release 5.1 are NOT automatically imported in TWA. Only RF Regions imported from RF Region catalog or created through Operator Manager after the migration are directly available on TWA. Hence, the Operator should manually create their RF Regions in TWA Operator Manager (or upload them via a custom catalog – using the manual mode) for them to be visible in TWA Network Manager application.

RDTP-2238: Add Dwell Time to the Device Profile GUI for AS923 devices

Feature Description

This feature allows enriching the Device Profile by configuring the default value of uplink and downlink dwell time that is used by devices during boot phase, i.e. initial network access.

The configuration of uplink and downlink dwell time is relevant for  AS923 devices only ; it is used by the LRC to know which dwell time is used  by default in the device’s LoRaWAN stack , before the LRC sends an explicit MAC command (TxParamSetupReq) to notify the device of the target runtime dwell time values.


NOTE: Like all the other RF boot parameters present in the Device Profile, the uplink/downlink dwell time MUST match the values used by the device stack during bootstrapping. If the boot settings configured in Device Profile are different from those really coded on the device stack, there is a high risk of desynchronization between the device and the network (i.e. the device may not be able to join the network)! Boot parameters set in Device Profile help the LRC adapt its bootstrapping messages to successfully establish communication with the device during initial network access; but the boot parameters are NEVER used to configure the runtime settings of the device (this is rather set in RF Region configuration).


For more details about the boot settings present in the Device Profile, please refer to [8].


Key Customer Benefits

The main advantage of this feature is to simplify the provisioning required by the network operator to onboard all AS923 devices whatever the default dwell time configuration implemented by their stack:

  • Prior to release 5.1, the LRC considered by default that the boot setting of dwell time = 400ms for AS923 devices. To change this boot setting, the network operator had to connect locally to the LRC and manually change it in its internal DeviceProfile database, but this change was not allowed from TWA GUI.
  • From release 5.1, thanks to RDTP-2238, this configuration becomes directly accessible from TWA GUI.

Feature Activation

This feature is activated by setting “MAC max uplink dwell time” and/or “MAC max downlink dwell time” in the Device Profile.


NOTE: The default value used by LRC if any of these fields is left empty in Device Profile = “400 ms” (AS923 devices should consider the worst-case dwell time during bootstrapping until they receive the TxParamSetupReq MAC command).


Feature Limitations

Not applicable.


Feature Description

With this feature, the LRC reports the current uplink TxPower and number of transmissions corresponding to each uplink packet to the Application Server in DevEUI_uplink reports.

The detailed description of these 2 new attributes is presented by the following table:

Attribute

Definition

TxPower

End-device transmission power in dBm. It can be expressed as conducted power or EIRP depending on ISM band and LoRaWAN version of the device (for more details, please refer to [8]. For devices using ADR, TxPower is computed by the LRC based on ADR algorithm, then sent to the device through a LinkADRReq; this value is reported to TWA/AS only when it is acknowledged by the device through a LinkADRAns. If no LinkADRAns have been yet validated by the device (or if the device does not use network-controlled ADR), the device’s boot parameter will be reported instead.

NbTrans

Number of transmissions for each uplink frame. It is dictated by the ADR algorithm implemented in the LRC then sent to the device through a LinkADRReq. This value is reported to TWA/AS only when it is acknowledged by the device through a LinkADRAns. If no LinkADRAns have been yet validated by the device (or if the device does not use network-controlled ADR), NbTrans=1 by default.

Key Customer Benefits

This feature offers an interesting level of monitoring for both network operators and subscribers/application providers:

  • For network operators: Thanks to this feature, the operator can assess the efficiency of the ADR algorithms by tracking the devices’ TxPower and NbTrans distribution. Such assessment is helpful in optimizing ADR parameters to maximize battery lifetime, minimize airtime/RF resources while maintaining target packet error rate. For more information about ADR algorithms and their optimization, please refer to [8].
  • For subscribers/application providers: This additional reporting is useful to evaluate the power consumption driven by uplink transmissions and accordingly assess the battery draining trend of each device.

In the following ThingPark wireless releases, these two attributes will be integrated into ThingPark KPI dashboards to maximize their usability.


Feature Activation

This feature is automatically activated after the upgrade to release 5.1.


Feature Limitations

  • TxPower and NbTrans are not yet displayed in TWA Device Manager GUI.
  • NbTrans reported by the LRC refers to the number of transmissions requested by the network to the device (based on ADR decisions), not the effective number of copies received by the LRC for each uplink frame.
  • If the device does not use network-controlled ADR (i.e. ADRbit = 0 in uplink frames), the TxPower and NbtTrans values are not necessarily aligned with the device’s transmission parameters especially if the device does ADR on its own. This is not a ThingPark limitation: the current LoRaWAN specification does not make the LRC aware of the device-controlled ADR strategy.

RDTP-2243/NFR1030 Support for Baidu Mapping Services

Feature Description

The scope of this User Story is to support Baidu Mapping services for ThingPark Applications, in addition to Google Maps and OpenStreetMap already supported in ThingPark Wireless.

As of ThingPark v5.1, four mapping services are available:

  • Google Maps – which is the default mapping service.
  • OpenStreetMap - already implemented in the scope of NFR472.
  • Baidu Maps - implemented in the scope of this User Story NFR1030/RDTP-2243.
  • No mapping services - implemented in the scope of NFR426.

The following technical guidelines have been considered through the development of this feature:

  • The Baidu mapping service relies on BD09 coordinate system. The geographical coordinates are stored using the WGS84 coordinate system in ThingPark databases and they are converted into BD09 only when they are displayed on Baidu maps.
  • WGS84 coordinate system is used for:
    • Geographical coordinates provisioning in ThingPark GUI: when a location is updated by clicking on Baidu map, its geographical coordinates are converted into WGS84 before they are provisioned into ThingPark DB.
    • Display decimal degrees in the application GUI.
    • Provisioning and reporting of decimal degrees in ThingPark APIs.

Baidu mapping service is supported in the following ThingPark Wireless applications:

  • Device Manager.
  • Network Manager.
  • Wireless Logger.
  • Network Survey (already supported since network survey v1.9.1).

Key Customer Benefits

This feature enables Operators to use different mapping services and remove the main 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’ external mapping services.


Feature Activation

To support the Baidu mapping services, the existing system-wide mapping service configuration is enhanced:

  • Map service for direct access: gmaps (default) | osm | none |  bmaps
  • Map service for module access: gmaps (default) | osm | none |  bmaps

Example:

map_service.module_access=bmaps

map_service.direct_access=bmaps


When Baidu (bmaps) service is configured in direct access and/or in module access the Baidu Maps API key needs to configure per Operator domain.

Example:

domain.DEFAULT.bmaps_api_key=AIzaSyAPxR8gUxNg8ZNNNnbzvEjTYdzeEV0sLBU


Feature Limitations

The following limitations and assumptions are considered:

  • When geographical coordinates are manually entered in the Application GUI, the WGS84 standard is used.
  • GCJ02 coordinate system is not supported by this feature. GCJ02 (Colloquially Mars Coordinates) is a geodetic datum formulated by the Chinese State Bureau of Surveying and Mapping based on the WGS84 standard.
  • This user story does not support the User Portal application.

RDTP-4292 ThingPark OS and Wireless OSS API Documentation through API framework

Feature Description

The purpose of this feature is to provide an online OSS API framework for the ThingPark users to design, build, document, and consume REST APIs. It is set to provide ThingPark OSS API reference documentation.

The online framework captures all OSS APIs of the ThingPark Wireless and ThingPark OS products. It provides the best experience for all developers who interface with ThingPark OS or ThingPark Wireless products for different use cases such as 3rd party API use, management of subscriptions, applications, devices, base stations, alarm management or downlink sending.


  • The framework usage is for applications implemented based on OpenAPI interface that can automatically generate documentation of methods, parameters and models. This helps keeping the documentation, client libraries, and source code always in synchronous mode.
  • All ThingPark OSS APIs documentation, currently produced in word format, are replaced by an API HTML format, available both for external customer and Actility users.
  • For each OSS API layer, the framework enables browsing both detailed documentation and changelog information for users to get to know the OSS API content and changes of each version.
  • The online documentation is accessed by browsing the following URL  https://oss-api.thingpark.com/

Here below is an example of subscriber retrieve method following a subscriber address retrieve CURL example:





 

Key Customer Benefits

The OSS API framework enables a simplified and modern API user experience, mainly set for development, testing, consuming API Rest resources and accessing API documentation. By becoming a dynamic API framework, it replaces the entire OSS API static documentation stack that was available before ThingPark v5.1.


Feature Activation

To access the OSS API framework, please browse the following URL:

https://oss-api.thingpark.com/

Feature Limitations

The following feature limitations are considered and are product feature candidates for improvements in the next ThingPark releases:

  • Documents are only produced manually.
  • API error codes are not available.
  • Out-of-the-box Swagger UI is not supported in this release.
  • Model order properties is set by an alphabetical order and not a functional one.
  • Improvements are required to enable the use of this framework during the development and integration phases.
  • Enhancements and clarifications are required on the JSON date format (EPOC) vs the XML date format (ISO).
  • A convenient and optimized PDF format should be produced for each API method.
  • API examples may include non-real values.
  • API testing:
    • Manual API testing is not supported. The HTTP document does not allow to run manual testing even when the user owns valid credentials.
    • Automatic API testing, e.g. for regression and progression type of testing, is not supported. The HTTP document does not allow to run automatic testing even when the user owns valid credentials.

RDTP-2259/NFR994 Report Number of active Application Servers in Usage Data Record

Feature Description

The operator user experience before ThingPark v5.1 was that no reporting of the number of active application servers was produced in the monthly usage data record (UDR). The purpose of this feature is to produce UDRs that will count and report the number of active application servers per subscriber.

An active application server is such one that has been provisioned by the subscriber, in the Device Manager application, and is set to an "Active" state.

To report the number of active application servers, a new Application Server activation record has been added to the UDR Operator report.

In this feature, the following Application Servers types are introduced:

  • HTTP Application Server (LoRaWAN)
  • HTTP Application Server (Cellular)
  • Message Queuing Kafka Cluster

The Application Server record is set to collect the Application Server activation information elements. The reported record is structured as follows:

  • A data structure tuple of {Subscriber ID, Activation date, Deactivation date, Application Server ID}, when an Application Server is activated and/or deactivated during the UDR generation period.
  • The reporting is set for each Subscriber ID when Application Servers were active throughout the entire period.

Here below is the structure of the new operator report / Application Server activation record:

Column

Details

A

Record type:

  • 'as_part' when the record reports an Application Server activation and/or Application server deactivation that was done during the period.
  • 'as' when the record reports Application Servers that were activated the whole period.

B

Subscriber ID.

C

External Subscriber ID.

D

Total number of AS that were activated, according to the type of the record:

  • Record type = as_part: Always '1'.
  • Record type = as: Total number of Application Servers that were activated the whole period

E

Date/time of activation, according to the type of the record:

  • Record type = as_part: Date/time of activation (if activated during the period), otherwise empty.
  • Record type = as: Always empty.

F

Date/time of deactivation, according to the type of the record:

  • Record type = as_part: Date/time of deactivation (if deactivated during the period), otherwise empty.
  • Record type = as: Always empty.

G

Application Server ID, according to the type of the record:

  • 'as_part' when the record reports an Application Server activation and/or Application server deactivation that was done during the period.
  • Record type = as: Always empty.

Here below are two examples of such records:

  • The Subscriber "199979762" creates a first Application Server "TWA_199979762.271.AS" and the Application Server is activated by default:

"as_part", "199979762",,"1","2018-01-14T14:17:15Z",,"TWA_199979762.271.AS"

  • The Subscriber "199979762" deactivates the Application Server "TWA_199979762.271.AS":

"as_part","199979762",,"1",,"2018-04-06T09:51:21Z","TWA_199979762.271.AS"

For more details on the UDR record structure and its functionality, please refer to ThingPark Wireless v5.1 Usage Detail Records Description document.

The Device Manager application has been enhanced to enable the subscriber end-user to activate or deactivate an Application Server:

  • Application Servers - a new mandatory ‘Status’ field is added per AS to set the AS status of "Active" or "Deactivated".

Please note that when an application server is deactivated, uplink frames from its associated devices are not forwarded to the application server anymore and the application server is not able to send downlink payloads.

  • Application Servers routing profile – a new field is added per AS to display the status of the AS either in "Active" or "Deactivated" state.

Here below is an image of the Application Server configuration with the new AS state Active or Deactivated.





Key Customer Benefits

This feature enables operators to charge their customers per the total number of active application servers. It is achieved through the extension of the UDR report to count the number of application servers per a given subscriber.

The feature also enables subscriber end-users to activate and deactivate application servers at any time without the need to deprovision them and later provision once again.


Feature Activation

This feature is activated by default after a SW upgrade to ThingPark v5.1.


Feature Limitations

The following feature limitations are applicable:

  • An AS is still considered active even if it is not associated with any device or does not receive nor send any IoT traffic.
  • The number of Application Servers actually used by the subscriber (associated with Devices) is not available.
  • AS provisioned by Application Suppliers are not counted in the UDR.
  • After a software upgrade to TP v5.1 and in the first UDR generation, all provisioned Application Servers will be counted as activated.

RDTP-2469/NFR987 Device Dual Provisioning in Join Server

Feature Description

This feature offers a two-step provisioning approach for OTAA devices operating in JSaaS (i.e. Join Server as a Service) mode. The purpose of this feature is to allow:

  • Device manufacturers to directly pre-provision their devices in ThingPark Wireless JS through a new device provisioning process.
  • The Subscriber, or the Operator on his behalf, to claim ownership over a device.

The new provisioning process is divided into two asynchronous steps and executed through Actility ThingPark Wireless Join Server:

  • Step #1 - The Device Manufacturer pre-provisions device’s unique identifiers and LoRaWAN security keys – the AppKey and the NwkKey.
  • Step #2 - The Subscriber, or the Operator on his behalf, claims an ownership of the device in the Join Server using a one-off security token at the time he is provisioning the device in the LRC to obtain connectivity.

The dual provisioning process insures that no device key transit from the device manufacturers to the subscribers or to the operators. It also simplifies the entire provisioning process.


The feature also includes the support of special device provisioning equipped with a Secure Element (SE). In this case, the device AppKey is never provisioned but replaced with a SE UID. Based on this SE UID, the device and the HSM can derive the device AppKey.
In its first version, ThingPark v5.1 supports only the STMicroelectronics ST-SAFE-A100 Secured Element.

1. Join Server Dual Provisioning

A device can be set in four different Join Server states, illustrated by the figure hereunder:

  • Pre-commissioned - device identities and keys are provisioned in the JS by the Device Manufacturer. Next, the device should be claimed by a subscriber to be commissioned and activated.
  • Generic Device – the device has been claimed by the subscriber but not yet commissioned (not yet associated with an AS Key and a Home Network Server (NS)).
  • Commissioned Device – the device has been commissioned by the subscriber but not yet successfully joined the network.
  • Activated Device – the device has successfully joined the network and is operational.


2. Device Dual Provisioning – Without Secured Element

To perform the device dual provisioning the following prerequisites are set:

  • The device is not equipped with a SE. The Device provisioning is based on AppKey and optionally NwkKey.
  • Provisioning of both LoRaWAN 1.0 and LoRaWAN 1.1 devices is supported.
  • Both SSM and HSM security models are supported.

Subscriber claim process

  1. First the Device Manufacturer pre-commissions the device in Actility JS using the Key Manager Application API (Device Manufacturer's account). An OwnerToken is sent back and provided to the Device Manufacturer.
  2. The Device Manufacturer associates the device with the OwnerToken. From a logistic perspective the OwnerToken can be printed as a QR code on the device packaging.
  3. Using the OwnerToken and device DevEUI, the Subscriber claims device ownership and commissions the device in Actility JS using the Key Manager Application or API (Subscriber's account).
  4. The Subscriber provisions the device in MNO NS (MNO is the Operator of the NS) using the MNO portal.
  5. The Subscriber provisions the device in the AS directly or through the MNO portal.

The above process is described in the following image:



 

MNO Claim process (on Behalf of the Subscriber)

When the MNO performs the claim process, it goes through the same process as for subscriber except for the following steps:

  1. The Subscriber provisions the device in MNO NS using the MNO portal - ownership claim and commissioning in Actility JS is performed by the MNO  on behalf of the Subscriber using the ThingPark Key Manager API (MNO's account).
  2. The Subscriber provisions the device in the AS using the MNO portal.

The above process is described in the following image:







3. Device Dual Provisioning – With Secured Element

To perform the device dual provisioning the following prerequisites are set:

  • The device is equipped with a SE.
  • The Device provisioning is based on SE UID.

Subscriber claim process

  1. The SE Manufacturer (STMicroelectronics) first shares the mother SeKey (encrypted by HSM) used for AppKey generation with Actility JS.
  2. The Device Manufacturer pre-commissions the device in Actility JS using the Key Manager API (Device Manufacturer's account).
  3. The Device Manufacturer solders the SE on the device and associates the device with the SeUID. From a logistic perspective the SeUID can be printed as QR code on the device packaging.
  4. Using the DevEUI and SeUID, the Subscriber claims device ownership and commissions the device in Actility JS using the Key Manager Application or API (Subscriber's account).
  5. The Subscriber provisions the device in the MNO NS using the MNO portal.
  6. The Subscriber provisions the device in the AS directly or through the MNO portal.

The above process is described in the following image:




MNO claim process (on behalf of the Subscriber)

When the MNO performs the claim process it passes the same process as for subscriber except for the following steps:

  1. The subscriber provisions the device in the MNO NS using the MNO portal - ownership claim and commissioning in Actility JS is performed by the MNO on behalf of the subscriber using the Key Manager API (MNO's account).
  2. The subscriber provisions the device in the AS using the MNO portal.

The above process is described in the following image:



Key Customer Benefits

The dual provisioning process ensures that no device key transit from the device manufacturers to the subscribers or to the operators. It also simplifies the entire provisioning process.

For Join Server providers, this feature allows Device Manufacturers to pre-provision manufactured devices in their JS and provide them with a security token, so that they can transmit these tokens to their customers via QR-code, scratch code or written in the delivery order. To claim ownership, the subscriber (or the operator) should provide this token to prove their device ownership, so that nobody else can provision their devices on their behalf and steal their secret keys or use their connectivity.

For more information on the dual provisioning processes, please contact your Actility Technical Manager contact person.

Feature Activation

The dual-provisioning mode is activated via a specific check box in the Key Manager application (when a new device is created in Key Manager), as per the following figure.

If “Pre-commissioning only” option is not checked, the Key Manager application shall not generate any owner token and hence the legacy single-step provisioning mode applies.






Feature Limitations

The following feature limitations are applicable:

  • Secured Element Limitations:
    • Only STMicroelectronics ST-SAFE-A100 Secured Elements are supported for a Secure Element integration.
    • Only provisioning of LoRaWAN 1.0 devices is supported.
    • Only HSM mode is supported and not SSM.
    • Provisioning of SE devices in the Device Manager Application is not supported.
    • The provisioning of a “Mother SE Key” is not yet integrated in the Operator Manager Application – the provisioning is achieved through a system-wide configuration.

  • The entire feature does not support device bulk import.
  • When a legacy device is pre-commissioned using the Key Manager Application, the owner of the token is always returned in clear text. Token owner encryption is only available through the Key Manager API.

RDTP-3366 Base Station and Device Vendor Description

Feature Description

The purpose of this feature is to enable operator administrators to add a commercial description to their device and base station vendors. Those descriptions are an integral part of the device and base station profiles.
In the ThingPark Wireless Operator Manager Application, the operator can override the default profile set description of the vendor through a new introduced free text field.

Key Customer Benefits

During device and base station provisioning, this feature enables the user to get additional information on the specific IoT element vendor, that he is about to provision. This information can be a technical and a commercial one.

For eco-system vendors this feature enables to give a more accurate and correct description of the designated IoT element.


Feature Activation


This feature is activated by default after a SW upgrade to ThingPark v5.1.


Feature Limitations


This feature does not introduce any limitations.

RDTP-4030 Enhance a Base Station Remote Secured Shell (SSH)

Feature Description

The purpose of this feature is to enable Network Suppliers, Partners and Subscribers to access the base station via a secured remote shell (SSH) interface. An SSH to base station is useful in case of advanced maintenance and troubleshooting operations.

For ThingPark wireless, remote access via SSH is already supported from previous ThingPark releases. This feature brings an additional enhancement via the “Rescue SSH mode”, which allows doing SSH to a base station even if this base station cannot be reached via the LRC.

The Rescue function process and design is described here below:








Key Customer Benefits

This feature enables base station administrator users to remotely access their base station via the Network Manager Application to perform troubleshooting and maintenance. In a rescue mode, it also proposes the option to remotely access the base station via the back-office even if it cannot access the LRC to make the initial open SSH request.


Feature Activation

This feature is activated by default after a SW upgrade to ThingPark v5.1.  

Feature Limitations
Not Applicable.



RDTP-3385 Display Device ESP Average in TWA Device Manager application

Feature Description

This feature adds the device Estimated Average Power average for the last 10 received packets. The ESP estimates the real received signal strength of a desired signal considering the impact of background noise. It is measured in dBm units.

The following ESP scale is applicable to the ThingPark Wireless product:

Value

Colour

-100 ≤ ESP

Green

-110 ≤ ESP < -100

Orange

ESP < -110

Red

The ESP measurement can be retrieved via:

  1. Display average ESP and last ESP in the Device Manager application device view.
  2. A new ESP tab in the in the Device Manager application charts view.

Key Customer Benefits

This feature enables device owners to view specific device average ESP which is an important radio meta data and make an analysis of its behaviour such as its variation over time (fast fading effect).


Feature Activation

This feature is activated by default after a SW upgrade to ThingPark v5.1.


Feature Limitations

Not applicable.


RDTP-2262 Backhaul Interface Status Alarm

Feature Description

The current user experience, before ThingPark v5.1, is that the Network Manager Application can report a "connectivity lost" alarm that tracks LRC-LRR connection state.

Though it cannot distinguish which LRR interface, such as ethernet, 3G, etc., has been lost. The purpose of this feature is to enable Network Supplier and Operators to track interfaces state through a new alarm mechanism, so it will be able to act before all backhaul network interfaces are all down.

For high availability and reliability reasons, LRRs are usually configured with two distinct types of backhaul connection interfaces. For example, ethernet and 3G. When the primary interface is not available anymore, the LRR automatically routes the traffic through the secondary one.

To support the new functionality a new type of Base Station (LRR) Alarm has been created:

Alarm ID

Details

121

Base Station backhaul network interface status


This alarm will trigger the backhaul network status and will provide the following information per each concerned backhaul network interface:

  • Interface index and name
  • Interface state
  • Alarm severity level

The previous network Alarm ID#102 Base station backhaul status alarm will now be reporting alarms for the entire Base Station backhaul connection state. It has renamed to "Base station connection status".

Please note that as part of this feature the ThingPark (TWA) SNMP MIB is enhanced to support the new Base Station alarm.

For more information on this alarm and on the Network Manager Application, please refer to the Network Manager User Guide document.

Key Customer Benefits

A network backhaul failed connection is an abnormal situation, where network managers must be informed of such cases, to troubleshoot the problem and fix it rapidly to guaranty the Base Station service.

This feature enables administrators and network managers to follow closely their base network backhaul connection status per designated interface.

Feature Activation

This feature is activated by default after a SW upgrade to ThingPark v5.1.

Feature Limitations

Not applicable.


RDTP-2574/NFR699 Report LRR-LRC IEC-104 Network Connection Status

Feature Description

The current user experience before ThingPark v5.1 LRR software, was that the only method to know the status of LRR connections towards the LRCs, was for an administrator to directly consult and verify certain LRR logs (trace.log file).

The purpose of this feature is to provide a straightforward way to retrieve the status of the LRR connection state towards the LRC.
The technical solution of the feature consists of a verification by the LRR lrr.x process, to detect a change of an IEC connection state, and to update the new revert status in a new dedicated log file named lrcstatuslink.txt.

The lrcstatuslink.txt log file is updated in a frequency of 10sec, if the IEC104 status has been changed.
Here below is the structure of the new file:

Attribute

Details

File Name

lrcstatuslink.txt

File Path

$ROOTACT/var/log/lrr (generally mounted on FSRAM)

File Format

Plain text

File Attribute #1

LRCPRIMARY. LRCPRIMARY grants the status of the IEC104 connection with the primary LRC: "ko" or "ok".

File Attribute #2

LRCSECONDARY. LRCSECONDARY grants the status of the IEC104 connection with the secondary LRC: "ko", "ok" or "none". The “none” status is applicable when a secondary LRC is not configured in the lrc.ini configuration file.

File Attribute #3

LRRPID. LRRPID grants the Linux process ID that has applied the last file modifications.

File Attribute #4

LASTUPDATE (in seconds). LASTUPDATE grants the timestamp of the latest applied file modifications.


Here below is an example of such file:

  • LRCPRIMARY=ok
  • LRCSECONDARY=none
  • LRRPID=25874
  • LASTUPDATE=585569801

To benefit of this feature, a Network Manager administrator can enable a (third party) LRR process to detect an LRR/LRC connection using the above attributes.

For more information on this feature and how to enable such a process please contact your Actility Technical Manager contact person.

Key Customer Benefits

This feature sets an infrastructure for Network Managers administrators to develop an advanced network operating service feature to monitor and supervise their IEC104 Base Stations connection status. A typical supportable use case is the activation of a local Base Station LED to alert when the connection of the base stations towards the LRCs is lost.

Feature Activation

This feature is activated by default after a SW upgrade to ThingPark v5.1.

Feature Limitations

Not applicable.

List of User Stories included but not validated 

None

Issues Resolved for Customer Project/Customer Support

This section lists customers issues that are resolved in ThingPark 5.1

ID

Summary

RDTP-6694

Impossible to delete a routing Profile

RDTP-5688

Join Accept not received by the GW (when two GWs got the Join Request)

RDTP-5587

[23104] AS923 - AS fails to send DL to class C devices

RDTP-5585

[23130] Blocked parent thread launching child threads in charge of sending uplinks from LRC to AS.

RDTP-5577

Email alarm notification sending problem on the EQX PREPROD and EQX Prod

RDTP-6718

[N3_QUEUE][\#20145] Device does not ACK new channel request therefore LRC keeps sending the MAC command in a loop

RDTP-6595

[24488] RX2 transmission is failing when RX2 Optimization is enabled in AS923 and EU868

RDTP-5876

[-] When compiling “elap.c” program on LRC, it is terminated with signal 11 and a segmentation fault, due to some memory leaks

RDTP-5723

Multicast Group Error: unlike in the FDB_Lora's LRRGroup table, there are missing Gateways in LRC LRRs group

RDTP-5611

Crash in ADRv3StateMachine_DownLink

RDTP-5599

[23103] LinkADRReq are sent in loop for Tx Power configuration on some devices since 5.0.1 upgrade

RDTP-5588

[23116][23102] FCntDown is not incremented in sequence

RDTP-5553

Downlink frequency not properly managed if a NewChannelReq is sent after a DlChannelReq

RDTP-5240

Default CURL timeout tuning is too short

RDTP-5032

[NFR924]: ADRv3 regression when NFR924 is activated

RDTP-4946

"Allow Class B" flag is missing in Connectivity Manager for Multicast Connectivity plan

RDTP-4546

Each LinkADR command should be considered as one command (FIX5208) but that's not the case.

RDTP-6831

The RXTimingSetupReq is sent in loop with the same value even if the device answered with a RXTimingSetupAns

RDTP-6174

Missing init scripts for KPIs

RDTP-6162

AU915 - join request goes in loop while using RX1 slot downlink

RDTP-5909

[NFR766]: LRC should check max payload size before responding to AS

RDTP-5906

[NFR766]: MAC commands should be sent exclusively on RX1 and RX2

RDTP-5784

[23193] Same FCntDown on DL after switchover from LRC2-ppr to LRC1-ppr

RDTP-5782

Wrong calculation for MaxPayloadSize (NFR766) feature

RDTP-5689

Additional Downstream message still being sent after the patch

RDTP-5662

LRC memory leak in RFRegion

RDTP-5661

LRC memory leak in GeolocResponse

RDTP-5660

LRC memory leak in RxChannel

RDTP-5649

NewChannelReq sent to US devices while unsupported

RDTP-5626

Order stuck in Init state

RDTP-5449

Some packets are not inserted in table B (in ADRv3 block) without any visible reason

RDTP-5017

identificationMode update failing

RDTP-5010

LRC doesn’t resend ACK for repeated “confirmed” frames

RDTP-4758

LRC 1.10.x, Binary table B break some compatibilities

RDTP-4742

[21866] downlink sent indicator mentioning year 1970

RDTP-4358

[21207] Ack sent from device not received at AS

RDTP-4253

[21371] - Network Manager : Incorrect colour rule used for Software Restart

RDTP-3991

[20996] Error thrown when updating the trace level to 0 in Network Manager

RDTP-1224

The regional-specific default settings should be used by the LRC during the boot phase whenever a corresponding field in DeviceProfile is empty

RDTP-472

Properly explained colour codes in the Network Manager

RDTP-6694

Impossible to delete a routing Profile

RDTP-5688

Join Accept not received by the GW (when two GWs got the Join Request)

  Known issues 

This section lists known issues that will be resolved in a further maintenance release of ThingPark 5.1


ID

Summary

RDTP-7521

Unable to create end-user account if all the previously defined end-user accounts have been removed

RDTP-7497

403 error when creating a supplier (the supplier can be created)

RDTP-7492

MAC Uplink Packet with Fport = 0 seen as MAC+Data in Wlogger

RDTP-7592

It’s possible to delete a RF Region in use from the RFRegion catalog

RDTP-6995

Multicast downlinks - FCntDn not correctly handled by LRC


    • 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 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.2 - Software Release Notes

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