Citation for published version
Adelantado, F., Vilajosana, X., Tuset-Peiro, P., Martinez, B., Melià-Seguí,
J. & Watteyne, T. (2017). Understanding the limits of LoRaWAN. IEEE
Communications Magazine, 55(9), 34-40
DOI
https://doi.org/10.1109/MCOM.2017.1600613
Document Version
This is the Submitted Manuscript version.
The version in the Universitat Oberta de Catalunya institutional repository,
O2 may differ from the final published version.
Copyright and Reuse
This manuscript version is made available under the terms
of the Creative Commons Attribution Non Commercial No Derivatives
licence (CC-BY-NC-ND)
http://creativecommons.org/licenses/by-nc-nd/3.0/es/, which permits
others to download it and share it with others as long as they credit you,
but they can’t change it in any way or use them commercially.
Enquiries
If you believe this document infringes copyright, please contact the
Research Team at: repositori@uoc.edu
Universitat Oberta de Catalunya
Research archive
This work has been accepted for publication in IEEE Communications Magazine in January 2017. Please, cite the IEEE
Communications Magazine.
Understanding the Limits of LoRaWAN
Ferran Adelantado, Xavier Vilajosana, Pere Tuset-Peiro, Borja Martinez, Joan Melià-Seguí, Thomas Watteyne,
ABSTRACT
Low-Power Wide Area Networking (LPWAN) technology
offers long-range communication, which enables new types
of services. Several solutions exist; LoRaWAN is arguable
the most adopted. It promises ubiquitous connectivity in
outdoor IoT applications, while keeping network structures,
and management, simple. This technology has received a lot
of attention in recent months from network operators and
solution providers. Yet, the technology has limitations that
need to be clearly understood to avoid inflated expectations
and disillusionment. This article provides an impartial and
fair overview of what the capabilities and the limitations of
LoRaWAN are. We discuss those in the context of use cases,
and list open research and development questions.
I. INTRODUCTION
Network operators are starting to deploy horizontal M2M
solutions to cover a wide set of large scale verticals, using Low
Power Wide Area Networking (LPWAN) technologies [1],
[2]. Application domains include smart city, metering, on-
street lighting control or precision agriculture. LPWAN tech-
nologies combine low data rate and robust modulation to
achieve multi-km communication range. This enables simple
star network topologies that simplify network deployment and
maintenance [3]. While the benefits of these technologies are
known and are often considered as the key enablers for some
applications, their limitations are still not well understood [4],
[5].
In this article we aim to provide an impartial overview of
the limitations of LoRaWAN [6], one of the most successful
technologies in the LPWAN space. LoRaWAN is a network
stack rooted in the LoRa physical layer. LoRaWAN features a
raw maximum data rate of 27 kbps (50 kbps when using FSK
instead of LoRa), and claims that a single gateway can collect
data from thousands of nodes deployed kilometers away. These
capabilities have really resonated with some solution providers
and network operators, who have created a large momentum
behind LoRaWAN to the point that it is sometimes touted as
the connectivity enabler for any IoT use case [7].
The goal of this article is to bring some sanity to these
statements, by providing a comprehensive, fair and inde-
pendent analysis of what the capabilities and limitations of
LoRaWAN are. We adopt a pragmatic approach, and identify
in which use cases the technology works, and in which use
cases it doesn’t work. Section II provides an overview of
LPWAN technologies, including cellular. Section III describes
F. Adelantado, P. Tuset-Peiro, B. Martinez and J. Melià-Seguí are with IN3
at the Universitat Oberta de Catalunya.
X. Vilajosana is with IN3 at Universitat Oberta de Catalunya and World-
sensing.
T. Watteyne is with Inria, EVA-team, Paris, France.
LoRaWAN technology in details. Section IV analyzes the
network capacity and scale limitations of the technology. Sec-
tion V discusses the use cases where LoRaWAN works/doesn’t
work. Section VI lists open research and development chal-
lenges for the technology. Section VII concludes.
II. OVERVIEW OF LPWAN AND CELLULAR
TECHNOLOGIES FOR IOT
A. Low-Power Wide-Area Alternatives
Although LoRaWAN is one of the most adopted technolo-
gies for IoT, there is a wide range of LPWAN technologies
in the market, such as Ingenu, Weightless W, N and P or
SigFox [8].
Ingenu developed a proprietary LPWAN technology in the
2.4 GHz band, based on Random Phase Multiple Access
(RPMA) to provide M2M industry solutions and private
networks. The main asset of Ingenu in comparison with
alternative solutions is high data rate up to 624 kbps in the
uplink, and 156 kbps in the downlink. On the contrary, the
energy consumption is higher and the range is shorter (a range
around 5-6 km) due to the high spectrum band used.
The Weightless Special Interest Group developed a set of
three open standards for LPWAN: Weightless-W, Weightless-N
and Weightless-P. Weightless-W was developed as a bidirec-
tional (uplink/downlink) solution to operate in TV whitespaces
(470-790 MHz). It is based on narrowband FDMA channels
with Time Division Duplex between uplink and downlink; data
rate ranges from 1 kbps to 1 Mbps and battery lifetime is
around 3-5 years. Weightless-N was designed to expand the
range of Weightless-W and reduce the power consumption (a
battery lifetime up to 10 years) at the expense of data rate
decrease (from up to 1 Mbps in Weightless-W to 100 kbps in
Weightless-N). Unlike Weightless-W, Weightless-N is based
on the Ultra Narrow Band (UNB) technology and operates
in the UHF 800-900 MHz band; it provides only uplink
communication. Finally, Weightless-P is proposed as a high-
performance two-way communication solution that can operate
over 169, 433, 470, 780, 868, 915 and 923 MHz bands.
However, cost of the terminals and power consumption are
higher than in Weightless-N, with a battery lifetime of 3-8
years.
Together with LoRaWAN, SigFox is one of the most
adopted LPWAN solutions. It is a proprietary UNB solution
that operates in the 869 MHz (Europe) and 915 MHz (North
America) bands. Its signal is extremely narrowband (100 Hz
bandwidth). It is based on Random Frequency and Time
Division Multiple Access (RFTDMA) and achieves a data rate
around 100 bps in the uplink, with a maximum packet payload
of 12 Bytes, and a number of packets per device that cannot
exceed 14 packets/day. These tough restrictions, together with
arXiv:1607.08011v2 [cs.NI] 13 Feb 2017
a business model where SigFox owns the network, have some-
what shifted the interest to LoRaWAN, which is considered
more flexible and open.
B. Cellular solutions for IoT
The 3
rd
Generation Partnership Project (3GPP) standard-
ized a set of low cost and low complexity devices target-
ing Machine-Type-Communications (MTC) in Release 13.
In particular, 3GPP addresses the IoT market from a three-
fold approach by standardizing the enhanced Machine Type
Communications (eMTC), the Narrow Band IoT (NB-IoT) and
the EC-GSM-IoT [9].
eMTC is an evolution of the work developed in Release
12 that can reach up to 1 Mbps in the uplink and downlink,
and operates in LTE bands with a 1.08 MHz bandwidth. NB-
IoT is an alternative that, thanks to the reduced complexity,
has a lower cost at the expense of decreasing data rate (up
to 250 kbps in both directions). Finally, EC-GSM-IoT is an
evolution of EGPRS towards IoT, with data rate between 70
and 240 kbps.
Although the approaches proposed by 3GPP reduce the
energy consumption and the cost of the devices, they have
not yet caught up their non-3GPP counterparts. For instance,
module cost for LoRaWAN and SigFox is around $2-5 and for
eMTC is still around $8-12. Despite the expected broad adop-
tion of cellular IoT solutions supported by 3GPP, LoRaWAN
presents some assets to prevail against these technologies in
specific market niches. Current assets are: i) the number of
LoRaWAN network deployments is increasing continuously
while, on the other hand, few initial NB-IoT deployments have
been already deployed; ii) LoRaWAN operates in the ISM
band whereas cellular IoT operates in licensed bands; this
fact favours the deployment of private LoRaWAN networks
without the involvement of mobile operators; iii) LoRaWAN
has backing from industry, e.g. CISCO, IBM or HP, among
others. In the future, both technologies will probably coexist
when 3GPP solutions will be backed up by large volumes.
III. OVERVIEW OF LORAWAN
LoRa is the physical layer used in LoRaWAN. It features
low power operation (around 10 years of battery lifetime),
low data rate (27 kbps with spreading factor 7 and 500 kHz
channel or 50 kbps with FSK) and long communication range
(2-5 km in urban areas and 15 km in suburban areas). It
was developed by Cycleo (a French company acquired by
Semtech). LoRaWAN networks are organized in a star-of-stars
topology, in which gateway nodes relay messages between
end-devices and a central network server. End-devices send
data to gateways over a single wireless hop and gateways are
connected to the network server through a non-LoRaWAN
network (e.g. IP over Cellular or Ethernet). Communication
is bi-directional, although uplink communication from end-
devices to the network server is strongly favoured, as it will
be explained in the following [6].
LoRaWAN defines three types of devices (Class A, B and
C) with different capabilities [6]. Class A devices use pure
ALOHA access for the uplink. After sending a frame, a Class
A device listens for a response during two downlink receive
windows. Each receive window is defined by the duration,
an offset time and a data rate. Although offset time can be
configured, the recommended value for each receive window
is 1 sec and 2 sec, respectively. Downlink transmission is only
allowed after a successful uplink transmission. The data rate
used in the first downlink window is calculated as a function
of the uplink data rate and the receive window offset. In the
second window the data rate is fixed to the minimum, 0.3
kbps. Therefore, downlink traffic cannot be transmitted until
a successful uplink transmission is decoded by the gateway.
The second receive window is disabled when downlink traffic
is received by the end-device in the first window. Class A
is the class of LoRaWAN devices with the lowest power
consumption. Class B devices are designed for applications
with additional downlink traffic needs. These devices are syn-
chronized using periodic beacons sent by the gateway to allow
the schedule of additional receive windows for downlink traffic
without prior successful uplink transmissions. Obviously, a
trade-off between downlink traffic and power consumption
arises. Finally, Class C devices are always listening to the
channel except when they are transmitting. Only class A must
be implemented in all end-devices, and the rest of classes must
remain compatible with Class A. In turn, Class C devices
cannot implement Class B. The three classes can coexist in
the same network and devices can switch from one class to
another. However, there is not a specific message defined by
LoRaWAN to inform the gateway about the class of a device
and this is up to the application.
The underlying PHY of the three classes is the same.
Communication between end-devices and gateways start with
a Join procedure that can occur on multiple frequency channels
(e.g. in EU863-870 ISM Band there are 3 channels of 125 kHz
that must be supported by all end-devices and 3 additional
125 kHz channels) by implementing pseudo-random channel
hopping. Each frame is transmitted with a specific Spreading
Factor (SF), defined as SF = log
2
(R
c
/R
s
), where R
s
is
the symbol rate and R
c
is the chip rate. Accordingly, there
is a trade-off between SF and communication range. The
higher the SF (i.e. the slower the transmission), the longer
the communication range. The codes used in the different
SFs are orthogonal. This means that multiple frames can be
exchanged in the network at the same time, as long as each
one is sent with one of the six different SFs (from SF=7 to
SF=12). Depending on the SF in use, LoRaWAN data rate
ranges from 0.3 kbps to 27 kbps.
The maximum duty-cycle, defined as the maximum percent-
age of time during which an end-device can occupy a channel,
is a key constraint for networks operating in unlicensed
bands. Therefore, the selection of the channel must implement
pseudo-random channel hopping at each transmission and be
compliant with the maximum duty-cycle. For instance, the
duty-cycle is 1% in EU 868 for end-devices.
The LoRa physical layer uses Chirp Spread Spectrum (CSS)
modulation, a spread spectrum technique where the signal
is modulated by chirp pulses (frequency varying sinusoidal
pulses) hence improving resilience and robustness against
interference, Doppler effect and multipath. Packets contain a
2
preamble (typically with 8 symbols), a header (mandatory in
explicit mode), the payload (with a maximum size between
51 Bytes and 222 Bytes, depending on the SF) and a Cyclic
Redundancy Check (CRC) field (with configurations that pro-
vide a coding rate from 4/5 to 4/8). Typical bandwidth (BW)
values are 125, 250 and 500 kHz in the HF ISM 868 and
915 MHz band, while they are 7.8, 10.4, 15.6, 20.8, 31.2,
41.7 and 62.5 kHz in the LF 160 and 480 MHz bands. The
raw data rate varies according to the SF and the bandwidth,
and ranges between 22 bps (BW = 7.8 kHz and SF = 12) to
27 kbps (BW = 500 kHz and SF = 7) [2]. Frequency hopping
is exploited at each transmission in order to mitigate external
interference [10].
IV. CAPACITY AND NETWORK SIZE LIMITATIONS
In this section we study the LoRaWAN network scale with
respect to data rate, duty-cycle regulations, etc.
A. Network size limited by duty-cycle
Although the performance of LoRaWAN is determined by
PHY/MAC overviewed in Section III, the duty-cycle regula-
tions in the ISM bands [11], [12] arise as a key limiting factor.
If the maximum duty-cycle in a sub-band is denoted by d
and the packet transmission time, known as Time On Air, is
denoted by T
a
, each device must be silent in the sub-band
for a minimum off-period T
s
= T
a
(
1
d
− 1). For instance, the
maximum duty-cycle of the EU 868 ISM band is 1% and it
results in a maximum transmission time of 36 sec/hour in each
sub-band for each end-device. Fig. 1 shows the Time on Air
of a packet transmission with coding rate 4/5 over a 125 kHz
bandwidth channel. It is known that large SFs allow longer
communication range. However, as observed in Fig. 1, large
SFs also increase the time on air and, consequently, the off-
period duration. This problem is exacerbated by the fact that
large SFs are used more often than small SFs. For instance,
considering a simple scenario with end-devices distributed
uniformly within a round-shaped area centred at the gateway,
and a path loss calculated with the Okumura-Hata model for
urban cells [13], the probability that an end-device uses a SF
i, p
i
, would be p
12
= 0.28, p
11
= 0.20, p
10
= 0.14, p
9
= 0.10,
p
8
= 0.08 and p
7
= 0.19.
Although Listen Before Talk is not precluded in LoRaWAN,
only ALOHA access is mandatory. Accordingly, the Lo-
RaWAN capacity can be calculated roughly as the superposi-
tion of independent ALOHA-based networks (one independent
network for each channel and for each SF, since simultaneous
transmissions only cause a collision if they both select the
same SF and channel; no capture effect is considered). How-
ever, and in contrast to pure ALOHA, a LoRaWAN device
using SF i cannot exceed a transmitted packet rate given by
nd/T
a
i
, where n is the number of channels, d is the duty-cycle
and T
a
i
is the Time On Air with SF i.
In the simple scenario described above, if all end-devices
transmit packets at the maximum packet rate nd/T
a
i
, the num-
ber of packets successfully received by the gateway decreases
as shown in Fig. 2, where a network with n = 3 channels has
10 20 30 40 50
0
0.5
1
1.5
2
Time on Air (sec)
MAC payload size (Bytes)
SF=12
SF=11
SF=10
SF=9
SF=8
SF=7
Fig. 1. Time on Air of LoRaWAN with code rate 4/5 and a 125 kHz
bandwidth.
0 500 1000 1500 2000 2500 3000
0
100
200
300
400
500
600
700
800
Num. received packets/hour per node
Num. end-devices
Payload: 10 Bytes
Payload: 30 Bytes
Payload: 50 Bytes
Fig. 2. Number of packets received per hour when end-devices attempt
transmission at nd/T
a
i
packets/sec with coding rate 4/5 and n = 3 channels
with 125 kHz bandwidth.
been analyzed. The number of received packets drops due to
the effect of collisions.
In Fig. 3 the number of packets received successfully
per hour and end-device is shown for deployments with
{250, 500, 1000, 5000} end-devices and n = 3 channels. For
low transmission rate values (in packets/hour), throughput is
limited by collisions; for high values, the maximum duty-cycle
prevents end-devices from increasing the packet transmission
rate and stabilizes the throughput. For deployments with
a “small” number of end-devices, the duty-cycle constraint
limits the maximum throughput.
Table I summarizes the maximum throughput per end-
device and the probability of successful reception for a set
of different deployments. The maximum throughput falls as
3
0 500 1000 1500 2000 2500 3000 3500
0
50
100
150
200
250
300
350
400
Num. received packets/hour per node
Generated Packets/hour per node (λ)
N=250
N=5000
N=500
N=1000
Limited
by Duty
Cycle
Fig. 3. Number of 10 Bytes payload packets received per hour and node for
{250, 500, 1000, 5000} end-devices and n = 3 channels as a function of the
packet generation.
the number of end-devices grows.
B. Reliability and Densification drain Network Capacity
In LoRaWAN, reliability is achieved through the acknowl-
edgment of frames in the downlink. For class A end-devices,
the acknowledgment can be transmitted in one of the two
available receive windows; for class B end-devices it is trans-
mitted in one of the two receive windows or in an additional
time-synchronized window; for class C end-devices it can be
transmitted at any time .
In LoRaWAN the capacity of the network is reduced not
only due to transmissions in the downlink, but also due to
the off-period time following those transmissions (gateways
must be compliant with duty-cycle regulation). Therefore, the
design of the network and the applications that run on it
must minimize the number of acknowledged frames to avoid
the capacity drain. This side-effect calls into question the
feasibility of deploying ultra-reliable services over large-scale
LoRaWAN networks.
At this point of development of the technology, LoRaWAN
faces deployment trends that can result in future inefficiencies.
Specifically, LoRaWAN networks are being deployed follow-
ing the cellular network model, that is, network operators
provide connectivity as a service. This model is making
gateways to become base stations covering large areas. The
increase in the number of end-devices running applications
from different vendors over the same shared infrastructure
poses new challenges to coordinate the applications. In par-
ticular, each application has specific constraints in terms of
reliability, maximum latency, transmission pattern, etc. The
coordination of the diverse requirements over a single shared
infrastructure using an ALOHA-based access is one of the
main future challenges for the technology. Therefore, a fair
spectrum sharing is required beyond the existing duty-cycle
regulations. Finally, the unplanned and uncoordinated deploy-
ment of LoRaWAN gateways in urban regions, along with
the deployment of alternative LPWAN solutions (e.g. SigFox),
could cause a decrease of the capacity due to collisions and
due to the use of larger SFs (to cope with higher interference
levels).
V. USE CASES
Several application use cases are considered in order to
analyze the suitability of LoRaWAN and complement the
understanding of the advantages and limitations of the tech-
nology when applied to different types of data transmission
patterns, latency requirements, scale and geographic dispersion
among others.
A. Real Time Monitoring
Agriculture, leak detection or environment control are appli-
cations with a reduced number of periodic/aperiodic messages
and relaxed delay constraints. In contrast, the communication
range must be long enough to cope with dispersed location
of end-devices. LoRaWAN has been designed to handle the
traffic generated by this type of applications and meets their
requirements as long as the deployment of the gateways is
enough to cover all end-devices.
On the other hand, industrial automation, critical infrastruc-
ture monitoring and actuation require some sort of real time
operation. Real time is understood in general by low latency,
and bounded jitter and depends on the specific application. Lo-
RaWAN technology cannot claim to be a candidate solution for
industrial automation, considering for example that industrial
control loops may require response times around 1 ms to 100
ms and that, even for small packets of 10 Bytes, the time on
air with SF=7 is around 40 ms. As presented in the previous
section, due to the MAC nature of LoRaWAN, deterministic
operation cannot be guaranteed despite of application specific
periodicity as ALOHA access is subject to contention which
impacts network jitter. Despite that, small LoRaWAN networks
can deliver proper service to applications that require, for
instance, sampling data every second. To do that, two main
design considerations should be taken into account:
• The spreading factor should be as small as possible to
limit both the time on air and the subsequent off-period.
In other words, the gateway must be close enough to the
end-devices.
• The number of channels must be carefully designed
and must be enough to i) minimize the probability
of collisions (tightly coupled with the number of end-
devices) and ii) offer quick alternative channels for nodes
to retransmit collided packets thereby diminishing the
impact of the duty-cycle.
Despite the two aforementioned aspects, latency will not be
deterministic.
B. Metering
The LoRa Alliance is working on standard encapsulation
profiles for popular M2M and metering protocols. Keeping an
4
