TP Wireless 6.1 Radio Parameters User Guide Rev2

Actility ThingPark
ThingPark Wireless
Radio Parameters User Guide
Under NDA
Notice
This document contains proprietary and confidential material of ACTILITY SA. This document
is provided under and governed by either a license or confidentiality agreement. Any
unauthorized reproduction, use, or disclosure of this material, or any part thereof, is strictly
prohibited.
The material provided in this document is believed to be accurate and reliable. However, no
responsibility is assumed by Actility SA for the use of this material. Actility SA reserves the
right to make changes to the material at any time and without notice. This document is
intended for information and operational purposes only. No part of this document shall
constitute any contractual commitment by Actility SA.
© 2020 ACTILITY SA. All rights reserved.
Portions of this documentation and of the software herein described are used by permission
of their copyright owners.
Actility, ThingPark, are registered trademarks of Actility SA or its subsidiaries may also be
registered in other countries.
Other denoted product names of Actility SA or other companies may be trademarks or
registered trademarks of Actility SA or its subsidiaries, or their respective owners.
Headquarters
Actility Lannion,
Actility S.A 4 rue Ampère BP 30225
22300 Lannion France
www.actility.com
Under Non-Disclosure Agreement

Actility S.A. au capital de 1 122 916 € - 4 rue Ampère, 22300 Lannion, France
RCS St Brieuc 522 305 473, Siret 522 305 473 00012, TVA FR62522305473
TP_Wireless_6.1_Radio_Parameters_User_Guide - 2
VERSIONS
Version Date Author Details

Actility Document creation
1.0 11/03/16
(R.SOSS)
Actility Update of ADR algorithm to account for
1.1 14/06/16
(R.SOSS) NFR279 in R3.0.2.2
Actility Doc update to account for FIX3447 in R3.0.2.4
1.2 15/07/16
(R.SOSS)
Updates to align to R3.2 implementation of
Actility
1.3 19/07/16 NFR 279 (addition of Device Profile and
(R.SOSS)
Connectivity Plan parameters)
Actility Updates to align to TPW release 3.2.3,
2.0 02/12/16
(R.SOSS) especially introduction of ADR V3
- Introduction of rfregtool and the new RF
Region-to-LRR association mechanism in TPW
Actility release 4.0
3.0 20/01/17
(R.SOSS)
- Introduction of Antenna Diversity
- Editorial changes
- Update for ThingPark 4.0.1 and 4.1.2, with
the introduction of the following NFRs: 703,
Actility 749, 596/743, 598, 792, 635 and 883
3.1 20/06/17
(R.SOSS) - [ADR V2]: Correction of a typing error for
“number of transmissions offset” and “margin
offset”
Actility Update for ThingPark 4.2 and 4.3, with the

4.0 12/02/2018 (R.SOSS, introduction of the following NFRs: 721, 880,
A.YVERNEAU) 921, 947, 766, 730 and 731.
Update for ThingPark 5.0.1 with the
Actility
5.0_rev1 04/04/2018 introduction of the following NFRs: 924, 928,
(R.SOSS)
187 and 1036.
Update for ThingPark Wireless 5.1 with the
Actility introduction of the following features: RDTP-
5.1_rev1 17/07/2018
(R.SOSS) 3365, RDTP-2213, RDTP-2924, RDTP-4623 and
RDTP-2238.

Version Date Author Details
Actility Minor update to screenshots in section 4.1.
5.1_rev2 07/09/2018
(R.SOSS)
Correction of the precedence rule in section
Actility
5.1_rev3 07/09/2018 5.2: Connectivity Plan takes the precedence
(R.SOSS)
over Device Profile.
- Minor update (Figure-29)
Actility
5.1_rev4 03/10/2018 - Update the LoRaWAN™ version field in
(R.SOSS)
Device Profile (section 5.1)
5.1_rev5 19/11/2018 Actility Syntax update of all the RF Region attributes

(A.YVERNEAU)
Update for ThingPark Wireless 5.2.2 with the
introduction of the following features: RDTP-
4265, RDTP-2215, RDTP-5105, RDTP-4587,
5.2.2_rev1 22/03/2019 Actility
(A.YVERNEAU) RD-76.
Description of NFR-928 algorithm, introduced
since TPW5.0.1.
6.0_rev1 18/07/2019 Actility introduction of the following features: RDTP-
(R.SOSS) 8570, RDTP-3466 and RDTP-2543.
introduction of RDTP-11576 and RDTP-8676.
Corrected Target_PER and Macro_Div_Reliab
ranges (section 4.3.4).
6.1_rev1 2020/05/13 Actility Update RX2 Optimization algorithm to

(R.SOSS) account for LRR-LRC backhaul latency (RDTP-
9891).
Update RF Region profiles included in Actility
catalogue to match v1.1.0 of the catalogue
(section 4.1.2).
Section 4.3: update the example as per the
latest RF region templates in the catalog.
6.1_rev2 2020/09/02 Actility Section 4.3.13: update the recommended
(R.SOSS)
value of RedundancyDeduplicationTimer to
3600s.

REFERENCE DOCUMENTS
Documents Author
01 LoRaWAN™ specifications v1.0.2 LoRa Alliance
02 LoRaWAN™ Regional Parameters v1.0.2revA/revB LoRa Alliance
03 ThingPark LRC Administration User Guide Actility
04 CEPT ERC Recommendation 70-03, October 2017 Electronic
Communication
Community (ECC)
05 ThingPark Wireless Air Interface Dimensioning tool Actility
06 ThingPark Wireless Spectrum Analysis User Guide Actility
07 ThingPark RF Channel Selection Guidelines Actility
08 DataBlock Multicasting Protocol LoRa Alliance
09 ThingPark_ADRv2_vs_ADRv3_Comparison_Tests_Report Actility
WHAT’S NEW
New/Enhanced Functionalities For More Information, See… Release

ADR V3 enhancement: RDTP-11576 (adapt
overlap condition depending on the availability 3.1.3 ADR V3 Algorithm 6.1
of LRR fine timestamps)
ADR V3 enforcement for new Connectivity Plans 3.1.5 ADR-Related Parameters in

6.1
(RDTP-8676) the Connectivity Plan
Replay attack mitigation for devices with 3.5 Replay Attack Mitigation (NFR-
6.1
disabled ADR (RDTP-14460) 730/NFR-731)
Multicast enhancement: RDTP-8570

3.7 Multicast for Class B & C Devices
(Optimization of LRC retry mechanism for 6.0
(NFR-187/NFR-1036)
unavailable LRRs)
ADRv3 enhancement: RDTP-3466 (Define 3.1.3 ADR V3 Algorithm

6.0
distinct Initial_WindowSize parameters) 4.3.4 ADR Parameter Settings

3.7 Multicast for Class B & C Devices
(NFR-187/NFR-1036)
Downlink capacity enhancement for class B/C
4.3 Main RF Region Parameters
devices: RDTP-2543 (support multi-RX2/pingslot 6.0
4.3.2 RX1/RX2 Parameter Settings
channels per RFRegion)
4.3.8 “TX Channel” Parameter
Settings

TABLE OF CONTENTS
VERSIONS.......................................................................................................... 3
REFERENCE DOCUMENTS ....................................................................................... 5
WHAT’S NEW .................................................................................................... 5
TABLE OF CONTENTS ............................................................................................ 7
ACRONYMS AND DEFINITIONS ................................................................................ 9
1 SCOPE.......................................................................................................11
2 THINGPARK SOLUTION OVERVIEW ...................................................................12
3 MAIN THINGPARK RADIO ALGORITHMS ............................................................13
3.1 Adaptive Data Rate .................................................................................................... 13
3.1.1 Basic ADR Implementation in ThingPark 3.0 (also known as ADR V1)............... 13
3.1.2 ADR V2 ................................................................................................................ 15
3.1.3 ADR V3 Algorithm............................................................................................... 17
3.1.4 ADR-Related Parameters in the Device Profile .................................................. 27
3.1.5 ADR-Related Parameters in the Connectivity Plan ............................................ 28
3.1.6 ADR Algorithm Selection .................................................................................... 29
3.2 RX2 Optimization ....................................................................................................... 30
3.3 Antenna Diversity ...................................................................................................... 34
3.4 Asynchronous Uplink/Downlink Processing .............................................................. 36
3.5 Replay Attack Mitigation (NFR-730/NFR-731)........................................................... 38
3.6 Best-LRR Selection Algorithm (NFR-924) ................................................................... 41
3.7 Multicast for Class B & C Devices (NFR-187/NFR-1036)............................................ 47
3.8 MAC Commands Retransmission Optimization (NFR-928) ....................................... 58
4 RF REGION CONCEPT ....................................................................................60
4.1 RF Region Configuration/Provisioning in ThingPark Wireless ................................... 60
4.1.1 RF Region creation/update via Operator Manager Application ........................ 62
4.1.2 RF Region Catalog Management ........................................................................ 63
4.2 Associating a Base Station with an RF Region Configuration .................................... 68
4.3 Main RF Region Parameters ...................................................................................... 70
4.3.1 TX Power Parameter Settings............................................................................. 75
4.3.2 RX1/RX2 Parameter Settings .............................................................................. 77
4.3.3 End-Device Parameter Settings.......................................................................... 81

4.3.4 ADR Parameter Settings ..................................................................................... 84
4.3.5 “RX2 Optimization” Parameter Settings ............................................................ 92
4.3.6 “Limit SNR per SF” Parameter Settings .............................................................. 92
4.3.7 “RX Channel” Parameter Settings ...................................................................... 95
4.3.8 “TX Channel” Parameter Settings ...................................................................... 99
4.3.9 Listen Before Talk (LBT) Parameter Settings (NFR 598) ................................... 103
4.3.10 Class B Parameter Settings (NFR 596) .............................................................. 104
4.3.11 Best-LRR Selection Parameters (NFR-924) ....................................................... 106
4.3.12 MAC Commands Retransmission parameters (NFR-928) ................................ 108
4.3.13 Other Parameters ............................................................................................. 110
5 INTERACTION BETWEEN PARAMETERS SETTINGS IN DIFFERENT THINGPARK INTERFACES
114
5.1 Device Profile Parameter Settings ........................................................................... 114
5.2 Connectivity Plan Parameter Settings ..................................................................... 119
ABOUT ACTILITY .............................................................................................. 121

ACRONYMS AND DEFINITIONS
Acronyms Definitions
ABP Activation By Personalization
ADR Adaptive Data Rate
AES Advanced Encryption Standard
AS Application Server
BPM Business Process Management
BS Base Station
BSS Billing Support Systems
CSP Communication Service Provider
DC Duty Cycle
End Device A sensor or actuator
ESP Estimated Signal Power
ETSI European Telecommunications Standards Institute
HAN Home Area Network
HSM Hardware Security Module
IaaS Infrastructure As A Service
IEC International Electrotechnical Commission
IoT Internet of Things
ISM Industrial Scientific Medical
GSCL Gateway Service Capability Layer
GTM Go To Market
KPI Key Performance Indicator
LC Logical Channel
LoRaWAN™ Long Range Wide Area NW
LPWAN Low Power Wide Area Network
LRC Long Range Controller
LRR Long Range Relay
MAC Media Access Control
M2M Machine-2-Machine
MTBF Mean Time Before Failure

Acronyms Definitions
NAT Network Address Translation
NW Network
NSCL Network Service Capability Layer. Also called RMS.
OBIX Open Building Information Exchange
OSS Operations Support Systems
OTA Over The Air
PER Packet Error Rate
PKI Public Key Infrastructure
POC Proof Of Concept
REST Representational State Transfer
RF Radio Frequency
RIT Receiver Initiated Transmit
RSSI Received Signal Strength Indicator
SaaS Software as a Service
SF Spreading Factor
SLRC Secured LRC (VPN Concentrator)
SMP System Management Platform
SMTP Simple Mail Transfer Protocol
SNMP Simple Network Management Protocol
SNR Signal to Noise Ratio
SSH Secure SHell
SSO Single Sign On
TLS Transport Layer Security
TWA ThingPark Wireless Application
UNB Ultra Narrow Band
VM Virtual Machine
VPN Virtual Private Network
WS Web Service

1 SCOPE
The scope of this document is to provide guidelines to ThingPark Wireless radio parameters
optimization in ThingPark release 6.1.
The document is divided into 3 main sections:
▪ Description of the main radio algorithms: Adaptive Data Rate (ADR), RX1/RX2
selection, Antenna Diversity, Uplink Replay Attack Mitigation, Asynchronous UL/DL
mode, Best-LRR Selection and Multicast.
▪ Description of RF Region concept, associating each Base Station to an RF Region,
presentation of the configurable parameters per RF Region…
▪ Interaction between the parameters configured in Device Profile, Connectivity Plan
and RF Region.
The target audience of this document is LoRaWAN™ radio network planning and optimization
teams, as well as quality assurance teams.

2 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.
Operator & Enterprise Application Servers

On-Line Shops
OSS & BSS Management
API Layer
ThingPark OS ThingPark Wireless Core NW & OSS ThingPark X

ThingPark Enterprise
User Portal Store (E-Shop) Operator Connectivity Address Usage Record Supervision, System OCP Edition SaaS Edition RMC
Manager Manager Manager Manager (UDR) Monitoring, Management
Alarms Platform (SMP)
BPM Engine Market
Drivers Connectors
Wireless Device Network

Logger Manager Manager LTE Security Geo-Location
Vendor Supplier Billing & EPC Server Server
Manager Charging ETSI M2M ETSI M2M
Manager Connectors
Net GSCL NSCL
Spectrum Network LoRaWANTM LoRaWANTM

Analysis Tool Survey Network Join Server ²
Local GW (GSCL)
Server
LoRaWANTM LRR (Gateway)

Any Device
Radio Network TPW Air Interface Message Broker Cluster Computing
Planning Tool Dimensioning Tool (Kafka) (Spark) LoRaWANTM /LTE Devices
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.

3 MAIN THINGPARK RADIO ALGORITHMS
3.1 Adaptive Data Rate
The Packet Error Rate (PER) of the communication between an end-device and an LRR Base
Station depends on the Signal to Noise Ratio (SNR) measured at the receiver. As the Spreading
Factor (SF) of the LoRaWAN™ physical layer is increased, the communication bitrate is
reduced, and the communication remains possible at lower signal levels.
The goal of the Adaptive Data Rate (ADR) feature of the ThingPark network is to always select
the highest possible communication bitrate for each end-device, for a given link budget
between the end-device and the Base Station. When devices are located closer to a Base
Station, or higher in a building (urban environment), the ADR algorithm selects higher bitrates.
As illustrated in Figure 2, the ADR feature makes it possible to reduce the average energy
consumption within a cell compared to fixed data rate technologies: at higher data rates,
frames are transmitted faster, and both the end-device transceiver and processor can spend
more time in sleep mode.
Figure 2– ADR effect on bitrate and energy consumption
3.1.1 Basic ADR Implementation in ThingPark 3.0 (also known as ADR V1)
The principle of ADR algorithm in ThingPark 3.0 is to compute the median SNR value of the
last 10 received uplink packets and to compare it against the limit SNR for each Spreading
Factor, taking into account a margin.

Note: When computing the median SNR value of the last 10 received packets, any lost packet
is injected in the distribution with a very low SNR level (-25 dB) to ensure that SNR distribution
remains consistent with the effective end-device Packet Error Rate. Indeed, lost packets are
typically those whose SNR is below the limit SNR level for the current Spreading Factor.
The algorithm considers a margin to account for SNR fluctuations around the median value
due to fading.
The lowest possible Spreading Factor is then selected, as illustrated in Figure 3. The requested
Spreading Factor is conveyed to the end-device using a MAC layer command. The end-device
must comply with the selected Spreading Factor: non-compliant end-devices using higher than
requested Spreading Factors (lower data rates) generate alarms in the Device Manager portal.
Figure 3 - Simplified ADR algorithm
Note that ADR is a relatively slow algorithm, therefore optimized for static end-devices only.
Moving end-devices typically encounter too much variation of these radio conditions so that
ADR cannot be reactive enough to track such fluctuations. Accordingly, such mobile devices
can signal this in the MAC layer (ADR bit of the frame control field) to inhibit ADR, or
alternatively, the Connectivity Plan characteristics may configure the ADR algorithm to use a
fixed data rate.

Setting the optimal ADR margin value (default = 10 dB):
ADR margin can be configured per RF Region using the parameter margin_db. For more details
about RF Region settings, please see 4 RF Region Concept.
This margin should be tuned according to the target Packet Error Rate. A good practice is to
start with a low margin value (for instance, 5dB), and increase until observed uplink packet
error rate in the cell is acceptable (for instance, below 10%).
3.1.2 ADR V2
Compared to ADR V1, ADR V2 provides better ADR management to optimize the following
parameters:
▪ Data Rate (Spreading Factor): by considering the minimum required macro-diversity

in the computation of the median UL SNR.
▪ For example, if each packet should be received by at least 3 gateways (N=3), then
Median_SNR = MIN [Median_SNR1, Median_SNR2, Median_SNR3].
▪ N is configurable by the RF Region parameter MinimumAntennaDiversity but it can

also be set at Connectivity Plan level via the parameter “Minimum antenna (macro)
diversity” (see Figure 4). Note that the Connectivity Plan value takes the precedence
over the RF Region value.
Figure 4 – ADR V2 fields in Connectivity Plan
▪ TX Power: Device power is optimized for SF7, when the device is very close to the
gateway.
▪ The power increase/decrease is determined by the delta between the Median SNR (as
computed above based on the value of MinimumAntennaDiversity) and the limit SNR
for SF7 (defined by the parameter SNR_limit_SF7 in RF Region).
▪ Repetition: the number of repetitions is semi-statically configured at RF Region &

Connectivity Plan levels, as per the following equation:

Number of transmissions per uplink packet = MIN (Redundancy + Number of
transmissions offset, Maximum number of transmissions), where:
▪ Redundancy is set in RF Region.
▪ “Number of transmissions offset” is set in the Connectivity Plan (see Figure 4)

to allow differentiating the number of repetitions between different grades of
services. It is set to 0 by default.
▪ Maximum number of transmissions is set in the Device Profile to provide an

upper bound to the number of transmissions.
Figure 5 – ADR V2 fields in Device Profile

Example: If 2 grades of service are targeted by the network operator, one with a target
packet success rate of 95% and another one with 80% success rate, the baseline
redundancy value can be set in RF Region, while the grade of service differentiation
can be addressed by the “number of transmission offset” in Connectivity Plan; as per
the following configuration:
▪ RF Region setting: <lora:Redundancy>2</lora:Redundancy>
▪ Connectivity Plan (95% success rate): Number of transmissions offset = 1
▪ Connectivity Plan (80% success rate): Number of transmissions offset = 0
The 3 parameters (Data Rate, TX Power and Number of Transmissions) are conveyed to the
device in “LinkADRReq” MAC command.
Additionally, ADR V2 offers more flexibility in tuning ADR parameters compared to ADR V1:
▪ In ADR V2, it is possible to tune the SNR margin applied on top of the median SNR in
the following way: Total margin = margin_db + Margin offset, where:
o margin_db is set in RF Region as detailed in 3.1.1 Basic ADR Implementation in
ThingPark 3.0 (also known as ADR V1), default value = 10 dB.
o “Margin offset” is set in the Connectivity Plan, default value = 0 dB, see Figure
4.
▪ In ADR V2, the SNR sliding window size is configurable: the computation of median
SNR considers a sliding window of the last EstimationSlidingWindow *
MinimumAntennaDiversity uplink packets, where EstimationSlidingWindow is defined
at RF Region level (default = 10), and MinimumAntennaDiversity is configured at RF
Region and/or Connectivity Plan level.

Note for US915/AU195 profiles (NFR-883):
For US915 (respectively AU915) profile, the maximum data rate supported by ADR V2 is DR3
(respectively DR6 for AU915) in the current release. This means that the dynamic data rate
adaptation is currently supported for 125 kHz channels only.
SF8/500 kHz (corresponding to DR4 for US915 and DR6 for AU915, and supported by NFR 883)
is commanded in LinkADRReq only when the all channels activated for the device have 500
kHz bandwidth (no 125 kHz channels activated for the device).
In future ThingPark releases, DR4/DR6 will be also integrated into the dynamic data rate
optimization by ADR algorithms.
Important Warning: ADR V2 will be deprecated by Actility in the next

ThingPark release, it will be replaced by ADR V3 (see next section).
3.1.3 ADR V3 Algorithm

With ADR V3, the three uplink transmission parameters (Spreading Factor, TX Power, #
Repetitions) are jointly optimized by the Network Server to achieve the target quality metrics.
Figure 6 – Main parameters optimized via ADR V3
ADR V3 optimization is quality-driven, based on the following targets:

▪ Maintaining Target Packet Error Rate (PER): PER reflects the quality of end-to-end
transmission, including both link budget and collision issues.
▪ Ensuring sufficient uplink coverage overlap for geo-location: When location is
required for a given device, even if PER meets the target, ADR should make sure that
device packets are received by multiple gateways (at least 3) to allow triangulation.
The following table illustrates the main differences between ADR V2 and ADR V3:

ADR V2 ADR V3
SNR-based Quality-based (PER and Overlap metrics)
End-device power saving ++ End-device power saving +++
Static repetition (predefined in RF Region + Dynamic repetition based on quality targets’
offset at Connectivity Plan level) fulfillment
Uplink TX Power control at SF7 cannot be It is possible to disable the ADR optimization
deactivated of any TX parameter (SF, TX Power or
Repetition) by setting Min value = Max value
in Device Profile/Connectivity Plan
Static SNR margin (margin_db, applied on No static SNR margin: SNR-related ADR
top of median SNR) needs to be manually decisions (to change SF or TX Power) are
tuned based on degree of coverage taken based on target quality metrics
overlapping and target PER considering the whole SNR distribution (not
just the median value)
Algorithm reactivity is controlled through Algorithm reactivity is controlled through
EstimationSlidingWindow RF Region forgetting factor & hysteresis parameters at
parameter RF Region level
Table 1 – Comparison between ADR V2 and ADR V3
For more details on the field test comparison between ADRv2 and ADRv3, please refer to [9].
3.1.3.1 ADR V3 Quality Metrics
3.1.3.1.1 Packet Error Rate (PER) Criterion

Target_PER is set in the Connectivity Plan and in RF Region, the Connectivity Plan setting
(mandatory field) takes the precedence over RF Region setting. The default setting is 10% PER.
To maintain this Target_PER, ADR V3 continuously evaluates uplink PER of each device (via a
long-term PER metric: PER_LT), as follows:
▪ Whenever the device boots/reboots, or following a transmission of new ADR MAC(1)
command, LRC computes the initial PER (PERinitial) over Initial_WindowSize
successfully decoded distinct packets (Initial_WindowSize(1) = 5 by default).
▪ Example1: LRC receives FCntUp 1,2,3,4,5 after boot → PERinitial = 0%
▪ Example2: LRC receives FCntUp 1,2,4,5,7 after boot → PERinitial = 28.5%

This PERinitial is used by the LRC to initialize the long-term PER metric: PER_LT = PERinitial
▪ For each new packet arriving, the LRC re-computes PER_LT = PER_LT * (1-K) + PER_ST
*K, where:

o PER_ST is computed over the 2 last successfully decoded distinct packets.
o K is the PER forgetting factor, defined by the RF Region parameter
Forgetting_Factor.
When the end-device successfully acknowledges a LinkADRReq command, PER statistics are
reinitialized by ADR V3 and the LRC waits for at least Initial_WindowSize(1) distinct packets
before potentially sending another ADR command. This mechanism is meant to provide
enough time for quality metrics’ convergence before the LRC reattempts a new set of ADR
parameters.
(1) Please see the NOTE below on Initial_WindowSize tuning starting release 6.0.
3.1.3.1.2 Coverage Overlap Criterion

The target coverage overlap criterion is mainly relevant when the end-device needs to be
LoRaWAN™ geo-located, it expressed as follows:
R >= MinimumAntennaDiversity over Macro_Div_Reliab % of occurrence, where:
▪ “R” = # gateways successfully receiving the device’s packets.
▪ MinimumAntennaDiversity = minimum required # gateways for geo-location, denoted

N in the remainder of this document. This parameter is defined in the Connectivity
Plan and RF Region (higher precedence for Connectivity Plan setting), default = 1.
▪ Macro_Div_Reliab is the target macro diversity reliability, defining the minimum %

occurrence when the device packets should be simultaneously received by N
gateways. Macro_Div_Reliab is defined in the Connectivity Plan and in the RF Region
(higher precedence for Connectivity Plan setting), default = 80%.
Example: if MinimumAntennaDiversity = 3 and Macro_Div_Reliab = 80%, the coverage overlap
target shall be fulfilled when at least 80% of the distinct uplink packets (that is to say, distinct
FCntUp, excluding repeated frames) are received by at least 3 gateways.
Note that the combination of Macro_Div_Reliab & MinimumAntennaDiversity parameter

settings shall impact the geolocation precision, with a trade-off between location precision
and end-device battery consumption.
To maintain this coverage-overlap target, the LRC continuously computes N_Server_Prob_LT

metric which is the long-term percentage of time that uplink packets are successfully reported
with a fine-timestamp by N servers:
▪ Like PER_LT computation, N_Server_Prob is initialized after device reboot or following

a LinkADRReq acknowledged by the device. N_Server_Probinitial is evaluated over
Initial_WindowSize distinct packets and initializes N_Server_Prob_LT metric.

▪ For each new distinct packet (that is to say, distinct FCntUp), re-compute
N_Server_Prob_LT = N_Server_Prob_LT * (1-K) + N_Server_Prob_ST *K, where:
o N_Server_Prob_ST is the average probability of reception by N gateways over
the previous 2 successfully decoded packets.
o K is the Overlap forgetting factor, defined by the RF Region parameter
Forgetting_Factor_Overlap.
The coverage overlap target is fulfilled when (1 - PER_LT) * N_Server_Prob_LT >=
Macro_Div_Reliab.
Note about coverage overlap assessment (NEW in release 6.1 (RDTP-11576)):

▪ When the Geolocation mode = TDoA in the device’s Connectivity Plan, the coverage
overlap target is always checked against fine-timestamp count (i.e. number of
receiving base stations reporting a valid fine timestamp for each uplink frame).
▪ When Network Geolocation is deactivated in the device’s Connectivity Plan or when
the Geolocation mode = RSSI, the coverage overlap target is always checked against
the LRR count (i.e. absolute number of receiving base stations whatever the fine-
timestamp-count).
▪ When the Geolocation mode = “BOTH” (that is to say, geolocation algorithm is
automatically adapted between TDoA and RSSI modes depending on the device
context and availability of the fine timestamps), ADRv3 is enhanced to dynamically
adapt the way coverage overlapping criterion is used by the algorithm:
o If the device is geolocated via TDoA algorithm, then the target “Minimum
Antenna Diversity” is checked against the fine-timestamp-count.
o If the device is geolocated via RSSI algorithm, then the target “Minimum
Antenna Diversity” is checked against the LRR count (i.e. absolute number of
receiving base stations whatever the fine-timestamp-count).
Examples - assuming Minimum Antenna Diversity = 4 in Connectivity Plan:
▪ Ex-1: Uplink frames of a given device are received by 4 LRRs, 2 LRRs generate valid fine
timestamps and 2 other LRRs cannot generate fine timestamp (for instance, indoor
nano base stations with v1.5 reference design). Since the LocSolver cannot resolve the
device location based on TDoA algorithm (fine-timestamp-count = 2), it will use RSSI
mode and will report this mode to LRC. Hence, ADRv3 will check the target Minimum
Antenna Diversity against the LRR count (4 in this example) → the target is fulfilled, no
need to extend the device’s uplink link budget to avoid battery draining.
▪ Ex-2: Uplink frames of a given device are received by 6 LRRs, 5 LRRs generate valid fine
timestamps and 1 LRR cannot generate fine timestamp. LocSolver will typically use
TDoA algorithm to resolve the device location (as fine-timestamp-count = 5); hence

ADRv3 will check the target Minimum Antenna Diversity against fine-timestamp-count
(5) → ADRv3 considers that coverage overlap criterion is fulfilled and checks if the
device should reduce its SF/TxPower/number of transmissions to optimize its battery.
NOTE: To avoid being stuck in RSSI mode when TDoA usage becomes possible, ADRv3
implements a mechanism to periodically detect the device’s eligibility to TDoA mode. Indeed,
TDoA geolocation is more precise than RSSI geolocation.
Note about Initial_WindowSize setting in ThingPark release 6.0 – NEW (RDTP-3466)

As explained above, 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.
3.1.3.2 ADR V3 Modules

ADR V3 algorithm consists of 2 modules:
▪ ADR_BATTERY_OPTIM: triggered when both quality targets are fulfilled with sufficient
margin. The aim of this module is to “safely” optimize the uplink TX parameters to
ensure efficient end-device power consumption while maintaining the quality targets.
▪ ADR_LKB_BOOST: triggered when at least one quality target is not fulfilled (that is to
say, the end-device in difficult radio conditions). The aim of this module is to “quickly”
rescue the link budget between end-device and the network to reach quality targets.
The following flow chart illustrates the functional behavior of ADR V3 algorithm at every new
packet arrival:

Figure 7 – ADR V3 flow chart
Please note that ADR_LKB_BOOST is meant to secure quick convergence towards target
metrics; whereas ADR_BATTERY_OPTIM acts more conservatively by considering safety
margins and hysteresis to converge to optimum performance without major risk of ping-pong
between ADR_LKB_BOOST and ADR_BATTERY_OPTIM.
In Figure 8 below (N=1 for simplicity):
▪ Device in difficult radio conditions (long-term PER > target, illustrated by the red
point in the figure) will be handled by ADR_LKB_BOOST module to quickly converge
towards target PER.
o Based on default settings: ADR_LKB_BOOST will tend to bring PER_LT to 10%.
▪ Device in very good radio conditions (PER_LT << target, illustrated by the blue point
in the figure) will be handled by ADR_BATTERY_OPTIM module to relax UL
parameters (SF, TX Power or # Repetition) while remaining in the middle of the
grey area (marked by “NO ACTION”).
o Targeting the middle of the grey area (7.5% PER by default) rather than directly
converging to target PER (10% by default) provides a safe mechanism to avoid
ping-pong between both modules.
o The grey area separating both modules is defined by hysteresis parameters
Hyst_PER and Hyst_Overlap, configurable at RF Region level.
o ADR_BATTERY_OPTIM is disabled by setting Hyst_PER = Target_PER and
Hyst_Overlap = Macro_Div_Reliab.

Figure 8 – interaction between modules in ADR V3
3.1.3.2.1 ADR_BATTERY_OPTIM
ADR_BATTERY_OPTIM is triggered when both quality metrics are fulfilled:
▪ PER_LT < Target_PER – Hyst_PER
▪ R >= N over a % of occurrence at least equal to Macro_Div_Reliab + Hyst_Overlap

Hyst_PER and Hyst_Overlap are hysteresis parameters used to avoid ping-pong.
What to optimize:
▪ Device TX Power: Use lower device transmit power compared to max when the device
is close to the gateway and already using the lowest SF allowed by its Connectivity
Plan.
o Gain: Battery lifetime, less interference to surrounding medium, less collision to
higher SF.
▪ # Repetitions (NbRep): for instance, moving from 3 consecutive transmissions to 2 or

1 if quality of service shall not be degraded.
o Gain: Airtime reduction → battery lifetime, less interference, more device capacity
within its Duty Cycle limit.
▪ Spreading Factor (SF): reducing SF, especially when the device is already using 1
transmission (no repetition) as long as actual SF is higher than the min SF allowed by
the Connectivity Plan.
o Gain: Airtime reduction → battery lifetime, less interference, more device
capacity within its Duty Cycle limit.
The decision order of ADR_BATTERY_OPTIM module is illustrated by the below flow chart:

Figure 9 – ADR_BATTERY_OPTIM flow chart
3.1.3.2.1.1 ADR_BATTERY_OPTIM – Repetition Optimization
Eligibility: current # transmissions (NbRep) > REP_Min

REP_Min and REP_Max parameters define the minimum and maximum number of repetitions;
they are configured in RF Region but can be tuned at Connectivity Plan level via the fields
“Minimum number of Device uplink transmissions” (taking the precedence over the RF Region
parameter REP_Min) and “Maximum number of Device uplink transmissions” (taking the
precedence over the RF Region parameter REP_Max).
Note: The effective upper limit for the number of transmissions considered by ADR V3 is
defined as the maximum value between “Maximum number of transmission” in Device Profile
and “Maximum Number of transmission” in the Connectivity Plan (this latter setting is
replaced by the RF Region value REP_Max if the corresponding field is empty in Connectivity
Plan).
3.1.3.2.1.2 ADR_BATTERY_OPTIM – SF Optimization
Eligibility: current SF > SFmin allowed for the device

SFmin and SFmax parameters define the minimum and maximum allowed Spreading Factors;
they are configured in the Connectivity Plan and RF Region (the Connectivity Plan setting takes
higher precedence).
3.1.3.2.1.3 ADR_BATTERY_OPTIM – TX Power Optimization
Eligibility: current SF = SFmin AND NbRep = REP_Min AND Current TX Power > MinPower

MinPower and MaxPower parameters define respectively the minimum and maximum
allowed TX Power for the device; they are configured in the Device Profile and RF Region
(Device Profile setting takes higher precedence).
3.1.3.2.2 ADR_LKB_BOOST
ADR_LKB_BOOST is triggered when at least one of the conditions below is fulfilled:
▪ PER_LT > Target_PER

▪ R < N over a % of occurrence equal to Macro_Div_Reliab → Overlap issue
The decision order of ADR_LKB_BOOST module is illustrated by the flow chart below:
Figure 10 – ADR_LKB_BOOST flow chart
From the flow chart above, one can see that ADR V3 algorithm favors uplink repetition than
increasing the Spreading Factor when the quality targets are not met.
Indeed, 2 transmissions at SF7 have the same aggregated airtime as one transmission over
SF8; yet the former case benefits from both frequency diversity (consecutive transmissions
use random frequency hopping) and time diversity (the device waits at least 2-3 seconds
between each 2 successive transmissions) which makes 2 TX at SF7 more efficient than 1 TX
at SF8 to mitigate RF problems such as packet collision, fast fading and interference issues.
3.1.3.2.2.1 ADR_LKB_BOOST – TX Power Boost
Eligibility: current TX Power configured for the device < MaxPower.
3.1.3.2.2.2 ADR_LKB_BOOST – Increase # Repetitions
Eligibility: current # transmissions (NbRep) < REP_Max.

3.1.3.2.2.3 ADR_LKB_BOOST – Move to Higher SF
Eligibility: current SF < SFmax and NbRep = REP_Max
Note for US915/AU195 profiles (NFR 883):

For US915 (respectively AU915) profile, the maximum data rate supported by ADR v3 is DR3
(respectively DR6 for AU915) in the current release. This means that the dynamic data rate
adaptation is currently supported for 125 kHz channels only.
SF8/500 kHz (corresponding to DR4 for US915 and DR6 for AU915; supported by NFR 883) is
commanded in LinkADRReq only when all the channels activated for the device have 500 kHz
bandwidth (no 125 kHz channels activated for the device).
In future ThingPark releases, DR4/DR6 will be also integrated into the dynamic data rate
optimization by ADR algorithms.
3.1.4 ADR-Related Parameters in the Device Profile

In the Device Profile, the LinkADRReq MAC command should be selected as per Figure 11 to
support sending ADR commands from the LRC to end-devices.
Figure 11 – Enabling LinkADRReq MAC command in the Device Profile
Moreover, the TX Power range supported by the device can be set in the Device Profile
(optional fields). If these fields are set, they overwrite the device settings in RF Region.
Note that “Max TX Power” is used by both ADR V2 and ADR V3 algorithms, while “Min TX
Power” is only used by ADR V3.
To disable the TX Power control in ADR V3, “Min TX Power” may be set equal to “Max TX
Power”.

Figure 12 – ADR parameters in Device Profile
The field “Max number of transmissions” may be used to inhibit repetitions for any legacy
devices not properly supporting this feature.
If this field is left empty, the LRC considers a default value of 10.
3.1.5 ADR-Related Parameters in the Connectivity Plan

Parameters common to all ADR versions Use the drop down menu to set
the minimum and maximum
Spreading Factors for a given
Connectivity Plan
Figure 13 – ADR common parameters in Connectivity Plan
Setting any of these parameters in the Connectivity Plan overwrites the corresponding RF
Region parameters.
The minimum and maximum Spreading Factors can be configured for all devices associated
with a given Connectivity Plan. Accordingly, the ADR algorithm considers the allowed range of
Spreading Factors based on the Connectivity Plan settings.
ADR can be disabled by setting SF min = SF max (for example for moving devices).
Additionally, in the Connectivity Plan, enabling the checkbox “Force adaptive data rate” allows
forcing UL rate adaptation even if the ADR bit is set to 0 by the device. For more information
about ADR bit, please refer to LoRaWAN™ specifications v1.0.2.
ADR V2 parameters in Connectivity Plan
Figure 14 – ADR V2 parameters in Connectivity Plan
The parameters indicated in Figure 14 are detailed in 3.1.2 ADR V2.

ADR V3 parameters in Connectivity Plan:
Figure 15 – ADR V3 parameters in Connectivity Plan
Setting any of the parameters presented in Figure 15 at Connectivity Plan level takes higher
precedence than the corresponding setting at RF Region level.
When these fields are set, “Minimum number of Device uplink transmissions” and “Maximum
number of Device uplink transmissions” overwrite respectively the RF Region parameters
REP_Min and REP_Max for all devices associated with this Connectivity Plan.
Note: The effective upper limit for the number of transmissions considered by ADRv3 is
defined as the maximum value between “Maximum number of transmission” in Device Profile
and “Maximum Number of transmission” in the Connectivity Plan (if this latter parameter is
left empty in Connectivity Plan, then it is replaced by the RF Region value REP_Max).
3.1.6 ADR Algorithm Selection

The choice of the ADR algorithm is defined at Connectivity Plan level, in the field “Adaptive
Data Rate algorithm”:
Figure 16 – ADR algorithm selection in Connectivity Plan
New in release 6.1 (RDTP-8676):

▪ All the new Connectivity Plans use ADR V3 (cannot use ADR V2).
▪ For existing Connectivity Plans created before the upgrade to release 6.1, if ADR V2 is
configured, it continues to be used by all the devices associated to this CP. The
Connectivity Supplier has the possibility to move to ADR V3. Note that switching to
ADR V3 is not a reversible action.

3.2 RX2 Optimization
All end-devices implement two downlink receive windows identified as RX1 and RX2.
This algorithm allows the LRC to optimize the choice between RX1 & RX2 slots.
As per LoRaWAN™ specifications v1.0.2, when listening to RX1 slot, the end-device expects to
receive a downlink signal using the same channel and Spreading Factor (if RX1DRoffset = 0) as
the last uplink transmission.
On RX2 slot, the end-device expects to receive a signal using a fixed configurable data rate
(SF9 by default) on a preset channel frequency (869.525 MHz by default for EU868).
The end-device will listen to RX2 slot if it has not received any downlink transmission on RX1,
therefore the choice of using RX1 or RX2 is made by ThingPark network.
When RX2 Optimization algorithm is not activated: DL transmission shall systematically use
RX1 slot, except in one of the following two cases:
1. If, due to unexpected backhaul network latency, the downlink frame reached the LRR
too late for RX1 slot but still in time for RX2, the LRR shall use RX2 slot.
2. [New with NFR-766]: if the LRC forces the use of RX2 to comply with the downlink
maximum payload size defined in LoRaWAN™ Regional Parameters v1.0.2revA/revB.
When RX2 Optimization algorithm is activated: The RX1/RX2 selection algorithm is
performed both by the local LRR and by the central LRC platform as described below:
▪ LRC algorithm: The LRC decides between RX1 and RX2 slots based on the following
criteria:
1. Link Budget criterion: Since RX2 channel can use higher TX Power than RX1 in
EU868 profile, end-devices with limited link budget shall use RX2 slot in priority
to secure reliable DL transmissions in bad coverage spots.
2. Data Rate criterion: When end-devices are not link-budget limited (that is to
say, radio conditions are “fair enough” for RX1 use), the LRC shall select the RX
slot that maximizes the data rate (that is to say, lower SF) to reduce air-time
and boost the DL capacity.
3. [NFR-766]: To comply with the maximum downlink MAC payload size imposed
by LoRaWAN™ Regional Parameters v1.0.2revA/revB, the LRC may force the
use of RX2 slot if the applicative payload can only be sent over RX2 but not RX1.
Let’s consider the following example:
▪ The applicative payload has 80 Bytes and the regional profile is EU868.
▪ The RX1 data rate is DR2 (SF10), the maximum allowed payload size for
RX1 is 59 Bytes, as per LoRaWAN™ Regional Parameters
v1.0.2revA/revB.

▪ The RX2 data rate is DR3 (SF9), the maximum allowed payload size for
RX2 is 123 Bytes → RX2 is forced by the LRC to send this downlink
frame.
4. Backhaul latency: When the round-trip delay between LRR and LRC is high, LRC
forces the use of RX2 channel to maximize the chances of sending the downlink
frame within the device’s timing constraints.
To implement the three criteria described above, the LRC applies the following
algorithm:
IF the end-device SNR is lower than the limit SNR for RX1 slot Spreading Factor,
considering an additional margin, THEN
Prioritize RX2 slot,
ELSE
IF the Spreading Factor of RX1 slot is higher than SF_Limit, THEN
ELSE
IF the maximum payload size of RX1 slot < size of the downlink applicative
payload, THEN
ELSE
IF (LRR <-> LRC round trip delay + 350 ms) > RX1 delay configured for the
device AND the RX2 frequency currently used by the device is different from
the RX2 frequency set in RF Region
Prioritize RX2 slot.
ELSE
Prioritize RX1.
▪ LRR algorithm:
o If LRC requested an RX2 slot transmission, use RX2 slot.
o If LRC requested an RX1 slot transmission, but the transmit command reached
the LRR too late due to unexpected backhaul network latency, use RX2 slot if
still in time.
In future ThingPark releases, downlink Duty Cycle of RX1 & RX2 channels shall be considered
in RX1/RX2 selection by the LRC, in the following way:
IF both downlink Duty Cycle of RX1 channel and RX2 channel are below the limit Duty
Cycle, THEN
Select RX1 or RX2 slot according to priority (that is to say, based on the SNR and
SF criteria explained above),
ELSE
Select the only possible slot.
Setting the optimal RX2 Optimization parameters:

The main configurable parameters used by RX2 Optimization algorithm can be set per RF
Region in the following way:
1. margin_uplink: this parameter sets the RX2 Optimization margin applied on the end-
device’s uplink median SNR. The default setting is 12 dB.
Note that downlink and uplink link budgets are not symmetrical:
o SNR_uplink = TX_EIRP – pathloss + LRR_antenna_gain – LRR_noise
o SNR_downlink = TX_EIRP – pathloss + Device_antenna_gain – Device_noise
➔ SNR_downlink = SNR_uplink – (LRR_antenna_gain - Device_antenna_gain) –
(Device_noise - LRR_noise)
Note: TX_EIRP is typically the same for EU zone since it is limited by CEPT regulation.
Therefore, margin_uplink should be set differently from margin_db to account for:
o RX antenna gain delta between the end-device and the gateway.
o Noise floor delta between the end-device and gateway, due to potentially
different interference levels between UL & DL as well as higher device noise
figure (typically 6-7 dB) compared to gateway noise figure (3-4 dB).
o Macro diversity gain (that is to say, the ability to mitigate Rayleigh fading by
receiving the same signal via multiple LRRs) which applies only to UL, not to DL.
Accordingly, margin_uplink = margin_db + (LRR_antenna_gain –
Device_antenna_gain) + (Device_noise - LRR_noise) + additional margin depending on
the macro diversity level in the network (that is to say, the degree of radio overlap).
Note: The link budget criterion described above is only relevant for EU868 regional
profile, but this RX1/RX2 selection criterion should be deactivated for other regions
since RX1 and RX2 channels use the same TX Power. The link budget criterion can be
deactivated by setting margin_uplink to a highly negative value (for instance, -40 dB).
2. SF_Limit: This parameter defines the limit Spreading Factor for RX1 slot. It is used by
the LRC algorithm described above to inspect the Data Rate criterion. The default
setting of this parameter is SF9.
In order to prioritize the fastest channel, it is recommended to set SF_Limit to the same
data rate as RX2 (that is to say, set SF_Limit = RX2DataRate). Increase the value only
when the LRR cell downlink capacity on RX2 is near the limit Duty Cycle, or when RX2

channel is highly more interfered than other RX1 channels (remember that RX2 slot
has no frequency diversity).
Activating the RX2 Optimization Algorithm:

RX2 Optimization algorithm can be activated separately for each LRR from the Network
Manager portal → Administration tab.
Figure 17 – Activating RX2 Optimization in Network Manager
Note: RX2 Optimization feature is activated by default for newly created base stations.

3.3 Antenna Diversity
Configuring Antenna Diversity:

Antenna diversity feature is supported by Semtech’s V2 reference design. It requires 2 physical
antennas per sector. To reflect this, the LRR hardware configuration set in Network Manager
should consist of 2 antennas.
Additionally, depending on the hardware configuration of the gateway, in terms of number of
radio boards and whether the gateway supports single sector or multi-sectors, the “RF
hardware configuration in use” field should be set to one of the following configurations:
▪ s1_a2_b1: 1 sector, 2 antennas, 1 board

▪ s1_a2_b2: 1 sector, 2 antennas, 2 boards
Figure 18 – Antenna Diversity configuration in Network Manager
▪ For antenna diversity configuration with 1 sector (s=1), 2 antennas (a=2) and 1 board
(b=1):
The RF Region should be configured with maximum 8 channels: indeed, each SX1301
chip is connected to one antenna and handles max 8 channels. The LRR configuration
is detailed below:
o Board 0:
▪ SX1301 chip 0: rfchain 0, LC 1 to 8, CHAIN* 0
▪ SX1301 chip 1: rfchain 1, LC 1 to 8, CHAIN 1
* The CHAIN terminology refers to the antenna ID, it is used by Wireless Logger
to display the fine timestamp of each antenna receiving the uplink packet.
▪ For antenna diversity configuration with 1 sector (s=1), 2 antennas (a=2) and 2 boards
(b=2):
o If the number of Logical Channels in RF Region <= 8, then the following
configuration applies:
▪ Board 0:
• SX1301 chip 0: rfchain 0, LC 1 to 8, CHAIN 0
▪ Board 1: not used
o If 8 < number of Logical Channels in RF Region <=16, then the following
configuration applies:
▪ Board 0:
▪ Board 1:
During antenna installation, the following mapping between physical antenna and rfchain
should be respected to provide reliable indication about the used CHAIN.
▪ rfchain 0 should be connected to CHAIN 0

▪ rfchain 1 should be connected to CHAIN 1
Note: In order to support antenna diversity configurations, the number of antennas defined
in $ROOTACT/usr/etc/lrr/lowlvlgw.ini file should be manually set to 2.
[gen]
antenna=2
How it Works for Uplink Packet Reception:
▪ When 2 packets are received by the LRR from the same device over different antennas,
the LRR determines the best packet (having highest ESP) and its corresponding rfchain.
▪ All the packets received over the different rfchains are forwarded to the LRC; and
eventually to LOC solver if the device needs be to geo-located.
▪ The LRC sends both packets to Wireless Logger. Therefore 2 entries are visible in
Wireless Logger GUI when antenna diversity is supported, but only the RSSI/SNR
metadata of the best packet (highest ESP) are considered. Also, only the best packet is
forwarded to TWA.
▪ ADR algorithm does not account for antenna diversity, only the best packet is included
in the SNR distribution used by ADR algorithm.
How it works for Downlink Packet Transmission:

If both rfchains are configured with txenable = 1, then the downlink response is sent on the
rfchain having the best ESP score of the previous UL packet. Otherwise, rfchain 0 will be used
for all downlinks.
“txenable” setting can be verified in $ROOTACT/actility/usr/etc/lrr/lowlvlgw.ini
(custom configuration) and $ROOTACT/actility/lrr/config/lowlvlgw.ini (default
configuration):
[rfconf:0:0] ; rfconf:board:rfchain (board0, rfchain0 here)
txenable=1
[rfconf:0:1] ; rfconf:board:rfchain (board0, rfchain1 here)
txenable=1

3.4 Asynchronous Uplink/Downlink Processing
In the current release, the LRC supports two modes for downlink packet transmission:
▪ Synchronous mode (default mode): In this mode, when the LRC receives an uplink
frame, it immediately inspects the downlink queue of this device after the expiry of
the deduplication window (250 ms), as per the following diagram:
Figure 19 – Synchronous UL/DL processing
(1) After the deduplication window (default 250 ms). The processing is synchronous, the LRC does not wait for an AS DL
answer and immediately processes the UL.
(1.1) The DL is buffered on the LRR.
(1.2) If the AS sends an AS DL to the associated device, the payload cannot be included in the DL answer. The payload must
wait in the DevFifoDn for the next device UL.
For Class A devices in synchronous mode, the AS response to the current uplink frame
(if any) is only transmitted in the next scheduling occasion, that is to say when the
device sends the next uplink frame.
This mode is good enough when the total end-to-end round-trip latency between the
device and AS (including AS processing time) is higher than the RX1 delay.
▪ Asynchronous mode (introduced by NFR-729): In this mode, when the LRC receives
an uplink frame, it starts a timer (denoted WaitAsResps in the diagram below and
configurable in Device Profile) to wait for a potential downlink frame coming from the
AS in response to this uplink frame. Once this timer expires, the LRC inspects the
downlink queue. Therefore, in this mode, the processing of downlink application
frames coming from AS is decorrelated from the uplink reception/processing.

Figure 20 – Asynchronous UL/DL processing
(2) After the deduplication window (default 250 ms) the UL processing is asynchronous, the LRC only sends reports to
TWA and to the AS. The delay used to process the UL is guarded by WaitASResps starting after the deduplication
window.
(2.4) If the AS sends an AS DL, for the associated device, before the expiration of WaitASResps, the payload is added to
the DevFifoDn.
The reception of the AS DL wakes up the UL processing: the payload can be included in the DL answer.
(2.5) The DL is buffered on the LRR.
Asynchronous mode enables the device to get the AS response to its latest uplink
frame within the current RX1/RX2 slots. It becomes useful if the end-to-end latency
between the device and the AS (including AS processing time) is lower than RX1 delay.
To activate Asynchronous Mode and configure the LRC timer, WaitASResps, a new
parameter is added in the Device Profile and Connectivity Plan:
Notes:
▪ Setting “Asynchronous UL processing” to 0 (or empty) disables Asynchronous

mode. To activate Asynchronous processing, the parameter “Asynchronous UL
processing” should be set to the target LRC waiting time WaitASResps.
▪ To fully leverage asynchronous mode, NFR-880 allows setting RX1 delay in the
Device Profile and/or Connectivity Plan to offer a consistent setting with
“Asynchronous UL processing”.
3.5 Replay Attack Mitigation (NFR-730/NFR-731)
The LRC implements a replay attack protection mechanism for both Join procedures and
regular uplink frames.
▪ For Join procedure (NFR-730):

1. The LRC memorizes the DevNonce history of the last N Join Request messages
(N = 50 by default). Any Join Request received with a DevNonce already present
in the DevNonce history is dropped by the LRC, triggering a TWA alarm to signal
a potential risk of replay attack.
2. In addition to DevNonce history verification, the LRC waits for a valid uplink
frame before validating the Join procedure. In other words, the new session
security keys remain pending on the LRC until a valid uplink frame is received
with a valid MIC using the new NwkSKey. During this transitional phase, the LRC
keeps both the old and the new security contexts, as described by section 6.2.4
of LoRaWAN™ specifications v1.0.2.
Note: NFR-730 implies that Class C OTAA devices cannot receive downlink frames
before they send their first uplink frame after a successful Join procedure.
Note: Another mitigation to the replay attack during Join procedures consists in using
counter-based DevNonce (in JoinRequest) and AppNonce/JoinNonce (in JoinAccept).
While this is fully supported by the LRC, it may not be supported by all the end-devices
hence the Device Profile configuration indicates to the LRC whether the device
supports counter-based DevNonce or not.
▪ For regular uplink frames (NFR-731):

Through the inspection of the frame counter (FCntUp) of each uplink frame, the LRC
expects monotonically increasing frame counters. Therefore, if the LRC receives any
uplink frame whose FCntUp is not higher than the last known FCntUp, it drops the
frame and generates a TWA alarm to signal a potential risk of replay attack.
Nevertheless, the LRC derogates to the rule described above in the following special
conditions:
1. Device Reset: When a device is reset, the LRC naturally accepts a reset of the
frame counter history.
▪ OTAA devices are naturally reset through “valid” Join procedures
(governed by NFR-730 as explained above).
▪ For ABP devices, although LoRaWAN™ 1.0.4 and 1.1 versions clearly
prohibit FCntUp reset for ABP devices, LoRaWAN™ 1.0.x devices (x < 4)
do not necessarily follow this rule. Therefore, ThingPark supports ABP
device reset only if the following conditions are met:

1. In the Device Profile, the flag “Allow ABP automatic reset” is
enabled:
2. The new FCntUp is lower than 255. This condition ensures that
a reset condition can still be detected by the LRC even in case of
significant packet loss up to 254 lost packets (for instance, when
the device is reset while being out of LoRaWAN™ coverage).
Note: For both ABP and OTAA devices, in addition to the reset
conditions described above, an administrative reset action can be
triggered by the device administrator to reset the current security
context. This action can be triggered from Device Manager GUI, in the
“Settings” tab (as shown below) or directly from OSS APIs/web services.
Important: Please do not trigger “Reset security context” unless the

device has effectively been reset: the ThingPark action does not send
any reset command to the device (such command does not exist in
LoRaWAN™ protocol 1.0.x).
2. Uplink Frame Repetition: An uplink frame (with a given FCntUp) is forwarded
once to AS, in other words frame repetitions are never forwarded to AS.
However, some “legitimate” uplink repetitions could trigger “partial” MAC-
layer processing by the LRC.
Note: Partial processing includes uplink ADR processing, best-LRR selection,
geolocation processing, and leverage of the downlink transmission
opportunity.
The maximum number of authorized (legitimate) repetitions of the same
FCntUp depends on the uplink data mode employed by the device:
▪ Confirmed mode with ADR activated: The maximum number of uplink
frame repetitions tolerated by the LRC is defined in the Device Profile
(default = 10):
▪ Unconfirmed mode with ADR activated: The maximum number of

uplink frame repetitions tolerated by the LRC is dictated by the NbTrans
value derived by ADR algorithm and sent to the device in the
LinkADRReq MAC command.

▪ Devices with deactivated ADR: The maximum number of uplink frame
repetitions tolerated by the LRC is defined systemwide in lrc.ini
(MaxRedundancyNoADR, default = 4):
NOTE: The parameter “RedundancyDeduplicationTimer” defines the maximum
time duration - counted from the reception of the initial uplink frame (FCntUp)
- beyond which the LRC does not expect any legitimate frame repetition. Any
repeated frame received after the expiry of this timer is treated by the LRC as
a replay attack. By default, any uplink frame received by the LRC more than
300s after the reception of the initial copy of this FCntUp shall be considered as
a replay attack. For more details, please see 4.3.13 Other Parameters.

3.6 Best-LRR Selection Algorithm (NFR-924)
NFR-924, introduced in ThingPark Wireless 5.0.1, optimizes the best-LRR selection algorithm
for both downlink and uplink frames.
Best-LRR for uplink frames:
For each uplink frame, the LRC identifies the best-LRR server; this best-LRR notion for each
uplink frame is used for:
▪ UDR/billing of Managed Customer Networks.

▪ Update of Network Manager statistics by TWA: when the same uplink frame is received
by several gateways, only the stats of the best-LRR are updated by TWA.
Prior to release 5.0, this uplink best-LRR selection was based on the ESP (Estimated Signal
Power) of the last uplink frame.
However, since SNR provides a more accurate representation of the reception conditions than
ESP, in release 5.0 the LRC determines the best LRR of each uplink frame based on its SNR
rather than ESP.
Best-LRR for downlink frames:

The best-LRR for downlink frames is essentially used by the LRC to:
▪ Route the downlink frames to the most appropriate gateway and update downlink
statistics in Network Manager accordingly.
▪ Determine the optimum RF Region configuration for each device, since the device
inherits the RF Region configuration of its downlink best-LRR.
NFR-924 addresses the following drawbacks seen in downlink best-LRR selection from
previous releases:
1. Issue #1: Prior to TPW5.0.1, the downlink best-LRR selection was based on the ESP of the
last uplink frame. This mechanism could sometimes yield volatile decisions as well as RF
Region ping-pong due to RF signal fading effect.
The following field measurement conducted in urban environment (stationary position)
illustrate the ESP fluctuation due to fast fading. This RF signal fading effect causes a high
risk of best LRR ping-pong as well as sub-optimal LRR selection (and consequently sub-
optimal RF Region association).

Figure 21 – ESP fluctuation in stationary position
Example: A device is covered by 2 LRRs. In average, LRR1 ESP is 5 dB better than LRR2:
▪ At instant T0 (when an UL packet is received by the 2 LRRs): LRR1 suffers from an

instantaneous fading hole (-10 dB with respect to its average RX level), while LRR2 is
in a more favorable fading condition (+5 dB above its average RX level).
▪ At instant T0 + 1s (corresponding to RX1 slot): the situation is inverted, with the signal
coming from LRR1 is around its average level, while that coming from LRR2 is -5 dB
with respect to its own average level → Selecting the best LRR based on the last UL
packet received at T1 yields LRR2 although LRR1 is 10 dB better at the DL transmission
time.
Additionally, the volatile decisions seen before release 5.0.1 could result in the following
side effects:
▪ If the nearest gateway instantly failed to receive an uplink packet (for instance, due to
half-duplex mode), routing of DL packets for Class C devices would be sub-optimized
until the nearest gateway receives a new UL packet!
▪ For heterogeneous network deployments with a mix of picocells (8-channels) and
macrocells (16 channels for instance), any packet missed by a picocell (for a nearby
device) but picked by the macrocell will trigger RF channel reconfiguration for that
device → potential ping-pong effect with back-and-forth MAC reconfiguration.
2. Issue #2: If the nearest gateway to some devices uses a slow backhaul (for instance, 3G
backhaul with one-way delay > 250 ms), it may often be received outside the 250 ms
window → This gateway will rarely be used as best LRR although it has the best ESP (lowest
path loss to the device), resulting in sub-optimal radio performance! This scenario is
illustrated by the figure below:

Figure 22 – Sub-optimal DL best-LRR selection due to slow backhaul (pre-TPW5.0.1)
To mitigate the drawbacks presented above, when NFR-924 is activated, the downlink best-
LRR selection algorithm is optimized as follows:
▪ For static devices (whose Motion Indicator = “Near Static”):

Instead of relying on the ESP of the last uplink frame, the optimized algorithm uses a
sliding window to compute the average ESP of each receiving gateway. After each
uplink frame, the algorithm determines the downlink best-LRR based on the ESP score
of each candidate.
The ESP score of each LRR considers several bonus/penalty margins to offer load
balancing (penalize the LRRs having high downlink Duty Cycle) and minimize MAC
configuration updates when the device switches from one RF Region configuration to
another.
Note: For downlink qualification, ESP is more representative than SNR because the
former reflects the path loss between the transmitter and the receiver without
accounting for the gateway noise.
Using an averaging window-size for static devices also mitigates the risk #2 detailed
above for slow backhaul gateway, as this LRR can still be considered for the long-term
averaging mechanism even if its uplink packets arrive outside the 250 ms deduplication
window (denoted “laggard” packets).
▪ For moving devices (motion indicator ≠ “Near Static”):

The downlink best-LRR selection remains based on the last uplink frame since the use
of sliding window does not fit in mobility. Nevertheless, to mitigate the RSSI
measurement inaccuracy reported by Semtech’s SX1301 chip for V1/V1.5 gateways for
uplink packets using SF10/11/12, the LRC relies on SNR of the last uplink frame instead
of ESP when uplink SF > 9.

For static devices, the downlink best-LRR selection consists of 3 STAGES:
A. STAGE #1: LRR ranking
For each static device, the LRC computes the following metrics over the previous
BestLRR_SlidingWindow UL packets, this table should be updated with each new UL
packet received by the LRC:
LRR ranking logic executes the following steps:

1. Candidate LRRs (present in the table above) are filtered by removing all the LRRs
where the UL PER-per-LRR exceeds:
▪ MaxLrrPER_IntraRegion threshold (RF Region parameter, default = 20%), if the

LRR belongs to the same RF Region as the current RF Region of the device,
▪ MaxLrrPER_InterRegion threshold (RF Region parameter, default = 50%), if the

LRR belongs to a different RF Region than the current RF Region of the device.
Note: MaxLrrPER_InterRegion has a higher default value than
MaxLrrPER_IntraRegion to account for potentially partial overlap of channel
definition for the 2 RF Regions.
2. The remaining LRRs are sorted by highest to lowest Adjusted_ESP, where
Adjusted_ESP is computed as:
Adjusted_ESP = Average_ESP – DC_offset – RFregion_offset + DevicePwr_delta
Where,
▪ DC_offset margin offers reasonable degree of traffic load balancing by

penalizing the LRRs having a high downlink long-term Duty Cycle (LT_DC) state:
▪ DC_offset = DC_penalty if LT_DC > HighDCThreshold, otherwise
DC_offset = 0,
▪ LT_DC is computed by aggregating downlink packet airtime of all
downlink channels over the last DC_Aggregation (default = 7 days).
Note: DC_Aggregation defines the long-term downlink Duty Cycle
aggregation period. This parameter is directly configurable on the Base
Station with LRR version >=2.2.53, in $ROOTACT/usr/etc/lrr/lrr.ini
file as following:
[lrr]
; period for long time dl dutycycle, in hours. default=24*7=168
dtcltperiod=168

▪ RFregion_offset adds a margin to minimize device switch between RF Regions:
RFregion_offset = RFRegion_Penalty if the LRR belongs to a different RF Region
than the current RF Region of the device, otherwise RFRegion_offset = 0.
▪ DevicePwr_delta = MIN (DeviceProfile.MaxPower, RFregion.MaxPower) –

Current MaxPower.
B. STAGE #2: RF Region Selection

The target RF Region (tRFRegion) of the device is the RF Region of the LRR having the
highest Adjusted_ESP (see STAGE #1). The current RF Region (cRFRegion) is the one
currently associated to the device. Based on these RF Regions:
▪ If tRF Region is different from cRF Region, the LRC reconfigures the MAC
parameters of the device to match its target RF Region.
▪ However, to address issue #2 described earlier (best-LRR issued from STAGE #1

has a slow backhaul) while ensuring that the device is successfully reconfigured
with the larger MACRxDelay1 of its target best-LRR, the LRC sends the MAC RX1
Delay setting corresponding to this LRR via another LRR whose Round Trip Time
(RTT) matches the device’s current RX1/RX2 timing.
In the example illustrated by the figure below, LRR1 is an indoor gateway, very close
to the end-device but connected to a slow backhaul (RTT > 2s); while LRR2 is a macro
gateway with Ethernet backhaul:
Figure 23 – Mitigating issue #2 by NFR-924
Once the device successfully acknowledges the RxtimingSetupReq command on the

next UL, the LRC starts routing downlink packets via the target best-LRR.

C. STAGE #3: Best-LRR Selection
The Best-LRR selected for downlink transmission is the one having the highest rank as
per STAGE #1 and belonging to cRF Region and fulfilling the following requirements:
▪ [For Class A devices only]: The last UL has been received by this LRR (this
condition is mandatory to derive the correct timestamp of DL packets).
▪ [For Class B device with DL transmission over a ping slot]: The best-LRR is GPS-
synchronized.
▪ Short-term Duty Cycle: The ST_DC (computed over the last hour by default) of
the intended RX1 and RX2 channels has not reached the limit. For more
details about short-term Duty Cycle constraints in RF Region configuration,
please refer to 0
▪
▪
▪ “RX Channel” Parameter Settings and 4.3.8 “TX Channel” Parameter Settings.
▪ LRR connection status: This LRR is in “connected” state (no loss of connection).
▪ [Passive roaming]: If the LRR belongs to a foreign operator, DLAllowed = true

on the last PRStartReq.
If no such LRR can be found in the cRF Region, the LRC chooses the next best-ranked
LRR fulfilling the requirements above regardless of its RF Region.
Feature Activation:
This feature is deactivated by default in release 5.0. It can be activated via a system-wide
parameter in lrc.ini:
[features]
ChooseLRRByOptimization=1 (1 = enabled 0 = disabled)
Note: This feature is only supported for devices operating with ADRv3 algorithm, it is not
applicable for devices using ADRv2.

3.7 Multicast for Class B & C Devices (NFR-187/NFR-1036)
Multicast is a crucial feature for downlink transmission, it allows sending the same downlink
frame to many devices at the same time. This is particularly interesting for Class B and Class C
devices acting as actuators where the application server can control many end-devices by
sending a single downlink frame - for instance, switch on/off street lamps or gas meters…etc.
Multicast feature drastically optimizes the downlink capacity and avoid overload of the air-
interface resources for many Class B and Class C use cases. Additionally, multicast is a
mandatory feature to support Firmware Upgrade Over The Air (also known as FUOTA).
How multicast works:

To support multicast, an end-device must be configured with a multicast DevAddr, multicast
NwkSKey and multicast AppSKey in addition to its unicast DevAddr/session keys.
While the unicast DevAddr/session keys are distinct for each device, the multicast
DevAddr/session keys must be the same for all the devices belonging to the same multicast
group. Therefore, a multicast group consists of a “virtual” device with a DevAddr, NwkSKey
and AppSKey.
End-devices must monitor both unicast and multicast addresses.
There are two ways to configure end-devices with the multicast group DevAddr/session keys:
1. Either via a personalized configuration hardcoded in the device stack, which is
analogous to using ABP mode for multicast, even if the device uses OTAA for unicast.
2. Or using over-the-air configuration via application-layer configuration messages, as
defined by the “Datablock multicasting protocol” specified by the LoRa Alliance
(namely McGroupSetupReq message type). For more details, please see DataBlock
Multicasting Protocol.
From ThingPark standpoint, the LRC does not know the mapping between the “virtual”
multicast device and the “real” devices associated to it. The following figure illustrates the
end-to-end downlink transmission flow:

Figure 24 – Multicast transmission flow
To support multicast, end-devices must either use class B or class C mode. Native Class-A
devices can still use multicast if they are configured by application layer to switch to class B or
C during the multicast session’s scheduling period. For more details, please refer to DataBlock
Multicasting Protocol.
Multicast Configuration: To configure multicast, a Multicast Group must be created in the

Device Manager of the subscriber, under the “Multicast groups” panel on the left sidebar.

Figure 25 – Creating Multicast Group in Device Manager
Once created, a Multicast Group must be associated to the BS-tag to determine the list of LRRs
participating to the multicast session, to which the LRC must forward the downlink frames of
the “virtual” device. This association is supported by the “Tag management” button available
in the Multicast Group view:

Figure 26 – Multicast tag management
In the screenshot above, the total number of tags associated with this Multicast Group and
the corresponding number of Base Station is indicated in the area highlighted by the red
frame.
Note: The BS-tagging consists of associating LRRs to a specific tag in Network Manager:
Figure 27 – BS-tagging in Network Manager
A Multicast Group must be associated with a multicast Connectivity Plan, that is to say the
Communication type set in the Connectivity Plan must be “Multicast”.
Figure 28 – Defining a Multicast Connectivity Plan

It is important to set an appropriate downlink packet rate in the multicast Connectivity Plan
to efficiently control the multicast radio usage while sparing enough resources to unicast
traffic in compliance to the regulatory Duty Cycle and network engineering rules.
Figure 29 – Multicast Connectivity Plan details
The following configuration parameters can be controlled in the multicast Connectivity Plan:
▪ Maximum Base Station Cells: Maximum number of Base Stations which can be added
in the scope of the multicast group.
▪ Downlink Transmission Inter Delay: Transmission delay in seconds between Base
Stations belonging to different clusters to avoid collision. The clustering algorithm is
described hereafter.
▪ Downlink Maximum Transmissions: Maximum number of times the LRC attempts to
transmit a downlink multicast frame through a Base Station that initially failed to
transmit it.
▪ Class C Collision Avoidance Distance: This parameter is used by the clustering
algorithm implemented in the LRC for class C devices (described below). It defines the
minimum distance required between two Base Stations to belong to the same cluster.
This value should be typically set to 1.5 * inter-site distance.

Note: Since TPW 5.2.2, the Downlink Retransmission Timer has been removed from the
Connectivity Plan. This parameter represents the delay in seconds between two successive
multicast retransmission attempts by the LRC. This retransmission timer is now managed
systemwide in the lrc.ini file of the LRC. Its value should depend on the multicast session scope
(that is to say, whether the multicast session serves class B or class C devices):
▪ If Class B, then multicast retransmission timer = MulticastRetxTimerClassB (60s by

default)
▪ Else (i.e. Class C) multicast retransmission timer = MulticastReTxTimerClassC (256s by
default).
MulticastRetxTimerClassB and MulticastReTxTimerClassC are configured in lrc.ini.
Downlink Packet transmission in multicast mode:

As specified by LoRaWAN, downlink multicast frames use unconfirmed mode, and do not
include any MAC commands.
Starting ThingPark 5.2.2 (RDTP-4265), two parameters are added for both Class B & C
Multicast Groups:
▪ Multicast Data Rate

▪ Multicast Frequency
Accordingly, it is possible to customize the multicast channel data rate and frequency (ping
slots for class B or RX2 for class C) directly in the Multicast Group. This enhancement allows
higher flexibility in the radio configuration of the Multicast group, allowing 2 different options
to do this configuration:
1. Either the multicast data rate and/or frequency are inherited from the RF Region
configuration (that is to say, reuse the same configuration setting as unicast downlink
transmissions) => To use this option, the Subscriber can leave Multicast Data Rate and
Multicast Frequency fields empty: the RF Region settings will apply.
Note: This option is not valid when multiple RX2 and/or multiple pingslots are
configured in the same RF Region (new feature supported in TPW release 6.0, by RDTP-
2543, see 4.3 Main RF Region Parameters for more details about this feature ).
2. Or the multicast data rate and/or frequency are personalized differently from the RF
Region configuration. To use this option, the Subscriber should set the desired
Multicast Data Rate and Multicast Frequency during the creation of the Multicast
Group.
Note: This is the only option compatible with multiple RX2/pingslot configuration in RF
Region (RDTP-2543, see 4.3 Main RF Region Parameters for more details about this
feature).

Important: Whenever the data rate and/or frequency is set in Multicast Group, it takes
precedence over the RF Region/Connectivity Plan setting. If no setting is made at Multicast
Group level, then RF Region configuration is used.
Note: The multicast frequency set in the Multicast Group must match a Logical Channel (LC)
defined in the RF Region configuration of each LRR participating to this Multicast Group; either
in the RxChannels or TxChannels section (RX2Freq is out of scope). If this condition is not
fulfilled, the LRC shall return an error (F0: “No matching channel for multicast frequency") for
every transmission related to this multicast group.
▪ Class B multicast session:

For Class B multicast, end-devices listen to the multicast address over specific pingslots
that are not necessarily the same as unicast ping slots. The multicast pingslot
periodicity is directly provisioned in the Multicast Group.
Since class B operation implies that LRRs are perfectly synchronized by GPS, a downlink
multicast frame can be safely transmitted synchronously over all the LRRs without any
risk of collision, leveraging the constructive interference effect which is already the
case for the synchronized transmission of beacon signals.
Note: In case the LRR cannot transmit the multicast frame over the programmed
pingslot, it automatically reattempts transmission over the remaining available
pingslots within the current and next beacon periods (like unicast mode) before
sending a failure indication back to the LRC.
▪ Class C multicast session:

To avoid radio collision between the different LRRs participating to the same multicast
session, the LRC applies the collision-avoidance algorithm as illustrated by the
following figure:

Figure 30 – Multicast Connectivity Plan details
o For all the LRRs that are GPS-synchronized (green gateways in the above
figure): The LRC schedules a simultaneous transmission like for class B devices
→ Perfectly synchronized transmissions (with +/- 1 µs precision) mitigate
collision risk.
o For other LRRs (not GPS-synchronized), the LRC uses a clustering algorithm to
group the LRRs that are sufficiently spaced away into the same cluster whereas
neighbor LRRs are put in different clusters. The minimum distance required
between two LRRs to share the same cluster is defined by the Connectivity Plan
parameter “Class C Collision Avoidance Distance”.
The LRC schedules multicast transmission sequentially for each cluster: all the
LRRs within the same cluster transmit their downlink multicast frames at the
same time (interference is mitigated by the distance separating those LRRs)
while the multicast transmission over distinct clusters do not overlap in time to
avoid collision. This case is illustrated by the orange gateways in the figure
above.
Note: In case the LRR location is not provisioned in ThingPark (blue gateways
in the figure above), the LRC considers each LRR as a separate cluster.
In case the first transmission scheduled by the LRC fails for some LRRs (eventually after the
LRR autonomously reattempts the transmission before giving up), the LRC shall re-attempt the
transmission of the multicast frame until the maximum number of attempts is reached. The
maximum number of attempts is configured in the multicast Connectivity Plan by the
parameter “Downlink Maximum Transmissions”.

The interval between two consecutive LRC attempts is determined by the timer configuration
in lrc.ini (set by default to 60s for class C and 256s for class C) (RDTP-4265 introduced in
TPW5.2.2).
The following figure illustrates the retransmission scheme used by the LRC for multicast
frames:
Figure 31 – Downlink retransmission initiated by the LRC
Note about LRC retransmission mechanism: (RDTP-8570): NEW

Starting release 6.0, RDTP-8570 optimizes the LRC 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.

Starting release 6.0: A new optional behavior is supported besides the existing behavior:
LRR3, LRR5 and LRR4 (in case of class B multicast session) are excluded from any subsequent
retry if they are not available during the first transmission attempt. This behavior assumes
that there are limited chances to have a status change on these base stations between the
first transmission and the following retries (the interval between 2 consecutive retries is less
than 256s) so it becomes suboptimal to increase the overall transmission time of the downlink
frame because of these base stations.
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.
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.
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.
Note on the Multicast Summary reports:

Since TPW 5.2.2 (RDTP-2215), the LRC is sending more detailed downlink reports. The goal is
to provide the distribution of LRR failure delivery causes in the multicast summary report sent
on LRC/TWA interface and LRC/AS interface.

Note: No delivery failed cause is reported if no "downlink sent" acknowledgement is received
from LRR.
List of LRC-computed failure causes applicable to multicast:
▪ DA: "Duty cycle constraint detected by LRC"
▪ DB: "Max dwell time constraint detected by the LRC"
▪ DC: "No GPS-synchronized LRR detected by the LRC"
▪ DD: "No LRR connected detected by the LRC"
List of LRR computed failure causes applicable to multicast:
▪ A0: "Radio stopped"
▪ A1: "Downlink radio stopped"
▪ A2: "Ping slot not available"
▪ A3: "Radio busy"
▪ A4: "Listen before talk"
▪ B0: "Too late for ping slot"
▪ D0: "Duty cycle constraint detected by LRR"
▪ E0: "Max delay for Class C" (60 seconds)
▪ F0: “No matching channel for multicast frequency"
On the DevEUI_multicast_summary document, the distribution of delivery failure causes is
formatted as a comma-separated list of cause/number of occurrences; example: A3=2, D0=7,
DC=3…

3.8 MAC Commands Retransmission Optimization (NFR-928)
This NFR aims at optimizing the retransmission algorithm of LoRaWAN MAC commands by
automatically blocking the transmission of MAC command requests which are not
acknowledged (at least one ACK bit set to 0 in the MAC command answer) or not replied by a
device.
Only MAC command requests sent from LRC to device are taken into account: LinkADRReq,
DutyCycleReq, RXParamSetupReq, DevStatusReq, NewChannelReq, RXTimingSetupReq,
TxParamSetupReq, DlChannelReq, PingSlotChannelReq and BeaconFreqReq.
A MAC command request sent in a DL frame is considered Acknowledged if:
▪ The next UL frame from the device contains the corresponding MAC command answer
AND
▪ All ACK bits of the MAC command answer are set to 1 (when applicable).
A MAC command request sent in a DL frame is considered Not acknowledged if:
▪ The next UL frame from the device contains the corresponding MAC command answer
AND
▪ At least one ACK bit of the MAC command answer is set to 0.
If the command is not acknowledged by the device after M attempts, the LRC applies a
learning logic to memorize the rejected configuration settings and avoid proposing the same
configuration again to the same device. A MAC command is blocked only after M successive
identical MAC commands, it is based on successive answers (rejections) of the same MAC
command by the device.
Notes:
▪ M corresponds to MaxMacTransmitNotAcked, see 4.3.12 MAC Commands
Retransmission parameters.
▪ The MAC commands NewChannelReq and DlChannelReq are not retransmitted by the
LRC if they are rejected (not acked), regardless of the value of M.
If a value has been rejected M times, then this value within the MAC command (for instance
ChMask in LinkADRReq) is blocked by the LRC for this device, that is to say, the LRC shall not
send a command asking for this value already blocked for this device. Note that the command
type is not blocked, only the rejected values are blocked so the command can be transmitted
with other values, to not block the whole command type.

A MAC command request sent in a DL frame is considered Not replied if the next UL frame
from the device does NOT contain the corresponding MAC command answer.
If a command is not answered/replied by the device after N attempts, it becomes “blocked”
during a configurable back-off condition. This back-off condition is either duration-driven or
determined by a minimum number of uplink frames to be elapsed after the command enters
the “blocked” state before the device becomes eligible again to this MAC command. The MAC
command is unblocked as soon as at least one of the two back-off conditions is reached.
Notes:
▪ N corresponds to “MaxMacTransmitNotReplied”, see 4.3.12 MAC Commands
Retransmission parameters.
▪ The duration-based back-off is configured by the RFRegion the parameter
“MacBackoffDelay”, see 4.3.12 MAC Commands Retransmission parameters.
▪ The frame-counter based back-off is configured by the RFRegion parameter
“MacBackoffFCntUp”, see 4.3.12 MAC Commands Retransmission parameters.
This feature can be activated by setting the MACRetransmission parameter to 1 in the lrc.ini
file on the LRC:
[features]
MACRetransmission=1
New device alarms are reported to Device Manager application to alert about MAC
command blocking:
▪ 012: MAC command transmission blocked because of rejection.
▪ 013: MAC command transmission blocked because of no reply.

4 RF REGION CONCEPT
To ease the optimization of the main ThingPark radio parameters, the RF Region concept is
introduced in ThingPark Wireless.
Indeed, to fully leverage the ThingPark macro diversity gain and efficiently support device
mobility while minimizing the amount of DL MAC commands, most optimization parameters
should be tuned over a wide geographical area rather than at base station level.
Several RF Regions can be defined in the network, each RF Region typically covering a
continuous geographical area.
Each base station (LRR) is associated with a given RF Region. All base stations sharing the same
RF Region shall have the same set of configuration parameters.
Actility recommends avoiding as much as possible overlapping between distinct RF Regions,
as well as setting the boundaries of each RF Region in a way to minimize the border effect.
Important
Since most of the configuration parameters included in the RF Region are conveyed to
end-devices via MAC command, it is strongly recommended to minimize the update of
these parameters to avoid huge impact on downlink induced by unicast reconfiguration
messages when there are millions of devices in the network!
A better practice to keep a good level of control on such RF Region reconfiguration is to

configure a new RF Region, then to progressively migrate LRRs to the new RF Region, after
proper planning with end customers for potential temporary service disruption due to
saturation of downlink capacity.
4.1 RF Region Configuration/Provisioning in ThingPark Wireless
The RF Region configuration consists of a configuration file gathering all the radio parameters
detailed in 4.3 Main RF Region Parameters. On the LRC side, this file is located under
/home/actility/FDB_lora/RFRegion/ and its name must be the same as the XML tag
element RFRegionId inside the file.
Starting TPW release 5.1, the RF Region configuration/provisioning is drastically simplified to
improve operability, thanks to the RF Region catalog feature (RDTP-3365).
Prior to release 5.1, RF Region management by the network operator had to go through the
following steps:

1. To create or update an RF Region configuration file, the network operator had to
connect to the LRC to manually create/update the file under
/home/actility/FDB_lora/RFRegion.
2. Then, call a specific script known as rfregtool to generate the LRR configuration files
(also known as tarballs) for each RF Region configuration. The tarballs are lgw.ini and
channels.ini files in compressed format.
3. Finally, the operator/network provider associates a base station with a given RF Region
configuration via TWA Network Manager application. This association pushes the
lgw.ini and channels.ini files to the base station in question and allows the LRC to know
which set of radio parameters are used for this base station.
Release 5.1 drastically simplifies this RF Region management process:
▪ Step #1 above becomes fully manageable from Operator Manager application:

o The network operator has access to Actility’s default RF Region catalog, it can
regularly update to the latest version (via Actility repository).
o Moreover, the network operator can create its own RF Region configurations from
“Operator Manager” GUI. Hence, each operator can maintain a list of custom RF
Regions to complement the default RF Regions supplied in Actility catalog.
▪ Step #2 above becomes transparent to the operator, as the RF Region provisioning is

entirely managed by TWA that provisions the RF Region files into the LRC and execute
rfregtool scripts.
▪ Step #3 (LRR association with a given RF Region) becomes simpler: instead of entering
the RFRegionID in Network Manager GUI, the operator/network provider can select
the target RF Region from a drop-down list – so this step becomes less prone to human
errors/typing mistakes.
With RDTP-3365, the Operator can perform the following tasks from Operator Manager
application:
▪ In “RF Regions” panel, the operator can manage its RF Regions: i.e. search, create,
update and delete an RF Region. Note that default RF Regions (from catalog) cannot
be edited but can be cloned by the operator for subsequent update. For more details,
please refer to 4.1.1 RF Region creation/update via Operator Manager Application.
▪ In “Catalogs” panel, the operator can manage the RF Region catalog. Two update
methods are supported: automatic and manual.

4.1.1 RF Region creation/update via Operator Manager Application
From the Operator Manager Application, the ThingPark Operator can manage its RF Regions,
under the “RF Regions” panel – as shown by the following figure:
Figure 32 – RF Regions tab under Operator Manager application
The “Create” button is used to create a new RF Region. A newly created RF Region is
automatically assigned version = 0.
The following actions are supported for RF Regions coming from the catalog: view, delete and
clone. The operator can use clone to duplicate an RF Region so that it can edit its content.
Only RF Regions not coming from the catalog can be directly edited. When an RF Region is
edited, its version is auto-incremented by TWA. The changelog space allows the operator to
add a descriptive text about the changes brought by this new version.
Note: When creating/updating RF Regions from Operator Manager application > “RF Regions”
panel, The XML description field is pre-filled with the following lines:
<?xml version="1.0" encoding="UTF-8"?>
<RFRegion xmlns="http://uri.actility.com/lora"
xmlns:lora="http://uri.actility.com/lora">
<RFRegionId>${rfRegion.provID}</RFRegionId>
<RFRegionVersion>${rfRegion.version}</RFRegionVersion>
<ISMband>${rfRegion.ismBand}</ISMband>
</RFRegion>

The three lines highlighted in yellow above in the in the “XML description” space must be
left unchanged: RFRegionID (corresponds to “ID” field at the top of the form),
RFRegionVersion and ISMband are variables auto-configured by TWA.
Additionally, two possible XML encoding rules are supported: with or without “lora” name
prefix. The right namespace must be defined by the xmlns attribute in the RF Region tag.
▪ With lora name prefix:

<lora:RFRegion xmlns:lora="http://uri.actility.com/lora">
<lora:RFRegionId>${rfRegion.provID}</lora:RFRegionId>
<lora:RFRegionVersion>${rfRegion.version}</lora:RFRegionVersion>
<lora:ISMband>${rfRegion.ismBand}</lora:ISMband>
…
</lora:RFRegion>
▪ Without lora name prefix:

<RFRegion xmlns="http://uri.actility.com/lora">
…
</RFRegion>
Note: In TPW release 5.1, when creating or modifying an RF Region, TWA only checks the XML
validity (if the XML is properly formatted or not). Since TPW release 5.2.2 (RDTP-4587), TWA
also checks the XML content to validate the syntax of each line. Note that this validation is
limited to the syntax of the XML content, it does not validate the technical configuration of
the RF Region itself. In other words, if the Operator sets an RF channel with a frequency
outside the authorized range, it will still be accepted by the Operator Manager as long as the
XML syntax is correct.
4.1.2 RF Region Catalog Management

The Operator can manage the RF Region catalog from the “Catalogs” panel under the Operator
Manager application. Like the Base Station profile and Device Profile catalogs, two modes are
supported for RF Region catalog management: automatic and manual.
4.1.2.1 Automatic Mode

The Auto mode allows the operator to access Actility’s catalog (available in Actility repository
at https://repository-saas.thingpark.com) and update it from the GUI as illustrated by the
following figure. While this mode allows the operator to leverage the latest version of Actility’s
default catalog, it also allows the operator to create custom RF Regions to complement
Actility’s default ones, as described in 4.1.1 RF Region creation/update via Operator Manager
Application.
Figure 33 – RF Region catalog – Auto update mode
When a new version of the catalog is available at Actility repository, the operator is notified
by a GUI message and hence can proceed to updating his catalog to the latest version by
clicking the “Update” button.
Otherwise, if the installed catalog version is the latest one, the GUI displays "Your catalog is
up-to-date".
The following RF Regions are included in the last default catalog version 1.1.0 (available on
Actility repository):
ISM Band Applicable countries RF Region ID
(2-digits ISO country code)
eu868 AE, AL, AD, AT, BE, BA, BG, CY, CZ, EU868_8channels
DE, DK, ES, EE, FR, FI, GB, HU, NL, EU868_16Channels
HR, IT, IE, IR, IS, LB, LI, LT, LU, LV,
MD, MK, MT, ME, PL, OM, PT, RO,
RS, CH, SA, SK, SI, TR, ZA
RU (kept for backward EU868_Russia_7channels
compatibility) EU868_Russia_12channels
MA EU868_Morocco
eu433 AD, AE, AL, AM, AT, AZ, BA, BD, BE, EU433
BG, BN, BY, CU, CY, CZ, DE, DK, DZ,
EE, EG, ES, FR, FI, GB, GR, HK, HU,
NL, HR, IE, IL, IR, IS, IT, KW, KZ, LB,
LI, LK, LT, LU, LV, MA, MD, ME, MK,
MM, MT, MY, NO, NZ, OM, PH, PL,
PT, PY, QA, RO, RS, CH, SA, SG, SK,
SI, TH, TN, TR, UA, UG, UZ, ZA
us915 AR, CA, CL, CO, EC, GT, JM, NI, NX, US915_First8channels
PA, US, UY US915_8channels_Block2
US915_8channels_Block3
US915_16channels
US915_72channels
as923 JP AS923_Japan_20mW_8channels
AS923_Japan_250mW_8channels
HK, TW AS923_Taiwan_16channels
AU, BN, BO, CR, EC, MY, NZ, PA, AS923_8channels_922_924
PE, PY, SG, SV, TH, UY
AU, BN, BO, CR, EC, ID, KH, LA, NZ, AS923_8channels_923_925
PA, PE, PY, SG, SV, TH, UG, UY
AU, BN, BO, CR, EC, MY, NZ, PA, AS923_16channels_921_925
PE, PY, SG, SV, TH, UY
BO, NZ, PA, SV, UY AS923_8AsymChannels_4W
AS923_NewZealand_8channels
AS923_NewZealand_16channels
AU, CR, EC, PE AS923_8AsymChannels_1W
AS923_Australia_8channels
AS923_Australia_16channels
au915 AU, BO, CL, DO, EC, GT, NZ, PA, PE, AU915_First8channels
PG, PY, SV, UY AU915_8channels_Block2
AU915_8channels_Block3

AU915_16channels
AU915_72channels
kr920 KR KR920_7SymChannels
cn779 CN CN779_8channels
cn470 CN CN470_First8channels
in865 IN IN865_8channels
ru864 RU RU864_Russia_7channels
RU864_Russia_12channels
4.1.2.2 Manual Mode

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

Figure 34 – RF Region catalog - Manual update mode
The operator can browse its local directories to upload the custom catalog. Versioning of the
custom catalog remains at the Operator’s responsibility.
To create the custom catalog package, the Operator has the following rules:
▪ The RF Regions catalog package is a tgz tarball containing the following files:
Filename Description
ref-<tpwVersion>-rf-regions-TEMPLATE- Filled RF Regions catalog TEMPLATE (1)
<rev>.xlsm (MANDATORY)
rf-regions.csv (MANDATORY) CSV export of the filled RF Regions catalog
TEMPLATE
change-log-rf-regions.txt (OPTIONAL) Change Log of the RF Regions catalog package
xml/rfregions/<rfRegionID>.xml RF Region XML description (2)
(MANDATORY) 1 XML file per XML description referred in the
RF Regions catalog TEMPLATE
logo/rfregions/<rfRegionLogo>.png RF Region PNG logo
(OPTIONAL) Maximum size: 150 x 150
1 PNG file per logo referred in the RF Regions
catalog TEMPLATE

(1)
Each RF Region is versioned in RF Regions catalog; the version number is used to notify the
end-user that the RF Region must be reloaded by the Base Station. RF Region versioning must
be handled as follows:
▪ If the RF Region update is a bug fix:

o If the RF Region update impacts the Base Station (for instance, the RF channels
or the TX Power): it is recommended to increment the version so that the
Network Manager administrator can be notified that the RF Region needs to be
reloaded by the Base Station.
o Else: no need to increment the version if the RF Region does not need to be
reloaded by the Base Station.
▪ Else: a new RF Region must be created → a new RF Region must be created to avoid
any impact on Base Stations already using the RF Region.
(2)The XML description must follow the same rules described in 4.1.1 RF Region
creation/update via Operator Manager Application.
In case you need Actility’s support to build your custom RF Region package, please contact
Actility Support team.
4.2 Associating a Base Station with an RF Region Configuration
Starting release 5.1 (RDTP-3365), to associate a Base Station with an RF Region, the user shall
select the target RF Region from a drop-down list provided in Network Manager under the
Administration panel > “Configuration” section as illustrated by the following figure:
1. Log on with the network partner in TWA and go to the Network Manager.
2. Select the LRR you want to configure for edition and go to the Administration panel.
3. In “Configuration”, click Update and select the RF Region you want to use.

Figure 35 – Setting the RF Region ID in Network Manager
Note: If a new version is available for the same RF Region (for instance, the Base Station is
currently associated with version 0 while version 1 is already available for this same RF Region
(e.g. to correct a bug)), then the GUI will display a message "A new version is available".
Migration note:
Existing RF Regions deployed on LRC before the migration to release 5.1 are NOT
automatically imported in TWA. Only RF Regions imported from RF Region catalog or
created through Operator Manager after the migration are directly available on TWA.
Hence, the Operator should manually create their RF Regions in TWA Operator Manager (or
upload them via a custom catalog – using the manual mode) for them to be visible in TWA
Network Manager application.
The following hardware configurations are fully supported by ThingPark in the current release:
▪ For V1 gateways (based on Semtech’s V1 reference design):

o 1 sector, 1 antenna, 1 board (mono-sector 1*8): s1_a1_b1
▪ For V2/V3 gateways (based on Semtech’s V2 reference design):

o 1 sector, 1 antenna, 1 board (mono-sector 1*8 or 1*16): s1_a1_b1

o 1 sector, 2 antennas, 1 board (mono-sector 2*8): s1_a2_b1 → Antenna
Diversity enabled
o 1 sector, 2 antennas, 2 boards (mono-sector 2*16): s1_a2_b2 → Antenna
Diversity enabled
o 1 sector, 1 antennas, 4 boards (mono-sector 1*64): s1_a1_b4
o 3 sectors, 3 antennas, 3 boards (tri-sectors 1*8 or 1*16): s3_a3_b3
Note: sX_aY_bZ_vN stands for X sectors / Y antennas / Z boards and N hardware format.
To download the right LRR configuration matching the Base Station hardware, the hardware
configuration of each LRR should be set in the Network Manager GUI > “Antennas” tab, as
follows:
Figure 36 – Hardware configuration setting in Network Manager
Please note that the options proposed by the drop-down list depend on the Base Station
Profile configured for each LRR.
The Base Station Profile indicates the maximum allowed hardware configuration. For example,
for a Kerlink iBTS gateway with 2 radio boards and 2 antennas physically cabled to the
gateway, the Base Station Profile shall be configured to s1_a2_b2 “1 sector, 2 antennas, 2
boards”, then each LRR can be individually configured to either s1_a1_b1, s1_a2_b1 or
s1_a2_b2.
4.3 Main RF Region Parameters
All the configurable parameters per RF Region are included in an XML file. The following figure
shows an example of the RF Region configuration file for EU868 deployment.
Note: To insert any comments to the RF Region XML file, precede your comment by  (as per the blue text shown in the XML template below):
<RFRegion xmlns="http://uri.actility.com/lora">


<MACRxDelay1>1000</MACRxDelay1>
<RX1DRoffset>2</RX1DRoffset>
<RX2DataRate>3</RX2DataRate>
<RX2TxPower>29</RX2TxPower>
<RX2Freq>869.525</RX2Freq>

<RX2SB>3</RX2SB>
<RX2DTC>10</RX2DTC>


<MaxDutyCycle>0</MaxDutyCycle>
<MaxPower>14</MaxPower>
<MinPower>2</MinPower>
<MaxEIRP>16</MaxEIRP>
<MinEIRP>2</MinEIRP>
<ChMask>FF</ChMask>


<Redundancy>1</Redundancy>
<margin_db>10.0</margin_db>


<Target_PER>0.1</Target_PER>
<Macro_Div_Reliab>0.8</Macro_Div_Reliab>
<MinimumAntennaDiversity>1</MinimumAntennaDiversity>
<REP_Min>1</REP_Min>
<REP_Max>3</REP_Max>
<SFmin>7</SFmin>
<SFmax>12</SFmax>
<WindowSize_SNR>50</WindowSize_SNR>
<Initial_WindowSize>10</Initial_WindowSize>
<Initial_WindowSize_Boot>5</Initial_WindowSize_Boot>
<Initial_WindowSize_Optim>25</Initial_WindowSize_Optim>
<Forgetting_Factor>0.15</Forgetting_Factor>
<Forgetting_Factor_Overlap>0.05</Forgetting_Factor_Overlap>
<Hyst_PER>0.05</Hyst_PER>
<Hyst_Overlap>0.05</Hyst_Overlap>
<Hyst_SNR>1</Hyst_SNR>
<Margin_Slope>2</Margin_Slope>


<margin_uplink>12.0</margin_uplink>
<SF_limit>9</SF_limit>


<SNR_limit_SF7>-7.0</SNR_limit_SF7>


<LRR_power>16</LRR_power>
<RadioCenterFrequency>866.5</RadioCenterFrequency>


<ClassBEnabled>1</ClassBEnabled>
<BeaconPeriod>128</BeaconPeriod>
<BeaconRandomization>100</BeaconRandomization>
<RedundancyDeduplicationTimer>3600</RedundancyDeduplicationTimer>


<RxChannels>
<RxChannel>
<ChIndex>0</ChIndex>
<IsDefault>1</IsDefault>
<LC>1</LC>

<Frequency>868.1</Frequency>
<SB>1</SB>
<DTC>1</DTC>
<MinDR>0</MinDR>
<MaxDR>5</MaxDR>
</RxChannel>
<RxChannel>
<LC>2</LC>
<SB>1</SB>
<DTC>1</DTC>
<MinDR>0</MinDR>
<MaxDR>5</MaxDR>
</RxChannel>
<RxChannel>
<LC>3</LC>
<SB>1</SB>
<DTC>1</DTC>
<MinDR>0</MinDR>
<MaxDR>5</MaxDR>
</RxChannel>
<RxChannel>
<LC>4</LC>
<SB>2</SB>
<DTC>1</DTC>
<MinDR>0</MinDR>
<MaxDR>5</MaxDR>
<LRR_power>+1</LRR_power>
</RxChannel>
<RxChannel>
<LC>5</LC>
<SB>2</SB>
<DTC>1</DTC>
<MinDR>0</MinDR>
<MaxDR>5</MaxDR>
</RxChannel>
<RxChannel>
<LC>6</LC>
<SB>2</SB>
<DTC>1</DTC>
<MinDR>0</MinDR>
<MaxDR>5</MaxDR>
</RxChannel>
<RxChannel>
<LC>7</LC>
<SB>2</SB>
<DTC>1</DTC>
<MinDR>0</MinDR>

<MaxDR>5</MaxDR>
</RxChannel>
<RxChannel>
<LC>8</LC>
<SB>2</SB>
<DTC>1</DTC>
<MinDR>0</MinDR>
<MaxDR>5</MaxDR>
</RxChannel>
</RxChannels>
<TxChannels>
<TxChannel>
<LC>253</LC>
<UsedForBeacon>1</UsedForBeacon>
<SB>3</SB>
<DTC>10</DTC>
<MaxDR>3</MaxDR>
</TxChannel>
<TxChannel>
<LC>254</LC>
<UsedForPingSlot>1</UsedForPingSlot>
<SB>3</SB>
<DTC>10</DTC>
<MaxDR>3</MaxDR>
</TxChannel>
</TxChannels>
</RFRegion>
Figure 37 – Example of RF Region configuration file (EU868 8-channels)
Configuring RX2 and pingslot in RF Region:

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.
Note: The RX2 channel can be different from pingslot channel.
Starting release 6.0 (NEW – RDTP-2543) it is possible de 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.
Note: Each device has only one RX2 channel i.e. the same device cannot use several RX2
(forbidden by LoRaWAN specification). Nevertheless, the same class B device may use several
pingslots if pingslot frequency hopping is enabled (only valid for US915, AU915 and China
CN470 ISM bands).

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.
▪ 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> 
<LC>127</LC> 
<SB>3</SB> 
<DTC>10.0</DTC> 
<Frequency>922.6</Frequency> 
<MaxDR>3</MaxDR> 
</TxChannel>
<TxChannel>
<UsedForRX2>1</UsedForRX2> 
<LC>128</LC> 
<SB>3</SB> 
<DTC>10.0</DTC> 
<Frequency>922.8</Frequency> 
<MaxDR>3</MaxDR> 
</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> 
<LC>129</LC> 
<SB>3</SB> 
<DTC>10.0</DTC> 
<Frequency>923.2</Frequency> 
<MaxDR>5</MaxDR> 
</TxChannel>
<TxChannel>
<UsedForPingSlot>1</UsedForPingSlot> 
<LC>130</LC> 
<SB>3</SB> 
<DTC>10.0</DTC> 
<Frequency>923.4</Frequency> 
<MaxDR>4</MaxDR> 
</TxChannel>
…
</TxChannels>

Notes:
▪ To maintain backward compatibility with RF Regions created before release 6.0, the
RX2 parameters for mono-RX2 configurations remain read from the attributes
RX2DataRate, RX2TxPower, RX2Freq, RX2DTC, and RX2SB. For more details about
these parameters, please refer to 4.3.2 RX1/RX2 Parameter Settings.
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.
▪ To support this feature, the minimum LRR version is 2.4.12.
▪ 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.
4.3.1 TX Power Parameter Settings

Parameter name “LRR_power”
Parameter The Power setting for each Logical Channel is computed based on the
description global parameter LRR_power + an optional Channel Offset (preceded
by + or – sign) defined separately for each Logical Channel in
<lora:RxChannel> section.
Accordingly, if the global parameter LRR_power = 16 dBm, and the
parameter LRR_power for LC4 = +1 → Overall LRR_power for LC4 = 17
dBm
Unit dBm for global parameter, dB for Channel Offset
Default setting 16
Recommended 16 for global parameter in EU868 band, 36 for US915 band.
setting To be configured according to max allowed EIRP for other countries.
Range [-10…36]

Additional Note that the real LRR conducted TX Power = LRR_power + Channel
comments Offset - Gain, potentially rounded down to match authorized calibrated
power levels.
“Gain” actually refers to the LRR antenna gain - cable losses, it is
configurable in custom.ini file and can be automatically set by Actility's
BS-Commissioning tool (for more details, please refer to [BS-
Commissioning]).
Note for EU868: With V1.5 gateways, LRR_power = +1 by default for
Logical Channels configured at 866…867 MHz frequencies (that is to
say, 1 dB offset) in order to compensate the additional SAW filter’s
insertion loss at these frequencies compared to 868 MHz (the insertion
loss at 868 MHz is already compensated by the PA during gateway
calibration). This 1 dB power offset is not needed for V2 gateways since
the SAW filter covers the whole 863-870 MHz band.
Parameter name “RX2TxPower”

Parameter This parameter defines the TX Power for downlink RX2 slot. It can be
description either set as an absolute TX Power level, or as an offset applied on top
of LRR_power global parameter setting (preceded by + or - sign).
This parameter is only valid for mono-RX2 configurations.
Unit dB (if set as an offset), dBm (if set as an absolute power level)
Default setting 29 (that is to say, 29 dBm).
Recommended To be optimized according to the max allowed gateway TX Power
setting (hardware limit) as well as the maximum radiated power limit imposed
by the local regulations.
Range [0…36 dBm] if set as an absolute power level
Additional CEPT regulations allow up to 29.15 dBm EIRP in EU at 869.525 MHz,
comments please refer to CEPT ERC Recommendation 70-03 for more details.
Note for EU868: If the RF Region contains gateways using V1.0
reference design supporting only 20 dBm, this parameter should be set
in such a way that the total TX Power does not exceed 20 dBm.

4.3.2 RX1/RX2 Parameter Settings
Figure 38 – RX1/RX2 timing
Parameter name “MACRxDelay1”

Parameter This parameter defines the delay between the end of the uplink packet
description transmission and the start of the downlink RX1 slot.
This parameter corresponds to “RECEIVE_DELAY1” in LoRaWAN™
specifications v1.0.2.
Unit milliseconds
Default setting 1000
Recommended See additional comments
setting
Range [1000…15000]
Additional For Ethernet backhaul, this parameter can be set to 1000 ms since the
comments LRR-LRC round-trip delay is always below 750 ms.
For cellular backhaul over 2G/3G/4G, this parameter should be set
according to worst case round trip delay measurements + 250 ms
(representing the LRC retention window needed for uplink packet
deduplication) + a few ms to account for the internal LRC processing
delay.
Parameter name “MACRxDelay2”

Parameter This parameter defines the delay between the end of the uplink packet
description transmission and the start of the downlink RX2 slot.
This parameter corresponds to “RECEIVE_DELAY2” in LoRaWAN™
specifications v1.0.2.
Unit milliseconds

Recommended Should be set to MACRxDelay1 + 1000
setting
Range [2000…16000]
Additional As indicated by LoRaWAN™ specifications v1.0.2, the second reception
comments slot opens one second after the first reception slot.
Parameter name “RX1DRoffset”

Parameter This parameter defines the offset to be applied between the uplink
description data rate and the downlink RX1 data rate, it corresponds to
“RX1DROffset” in LoRaWAN™ specifications v1.0.2: RX1 Data Rate =
Uplink Data Rate + RX1DRoffset.
For scenarios where UL and DL paths are symmetric, this offset could
be set to 0 (that is to say, the same data rate/Spreading Factor for UL
and DL RX1).
However, for asymmetric channels where downlink path is more
limiting that uplink for RX1 slot (typical scenario for EU countries), this
parameter allows compensating the link imbalance and boosting
downlink coverage by selecting a more robust (but slower) data rate
for RX1 slot compared to UL data rate.
Unit N/A
Default setting 0
Recommended To be set by the operator based on the link imbalance between UL and
setting DL.
Range [0…5]
Additional UL and DL paths can be potentially asymmetric due to the following
comments factors:
▪ Noise Rise difference between end-device and gateway.

▪ EIRP difference between end-device and gateway (depending on
effective end-device TX Power settings and EIRP regulatory limits).
▪ RX sensitivity difference between end-device and gateway, due to the
noise figure difference (3-4 dB for gateways vs. 6-7 dB for end-
devices).
▪ RX antenna gain difference between end-device (0 or negative
antenna gain) and the gateway (>= 3 dBi).

▪ Uplink Macro Diversity Gain, which mitigates fading effects for uplink
(since device packets can be potentially recovered by another
gateway when the nearest gateway is in fading hole). This gain does
not apply to downlink since only one gateway sends the packet to the
device.
This offset can be assessed by ThingPark Air Interface Dimensioning
Tool (please see ThingPark Wireless Air Interface Dimensioning tool).
Parameter name “RX2DataRate”

Parameter This parameter defines the data rate for downlink RX2 slot, it
description corresponds to “RX2DataRate” in LoRaWAN™ specifications v1.0.2.
Unit N/A
Default setting 3 (= SF9 for EU868)
Recommended To be optimized by the operator to trade off downlink coverage and
setting capacity.
Range [0…13]. SF12 corresponds to 0 for EU868 band, and 8 for US915 band.
Additional SF9 is used by default in EU868 to boost downlink capacity.
comments Note: If RX2 data rate is set in Connectivity Plan, it has the precedence
over the RX2 data rate defined in RF Region.
Parameter name “RX2Freq”

Parameter This parameter defines the frequency of downlink RX2 slot, it
description corresponds to the Frequency field of “RX2ParamSetupReq” MAC
command.
Unit MHz
Default setting 869.525
Recommended 869.525 for EU868. To be tuned for other bands depending on
setting spectrum analysis.
Range EU868: [863.1…869.9]

US915 &AU915: {923.3, 923.9, 924.5, 925.1, 925.7, 926.3, 926.9 and
927.5}
Additional Choosing 868.525 MHz for RX2 in EU868 allows transmitting with up to
comments 29.15 dBm EIRP; please refer to CEPT ERC Recommendation 70-03 for
more details.
Parameter name “RX2SB”

Parameter This parameter defines the Sub-Band of the RX2 channel, used for per
description Sub-Band Duty Cycle inspection.
Unit N/A
Default setting 3
Recommended 3 for EU868
setting N/A for US915
Range No specific range limitation
Additional RX2 Sub-Band is also displayed by Wireless Logger.
comments
Parameter name “RX2DTC”

Parameter This parameter defines the maximum allowed TX Duty Cycle of RX2
description channel.
Unit %
Default setting 10%
Recommended 10% for EU868
setting N/A for US915
Range [0…100]

Additional RX2 Duty Cycle limitation is also taken into account in best-LRR
comments selection for downlink packet routing.
4.3.3 End-Device Parameter Settings

Parameter name “MaxDutyCycle”
Parameter This parameter defines the maximum end-device TX Duty Cycle, it
description corresponds to the “MaxDCycle” field of “DutyCycleReq” MAC
command in LoRaWAN™ specifications v1.0.2.
Note that the maximum end-device Duty Cycle is defined as 1 /
(2MaxDutyCycle).
Unit N/A
Default setting 0
Recommended To be set by operator.
setting
Range [0…15]
Additional The value 0 corresponds to no Duty Cycle limitation except the one set
comments by the device.
Parameter name “MaxPower”

Parameter [ADR V2/V3]: This parameter defines the maximum allowed end-
description device conducted TX Power (excluding the end-device antenna gain).
The effective max TX Power of the device is computed by the LRC as
the minimum value between this parameter and the Device Profile
parameter “Max TX Conducted Power”.
Unit dBm
Default setting 14
Recommended 14 dBm in EU (to comply with worst case device capabilities)
setting
Range [2…20] in EU, [10…30] in US
Additional Note: Depending on the LoRaWAN™ regional parameter revision
comments provisioned in the Device Profile, the LRC considers either MaxPower
or MaxEIRP for TX Power encoding.

Parameter name “MinPower”
Parameter [ADR V3]: This parameter defines the minimum allowed end-device
description conducted TX Power. The effective min TX Power of the device is
computed by the LRC as the maximum value between this parameter
and the Device Profile parameter “Min TX Conducted Power”.
Unit dBm
Default setting 2
Recommended To be optimized by the operator according to end-device hardware
setting capabilities.
Range [2…20] in EU, [10…30] in US
Additional This parameter is not used by ADR V2.
comments Note: Depending on the LoRaWAN™ regional parameter revision
provisioned in the Device Profile, the LRC considers either MinPower
or MinEIRP for TX Power encoding.
Parameter name “MaxEIRP”

Parameter This parameter defines the maximum end-device radiated power
description (EIRP) allowed by the local regulations.
The max end-device radiated power allowed by the device hardware
shall be set in the Device Profile through the field “Max TX EIRP”.
The effective Max EIRP for each device is the minimum between RF
Region setting and Device Profile setting. This value is used by ADR
algorithms, it is also used to derive the MaxEIRP field of the
“TxParamSetupReq” MAC command.
Unit dBm
Default setting 14
Recommended To be set according to the maximum allowed EIRP of the local
setting regulation.
Range [8…36]
comments provisioned in the Device Profile, the LRC considers either MaxPower
or MaxEIRP for TX Power encoding.
Parameter name “MinEIRP”

Parameter This parameter defines the minimum end-device radiated power
description (EIRP).
The min end-device radiated power allowed by the device hardware
shall be set in the Device Profile through the field “Min TX EIRP”.
The effective Min EIRP for each device is the maximum between RF
Region setting and Device Profile setting. This value is used by ADR V3
algorithm.
Unit dBm
Default setting 2
Recommended To be optimized by the operator according to end-device hardware
setting capabilities.
Range [2…36]
comments provisioned in the Device Profile, the LRC considers either MinPower
or MinEIRP for TX Power encoding.
Parameter name “ChMask”

Parameter This parameter allows activating/deactivating individual LoRaWAN™
description Logical Channels, it corresponds to “ChMask” field in “LinkADRReq”
MAC command.
This Channel Mask is very useful when the network operator needs to
deactivate a noisy channel to progressively inhibit its use by end-
devices before being completely deleted from the channels list.
Note that any noisy channel that is candidate for deletion should be
first deactivated by setting the appropriate channel mask for a
sufficiently long duration (possibly up to 1-2 weeks depending on the
end-device density and their transmission periodicity), in order to be
sure that all end-device are notified by MAC commands. Once it is sure
that noisy channel is not in use anymore by any device, the operator
can proceed to deleting this noisy channel or possibly replacing by a
cleaner one. This replacement procedure is done by updating the “RX
Channel” configuration in RF Region file.
Unit N/A
Default setting 7, meaning only LC1/LC2/LC3 (the 3 mandatory channels in EU) are
activated by default.
Recommended To be optimized based on the operator strategy.
setting

Range [000000000000000000…FFFFFFFFFFFFFFFFFFFF], supporting up to 96
channels.
Additional Channel Mask is set in hexadecimal, it is then converted by the LRC into
comments binary to derive which channels are activated (bit = 1) and which are
deactivated (bit = 0). Note that the least significant bit refers to LC1
(and LC0 in US915).
Note: For EU868 & ETSI-style channel plans, it is possible to deactivate
the default channels by setting the appropriate channel mask, however
the default channels cannot be deleted from the channel list.
When the Channel Mask is forced in the Connectivity Plan, it takes the
precedence over RF Region setting.
4.3.4 ADR Parameter Settings

Parameter name “margin_db”
Parameter [ADR V2]: This parameter defines the SNR margin to be applied on top
description of the median SNR to account for SNR variation in the computation of
the target Spreading Factor by ADR algorithm.
Unit dB
Default setting 10
Recommended To be optimized by the operator based on the target Packet Error Rate
setting and the degree of macro-diversity.
Range [0…30]
Additional For more details related to the interaction between this parameter and
comments ADR algorithm, please refer to 3.1 Adaptive Data Rate.
Parameter name “Redundancy”

Parameter [ADR V2]: This parameter defines the number of transmissions of
description uplink packets in Unconfirmed mode, corresponding to the “NbTrans”
field in LoRaWAN™ specifications v1.0.2.
Unit N/A
Default setting 1
Recommended To be optimized by the operator based on the target Packet Error Rate
setting and the degree of macro-diversity.
Range [0…10]

Additional This parameter is not applicable to ADR V3.
comments
Parameter name “EstimationSlidingWindow”

Parameter [ADR V2]: This parameter defines sliding window size used in
description computation of median SNR for ADR (for more details, please refer to
3.1 Adaptive Data Rate).
Note that the effective size of the sliding window corresponds to:
EstimationSlidingWindow * MinimumAntennaDiversity
Unit N/A
Default setting 10
Recommended To be optimized by the operator to ensure non-volatility of ADR
setting decisions.
Range [1…30]
Additional This parameter has been deprecated since TPW 3.2.2 and is replaced
comments by WindowSize_SNR.
Parameter name “WindowSize_SNR”

Parameter [ADR V2/V3]: This parameter defines the sliding window size used for
description SNR distribution for both ADR V2 and V3.
Unit N/A
Default setting 50
Recommended To be optimized by the operator to ensure non-volatility of ADR
setting decisions.
Range [1…100]
Additional If this parameter is present in the RF Region configuration file, its value
comments replaces the old parameter EstimationSlidingWindow previously used
for ADR V2.
Parameter name “MinimumAntennaDiversity”

Parameter [ADR V2/V3]: This parameter defines the minimum required number
description of gateways simultaneously receiving the device packets and providing
a fine timestamp.

Unit N/A
Default setting 1
Recommended 1. Specific tuning should be performed at Connectivity Plan level via the
setting field “Minimum Macro Diversity” (for instance, to support
geolocation).
Range [1…30]
Additional Connectivity Plan setting "Minimum Macro Diversity" takes the
comments precedence over RF Region setting.
Parameter name “Target_PER”

Parameter [ADR V3]: This parameter defines the target uplink packet error rate
description for ADR V3.
Unit N/A
Default setting 0.1
Recommended To be optimized according to operator quality targets.
setting
Range [0…1]
Additional Connectivity Plan setting takes the precedence over RF Region setting.
comments 0.1 means 10%.
Parameter name “Macro_Div_Reliab”

Parameter [ADR V3]: This parameter defines the target Macro Diversity Reliability
description (that is to say, minimum required probability of having N gateways
receiving device packets and providing a fine timestamp).
Unit N/A
Default setting 0.8
Recommended To be optimized according to operator quality targets.
setting
Range [0…1]
comments

0.8 means 80%.
Parameter name “Initial_WindowSize”

Parameter [ADR V3]: This parameter defines the minimum number of distinct
description uplink frames to be received by the algorithm before triggering a new
ADR commands to boost the end-device link budget when the quality
targets are not met (bad uplink PER or insufficient macro
Unit N/A
Default setting 5
Recommended 10, to provide a trade-off between ADR V3 stability and reactivity.
setting
Range [1…50]
Additional RULE: Initial_WindowSize_Optim > Initial_WindowSize >
comments Initial_WindowSize_Boot.
Parameter name “Initial_WindowSize_Boot” – NEW (RDTP-3466)

Parameter [ADR V3]: This parameter defines how many distinct uplink frames
description should be received by ADR V3 before sending its first ADR command
when the device boots/reboots (that is to say, new join for OTA devices
or reset detection for APB devices).
Unit N/A
Default setting = Initial_WindowSize
Recommended 5
setting
Range [1…50]
Parameter name “Initial_WindowSize_Optim” – NEW (RDTP-3466)

Parameter [ADR V3]: This parameter defines the minimum number of distinct
description uplink frames to be received by the algorithm before triggering a new
ADR commands to optimize the end-device battery/airtime when all

the quality targets are met (good uplink PER and sufficient macro
Unit N/A
Default setting = Initial_WindowSize
Recommended 25
setting
Range [1…50]
Parameter name “Forgetting_Factor”

Parameter [ADR V3]: This parameter defines the Forgetting Factor used to
description compute long-term PER. Prior to ThingPark 4.0, the same parameter is
also used to compute the long-term Overlap metric; but starting LRC
1.6.4, it is a separate RF Region parameter.
Forgetting_Factor_Overlap is used for Overlap metric.
Unit N/A
Recommended To be tuned by the operator to provide a trade-off between ADR V3
setting stability and reactivity.
Range [0…1]
Additional
comments
Parameter name “Forgetting_Factor_Overlap”

Parameter [ADR V3]: This parameter defines the Forgetting Factor used to
description compute the long-term Overlap metric.
Unit N/A
Recommended To be tuned by the operator to provide a trade-off between ADR V3
setting stability and reactivity.

Range [0…1]
Additional This parameter is only available starting ThingPark 4.0.
comments
Parameter name “Hyst_PER”

Parameter [ADR V3]: This parameter defines the hysteresis applied on top of PER
description target, to enter ADR_BATTERY_OPTIM state.
Unit N/A
Recommended Depends on operator strategy.
setting
Range [0…1]
Additional Setting Hyst-PER > = Target_PER deactivates ADR_BATTERY_OPTIM.
comments 0.05 means 5%.
Parameter name “Hyst_Overlap”

Parameter [ADR V3]: This parameter defines the hysteresis applied on top of
description Macro_Div_Reliab target, to enter ADR_BATTERY_OPTIM state.
Unit N/A
setting
Range [0…1]
Additional 0.05 means 5%.
comments
Parameter name “Hyst_SNR”

Parameter [ADR V3]: This parameter defines the hysteresis applied on top of
description original SNR transition table (lora:SNR_Limit_SFx).
Unit dB
Default setting 1

setting
Range [0…10]
Additional
comments
Parameter name “REP_Min”

Parameter [ADR V3]: This parameter defines the minimum allowed number of
description transmissions.
Unit N/A
Default setting 1
Recommended 1
setting
Range [1…5]
comments
Parameter name “REP_Max”

Parameter [ADR V3]: This parameter defines the maximum allowed number of
description transmissions.
Unit N/A
Default setting 5
Recommended Depends on the operator strategy.
setting
Range [1…15]
comments
Parameter name “SFmin”

Parameter [ADR V3]: This parameter defines the minimum allowed uplink
description Spreading Factor.

Unit N/A
Default setting 7
Recommended 7
setting
Range [7…12]
comments
Parameter name “SFmax”

Parameter [ADR V3]: This parameter defines the maximum allowed uplink
description Spreading Factor.
Unit N/A
Default setting 12
Recommended 12
setting
Range [7…12]
comments
Parameter name “Margin_Slope”

Parameter [ADR V3]: This parameter defines the constant used to derive the SNR
description margin to compensate the lack of information about SNR of lost
packets in ADR_LKB_BOOST.
Unit N/A
Default setting 2
Recommended To be fine-tuned based on field results.
setting
Range [0.1…10]
Additional
comments

4.3.5 “RX2 Optimization” Parameter Settings
Parameter name “margin_uplink”
Parameter This parameter defines the SNR margin to be applied on top of the
description median uplink SNR in the selection of RX1 vs. RX2 slots by the LRC.
Unit dB
Default setting 12
Recommended Should be optimized by the operator as detailed by 3.2 RX2
setting Optimization.
Range [-50…+50]
comments RX2 Optimization algorithm, please refer to 3.2 RX2 Optimization.
Setting this parameter to a highly negative value (-40 for instance)
practically deactivates the prioritization of RX2 channel based on the
link budget criterion. This is recommended for all the regional profiles
where RX1 and RX2 use the same TX Power.
Parameter name “SF_Limit”

Parameter This parameter defines the maximum SF for RX1 if RX2 Optimization
description algorithm is activated.
Unit N/A
Default setting 9
Recommended Should be optimized by the operator as detailed by 3.2 RX2
setting Optimization.
Range [7…12]
comments RX2 Optimization algorithm, please refer to 3.2 RX2 Optimization.
4.3.6 “Limit SNR per SF” Parameter Settings

Parameter name “SNR_limit_SF7”
Parameter This parameter defines the minimum SNR for SF7.
description
Unit dB

Default setting -7
Recommended -7
setting
Range [-25…0]
Additional This parameter is used by the ADR algorithm to derive the optimum SF
comments based on device’s radio conditions. It is also used by RX2 Optimization
algorithm in RX1/RX2 selection.

description
Unit dB
Default setting -9
Recommended -9
setting
Range [-25…0]

description
Unit dB
Default setting -11.5
Recommended -11.5
setting
Range [-25…0]
comments based on device’s radio conditions. It is also used by the RX2
Optimization algorithm in the RX1/RX2 selection.

description
Unit dB
Default setting -14
Recommended -14
setting
Range [-25…0]
Additional This parameter is used by ADR algorithm to derive the optimum SF
comments based on device’s radio conditions. It is also used by the RX2
Optimization algorithm in RX1/RX2 selection.

description
Unit dB
Default setting -16.5
Recommended -16.5
setting
Range [-25…0]

description
Unit dB
Default setting -19
Recommended -19
setting
Range [-25…0]

4.3.7 “RX Channel” Parameter Settings

Parameter name “ChIndex”
Parameter This parameter defines the index of each LoRaWAN™ channel.
description
Unit N/A
Default setting N/A
Recommended N/A
setting
Range [0…95]
Additional For EU868, KR920 and CN779: the 3 mandatory channels must have
comments channel index 0, 1 & 2.
For AS923: the channel index of the 2 mandatory channels is 0 & 1.
For US915, AU915 and CN470: the channel index is defined by
LoRaWAN™ Regional Parameters v1.0.2revA/revB.
Parameter name “IsDefault”

Parameter This parameter determines whether the Logical Channel is part of the
description default (mandatory) channels.
For a given ISM band, default channels must be implemented in each
device and each gateway; they can be deactivated (by appropriate
channel mask) but cannot be deleted.
Unit N/A
Default setting 0
Recommended 1 for LC1…LC3 in EU868, KR920 and CN779
setting 1 for LC1 and LC2 in AS923
Range {0,1}
Additional In EU868, the default channels are 868.1, 868.3 and 868.5 MHz.
comments In AS923, the default channels are 923.2 and 923.4 MHz.
In KR920, the default channels are 922.1, 922.3 and 922.5 MHz.
For US915, AU915 and CN470: the full channel plan is fixed by
LoRaWAN™, so IsDefault is not applicable.
Parameter name “LC”

Parameter This parameter defines the Logical Channel index of each LoRaWAN™
description channel.
Unit N/A
Default setting N/A
Recommended N/A
setting
Range [1…96]
Additional For EU868, CN779 and KR920, the Logical Channel index of the 3
comments mandatory channels is 1, 2 and 3.
For AS923, the 2 mandatory channels are LC1 & LC2.
For US915, AU915 and CN470: the Logical Channel follows the ChIndex.
Parameter name “Frequency”

Parameter This parameter defines the center frequency of the LoRaWAN™
description Channel.
Unit MHz
Default setting N/A
Recommended N/A
setting
Range The frequency range is specific to each regional profile ([863.1…869.9]
for EU868).
Additional Before associating a physical frequency to each Logical Channel, the
comments spectrum analysis should be conducted over a sufficiently large
number of gateways within the area concerned by the RF Region
configuration.
Please refer to ThingPark Wireless Spectrum Analysis User Guide for
more details on how to run spectrum scan over ThingPark network.

Parameter name “MinDR”
Parameter This parameter defines the minimum data rate of the Logical Channel,
description it is notified to the device in the “NewChannelReq” MAC command.
Unit N/A
Default setting 0 (= SF12 for EU868 and AS923 regional profiles)
Recommended 0
setting
Range [0…5]
Additional MinDR and MaxDR parameters define the allowed data rate range for
comments a given Logical Channel. These are global to an RF Region, but the actual
data rate range for each device can be configured in the Connectivity
Plan (see 5 Interaction between Parameters Settings in different
ThingPark Interfaces).
Parameter name “MaxDR”

Parameter This parameter defines the maximum uplink data rate of the Logical
description Channel, notified to the device in the “NewChannelReq” command.
Unit N/A
Default setting 5 (= SF7 for EU868 and AS923 regional profiles)
Recommended 5
setting
Range [0…5]
Additional MinDR and MaxDR parameters define the allowed data rate range for
comments a given Logical Channel. These are global to an RF Region, but the actual
data rate range for each device can be configured in the Connectivity
Plan (see 5 Interaction between Parameters Settings in different
ThingPark Interfaces).
Parameter name “SB”

Parameter This parameter defines the Sub-Band of the LoRaWAN™ channel, it is
description used for the per Sub-Band Duty Cycle inspection.
Unit N/A

Default setting N/A
Recommended For EU868: SB1 for default channels (LC1…LC3), all other channels
setting below 868 MHz should be associated with the same Sub-Band SB2.
Range No specific range limitation
Additional Rules:
comments
▪ If the Duty Cycle constraint applies on a group of channels (that
is to say, Sub-Band), all these Logical Channels bound by the
same Duty Cycle constraint should be defined with the same
Sub-Band.
▪ If the Duty Cycle constraint applies at Logical Channel level (not
at the group of channels), each LC should be configured with a
specific Sub-Band.
Parameter name “DTC”

Parameter This parameter defines the maximum allowed TX Duty Cycle of the Sub-
description Band associated to this Logical Channel.
When applicable, this max DC constraint is considered in the best-LRR
selection for downlink traffic routing.
Unit %
Default setting 1%
Recommended EU868: 1% for SB1 & SB2
setting US915 & AU915: N/A
Range [0…100]
Additional Rules:
comments
▪ For a given Logical Channel, <lora:DTC> should not be set
without <lora:SB>.
is to say, Sub-Band), all these Logical Channels bound by the
Sub-Band.
▪ If the Duty Cycle constraint applies per Logical Channel (not at
the group of channels), each LC should be configured with a
specific Sub-Band.

Parameter name “DlFrequency” (NFR-703)
Parameter This parameter defines the separate downlink center frequency for RX1
description window.
For EU868, AS923, KR920 and CN779: setting this parameter for a given
Logical Channel means that the UL and DL RX1 transmissions will be
asymmetric for devices supporting LoRaWAN™ 1.0.2 onwards.
If this parameter is not present for a given Logical Channel, the RX
Channel is automatically defined as a bidirectional channel.
Unit MHz
Default setting N/A
Recommended N/A
setting
Range The frequency range is specific to each regional profile:
EU868: [863.1…869.9]
US915 & AS915: {923.3, 923.9, 924.5, 925.1, 925.7, 926.3, 926.9, 927.5}
Additional For US915, AU915 and CN470: The channel plan is natively asymmetric.
comments Please refer to ThingPark RF Channel Selection Guidelines for more
details on how to define asymmetric channel plans in ThingPark.
4.3.8 “TX Channel” Parameter Settings

Parameter name “LC”
Parameter This parameter defines the Logical Channel index of the separate
description downlink channel.
Unit N/A
Default setting N/A
Recommended N/A
setting
Range [127…254]
Additional For EU868: the Logical Channel index of the 3 mandatory channels is 1,
comments 2 and 3.

For US915 & AU915: the Logical Channel index of downlink channels is
LC127…LC134.
Parameter name “Frequency”

Parameter This parameter defines the center frequency of the DL RX1 channel,
description this frequency should match DlFrequency in <RxChannel> section.
Unit MHz
Default setting N/A
Recommended N/A
setting
Range The frequency range is specific to each regional profile:
EU868: [863.1…869.9]
US915 & AS915: {923.3, 923.9, 924.5, 925.1, 925.7, 926.3, 926.9, 927.5}
Additional For EU868, AS923, KR920 and CN779: Asymmetric channel plan shall
comments be implemented only for LoRaWAN™ 1.0.2 devices supporting the
“DlChannelReq” MAC command.
For US915, AU915 and CN470: The channel plan is natively asymmetric.
Please refer to ThingPark RF Channel Selection Guidelines for more
details on how to define asymmetric channel plans in ThingPark.
Parameter name “Bandwidth”

Parameter This parameter defines the bandwidth of the downlink channel.
description
Unit kHz
Default setting 125 kHz
Recommended Depends on the ISM band.
setting
Range {125, 500}
Additional For EU868, AS923, KR920, CN779 and CN470: Downlink channel
comments bandwidth of asymmetric channels must be 125 kHz.
For US915 & AU915: Downlink channel bandwidth must be 500 kHz.

Parameter name “SB”
Parameter This parameter defines the Sub-Band of the separate downlink
description channel, it is used for the per Sub-Band Duty Cycle inspection.
Unit N/A
Default setting N/A
Recommended For EU868: SB1 for frequencies in the range [868…868.6 MHz], all other
setting channels below 868 MHz should be associated with the same Sub-Band
SB2.
Range No specific range limitation.
Additional Rules:
comments
is to say, Sub-Band), all these Logical channels bound by the
Sub-Band.
▪ If the Duty Cycle constraint applies at Logical Channel level (not
at the group of channels), each LC should be configured with a
specific Sub-Band.
Parameter name “DTC”

Parameter This parameter defines the maximum allowed TX Duty Cycle of the Sub-
description Band associated to this Logical Channel.
When applicable, this max DC constraint is considered in the best-LRR
selection for downlink traffic routing.
Unit %
Default setting 1%
Recommended EU868: 1% for SB1 & SB2
setting US915 & AU915: N/A
Range [0…100]
Additional Rules:
comments
▪ For a given Logical Channel, <lora:DTC> should not be set
without <lora:SB>.
is to say, Sub-Band), all these Logical channels bound by the
same DutyCycle constraint should be defined with the same
Sub-Band.

▪ If the Duty Cycle constraint applies per Logical Channel (not at
the group of channels), each LC should be configured with a
specific Sub-Band.
Parameter name “UsedForRX2” (RDTP-2543)

Parameter This parameter determines whether the Logical Channel in question is
description used for downlink RX2.
When this flag is set on one (or more) Tx Channels, the RX2 parameters
defined in 4.3.2 RX1/RX2 Parameter Settings are ignored by the LRC.
Unit N/A
Default setting 0
Recommended To be configured by the Operator if they want to define multiple RX2
setting channels in the same RF Region (see 4.3 Main RF Region Parameters
for more details about this feature).
Range {0,1}
Additional
comments
Parameter name “UsedForBeacon” (NFR-596)

description used to send Class B beacon signal.
Unit N/A
Default setting 0
Recommended To be tuned by the network operator.
setting
Range {0,1}
Additional To be able to send a beacon signal, the field “Activate Beacon
comments transmission” should be set in Network Manager GUI for the LRRs in
question.
Parameter name “UsedForPingSlot” (NFR-596)

description used for Class B ping slots.
Unit N/A
Default setting 0
Recommended To be tuned by the network operator.
setting
Range {0,1}
Additional Starting TPW release 6.0 (RDTP-2543), it is possible to define multiple
comments pingslot channels in the same RF Region (see 4.3 Main RF Region
Parameters for more details about this feature).
Parameter name “MaxDR”

Parameter This parameter defines the maximum data rate of the downlink Logical
description Channel. It is only relevant when the channel is used for Class B beacon
and/or ping slot.
Unit N/A
Default setting 5
Recommended To be tuned by the network operator for Class B operation.
setting
Range [0…13]
Additional Data Rate encoding is regional-dependent, it is defined in LoRaWAN™
comments Regional Parameters v1.0.2revA/revB.
4.3.9 Listen Before Talk (LBT) Parameter Settings (NFR 598)

Parameter name “LBTCarrierSensingLevel”
Parameter This parameter defines the RSSI signal strength above which the LBT
description function embedded in the LRR considers that the medium is busy.
Unit dBm
Default setting -80
Recommended -80 dBm for Japan, -65 dBm for Korea.
setting Note: If this parameter is not present in the RF Region XML file, LBT will
not be activated on the LRRs associated with this RF Region.
Range [-50 … -120]

Additional This is a global parameter, it applies to all the Logical Channels. It must
comments be present in RF Region file otherwise LBT will not be activated.
Parameter name “LBTCarrierSensingDuration”

Parameter This parameter defines the LBT carrier sensing duration for each Logical
description Channel.
Unit milliseconds
Default setting N/A
Recommended Depends on the local regulation.
setting
Range { 128, 5000 }
Additional The LRR supports LBT over up to 8 downlink channels in V1.5 gateways
comments and up to 16 channels in V2 gateways.
To activate LBT over a specific channel, this parameter must be present
either in <RxChannels> section (when the channel index of concern is a
symmetric/bidirectional channel) or in <TxChannels> section (when the
channel index in question is a downlink-only channel).
4.3.10 Class B Parameter Settings (NFR 596)

Parameter name “ClassBEnabled”
Parameter This parameter activates/deactivates Class B support.
description
Unit N/A
Default setting 0
Recommended 1 if Class B shall be activated in the network.
setting
Range { 0, 1 }
Additional
comments
Parameter name “BeaconPeriod”

Parameter This parameter defines the beacon periodicity.
description

Unit seconds
Default setting 128
Recommended 128 as per LoRaWAN™ specifications.
setting
Range In the current LoRaWAN™ specification, only 128s periodicity is
defined.
Additional This parameter is present to allow flexibility if future LoRaWAN™
comments versions define several beacon periods.
Parameter name “BeaconMaxPeriod”

Parameter This parameter defines the maximum interval in seconds between
description beacons. If no beacon has been transmitted within this interval, the LRR
must transmit a beacon (disable beaconing randomization).
Unit seconds
Recommended To be set according to the operator strategy.
setting
Range <= 3600
Additional
comments
Parameter name “BeaconRandomization”

Parameter At each BeaconPeriod, LRR computes a random number R between 0
description and 99, then transmits a beacon if R < BeaconRandomization. Setting
this parameter to 100 disables randomization.
Unit N/A
Default setting 100
Recommended To be set according to the operator strategy.
setting
Range [0 … 100]
Additional Beacon randomization could be activated in very dense deployments,
comments when it is not necessary to transmit beacon signal by every LRR.

4.3.11 Best-LRR Selection Parameters (NFR-924)
Parameter name “BestLRR_SlidingWindow”
Parameter This parameter defines the sliding window size for averaging of ESP
description values of static devices.
Unit N/A
Default setting 50
Recommended To be optimized by the operator to ensure non-volatility of best-LRR
setting selection for static devices.
Range [1…100]
Additional This averaging window size is only relevant for static devices. For more
comments details, please refer to 3.6 Best-LRR Selection Algorithm (NFR-924).
Parameter name “MaxLrrPER_InterRegion”

Parameter This parameter defines the maximum packet error rate of each
description candidate LRR that belongs to a different RF Region than the one
currently configured for the device.
Unit %
Default setting 50
Recommended To be optimized by the operator to compensate the potential RF
setting channel mismatch between different RF Regions.
Range [1…100]
Additional This parameter is used by NFR-924 to filter-out LRRs having very higher
comments PER for a given device. For more details, please refer to STAGE #1 in 3.6
Best-LRR Selection Algorithm (NFR-924).
Parameter name “MaxLrrPER_IntraRegion”

Parameter This parameter defines the maximum packet error rate of each
description candidate LRR that belongs to the same RF Region as the one currently
configured for the device.
Unit %
Default setting 20
Recommended MaxLrrPER_IntraRegion < MaxLrrPER_InterRegion
setting

Range [1…100]
Additional This parameter is used by NFR-924 to filter-out LRRs having very higher
comments PER for a given device. For more details, please refer to STAGE #1 in 3.6
Best-LRR Selection Algorithm (NFR-924).
Parameter name “DC_penalty”

Parameter This parameter defines the penalty applied to the average ESP of each
description LRR, to penalize the selection of gateways that are highly-loaded by
downlink traffic and ensure loading balancing.
Unit dB
Default setting 5
Recommended To be optimized according to the operator strategy.
setting
Range [-50…50]
Additional For more details, please refer to STAGE #1 in 3.6 Best-LRR Selection
comments Algorithm (NFR-924).
Parameter name “RFRegion_penalty”

Parameter This parameter defines the penalty applied to the average ESP of each
description LRR, to harden the selection of an LRR belonging to a different RF
Region than the one currently used by the device. This mechanism is
helpful to avoid unnecessary reconfiguration of the device’s MAC layer
when it switches from one RF Region to another.
Unit dB
Default setting 10
Recommended To be optimized by the operator to avoid useless ping-pong between
setting different RF Regions.
Range [-50…50]
Parameter name “HighDCThreshold”

Parameter This parameter defines the average long-term downlink Duty Cycle
description value above which the DC_penalty is applied to the LRR. If the average
DL Duty Cycle is lower than this threshold, the DC_penalty is not
applied because the LRR is not considered highly downlink-loaded.
Unit %
Default setting 5
Recommended To be optimized according to the operator strategy.
setting
Range [0…100]
4.3.12 MAC Commands Retransmission parameters (NFR-928)

Parameter name “MaxMacTransmitNotReplied”
Parameter This parameter defines the maximum number of transmission
description attempts for a MAC command that is not replied by a device.
Unit N/A
Default setting 4
Recommended To be optimized according to operator strategy, to trade-off downlink
setting coverage with capacity.
Range [0…50], the value 0 means no limit
Additional A MAC command request sent in a DL frame is considered “Not
comments Answered” if the next UL frame from the device does not contain the
corresponding MAC command answer.
Parameter name “MaxMacTransmitNotAcked”

Parameter This parameter defines the maximum number of transmission
description attempts for a MAC command that is not acknowledged by a device.
Unit N/A
Default setting 2
Recommended 2
setting
Range [0…50], the value 0 means no limit
Additional A MAC command request sent in a DL frame is considered “Not
comments Acknowledged” if the next UL frame from the device contains the
corresponding MAC command answer and at least one ACK bit of the
MAC command answer is set to 0.
Parameter name “MacBackoffFCntUp”

Parameter This parameter defines the minimum number of UL frames to be
description elapsed after the “Not Answered” command enters the “blocked” state
before the device becomes eligible again to this MAC command.
Unit N/A
Default setting 10
Range [0…100]
Additional If a DL MAC command is not answered by the device after
comments MaxMacTransmitNotReplied attempts, it becomes “blocked” during a
back-off period that is either duration-driven or frame-counter driven,
the MAC command is unblocked as soon as at least one of the two back-
off conditions is reached.
This parameter defines the frame-counter back-off condition.
Parameter name “MacBackoffDelay”

Parameter This parameter defines the minimum delay to be elapsed after the “Not
description Answered” command enters the “blocked” state before the device
becomes eligible again to this MAC command.
Unit seconds
Range >0
Additional If a DL MAC command is not answered by the device after
comments MaxMacTransmitNotReplied attempts, it becomes “blocked” during a
back-off period that is either duration-driven or frame-counter driven,
the MAC command is unblocked as soon as at least one of the two back-
off conditions is reached.
This parameter defines the duration-driven back-off condition.
4.3.13 Other Parameters

Parameter name “RedundancyDeduplicationTimer” (Modified by NFR-731)
Parameter This parameter defines the maximum time duration after the reception
description of the initial uplink frame (FCntUp) beyond which the LRC does not
expect any legitimate frame repetition. Any repeated frame received
after the expiry of this timer is treated by the LRC as a replay attack.
Unit seconds
Default setting 300
Recommended 3600
setting
Range N/A
Additional
comments
Parameter name “RadioCenterFrequency”

Parameter This parameter defines the center frequency of AD9361 transceiver for
description V2/V3 gateways (for instance, Kerlink iBTS, Cisco Warbler…).
Unit MHz
Default setting 866.5 MHz
Recommended 866.5 MHz for EU868
setting
Range [863…870] for EU868, [902…915] for US915, [915…928] for AS923
Additional The setting of this parameter also impacts the allowed range applicable
comments to spectrum scan.
Parameter name “UplinkDwellTime” (NFR-703)

Parameter This parameter defines the maximum dwell time for the transmission
description of UL packets by the device. This parameter corresponds to the
LoRaWAN™ parameter “UplinkDwellTime” defined in LoRaWAN™

1.0.2. It is sent to the device in the “TxParamSetupReq” MAC command
and determines the maximum allowed UL date rate.
Unit N/A
Default setting 0 (no limit)
Recommended To be configured for the Asian cluster according to the local country
setting regulations.
Range { 0 (No limit), 1 (400ms) }
Additional This parameter is only relevant for AS923 regional profile, where the
comments MAC command “TxParamSetupReq” is supported.
Parameter name “DownlinkDwellTime” (NFR-703)

Parameter This parameter defines the maximum dwell time for the reception of
description DL packets by the device. It corresponds to the LoRaWAN™ parameter
“DownlinkDwellTime” defined in LoRaWAN™ 1.0.2. It is sent to the
device in the “TxParamSetupReq” MAC command and determines the
maximum allowed DL date rate.
Unit N/A
Default setting 0 (no limit)
Recommended To be configured for the Asian cluster according to the local country
setting regulations.
Range { 0 (No limit), 1 (400ms) }
Additional This parameter is only relevant for AS923 regional profile, where the
comments MAC command “TxParamSetupReq” is supported.
Parameter name “ISMband” (Chinese profiles are added by NFR 921 in TPW4.3)
Parameter This parameter defines the LoRaWAN™ regional profile.
description
Unit N/A
Default setting N/A
Recommended To be configured by the network operator.
setting
Range { eu868, us915, au915, as923, kr920, eu433, cn779, cn470 }

Additional This parameter must be consistent with the “Band” value set in LRR.ini
comments file on the gateway. For more information, please refer to ThingPark RF
Channel Selection Guidelines.
Parameter name “UseCFList”

Parameter This parameter defines an optional list of channel frequencies (CFList)
description that can be sent to the end-device in the Join Accept message. It
corresponds to the LoRaWAN™ parameter “CFList” defined in
LoRaWAN™ 1.0.2. The CFList option is region specific and is defined in
the LoRaWAN™ Regional Parameters v1.0.2revA/revB.
Unit N/A
Default setting 1
Recommended 1 for EU868, EU433, KR920.
setting This parameter is ignored for US915 & AU915 (since CFList is not
supported in these 2 regions).
Range { 0, 1 }
Additional When DownlinkDwellTime = 1, UseCFList must be set to 0 to respect
comments the 400ms dwell time constraint for the Join Accept message.
Parameter name “MaxConcatenatedCommands”

Parameter This parameter defines the maximum number of MAC commands
description concatenated in the same downlink frame.
Unit N/A
Default setting 4
Recommended 5 for US915 (in order to limit the payload of the UL MAC response from
setting the device).
Range [1…10]
Additional When DownlinkDwellTime = 1, MaxConcatenatedCommands must be
comments set to 2 to comply with the worst-case DL payload size limit (11 bytes
at SF10).
Parameter name “BackhaulDelayGraceWindow” (NFR-731)

Parameter This parameter defines the time duration beyond which a duplicated
description packet is considered as a repetition initiated by the device.
Unit seconds
Default setting 2
Recommended Should be set > = MACRxDelay1 +1, since a device cannot repeat an
setting uplink packet before waiting for RX2 slot.
Range [1…20]
Additional
comments

5 INTERACTION BETWEEN PARAMETERS SETTINGS IN DIFFERENT THINGPARK INTERFACES
5.1 Device Profile Parameter Settings
In the Operator Manager tab, the network operator can define customized Device Profiles
besides the Device Profiles available by default in the Device Profile catalog.
The RF configuration parameters available in the Device Profile are split into four main
categories:
1. General RF Configuration Parameters:
▪ Supported ISM bands: List of the supported ISM Bands for this Device Profile.
▪ LoRaWAN™ version: Supported versions are LoRaWAN™ 1.0.0/1.0.1, 1.0.2 and 1.1.
Note: LoRaWAN™ version 0.9 represents legacy devices that were not fully
compliant with the first official release of LoRaWAN™ specification. This value is
only kept for compatibility reasons but shouldn’t be used for newly provisioned
devices.
▪ LoRaWAN™ PHY version (Supported Regional parameter revision): This field

indicates the right revision of the Regional Parameters document supported by the
device. In LoRaWAN™ 1.0.2, two PHY revisions are officially published by the LoRa
Alliance (revA and revB). Hence, to guarantee proper handling of the TX Power
encoding rules for each end-device, the LoRaWAN™ Regional Parameters revision
supported by each Device Profile should be properly configured through the new
field “Supported Regional parameter revision”.
▪ Minimal RX1 delay (ms) (NFR-880): Set the delay between the end of uplink TX
window and the start of RX1 slot. This parameter is optional in the Device Profile,
and if it is set then it overwrites the MACRxDelay1 value set in RF Region.
▪ Asynchronous UL processing: The parameter determines whether the processing

of uplink and downlink frames use the synchronous or asynchronous mode. To set
asynchronous mode, the value of this parameter should be set to the target value
of the “WaitASResps” timer. For more information, please refer to 0
▪ Asynchronous Uplink/Downlink Processing.
▪ Ignore DL max payload size (NFR-766): This box is disabled by default, so that the
LRC systematically controls the MAC payload size of downlink frames as per the
limits set in LoRaWAN™ Regional Parameters v1.0.2revA/revB for each regional
profile. If this box is checked, the LRC does not control the maximum payload size
of downlink frames; which may cause devices to reject the downlink packet if the
max payload size is not respected.

To avoid compatibility issues with devices/applications exceeding the DL max
payload limit imposed by LoRaWAN™, this flag is added in the Device Profile to
exceptionally allow larger DL payloads than the max payload size defined in
LoRaWAN™ Regional Parameters v1.0.2revA/revB.
Note: The max payload size counts the whole MAC payload, including MAC
commands (either piggybacked to an application payload or sent separately with
FPort = 0).
In case the application payload already sent by Application Server exceeds the max
size, the LRC blocks the DL and a notification with max downlink dwell time is sent
to the AS over the AS tunnel interface.
For UL, it is not relevant to block based on dwell time because the packet has
already reached the LRC (so the radio resources have already been used).
2. Boot parameters, under the section “Device Radio Frequency boot parameters”:
This section allows the LRC to know the LoRaWAN™ TX/RX parameters used by the
device during the boot phase (that is to say, after commissioning or following a factory
reset).
This step is essential to make sure that the LRC uses the right parameters to establish
the initial communication with the device.
Once this initial communication is successfully established, the LRC may send MAC
commands to configure the device to the target RF settings of the corresponding RF
Region and Connectivity Plan.
The following figure presents a view on the RF boot parameters for a Class A device
using EU868 ISM band:
Figure 39 – Device profile boot parameters

Default setting
Boot Parameter if not filled in Corresponding RF
Description
Name “Device Region Parameter
Profile”
Boot value used by the device to set the
delay between the end of UL TX and start
of RX1 slot. This delay is then aligned by
Mac RX1 delay the LRC to the target value set in the RF 1000 ms MACRxDelay1
Region through the “RXParamSetupReq”
MAC command, if supported by the
device.
offset between UL data rate and DL RX1
data rate. This offset is then aligned by
Mac RX1 data
the LRC to the target value set in RF 0 RX1DRoffset
rate offset
Region through the “RXParamSetupReq”
MAC command, if supported by the
device.
ISM-
DL RX2 data rate. This data rate is then
dependent
Mac RX2 data aligned by the LRC to the target value
(use default RX2DataRate
rate (Connectivity Plan or RF Region) through
LoRaWAN™
the “RXParamSetupReq” MAC command,
value)
if supported by the device.
ISM-
DL RX2 frequency. This frequency is then
dependent
Mac RX2 aligned by the LRC to the target value set
(use default RX2Freq
frequency in the RF Region through the
LoRaWAN™
“RXParamSetupReq” MAC command, if
value)
supported by the device.
max TX Duty Cycle. This Duty Cycle is then
Mac max Duty aligned by the LRC to the target value set
0 MaxDutyCycle
Cycle in the RF Region through the
“DutyCycleReq” MAC command, if
supported by the device.
Delay between the end of the Join
Join Accept
Request message and the start of RX1 5000 ms N/A
delay 1
window to receive a Join Accept.

Default setting
Description
Profile”
Delay between the end of the Join
Join Accept
Request message and the start of RX2 6000 ms N/A
delay 2
window to receive a Join Accept.
Device Join Accept session timeout
Join session
before launching a new Join Request to N/A N/A
timeout
the Network Server.
MAC max Only relevant for AS923 ISM band,
uplink dwell defines the default uplink dwell time used 400ms UplinkDwellTime
time by the device during boot phase.
MAC max Only relevant for AS923 ISM band,
downlink dwell defines the default downlink dwell time 400ms DownlinkDwellTime
time used by the device during boot phase.
For Class B device (NFR-743), additional boot parameters are available in the Device Profile:
Default setting
Description
Profile”
Ping slot channel frequency (in MHz) at ISM-

device boot. The ping slot frequency is dependent See 4.3.8 “TX
PingSlotChannelF
then aligned by the LRC to the target (use default Channel” Parameter
requency
value set in RF Region through the LoRaWAN™ Settings
“PingSlotChannelReq” MAC command. value)
Ping slot data rate used by the device at ISM-

boot. The ping slot data rate is then dependent See 4.3.8 “TX
PingSlotChanneD
aligned by the LRC to the target value (use default Channel” Parameter
atarate
set in RF Region through the LoRaWAN™ Settings
“PingSlotChannelReq” MAC command. value)
Beacon frequency (in MHz) at device ISM-

boot. The beacon frequency is then dependent See 4.3.8 “TX
BeaconFrequency aligned by the LRC to the target value (use default Channel” Parameter
set in RF Region through the LoRaWAN™ Settings
“BeaconFreqReq” MAC command. value)

3. Device capabilities:
The RF parameters defined in this section determine the RF capabilities of end-devices
associated with this Device Profile:
▪ Min & max conducted TX Power (dBm): correspond to the conducted power
emitted by the radio board, excluding the antenna gain of the device.
o If these fields are left empty in the Device Profile, the LRC uses the
corresponding RF Region settings (MinPower & MaxPower).
o If these fields are set in the Device Profile, the effective max TX Power of the
device is the minimum value between the Device Profile and the RF Region
settings. Similarly, the effective min TX Power of the device is the maximum
value between the Device Profile and the RF Region settings.
▪ Min & max EIRP (dBm): correspond to the supported range of radiated power,
including the antenna gain of the device.
o If these fields are left empty in the Device Profile, the LRC uses the RF Region
settings (MinEIRP & MaxEIRP).
o If these fields are set in the Device Profile, the effective max EIRP of the device
is the minimum value between the Device Profile and the RF Region settings.
Similarly, the effective min EIRP of the device is the maximum value between
the Device Profile and the RF Region settings.
▪ Maximum number of transmissions: this field is used to set an upper bound to the
number of consecutive transmissions of the same uplink frame counter (also
known as repetitions). If this field is left empty in the Device Profile, the default
setting considered by the LRC is 10.
▪ Maximum number of transmissions for confirmed uplink frames: this parameter

is used by NFR-731 (replay attack mitigation) to set an upper bound to the number
of consecutive transmissions of the same uplink frame counter for confirmed
uplink frames. If this field is left empty in the Device Profile, the default setting
considered by the LRC is 10. For more details, please see 3.5 Replay Attack
Mitigation (NFR-730/NFR-731).
▪ Allowed ABP automatic reset: this flag is only relevant for ABP devices, it is used
to inform ThingPark whether an ABP device using LoRaWAN™ 1.0.x protocol can
reset its UL/DL frame counters. For more details, see 3.5 Replay Attack Mitigation
(NFR-730/NFR-731).
▪ DevNonce is a counter (NFR-1043): this flag is only relevant for OTAA devices, it is
used to inform ThingPark whether an OTAA device using LoRaWAN™ 1.0.x protocol
implement the enhanced security mode described in the LoRaWAN™ Best Practice

Recommendations. In this mode, the DevNonce used by the device in Join Request
messages is a monotonically increasing counter that is never reused for a given
AppEUI.
End-devices implementing this enhanced security mode are protected from replay
attack threats during Join phase: for these devices, the LRC inspects the DevNonce
value sent in the Join Request and reject it if DevNonce is not strictly higher than
the last value known by the LRC.
4. Supported MAC commands:

Activation/deactivation of the different MAC commands supported by this type of
device.
Important
Any modification to the Device Profile parameters is immediately considered by the LRC
without reprovisionning of existing devices.
5.2 Connectivity Plan Parameter Settings
In the Connectivity Plan, it is possible to override some of the RF Region parameters, for
example:
▪ ADR parameters: ADR-specific parameters can be configured at Connectivity Plan

level, to offer a differentiated grade of service for the different subscriber classes:
o Spreading Factor Range (Min/Max SF): used by ADR V2/V3 algorithms.
o Channel Mask: sent to the device via “LinkADRReq” MAC command:
▪ The channel mask is configured in hexadecimal format. It can be
configured in the Connectivity Plan to offer different service profiles to
the end-users subscribing to the ThingPark solution.
▪ Note: Starting TPW4.1.2 (NFR-883), the channel mask configuration in
Connectivity Plan GUI supports up to 72 channels, which is relevant for
US915 & AU915 profiles.
o Minimum Antenna Diversity: used for ADR V2/V3 algorithms.
Figure 40 – Connectivity Plan parameters overriding RF Region settings

o ADR V2-specific parameters:
Figure 41 – ADR V2 parameters in Connectivity Plan (overriding RF Region settings)
o ADR V3-specific parameters:
Figure 42 – ADR V3 parameters in Connectivity Plan (overriding RF Region settings)
▪ RX1/RX2 parameters:
o RX2 Data Rate (NFR-749):
o RX1 Delay (NFR-880):
Important
Some parameters can be defined in different interfaces: RF Region, Connectivity
Plan and Device Profile. If the values set for these parameters are not the same,
the priority is as following: Connectivity Plan > Device Profile > RF Region.
Example: If the values of Minimal RX1 delay are different in the Device Profile,
Connectivity Plan and RF Region, the value defined in the Connectivity Plan takes
precedence over Device Profile and RF Region settings.

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

TP Wireless 6.1 Radio Parameters User Guide Rev2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TP Wireless 6.1 Radio Parameters User Guide Rev2

Uploaded by

Copyright:

Available Formats

Actility ThingPark

© 2020 ACTILITY SA. All rights reserved.

Under Non-Disclosure Agreement

Version Date Author Details

Actility Update for ThingPark 4.2 and 4.3, with the

Under Non-Disclosure Agreement

5.1_rev5 19/11/2018 Actility Syntax update of all the RF Region attributes

6.1_rev1 2020/05/13 Actility Update RX2 Optimization algorithm to

Under Non-Disclosure Agreement

New/Enhanced Functionalities For More Information, See… Release

ADR V3 enforcement for new Connectivity Plans 3.1.5 ADR-Related Parameters in

Multicast enhancement: RDTP-8570

ADRv3 enhancement: RDTP-3466 (Define 3.1.3 ADR V3 Algorithm

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

Under Non-Disclosure Agreement

The ThingPark set consists of four main key components:

Operator & Enterprise Application Servers

ThingPark OS ThingPark Wireless Core NW & OSS ThingPark X

Wireless Device Network

Spectrum Network LoRaWANTM LoRaWANTM

LoRaWANTM LRR (Gateway)

Figure 1 - ThingPark Solution Architecture Description High Level Product Illustration

Under Non-Disclosure Agreement

3.1 Adaptive Data Rate

Figure 2– ADR effect on bitrate and energy consumption

Under Non-Disclosure Agreement

Figure 3 - Simplified ADR algorithm

Under Non-Disclosure Agreement

▪ Data Rate (Spreading Factor): by considering the minimum required macro-diversity

▪ N is configurable by the RF Region parameter MinimumAntennaDiversity but it can

Figure 4 – ADR V2 fields in Connectivity Plan

▪ Repetition: the number of repetitions is semi-statically configured at RF Region &

Under Non-Disclosure Agreement

▪ Redundancy is set in RF Region.

▪ “Number of transmissions offset” is set in the Connectivity Plan (see Figure 4)

▪ Maximum number of transmissions is set in the Device Profile to provide an

Figure 5 – ADR V2 fields in Device Profile

▪ RF Region setting: <lora:Redundancy>2</lora:Redundancy>

▪ Connectivity Plan (95% success rate): Number of transmissions offset = 1

▪ Connectivity Plan (80% success rate): Number of transmissions offset = 0

Under Non-Disclosure Agreement

Important Warning: ADR V2 will be deprecated by Actility in the next

3.1.3 ADR V3 Algorithm

Figure 6 – Main parameters optimized via ADR V3

ADR V3 optimization is quality-driven, based on the following targets:

Under Non-Disclosure Agreement

3.1.3.1 ADR V3 Quality Metrics

3.1.3.1.1 Packet Error Rate (PER) Criterion

▪ Example1: LRC receives FCntUp 1,2,3,4,5 after boot → PERinitial = 0%

▪ Example2: LRC receives FCntUp 1,2,4,5,7 after boot → PERinitial = 28.5%

Under Non-Disclosure Agreement

3.1.3.1.2 Coverage Overlap Criterion

▪ “R” = # gateways successfully receiving the device’s packets.

▪ MinimumAntennaDiversity = minimum required # gateways for geo-location, denoted

▪ Macro_Div_Reliab is the target macro diversity reliability, defining the minimum %

Note that the combination of Macro_Div_Reliab & MinimumAntennaDiversity parameter

To maintain this coverage-overlap target, the LRC continuously computes N_Server_Prob_LT

▪ Like PER_LT computation, N_Server_Prob is initialized after device reboot or following

Under Non-Disclosure Agreement