Computer Communications 195 (2022) 303–314

Contents lists available at ScienceDirect

Computer Communications
journal homepage: www.elsevier.com/locate/comcom

Improving LoRaWAN downlink performance in the EU868 spectrum

Dimitrios Zorbas
Nazarbayev University, School of Engineering & Digital Sciences, Nur-Sultan, Kazakhstan

ARTICLE INFO ABSTRACT

Keywords: LoRaWAN is one of the most widely used Internet of Things protocols. It is developed driven by the easiness
LoRa of the deployment and the support of any type of application. However, LoRaWAN has been made mostly for
LoRaWAN uplink transmissions rather than downlink traffic. As it has been shown by many studies in the literature, it
Downlink
suffers from very poor performance even with moderate downlink traffic. This is mainly due to the radio duty
EU868
cycle restrictions applied on gateways but also due to the half-duplex nature of LoRa transceivers. To mitigate
the problem of the reduced downlink performance, this paper proposes different channel, band, and downlink
window schemes taking into account the recently announced Band 47b in the EU868 spectrum which adds
four extra downlink channels with a total radio duty cycle of 10%. The main issue that is tackled is how the
additional downlink time can be used effectively in the new schemes. The advantages and disadvantages of
each scheme are discussed and ranked based on the easiness of their integration into the native LoRaWAN
and the number of modifications they require. Extensive simulation results are presented and are compared
to the baseline. The results reveal that schemes which require more changes to the protocol exhibit higher
performance gains. More specifically, if a 10% duty cycle channel is applied in the first receive window, a
higher than 200% performance gain in terms of packet delivery ratio and energy consumption can be achieved.

1. Introduction
LoRaWAN is an open standard developed by the LoRa Alliance
which provides LoRa-enabled IoT devices with the necessary MAC
and link layer mechanisms. LoRa is a proprietary spread spectrum
modulation which can achieve long ranges (over 10 km with line of
sight) and presents remarkable resistance to interference and Doppler
effects. LoRa and LoRaWAN are used in a wide range of applications
such as the asset tracking, the monitoring of soil, air pollution, water
quality etc. [1,2].
LoRaWAN creates a star of stars topology usually consisting of
several end-nodes and one or more gateways which are connected to a
group of servers through a cloud-based system. The Network server, the
Join server, and the Application server, are responsible for a number of
operations in the network such as the encryption key management, the
transmission of the acknowledgments, and the interconnection with the
user applications. The gateways forward uplink/downlink data from/to
the end-devices to/from the servers. The communication between the
gateway(s) and the end-nodes is done through LoRaWAN while the
communication between the gateway(s) and the servers is done through
non-LoRaWAN protocols (see Fig. 1).
LoRaWAN distinguishes three modes of operation for the end-
devices; Class A, B, and C. In Class A, the end-devices are considered
as energy constrained devices which need to be on only when they are
transmitting or receiving data (even if no data is actually transmitted
by a gateway). The MAC layer of Class A is Aloha-based, which means
that transmissions are performed without employing any collision
avoidance mechanism. Downlink transmissions (i.e., acknowledgments
and commands) are sent using two receive windows, one and two
seconds (default values) after the end of the uplink transmission. More
details about the downlink mechanism of LoRaWAN are given in the
next section. In Class B, synchronization beacons are employed by
the gateways to allow a number of end-devices to open more receive
windows at specified times. Finally, in Class C, the end-devices have
constantly their radio on, thus, it is assumed they have unlimited power
resources. The last two classes of devices are not often used and most
commercial devices implement only the first mode of operation.
Due to the Aloha-based MAC of LoRaWAN, many collisions may
occur which leads to a high number of retransmissions and channel
saturation [3]. Downlink traffic worsens the performance because,
first, it increases the amount of traffic and, second, it blocks uplink
transmissions for the duration of the downlink since LoRa transceivers
are half-duplex. As it is stated by many studies [4], LoRaWAN is
mainly made for unconfirmed traffic. Nevertheless, there are applica-
tions where the acknowledge of the reception is vital for the nature of
the measurements (e.g., healthcare applications). Apart from that, LoRa
networks operating in the sub-GHz spectrum have to obey radio duty
cycle regulations which limit the total transmission time for both end-
devices and gateways. LoRaWAN relies on the deployment of additional

E-mail address: dimitrios.zorbas@nu.edu.kz.

https://doi.org/10.1016/j.comcom.2022.09.001
Received 20 May 2022; Received in revised form 31 August 2022; Accepted 1 September 2022
Available online 6 September 2022
0140-3664/© 2022 Elsevier B.V. All rights reserved.
D. Zorbas
Fig. 1. The LoRaWAN architecture.
gateways to solve the problem of limited downlink time, however, this
increases the cost of the deployment.
In this work, the limited downlink capabilities of LoRaWAN are
discussed and a number of radio channels, bands, and receive window
arrangement schemes are proposed taking into account the newly
introduced band for access points in the EU868 spectrum1 . This new
band, which can also be used by RFID devices with 2 W transmit power,
provides 4 additional channels in the EU868 spectrum with a total duty
cycle of 10% for access points (gateways) [5]. Adaptive power control
is also required which can be easily achieved in LoRaWAN through
the adaptive data rate mechanism. Even though the new band was
introduced in mid 2017, the present work is so far the only study which
explores its potential in enhancing LoRaWAN’s downlink performance.
This paper describes how the new available channels can be used in
LoRaWAN proposing a number of channel, band, and window arrange-
ment schemes. The proposed schemes are ranked in ascending order
starting from the scheme which requires the least amount of changes in
the protocol. Extensive simulation results are presented using variable
number of nodes, number of gateways, node placement distributions,
packet retransmission attempts, and percentages of confirmed traffic.
The contributions of the paper are summarized as follows:
• An analysis of the current downlink status of LoRaWAN in the
EU868 spectrum is given emphasizing at the limitations.
• The potential of the new recently introduced band for downlink
is discussed.
• Four new frequency and window arrangement plan schemes to
take advantage of the available spectrum that the newly intro-
duced band offers are proposed.
• A discussion of the advantages and disadvantages of the proposed
schemes is made focusing on their ‘‘implementability’’ and rank-
ing them based on the easiness of their integration in the native
LoRaWAN.
The rest of the paper is organized as follows: Section 2 gives the es-
sential technical background around LoRa and LoRaWAN, and presents
the related work. Section 3, discusses the limitations of the current
downlink status of the protocol while Section 4 presents the charac-
teristics of the new band in detail. Section 5 discusses the proposed
channel/band and receive window schemes stressing their advantages
and disadvantages. The evaluation setup and the results are presented
in Section 6, while special evaluation cases are presented in the A
and B. Finally, conclusions and ideas for future work are presented in
Section 7.
1
Commission Implementing Decision (EU) 2017/1483 of 8 August 2017
amending Decision 2006/771/EC on harmonization of the radio spectrum for
use by short-range devices and repealing Decision 2006/804/EC
304
Computer Communications 195 (2022) 303–314
Fig. 2. Default downlink windows after an uplink transmission in LoRaWAN Class A.
2. Background
This section describes the main LoRaWAN downlink policy which
is necessary for non-experts to understand the main concepts of this
work. It also briefly presents the related research in the literature.
2.1. Downlink policy in lorawan
Class A end-devices can choose between unconfirmed and confirmed
uplinks before each transmission. In the first case, no acknowledgment
is sent by the back-end system to the node. In the second case, an
acknowledgment may be sent by the network server to the end-device
through a gateway. The end-device has two chances to get the acknowl-
edgment via two receive windows (RX1 and RX2) that open one and
two seconds2 respectively after the uplink as it is shown in Fig. 2. The
channel and the SF used in RX1 are the same as the uplink. The channel
and the SF used in RX2 are fixed and the latter is communicated to
the end-device during the Over The Air Activation (OTAA)3 (otherwise
they must be hardcoded in the end-device’s memory if ABP is used).
The default RX2 SF is 12, however, SF12 quickly uses up the gateways’
duty cycle time, thus, lower values are usually used (e.g., SF9 in TTN,
see Table 2).
The end-device cannot know in advance if the ack will be trans-
mitted in the first or the second receive window. If it receives nothing
in the first window, it has to turn its radio on in the second window
as well. If nothing is received in RX2 either, the uplink packet is
retransmitted after some random time over a different uplink channel.
Apparently, retransmissions are translated to energy waste. Indeed,
the gateways can afford ack transmissions up to some certain amount
which is related by the duty cycle time resources within an hour per
band. If a gateway has used up these resources, no ack is possible to be
sent, causing retransmissions and an even higher traffic.
A weakness of the protocol is that it does not give the privilege to
the providers to add more channels in RX2 in order to increase the
downlink capacity. Providers can only indirectly increase the downlink
capacity by adding additional uplink channels which are also used
in RX1. However, RX2 capacity remains fixed. Moreover, due to the
limited room in the sub-GHz spectrum and due to the fact that LoRa
concentrators cannot listen to more than 8 channels at the same time,
the total number of uplink channels can be increased only by 5.
2.2. Related research
The negative impact of the downlink traffic on LoRaWAN per-
formance is stressed by many works in the literature [6–10]. Using
simulations for a smart metering application, Varsier et al. [6] showed
that the performance degrades fast when downlink traffic is applied.
2
The times represent the default protocol values, however, the network
server may override these values using the RXParamSetupReq command which
is piggypacked in the join-accept packet during registration.
3
This is the default end-device registration procedure in LoRaWAN where
the encryption keys are calculated in two phases using some parameters in
the join-request and join accept packets along with a hardcoded app key.
On the contrary, in Activation By Personalization (ABP), the keys and other
parameters are hardcoded.
D. Zorbas Computer Communications 195 (2022) 303–314

Table 1
Related articles studying the downlink capabilities of LoRaWAN.
Ref. Examined topic(s) Proposed solution(s) and ideas Up.+Down.
Channels
[6] Simulation study for a smart metering application. The – 1+1
packet delivery ratio drops significantly for confirmed
transmissions.
[7] Simulation study of intra/inter-SF collisions and downlink – 5+1
traffic. The negative effect of the downlink traffic is
mentioned.
[8] Simulation study of LoRaWAN in an urban environment. The – 3+1
negative effect of the downlink traffic is also invistigated.
[9] Simulation study to confirm among others the negative effect – 3+1
of downlink traffic
[10] Description of the problems associated with the presence of Three solutions are proposed: a) use of multiple gateways, b) Not mentioned
downlink traffic and proposed solution to mitigate the parallel downlink transmissions using SF orthogonality (not
problems. currently supported by any LoRa hardware), and c) more
effective selection of the gateway by the Network Server.
[11] Experimental study using a small testbed to show the Use of secondary channels to set priority classes among the 8+1
negative effect of the downlink traffic. Use of 5 additional nodes and increase the efficiency for prioritized classes.
channels to enhance the downlink performance.
[12] The effect of the downlink traffic modeled and implemented a) use of multiple gateways, b) multiple unconfirmed uplinks 1+1
around NS-3 is investigated. instead of one confirmed uplink
Current Simulation study to assess the use of an extra downlink band Four proposed channel, band, and window arrangement 8+(1+4)
in the EU868 spectrum. schemes to efficiently take advantage of the extra time
resources of Band 47b.

Similar evidences are found by Markkula et al. [7] in their theoretical Table 2
TTN uplink (U) and downlink (D) LoRaWAN bands and channels for EU868. (St. Fr. =
work.
Starting Frequency).
Pop et al. [9] went a step further and mentioned that retrans-
Band Usage Downlink St. Fr. BW Duty SF
missions cause a large drop in packet success rate. This statement Window (MHz) (kHz) Cycle
is supported by other studies as well [13,14]. Indeed, the number
U/D RX1 868.0 125 7-12
of retransmissions plays a critical role because it rapidly increases 48 U/D RX1 868.2 125a ≤ 1% 7–12
the demand for acknowledgments after some failures. This is also U/D RX1 868.4 125 7–12
connected to the waiting time before retransmitting the packet, to the U/D RX1 867.0 125 7–12
channel over which the new transmission is performed as well as to the U/D RX1 867.2 125 7–12
distribution of nodes to different channels for prioritized events [11]. 47 U/D RX1 867.4 125 ≤ 1% 7–12
U/D RX1 867.6 125 7–12
In conclusion, as it is summarized in Table 1, there is a consensus U/D RX1 867.8 125 7–12
that the limited downlink performance of LoRaWAN is mainly due
54 D RX2 869.525 125 ≤ 10% 9
to the time resources saturation caused by the radio duty cycle re-
a
strictions on the gateways [15,16]. Apparently, the problem can be 250 kHz with SF7 is also allowed.

solved to some extend by deploying additional gateways [10,12] but

this increases the deployment as well as the maintenance cost. Van
den Abeele et al. [12] also mention the possibility to send multiple where AvgToA𝑖 corresponds to the average transmission time (Time-
uplinks – instead of using acks – to increase the probability of receiving on-Air - ToA) in band 𝑏𝑖 and is given by:
a packet. This can increase the packet success rate compared to the ∑𝑐𝑖
𝑇 𝑅𝑋1
𝑗=1 𝑓𝑗
transmission of acks, however, a more sophisticated solution is required AvgToA𝑖 = , (2)
for reliability-sensitive applications. Di Vincenzo et al. [10] also pro- 𝑐𝑖
pose a number of solutions to increase the downlink capacity which where 𝑐𝑖 is the number of transmissions acknowledged in band 𝑏𝑖 , 𝑇𝑓𝑅𝑋1
𝑗
among the non-mentioned ones (i.e., multiple gateways, adjustable
is the downlink time of transmission 𝑗 using SF 𝑓𝑗 (𝑗 ∈ [1, 𝑐𝑖 ]) and 𝑇𝑓𝑅𝑋2
′
retransmissions, multiple consecutive uplinks) is the use of a more bal-
is the downlink transmission time in RX2 over SF 𝑓 ′ . 𝑓𝑗 is equal to
anced gateway selection algorithm at the network server. Nonetheless,
the SF used for the corresponding uplink 𝑗 while 𝑓 ′ is fixed for all the
the improvement cannot be high because the current available time
transmissions. Moreover, all 𝑏𝑖 RX1 bands and the single RX2 channel
resources upper limit the downlink time.
have duty cycle limits, 𝛿𝑖𝑅𝑋1 and 𝛿 𝑅𝑋2 , respectively.
It is straightforward that a more rigid solution to increase the
downlink capacity is required. How to efficiently use the available In Europe, the LoRa Alliance defines at least three channels for
spectrum that the recently announced Band 47b offers for LPWAN is uplink transmissions [17]. However, a network provider can extend
the study of this paper. this list to include additional bidirectional channels. For example, The
Things Network (TTN) use the frequencies summarized in Table 2.
Two bands with a total of eight channels are used for uplink and
3. Current downlink status of lorawan
downlink transmissions (RX1), where each band has 1% radio duty
cycle limit. A separate channel with up to 10% duty cycle can be used
LoRaWAN’s downlink capacity depends on regional settings and
for downlink transmissions in the second receive window (RX2). As it
on the number of channels and bands used for uplink and downlink
is already mentioned, TTN prefer to use SF9 for RX2 transmissions in
transmissions. Assuming that 𝑏1 ...𝑏𝑘 is the set of available bands for RX1
and that there is one channel for RX2, the maximum downlink capacity their channel frequency plans.
of a LoRaWAN cell per hour is given by the following formula: Given the TTN settings, Eq. (1) can be written as follows:
⌊ ⌋ 2 ⌊
∑𝑘
3600𝛿𝑖𝑅𝑋1 ⌊
3600𝛿 𝑅𝑋2
⌋ ∑ 36𝑐𝑖 ⌋ ⌊ 360 ⌋
= + , (1) = ∑𝑐𝑖 𝑓
+ ′
, (3)
𝑖=1
AvgToA𝑖 𝑇𝑓𝑅𝑋2
′ 𝑖=1 𝑇 𝑗 𝑇2𝑓
𝑗=1 1

305
D. Zorbas Computer Communications 195 (2022) 303–314

𝑓 𝑓′
where 𝑇1 𝑗 and 𝑇2 can be calculated using the LoRa over-the-air Table 3
New downlink LoRa channels.
calculator [18] with 𝑓𝑗 ∈ [7, 12], 𝑓 ′ = 9, BW125, and a payload
Band U/D Downlink Frequency BW Duty
of 12 Bytes. The downlink payload consists of 1 Byte for the MAC
Window (MHz) (kHz) Cycle
header, 4 Bytes for the message integrity check (MIC), and 7 Bytes
54 D RX2 869.525 125 ≤ 10%
for the frame header. Additional bytes may be used if commands are
D RX2 865.6–865.8 125
encapsulated into the downlink packet [19]. Assuming no commands, D RX2 866.2–866.4 125
47b ≤ 10%
CR=4/5, and 8 preamble symbols, the downlink time in RX1 lasts from D RX2 866.8–867.0 125
41.216 ms (SF7, BW125) to 1155.072 ms (SF12, BW125), while the D RX2 867.4–867.6 125
second receive window lasts 144.384 ms (SF9, BW125). To give an
example, if all the nodes use SF7, a LoRaWAN cell can acknowledge
up to 873 transmissions per RX1 band and up to 2493 transmissions in 4. A new recently introduced downlink band
RX2. This results in a total downlink capacity of 4239 transmissions
per hour. For a typical average packet rate of 12 packets per hour Recent regulations of spectral usage in the EU unlock 4 channels
(i.e., 1 packet per 5 min), the previous theoretical maximum number with up to 500 mW ERP and 10% radio duty cycle shared amongst all
of transmissions corresponds to 353 nodes. Apparently, this number 4 channels for LoRaWAN gateways [5]. The presence of an additional
decreases as higher average SFs are used for the corresponding uplink band with 10% duty cycle dedicated for downlinks is apparently a
transmissions as well as if packet collisions are taken into account. big asset for the downlink performance of the protocol. On one hand,
this practically means that the downlink time can be doubled and
From Eq. (1) and (3), we can observe that the contribution of RX2
roughly a double number of uplinks can be confirmed in RX2 (if all
to the total capacity is fixed while RX1’s contribution depends on the
the available spectrum is dedicated to RX2). Moreover, since the band
SF of the corresponding uplinks as well as on the distribution of nodes
can be divided in four channels, redundancy increases in presence of
in the available spectrum bands. In fact, downlink time may reserve up multiple gateways because up to four gateways in the same area can
to 12% of the total time in a TTN cell, thus, the maximum blocking send out acknowledgments simultaneously without their transmissions
probability (i.e., the probability a transmitting node finds the gateway colliding with each other. On the other hand, downlink transmissions in
in downlink mode) is 0.12. In other words, 88% of the total time the last channel may collide with uplink transmissions in one or more
can be used for uplinks which – considering also a high level of SF uplink channels (see Tables 2 and 3). Furthermore, an up to 10% more
orthogonality – results in a total uplink capacity of multiple times the downlink time implies an up to 10% more uplink blocking time per
capacity of the downlink. It must also be noted that uplinks which gateway.
overlap with the duration of the downlink will fail as well causing
additional ‘‘deaf’’ time. Thus, it is easy to understand that LoRaWAN 5. Revisiting downlink channels & window plans
has not been designed to support a high volume of confirmed traffic.
The purpose of this section is to propose a number of frequency ar-
A weakness of current LoRaWAN design is that it does not al-
rangement plans and downlink channel modifications in the protocol in
low the network operators to add more downlink channels and, thus,
order to improve the downlink performance. All the proposed schemes
increase capacity. This can only be done for bidirectional channels use the standard LoRaWAN policy which opens two receive windows
which, however, cannot be used explicitly for downlink transmissions. after each confirmed uplink. However, the main issue to be addressed is
In other words, adding more bidirectional channels, the uplink capacity how the available downlink channels (bands) can be distributed evenly
increases as well, so the problem of the low downlink/uplink ratio among the nodes in one or both receive w. The proposed schemes are
still exists. Moreover, we should never forget that LoRa transceivers ordered according to the least number of protocol changes they require
are half-duplex. This means that adding new directional downlink to operate using the recently introduced downlink band in the EU868
channels, the downlink time increases, but the available uplink time spectrum.
decreases which leads to a higher probability of blocked packets.
It should also be noted that using the default LoRaWAN values 5.1. 5Rx2-SF: Division by SF
for RX2, the downlink capacity is limited to 25 nodes only. TTN
The idea of this scheme is to equally divide the 10+10% downlink
trade downlink capacity of lower SFs with that of higher SFs. This is
time of Bands 54 and 47b in RX2 to two group of nodes based on their
because by using SF9 for RX2, only uplink transmissions with SF7-9
SF. The solution assumes that the distribution of the nodes in the cell
can be acknowledged in RX2, while transmissions with SF10-12 can
is known. For example, assuming that the nodes are uniformly placed
only be acknowledged in RX1. Apparently, this is a good choice for in the cell and 𝑅12 is the maximum range that can be achieved with
deployments where the majority of the nodes are deployed close to SF12 (see Fig. 3), the area that each SF occupies in the disk of range
the gateway but the network would suffer from poor performance if a 𝑅12 , reveals the percentage of nodes that each disk zone can have. Let
large number of nodes used the three higher SFs. Thus, we can notice us denote with 𝑁 the number of deployed nodes. Then, the theoretical
𝐴𝑟𝑒𝑎𝑆𝐹
here that a clear weakness of LoRaWAN is the fixed data rate of the number of deployed nodes per SF zone is 𝑁 2 , where 𝐴𝑟𝑒𝑎𝑆𝐹 is
𝜋𝑅12
second receive window. That is, uplink transmissions performed on a given by the following equation:
low SF may be acknowledged using a higher SF in RX2 which causes a {
waste of resources. The only advantage of using a fixed and higher RX2 𝜋𝑅27 , if SF = 7,
𝐴𝑟𝑒𝑎𝑆𝐹 = (4)
data rate than the uplink transmission is the case of link asymmetries. 𝜋𝑅2𝑆𝐹 − 𝜋𝑅2𝑆𝐹 −1 , if SF > 7.
However, the higher allowed transmission power of the RX2 channel The problem of finding the optimal division in two groups is trans-
(27dBm) compared to the uplink transmission (14dBm) permits an up formed to a partition problem [20] as follows:
to 13 dB better received power at the node which most likely eliminates |∑ |
| 𝑘 𝐴𝑟𝑒𝑎𝑖 ∑ 𝐴𝑟𝑒𝑎𝑗 ||
𝑙
the problem of link asymmetry. min || 𝑁 − 𝑁 |, (5)
| 𝑖=1 𝜋𝑅12 𝑗=1 𝜋𝑅12 |
2 2
The only solution to the limited downlink capacity of LoRaWAN is | |
the deployment of multiple gateways. Indeed, the available downlink where 𝑘 and 𝑙 are the number of items of the two groups respectively.
time increases linearly with every additional gateway, however, so it The partition problem is NP-Complete, however, because the num-
does the cost of the deployment. ber of possible solutions is only 26 − 1, it can easily be solved by brute

306
D. Zorbas
Fig. 3. Theoretical SF coverage zones.
force. Moreover, since 𝑁 is a constant, the optimal solution does not
depend on 𝑁. The optimal distribution of nodes in two groups given
their minimum SF value is [SF7, SF10, SF11] and [SF8, SF9, SF12],
respectively. All nodes in the first group can share the single channel
in Band 54, while nodes of the second group can use 3 channels of
Band 47b. The solution can be adjusted accordingly for other node
distributions (see Appendix A).
Advantages. The advantage of this scheme is the implementation
simplicity; neither the nodes nor the gateways need to know any other
information apart from what channel is assigned to what SF for RX2.
The nodes can use the channel that corresponds to their uplink SF in
RX2. Therefore, the implementation is extremely easy by just hardcod-
ing this information to the nodes’ non-volatile memory. Alternatively,
this can be done by adjusting the list of channels field in the join-accept
message during the OTAA registration. Moreover, the scheme works
regardless the number of nodes (at least for the uniform distribution).
Disadvantages. The solution depends on the theoretical distri-
bution of the nodes in the cell which may not be known or may
considerably differ from the actual one. Furthermore, the scheme as-
sumes that all the nodes send confirmed data with the same rate, and
thus, occupy similar downlink resources. Finally, some of the available
channels in Band 47b may not be used.
5.2. 5Rx2-BND: Division by band
In this scheme, the nodes are divided in two equal-size groups as
long as they register to the network. The nodes of Band 47b are also
equally spread in the four available channels. This results in roughly
𝑁∕2, 𝑁∕8, 𝑁∕8, 𝑁∕8, 𝑁∕8 members for the five available channels of
the two bands, respectively.
Advantages. The scheme does not require any prior channel knowl-
edge from the nodes. A moderate number of modifications is required
in the protocol, such as a new field in the join-accept message to specify
the RX2 channel of the registered end-device.
Disadvantages. As with the previous one, the scheme assumes that
all the nodes send confirmed data with the same rate, and thus, occupy
similar downlink resources. Moreover, the network server needs to keep
track of the registered nodes and of the available resources over time.
5.3. 5Rx2-toa: Division by packet rate
This scheme divides the nodes in two equal-traffic groups based
on their confirmed uplink activity. The solution assigns a channel to
the nodes as long as they register to the network but it is very likely
to need to redo that in the near future since the packet rate is not
307
Computer Communications 195 (2022) 303–314
known in advance (see disadvantages). As an alternative approach, it
is proposed the user to declare the maximum required packet rate of
the application during registration. This action eliminates or mitigates
the need for channel re-assignment through gateway downlinks but it
requires changes in the registration process.
Advantages. The scheme does not require any prior channel knowl-
edge from the nodes. The solution works even for variable packet rates
per node.
Disadvantages. The disadvantage of the approach is that the net-
work server needs to constantly keep track of the confirmed uplink
activity of the nodes, assign, and also re-assign certain number of nodes
to a different band and channel. Since the packet rate of the nodes is
not known in advance, this must be done through additional downlink
packets for commands. That practically means that modifications need
to be made in the ADR mechanism but also in the back-end system.
As some band or channels may get congested, water-filling algorithms
need to periodically run to balance the load between the bands and
channels. As a consequence, the system must be capable of periodically
sending a batch of downlinks to certain nodes. Even if the gateways
have the time resources to do so, the transmission of the downlinks will
take considerable amount of time due to the low data rates of higher
SFs in RX2. For these reasons, the solution is very likely to be unscalable
especially at the presence of many hundreds of nodes.
5.4. 10Prx1: 10% duty cycle windows
Because the RX1 channels can get congested very quickly due to the
1% duty cycle, the nodes waste energy waiting for an acknowledgment
that may never arrive. To solve this issue, this scheme uses 10% duty
cycle bands in both RX1 and RX2. In RX1, it maps the first 4 uplink
channels to the single downlink channel of Band 54, while the last 4
uplink channels are mapped to the 4 downlink channels of Band 47b
(if less than 8 uplink channels are used, the division can be done in
a similar way). The uplink channels are not used for downlink in this
scheme (except of the 867.4MHz channel which exists in both 47 and
47b bands). This means that the total theoretical downlink time is 2
percentage points lower than the other schemes. Finally, the SF in RX1
is the same as the SF used in the corresponding uplink.
Advantages. The implementation of the channel mapping is very
easy and does not require any additional knowledge from the nodes.
Disadvantages. The scheme requires radical changes in the proto-
col so that the end-devices use different channels in RX1 than those
used for the corresponding uplinks. This implies that the devices must
specify during the registration what versions they can support in order
to co-exist with the current versions of the protocol.
5.5. Variants
It is easy to understand that the new downlink band and channels
can be arranged in RX1 and RX2 in many different ways. For example, a
variant of the already presented schemes is to equally divide the nodes
(or traffic) in all 5 RX2 channels instead of bands. The assignment
can still be done as long as the nodes register to the network or be
predefined similar to 5RX2-SF. For example, in 5RX2-BAND someone
could assign more nodes to Band 47b (4𝑁/5) because of the existence
of 4 channels compared to only one in Band 54. In this way, we can
assess the effect of multiple orthogonal downlink channels in Band 47b.
6. Evaluation & discussion of the results
The purpose of this section is to evaluate the four LoRaWAN
schemes as they were presented in Section 5. Since this is the first
work dealing with channel and band arrangement using Band 47b, the
schemes are compared only to the default LoRaWAN policy.
D. Zorbas Computer Communications 195 (2022) 303–314

6.1. Simulator Table 4

Simulation parameters.
Parameter Value
To do so, LoRaWAN-SIM simulator4 [21] was modified to support
the new downlink band and the proposed channel and window arrange- Simulation time 1M sec (∼ 11.6 days)
Nodes 100–1200
ment schemes. The simulator incorporates the following characteristics
Gateways 1 or 3
and features: Terrain size (1 gateway) 1500 × 1500 m
Terrain size (3 gateways) 2500 × 2500 m
• multiple half-duplex gateways, Nodes position Random (Uniform/Gaussian)
• multiple bands and channels, Gateways position Random uniform
• 1% radio duty cycle per band for uplink transmissions, Spreading Factors 7–12
Channel bandwidth (BW) 125 KHz
• two receive windows (RX1, RX2) for ACKs and commands,
Preamble symbols 8
• 1 and 10% radio duty cycle for downlink transmissions, Coding Rate 4/5
• imperfect-orthogonal SF transmissions, SFs for RX 1/2 SF7–12/SF9
• capture effect, Uplink/Downlink channels 8/8+5 (8/5 for 10pRX1)
Payload size Variable (see Table 5)
• path-loss signal attenuation with shadowing model,
𝐿𝑝𝑙 (𝑑0 ) = 110 dBm, 𝑑0 = 40 m,
• collision handling for both uplink and downlink transmissions, Path loss model
𝛾 = 2.08, 𝜎𝑑𝐵𝑚 = 3.57
• full LoRaWAN header overhead, Receiver sensitivities Typical Semtech SX1276
• node energy consumption model, Tx power 2, 7, 14 dBm (ADR adjustable)
• ADR for Tx power and SF adjustment, Max energy consumptions
75, 45, 30, 0 mA [23]
(Tx, Rx, Idle, Sleep)
• confirmed and non-confirmed traffic, Voltage 3.3 V
• periodic and exponential packet generation, Packet rate (Gaussian) [2..15 min] with 𝜇 ∼=5 min
• variable or fixed packet sizes, Retransmissions 8 (see Appendix B for 1)
• detailed statistics and SVG terrain generation.

The SF of the nodes is initially determined based on the distance to Table 5

Maximum data payload per SF (without
the nearest gateway assuming that there is enough gap (now arbitrary overheads).
set to 10 dB to confront power fluctuations due to environmental SF Payload (bytes)
changes) between the received power and the sensitivity threshold.
7–8 222
Environmental changes are modeled through the use of a random 9 115
Gaussian variance 𝜎𝑑𝐵𝑚 in the path-loss equation (see [22]). Apart from 10–12 51
that, the nodes start with the highest transmit power but this may be
later adjusted by the Network Server after the first uplink transmissions.
This is done by encapsulating the margin into downlink packets from
The packet rate of each end-device is selected randomly in the
a gateway to the node. As a consequence, in terms of fairness, nodes
range [2..15 min] while the average value is ∼5 min (a pseudo-
close to the gateway transmit – on average – with much less power
Normal distribution is applied so that the majority of the nodes are
compared to nodes which are located far from the gateways (i.e., nodes
within [4..6 min]). The way the rates are generated causes an irregular
with higher SFs).
distribution of transmissions through time and different total number of
transmissions per node. It is assumed that each node’s clock drifts over
6.2. Settings
time and, thus, repeated collisions are avoided by slightly randomizing
the next transmission within 1 s. The distribution of the nodes to
All schemes were tested in a number of scenarios such as (a)
downlink channels (wherever this is required) is done randomly among
multiple node populations, (b) multiple gateways, (c) the presence of
the nodes for each run. The payload size for each node is also randomly
non-confirmed traffic, (d) the presence of non-periodic traffic, and (e)
decided at the beginning of each simulation and according to the
the non-uniform node placement. Two main evaluation metrics are
maximum supported payload size in LoRaWAN (see Table 5). All the
recorded and discussed; the packet delivery ratio (PDR) and the energy
results presented in the figures correspond to averages of 50 runs
consumption. For confirmed packets, PDR is defined as the ratio of the
with different node/gateway placements, different selection of initial
total number of acknowledged uplinks divided by the total number of
transmission times, and different node distribution to channels. The
unique packet transmissions. For unconfirmed packets, PDR is the ratio
node population range as well as the packet rates are selected in such a
between the successfully delivered and the total transmitted packets.
way that conclusions are easy to be made. The 95% confidence intervals
The energy consumption is calculated according to experimental data
are shown on each figure.
for the reception, transmission, and idle power consumption [23]. The
Table 4 summarizes the simulation parameters.
idle power consumption is added to represent sensing and processing
In total, six schemes are evaluated; the default LoRaWAN policy
expenditures. Other evaluation metrics are the downlink unfairness and
with one fixed channel in RX2, the four schemes mentioned in the
the downlink availability in both receive windows. The unfairness is
previous section, and a variant which splits the nodes in five equal
defined as the standard deviation of the ratio between the number
groups and assigns a channel to each of these groups. All six groups
of packets that were successfully acknowledged by the application are mentioned in the figures as ‘‘1RX2’’ (legacy LoRaWAN), ‘‘5RX2-SF’’,
server (through a gateway) and the number of confirmed packets that ‘‘5RX2-Bnd’’, ‘‘5RX2-ToA’’, ‘‘10pRX1’’, and ‘‘5RX2-Ch’’, respectively.
have been received by the application server. The further the ratio of
a node from the average ratio value over all nodes, the higher the 6.3. Results
unfairness for that examined node. For example, if the average ratio is
8/10, a node whose ratio is 1/10 presents a high unfairness because The results are divided in subsections where each subsection rep-
the percentage of successfully acknowledged uplinks is much lower resents an evaluation metric, starting from the PDR, followed by the
than the average. The standard deviation provides an image of such energy consumption, and ending with the downlink unfairness and
unfairness over the entire node population. gateway availability. More than 120 figures have been generated for
combinations of evaluation metrics, deployment scenarios, type of traf-
4
https://github.com/deltazita/LoRaWAN-SIM fic, retransmissions, and node/gateway populations. For presentation

308
D. Zorbas
Fig. 4. Packet Delivery Ratio for a scenario with a single gateway (upper) or 3 gateways (lower), periodic packet transmission (1 packet every 5 min), and variable number of
nodes.
purposes and because the Gaussian node placement ones do not present
any significant change compared to the uniform node placement, only
the latter case is presented in this section while the rest of the cases are
placed in the A and B.
6.3.1. Packet delivery ratio
Fig. 4 presents the PDR results for one and three gateways respec-
tively. The results reveal that the approaches which require a higher
number of protocol modifications exhibit a better performance. For
example, selecting 10% duty cycle channels for RX1 (10pRX1), leads
to the best PDR, while distributing the nodes to channels according
to their SF (5RX2-SF) leads to the least improvement. 5RX2-Bnd and
5RX2-ToA present an almost identical performance because both of
them divide the nodes in two equal band groups. The different packet
rate does not affect the performance because the average downlink
traffic per group is almost the same. The two approaches are further
compared with unequal load per band and the results will be discussed
at the end of this subsection. Dividing the nodes in 5 equal groups, one
for each downlink channel, leads to an average performance but much
better than the default LoRaWAN. It is worth mentioning that switching
to a higher number of gateways, the performance gap between the
approaches becomes larger. This is because the total downlink capacity
is proportional to the average number of gateways that each node can
reach. For example, the total maximum available downlink time with 3
gateways in native LoRaWAN is 36% (3 times 12%) while the downlink
time in 10pRX1 is 60%! In such a case, 10pRX1 provides an up to
309
Computer Communications 195 (2022) 303–314
215% improvement over the default LoRaWAN policy for the examined
scenarios.
In Fig. 5a,b, we vary the percentage of confirmed traffic instead
of the number of nodes. We observe that, for this scenario, when
the confirmed traffic is up to 40%, there is almost no performance
gain when using the additional downlink band. The opposite holds
beyond that threshold. The threshold increases or decreases depending
on how much uplink traffic (confirmed or unconfirmed) is generated
(i.e., according to the average packet rate). For example, in Fig. 5c,d,
the same scenario is examined, this time using the half of the previous
packet rate. The approaches start to detach from each other after
a 60%–70% of confirmed traffic. In the same figure, we observe a
declining trend in PDR which increases again after a certain percentage
of confirmed traffic. This occurs because the unconfirmed packets have
only one chance to be delivered as no retransmissions occur. On the
contrary, as the number of confirmed packets gets higher, the average
PDR increases again because these packets have a higher probability to
get delivered and acknowledged (up to 8 retransmissions are allowed).
It is easy to understand that some schemes cannot handle the high
volume of confirmed traffic and their performance rapidly declines
(e.g., 5RX2-SF).
Unequal traffic per band. The next couple of paragraphs present a
special case when the total traffic between the two downlink bands is
unequal. Schemes which divide the nodes in two groups, one for each
band (e.g., 5RX2-Bnd), are affected by the distribution of the traffic
that each node can generate in the band. This is because these schemes
D. Zorbas Computer Communications 195 (2022) 303–314

Fig. 5. Packet Delivery Ratio for a scenario with variable number of confirmed traffic. The number of nodes is set to 500 and 1200 for 1 and 3 gateways, respectively.

Fig. 6. Appendix c: Packet Delivery Ratio for a scenario with 3 gateways, periodic packet transmission (1 packet every 5 min).

cannot know in advance how much traffic each node is going to pro-
duce, so they divide the available node population in two equal parts.
In the previous simulations, the nodes were randomly (but uniformly)
assigned to the two bands causing little or almost no difference in
their total downlink traffic. As a consequence, 5RX2-Bnd and 5RX2-ToA
presented an almost identical performance.
However, to understand the benefit of the re-allocation of traffic in
bands that 5RX2-ToA performs, an extreme case scenario is examined,
where the difference in traffic between the two downlink bands is
considerably high. In reality, this may never happen but moderate
traffic differences can be possible. Fig. 6 presents some indicative
PDR results for a network with 3 gateways and variable number of

310
D. Zorbas
Fig. 7. Energy consumption for a scenario with a single gateway (upper) or 3 gateways
(lower), periodic packet transmission, and variable number of nodes.
nodes of confirmed traffic percentages. The results reveal a very slight
improvement in the case of variable number of nodes but a high
improvement when the confirmed traffic varies. This happens because
5RX2-Bnd cannot know during registration which nodes will generate
confirmed traffic and which not; thus, it handles all nodes as equal
and allocates some downlink space in one of the two bands. This
implies that the confirmed traffic may be squeezed in a narrower space
compared to 5RX2-ToA which allocates space dynamically and based
on the confirmed traffic status.
6.3.2. Energy consumption
As it was expected, the energy consumption has an inversely propor-
tional behavior to PDR. As we see in Fig. 7, the energy consumption can
be improved considerably when using the new downlink band. Appar-
ently, this behavior is strongly connected with the increased downlink
capacity, and thus, to the lower probability of having retransmissions.
Similarly with the PDR, when the extra downlink band is used in the
first receive window, the gains are higher. The same behavior appears
in the scenario where the number of nodes is fixed and the percentage
of confirmed traffic varies (see Fig. 8. As with the PDR, the use of the
new downlink band makes difference when more than 40% of the total
packets are confirmed. The results do not change for lower packet rates
or other node placement distributions.
6.3.3. Gateway availability and downlink unfairness
Fig. 9 depicts the percentage of times where none of the gateways
was available to send an acknowledgment in the first receive window
(top) and in any of the receive windows (bottom). This is an indication
of how quickly a frequency band can use up its resources due to the
311
Computer Communications 195 (2022) 303–314
Fig. 8. Energy consumption for a scenario with a single gateway (upper) or 3 gateways
(lower), periodic packet transmission, and variable percentage of confirmed traffic. The
number of nodes is set to 500 and 1200 for 1 and 3 gateways, respectively.
radio duty cycle restrictions. We remind that when no ack is received
in RX2, this means that no ack was received in RX1 either. Looking
at the results, we observe that most schemes suffer from high gateway
unavailability in the first receive window, which means that the nodes
turn on their radio in RX1 wasting energy. In native LoRaWAN, when
the number of nodes is 1200, there is an only 6% difference in unavail-
ability between RX1 and RX2. The same percentage is 53% in 10pRX1,
and 72% in 5RX2-Bnd which indicates how much better they handle
the traffic in RX2.
Finally, Fig. 10 illustrates the downlink unfairness for the same
scenarios with 3 gateways. We remind that unfairness is defined as
the standard deviation of the ratio between the number of packets that
were successfully acknowledged by the application server (through a
gateway) divided by the number of confirmed packets that have been
received by the application server. The higher the value, the higher
the dispersion of the ratio, thus, the lower the fairness among the
nodes. We observe that all the schemes are quite fair; none of them
exceeds an unfairness of 0.25 in any scenario. 5RX2-SF seems to be a bit
more unfair probably because the random node allocation to channels
sometimes leads to less flexibility when some channels get slightly more
congested than others.
7. Conclusions & future work
The introduction of Band 47b in the EU868 spectrum brings up new
opportunities for downlink transmission in LoRaWAN. In order to take
full advantage of the available space in the spectrum, changes are re-
quired to be made to the protocol and especially to the channels/bands
D. Zorbas
Fig. 9. Gateway unavailability: Percentage of times where no gateway was available
in RX1 (upper) and RX2 (lower) for a scenario with 3 gateways, periodic packet
transmission, and variable number of nodes.
arrangement in LoRaWAN receive windows. Four different schemes are
described and their advantages and disadvantages are discussed. These
four schemes, as well as a related variant, are extensively evaluated and
compared to the legacy LoRaWAN through simulation means.
The results show that, in general, the higher the number of changes
required to the protocol, the better the performance of the scheme.
Assigning a 10% duty cycle band to the first receive window gives by
far the best results in all evaluated metrics (i.e., packet delivery ratio,
energy consumption, and fairness). Dividing the number of nodes in
two equal size downlink bands is also a good option. The reallocation of
nodes to other bands according to the amount of downlink traffic they
generate has sense only when the distribution of the traffic in bands
is highly unequal. Finally, the allocation of nodes to fixed channels
instead of bands leads to average results but better ones compared to
the SF-based allocation.
In the future, the co-existence of the presented schemes with the
native LoRaWAN in the same network will be examined. For example,
it will be interesting to see what is the minimum required percentage
of nodes which follow the new schemes to get a certain performance
gain while some other nodes in the network follow the older version of
the protocol.
CRediT authorship contribution statement
Dimitrios Zorbas: Conceptualization, Methodology, Software, Visu-
alization, Writing- Original draft preparation, Writing- Reviewing and
Editing, Funding acquisition.
312
Computer Communications 195 (2022) 303–314
Fig. 10. Unfairness (the lower, the better) for a scenario with 3 gateways, periodic
packet transmission, and variable number of nodes (upper) or percentages of confirmed
traffic (lower).
Declaration of competing interest
The authors declare the following financial interests/personal rela-
tionships which may be considered as potential competing interests:
Dimitrios Zorbas reports financial support was provided by Nazarbayev
University.
Data availability
No data was used for the research described in the article.
Acknowledgments
This publication has emanated from research conducted with the
financial support of Nazarbayev University, Republic of Kazakhstan
grant No. 11022021FD2916 for the project ‘‘DELITMENT: DEtermin-
istic Long-range IoT MEsh NeTworks’’.
Appendix A. Gaussian node placement
In this appendix section, an analysis of the Gaussian node placement
for the 5RX2-SF scheme is presented. In this type of placement, the
positions of the gateways remain uniformly random while the nodes
are randomly placed around a gateway. The selection of the gateway
around which a node will be placed is also random, but this does not
mean that during the simulation, this particular node can communicate
only with that gateway. An example of placement using 3 gateways as
it was generated by LoRaWAN-SIM is given in Fig. A.11.
D. Zorbas Computer Communications 195 (2022) 303–314

Fig. A.11. A deployment with 3 gateways (red squares) and 300 nodes (dots) following
the normal distribution.

Fig. B.13. Appendix B: Packet Delivery Ratio and energy consumption for a scenario
with 3 gateways, periodic packet transmission (1 packet every 5 min), and variable
percentage of confirmed traffic.

In the case of a single gateway, the division by SF can be done in

the same way as with the uniform placement. Taking ( into account the
( )2 )
1 1 𝜒−𝜇
Probability Density Function (PDF) 𝑓 (𝜒) = √ exp − 2 and
𝜎 2𝜋 𝜎
the finite ring-shaped area of each SF range (𝑅𝑆𝐹 ), the number of nodes
for each SF can be easily found by calculating the probability of a node
to be placed in the SF ring area as follows:

∞ ∞
𝑃 𝑆𝐹 = 1 2 (𝑥, 𝑦)𝑓𝑋,𝑌 (𝑥, 𝑦)𝑑𝑥𝑑𝑦
∫−∞ ∫−∞ 𝑥2 +𝑦2 <𝑅𝑆𝐹
( 2 ) (A.1)
𝑅
= 1 − exp − 𝑆𝐹 .
2𝜎 2
It is assumed that 𝑃 𝑆𝐹 12 = 1, that the gateway is placed at (0, 0) (so
𝜇𝑥 and 𝜇𝑦 are zero in PDF) and that there is a variance 𝜎 which defines
how far from the gateway a node can be placed.
Solving the equivalent partition problem for the set of SFs assuming
Fig. B.12. Appendix B: Packet Delivery Ratio and energy consumption for a scenario 𝜎 = 400 (the value was selected so that the average SF is ∼8), the
with 3 gateways, periodic packet transmission (1 packet every 5 min), and variable
two groups of SF are defined as [7, 9] and [8, 10, 11, 12]. This is a
number of nodes.
reasonable result given that most of the nodes are closer to the gateway.
The simulation results slightly differ in absolute values to those of the
uniform placement but the performance trend of the schemes is exactly
the same.

313
D. Zorbas
Appendix B. Less retransmissions
This appendix section presents results in the scenario where the
number of retransmissions is one (default LoRaWAN value). As we can
see in Figs. B.12 and B.13, the performance of the 6 schemes is closer to
each other. The packet delivery ratio and the energy consumption are
lower because of the lower number of retransmissions. Nevertheless,
the trend and the order of schemes is the same as with the higher
number of retransmissions.
References
[1] J. Haxhibeqiri, E. De Poorter, I. Moerman, J. Hoebeke, A survey of LoRaWAN
for IoT: from technology to application, Sensors 18 (11) (2018) 3995.
[2] W.A. Jabbar, T. Subramaniam, A.E. Ong, M.I. Shu’Ib, W. Wu, M.A. de Oliveira,
LoRaWAN-based IoT system implementation for long-range outdoor air quality
monitoring, Internet Things 19 (2022) 100540.
[3] D. Bankov, E. Khorov, A. Lyakhov, Mathematical model of LoRaWAN channel
access, in: WoWMoM, 2017, pp. 1–3.
[4] P. Gkotsiopoulos, D. Zorbas, C. Douligeris, Performance determinants in LoRa
networks: a literature review, IEEE Commun. Surv. Tutor. 23 (3) (2021)
1721–1758.
[5] Semtech Corporation, How to qualify a LoRaWAN device in europe,
2018, Online; https://lora-developers.semtech.com/?ACT=72&fid=30&aid=48_
0znCpZpvImL3agza59hG&board_id=1. (Accessed 10 May 2022).
[6] N. Varsier, J. Schwoerer, Capacity limits of LoRaWAN technology for smart
metering applications, in: IEEE International Conference on Communications,
IEEE, 2017, pp. 1–6.
[7] J. Markkula, K. Mikhaylov, J. Haapola, Simulating LoRaWAN: On importance of
inter spreading factor interference and collision effect, in: ICC 2019-2019 IEEE
International Conference on Communications, ICC, IEEE, 2019, pp. 1–7.
[8] A. Farhad, D.-H. Kim, J.-Y. Pyun, Scalability of LoRaWAN in an ur-
ban environment: a simulation study, in: 2019 Eleventh International
Conference on Ubiquitous and Future Networks, ICUFN, IEEE, 2019,
pp. 677–681.
314
Computer Communications 195 (2022) 303–314
[9] A.-I. Pop, U. Raza, P. Kulkarni, M. Sooriyabandara, Does bidirectional traffic
do more harm than good in LoRaWAN based LPWA networks? in: GLOBECOM
2017-2017 IEEE Global Communications Conference, IEEE, 2017, pp. 1–6.
[10] V. Di Vincenzo, M. Heusse, B. Tourancheau, Improving downlink scalability in
LoRaWAN, in: ICC 2019-2019 IEEE International Conference on Communications,
ICC, IEEE, 2019, pp. 1–7.
[11] K. Mikhaylov, J. Petäjäjärvi, A. Pouttu, Effect of downlink traffic on performance
of LoRaWAN LPWA networks: Empirical study, in: 2018 IEEE 29th Annual
International Symposium on Personal, Indoor and Mobile Radio Communications,
PIMRC, IEEE, 2018, pp. 1–6.
[12] F. Van den Abeele, J. Haxhibeqiri, I. Moerman, J. Hoebeke, Scalability analysis
of large-scale LoRaWAN networks in ns-3, IEEE Internet Things J. 4 (6) (2017)
2186–2198.
[13] M. Centenaro, L. Vangelista, R. Kohno, On the impact of downlink feedback on
LoRa performance, in: IEEE 28th Annual International Symposium on Personal,
Indoor, and Mobile Radio Communications, PIMRC, IEEE, 2017, pp. 1–6.
[14] M. Capuzzo, D. Magrin, A. Zanella, Confirmed traffic in LoRaWAN: Pitfalls
and countermeasures, in: 2018 17th Annual Mediterranean Ad Hoc Networking
Workshop, Med-Hoc-Net, IEEE, 2018, pp. 1–7.
[15] A.H. Jebril, R.A. Rashid, A systematic literature review on downlink frames in
LoRaWAN, Comput. Electr. Eng. 101 (2022) 108006.
[16] J.M. Marais, A.M. Abu-Mahfouz, G.P. Hancke, A survey on the viability of
confirmed traffic in a LoRaWAN, IEEE Access 8 (2020) 9296–9311.
[17] Technical Committee, LoRaWAN™ 1.1 regional parameters, 2017, LoRa Alliance.
[18] Semtech Corporation, LoRa modem design guide, 2013, Online; https://lora-
developers.semtech.com/library/product-documents/. (Accessed 11 May 2020).
[19] LoRa Alliance Technical Committee, LoRaWAN™ 1.1 specification, 2017, On-
line; lora-alliance.org/sites/default/files/2018-04/lorawantm_specification_-v1.1.
pdf. (Accessed 17 September 2019).
[20] S. Chopra, M.R. Rao, The partition problem, Math. Program. 59 (1) (1993)
87–115.
[21] D. Zorbas, C. Caillouet, K. Abdelfadeel Hassan, D. Pesch, Optimal data collection
time in LoRa networks—a time-slotted approach, Sensors 21 (4) (2021).
[22] M.Z. Win, P.C. Pinto, L.A. Shepp, A mathematical theory of network interference
and its applications, Proc. IEEE 97 (2) (2009) 205–230.
[23] D. Zorbas, K. Abdelfadeel, P. Kotzanikolaou, D. Pesch, TS-LoRa: time-slotted
LoRaWAN for the industrial internet of things, Comput. Commun. 153 (2020)
1–10.