Scope

The scope of this document is to describe the release notes of the ThingPark Wireless Product Software v5.1.

• Version 5.1 subcomponents versioning
  
• Version 5.1 list of new introduced features (User Stories) and release notes for all ThingPark software components
  
• Issues Resolved for Customer Project/Customer Support
  

Versions

Reference Documents

Acronyms and Definitions

ThingPark Solution Overview

The ThingPark set consists of four main key components:

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

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

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

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

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

Figure 1 - ThingPark Solution Architecture Description High Level Product Illustration Note that the modules above may be representing a physical server, a function, a service or a business support layer as part of the overall ThingPark solution and not necessarily a physical HW server.

Subcomponents Versioning

ThingPark OS

Sub component versioning:

ThingPark Wireless

Sub component versioning:

ThingPark System

Sub component versioning:

Version 5.1 Newly Introduced Features (User Stories)

LoRaWAN Standard Alignment Features

LoRaWAN 1.1 MAC layer protocol

Feature Description

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

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

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

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

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

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

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

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

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

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

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

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

LoRaWAN1.1 introduces 3 modifications to uplink ADR:

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

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

Key Customer Benefits

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

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

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

Feature Activation  

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

Feature Limitations

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

• For OTAA devices:
  
  • REJOIN procedures are not supported.
    
  • Only CFListType 0 is supported in release 5.1. Hence, CFList is only used for eu868, as923, kr920, in865, eu433, cn779 (not used for us915, au915, cn470).
    
    
    
• For ABP devices: The ResetInd/ResetConf MAC commands are not supported.
  
• For Class C devices: DevModeInd/DevModeConf MAC commands are not supported.
  
• The ADRParamSetupReq/Ans MAC commands are not yet supported in release 5.1.
  

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

Feature Description

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

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

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

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

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

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

Example for sNS configuration:
<ForeignOperator>

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

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

    <RoutingProfileJS>js-ope1</RoutingProfileJS>

</ForeignOperator>

NOTE: Used to route JoinReq.

 <TrustedOperator>

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

 </TrustedOperator>

NOTE: Used to authorize JoinAns.

Example for JS configuration:

<ForeignOperator>

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

<RoutingProfileSNS>sns-ope1</RoutingProfileSNS>

</ForeignOperator>

NOTE: Used to route JoinAns.

 <TrustedOperator>

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

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

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

 </TrustedOperator>

NOTE: Used to authorize JoinReq.

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

NS                                                JS

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

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

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

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

Key Customer Benefits

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

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

Feature Activation

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

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

Feature Limitations

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

Roaming Features

IMPORTANT NOTE:

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

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

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

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

Example of RoamingOperator table structure:

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

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

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

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

   <NwkID>000a</NwkID>

   <AppEUI>a34a34a341234567</AppEUI>

   <RoutingProfileSNS>NetID_SNS_00000a</RoutingProfileSNS>

   <RoutingProfileFNS>NetID_FNS_00000a</RoutingProfileFNS>

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

</RoamingOperator>

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

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

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

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

Example of TrustedOperator table structure:

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

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

   <SenderID>00000a</SenderID>

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

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

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

</TrustedOperator>

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

NOTE

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

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

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

RDTP-4575: Support of HomeNsReq/HomeNsAns

Feature Description

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

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

cat App_a34a34a341234567

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

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

   <NetID>00000a</NetID>

   <NwkID>000a</NwkID>

   <AppEUI>a34a34a341234567</AppEUI>

   <RoutingProfileSNS>NetID_SNS_00000a</RoutingProfileSNS>

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

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

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

</RoamingOperator>

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

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

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

cat Net_000002-App_a34a34a341234567 // fNS NetID = 000002

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

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

   <ReceiverID>a34a34a341234567</ReceiverID>

   <AppEUI>a34a34a341234567</AppEUI>

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

</RoamingOperator>

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

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

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

Key Customer Benefits

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

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

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

Feature Activation

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

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

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

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

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

   <ReceiverID>a34a34a341234567</ReceiverID>

   <AppEUI>a34a34a341234567</AppEUI>

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

</RoamingOperator>

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

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

cat js-ope1

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

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

   <ID>js_ope1</ID>

   <Descs>

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

   </Descs>

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

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

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

</RoutingProfile>

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

Example of TrustedOperator table structure:

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

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

   <SenderID>a34a34a341234567</SenderID>

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

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

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

</TrustedOperator>

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

JS configuration:

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

<RoamingOperator>

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

    <RoutingProfileFNS>fns-ope2</RoutingProfileFNS>

</RoamingOperator>

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

 <TrustedOperator>

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

 </TrustedOperator>

Feature Limitations

Not applicable.

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

Feature Description

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

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

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

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

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

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

   <AppEUI>APP_DEFAULT</AppEUI>

                                                                                                                                                // ReceiverID is not set

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

</RoamingOperator>

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

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

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

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

   <AppEUI>a34a34a341234999</AppEUI>

</RoamingOperator>

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

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

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

   <SenderID>APP_DEFAULT</SenderID>

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

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

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

</TrustedOperator>

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

Key Customer Benefits

This feature simplifies the roaming configuration between fNS and JSaaS.

Feature Activation

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

Feature Limitations

Not applicable.

Scalability Features

RDTP-2745: LRC multi-threading and performance improvement

Feature Description

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

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