Feature Limitations

The Proof-of-Concept implementation of this feature in release 6.0 has the following limitations:

• The indoor base station must be within the coverage area of an outdoor macro base station that is GPS-synchronized. If this condition is not fulfilled, the indoor base station cannot support class B operation.
  

• SYNC-frames sent by the LRR are not authenticated by a Message Integrity Code (MIC). This limitation shall be lifted in the productized implementation in future releases.
  

• The configuration of the synchronization mode is done manually; it will be automatically controlled by ThingPark in the productized implementation.
  

• The RF frequency and data rate used by SYNC-frames is configurable directly in lrr.ini in the current release; this configurable will be supported at RF Region level in the productized version.
  

• The indoor BS synchronization mode (synchronized-by-macro) is not reported to Network Manager in the current release, hence the indoor BS is seen as “GPS-synchronized” as long as it remains synchronized via an outdoor macro BS.
  

• Only unicast class B is supported in the current release, multicast class B is not yet implemented (will be supported in the productized implementation).
  

Feature Interaction Matrix

Scalability/Performance Improvement Features

RDTP-6447: LRCv2 Early availability (PoC)

Feature Description

The scope of this feature is to support a proof-of-concept (PoC) for LRCv2 in release 6.0.

LRCv2 is the long-term evolution of the current LRC sub-system, providing a horizontally scalable and fault-tolerant subsystem, that aims to replace LRCv1 in ThingPark Wireless deployments.

Two types of functions are introduced in the LRCv2 and are spread out on distinct virtual machines:

• RAN function dedicated to the management of the LRR state machines (LRR TCP/IEC-104 connections, periodic LRR reports…etc.).
  

• DEV function dedicated to the management of DEVICE state machines (uplink / downlink LoRaWAN processing, advanced radio algorithms (ADRv3, best-LRR selection…etc.) as well as implementing the tunnel interface with Application Servers.
  

The following diagram illustrates the main LRCv2 architecture:

• Each RAN-GROUP or DEV-GROUP consists of two RAN instances, spread over  two physical site locations to support geo-redundant High-Availability architecture.
  

• The LRCv2 is based on active-active architecture: in average, each LRC-RAN instance within the RAN-GROUP acts as primary for statistically 50% of the LRRs connected to this RAN-GROUP and secondary for the other 50% of the LRRs. Likewise, each LRC-DEV instance within the DEV-GROUP acts as primary for roughly 50% of the devices associated with this group and acts as secondary for the other 50% of the devices.
  

• The RAN-GROUP serving each LRR is determined by a hash function on the LRR-ID. This function is designed in a way that equally balances the RAN load over the different RAN-GROUPs deployed in the platform. A “BOOT SERVER” component is introduced by LRCv2 architecture to inform each LRR of its RAN-GROUP configuration.
  

• The DEV-GROUP serving each device is determined by a hash function on the DevAddr. Like for RAN-GROUP, the DevAddr hash function aims at equally balancing the DEV load over the different DEV-GROUPs deployed in the platform. For uplink frames, RAN hashes the DevAddr included in uplink frames to determine which DEV-GROUP should the uplink frame be routed to (note: a special behavior is implemented for Join Request frames until DevAddr is allocated by the LRC). For downlink frames coming from AS, the DevAddr hash function is implemented by the PROXY-HTTP Server.
  

• The communication between RAN and DEV groups uses a Kafka message bus to bring additional scalability and resilience gains to the overall architecture.
  

• RAN/DEV functions on LRC are fully integrated with their peers in TWA architecture:
  

  • LRR Reports produced by LRC-RAN are consumed by TWA-RAN (already supported in ThingPark architecture since release 5.2.2, also known as TWAv2].
    

  • Device Reports (uplink/downlink frames, location reports, downlink sent indication, multicast summary reports) are produced by LRC-DEV and consumed by TWA-DEV (also introduced in TWAv2 architecture).
    

• All incoming flows to LRC remain accessible via a PROXY-HTTP Server, like LRCv1 architecture. However, the internal interface between PROXY-HTTP and LRC-DEV is based on Kafka brokers.
  

The scope of this feature in the current release is to validate the LRCv2 architecture in lab environment :

• LRR bootstrapping and connection to RAN-GROUP.
  

• OTA device attachment: Join procedure, DevAddr assignment…
  

• Uplink/downlink frame processing (OTA and ABP).
  

• Passive Roaming: fNS and sNS behavior.
  

• Addition of new RAN/DEV functions to simulate capacity extension.
  

Key Customer Benefits

LRCv2 brings substantial scalability enhancements over LRCv1, these gains are illustrated by the following table:

(*) NOTE: The max # LRR connections with LRCv2 considers the following assumptions:

• For macro gateways, LRR reporting periodicity = 300s (5 minutes).
  

• For pico/nano gateways, LRR reporting periodicity = 3600s (1 hour).
  

The split of the LRC functions into RAN and DEV allows flexible (and independent) horizontal extension of these instances: RAN-GROUPS scale with growing number of LRR connections (driven by radio coverage extension and network densification requirements), whereas DEV-GROUPS scale independently from RAN-GROUPS according to the LoRaWAN traffic growth and the number of devices supported by the platform.

On top of its substantial scalability advantages over LRCv1, LRCv2 architecture also has some functional advantages: Unlike LRCv1, an uplink/downlink frame of a given device cannot be processed by several LRCs at the same time in LRCv2: thanks to DevAddr hashing, only one DEV instance shall be competent to process all the frames of a given DevAddr.

NOTE: the LRCv1 limitation described above shall also be lifted in TPW release 7.0.

Feature Activation

This feature is deactivated by default, i.e. LRCv1 architecture remains activated after the upgrade to release 6.0. Please contact Actility Support team if you want to run a PoC for LRCv2 architecture.

Feature Limitations

The LRCv2 implementation in the current release is not yet fully productized, it is only for PoC demonstrations in lab environment. The following limitations are present in the current release:

• LRR-LRC security mode in the current release is only TLS-based, IPSec mode shall be supported in future releases.
  

• Device/base station provisioning from TWA to LRCv2 is not supported in release 6.0 (TWA provisioning should use Kafka with LRCv2 instead of HTTP, will be addressed in future ThingPark releases). Hence, the base stations and devices used during the PoC phase shall be manually provisioned in LRCv2.
  

Feature Interaction Matrix

RDTP-5790: Modified use of blast mode in Application Server configuration

Feature Description

When a subscriber configures an Application Server through the Device Manager application, it is possible to define multiple destinations for the same AS. This option is essentially meant to allow the definition of alternative destinations in case the primary destination URL cannot be resolved / is not responding; a routing strategy defined by Device Manager as “Sequential”.

Prior to release 6.0: Two different modes were supported when configuring multiple destinations within an Application Server (AS):

• Sequential mode: To send a frame to the AS, the LRC uses the first destination URL. If the LRC receives an HTTP 200-OK from this first destination, it does not send the frame to other destinations associated with this AS. However, if this first destination is blacklisted or is not responding, the LRC tries the second destination in the ordered list and so forth… At the end, the frame is never sent to more than one destination.
  

• Blast mode: The LRC sends the same frame to all the destinations at the same time . However, the use of this mode could negatively impact the LRC performances (CPU load) in case of slow-responding/irresponsive AS using HTTPS tunnel interface.
  

Starting release 6.0: to improve the LRC performances and scalability, the blast mode is modified. While it is still possible to send the uplink frame to several destinations, the LRC does not trigger for all the destinations at the same time: the delay between two successive transmissions (to destinations Dn-1 and Dn) is limited by either the response time of Dn-1 or the CURL timeout of Dn-1 (whichever is smaller).

• If the routing strategy is already sequential => no change in release 6.0.
  

• If the routing strategy is blast => the LRC applies a short delay between transmissions towards the different destinations.
  

IMPORTANT NOTE: in release 6.0, it is still possible to configure a routing profile so that several destinations can simultaneously receive the same uplink frame without any delay. To do so, the subscriber needs to create a distinct Application Server (AS) for each destination URL then add those AS to their AS routing profile. Each individual AS shall have one or several destinations (for reliability purposes) in sequential mode.

This is Actility’s recommended approach.

Key Customer Benefits

This feature helps improving the LRC performances by protecting the LRC from slowing responding or irresponsive AS using HTTPS interface.

Note: This feature has no impact on Application Serves using Kafka to consume the LRC uplink frames.

Feature Activation

The conversion of blast into sequential strategy for an Application Server is activated by default. It can be controlled in the LRC by a systemwide parameter in lrc.ini :

[lrnoutput].blasttosequential

• 0 : blast mode remains unchanged
  

• 1: blast mode is converted to sequential by the LRC ( default setting ).
  

Feature Limitations

Not applicable.

Feature Interaction Matrix

RDTP- 7021: TWA Asynchronous write operations

Feature Description

This feature introduces a new framework to asynchronously manage device creation/deletion tasks for both unitary level and mass/bulk import actions.

A task is an asynchronous processing triggered by a webservice API request implemented by an Application. A task is associated with a set of generic attributes: ID, creation timestamp, owner ID, state… When the asynchronous processing is complex, the task is split into several sub-tasks.

Prior to release 6.0: Mass/bulk import of devices is processed  synchronously by ThingPark. The Subscriber can import up to 4000 devices in one-shot via .csv upload. Synchronous processing means that the user launches the request, then waits until the request is executed by the API to get the result notification. This mode implies that the task execution duration is constrained by the maximum allowed delay between an HTTP request and its HTTP response (set to 60s in the current product).

Thus, before release 6.0, the maximum number of devices that can be imported in one operation is limited to 4000 devices, to fit the 60s delay described above.

Starting release 6.0: In addition to the synchronous mode (kept for backward compatibility and still used by Device Manager GUI to synchronously deliver the notification to the End-user), the device mass import task can be processed asynchronously via new API webservices. Asynchronous processing means that the reception of the requested task is acknowledged by ThingPark and allocated a task-ID, then it is processed in background in parallel to other tasks. Hence, the task execution duration is not constrained anymore by a maximum delay as it is the case in synchronous processing.Importing devices using asynchronous mode is supported by the new webservice:

POST /subscriptions/\/devices/import?async

When the request is accepted by TWA, the API responds as per the following example:

The location URL provided in the API response can be used (e.g. polled) by the Subscriber to follow-up the execution status of his bulk import request.

Therefore, thanks to the asynchronous processing, the user can import up to 50 000 devices in a single operation, providing substantial scalability improvement to the mass import functionality.

To support this new framework, three new applications are added to TWA architecture:

• TWA-DEV-TASK-FC: this application performs flow control to gradually inject the sub-tasks issued from the main task (typically mass import of devices) into the different Kafka topics. This flow control is crucial to efficiently parallelize the bulk import requests with other tasks to avoid blocking TWA resources on complex batch tasks.
  

• TWA-TASK-RES: this application retrieves the results of the individual sub-tasks and aggregates them to produce a consolidated result for the original task.
  

• TASK-NOTIF-WS: this application distributes the notifications to the different consumers.
  

Key Customer Benefits

For ThingPark Wireless Operators/Subscribers, the asynchronous import of devices offers higher scalability to ThingPark Wireless Subscribers.

Therefore, asynchronous import API allows extending the maximum number of devices per mass import request beyond the initial limit of 4000 devices. With this new API, it is possible to import up to 50 000 devices in a single mass import operation.

Additionally, the new framework introduced by this feature shall be leveraged in future releases to support bulk actions related to device/base station administrative operations.

This feature is also beneficial for ThingPark Enterprise customers, lifting a limitation present in previous releases regarding bulk import interaction with DX Dataflow.

Feature Activation

The new TWA architecture is automatically put in place with the upgrade to release 6.0.

The use of asynchronous APIs for device creation/deletion is optional , it is up to the API caller to choose between synchronous mode (existing behavior) and asynchronous mode (new behavior implemented by this feature) by using the right query parameter: Asynchronous mode is triggered by adding “async” query parameter to the request as follows:

• To create a new device: POST /subscriptions/\/devices?async
  

• To delete one device: DELETE /subscriptions/\/devices/\?async
  

• For mass/bulk import of devices: POST /subscriptions/\/devices/import?async
  

Feature Limitations

Feature Interaction Matrix

Platform performance improvement (RDTP-7035 and RDTP-10696)

Feature Description

The following improvements are introduced in release 6.0 to enhance the overall performance of ThingPark Wireless sub-systems:

• Slow Mongo query on BaseStationAlarm alarm 112 (RDTP-7035): Base Station alarm #112 refers to “Abnormal log activation” condition. When this alarm is triggered and the RAM-disk usage is true, instead of reevaluating the BS conditions every 5 minutes, the reevaluation is done only once to improve MongoDB performances.
  

NOTE: The default severity of this alarm (when RAM-disk usage is activated) is changed from Major to Minor starting release 6.0.

• LRC reduce CPU consumption for some threads when there is no traffic (RDTP-10696): The purpose of this improvement is to minimize the CPU consumption of some LRC threads (lora, join, lrn) when there is no traffic.
  

Key Customer Benefits

The improvements presented above enhance the performance of TPW sub-systems and improve their scalability/response time.

Feature Activation

The improvements presented above are activated by default.

Feature Limitations

Not applicable.

Feature Interaction Matrix

MAC Efficiency and Performance Optimization Features

RDTP-8570: [Multicast] - Optimization of LRC retry mechanism for unavailable LRRs

Feature Description

To transmit downlink multicast frames, the LRC uses a retry mechanism to reattempt the transmission of a downlink frame that could not be transmitted on the first attempt.

The scope of this feature is to optimize this retry mechanism when some base stations are not available during the first transmission attempt.

Consider the following example:

• LRR1: up and running, GPS-OK, Duty Cycle OK
  

• LRR2: up and running, GPS-OK, Duty Cycle OK
  

• LRR3: backhaul connection lost to LRC
  

• LRR4: up and running, GPS-NOK, Duty Cycle OK
  

• LRR5: up and running, GPS-OK, Duty Cycle NOK
  

Prior to release 6.0: Even if LRR3, LRR5 and LRR4 (for class B multicast only) are not eligible for the initial transmission attempt of the downlink frame, they were still reattempted on each subsequent retry in case their status has changed in the meantime.

The multicast summary report sent to AS includes the delivery status of all the LRRs in the initial list, i.e. LRR1…LRR5 in the example above.

NOTE: This process is re-initialized for every fresh downlink multicast frame, i.e. a non-eligible LRR for multicast frame “n” shall still be inspected for potential eligibility when multicast fame “n+1” is sent by the LRC.

For more details about downlink multicast, please refer to [6].

Key Customer Benefits

Thanks to this feature, the multicast transmission is enhanced to address an extended variety of use cases:

• If the multicast session targets battery-powered devices and the main target is to optimize the session duration the new behavior can be used to avoid reattempting the transmission of the same downlink frame on base stations that not available during the initial transmission attempt.
  

• Otherwise, if the multicast session targets class C devices that are mains-powered (no power budget constraint) and the main target is to maximize the downlink frame reception rate for end-device regardless of the session duration the old behavior can be used.
  

Feature Activation

The activation of the new behavior is controlled by the Application Server  (for instance, the RMC-Server for Actility’s FUOTA service) by setting a new boolean flag “RetryIneligibleGateways” in the query parameters of the downlink frame POST:

• RetryIneligibleGateways = 0 The new approach is deactivated. This is the default value if the parameter is not present, for sake of backward compatibility with previous releases).
  

• RetryIneligibleGateways = 1 The new approach is activated, hence the non-eligible base stations at the first transmission attempt are excluded from the LRC retransmission mechanism.
  

Feature Limitations

Not applicable.

Feature Interaction Matrix

In LoRaWAN specification, RX2 channel is used by all device classes to receive downlink frames; this receive window is opened 1 second after the RX1 window. Additionally, RX2 window remains open all the time for class C devices, allowing them to receive downlink frames at any time.

For class B devices, in addition to the conventional RX1/RX2 slots defined for class A, periodic downlink slots are available in class B: they are called pingslots, allowing the device to receive downlink frames without initiating a prior uplink transmission.

Prior to release 6.0: Only one RX2 can be defined for all the devices associated with a given RF Region. Also, for class B devices, only one  pingslot can be defined per RF Region. RX2 channel is always mapped to LC255 when reported to Application Servers (over the tunnel interface) or over LRC-OSS interface (towards TWA).

NOTE: The RX2 channel can be different from pingslot channel.

Starting release 6.0: it is possible to define several RX2 channels and/or several pingslots on the same RF Region. This means that the same LRR can serve devices having different RX2 and/or pingslot channels.

Additionally, starting release 6.0, LC255 is not reported any more for RX2: the “real” Logical Channel (LC) used by the LRR is reported to AS (over tunnel interface) and over LRC-OSS interface. The only except to this rule in release 6.0 is the Join Accept that is still reported with LC255 when it is sent over RX2 channel. This limitation will be lifted in TPW release 7.0.

In case of mono-RX2 configuration, the LC associated with RX2 is derived as follows rules:

If <RX2Freq> does not match at least one <RxChannel> or <TxChannel>:

        

If LC127 is not already used by a<TxChannel>:

                  RX2 LC is LC127
        Else
                  RX2 LC is LC max + 1
Else
        RX2 LC is the highest LC among all <RxChannel> and <TxChannel> matching the <RX2Freq>.

When more than one RX2/pingslot channel are configured in the RF Region, the LRC assigns the target RX2/pingslot channel for each device according to its DevAddr . For instance, if 4 RX2 channels are defined in the RF Region, the LRC computes the modulo 4 of each DevAddr to choose the target channel for this DevAddr, then sends this target channel to the device via the MAC command RxParamSetupReq.

Please refer the “Feature Activation” section for more details about configuring multiple RX2/Pingslot channels in the RF Region.

The downlink transmission slot is reported to Application Servers in the Downlink Frame Sent report, via the new attribute “TransmissionSlot”: 

• TransmissionSlot = 1 -> RX1
  

• TransmissionSlot = 2 -> RX2
  

• TransmissionSlot = 3 -> Pingslot (class B only).
  

NOTE: TransmissionSlot = 0 means unknown.

The Operator Manager application (both UI and API) is also enhanced by this feature to provide a synthesis of the Logical Channels configured in the RF Region. The Operator administrator can consult the Logical Channel description of each RF Region by viewing the RF Region in question and scrolling to the end of the page:

Network Manager impact:

To provide Network Manager users with consistent user experience after the introduction of multiple RX2/pingslot channels, some updates are brought to Network Manager application:

• Like previous releases, the radio statistics (duty cycle, Spreading Factor and RSSI/SNR) are displayed for each logical  channel under RF Cell panel in Network Manager. Starting release 6.0, when the RF Region used by the LRR is provisioned in Operator Manager, the RF center frequency (in MHz) is displayed in Network Manager when the user moves the mouse over a given LC tab; as highlighted in the example below:
  

• Additionally, the user can specify the group of RF Logical Channels that they want to display from the following list:
  

• Uplink/downlink channels: correspond to symmetrical Logical Channels, used for both uplink reception and downlink RX1 transmission slots.
  

• Asymmetric downlink channels: correspond to downlink-only channels, used for asymmetric channel plans (when downlink RX1 transmissions use a different frequency than the uplink channel) as well as downlink RX2, downlink pingslots and beacon signals.
  

Wireless Logger impact:

The background color of the “Channel” column on Wlogger determines the transmission slot (RX1/RX2/Pingslot) of each downlink frame (see example below):

• While background -> RX1
  

• Orange background -> RX2
  

• Blue background -> Pingslot (for class B).
  

NOTE: RX2 is explicitly displayed on the “Channel” column only for Join Accept packets sent on RX2. For all other cases, the Logical Channel (LC) of the RX2 slot is displayed. In TPW 7.0, Join Accept packets will also show the real LC in the “Channel” column.

Interaction between multi-RX2/pingslot and multicast:

To configure the downlink multicast channel for class B/C devices, two options are supported by ThingPark in the current release:

• Either the multicast frequency and data rate are directly provisioned in the Multicast Group This option is fully compatible with multi-RX2/pingslot configuration.
  

• Or the multicast frequency and/or data rate are not provisioned in the Multicast Group, so they are inherited from the RF Region configuration This option is not compatible with multi-RX2/pingslot RF Regions since there is no unique RX2/pingslot channel! When this happens, the LRC returns a multicast transmission error to AS with the following error message:
  

  • For class B: “Multiple Ping Slot channels and no configured multicast frequency” (F1).
    

  • For class C: “Multiple RX2 channels and no configured multicast frequency” (F2).
    

Key Customer Benefits

This feature brings significant downlink radio capacity enhancement for class B/C use-cases: thanks to this feature, instead of using the same RF channel for all end-devices, several downlink channels could be defined for the same LRR. Using several downlink RF channels also mitigates collision, RF pollution and potential jamming risks on a single channel.

This feature is particularly interesting for US915 and AU915 deployments (eight downlink channels are supported) as well as Asian deployments (AS923, Korea KR920, India IN865, China CN470) where all the potential downlink channels have the same transmission limits (TxPower, duty cycle or dwell time if required by the local regulation).

While this feature is fully supported for all the LoRaWAN regional profiles (ISM bands), it currently has low interest for European LoRaWAN deployments with the current ETSI regulation of EU 863-870 MHz band: the downlink sweet spot is RF channel 869.525MHz (currently used for RX2 and ping slots) thanks to its higher Tx Power (EIRP = 29.15 dBm) and duty cycle (10%) compared to other downlink channels.

Feature Activation

This feature is deactivated by default.

To activate this feature, the RF Region configuration needs to be modified to define several RX2 and/or pingslot channels as per the following examples:

• To configure multiple RX2 channels (for class A/B/C), all RX2 channels are defined by setting <UsedForRX2> to 1 in <TxChannel>  sections. The following example configures two RX2 channels are frequencies 922.6 and 922.8MHz:
  

<TxChannels>
    <TxChannel>
          <UsedForRX2>1</UsedForRX2> <!-- RX2 Tx Channel flag -->
          <LC>127</LC> <!-- RX2 Logical channel index -->
          <SB>3</SB>   <!-- RX2 Tx channel subband -->
          <DTC>10.0</DTC> <!-- RX2 Tx Channel duty cycle -->
          <Frequency>922.6</Frequency>           <!-- RX2 Tx Channel frequency -->
          <MaxDR>3</MaxDR>                                    <!-- RX2 Tx Channel data rate -->
    </TxChannel>

     <TxChannel>
          <UsedForRX2>1</UsedForRX2> <!-- RX2 Tx Channel flag -->
          <LC>128</LC>        <!-- RX2 Logical channel index -->
          <SB>3</SB> <!-- RX2 Tx channel subband -->
          <DTC>10.0</DTC> <!-- RX2 Tx Channel duty cycle -->
          <Frequency>922.8</Frequency>           <!-- RX2 Tx Channel frequency -->
          <MaxDR>3</MaxDR> <!-- RX2 Tx Channel data rate -->
    </TxChannel>

…
</TxChannels>

• To configure multiple pingslot channels (for class B), all pingslot channels are defined by setting <UsedForPingSlot> to 1 in <TxChannel> sections. The following example configures two pingslots at frequencies 923.2 and 923.4MHz:
  

<TxChannels>
      <TxChannel>
          <UsedForPingSlot>1</UsedForPingSlot>         <!-- Ping Slot Tx Channel flag -->
          <LC>129</LC>  <!-- Ping Slot Logical channel index -->
          <SB>3</SB> <!-- Ping Slot Tx channel subband -->
          <DTC>10.0</DTC> <!-- Ping Slot Tx Channel duty cycle -->
          <Frequency>923.2</Frequency>         <!-- Ping Slot Tx Channel frequency -->
          <MaxDR>5</MaxDR>         <!-- Ping Slot Tx Channel data rate -->
      </TxChannel>

      <TxChannel>
          <UsedForPingSlot>1</UsedForPingSlot>         <!-- Ping Slot Tx Channel flag -->
          <LC>130</LC>  <!-- Ping Slot Logical channel index -->
          <SB>3</SB>   <!-- Ping Slot Tx channel subband -->
          <DTC>10.0</DTC>   <!-- Ping Slot Tx Channel duty cycle -->
          <Frequency>923.4</Frequency>         <!-- Ping Slot Tx Channel frequency -->
          <MaxDR>4</MaxDR>           <!-- Ping Slot Tx Channel data rate -->
      </TxChannel>

…
</TxChannels>

NOTE: To maintain backward compatibility with RF Regions created in previous releases, the RX2 parameters for mono-RX2 configurations remain read from the attributes RX2DataRate, RX2TxPower, RX2Freq, RX2DTC, and RX2SB.

However, these attributes are not read if one (or more) Tx channel is configured with the flag <UsedForRX2> set to 1 in the RF Region. Hence, Actility does not recommend setting  <UsedForRX2>  flag in RF Regions having mono-RX2 configurations.

NOTE: To support this feature, the minimum LRR version is 2.4.12.

Feature Limitations

• Multi-pingslot configuration is not compatible with pingslot frequency hopping (for US915, AU915 and CN470 ISM bands). Indeed, defining several pingslots becomes meaningless in presence of pingslot frequency hopping. Hence, it is not allowed to define pingslot Frequency = 0 (i.e. frequency hopping) in a multi-pingslot RF Region.
  

• When using multi-RX2/pingslot configuration, the multicast frequency and data rate MUST be configured at Multicast Group level.
  

• Join Accept messages sent on RX2 are still reported with LC255 in the current release (not the real LC); this limitation will be lifted in release 7.0.
  

RDTP-3466: [ADRv3]: Define distinct Initial_WindowSize parameters

Feature Description

To avoid volatile decisions, ADRv3 waits for (at least) N frames before sending an ADR decision (i.e. a LinkADRReq) to an end-user. This convergence phase allows the algorithm to receive enough uplink frames to take the right decisions and fulfill the target quality metrics: the uplink packet error rate and macro diversity overlapping for geolocated devices.

The ADRv3 convergence phase applies to the following cases:

• When the end-device boots/reboots (for instance a Join Request for OTA device or a reset detection for ABP device).
  

• Once the end-device acknowledges an ADR command (i.e. sending a LinkADRAns command in response to a LinkADRReq command from the LRC).
  

Prior to release 6.0: N is defined by the RF Region parameter “Initial_WindowSize”. The same parameter is used for all the convergence cases: device boot or between 2 ADR commands.

Starting release 6.0: To enhance configuration flexibility, the original “Initial_WindowSize” parameter is split into 3 parameters:

• Initial_WindowSize_Boot (new RF Region parameter): this parameter defines how many distinct uplink frames should be received by ADRv3 before sending its first ADR command when the device boots/reboots.
  

• Initial_WindowSize (existing parameter from previous releases): Once the device responds to an ADR command (i.e. sending a LinkADRAns MAC command), this parameter defines how many distinct uplink frames should be received by ADRv3 before sending a new ADR command (LinkADRReq) to boost the end-device link budget in case the quality targets are not met (bad uplink PER or insufficient macro diversity/coverage overlap).
  

• Initial_WindowSize_Optim (new RF Region parameter): Once the device responds to an ADR command (i.e. sending a LinkADRAns MAC command), this parameter defines how many distinct uplink frames should be received by ADRv3 before sending a new ADR command (LinkADRReq) to optimize the end-device battery power when all the quality targets are satisfied (good uplink PER and sufficient macro diversity/coverage overlap).
  

Actility recommendation:

Initial_WindowSize_Optim > Initial_WindowSize > Initial_WindowSize_Boot.

This rule allows:

• Faster convergence to higher data rates when the device boots/reboots: In most cases, end-devices choose the lowest data rate (and highest Tx Power) during initial network access. Reducing the window size during boot phase offers more reactivity of the algorithm.
  

• High stability (less volatility) when optimizing the device’s battery consumption (airtime and Tx Power): To minimize the risk of ping-pong decisions while maintaining reactivity to any degradation of the uplink reception conditions, ADR decisions that are driven by boosting link budget should be triggered faster than ADR decisions driven by optimizing the device’s battery.
  

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

Key Customer Benefits

Thanks to this feature, the Operator have a better control on the level of reactivity vs. stability of the ADRv3 decisions. It offers finer tuning granularity of ADRv3 parameters to maximize reactivity to degrading radio conditions without jeopardizing the stability of the algorithm; i.e. speeding-up rescue decisions and slowing-down battery/airtime optimization decisions.

Feature Activation

This feature is activated by explicitly configuring Initial_WindowSize_Boot and/or Initial_WindowSize_Optim parameters in the RF Region configuration.

The feature can be deactivated at any time by simply removing Initial_WindowSize_Boot and Initial_WindowSize_Optim from the RF Region (or by setting them equal to Initial_WindowSize). In this case, the same window size is applied to all the stages of the ADRv3 algorithm.

Feature Limitations

Not applicable.

Feature Interaction Matrix

Operational Excellence Features

Support NetID migration procedure (RDTP-5320)

Feature Description

This feature allows ThingPark Operators to upgrade their NetID without running manual scripts.

where M and N depend on the NetID type. For more information about the different NetID types, DevAddr structure and NwkID/NetID mapping, please refer to [2].

Accordingly, the NetID migration has an impact on the DevAddr: changing the NetID requires re-allocating the DevAddr so that NwkID matches the new NetID. This is important to support roaming since the NwkID part of the DevAddr allows the visiting network to derive the home NetID of the device.

However, since DevAddr is only allocated during the Join procedure for OTAA devices, there is a transition period between updating the NetID on ThingPark backend and updating the DevAddr of all active devices in the field. The completion of this transition period depends on when active devices will trigger an new Join procedure: this cannot be controlled by the network for LoRaWAN 1.0.x devices, so it is device implementation-dependent and whether some applicative commands are supported by the device to trigger an new Join procedure).

NOTE: Traffic segregation between Operators sharing the same LRC considers the new NetID even if some devices have not yet updated their DevAddr to the new NwkID/NetID.

To update NetID, please refer to the procedure described in the “Feature Activation” section.

Key Customer Benefits

This feature allows ThingPark Wireless Operators to safely migrate from one NetID to another which is needed in the following use cases:

• An Operator upgrades its LoRaWAN membership status from adopter (NetID type 6) to contributor (NetID type 3) to grow its LoRaWAN business and support larger DevAddr range.
  

• An Operator moves from experimental NetID 0 or 1 to their own NetID.
  

• An Operator moves from Actility’s NetID to their own NetID.
  

Feature Activation

This feature is deactivated by default.

To activate it, the TPW administrator needs to perform the following tasks:

1. Update the Operator’s NetID on TWA SQL database via the following TWA webservice:
   

          U         /systems/updates/operator/netID?operatorID=<operatorID>&netID=<netID> .
   

2. A new Table O entry is created for the new NetID.
   

3. 
   

   Launch a full re-provisioning command to trigger TWA provisioning of the new NetID on the LRC databases. To execute this command, the following webservice shall be used: /systems/lrcFullProvisionningRequests. This API should be called twice to allow reprovisionning of devices and base stations. 
   
   NOTE: During the full provisioning, LRC provisioning queue is stopped.
   

   
   

4. The previous Table O entry (previous NetID) is deleted.
   

• ABP devices are out-of-scope of the NetID migration procedure since their DevAddr is personalized out-of-band (cannot be updated in-band via LoRaWAN MAC layer). Hence, if the DevAddr of these devices does not match the new operator NetID, they may not be able to roam-out to partner networks.
  

• OTAA devices with manual DevAddr allocation are out-of-scope of this feature: the DevAddr is not impacted by NetID migration. Hence, if the DevAddr of these devices does not match the new operator NetID, they may not be able to roam-out to partner networks.
  

• For OTA devices with automatic DevAddr allocation, the new DevAddr (matching the new NetID) is only assigned when the device sends a new Join Request. Therefore, active devices will continue to use the old DevAddr (with the old NwkID/NetID) until they request a new LoRaWAN session via Join Request. 
  

• Only one NetID is supported per Operator in the current release.
  

RDTP-6614: Improved High Availability of LRC-queued downlink frames

Feature Description

For class A devices, the LRC queues up to 5 downlink frames for each device; waiting to send them as soon as a downlink scheduling opportunity is available in class A mode (i.e. when the device sends an uplink frame, thus opening RX1/RX2 reception windows to receive potential downlink frames).

Prior to release 6.0: The downlink frames queued by the LRC cluster are kept in RAM. This approach had two side-effects:

• Queued frames are lost in case of LRC restart.
  

• Queued frames are not synchronized between both LRCs of the LRC-cluster (i.e. LRC1/LRC2). Hence, in case of traffic switchover to LRC2, these queued frames at LRC1 cannot be processed by LRC2.
  

Starting release 6.0: Downlink frames queued by any LRC are stored on disk (in the device context, also known as LRC table-B) and synchronized with peer-LRC.

Key Customer Benefits

Thanks to this feature, downlink transmission is not jeopardized by LRC restart/switchover; leveraging ThingPark High Availability architecture to prevent downlink packet loss in such conditions.

Feature Activation

This feature is activated by default, it can be deactivated in lrc.ini via the parameter:

[features] FifoDnTabB (1 to activate, 0 to deactivate).

Feature Limitations

In case of backhaul instability, yielding the same uplink frame being received by 2 base stations connected to different LRCs (i.e. LRR1 connected to LRC1, LRR2 connected to LRC2), the downlink frame coming from AS might be sent twice to the device.

This limitation will be lifted in future releases via RDTP-11708.

Feature Interaction Matrix

RDTP-9070: Operator Dashboard support for SaaS operators sharing the same NetID

Feature Description

The ThingPark Operator Dashboard provides TPW Operators with an efficient tool to assess the Key Performance Indicators (KPI) aggregated at network level. This functionality is particularly interesting for performance monitoring and reporting.

Prior to release 6.0: The Operator Dashboard only supported for TPW Operators having their own dedicated NetID. Hence, TPW-SaaS Operators sharing Actility’s NetID (or using experimental NetID 0 or 1) cannot benefit from the Operator Dashboards.

Reason: Without this feature, the LRC deduces the Operator identity from their NetID.

Starting release 6.0: The Operator Dashboard is fully supported by SaaS Operators using a shared/experimental NetID. With this feature, the LRC does not rely on the NetID to derive the Operator identity: the Operator-ID is directly provisioned on the LRC by TWA backend.

For more details on the ThingPark Operator Dashboard, please refer to [7].

Key Customer Benefits

Thanks to this feature, Operator Dashboard becomes fully available for TPW SaaS operators that do not use a dedicated NetID (i.e. either sharing Actility’s NetID or using experimental NetID 0/1).

Feature Activation

This feature is automatically activated on TPW SaaS platforms after the migration to release 6.0: During the upgrade procedure, Actility NetOps perform full re-provisioning of devices and base stations by TWA into the LRC in order to provision the OperatorID on the LRC databases.

Feature Limitations

Since this feature requires full reprovisionning of devices and base stations by TWA into the LRC, the Operator KPIs will be aggregated only after this action. Hence, for SaaS Operators sharing the same NetID, their KPI history before release 6.0 cannot be displayed on the Dashboard.

Feature Interaction Matrix

RDTP-8095: LRC Record/Replay tools

Feature Description

The scope of this functionality is to enrich the LRC non-regression test suite by defining a set of record/replay tools allowing Actility Operations department as well as ThingPark Wireless Operators to record live traffic for a limited number of devices during a few hours from the LRC.

Typically, recording of reference scenarii shall be performed on Production or Pre-Production platforms (TPW version n), whereas the replay of these reference scenarii shall be performed by Actility R&D teams on validation platforms for TPW versions n+1, n+2…etc.

The target is to verify that the device’s behavior (MAC layer, ADR commands, uplink routing towards AS/TWA, downlink processing and routing to the best-LRR…etc.) does not show any regression from one TPW release to another.

To manage this recording on Production/Preproduction platforms, the following functions are packaged in a script delivered on the LRC since release 6.0:

• BACKUP: Backup the reference configuration of the scenario, for the device being recorded (device’s initial context, LRC tables, RF Region…etc.).
  

• RECORD-IN: Record the reference INPUT traffic for the device being recorded (i.e. traffic coming from LRRs via IEC-104 backhaul interface, downlink frames coming from AS).
  

• RECORD-OUT: Record the reference OUTPUT message flows related to the device being recorded (i.e. downlink frames sent to LRRs for this device, messages forwarded to AS/TWA for this device).
  

The output of the recording is packaged into a single archive containing backup, traffic-in and traffic-out data. The following diagram illustrates the recording mechanism:

NOTE: The recording tool exports the device keys in encrypted format  (encrypted by the LRC Cluster Key, in the same way they are locally stored in the LRC). LRC Cluster Key is used to encrypt the device’s root AppKey and session keys (NwkSKey, AppSKey).

This approach is implemented to ensure confidentiality of customer’s keys by:

• Never exporting the LRC Cluster Key in any archive generated by the LRC.
  

• Never storing the device’s keys in clear format in any Actility database.
  

Since it is not possible to record traffic for all devices, the Operator should focus on few device models (less than 10) that are the most represented in their network.

NOTE: Any scenario recorded by TPW Operators should be first validated by Actility before it is added to the reference tests’ library.

Recording pre-requisites:

• The recorded device should not be activated on external JS, nor should it use HSM mode (see “Feature Limitations” section)
  

• The lrc.ini parameter “JoinNonceType” should be set to 1 during recording. This requirement is important to allow replaying of a reference scenarii where an OTA device has issued a new Join Request (to avoid randomly allocated AppNonce/JoinNonce values in the Join Accept).
  

Please refer to the “Feature Limitations” section for a detailed description of the exclusions not supported in the current release.

Key Customer Benefits

Indeed, thanks to record/replay mechanisms, the real radio conditions of devices shall be covered in Actility’s non-regression test suite; this will also be the case for devices implementing a specific MAC behavior due to any potential grey areas in LoRaWAN specifications.

Feature Activation

This feature is deactivated by default.

NOTE: This feature also allows setting the trace level (globally or for a given thread) via command line interface (CLI).

For example, to investigate a specific beacon issue, the LRC administrator can increase the trace level of the lrc-lrr-beacon thread using the command:

       thtrace lrc-lrr-beacon 5.

To apply the same level for all threads, use thtrace * 0.

• Prefixing of trace lines: A prefix is added between () in each line to indicate the corresponding LRC thread type (instead of the thread ID in previous releases) so that it becomes easier to track the logs related to a given feature/behavior.
  

Example:

16:05:49.400 (lrc-lora) [ADRv3.c:784] Distinct_Pkts_CNT=2 PER_LT=-1.000000  PER_ST=-1.000000
16:05:49.400 (lrc-lora) [ADRv3.c:827] ComputeOverlap_v12
16:05:49.400 (lrc-lora) [ADRv3.c:1830] instantPERoneLRR lrrid=290000fc  expected=2 cnt=1 instantPER=0.50

This feature offers the following benefits to Operators having direct access to the LRC:

• More comprehensive classification of the different trace levels, as well as high flexibility to configure trace levels differently for each LRC thread (e.g. to analyze specific problems).
  

• Better readability of the trace lines to simplify analysis/debug.
  

• Overall reduction of the troubleshooting effort/time.
  

Feature Activation

Not applicable.

Feature Limitations

The following points are out-of-scope of this feature:

• Transfer of LRC logs to external servers.
  

• Support of Syslog client on the LRC to enhance the management of internal logging, rotation and file cleanup.
  

Device alarm enhancement (RDTP-7010 and RDTP-7011)

Feature Description

The scope of this feature is to enhance the generation of some alarms related to adversary attacks:

• [RDTP-7010]: Add AppEUI/JoinEUI to “Wrong MIC detected in Join request” - Device alarm # 008 and Base Station alarm # 114.
  

  • Prior to release 6.0: The alarm “Wrong MIC detected in Join request” generated at device level (alarm # 008) and Base Station level (alarm #114) only indicates the DevEUI but does not indicate the AppEUI/JoinEUI.
    

  • Starting release 6.0: When this alarm is raised, the AppEUI/JoinEUI included in the fake Join Request message is reported to the device and Base Station administrators.
    

Reminder: The alarm “Wrong MIC detected in Join request” is raised when ThingPark receives a Join Request from a device but cannot authenticate this request due to wrong Message Integrity Code (MIC). This could be either due to an adversary attack or a wrongly provisioned AppKey.

• [RDTP-7011]: Generate “Wrong MIC detected in Uplink frame” alarm at device level.
  

  • Prior to release 6.0: The alarm “Wrong MIC detected in Uplink frame” is only generated at Base Station level (alarm # 117) because of potential ambiguity related to the mapping between a DevAddr and the corresponding DevEUI.
    

  • Starting release 6.0: The alarm “Wrong MIC detected in Uplink frame” is generated at device level (new alarm # 016) besides the BS alarm # To mitigate the DevAddr ambiguity issue, ThingPark implements the following logic:
    

    • If the DevAddr matches only one DevEUI provisioned under the Operator scope, the device alarm # 016 shall be raised on this DevEUI with default severity = major.
      

    • If the DevAddr matches more than one DevEUI provisioned under the Operator scope, the device alarm # 016 shall be raised on all those DevEUI with default severity = indeterminate (due to DevAddr collision/ambiguity).
      

Reminder: DevAddr collision is authorized in LoRaWAN, several devices can be associated with the same DevAddr but the DevAddr/NwkSKey pair must be unique within the network. When the LRC cannot authenticate the uplink frame due to wrong MIC, it becomes impossible for the LRC to precisely reveal the device identify in case of DevAddr collision.

Key Customer Benefits

This enhancement allows the subscriber to better monitoring the devices under their ownership, it also helps them troubleshoot adversary attacks targeting their devices.

Feature Activation

The above enhancement on alarms is activated by default, it cannot be deactivated.

Feature Limitations

Not applicable.

Feature Interaction Matrix

RDTP-2217: Subscriber KPI Dashboard

Feature Description

This feature provides ThingPark Wireless subscribers with a new application “Dashboard” showing them Key Performance Indicators (KPI) related to their devices.

Wireless Subscriber Dashboard application is integrated as a SMP application. It must be packaged in an offer to be sold to subscribers. A subscriber will have access to the Dashboard through the ThingPark User Portal, as per the following view:

An administrator (for instance, the Customer Support team with Operator access) can access the Dashboard application through SMP impersonate on a subscriber having an active subscription on Subscriber Dashboard.

The Dashboard consists of eight widgets, the default widget configuration is shown by the following figure – please note that each end-user of the Subscriber role can access a dedicated Dashboard so they can customize the widget organization/preferences on their own:

The following KPIs are supported by the Subscriber Dashboard:

Key Customer Benefits

Thanks to this feature, ThingPark Wireless Subscribers can easily:

• Monitor the health of their devices.
  

• Follow the evolution of their main KPIs over time.
  

• Identify devices having unacceptable performances (via the Top/Worst 10 statistics).
  

• Have a comprehensive view on the distribution of their devices according to many criteria (split by manufacturer, by device model…etc.)
  

This Dashboard also provides TPW Operators (e.g. technical support teams) with the necessary tools to proactively diagnose performance issues for their key Subscribers so they can take the appropriate corrective actions.

Feature Activation

This feature is deactivated by default. To activate it, the Operator/Vendor must add the “Subscriber Dashboard” application to vendor offers to be available for TPW Subscribers.

This feature has the following pre-requisites:

• TWA-Spark (based on Apache Spark) should be installed on the platform, this framework is required to perform KPI aggregation.
  

• DC/OS should be setup on the platform, please see Section 4.4.9 for more details.
  

NOTE: Actility does not recommend activating this feature to all Subscribers, it is recommended to limit its usage in the current release to 100 subscribers (maximum 500K devices) to minimize the risk of facing platform scalability issues.

Feature Limitations

This feature has the following limitations:

• Metrics are available in the Dashboard with a delay of:
  

  • 10 min for hourly device metrics.
    

  • 1h10min for device metrics aggregated on daily/weekly basis.
    

  • 1h10 min for hourly subscriber metrics.
    

  • 2h10min for subscriber metrics aggregated on daily/weekly basis.
    

• KPI labels are provided only in en-US language, there is no maintenance script nor WS to add translation in another language. New translations can only be added by inserting in database.
  

• KPI metadata are system-wide, so they cannot be customized per operator (for SaaS operators).
  

This feature introduces the use of Data Center Operational System (DC/OS) to host TWA Spark KPI applications, adding high availability and horizontal scaling to the KPI framework.

Spark application is required for KPI dashboards, it is supported in ThingPark Wireless since release 4.3 to introduce the Operator KPI Dashboard. In the next release, this framework will be also used to offer a KPI dashboard for subscriber role.

Prior to release 6.0 , the Spark server was installed on a single server. Thus, a system administrator had to intervene to deal with the issue. Nevertheless, no data got lost in the process.

Release 6.0 supports fault-tolerance towards a KPI-side failure with a help of DC/OS that keeps the system (and thus KPIs display) operational even in case of a dysfunction.

The level below DC/OS called Apache Mesos, is a “heart” of distributed systems, a basement on which other stack components run. It allows to abstract CPU, memory, storage in the Cloud, thus, being in charge of resources management and scheduling across entire cloud environments. It is widely applied by the businesses to build real-time systems.

The DC/OS can either be accessed via GUI (available from a master mode and providing a graphical view of a cluster) or CLI (command-line interface: a utility to manage cluster nodes, install and manage packages, inspect the cluster state, and manage services and tasks).

The two types of nodes form a DC/OS cluster:

• Master nodes: manage the rest of the cluster by collaborating with each other
  

• Agent nodes: nodes user tasks are run on 
  

As shown above, Master node manages Agent nodes as well as Executors and Schedulers which manage DC/OS tasks.

When running Apache Spark applications in charge of KPI generation, the following diagram is applied:

A Cluster Manager is used as a Mesos Master node, the Driver program represents a Mesos scheduler to dispatch Executor workloads on Agent Nodes (Mesos agents) according to resource offered by the Mesos Master node.

The Spark Driver itself run as a Mesos Task managed by Mesos’s Marathon component for streaming applications or by Mesos’s Metronome component for batch applications.

Key customer benefits

Thanks to DC/OS’s built-in high-availability and fault-tolerance, this feature allows hosted KPI applications to gain HA and horizontal scaling capabilities, thus, drastically diminishing the probability of system’s outage. The visible advantage of it is expressed through the absence of KPIs’ display holes in a customer-side GUI.

Feature Activation

The feature is activated by default.

Feature Limitations

Not applicable.

Feature Interaction Matrix

RDTP-4181: Add the monitoring of the AS server response (LRC part)

Feature Description

This feature introduces statistics on the health of the LRC-AS tunnel interface for HTTP Routing Profiles.

The following stats are aggregated by LRC every 5 minutes (default periodicity, configurable in lrc.ini) and reported for each HTTP type of Routing Profile:

The stats described above are produced by LRC as a JSON document “AS_statistic” in a specific Kafka topic “OSS.AS.V1”, this topic has 50 partitions (partition key = routing-profile-ID) .

“AS_statistic”:{

        “ID”:”UPHTTP_AS_WAIT_SEQ”,

        “Time”:”2018-09-25T19:28:45.000+02:00”,

        “Period”:15,

        “PeriodCount”:4,

        “LrcID”:”00000000”,

        “OpeID”:”ope_id”,

        “OwnerID”:”owner_id”,

        “Request”:2,

        “RequestOk”:0,

        “RequestError”:2,

        “OverloadDropped”:0,

        “BlackListDropped”:0,

        “OverloadDuration”:0.000000,

        “BlackListDuration”:0.000000,

        “Descs”:[ // This section is provided for each destination of the routing profile

                {

                        “Idx”:0,

                        “Desc”:” http://trash:5555/lora?p=X “,

                        “Request”:2,

                        “Blast”: 2

                },

                {

                        “Idx”:2,

                        “Desc”:” http://localhost:6666/lora?p=1 “,

                        “Request”:1,

                        "Ok”:1,

                        “Timeout”:0,

                        “Error”:0,

                        “AvgRT”:3,

                        “DevRT”:0,

                        “MaxRT”:3,

                        “MaxRTTime”:”2018-09-25T19:28:48.000+02:00”,

                        “AvgTT”:3,

                        “DevTT”:0,

                        “MaxTT”:3,

                        “MaxTTTime”:”2018-09-25T19:28:48.000+02:00”

                },

                {

                        “Idx”:4,

                        “Desc”:” http://localhost:6666/lora?p=2 “,

                        “Request”:1,

                        “Ok”:1,

                        “Timeout”:0,

                        “Error”:0,

                        “AvgRT”:9,

                        “DevRT”:0,

                        “MaxRT”:9,

                        “MaxRTTime”:”2018-09-25T19:28:47.000+02:00”,

                        “AvgTT”:9,

                        “DevTT”:0,

                        “MaxTT”:9,

                        “MaxTTTime”:”2018-09-25T19:28:47.000+02:00”

                },

                {

                        “Idx”:6,

                        “Desc”:” http://trash:5555/lora “,

                        “Request”:2,

                        “Ok”:0,

                        “Timeout”:2,

                        “Error”:0,

                        “AvgTT”:49,

                        “DevTT”:12,

                        “MaxTT”:62,

                        “MaxTTTime”:”2018-09-25T19:28:47.000+02:00”

                },

                {

                        “Idx”:7,

                        “Desc”:” http://localhost:5555/lora “,

                        “Request”:2,

                        “Ok”:0,

                        “Timeout”:2,

                        “Error”:0,

                        “AvgTT”:0,

                        “DevTT”:0,

                        “MaxTT”:0,

                        “MaxTTTime”:”2018-09-25T19:28:48.000+02:00”

                }

        ]

}

Additionally, an AS_event JSON document is created by the LRC every time the AS status changes, for instance the AS switches from one state to another:

• Nominal state (NominalReached): the Routing Profile is working properly, AS is responding in timely manner without overload/blacklist situation.
  

• Overloaded state (OverloadReached): the Routing Profile is overloaded, i.e. all the handlers are currently occupied and LRC starts dropping new outgoing HTTP Posts until the Routing Profile goes back to nominal state.
  

• Blacklisted state (BlacklistReached): When the overload state persists over time, the Routing Profile is eventually blacklisted, all outgoing HTTP posts are blocked during the blacklisting duration.
  

Example of the AS_event document:

{

        “AS_event”: {

                “ID”: “ROUTING1”,

                “Time”: “2014-04-01T14:19:56.38+02:00”,

                “LrcID”: “00000065”,

                “OpeID”: “actility-ope”,

                “OwnerID”: “199906950”,

                “Event”: “BlacklistReached”

        }

}

This feature provides ThingPark Wireless Operators with a comprehensive set of statistics to improve the debug/troubleshooting capability of the LRC-AS interface when some Application Servers show slow response to HTTP Posts from the LRC, yielding temporary packet drops due to blacklisting mechanism on LRC side.

Feature Activation

This feature is activated by default: after the upgrade to release 6.0, the LRC starts computing periodic statistics on each HTTP Routing Profile.

To deactivate this feature, the LRC administrator can set asstatperiod to 0 in custom lrc.ini.

The following parameters are configurable in lrc.ini related to this feature under [lrnoutput]:

• asstatperiod : Aggregation duration of each report in seconds, default 300 (0 to deactivate the feature).
  

• 
  

  aseventmask : Report state changes (Nominal, Overloaded, Blacklisted).
  
  Concerns only AS_event reports. 0: report only Blacklisted event (default) 1: report all state change events.
  

  
  

• askafkareport : Report stats per AS to KAFKA, 0 to deactivate, 1 to activate (default)
  

To retrieve these stats from the LRC, the following command line interface (CLI) shall be used:  xor <routing-profile-id>

Another way to retrieve these stats is to consume the Kafka topic OSS.AS.V1 on LRC-OSS interface.

Feature Limitations

• In the current release, the statistics introduced by this feature are produced by the LRC but not processed by TWA Device Manager / Subscriber KPI Dashboard applications.
  

• The statistics available at HTTP-destination level are aggregated separately by the LRC for each routing profile; hence, if the same HTTP destination is configured across different Routing Profiles, the related stats are not aggregated across all the corresponding Routing Profile. 
  

RDTP-2488: Read-only/viewer mode for all role types

Feature Description

This feature provides ThingPark Wireless administrators and end-users with enhanced access permission options.

Prior to release 6.0:

• Use-case #1: All end-users created under the Subscriber role have full read/write access to all the subscribed applications (Device Manager, Network Manager, Key Manager for JS).
  

• Use-case #2: ThingPark Wireless administrators (i.e. Operator administrators, Network Provider administrators, Connectivity Supplier administrators, Vendor administrator, Supplier administrators) have either full-administrator access or to specific security groups. However, there is no read-only mode to allow an administrator to access all the applications/tabs without write access.
  

• Use-case #3: A vendor administrator that is member of “Subscriber Managers” group cannot create subscribers, only full-administrators can do.
  

Starting release 6.0:

• Use-case #1: End-users can have one of the following permission profiles:
  

  • Full administrator with read/write access to all applications. This is the pre-release 6.0 mode; all the existing end-users are automatically migrated to this profile after TPW upgrade to release 6.0.
    

  • Read-only mode for all applications: in this mode, the end-user has access to all applications but cannot make any administrative action such as create/edit/delete/move/tag…etc. The related buttons are either hidden or greyed in the User Interface.
    

  • Hybrid profile: intermediate mode between the 2 profiles mentioned above, where the end-user can be granted write access to one of the available applications (e.g. Device Manager) but remains in read-only mode for other applications (e.g. Network Manager).
    

The following figure illustrates the different security groups available for a typical end-user subscribed to Device Manager and Network Manager applications:

NOTE: During the creation of a new application, a new field is supported to indicate whether it requires write access or not; as illustrated by the following figure:

• Use-case #2: Besides the existing security groups, a new group called “Viewers” is supported by this feature. Administrators assigned to this group have read-only access to all the applications/tabs available by the corresponding role. They can also impersonate underlying roles if applicable, but still in read-only mode.
  

To make it more comprehensive, the organization of the security groups has evolved in release 6.0 to support two modes:

• Basic mode: offering only two groups: Administrators (i.e. full-admin rights with read/write access to all applications/tabs) and Viewers (read-only profile, newly introduced by this feature).
  

• Advanced mode: while in basic mode, only Administrators and Viewers groups are proposed; in advanced mode, all groups are proposed.
  

NOTE: Custom profiles are also possible here, for instance, an Operator administrator may be member of “Viewers” + “Subscriber managers” groups; in which case he would have read-only mode to Operator Manager application but full read/write access to manage Subscribers.

• Use-case #3: Vendor administrators that are members of “Subscriber Managers” group can create subscribers even if they don’t have full-admin rights.
  

This feature enhances the permission management rules for all ThingPark Wireless roles. Read-only profile allows safer distribution of TPW accounts to end-user/administrator to ensure better control of administrative actions taken on the platform and allow a better segregation of the different profiles accessing its different applications.

The detailed benefits are explained above for each use-case described.

Feature Activation

This feature is available for all ThingPark wireless administrators/end-users once the platform is upgraded to release 6.0.

Permission profiles for existing end-users/administrators are not impacted by the upgrade to the new release. It is up to the Operator/Subscriber to switch relevant end-users to read-only mode (or viewers for administrators) at their own convenience.

Feature Limitations

Activation of the “write access supported” option for existing applications is not supported.

Feature Interaction Matrix

RDTP-5787: Improve WLogger display when DL frames are sent for repeated UL frames

Feature Description

When the same uplink frame is transmitted several times by the device (i.e. frame repetition), only one copy of this uplink frame is visible in WLogger and sent to AS thanks to the LRC deduplication mechanism. However, since each individual uplink transmission by the device allows two downlink scheduling slots (RX1 and RX2), the LRC may send downlink frames on RX1/RX2 slots of a repeated uplink frame.

Prior to release 6.0: When the situation described above occurs, the Wireless Logger user sees downlink frames without the corresponding uplink frames; which sounds wrong for a class A device.

Starting release 6.0: To avoid any ambiguity in Wireless Logger, a new display scheme is introduced in this situation to notify the user that the downlink frame in question is sent in response to an uplink frame that is masked by deduplication – see the following capture:

• A new icon is used to display the downlink frame: 
  

  
  

• In the expandable panel, the text “generated for a repeated UL” is added besides the LoRaWAN MType.
  

Key Customer Benefits

Thanks to this feature, the user experience is more consistent; avoiding any ambiguity in Wireless Logger display.

Feature Activation

This feature is activated by default, it cannot be deactivated.

Feature Limitations

Not applicable.

Feature Interaction Matrix

RDTP-2467: Spectrum Analysis parameters should be configurable in Network Manager

Feature Description

This feature improves the configuration of the RF spectrum scan utility to provide higher flexibility to Network Partners or Subscribers using Network Manager application.

Prior to release 6.0: The spectrum scan functionality supported by Network Manager does not allow configuring the start/stop frequencies nor the frequency step used during the measurement. All the configuration parameters of the RF spectrum scan utility are inherited from the ISM band configured on the LRR as per the following table:

Starting release 6.0: The Network Partner/Subscriber can customize the start/stop frequencies as well as the frequency step via Network Manager application.

From the Base station Administration panel, when the user launches a RF spectrum scan (by clicking the “Scan the radio” button, a new window is displayed to allow the user to customer the scan parameters: 

By default, if these parameters are not customized, the settings presented in the table above remain applicable.

Additionally, the user may use a different ISM Band than the one currently assigned to the Base Station (inherited from the RF Region configuration): this could be useful for Base Station hardware models that are compatible with several ISM Band (for instance, Asian gateways can scan both AS923 and Australian AU915 bands).

WARNING: Choosing frequency ranges that are not compatible with the Base Station hardware capabilities could yield  performance instabilities and shall result in RF scan failure.

Key Customer Benefits

This feature brings additional flexibility to Network Partners/Subscribers doing RF spectrum scan on their base stations using Network Manager application.

RF spectrum scan utility is very useful to assess the background interference/noise level perceived by the Base Stations and troubleshoot uplink radio performance issues. This utility is also crucial in the determination of the optimum RF channel plan for a given geographical region.

Feature Activation

This feature is automatically available when the platform is upgraded to release 6.0.

Feature Limitations

The maximum number of steps allowed for an RF spectrum scan is 200 steps (systemwide configuration).

Feature Interaction Matrix

RDTP-2277: Customization of alarm parameters at operator level

Feature Description

This feature allows ThingPark Wireless SaaS Operators to personalize alarm settings differently from the default systemwide configuration.

Prior to release 6.0: Alarm settings (i.e. severity levels and trigger thresholds) can be customized system-wide (i.e. same settings apply to all customers sharing a SaaS platform).

Starting release 6.0: Customization of alarm settings becomes per-operator, allowing Operators using ThingPark Wireless in SaaS model to personalize their alarm configuration independently. Additionally, alarm activation/deactivation can be also controlled by the Operator.

NOTE: The customization of alarm settings is not supported via APIs, it is performed by a TWA script run by ThingPark network administrators (Actility’s Network Operations team for SaaS platforms).

For more information about ThingPark Base Station and Device alarms, please refer to [8].

Key Customer Benefits

This feature is particularly useful for SaaS Operators, it provides them with full flexibility to customize the settings of Device/Base Station alarms according to their strategy.

For instance, an Operator may decide to deactivate an alarm that is not relevant for their deployment, whereas another Operator may decide to increase the trigger severity of some other alarms to improve its awareness of service-impacting problems.

Feature Activation

Feature Limitations

• The customization of alarm settings per operator is performed using a script run by the ThingPark network administrator (Actility’s Network Operations team for SaaS model). The integration of such customization in Operator Manager API and GUI is out-of-scope of this feature.
  

• The periods defining the minimum sustained duration to clear an active alarm remain configurable system-wide (not operator-wide). This limitation applies to the following alarm types:
  

  • Device alarms: 002, 003, 007, 008, 009, 010, 011, 013, 014, 015 and 016
    

  • Base Station alarms: 101, 113, 114, 115, 116, 117, 118, 119 and 120.
    

RDTP-2174: Global LRR configuration enhancements (NFR-920)

Feature Description

This feature brings the following enhancements to ThingPark Network Partners and Subscribers having access to Network Manager:

1/ Enhancement of the remote LRR configuration UI accessible via reverse-SSH on the Base Station (also known as SUPLOG):

• Without this feature: SUPLOG UI supports limited functionalities:
  

  • View logs
    

  • LRR configuration: Get the current radio configuration (number of antennas, ISM band, LBT configuration, TX Power look-up tables (LUT), physical channel configuration…etc.), get LRR-UUID, set Transmit Power and Power transmission adjustment (i.e. antenna gain and cable loss).
    

  • Network: View ethernet or cellular networks and DNS address.
    

  • PKI configuration (IPSec/TLS)
    

  • Troubleshooting: ping, view disk usage, view real time system metrics, view iptables, view software versions, view status of each network interface…etc.
    

Accordingly, it was not possible to change network/backhaul configurations via the Support account used on SUPLOG; this was only possible via root access to the base station, or by embedding all the required configuration settings in the BS image.

• With the new feature: the following actions are added besides existing ones:
  

  • Network configuration
    

    • Network interface configuration: For each interface, view/change:
      

      • Name (e.g. eth0) [VIEW only]
        

      • Type (Ethernet | Cellular | Wi-Fi) [VIEW only]
        

      • State (UP | DOWN) [VIEW only]
        

      • DHCP activation [CHANGE/VIEW]
        

      • DHCP lease obtained [VIEW] (only when DHCP is enabled)
        

      • DHCP lease expire [VIEW] (only when DHCP is enable)
        

      • VLAN [CHANGE/VIEW] (only valid when DHCP is disabled)
        

      • IP address [CHANGE/VIEW] (only valid when DHCP is disabled)
        

      • Netmask [CHANGE/VIEW] (only valid when DHCP is disabled)
        

      • Broadcast [CHANGE/VIEW] (only valid when DHCP is disabled)
        

      • Gateway [CHANGE/VIEW] (only valid when DHCP is disabled)
        

      • DNS servers [CHANGE/VIEW] (only valid when DHCP is disabled)
        

    • Cellular interface configuration:
      

      • APN auto-configuration [CHANGE/VIEW]: When activated, the BS is expected to retrieve the MCC (Mobile Country Code) and MNC (Mobile Network Code) from the SIM card, and map the MCC/MMC pair to the right APN  configuration based on a local mapping database included in the BS image.
        

      • APN [CHANGE/VIEW]
        

      • PIN [CHANGE/VIEW]
        

      • USER [CHANGE/VIEW]
        

      • PASSWORD [CHANGE/VIEW]
        

    • WiFi interface configuration:
      

      • SSID [CHANGE/VIEW]
        

      • SECURITY [CHANGE/VIEW]
        

      • KEY [CHANGE]
        

    • NTP configuration: view and add NTP servers (up to 3)
      

    • Time zone configuration
      

  • IP Failover configuration (also known as interface failover, this mechanism is used to switch to secondary network interface when the primary interface is down):
    

    • Activation [VIEW only]
      

    • Local SSH port [CHANGE/VIEW]
      

    • Network interface configuration:
      

      • Name [VIEW only]
        

      • Status (Primary | Secondary | Not Used) [CHANGE/VIEW] (to deactivate an interface, set it to “Not Used”).
        

      • Bandwidth constraint (Very Limited | Limited | No) [CHANGE/VIEW]
        

      • ICMP addresses to use to validate the state of the interface [VIEW only]
        

  • PKI configuration (IPSec/TLS):
    

    • Activation (start/stop) [CHANGE/VIEW]
      

    • Key installer Platform [CHANGE/VIEW]
      

    • Key installer instance [CHANGE/VIEW]
      

    • Key installer server [CHANGE/VIEW]
      

    • Cleanup certificates [ACTION]
      

  • Backhaul configuration:
    

    • LRC servers: List of IPv4 addresses or FQDN (up to 2) [CHANGE/VIEW]
      

    • FTP download servers: List of IPv4 addresses or FQDN (up to 2) [CHANGE/VIEW]
      

    • FTP upload servers: List of IPv4 addresses or FQDN (up to 2) [CHANGE/VIEW]
      

    • Reverse SSH servers: List of IPv4 addresses or FQDN (up to 2) [CHANGE/VIEW]
      

    • ICMP addressees (see RDTP-4176): List of IPv4 addresses to use to validate the state of the interface [VIEW only]
      

  • Enhanced troubleshooting options , for both network and IPSec/TLS.
    

2/ Enhanced mechanism to allow configuration changes:

• Without this feature: any configuration changes are directly committed on the Base Station.
  

• With this new feature: to ensure safer transition from existing to new configuration, a new mechanism is supported; it is based on apply/commit/rollback actions:
  

  • Apply : Applies all changes done in the network configuration menu. Because, with this action, modifications are not committed, the administrator should come back (for instance after the BS reboot) in SUPLOG to commit modifications, or rollback modifications.
    

  • Commit (available when the modification status is APPLIED): Commits all changes done in the network configuration menu.
    

  • Rollback (available when the modification status is APPLIED): Restore the backup configuration (that gets the COMMITTED status).
    

  • Cancel : Discard all the modification in progress.
    

The following diagram illustrates the different modification states and their transitions

This new mechanism avoiding losing the connection of a Base Station to ThingPark core network in case of configuration errors: if an applied configuration is not committed after a configurable delay (15 minutes by default), then the Base Station will automatically rollback to the last committed configuration.

3/ The backup/restore of Base Station configuration is enhanced by the new feature, covering backup of LRR software binaries and scripts + LRR configurations + some Linux configuration (such as NTP configuration, network interface configuration).

NOTE: The backup/restore functionality supported by this feature does not cover full system backup, it essentially covers the LRR package + configuration that allow recovering from a bugged LRR software version or a wrong configuration.

Additionally, the SUPLOG menu is reorganized to provide users with a more comprehensive UI.

Key Customer Benefits

As explained in the previous section, this feature also brings significant enrichment of the troubleshooting information provided to BS managers. It also provides a homogenous framework for Base Station backup/restore functionality, whatever the BS model.

Finally, this feature ensures safer configuration updates through the apply/commit/rollback mechanisms, minimizing the risk of losing access to the BS in case of misconfiguration.

Feature Activation

This feature is deactivated by default, it is activated via a specific flag in lrr.ini:

This feature is only supported from LRR version 2.4.92 onwards.

Feature Limitations

The implementation of this feature has the following limitations:

• The configuration of etc/host file and associated routes are only accessible in read-only mode from SUPLOG and LRR CLI interface.
  

• All logins and passwords (Prestager ID/password, Reverse SSH login/password, LRC FTP login/password, Support FTP login/password, and BS SSH login/password) are pre-defined in the BS image and cannot be updated via SUPLOG. Hence, these credentials remain defined per-operator (cannot be customized per base station).
  

• Since the backup/restore mechanisms evolved with this feature, old backup run before activating this feature cannot be used after activation. It is then recommended to run a new backup after activating this feature on the Base Station.
  

Comprehensive API-only mode for end-users and administrators (RDTP-10108 and RDTP-6589)

Feature Description

The scope of this enhancement is to provide a comprehensive view of API-only mode for both administrators and end-users.

• For Administrators: in release 6.0, API-only administrators can be recognized via “API only” flag in the Administrator details on SMP GUI. Additionally, the “Forgot password” option is removed for such administrators since they have permanent password. 
  
  NOTE: API-only administrators cannot access ThingPark UI, this behavior has not changed from previous releases.
  

• For End-users: An end-user can be created with a permanent password (that never expires) using SMP UI (not possible via User Portal UI). This functionality was already supported before release 6.0 but it was wrongly named “API-only”. Starting release 6.0, the related feature flag is renamed “Permanent password” in the UI.
  

End-users with permanent passwords can be easily recognized on SMP UI via the new flag “Permanent password” added in the end-user details in release 6.0.

NOTE: An end-user using permanent password can access User Portal UI, like classic end-users; this behavior has not changed from previous releases.

Key Customer Benefits

This feature allows easy recognition of end-users having permanent password or API-only administrators. It also offers a more comprehensive user experience by avoiding misleading naming for end-users.

Feature Activation

Not applicable.

Feature Limitations

Not applicable.

Feature Interaction Matrix

OAuth V2 for end-user roles: Step-1 (RDTP-2443) and Step-2 (RDTP-6887)

Feature Description

The scope of this development is to implement the first steps of an EPIC targeting the use of standard OAuth V2 / OpenID Connect authentication flows to authenticate end-users and applications in ThingPark.

• The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service.
  

• OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
  

The goal of these two steps is to migrate end-users from SMP to Keycloak and rely on Keycloak to authenticate end-users instead of SMP API.

No functional enhancement is introduced in release 6.0 (next steps are planned in TPW release 7.0). Nevertheless, the login UI on User-Portal is slightly modified with the Keycloak integration.

The end-user account activation window is also slightly modified: On first user connection, the user is asked to update his profile with following form:

Then, if user has not yet defined any password, the “update password” action will be presented with the following form.

For more details about end-user login changes in release 6.0, please refer to [3].

Key Customer Benefits

Steps #1 and #2 presented above are the preliminary steps of a full EPIC to integrate KeyCloak with ThingPark Wireless. This EPIC has the following objectives:

• Enhance security by using standardized authentication flow.
  

• Leverage Keycloak as an identity provider to enhance security by using a dedicated / well tested authentication solution.
  

• Simplify third-party application integration with ThingPark.
  

• Allow authentication delegation to external identity provider (Keycloak):
  

  • Unified authentication on different ThingPark platforms/solutions
    

  • Delegate authentication for an operator.
    

• True single sign-on (SSO).
  

Feature Activation

This feature is activated once the platform is upgraded to release 6.0.

Keycloak is deployed on a new Virtual Machine named AS_IDP in Orange zone. Keycloak High-Availability is based on a cluster composed of at least two nodes (nodes must be deployed in different failure zones).

Feature Limitations

• All the links included in the Account Activation / Password Reset emails sent by ThingPark before the upgrade to release 6.0 will expire after the upgrade. If the activation/reset has not be executed before the platform upgrade, the user will get an error and will need to re-initiate again the activation/reset request (same error as the one related to the link expiration).
  

• When the end-user or the administrator triggers a password reset action (i.e. “lost password” by the end-user or “reset password by administrator), the email sent is not customized for each operator (using SMP templates) – the same email content is used for all operators/platforms. To customize these elements, a Keycloak subtheme must be deployed per  operator.
  

Geolocation Features

RDTP-2200: Report GPS coordinates of the base station to LocSolver if antenna coordinates are not manually provisioned

Feature Description

The exact position of the base station / RF antennas is a crucial input to the network geolocation solver.

Prior to release 6.0: Only the antenna coordinates – manually provisioned by the Network Partner of the base station – are sent to the LocSolver and used in geolocation algorithms.

Hence, if antenna location is not manually provisioned, the geolocation service becomes unavailable.

Starting release 6.0: With RDTP-2200, the antenna location used by the LocSolver is retrieved as follows:

• If the antenna location is manually set by the Network Partner, it is directly used by the LocSolver. This rule assumes that the RF antenna location may be different from the base station location when RF antennas are spaced away from the BS/GPS antenna depending on the site installation setup (rooftop or tower-mounted).
  

• Else (if antenna location is not available), the LocSolver uses the base station location:
  

  • If the BS location is manually set (i.e. administrative location), then it is used by LocSolver for all the antennas of the base station.
    

  • Otherwise (BS location is set to Auto (GPS) mode), then the average/filtered location reported by the GPS receiver is used by LocSolver for all the antennas of the base station.
    

The precedence rules are summarized in the following table:

To leverage the GPS position reported by the base station, the LRR applies a filtering algorithm to exclude bad GPS fixes and minimize swings.

The algorithm is designed to address the following requirements:

• Minimize fluctuations between GPS positions returned by the GPS receiver (either during GPS power-up phase, GPS recovery following an outage, fluctuating GPS signal…etc.) provide stable GPS position to LRC/LocSolver.
  

• Minimize impact on base station CPU load.
  

• Minimize LRR-LRC backhaul overhead due to reporting of BS position.
  

Thanks to this feature, network geolocation becomes possible even when the Operator/Network Partner does not manually provision the antenna position of their base stations.

Hence, this feature offers enhanced operability to ThingPark Wireless Operators, it also enhances the geolocation service availability.

Feature Activation

[gpsposition]

Feature Limitations

If the base station coordinates reported by the GPS receiver are too different from the antenna coordinates manually provisioned by the Network Partner, the latter coordinates are still used by the LocSolver without triggering a backend alarm to notify the Network Partner of potential provisioning error of the antenna coordinates.

Feature Interaction Matrix

List of User Stories included but not validated

Not applicable.

Issues Resolved for Customer Project/Customer Support

This section lists customers issues that are resolved in ThingPark 6.0: