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
  

• Issues Resolved for Customer Project/Customer Support
  

ThingPark Solution Architecture Description

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.

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 OS

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.3 Newly Introduced Features (NFR’s)

NFR#187 ThingPark Wireless Class B and Class C Multicast

Feature Description

• Each multicast group was identified by a specific “virtual” DevEUI, DevAddr, NwkSKey and AppSKey. These parameters have been provisioned in ThingPark Device Manager
  

• The LRR list corresponding to each multicast group was defined internally in the LRC, in table “A”:
  

• Setting the LRR list in Table “A” implicitly means that the LRC will send Downlink packets corresponding to this DevEUI without waiting for an initial Uplink transmission
  

• The Downlink frame is set in “Unconfirmed mode”
  

• Downlink multicast frames are sent over RX2 channel, using the SF & frequency defined in CP/RFregion of the virtual DevEUI.
  

• Transmission over several LRRs is delayed by 5-10s to avoid collision
  

• Only Class C was supported
  

ThingPark wireless v4.3 introduces an enhanced Multicast feature based on the specific design and capability introduced earlier.

Please note that in ThingPark Wireless v4.3 the feature is supported at the LRC level only. The rest of the feature enhancements, e.g. all ThingPark Applications and UDRs are delivered in ThingPark v5.0

In the following sections we will describe its functionality and different configurations available for this feature.

LoRaWAN multicast for Class B and Class C

• A multicast group is composed of LoRaWAN Devices implementing:
  

• A regular unicast ABP or OTAA type of Device set with Class B or Class C - Associated with a first set of {DevEUI, DevAddr, NwkSKey, AppSKey} (ABP) or {DevEUI, AppKey} (OTAA)
  

• A virtual multicast ABP Device (Class B or Class C) - Associated with a second set of {DevEUI, DevAddr, NwkSKey, AppSKey}. This virtual device is pre-shared by all members of the multicast group
  

• A multicast virtual ABP Device only implements Unconfirmed Data Downlink message type without MAC commands
  

• Class C: The same RX2 window than a unicast Device refers to – The same RX2 Frequency/DR of a unicast type Device
  

• Class B: Specific multicast ping slots are introduced; the number of slots depends on the multicast group periodicity – The same Ping Slot Frequency/DR of a unicast type Device
  

The figure bellow gives a high-level view over the different Multicast elements and flow of information:

LRC implementation

• A multicast group is mapped to a virtual ABP Device attached to a multicast Service Profile (Connectivity Plan)
  
• A static list of LRRs is linked to the virtual ABP Device through a new LRR  Group Table
  
• The link between the multicast group and the unicast Devices is transparent  to the LRC
  
• The proposed Service level is controlled by the multicast Service Profile –  such as Downlink token bucket settings and Downlink transmission settings
  
• Downlink security setting can be set and activated through Routing Profile
  
• Multicast downlink frame transmission
  
• Class B: Downlink frame is transmitted by all LRRs which are GPS synchronized, at the same time
  
• Class C: Downlink frame is transmitted by all LRRs which are GPS synchronized, at the same time. Transmission by non GPS synchronized LRRs is delayed avoiding interferences between adjacent cells
  
• A Downlink frame is retransmitted to a LRR until it is successfully transmitted
  
• Multicast Downlink frame reporting
  
• For each transmitted frame, a delivery status report is sent to the TPW OSS layer
  
• Partial and final summary reports, including the number of successful and failed transmissions, are sent to the 3rd party AS and onto the OSS layer
  

ThingPark Wireless Enhanced Applications – ThingPark v5.0 items

To operate the multicast feature, the following modifications will be introduced in the different sets of ThingPark v5.0 Applications:

• Operator Manager – A new Base Station Profile attribute has been added:
  

• Base Station Type: Macro Cell / Nano Cell / Pico Cell which is required to limit multicast group to a specific type only
  

• Connectivity Manager – A new Connectivity Plan type named Multicast with following feature flags:
  
• Downlink rate / Downlink bucket size / Downlink regulator policy – Sets the Downlink token bucket settings
  
• Multicast Max LRR Cells – Sets the maximum number of LRRs associated with the multicast group. The absolute value is set to a maximum of 1000 and the constraint is verified by the Device Manager Application
  
• Multicast Inter Delay – Sets the transmission delay between different LRRs (in seconds)
  
• Multicast Retransmit Timer – Sets the Delay between two multicast retransmissions burst (in seconds)
  
• Multicast Max Retransmit – Sets the maximum number of times the LRC will attempt to retransmit frames to LRRs which previously could not have been broadcasted
  
• Multicast Pico Cell Only – Sets if only Pico Cell LRRs can be associated with the multicast group and the constraint is checked by the Device Manager Application
  
• Multicast Class C Collision Avoidance Distance – Sets the minimum distance between two LRRs to avoid transmission collision
  
• Device Manager
  
• Multicast Groups management new panels have been added to enable the functions of Create, Search, View, Edit and Delete
  
• Settings - DevEUI, DevAddr, NwkSKey, AppSKey, Class B or Class C, Class B Periodicity
  
• Integration with the Device Address Manager Application (verification code)
  
• Configuration the LRR tags (0..N) / Multicast Connectivity Plan / AS Routing Profile for Downlink security
  
• Visualization of KPI - Downlink packets with delivery status, overflow downlink packets
  
• New feature flags in as set in the Connectivity Plan are displayed in the Network Subscriptions
  

• Network Manager – A new Base Station attribute added of Tags - which list of tags (0..N)
  

• The Wireless Logger Application - Multicast downlink frames are identified with a new multicast flag at both Subscriber and Network Partner levels
  

• Usage Data Records (UDR)
  

• Subscriptions to Multicast Connectivity Plans are included in the Connectivity Supplier report / Network Subscriptions records
  

• Activations of Multicast Groups are included in CS report / Network Activations records
  

• Multicast Downlink frames are included in Network Provider report and CS report / Network Traffic records
  

* Please note that the above modifications might be modified during the development phase of ThingPark v5.0

Multicast Reports

The following ThingPark report messages have been enhanced or introduced:

• EUI_Downlink – this type of report is sent to TWA and to the Wireless Logger Application. A new field is added to indicate the Class of the multicast group (B/C). Please note that it is only set when the downlink is sent to a multicast group
  

• EUI_multicast_summary (new) –
  

• Few partial and one final multicast summary report per multicast Downlink for each multicast downlink received from an AS few multicast summary reports are sent to the OSS layer
  

• Partial multicast summary report is triggered between each retransmission burst including the number of successful transmissions
  

• Final multicast summary report is triggered at the end of the retransmission mechanism including the final status and the number of successful/failed transmissions
  

• Multicast summary report is applicable to the following applications:
  

• Device Manager – to display Multicast Group KPI
  

• UDR - to count each multicast Downlink procedure
  

• DevEUI_Downlink_Sent - This type of report is not generated for a multicast Downlink frame to avoid flooding the 3rd party AS with reports
  

• DevEUI_multicast_summary (new) –
  

• Like the multicast summary report implemented on LRC/OSS interface (EUI type of report)
  

• Partial multicast summary report is triggered between each retransmission burst including the number of successful transmissions
  

• Final multicast summary report is triggered at the end of the retransmission mechanism including the final status and the number of successful/failed transmissions
  

Multicast Downlink Transmission and Retransmission Examples

The image below displays an example of a multicast downlink retransmission:

Key Customer Benefits

ThingPark Wireless Multicast introduces the following advantages to Actility LoRaWAN Operators:

• When sending the same data to multiple receivers, rather than send multiple copies all the way from sender to all the receivers, just send one copy and duplicate where paths diverge
  

• Better bandwidth utilisation
  

• Less network server (LRC) processing
  

• Receivers’ addresses may be unknown or transparent
  

• Enhanced Efficiency: Controls network traffic and reduces server and CPU loads
  

• Optimised Performance: Eliminates traffic redundancy
  

• One single AS entry for all Devices
  

• Centralized reporting mechanism
  

NFR#432 ThingPark Wireless Operator KPIs Dashboard

Feature Description

The purpose of this feature is to enable ThingPark Wireless Operator Dashboard that includes Key Performance Metrics (KPI). A Key Performance Indicator is a measurable value that demonstrates how effectively the platform is and enables the Operator to evaluate their success at reaching operational and business targets.

A KPI is composed of a consistent set of metrics. A metric is absolute or relative to a duration:

• A measured value is associated with a timestamp - beginning of aggregation period and
  

• Optionally a duration
  

Here below is an extract of the Operator Dashboard User Interface:

KPI Generation

KPI measured values are generated by TWA-SPARK at a given aggregation period for a given resource.

• Supported aggregation periods are 10 minutes, 1 day and 1 week
  

• Supported resources are Base Station, Network Partner and Operator
  

Input data used by TWA-SPARK to produce KPI measured values may be:

• Kafka topics: LRC type of reports or KPI measured values produced on lower aggregation period
  

• MongoDB collections
  

• MariaDB tables
  

Please note that several inputs may be combined together

KPI measured values are produced by TWA-SPARK in Kafka KPI topics:

• One topic per tuple {resource, period} containing all KPIs: KPI.<RESOURCE>.<PERIOD>.v1
  

Where:

• <RESOURCE> is "LRR" (Base Station), "NP" (Network Partner) or "OP" (Operator)
  
• <PERIOD> is "600" (10 minutes), "86400" (1 day) or "604800" (1 week)
  

The image below describes the KPI generation process. At the left side these are the “producers” which are the source of information. In the core architecture, we have positioned a Spark server to process and create those KPIs through Spark Jobs. These aggregations are pushed to a Kafka server and then into a MongoDB. The latter is set at the right side of the image here below.

KPI Value Storage

KPI measured values are stored in a ThingPark MongoDB and are inserted in MongoDB by TWA-KP. Here below a technical high-level description of the collection (record) and stored documents:

• One collection is set per resource type:
  
• OperatorMetric (Operator)
  
• NetworkPartnerMetric (Network Partner)
  
• BaseStationMetric (LRR)
  
• One document is set per tuple { resource, timestamp, period } containing all KPIs: each KPI has its own dedicated sub-structure
  
• The document is created by the first generation of KPI measured values for the tuple
  
• The document is updated for each next generation of KPI measured values for the tuple
  
• Document expiration will depend on the aggregation period:
  
• 10 minutes aggregation: expiration is set to 10 days with maximum of 1440 documents per resource
  
• One-day aggregation: expiration is set to 1 year with maximum of 366 documents per resource
  
• One-week aggregation: expiration is set to 3 years with maximum of 156 documents per resource
  

KPI Value Retrieval

For visualization, KPI measured values are retrieved by the TWA-DASHBOARD Webservice API. Each KPI is associated with metadata providing the meaning of the KPI and the supported retrieval modes. Depending on the specific KPI type, three retrieval modes may be available: Time Series, Distributions and Last Values.

• Time Series - Time series retrieval mode consists in retrieving a sequence of values indexed by time. This mode is used for Timeline Chart (Line Chart, Bar Chart) visualization.
  

• Distributions - Distributions retrieval mode consists in retrieving a sequence of values indexed by Base Station or Network Partner. This mode is used for Comparison Chart (Top 10, Bar Chart, Pie Chart) visualization where the measured values are compared by Base Stations or Network Partners.
  

• Last Values - Last values retrieval mode consists in retrieving the last set of values. This mode is used for Comparison Chart (Top 10, Bar Chart, Pie Chart) visualization where measured values are compared among themselves.
  

Spark Server Integration

Two types of Spark Jobs are implemented by the TWA-SPARK service:

• Spark Structured Streaming Jobs: continuously running
  
• Used to compute KPI measured values relying on LRC reports
  
• LRC reports are consumed in Kafka OSS topics
  
• Windowing and Watermarking features are used to handle late reports
  
• Update output mode is used to produce a first result as soon as the aggregation window is over
  
• KPI measured values are produced in Kafka KPI topics
  
• Spark Batch Jobs: periodically triggered
  
• Used to compute KPI measured values relying on lower aggregation periods or on MongoDB/MariaDB (SQL) data
  
• KPI measured values computed on lower aggregation periods are extracted from MongoDB rather than Kafka KPI topics
  
• KPI measured values are produced in Kafka KPI topics
  

Supported KPI’s

Here below is the list of out-of-the-box supported KPIs

• Cumulated number of uplink/downlink frames
  

• Device Packet Error Rate (PER) statistics
  

• Statistics on the number of Devices per Base Station (ThingPark v5.0 roadmap item)
  

• Cumulated number of Base Stations per Base Station profile
  

• Cumulated number of Base Stations per health state
  

• Cumulated number of Devices per Device profile (ThingPark v5.0 roadmap item)
  

• Cumulated number of Devices per health state
  

• Cumulated number of Subscribers per Device Manager subscriptions (ThingPark v5.0 roadmap item)
  

• Macro Diversity average per Base Station
  

• Worst Base Stations by uplink noise estimation (ThingPark v5.0 roadmap item)
  

User Interface

The Wireless Dashboard GUI is integrated as an Operator module. The new Dashboard tab is automatically opened and displayed to the Administrator user immediately after login (landing page).

The Dashboard GUI is developed on a new Bootstrap Template Genius UI [https://genesisui.com/bootstrap-admin-template.html?id=genius](https://genesisui.com/bootstrap-admin-template.html?id=genius) . Which enables a fast way to build modern administrator sites and dashboard for any browser or device.

The Dashboard page is composed of a static set of widgets as illustrated in the image above. Each widget is associated with a KPI and specific visualization settings.

At first login, a default widget configuration is loaded. This default configuration is customizable per Administrator user. The customization is saved and automatically restored at the next login. This feature enables Operator Administrator users to configure their own private Dashboard.

In ThingPark future releases additional GUI and UX enhancements will be introduced such as drag and drop or turn on/off specific widgets.

Key Customer Benefits

KPIs are a necessary part of any IoT Operator business aiming for success to measure, monitor and manage performance; they allow Operators to envision what needs to be done to improve their organization.

ThingPark Wireless KPIs enables Operators to excel, have a global and detailed view on its current operational and business performance. This is done through advanced extraction, processing and retrieval mechanisms via GUI or via Webservice. Granting full flexibility to the Operator to manage its own specific Dashboard

NFR#691 ThingPark Cellular Phase 2

Feature Description

The scope of this NFR is the introduction and the integration of cellular Devices into ThingPark Wireless.

For more information on EPC elements and Sx interfaces please visit the following Wiki site https://en.wikipedia.org/wiki/System_Architecture_Evolution

The phase 2 includes a complete end to end provisioning solution of cellular Devices which relies on Actility EPC connector the P-GW and the HSS/SPR sub-systems.

The P-GW uses only data provisioned in the SPR (Subscriber Profile Repository) while data provisioned in the HSS is used only by the LTE core network (i.e. MME, S-GW):

• When the MVNO uses Actility HSS, TWA will provision both HSS data and SPR data
  

• When the MVNO/MNO uses a 3rd party HSS, TWA will provision only the SPR data
  

The below images represent the LTE-HSS integration:

Actility Cellular and ThingPark Wireless interfaces are listed here below:

ThingPark Wireless Provisioning

The following ThingPark Wireless Applications have been enhanced to support the provisioning of cellular devices:

Limitations

The following feature limitations needs to be considered:

• This feature is set for demos and PoC (Proof of Concept) modes only
  

• High Availability and Disaster Recovery are planned roadmap items
  

Key Customer Benefits

This feature enables ThingPark Wireless Operators to leverage their connectivity types and enable both LoRaWAN and Cellular (different Cellular LTE categories) offerings. It enables the provisioning of Cellular Devices in a unified manner using the same mechanism, processes, roles and models as for ThingPark Wireless. It enables Operators to benefit from one and single NW and operating processes.

NFR#730/#731 ThingPark Wireless Join Request Message and Device Uplink to Application Server Prevent Replay Attacks

Feature Description

The purpose of these two features is to solve LoRaWAN security breaches.

NFR#730

• Current behaviour before NFR#730
  

If a malicious user replays an outdated activation (Join request) message, the LRC doesn’t drop the message and creates new network and application sessions keys. The legitimate Device still sends frames, but they are no longer processed because the session keys have been changed. The LRC should block those kinds of attacks.

• NFR#730 enhancements
  

The LRC will not “flush” the current session context (in its file system) after successfully processing the Join-request anymore. Instead, the LRC will wait for the first UL frame MICed using the new session key before flushing the previous context (counters, session key). Additionally, the LRC will keep track of the last DevNonce, to limit additional tentative replay attacks.

The process will be carried out in a twostep processing:

• First, validation of the JoinReq based on DevNonce history
  

• Secondly, validation of the JoinReq based on the next Uplink MIC
  

Please note that if the DevNonce generation is randomly generated by the Device, with a certain history limit which are kept in the LRC (e.g. up to 50), the probability to regenerate the same DevNonce will be at a rate of ~0.1% per Device. In this case the JoinReq will be ignored by the LRC, and the Device will have to regenerate a new JoinReq with a new DevNonce and resubmit its request.

When a join request attack is detected by the LRC, the LRC will report an alarm document to TWA.

NFR#731

• Current behaviour before NFR#731
  

When a Device sends an uplink frame, received by the LRC with the same FCntup, it may process its application payload more than once. Hence replaying an applicative message is possible and may lead to trigger a malicious action, the LRC should detect and block this kind of attacks.

• NFR#731 enhancements
  

the LRC will send the application payload to the 3rd party AS only once, and never again in response to receipt of subsequent copies of the same UL. The LRC will now discard the application payload in re-transmitted frames.

The LRC will verify and raise a TWA alarm if:

• It detects a wrong MIC
  

• It detects wrong FncUp
  

• It detects a repeated FncUp
  

For more information on this feature please also refer to the LoRaWAN Change Request TC12

ThingPark Wireless Operator Manager Application

ThingPark Wireless Operator Manager / Device Profile has been enhanced to support this feature.:

• A new field of maximum number of transmissions the Device performs for confirmed uplink frames
  

• A new field of an implicit reset that can be assumed when the FCntUp rollbacks to 0 and when the LRC security context is desynchronized
  

Device Manager Alarms

The following new Alarm types have been added onto the Device Manager application:

• 007: Join request replay detected (DevNonce replay)
  

• 008: Wrong MIC detected in Join request
  

• 009: Join request replay detected (wrong MIC correlation)
  

• 010: Uplink frame replay detected (wrong FCnt)
  

• 011: Uplink frame replay detected (repeated FCnt)
  

Key Customer Benefits

This feature enables ThingPark Wireless customers and their users to be aware of Join Request or applicative message replay attacks, which is a form of a network attack in which a valid data transmission is maliciously of fraudulently repeated. ThingPark Wireless will also raise a user alarm in case of such replay attacks detections.

NFR#765 ThingPark Wireless Geolocation Stateless Solver

Feature Description

The scope of NFR#765 is the introduction of High Availability and Scalable Geolocation solver which requires a stateless solution.

It aims solving the following required target configurations:

• High availability network solver
  

To enable Operators to deploy multiple stateless geolocation solvers, so that if one is failing he can feed the data to the backup solver instead without losing the solver state.

• Scalable network solver
  

To enable Operators to deploy multiple stateless geolocation solvers so that it can send its state and data to any of them based on simple criteria’s

The following is set as part of NFR#765:

• To support a high availability solver solution, the solver becomes a stateless server
  

• For scalability purposes, the solver will now be hosted on a dedicated virtual machine, and will implement an n+1 scalability pattern
  

The image below shows the targeted stateless architecture:

• Solver context backup
  

The solver context is now provided by the LRC to the solver on each \. The solver context is retrieved by the LRC from Table B (contextual information).

The solver may update the context on each \, in this case the LRC will back up the solver context in Table B so it can be provided to the solver on the next iteration.

In case of LRC1 failure, or when the connection between the LRR and LRC1 is lost, new Uplinks will be processed by LRC2. As Table B is synchronized between both LRCs, LRC2 will be able to retrieve the last backup solver context provided by the solver to LRC1 and vice versa.

• Load balancing
  

NFR#765 introduces a random load balancing mechanism between LRCs and solvers.

The configuration of the list of solvers URLs can be configured per-operator (operator-wide configuration). In this case the solvers can only be used by this (these) operator(s).

The operator-wide configuration is optional. When no operator-wide configuration is set, the LRC will use a default list of solvers URLs (system-wide configuration).

Key Customer Benefits

This feature enables the following advantages:

• Allows a simple High Availability and Scalability scheme for network solver
  

• Have a robust geolocation solver to avoid software failures in Operators production geolocation services
  

• Enables the support for customers who favours stateless implementation of solver integration
  

NFR#766 ThingPark Wireless Respect maximum downlink Dwell time by respecting the maximum payload size of each Spreading Factor

Feature Description

The scope of NFR#766 is to implement the LoRaWAN maximum payload size constraints, dwell time, as specified in the LoRaWAN regional specifications:

• Limited to Downlink messages only as Uplinks payload size are not yet controlled by the LRR nor the LRC
  

• Max Payload size configurations are computed as the sum of the maximum payload size of the application payload plus any MAC commands sent in FOpts field.
  

The feature supports the following scenarios:

• When the Downlink contains only MAC commands
  

• When the Downlink contains MAC commands and 3rd party AS payloads
  

Interfaces and Application Changes

• A new Device Profile attribute is added to set if the LRC should enable or disable the maximum Dwell time inspection.
  

• When the LRC rejects the 3rd party AS Downlink, a status return message is set in \
  

• If the Downlink cannot be sent neither on RX1 nor RX2, the LRC rejects the 3rd party AS Downlink message with an error 350 “Invalid payload size according to currents DR”
  

Key Customer Benefits

This feature enables LoRaWAN Operators, and their entire eco-system, to align to the LoRaWAN specifications and respect dwell time regulations.

NFR#781 ThingPark X Datalogger Enhancements For Data Source Selection

Feature Description

Before the introduction of ThingPark X Datalogger NFR#781, the association of a graphable chart and its database containers data sources, was either done manually or through an intermediate Actility Administration User.

This NFR aims to enable the association of data sources containers, into the Datalogger application by Users, so to visualize the data of those containers using Datalogger graphs.

The configuration mechanism in the Datalogger application itself, through a native ETSI M2M Discovery mechanism, is mapping to the User Datalogger Application a filtered list of containers, that the Datalogger application can graph based on time series. Those containers need to be set in advance with a Discovery string, so later the Datalogger to retrieve them and propose the User to graph them in the Datalogger application.

The User, through a new data source selection GUI wizard, can:

• Manage data sources
  

• List data sources
  

• Filter and Search data sources
  

• Can give a friendly name to data sources
  

• Can replace data sources
  

• Benefit of tool-tips and help menus
  

Please note that it is assumed that the User will have the correct Access Rights to retrieve the list of containers e.g. his part of the Subscriber VGSCL organisation.

Here below is an image of the delivered functionality:

Key Customer Benefits

This feature completely removes any backend manual operation that was previously done to graph data sets in Datalogger. Not only it removes the intervention of Actility Administrators, but it also enables the End User itself, to be autonomy and provisioning his own graph, at any moment, based on his specific business and operational requirements.

NFR#788 ThingPark Wireless Show a Complete List of Uplink receiving Base Stations

Feature Description

ThingPark Wireless v4.3 offered a possibility to view only a limited number of receiving Base Stations for a given received Uplink. Precisely, the number of receiving Base Stations (macro diversity) as displayed in Wireless Loggers was limited to 10 Base Stations and to 3 in the AS Tunnel API (Dev_EUI type of messages).

To support this new capability a new debug option (lorlog) is added to the activated devices context table (Table A) in the LRC:

• For a given Device, when the loralog debug option is deactivated, the current behaviour is maintained.
  

• For a given Device, When the loralog debug option is activated, the new behaviour is:
  

  • The LRC traces all Uplink traffic associated to the device before the 250ms deduplication window. As a result, the traced Device logs includes information such as repetition associated to the macro diversity, antenna diversity and frequency diversity
    

  • Each trace log includes the entire associated data (not decoded) and associated metadata associated to the specific Uplink.
    

Traced log files are stored on a LRC local file system:

• Each Operator is associated with a dedicated folder. This configuration allows, on a ThingPark SaaS Platform to associate each folder to a dedicated SFTP account - The NetID of the Operator is used to name the folder.
  

• Each Device is associated to a dedicated LoRaWAN log file - The DevEUI of the Device is used to name the file
  

For example: ~/var/log/lrc/loralog/\/\.log

Both the trace file maximum size and maximum number of archives can be set in a global system wide configuration.

Feature Process

For devices where loralog debug option is activated

• The list of Devices with loralog debug option is activated will be stored in RAM. The total number of Device allowed in this debug mode is set to < 100
  

• For OTAA Device - Before the 250ms deduplication window, when the LRC receives a JOIN Request message, the LRC checks if the DevEUI is associated with the debug flag (loralog). If so the LRC appends the Uplink in question to the associated trace file
  

• For OTAA and ABP Devices - When the LRC receives an Uplink, the LRC verifies if the DevAddr is associated with the debug flag (loralog). If so the LRC appends the Uplink in question to the associated trace file
  

Trace File Structure

Log file format is in set to CSV. Its structure is the following: lrcts;devaddr;netid;deveui;lrrid;rssi;snr;esp;sf;sb;lc;chain;ftq;lrrts;payload;

Defined as:

• lrcts: LRC timestamp in seconds with milliseconds precision e.g. 1501083074.781
  

• devaddr: Device address
  

• netid: Network id
  

• deveui: Device EUI
  

• lrrid: LRR id
  

• rssi: Received Signal Strength Indication
  

• snr: Signal to Noise Ratio
  

• esp: Estimated Signal Power
  

• sf: Spreading Factor
  

• sb: Sub Band number G1, G2, G3
  

• lc: Logical Channel
  

• chain: Antenna id if configured in lgwXXX.ini
  

• ftq: Fine Time Qualifier
  

• lrrts: LRR timestamp in seconds with milliseconds precision if ftq=0 e.g. 1501083074.781 or with nanoseconds precision if ftq=1 e.g. 1501083074.408952390
  

• payload: LoRa payload
  

Feature Limitations

• For scalability reasons, the list of Devices where the loralog debug option is activated is built step by step in memory after the reception of the first Uplink for each Device. In consequence the first Uplink, join for OTAA or standard Uplink for ABP, received by the LRC for each Device, will not be traced
  

• Resetting loralog debug option is considered only after the standard treatment of the next Uplink
  

• In theory, several Devices may share the same DevAddr. Assuming maximum of 100 Devices activated with debug set to loralog at a certain time, the probability to have two Devices with the same DevAddr while one with debug set to loralog is very low. This limitation will be treated as a roadmap item
  

• Log rotate mechanism is used on trace files to limit the disk space allocation - the trace file is archived when it reaches its maximum size
  

• Several archives can be kept at the same time - each archive is indexed with an integer, the archive with the index 1 is the recent one
  

• Storing log files on the LRC filesystem is not based on a clustered solution
  

• Debug log files are not purged when LoRaWAN debugging is deactivated
  

Key Customer Benefits

By having the complete list of Base Stations receiving a specific Uplink, the Operator can perform network benchmarking or network optimisations through the captured LoRaWAN metadata such as the SNR and RSSI indicators.

NFR#797/NFR#791 ThingPark Wireless Geolocation Interface Enhancements

Feature Description

The purpose of this feature is to extend the Geolocation Request and Response interfaces in between the LRC and the geolocation solver.

For more information please refer to the ThingPark Wireless LoRa Geolocation Solver Release document.

NFR#797 – Geolocation Request Enhancements

The following information elements are provided to the Geolocation solver, by the LRC, in addition of the existing information elements.

• Reset indicator
  

This attribute indicates that a Device reset has occurred - the reset applies only to OTAA type of Devices. The reset indicator is set to 1 when the associated Uplink is a JoinReq message.

• ADR indicator
  

This attribute indicates if the ADR function is allowed for this Device - The ADR indicator is set to 1 when SFmin < SFmax in the associated Connectivity Plan / ServiceProfile (LRC).

• Motion indication
  

The motion indicator defines a new value of Auto (4). When the motion indicator is set to Auto, the geolocation solver automatically detects the Device motion status. The cluster management and filter configuration are set accordingly by the solver.

The following interfaces are impacted by these changes:

• LRC - Reporting of the reset indicator and ADR indicator in the <GeolocRequest> message
  

• RTLSNET solver to comply with the new Webservice interface
  

• LRC/Solver interface enhancements
  

• LRC/TWA interface enhancements - <DeviceProfile> and <Device> structures are enhanced to accept a new value for the motion indicator
  

• LRC/AS interface enhancements - no impact
  

NFR#791 – Geolocation Response Enhancements

The following information elements are provided by the Geolocation solver to the LRC, in addition of the existing information elements.

• Uplink FCntUp
  

The geolocation solver will now return the most significate FCntUp used to provide the geolocation result.

• Vertical and Horizontal dilution
  

For debugging purposes, the geolocation solver will now return the vertical and horizontal dilution figures. Please note that this information is used for maintenance and troubleshooting only and will be available in LRC log files only.

• North and East velocity
  

The geolocation solver will now return the estimated velocity to the LRC.

Please Note that the field \ (Accuracy) is deprecated and is no longer reported by the geolocation solver.

The following interfaces are impacted by these changes:

• LRC - Reporting of these fields to 3rd party AS and to TWA
  

• RTLSNET solver to comply with the new Webservice interface
  

• LRC/Solver interface enhancements
  

• LRC/TWA interface enhancements
  

  • <EUI_Uplink> message is updated to support the new <GeolocResponse> new fields
    

  • <EUI_Location> message is updated to support the new <GeolocResponse> new fields
    

• LRC/AS interface enhancements
  

  • <DevEUI_Uplink> message is updated to support the new <GeolocResponse> new fields
    

  • <DevEUI_Location> message is updated to support the new <GeolocResponse> new fields
    

Key Customer Benefits

The extension of the current geolocation solver HTTP/XML interface enables Operators to have an improved capability to integrate geolocation solvers with Actility LRC Network Server. This is required for specific configurations and maybe network dependant. For example, the field \, which is the most significate FCntUp used to provide the geolocation result, enables Operators to correlate which Uplink frame have been considered into the geolocation estimate.

NFR#857 ThingPark X Enable a Swagger API Framework

Feature Description

The purpose of this feature is to enable a ThingPark X Operator to have access to a Swagger API Framework. Swagger is a known framework of API developer tools for the OpenAPI Specification (OAS), enabling development across the entire API lifecycle, from design and documentation, to test and deployment.

To support this feature, a M2M Swagger file will become available to the User to be opened either directly in his browser or via automatically YAML downloaded file. While the former option displays a raw YAML content, the latter visualizes a user-friendly API swagger environment allowing to modify body values and execute HTTP requests. A usage of its own Swagger UI is equally set at customer’s service.

Key Customer Benefits

The feature simplifies the introduction, usage and testing of the ThingPark X APIs via a simplified but well-built Swagger’s UI taking the user to an interactive ride-along and allowing him to customize the request body as well as to execute the concerned API request. Alternatively, to any other API client, Swagger is comprehensive, human and machine readable, library-like approach to Thing Park APIs implementation.

NFR#921 ThingPark Wireless Support for LoRaWAN 1.0.2 Regional Parameters

Feature Description

The purpose of this feature is to support the CN 470-510MHz and China 779-787MHz ISM Bands RF Regions as defined in the LoRaWAN_Regional_Parameters_v1.0_20160812-1 specification document.

The following identifiers and notions are implemented:

• For CN 470-510MHz ISM Band - cn470 defines 96 Uplink channels and 48 asymmetric Downlink channels.
  

• For China 779-787MHz ISM Band - cn779 defines 16 symmetric Uplink and Downlink channels
  

To be compatible with new China regional parameters the following ThingPark Wireless Components and Applications have been enhanced:

• LRC
  

• LRR
  

• TWA
  

• Wireless Logger
  

• ThingPark Wireless RF Tools
  

Customer Benefits

The feature enables ThingPark Operators to operate the various ThingPark Wireless products in the Chinese region and benefit from a full compatible LoRaWAN network and OSS stuck.

NFR#946 ThingPark Enterprise Early Availability v2

Feature Description

ThingPark Enterprise v4.2 Early Availability Appliance Edition was the first version of Actility new offering for the Enterprise market. The purpose of this feature is to enhance the initial version and introduce the second Early Availability version of the ThingPark Enterprise.

The following features have been introduced in V4.3 TPE version:

Customer Benefits

With the above listed enhancements, ThingPark Enterprise Operators have much better capabilities and tools to operate their platforms.

As major enhancements are expected already in ThingPark Enterprise v5.0, this v4.3 EA version enables the Operator to safely upgrade their platform, in the future, without losing any of their data in a simplified, automatic no human intervention manner.

NFR#947 ThingPark Wireless ADRv3 Algorithm Uses Number of Receiving GWs with a Finetimestamp

Feature Description

This feature enables ThingPark Wireless Operator, to operate ADR algorithm decisions based on “Finetimestamp count” instead of the “LRR count” so that it can optimize the ADR result for geolocation purposes. This is the number of gateways, after the 250ms deduplication window, associated with a finetimestamp.

This feature is required in a use case where a Device needs to be geolocated within a mixed network of V1 & V2 gateways.

• At the end of 250ms de-jitter period, the LRC will report the number of distinct LRR reporting valid fine timestamps for each uplink packet, in addition to the LRR count reported today
  

• In the ADR V3 algorithm, the fine timestamp count will be considered to compute the overlap metric instead of the LRR count i.e. the GwCNT will be read from the fine timestamp count instead of the LRR Count in today’s implementation
  

• No other changes are introduced
  

Customer Benefits

This feature enables a precise ADR V3 decisions for geolocation purposes thus increasing the actual geolocation results accuracy. For Actility customers it enables an enhanced geolocation accuracy for heterogenous networks

NFR#973 ThingPark Wireless LoRaWAN nwkID prefix change

Feature Description

The purpose of this feature is to enable ThingPark operators to support the new LoRaWAN NwkID format so that ThingPark Wireless supports both the existing and future entered DevAddr.

In LoRaWAN 1.0.x specification the DevAddr is formed using a fixed length NwkID (7 bits). Those are the 7 LSB bits of the NetID. The limitation with this configuration is that those 7 bits will easily be wrap around and start to collide among allocated NetIDs. In the future there will be allocation of more than 2\^7=128 NetIDs, and eventually multiple NetIDs will be mapped onto the same NwkID.

For this reason, a new DevAddr format is set:

• There will be diverse types of NetIDs, with different NwkID lengths
  

• This ensures we are not forced into a 7bit NwkID space
  

• Each type has different strength in terms of how soon the NwkID space may wrap around (or, even allowed to wrap around), and how many bits are there for uniquely identifying devices for each NwkID
  

The LRC is realigned on the new NetID and NwkID allocation policy limited to Type0 and Type3 operators

• Operator Type0:
  

• NetID = 000 + 000000000000000 + ID (6 bits)
  

• DevADDR = 0 + NwkID (6 bits) + NwkAddr (25 bits)
  

Please note that:

• NwkID = ID
  

• Maximum 2^6 Type0 operators / Maximum 2\^6 NwkID / Maximum 2^25 DevADDR per operator
  

• Operator Type3:
  

• NetID = 011 + ID (21 bits)
  

• DevADDR = 1110 + NwkID (11 bits) + NwkAddr (17 bits)
  

Please note that:

• NwkID = 11 LSB of ID
  

• Maximum 2^21 Type0 operators/ Maximum 2^11 NwkID / Maximum 2^17 DevADDR per operator
  

The following LRC functionality is enhanced to support the above changes:

• DevAddr allocation (OTAA pool)
  

• Foreign operator selection (Stateless PR)
  

Limitations and Clarifications

• None of the already allocated NetID owners are affected by this new NetID/DevAddr scheme but only future ones
  

• This change applies also to LoRaWAN 1.0.x type of deployments
  

• For additional details please refer to the LoRa Alliance NetID policy
  

Customer Benefits

This feature enables Actility ThingPark Wireless Operators to align with LoRaWAN specifications and to ensure that all ThingPark Wireless applications are compatible with latest LoRaWAN Technical Committee decisions and policy changes.

Additional benefits are highlights in the feature description itself and are not repeated in this section.

Issues Resolved for Customer Project/Customer Support

This section lists the issues that are resolved in ThingPark 4.3

About Actility

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