sensors

Review
LoRaWAN Mesh Networks: A Review and
Classification of Multihop Communication
Jeferson Rodrigues Cotrim * and João Henrique Kleinschmidt
Center of Engineering, Modeling, and Applied Social Sciences, Federal University of the ABC,
Santo André 09210-580, Brazil; [email protected]
* Correspondence: [email protected]




Received: 11 July 2020; Accepted: 28 July 2020; Published: 31 July 2020


Abstract: The growth of the Internet of Things (IoT) led to the deployment of many applications
that use wireless networks, like smart cities and smart agriculture. Low Power Wide Area Networks
(LPWANs) meet many requirements of IoT, such as energy efficiency, low cost, large coverage area,
and large-scale deployment. Long Range Wide Area Network (LoRaWAN) networks are one of the
most studied and implemented LPWAN technologies, due to the facility to build private networks
with an open standard. Typical LoRaWAN networks are single-hop in a star topology, composed of
end-devices that transmit data directly to gateways. Recently, several studies proposed multihop
LoRaWAN networks, thus forming wireless mesh networks. This article provides a review of the
state-of-the-art multihop proposals for LoRaWAN. In addition, we carried out a comparative analysis
and classification, considering technical characteristics, intermediate devices function, and network
topologies. This paper also discusses open issues and future directions to realize the full potential of
multihop networking. We hope to encourage other researchers to work on improving the performance
of LoRaWAN mesh networks, with more theoretical and simulation analysis, as well as practical
deployments.

Keywords: internet of things; LPWAN; LoRaWAN; multihop; mesh networks

1. Introduction
The Internet of Things (IoT) aims to enable heterogeneous devices to communicate and cooperate
to provide smart services in different environments transparently to the user. In the next few years,
billions of IoT devices will be deployed around the world, enabling smart systems for different
applications [1]. Such applications include smart cities, smart farming, health care, manufacturing,
transportation, and many others [2]. Wireless networks are essential for these applications to cover a
wide area in a city, building, or a farm [3]. Typical wireless technologies used for this goal, such as
ZigBee, Bluetooth, and Wi-Fi, have a range of few meters or tens of meters [4]. They can use multihop
communication in mesh network topologies to expand the coverage area [5]. In recent years, the Low
Power Wide Area Networks (LPWAN) were developed to provide a feasible solution for applications
that require a wide area coverage and energy efficiency [6]. The most prominent technologies for
LPWAN are Long Range Wide Area Network (LoRaWAN) and SigFox in the unlicensed bands and
Long Term Evolution for M2M (LTEM) and Narrowband IoT (NB-IoT) [7] in the licensed bands.
Long Range (LoRa) is one the most used in applications because of the facility to develop private
networks operating in the unlicensed frequency bands (868 MHz in Europe and 915 MHz in USA and
Brazil) [8–11]. LoRaWAN technology promises long-range communication with low data rates and low
energy consumption. Some tests have shown that the technology may achieve several kilometers in
rural environments or open areas. However, in scenarios with obstacles or inside buildings, the range
achieved by LoRaWAN is significantly less due to attenuation and fading effects, resulting in packet

Sensors 2020, 20, 4273; doi:10.3390/s20154273 www.mdpi.com/journal/sensors

Sensors 2020, 20, 4273 2 of 21

losses and errors [11]. In urban areas, a lot of obstacles may degrade the signal, thus also decreasing
the coverage area. Rural areas are very dependent on the terrain topology, where a mountain could
create a shadow area, for example. A device in an adverse condition will require more power to
transmit, and by consequence, the energy consumption will increase and the lifetime of the device
will decrease. The LoRaWAN network is composed of end-devices that transmit data to gateways,
forming a star network topology. The specification allows only one hop between end-devices and the
gateway [8–10]. Multihop networks are well known for extending coverage and improving the energy
efficiency of wireless networks, extending battery life due to lower transmission power when compared
to single-hop networks. Some open research issues in LoRaWAN networks are the scalability and the
network capacity. Several works have shown that dense networks with many devices may degrade the
overall network performance with longer delays and low reliability [12–14]. LoRaWAN uses ALOHA
as the Medium Access Control (MAC) protocol, which does not perform well when traffic load or
node density increases, due to interference and packet collisions [15,16]. Multihop strategies may also
contribute to improve scalability, capacity, and reliability, as pointed in [12,15].
Many authors have proposed multihop solutions for LoRaWAN [17–40], where some devices act
as relays to other devices. The forwarding mechanism is a crucial choice for a multihop LoRaWAN,
as it may affect the performance of the network, in terms of throughput, reliability, latency, and energy
consumption. Some works propose mechanisms using intermediate nodes as a simple relay using
only LoRa physical layer, while others propose routing protocols, forming more complex mesh
networks. Another important choice in LoRaWAN is which node will be the intermediate node:
the end-device or the gateway. In this paper, we provide a comprehensive review of multihop
LoRaWAN networks, analyzing and classifying the existing proposals. With this classification, we give
a better understanding of the current situation of multihop LoRaWAN, identifying the most promising
approaches, and providing research challenges and future directions. The paper is organized as follows.
Section 2 introduces the LoRaWAN main concepts, and Section 3 presents related work on multihop
LoRaWAN networks. In Section 4, we present a classification of the devices and features to be used
in multihop LoRaWAN, while Section 5 presents network topologies and applications. In Section 6,
we discuss open issues and future research. Finally, Section 7 gives the final considerations.

2. LoRaWAN
LoRaWAN is a data link layer protocol developed by LoRa Alliance in 2015 to provide a low
power connectivity solution to battery-powered devices [8,41]. The current LoRaWAN specification
is 1.1 [9], and the most used specification is 1.0.3 [10]. The physical layer used by LoRaWAN is
called LoRa [42], developed by Semtech company and based on the Chirp Spread Spectrum (CSS)
modulation [43]. The CSS modulation uses a Spreading Factor (SF) to spread the information over the
frequency. The SFs are orthogonal to each other and define the number of chirps per signal symbol.
There are six possible SFs in LoRa networks, from 7 to 12, that determine the number of bits necessary
to transmit the same amount of data. A higher number of bits per symbol increases the capability
of the receiver to demodulate the message. Higher SF means that more bits are necessary to send
the same information. However, it is possible to deploy the end-device further from the gateway.
The orthogonality between SFs guarantees that different end-devices could transmit their packets
using the same frequency but using different SFs. There are three available bandwidths: 125, 250,
and 500 kHz. Usually, networks use a 125 kHz bandwidth. The relation between SF, bandwidth,
and packet size is essential to determine the Time on Air (ToA), which is the total time a single
transmission uses the air interface to send a packet. Two packets with the same size, using the same
bandwidth but with different SF, have completely different ToA. For comparison, to transmit a packet
with 50 bytes using 125 kHz bandwidth, the ToA is 0.113 s for SF 7, while using SF 12 the ToA is
2.62 s. Considering only the ToA, the latency to deliver a packet is at least 20 times higher with SF
12 than SF 7. A more detailed comparison, including other SFs, is found in [13]. The SF, bandwidth,
and packet size chosen directly affect the throughput of the link [44]. A device transmitting with a
Sensors 2020, 20, 4273 3 of 21

low value of SF has a higher throughput than a device transmitting with a high value of SF. However,
the increase in SF also increases the range of the transmission [45]. Table 1 summarizes the relation
between the SF, throughput, and ToA considering a packet with different payload sizes, 125 kHz
bandwidth, and without the duty cycle restrictions.

Table 1. Relation between Spreading Factor (SF), throughput, and Time on Air (ToA).

50 Bytes Payload Max Payload Size

SF ToA (s) Throughput (bits/s) Payload Max ToA (s) Throughput (bits/s)
7 0.113 3543.1 242 0.394 4913.7
8 0.205 1948.2 242 0.697 2777.6
9 0.369 1082.1 115 0.677 1358.9
10 0.698 572.8 51 0.698 584.5
11 1.478 270.5 51 1.479 275.9
12 2.629 152.1 51 2.793 146.1

LoRa uses Industrial, Scientific, and Medical (ISM) frequencies, and every country or region
has its frequency band. Europe uses 868 MHz, while the USA, Brazil, and Australia use 915 MHz,
for example. Each country also uses a sub-band frequency scheme to create channels of transmissions.
Each sub-band is composed of a number of frequencies called channels. Australia, for example,
uses sub-bands composed of eight channels (frequencies) using 125 kHz bandwidth. The sub-band is
essential to separate networks in the same area by using different frequencies. Figure 1 presents the
channel scheme for Europe (EU868), United States (US915), and Australia (AU915) [46]. The European
regulation specifies that the network channels can be freely attributed. However, all end-devices
shall implement the three default channels (868.1 MHz, 868.3 MHz, and 868.5 MHz). The United
States and Australia have a similar channel scheme with 64 uplink channels utilizing 125 kHz
bandwidth, and incrementing linearly by 200 kHz. Both regions also implement eight channels
with 500 kHz bandwidth and increment linearly by 1.6 MHz. The difference between US915 and
AU915 is the downlink channel. Both have eight channels utilizing 500 kHz bandwidth, but US915
uses a separated band from the uplink scheme, while in AU915 the downlink overlaps the uplink
frequencies. Countries and regions may also determine the amount of time one single device could
use the channel by implementing duty cycle restrictions. In Europe, the duty cycle is 1% [47].

...

Figure 1. Long Range Wide Area Network (LoRaWAN) channels for Europe, USA, and Australia.

Typically a LoRaWAN network is a star-of-stars topology composed by one or more gateways,

end-devices, and a LoRaWAN Network Server. Figure 2 presents the basic topology of a LoRaWAN
network. The end-devices are the nodes responsible for collecting data or actuating and generating
LoRaWAN packets. The gateway is responsible for receiving the LoRaWAN packets and forwarding
them to the LoRaWAN Network Server through an IP based network. It only handles in the physical
Sensors 2020, 20, 4273 4 of 21

layer, being unable to decode the packets and know their content. The LoRaWAN Network Server is a
short way to describe a more sophisticated element composed of three main components: a Network
Server, an Application Server, and the Join Server. The main functions of the LoRaWAN Network
Server are as follows.

• Network Server: It is the central element of a LoRaWAN network responsible for managing the
MAC layer. The Network Server is responsible for many management functions in the network,
such as the verification of the end-devices addresses, packet acknowledgment, frame count,
and answers to end-devices requests. Furthermore, the Network Server forwards the messages to
the Application Server and Join Server, and manages the downlink messages queue.
• Application Server: The Application Server is responsible for forwarding all received packets
from the Network Server to the specific associated application. In the same way, a message from
one application is forwarded by the Application Server to the Network Server.
• Join Server: The Join Server takes care of the end-devices authentication process, generating
and distributing the authentication keys. There are two authentication methods allowed on a
LoRaWAN network: the Activation by Personalization (ABP) and the Over-The-Air Activation
(OTAA). Section 2.1 describes both authentication methods in detail.

LoRaWAN
Join Server Network
Server

Gateway Network Server

Application
End-Devices Server

Figure 2. Typical LoRaWAN network.

The end-devices transmit their data to one or more gateways, and the gateways forward the
message to the Network Server. No communication between end-devices is allowed in the default
standardization. The end-devices follow one of the three possible classes of operation, as shown in
Figure 3.

• Class A: In this class, end-devices can send packets at any time they want. After each transmission,
the end-device must open one or two reception windows. If the end-device receives a packet in
the first reception window, the second one will be kept close. All end-devices must join a network
in Class A mode and, according to the Network Server request, can change their behavior to
another operation class. The ALOHA protocol controls the medium access since it is suitable
for energy-constrained applications. However, the ALOHA protocol is well known to provide
low network throughput in dense networks because of a high number of packet collisions [15,16].
The ALOHA limitation in LoRaWAN was already discussed in terms of scalability and reliability
in several works [12,48].
• Class B: Defines a mechanism that allows end-devices to open more reception windows than
the default ones. The end-device will open periodically new reception windows following the
Network Server demands. The gateway and end-devices use a beacon message to get synchronism
between them. The new reception windows receive the ping name.
Sensors 2020, 20, 4273 5 of 21

• Class C: Opens the two reception windows and keeps the second one open until the next uplink
transmission. Class C must be used only by non-energy constrained devices.

Transmission
Class A (Time-on-Air)
Rx1 Rx2

Rx Delays

Ping Interval
Transmission
Class B Bcn Ping Ping Ping Bcn
(Time-on-Air)

Beacon Interval

Transmission
Class C (Time-on-Air)
Rx2 Rx1 Rx2

Figure 3. LoRaWAN classes.

LoRaWAN end-devices implement a mechanism called Adaptive Data Rate (ADR) to improve
the use of network resources. Based on data collected from the end-device, the Network Server could
request this end-device to change its characteristics, such as the SF, the bandwidth, or the transmission
power. Each country may specify a different Data Rate (DR) [49], which is a number related to a
specific bandwidth and SF, used to inform the end-devices of the new characteristics of the ADR
process. Each end-device decides who is responsible for managing the ADR: the end-device itself
or the Network Server.

2.1. LoRaWAN Security

Information security is an essential requirement for all IoT levels, and the LoRaWAN protocol
was developed to provide a secure connection to all the devices. Furthermore, the security solution
to the LoRaWAN networks also concern about energy consumption, low levels of complexity,
low cost, and high scalability [50]. LoRaWAN provides end-to-end security, from the end-device
to the application, using the standard AES cryptographic algorithm.
Every end-device has a unique identifier called DevEUI, an application identifier called AppEUI,
and a application key called AppKey. The AppKey is used to generate the Network Session Key
(NwkSKey) and the Application Session Key (AppSkey). The NwkSKey is used to provide integrity to
the data and MAC commands. The AppSKey provides end-to-end cryptography. The LoRaWAN
implements two different network join methods handled by the Join Server to authenticate an
end-device [51].
The first authentication method is called ABP, which specifies that all the information necessary to
authenticate a device is previously set up in the end-device and the Join Server. The ABP mode excludes
the need of the end-device to exchange authentication messages with the Join Server. The network
manager is responsible for managing the join procedure.
The second method is called OTAA and requires a handshake between the end-device and the
Join Server. Only end-devices can initiate a join procedure, and they do it every time a new device
wants to join a network or a device loses connection with the Network Server. The end-device starts the
join procedure sending a join request message to the Join Server that will accept or not the entrance of
the end-device on the network. The Join Server sends back a join accept if the end-device is authorized
to join the network. When the Join Server receives the join request, it generates the NwkSKey and stores
it in the Network Server. The Join Server also creates the AppSKey and stores it in the Application
Server. Both keys (NwkSKey and AppSKey) are sent to the device with the join accept. Figure 4
presents the LoRaWAN security architecture with the respective authentication keys.
Sensors 2020, 20, 4273 6 of 21

Join Server LoRaWAN

NwkSKey Network
Server
AppSKey

Network Application
Server Server

End-Device Gateway

Figure 4. LoRaWAN security architecture.

3. Related Work
This section presents an overview of the existing works in multihop for LoRaWAN. In general,
all approaches consider intermediate nodes (end-devices or gateways) to expand the coverage of the
network. A packet transmitted by an end-device will be forwarded by the intermediate nodes until it
reaches a gateway connected to a Network Server. These intermediate devices may perform simple
relay functions or complex routing protocols.
Table 2 presents a summary of existing works on multihop LoRaWAN, showing the protocol
level used (LoRa or LoRaWAN); the scenario used for testing; and if the work is a theoretical proposal
(T), a simulation (S), or a practical testbed (P). It can be seen that some works consider only the LoRa
physical layer, while others use LoRaWAN characteristics. Most of the previous work are practical
implementations of the aforementioned proposals.

Table 2. Related work on multihop LoRaWAN.

Paper Lora/LoRaWAN T S P Scenario

Abrardo and Pozzebon [21] LoRa x underground
Anedda et al. [20] LoRaWAN x general
Aslam et al. [37] LoRaWAN x smart cities
Azhari [52] LoRa x linear
Bezunartea et al. [53] LoRa x general
Bor et al. [17] LoRa x University Campus
Choi et al. [36] LoRaWAN x general
Dias and Grilo [24] LoRaWAN x linear and bootleneck
Diop and Pham [33] LoRa x farm
Duong and Kim [22] LoRaWAN x University Campus
Dwijaksara et al. [30] LoRaWAN x general
Ebi et al. [27] LoRa / LoRaWAN x urban underground monitoring
Farooq [40] LoRa x general
Flauzac [54] Lora/LoRaWAN x general
Haubro et al. [29] LoRa x general
Huh and Kim [55] LoRaWAN x urban/industrial
Kim and Jang [56] LoRaWAN x general
Lee and Ke [23] LoRa x University Campus
Liao et al. [18] LoRa x x x multiple-building area networks (MBAN)
Lundell et al. [19] LoRaWAN x linear and warehouse
Mai and Kim [25] LoRaWAN x smart cities
Misbahuddin et al. [39] LoRaWAN x x ring
Ochoa et al. [38] LoRa x general
Sartori et al. [28] LoRa x general
Sisinni et al. [31] LoRaWAN x industrial
Sisinni et al. [32] LoRaWAN x industrial
Tanjung et al. [35] LoRaWAN x general
Weiwei Zhou and Wang [34] LoRaWAN x urban
Zhu et al. [26] LoRa x x general
Sensors 2020, 20, 4273 7 of 21

3.1. Routing Proposals

Several works that introduce multihop networking propose the use of a routing protocol, either
based on existing protocols for ad hoc and mesh networks, or even new solutions. The “LoRa
for the Internet of Things” article was the first work proposing a multihop LoRa-based network
in 2016 [17]. The authors proposed a new protocol called LoRaBlink that works over the LoRa
physical layer and aims to cover several points not specified by LoRAWAN v1.0, including multihop
communication. The protocol integrates MAC and routing at the same layer in a synchronous flooding
based protocol. The work evaluated the protocol in a university campus, in a testbed composed of six
nodes and one sink deployed in different places. The results have shown that 80% of the packets were
reliably delivered.
In [18], the authors proposed the use of Concurrent Transmission Protocol (CT), a novel flooding
routing protocol successfully used in IEEE 802.15.4 networks. The CT protocol does not demand
a routing table, and the flooding mechanism does the synchronization of the nodes. The results
for the indoor proposed scenario showed that the protocol enhances the coverage of LoRa and
achieves a reliable packet delivery rate. The authors do not present an energy consumption analysis of
the protocol.
The work presented in [19] combines the Hybrid Wireless Mesh Protocol (HWMP) and Ad hoc
On-Demand Distance Vector (AODV) protocol to create a lightweight protocol for LoRa. The proposed
solution works with the deployment of intermediate nano-gateways (which do not implement
full LoRaWAN), and the routing mechanism is transparent to end-devices and the network server.
The protocol is evaluated only in terms of route construction delays.
The authors of [20] proposed an energy-efficient multihop communication solution (e2McH)
where routes are constructed based on energy consumption, residual battery life, and traffic rate.
Simulations results show an improvement of 15% in energy consumption compared to the single-hop
LoRaWAN.
In [21], the authors proposed a linear multihop communication over LoRa to monitor the ancient
underground water distribution systems in Siena, Italy. The authors used a simple routing protocol
and a synchronization mechanism, where the end-devices use a wake-up time transmission scheme
to minimize energy consumption. The results showed that the proposed solution is reliable, and the
synchronization mechanism reduces the energy consumption by 50% when comparing to non-optimal
wake-up time. A linear topology may be the only viable option in some applications, such as mines and
pipelines. In [22], the authors also considered a linear multihop network based on LoRa. They proposed
a simple routing protocol to enhance the coverage area. The authors also added a synchronization
mechanism to the end-devices and implemented the protocol in a real environment. The performance
was analyzed using the throughput and reliability of the testbed, without power consumption analysis.
The work in [23] proposed a routing protocol over a LoRa physical layer based on a child-list to
create routes. It uses a polling-based approach, where the devices listen to requests of the gateway.
Battery-powered end-devices are used as intermediate nodes. The solution was tested at the university
campus and in an indoor building. The results showed the increase of packet delivery rate using the
multihop approach compared to direct transmission. They also showed that the number of nodes in
the network that could transmit simultaneously decreases compared to the star topology.
The authors of [24] adapted the Destination-Sequenced Distance Vector (DSDV) routing protocol
to work in LoRaWAN. The proposed solution classifies the nodes into two types: the routing nodes
and the leaf ones, where the routing devices are non-energy constrained. The authors tested the
solution in linear and bottleneck scenarios in a prototype system. They conclude the solution is feasible
even for the duty cycle limitations.
The research in [25] proposed a full protocol solution over LoRa physical layer, including TDMA
access, collision avoidance, synchronization, and routing mechanism to provide a low latency solution.
The authors deployed end-devices on a university campus to do the tests. The results showed that
Sensors 2020, 20, 4273 8 of 21

the protocol has high data reliability and low latency, but energy consumption was not analyzed.
They concluded that the proposed solution is suitable for agriculture applications and in tunnels.
The authors of [26] presented a networking clustering based on the spreading factor to improve
the performance of multihop LoRa networks. They proposed a tree-based SF clustering algorithm
(TSCA), which assigns the nodes to several subnets. The strategy explored the possibility of parallel
transmission in LoRa using multiple SFs. The authors analyzed the solution with simulation and
practical scenarios, and they concluded that an efficient multihop LoRaWAN network needs to consider
the SF allocation.
The work in [27] proposed a new architecture to LoRaWAN to solve the problem of monitoring
underground infrastructure. The architecture is composed of sensor nodes forming a LoRa mesh
network sending data to a repeater node, which acts as a sink for the sensors. The repeater node
communicates directly with the main gateway, and it may be a simple battery-powered end-device not
connected to the Internet. While the sensor nodes act as routers in the mesh network, the repeater node
acts as a relay that forwards the messages to the gateway. The authors conducted two field tests as a
proof-of-concept. Both repeater and router nodes are energy-constrained, single-channel (repeater with
two radios), and implement a synchronization mechanism. The results showed the improvement in
the packet delivery ratio for underground devices, but no energy consumption analysis was presented.
The first proposal of routing protocol in a LoRa network, using a typical IP stack, was presented
in [28]. The authors proposed a new MAC layer to deal with IPv6 Routing Protocol for Low Power and
Lossy Network (RPL) routing protocol, and conclude that enabling RPL over LoRa is an open issue and
needs to be better tested. In [29], the authors propose to use the Time Slotted Channel Hopping (TSCH)
protocol over LoRa physical layer to provides a multihop IPv6-based solution. The experiments testbed
include real devices, and the authors demonstrated the possibility to implement an IPv6 network
over LoRa.
In [30], the authors state that many routing proposals for LoRaWAN do not consider constraints
such as packet size, duty cycle, and time for downlink transmission. They proposed a new class
G to the LoRaWAN standards, where they include a gateway-to-gateway communication using a
routing protocol based on AODV. The authors used a simulation scenario to validate the proposal and
concluded the communication gateway-to-gateway had a reasonably good performance in terms of
throughput and delay.

3.2. Relay Proposals

The intermediate nodes used to form multihop networks may perform simple tasks comparing to
routing, that is, acting only as repeaters. We call these nodes as relay nodes, that retransmit the packets
received to the next node, without the need of establishing routes. Although simpler than routing,
this approach may be attractive for LoRaWAN, since routing protocols may include unnecessary
complexity, thus consuming more resources of the constrained devices. Relay nodes may also act as a
sink for a mesh network, as presented in [27] and discussed in the previous subsection.
Only in 2018, the first papers started to present solutions using relay nodes. In [31], the authors
proposed a new device to the LoRaWAN networks called e-Node, which is a relay node developed
using a multichannel and non-energy constrained gateway. The main idea is to increase the coverage
area with a transparent node to the network. In [32], the same authors used an industrial scenario to
validate and implement a proof-of-concept prototype of the e-Node, but using an end-device as an
intermediate node. They measured several messages delays and concluded the proposed solution
could improve the coverage of the network with high reliability of packets sent by distant end-devices.
The work in [33] proposed to use a simple relay device to increase the LoRaWAN coverage area
for rural areas. The authors suggested deploying the relay nodes knowing the places that are not
covered by the gateway. The authors proposed a simple message forwarder and a synchronization
mechanism. They showed that energy consumption decreases with the addition of the relay node to
deliver the packets. They also notice an increase in the coverage area and reliability.
Sensors 2020, 20, 4273 9 of 21

In [34], the authors created a hybrid intermediate device capable of executing the ABP join
procedure of remote nodes, while being validated by the network server using OTAA. This mechanism
avoids the remote nodes to do the OTAA and decreases the number of messages on the network.
However, the authors do not discuss any mechanism to forward the data packets. In the results,
they showed the packet delivery rate achieves 100% in the proposed scenarios.
The research in [35] proposed a multihop technique based on three main mechanisms:
opportunistic forwarding, opportunistic transmission, and networking coding. The relay node will
only transmit the packets of end-devices that send their packets to the gateway without success.
The simulation results presented a similar packet delivery rate compared to directed transmission or
simple multihop. However, the proposed mechanism requires fewer transmissions.
The work proposed in [36] uses an Automatic Repeat Request (ARQ) mechanism and relay nodes
to improve reliability on LoRa networks. The relay nodes chose the best parent to transmit the data
based on collected RSSI. The authors implemented a real testbed on a university campus and presented
results only for packet reliability.
In [37], the authors analyzed two architectures for multihop LoRaWAN in smart cities. In the
first architecture, an end-device functions as a relay node to extend the coverage area. In the second
architecture, called star-of-stars, a group of remote devices forms a cluster sending data to a cluster
gateway, which acts as a relay sending the information to a central gateway. The authors implemented a
prototype of both architectures, but did not present any new forward mechanism. The results showed
a decrease in energy consumption for two or three hops compared to single-hop communication.
Moreover, this work discusses some challenges and future work for multihop LoRaWAN networks.

3.3. Analyses and Other Approaches

Other works studied the issue of multihop for LoRaWAN and LPWANs. Some of them presented
theoretical approaches with analytical models and simulations [38–40], simple solutions [52–56],
or generic proposals for LPWANs [57,58] that may be extended to LoRaWAN. Another interesting
approach is presented in [59], where the authors proposed a control plane and data plane separation
for multihop networks. The main idea is to use LoRaWAN for the control plane and another multihop
technology to the data plane, like ZigBee. An implemented testbed showed the feasibility of the
proposed approach. The works presented in [52–56] discuss some practical issues about multihop
LoRaWAN, but the authors give few details of the implementations, so they are not discussed here.
In [38], the authors analyzed the energy efficiency of the star and mesh topology. They also
proposed an analysis to find the best relations between spreading factor, transmission power, distance,
and bandwidth. In terms of energy consumption, they concluded that the best choice between
direct or multihop transmission depends on the end-to-end distance between the sender and the
gateway. In [39], the authors presented a model to analyze the energy consumption of single-hop and
multihop LoRaWAN networks. The authors consider a network formed by several rings around the
gateway in the multihop approach. The simulations used MatLab, and the authors concluded the
nodes near the gateway consume more energy than the nodes far from it in the multihop scenario.
On the other hand, for the single-hop scenario, nodes near the gateway present a better energy
efficiency. Another theoretical work was presented in [40] for different possible multihop set-ups
for LoRa networks with three hops (or layers) to the gateway. The results demonstrated that some
topologies could improve packet delivery ratio and energy consumption when compared to traditional
single-hop LoRaWAN.
In [57], the authors consider a generic LPWAN based on the TDMA MAC layer. They proposed a
Distance-Ring Exponential Stations Generator (DRESG) framework, which evaluates the performance
and establishes optimal routing connections for multihop communications in the uplink. Their results
showed that multihop might improve network lifetime and balance the energy consumption among
all nodes in the network. In [58], the same authors proposed a protocol stack for LPWANs
called HARE, which permits single-hop and multihop. It is composed of several techniques
Sensors 2020, 20, 4273 10 of 21

in different communication layers, including network synchronization, TDMA channel access,

adaptive transmission power level, network association process, and energy-aware routing protocol.
The protocol was implemented in real hardware platforms and showed high reliability and low
energy consumption.

4. Classification of LoRaWAN Devices for Multihop

In this section, we present and define a classification for devices in a LoRaWAN mesh network
based on the function the devices have in the network. The main idea of the proposal for multihop
networks is to keep the default LoRaWAN standardized device types and to define a new function
to the end-devices and gateways. The end-device is the one capable of collecting data or acting
in the network and can generate LoRaWAN packets. The gateway provides a connection between
end-devices and the Network Server, and never generates a new LoRaWAN packet. We admit a
gateway is a device with the capability to change networks or split networks.
A new classification based on functions performed by devices is necessary to describe and separate
the regular devices from the new intermediate devices on a multihop network. The intermediate
device could act as one of the two new functions proposed: a relay or a router. We define the
gateway connected to the Network Server as the main gateway, and the other possible gateways as the
intermediate gateways. All main gateways are connected to the Network Server and, by definition,
they change from LoRaWAN Network to IP Network. One network could have more than one
Main Gateway. All gateways could have the capability to connect to the Internet, but to work as an
intermediate gateway, the Internet connection must be down. An intermediate gateway could change
its status to be a main gateway if necessary. A network manager may be responsible for making this
decision based on the transmission quality. A gateway is set as an intermediate device if the connection
between gateways is more reliable than to use a 4G or 5G connection, for example. Remote areas are
suitable scenarios to use intermediate gateways to improve coverage.
The relay is a device capable of forwarding all received messages from other end-devices. The relay
could work in the physical layer only (LoRa) or the data link layer (LoRaWAN). The intermediate
devices with relay function could work as a regular end-device at the same time. The relay device
keeps the LoRaWAN network characteristic forbidding communication between end-devices.
The router devices, as the name suggests, require the implementation of a routing protocol.
The routing protocol requires, at least, the data link layer, and some works insert a network layer over
the LoRaWAN [28,29]. In a routing network, all the router devices may also act as a regular end-device.
The routing protocol adds the possibility of communication between end-devices.

4.1. Device Characteristics

The devices performing relay and router functions share three main characteristics as follows.

• Radio: The intermediate nodes could have a single or multichannel hardware radio. If the devices
use a single channel, there will be severe limitations. The intermediate device will have to receive
packets in only one frequency and DR at the same time. By default, all end-devices can transmit in
eight different frequencies in a pseudo-random frequency hopping technique. If the intermediate
device is multichannel, it will be able to receive up to eight packets at the same time with different
frequencies or SFs. However, multichannel radio hardware requires a non-energy constrained
device to work properly.
• Energy Constraints: The energy capabilities of the intermediate device are important to determine
how many features the device could have. Generally, a constrained device is not adequate to
perform complex activities because the energy consumption will be high and may decrease the
device’s lifetime. Here, we consider a multichannel device as a non-energy constrained object
because the radio needs to consume more energy, and even the development boards require
Sensors 2020, 20, 4273 11 of 21

at least a Raspberry Pi to support the radio. Furthermore, a gateway is always a non-energy

constrained hardware.
• Smart: The smart characteristic refers to the capability a device has to perform any high-level
feature. A non-smart device will only be responsible for receiving and forwarding a packet, that is,
a very simple relay. A smart intermediate device will be able to execute other features, some of
them are described below.

– Routing: We classify any routing technique as a smart feature because it requires the devices
to make decisions to create or select routes. Only router devices may have this function.
– White-List: To minimize the number of packets that an intermediate device handle, it is
possible to implement a white-list where the device only forwards the packets from
the devices on the list, thus decreasing the total amount of messages in the network.
The white-list may also be useful to avoid routing loops.
– Loop avoidance: Using the header of the LoRaWAN packet, a device may add information if
the packet is new or a forwarded one. A packet tagged as forwarded when received again by
a relay could be dropped to avoid loops.
– Synchronization: The synchronism mechanism is essential to the intermediate device to know
when it will receive a packet and, by doing this, save energy.
– Buffering: The total amount of data received by the intermediate device could exceed the
transmission capacity of the device, or the duty cycle restriction. The intermediate device
could manage a buffer and a queue to deliver the received packets and minimize the losses.

4.2. Devices Classification

The router and relay functions can be implemented in an end-device or gateway device, so we
admit a new nomenclature to simplify the understanding. The end-device with relay function will be
called Relay-Device, and when working as a router will be called Router-Device. The gateways follow
the same rule, so there will be a Relay-Gateway and a Router-Gateway.
The Relay-Device is a simple message forwarder and could work directly on the LoRa physical
layer or LoRaWAN link layer. The Relay-Device could work without any smart feature, but to
improve the efficiency of the solution, a synchronization mechanism can be implemented, for example.
A Relay-Device always sends the packets to another relay or gateway, and always participates in only
one network. The hardware requirements include single- or multichannel radio, and the hardware
definition will affect the energy requirements. A multichannel radio needs a non-energy constrained
device to be reliable.
The Router-Device implements a routing protocol to create a route between the end-device and
the gateways (intermediate or main gateway). From the related work presented in Section 3, we can
notice that there are several possibilities for a routing protocol, from a simple flooding mechanism to
one that is more sophisticated, including the IPv6 stack. The routing protocol is a smart feature, so all
Router-Devices are smart objects. A single or multichannel radio supports the implementation of a
Router-Device, and this decision will affect the energy requirements. A multichannel device requires a
non-energy constrained hardware.
The Relay-Gateway and Router-Gateway are always developed using multichannel radio, so they
are non-energy constrained devices. The difference between them is that the Relay-Gateway could
be a non-smart object. Besides the similarities with intermediate end-devices, a Relay-Gateway or
Router-Gateway never collects data or act in the network, and never generate a new LoRaWAN packet.
The gateway solution could split the network by choosing different sub-band frequencies for reception
and transmission. A Router-Gateway can function as a border gateway, participating in the end-devices
subnetwork and the gateways subnetwork at the same time.
Table 3 summarizes the classification of the devices, presenting the nomenclature, characteristics,
and the most important details of each one.
Sensors 2020, 20, 4273 12 of 21

Table 3. Devices classification.

Device Radio Energy Smart Details

- Constrained
End-device - Single-Channel - Non-Smart - Create new LoRaWAN packet
- Non-Constrained
- Single-Channel - Constrained - Smart - Forward packets
Relay-Device
- Multi-Channel - Non-Constrained - Non-Smart - Create new LoRaWAN packet
- Single-Channel - Constrained - Implement a routing protocol
Router-Device - Smart
- Multi-Channel - Non-Constrained - Create new LoRaWAN packet
- Smart - Connected to the Internet
Main Gateway - Multi-Channel - Non-Constrained
- Non-Smart - Split networks
- Smart - Forward packets
Relay-Gateway - Multi-Channel - Non-Constrained
- Non-Smart - Not connected to the Internet
- Implement a routing protocol
Router-Gateway - Multi-Channel - Non-Constrained - Smart
- Not connected to the Internet

Table 4 presents a classification of the related work in terms of the types of devices used as
intermediate nodes and their characteristics. The theoretical works and the other approaches of
Section 3.3 are not classified in the table. From the table, it is possible to observe that most works
proposed a solution using an end-device with single-channel radio. Moreover, most works use
non-energy constrained devices with smart capabilities. The works are balanced in terms of using
relays or router as a solution to multihop LoRaWAN.

Table 4. Intermediate device functions and characteristics.

Paper Device Radio Energy Constrained Smart

Abrardo and Pozzebon [21] Router-Device Single Yes Yes
Anedda et al. [20] Router-Device Single Yes Yes
Relay-Device
Aslam et al. [37] Single No No
Relay-Gateway
Bor et al. [17] Router-Device Single Yes Yes
Choi et al. [36] Relay-Device Single Yes Yes
Dias and Grilo [24] Router-Device Single No Yes
Diop and Pham [33] Relay-Device Single Yes Yes
Duong and Kim [22] Relay-Device Single Yes Yes
Dwijaksara et al. [30] Router-Gateway Multi No Yes
Router-Device Single
Ebi et al. [27] Yes No
Relay-Gateway Multi
Haubro et al. [29] Router-Device Single Yes Yes
Lee and Ke [23] Router-Device Single No Yes
Liao et al. [18] Router-Device Single Yes Yes
Lundell et al. [19] Router-Device Single Yes Yes
Mai and Kim [25] Router-Device Single Yes Yes
Sartori et al. [28] Router-Device Single Yes Yes
Sisinni et al. [31] Relay-Gateway Multi No No
Sisinni et al. [32] Relay-Device Multi No Yes
Tanjung et al. [35] Relay-Device Single Yes Yes
Weiwei Zhou and Wang [34] Relay-Device Single Yes Yes
Zhu et al. [26] Router-Device Single Yes Yes

4.3. Micro-Server Gateway Solution

An essential characteristic of the intermediate gateways is the hardware capabilities, as the
multichannel radio requires a robust platform to support it, like at least a Raspberry Pi. This availability
of robust hardware allows the development of new and high-level features. One possible solution
that could be implemented in the intermediate gateways is to extend Network Server functions.
Sensors 2020, 20, 4273 13 of 21

One possible application is to create a micro-server to handle functions such as the join procedures and
ADR. A secure LoRaWAN network requires the OTAA join procedure, and the number of hops in a
multihop scenario could be a problem. The join procedure will increase the total amount of messages in
the network, and if the duty cycle needs to be respected, the overall time could increase. As explained
in Section 2, ADR is a mechanism that could be controlled by the end-device. However, for better
results, the best approach is to leave all the decisions to the Network Server. Using intermediate
devices, the downlink packets to inform the end-device the new transmission setups could be lost or
take a long time to be delivered due to duty cycle restrictions, and the total amount of data in the air
interface will increase. The micro-server solution could implement the ADR mechanism to control a
list of end-devices connected to it. No work in the literature has studied these characteristics so far.

5. Network Topology
The insertion of an intermediate device changes the LoRaWAN network topology from
star-of-stars to several new possibilities. For a better understanding, it is important to contextualize
the relay and router nodes in a mesh network topology. Figure 5 presents a big picture of the multiple
mesh LoRaWAN network possibilities based on the concept of mesh networks presented in [60].
The subnetwork 1 represents the communication between gateways using a routing protocol. The Main
Gateway is connected to the Network Server, and the others are Router-Gateways. The subnetwork 2
presents a Relay-Gateway providing connection to the end-devices. In the subnetwork 4, the relay
function is performed by an end-device, which could also act as a regular end-device collecting
data. The subnetwork 3 presents a solution with router-devices. In subnetworks 2 and 3, there is a
Relay-Gateway connecting the remote devices with a gateway network level (subnetwork 1). The next
subsections present and describe the possible new LoRaWAN multihop topologies.

LoRaWAN
Network
Server 1 - Router-Gateway Subnetwork
2 - Relay-Gateway Subnetwork
3 - Hybrid Subnetwork
4 - Relay-Device Subnetwork
Main-Gateway

1 Router-Gateway

Relay-Gateway Relay-Device
Relay-Gateway

3
2 End-Device 4 End-Device

Router-Device

Figure 5. LoRaWAN mesh network.

5.1. Relay Topology

To provide or improve the connection of remote nodes it is possible to use relay devices. Figure 6a
presents a solution using Relay-Devices, where the Relay-Device also works as a regular end-device.
The solution is suitable for a smart building or industrial application where the end-devices have
Sensors 2020, 20, 4273 14 of 21

access to a power supply, for example. Figure 6b shows the relay solution with Relay-Gateways.
One important difference between the Relay-Device solution compared to the Relay-Gateway is that
the Relay-Device could be battery supplied or not, while the Relay-Gateway must be non-energy
constrained. The Relay-Gateway uses a multichannel radio allowing the device to listen in at least
eight frequencies, which permits the Relay-Gateway to concentrate the traffic from remote end-devices
without any mechanism to select the frequency used. A rural scenario is very suitable to use a
Relay-Gateway to connect remote devices to the main gateway.
Figure 6c presents an architecture composed of Relay-Devices and Relay-Gateways. An example
scenario of a mixed relay network is a smart city where there is the need to connect remote devices
and concentrate traffic at different points of the network. A Relay-Device could provide a connection
to a remote end-device, and the Relay-Gateway could aggregate the data from a set of end-devices
(and Relay-Devices) to deliver their messages to the main gateway.

LoRaWAN LoRaWAN LoRaWAN

Network Network Network
Server Server Server

Gateway Main-Gateway
Relay-Device
Main-Gateway

Relay-Gateway
Relay-Gateway
Relay-Device

End-Device End-Device End-Device

(a) Relay-Devices (b) Relay-Gateway (c) Relay-Device and gateway

Figure 6. Architecture with relay nodes.

5.2. Router Topology

The router topology describes the network architectures based on devices with routing capabilities.
The routing protocols can work at the end-devices or at gateway level. Figure 7a,b depicts both
solutions individually and Figure 7c puts in the same network infrastructure the two routing levels.
Figure 7a may represent a scenario like a smart building with a large number of nodes in a complex
network with access to the power supply and with a lot of transmission barriers. As the end-devices
have a lower cost compared to gateway hardware, it is possible to admit the use of Router-Devices for
the scenario.
Figure 7b presents the end-devices connected to only one Router-Gateway. However, it is possible
to admit that the end-device could have a connection to more than one Router-Gateway at the same
time. In this case, the Router-Gateways would have to manage the duplicated packets in the network
to avoid unnecessary data traffic. A farm with some points of energy infrastructure, such as a central
irrigation pivot, is very suitable in using a Router-Gateway solution. Each Router-Gateway can work
as a packet concentrator of some end-devices and determine a better route to forward the information
through the main gateway. It is also important to admit every Router-Gateway could have a connection
to another network, like 4G or 5G, disabled until the network manager decides to enable it.
Figure 7c shows the interconnection between distinct routing levels, one for the Router-Devices
and another to the Router-Gateways. The routing protocol, the network manager, and physical
limitations will determine if one or more Router-Devices will have a connection to one or more
Router-Gateways. The scenario is relevant to provide a reliable connection to remote or restricted areas
like underground deployment with the addition of routing gateway level.
Sensors 2020, 20, 4273 15 of 21

LoRaWAN LoRaWAN LoRaWAN

Network Network Network
Server Server Server

Main-Gateway
Gateway Main-Gateway

Router-Gateway

Router-Gateway
Router-Device
Router-Device

End-Device

(a) Router-Devices (b) Router-Gateway (c) Router-Device and gateway

Figure 7. Architecture with router nodes.

5.3. Hybrid Topology

A hybrid topology is also a possible implementation, with part of the network using routers
and another part using relays. Both routing or relay level could be implemented in the end-devices
layer or gateway layer. Several end-devices could transmit data packets to a Relay-Device, and the
Relay-Device would forward all data to a Router-Gateway. Finally, the Router-Gateway would
send all the packets until they reach the main gateway. Another option is a subnetwork formed by
Router-Devices connected to one Relay-Gateway that will forward the messages to the main gateway.
The work presented in [27] uses the idea of a hybrid topology with Router-Devices connected to one
Relay-Gateway. The authors connected several Router-Devices to monitor underground streets for a
smart city proposal. All the Router-Devices data are forwarded to one root node. The authors called
the root node as a relay. However, by the description, we classified the device as a Relay-Gateway
because it is a multichannel radio and splits the networks.

5.4. Summary of Topologies

Table 5 summarizes the proposed topologies with possible application scenarios of each topology.
The table also relates the works presented in Section 3 with the proposed topologies. Most of relay and
router solutions use the topology showed in Figures 6a and 7a, respectively. Only [31,37] (the authors
used two scenarios, one with Relay-Devices and another with Relay-Gateway) uses a Relay-Gateway
solution as shown in Figure 6b, and [30] uses a Router-Gateway as showed in Figure 7b. None of
the related work presents a network solution like the Figures 6c and 7c that uses Relay-Devices and
Relay-Gateways or Router-Devices and Router-Gateways, respectively.

Table 5. Topology summary.

Architecture Scenario Scenario Details Related Work

Aslam et al. [37]
Choi et al. [36]
Diop and Pham [33]
Relay-Device - Smart Building - Improve connection
Duong and Kim [22]
(Figure 6a) - Industrial - Access to power supply
Sisinni et al. [32]
Tanjung et al. [35]
Weiwei Zhou and Wang [34]
Relay-Gateway - Connect remote areas Aslam et al. [37]
- Smart Farm
(Figure 6b) - Concentrate data traffic Sisinni et al. [31]
Relay-Device - Improve coverage area
Relay-Gateway - Smart City - Concentrate data traffic None
(Figure 6c) - Battery powered devices
Sensors 2020, 20, 4273 16 of 21

Table 5. Cont.

Architecture Scenario Scenario Details Related Work

Abrardo and Pozzebon [21]
Anedda et al. [20]
Bor et al. [17]
Dias and Grilo [24]
- Improve connection Haubro et al. [29]
Router-Device - Smart Building
- Access to power supply Lee and Ke [23]
(Figure 7a) - Industrial
- Multiple barriers scenario Liao et al. [18]
Lundell et al. [19]
Mai and Kim [25]
Sartori et al. [28]
Zhu et al. [26]
Router-Gateway - Smart Farm - Connect remote areas
Dwijaksara et al. [30]
(Figure 7b) - Smart City - Concentrate data traffic
Router-Device
- Improve coverage area
Router-Gateway - Underground None
- Concentrate data traffic
(Figure 7c)
- Improve connection
- Smart Farm
Hybrid - Improve coverage area Ebi et al. [27]
- Underground
- Concentrate data traffic

6. Open Issues and Future Directions

In general, existing literature has shown that multihop and mesh topologies may extend the
coverage of LoRaWAN networks and potentially improve energy efficiency and reliability in certain
scenarios. However, many open issues remain as challenges for the widespread adoption of multihop
in LoRaWAN. As this feature is not present in current specifications, the solutions so far have to
be implemented by the LoRaWAN network developers. A standardization on LoRaWAN mesh
networks would lead to more adoption of multihop characteristics. Other wireless IoT technologies
(Wi-Fi, Bluetooth, and ZigBee) have a mesh standard, which facilitates the adoption of multihop by
applications. Some proposals of future research for multihop LoRaWAN are listed below.

• Power consumption: The energy consumption is of utmost importance in battery-powered nodes.

Several techniques may be employed to increase the battery lifetime of the end-devices, such as
energy harvesting, detection and decoding weak signals, and transmission using backscatter
signals [11]. Cognitive radio is another promising approach to be explored in LoRaWAN.
Multihop communication may benefit from all these techniques to save energy in constrained
devices. However, many of the recent multihop proposals do not deal with energy issues, like the
ones presented in [18,23,24]. Although these proposals could be applied in applications with
no energy constraints, many scenarios where it is unfeasible to have an external power source
could not use such solutions if the energy consumption is high, thus depleting the node’s battery.
More work has to be done on analysis of the power consumption of relay nodes and routing
protocols, which add new messages in the network. Real-world measurements in practical
implementations, as well as analytical and simulation tools, may help in this challenge.
• Scalability and multihop optimization: The scalability of single-hop LoRaWAN has been
extensively studied, and it is one of the main challenges of the technology. When the traffic
load or the node density increases, the network performance can be severely affected [12,13,15].
Some works propose to improve scalability at the MAC layer level of LPWAN, using techniques
such as scheduled MAC protocols, station grouping algorithms, adaptive transmission mode,
and adaptive power control [14,58], or even using concurrent multiband technologies [15].
Multihop communication may also improve the network scalability, but many works presented
in this review only show results for networks with few nodes and low traffic. Therefore,
Sensors 2020, 20, 4273 17 of 21

more research is needed on how and when multihop transmission may overcome single-hop
transmission. Many issues remain open, such as the number of devices per relay, the number of
relays, the number of hops to the gateway, and the energy consumption, as already mentioned.
The requirements may be different in urban scenarios, rural areas, and industrial applications.
• Densification and Coexistence with other LPWAN technologies: With many LoRAWAN networks
deployed in urban scenarios, coexistence issues must be considered. The performance of
isolated networks will not be the same in scenarios with other coexisting devices, such as
intermediate nodes for multihop communication. Coordination mechanisms between gateways
and intermediate devices from different operators must be necessary. This problem is even
harder considering the different sub-GHz technologies that use the same wireless spectrum,
such as SigFox, IEEE 802.15.4g, and IEEE 802.11ah, causing interference at a larger scale.
As described in [14], some applications may require that different technologies form one LPWAN,
switching from one wireless standard to the other and also creating multihop LPWANs with
different LPWAN technologies. This integration would require new routing protocols, handover
mechanisms, and a virtualized LPWAN interface.
• Synchronization, Queuing, and Duty Cycle: In LoRaWAN mesh networks, the intermediate
nodes require tight synchronization between nodes in every hop to the gateway. LoRaWAN
specification provides synchronization using beacons, but only for Class B devices in single-hop
networks. Recent work proposed some methods for synchronization for multihop, such as
using the same idea of beacons for multihop [17,24], beacon flooding [27], TSCH scheme [29],
or using synchronization by flooding with concurrent transmission [18]. More research has to
be done using different methods, MAC schemes, and performance evaluation. One problem
that may appear is that the intermediate node can not immediately transmit the received packet,
thus temporarily storing the data. The node must have enough memory for buffering, which is
limited in many end-devices. Moreover, the delay for the data packet will increase, leading to
longer delays that may prejudice the application. Moreover, with more transmissions by the relay
nodes, the duty cycle may be affected, compromising the network capacity. Data aggregation
techniques may alleviate the number of transmissions and is another topic of research.
• Optimal placement of relays: The position of the relay nodes (or routers) in the network has a
direct impact on both range extension and energy consumption. This question is similar to the
optimal placement of multiple gateways (in single-hop networks). The optimal placement of
relays depends on many factors, such as hardware characteristics of the nodes and the application.
• Intelligent LoRaWAN networks: There are many configurable parameters in LoRaWAN, such as
spreading factor, bandwidth, coding rate, and transmission power, resulting in hundreds of
possible settings. All these parameters must be optimally chosen considering the constraints
and objectives of the application, such as minimizing the energy consumption or latency or
maximizing the throughput and packet arrival. With multihop communications, the optimal
configuration is yet more difficult to achieve by mathematical and statistical models, as pointed
in [37]. In such situations, machine learning and deep learning are good candidates to be explored
in forming efficient LoRaWAN networks.
• Security: The introduction of multihop topologies poses new challenges to security, like denial of
service attacks (DoS) and traditional attacks at the routing layer, such as black hole, gray hole,
wormhole, Sybil, flooding, and so on. The relay or router nodes are especially vulnerable to these
types of attacks, which may compromise many end-devices in the network. Intrusion detection
techniques may be required to detect and mitigate such attacks. Besides that, the network must
have security mechanisms for node authentication and key management in addition to the already
defined in the LoRaWAN specification.
• Gateway-to-gateway communication: Among all solutions proposed in the literature so far, few
of them [30,31,37] studied the gateway as an intermediate node. Many applications may require
this type of communication, such as several gateways covering a rural area, where only one of
Sensors 2020, 20, 4273 18 of 21

them has a stable Internet connection. Another open issue is how to handle server functions in
intermediate gateways, such as join procedure and ADR, as discussed in Section 4.3.
• IPv6 over LoRaWAN: One promising solution to be used for multihop LoRaWAN is IPv6
adaptation, thus connecting the LPWAN to the Internet. Simple solutions were investigated in
the literature [29], but solutions using the Static Context Header Compression and Fragmentation
(SCHC) [61], an ultralightweight IPv6 adaptation layer for LPWANs, are still to be investigated.

7. Conclusions
LoRaWAN is an LPWAN technology widely adopted to connect several devices with low power
and long-range communication. It allows building a private network without other third-party
infrastructure, like SigFox and NB-IoT. Several authors have proposed multihop mechanisms to
extend coverage, which were discussed in this paper. These solutions propose intermediate nodes to
forward messages from other end-devices. The intermediate nodes in each hop could be either an
end-device or a gateway, performing simple relay functions or complex routing protocols. The devices
in previous work may have different constraints and features, forming different mesh topologies.
We classified the existing solutions according to their characteristics, identifying the challenges in
deploying LoRaWAN multihop networks. We showed that different applications could use different
network topologies and intermediate nodes, depending on the requirements on coverage, reliability,
energy consumption, and so on. Further, we presented some open issues and possible directions for
practical large-scale deployment of LoRaWAN mesh networks. We encourage further developments in
multihop communication to improve coverage, scalability, capacity, reliability, and energy efficiency of
LoRaWAN networks.

Author Contributions: J.R.C. made the literature search and selected the papers. J.R.C. and J.H.K. discussed the
classification and network topologies. J.R.C. and J.H.K. wrote and revised the paper. All authors have read and
agreed to the published version of the manuscript.
Funding: This research was funded by CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior)
and MCTIC/RNP (Rede Nacional de Pesquisa), under the EUB-02-2017 IoT Pilots call.
Acknowledgments: Authors would like to thank all members of the SWAMP project.
Conflicts of Interest: The authors declare no conflict of interest.

References
1. Atzori, L.; Iera, A.; Morabito, G. Understanding the Internet of Things: Definition, potentials, and societal
role of a fast evolving paradigm. Ad Hoc Netw. 2017, 56, 122–140. [CrossRef]
2. Atzori, L.; Iera, A.; Morabito, G. The Internet of Things: A survey. Comput. Netw. 2010, 54, 2787–2805.
[CrossRef]
3. Sheng, Z.; Yang, S.; Yu, Y.; Vasilakos, A.; Mccann, J.; Leung, K. A survey on the ietf protocol suite for the
internet of things: Standards, challenges, and opportunities. IEEE Wirel. Commun. 2013, 20, 91–98. [CrossRef]
4. Al-Fuqaha, A.; Guizani, M.; Mohammadi, M.; Aledhari, M.; Ayyash, M. Internet of Things: A Survey
on Enabling Technologies, Protocols, and Applications. IEEE Commun. Surv. Tutor. 2015, 17, 2347–2376.
[CrossRef]
5. Cilfone, A.; Davoli, L.; Belli, L.; Ferrari, G. Wireless Mesh Networking: An IoT-Oriented Perspective Survey
on Relevant Technologies. Future Internet 2019, 11, 99. [CrossRef]
6. Raza, U.; Kulkarni, P.; Sooriyabandara, M. Low Power Wide Area Networks: An Overview. IEEE Commun.
Surv. Tutor. 2017, 19, 855–873. [CrossRef]
7. Sinha, R.S.; Wei, Y.; Hwang, S.H. A survey on LPWA technology: LoRa and NB-IoT. ICT Express 2017,
3, 14–21. [CrossRef]
8. LoRa Alliance. LoRaWANTM 1.0 Specification. 2015. Available online: https://lora-alliance.org/resource-
hub/lorawanr-specification-v10 (accessed on 8 June 2020)
9. LoRa Alliance. LoRaWANTM 1.1 Specification. 2017. Available online: https://lora-alliance.org/resource-
hub/lorawanr-specification-v11 (accessed on 10 June 2020)
Sensors 2020, 20, 4273 19 of 21

10. LoRa Alliance. LoRaWANTM 1.0.3 Specification. 2018. Available online: https://lora-alliance.org/resource-
hub/lorawanr-specification-v103 (accessed on 5 June 2020)
11. Shanmuga Sundaram, J.P.; Du, W.; Zhao, Z. A Survey on LoRa Networking: Research Problems,
Current Solutions, and Open Issues. IEEE Commun. Surv. Tutor. 2020, 22, 371–388. [CrossRef]
12. Adelantado, F.; Vilajosana, X.; Tuset-Peiro, P.; Martinez, B.; Melia-Segui, J.; Watteyne, T. Understanding the
Limits of LoRaWAN. IEEE Commun. Mag. 2017, 55, 34–40. [CrossRef]
13. Mikhaylov, K.; Petäjäjärvi, J.; Hänninen, T. Analysis of Capacity and Scalability of the LoRa Low Power
Wide Area Network Technology. In Proceedings of the European Wireless 2016, Oulu, Finland, 18–20 May
2016; pp. 119–124.
14. De Poorter, E.; Hoebeke, J.; Strobbe, M.; Moerman, I.; Latré, S.; Weyn, M.; Lannoo, B.; Famaey, J.
Sub-GHz LPWAN Network Coexistence, Management and Virtualization: An Overview and Open Research
Challenges. Wirel. Pers. Commun. 2017, 95, 187–213. [CrossRef]
15. Adame, T.; Bel, A.; Bellalta, B. Increasing LPWAN Scalability by Means of Concurrent Multiband IoT
Technologies: An Industry 4.0 Use Case. IEEE Access 2019, 7, 46990–47010. [CrossRef]
16. Laya, A.; Kalalas, C.; Vazquez-Gallego, F.; Alonso, L.; Alonso-Zarate, J. Goodbye, ALOHA! IEEE Access
2016, 4, 2029–2044. [CrossRef]
17. Bor, M.; Vidler, J.; Roedig, U. LoRa for the Internet of Things. In Proceedings of the 2016 International
Conference on Embedded Wireless Systems and Networks, Graz, Austria, 15–17 February 2016; pp. 361–366.
18. Liao, C.H.; Zhu, G.; Kuwabara, D.; Suzuki, M.; Morikawa, H. Multi-Hop LoRa Networks Enabled by
Concurrent Transmission. IEEE Access 2017, 5, 21430–21446. [CrossRef]
19. Lundell, D.; Hedberg, A.; Nyberg, C.; Fitzgerald, E. A Routing Protocol for LoRA Mesh Networks.
In Proceedings of the 19th IEEE International Symposium on a World of Wireless, Mobile and Multimedia
Networks, WoWMoM 2018, Chania, Greece, 12–15 June 2018.
20. Anedda, M.; Desogus, C.; Murroni, M.; Giusto, D.D.; Muntean, G.M. An Energy-efficient Solution for
Multi-Hop Communications in Low Power Wide Area Networks. In Proceedings of the IEEE International
Symposium on Broadband Multimedia Systems and Broadcasting, BMSB, Valencia, Spain, 6–8 June 2018.
21. Abrardo, A.; Pozzebon, A. A multi-hop lora linear sensor network for the monitoring of underground
environments: The case of the medieval aqueducts in Siena, Italy. Sensors 2019, 19, 402. [CrossRef] [PubMed]
22. Duong, C.T.; Kim, M.K. Reliable Multi-Hop Linear Network Based on LoRa. Int. J. Control Autom. 2018,
11, 143–154. [CrossRef]
23. Lee, H.C.; Ke, K.H. Monitoring of Large-Area IoT Sensors Using a LoRa Wireless Mesh Network System:
Design and Evaluation. IEEE Trans. Instrum. Meas. 2018, 67, 1–11. [CrossRef]
24. Dias, J.; Grilo, A. Multi-hop LoRaWAN uplink extension: Specification and prototype implementation.
J. Ambient Intell. Humaniz. Comput. 2020, 11, 945–959. [CrossRef]
25. Mai, D.L.; Kim, M.K. Multi-Hop LoRa Network Protocol with Minimized Latency. Energies 2020, 13, 1368.
[CrossRef]
26. Zhu, G.; Liao, C.H.; Sakdejayont, T.; Lai, I.W.; Narusue, Y.; Morikawa, H. Improving the Capacity of a Mesh
LoRa Network by Spreading-Factor-Based Network Clustering. IEEE Access 2019, 7, 21584–21596. [CrossRef]
27. Ebi, C.; Schaltegger, F.; Rust, A.; Blumensaat, F. Synchronous LoRa Mesh Network to Monitor Processes in
Underground Infrastructure. IEEE Access 2019, 7, 57663–57677. [CrossRef]
28. Sartori, B.; Thielemans, S.; Bezunartea, M.; Braeken, A.; Steenhaut, K. Enabling RPL multihop
communications based on LoRa. In Proceedings of the 2017 IEEE 13th International Conference on Wireless
and Mobile Computing, Networking and Communications (WiMob), Rome, Italy, 9–11 October 2017; pp. 1–8.
29. Haubro, M.; Orfanidis, C.; Oikonomou, G.; Fafoutis, X. TSCH-over-LoRA : Long range and reliable IPv6
multi-hop networks for the internet of things. Internet Technol. Lett. 2020, 1, 1–6. [CrossRef]
30. Dwijaksara, M.H.; Sook Jeon, W.; Jeong, D.G. Multihop gateway-to-gateway communication protocol for
lora networks. In Proceedings of the IEEE International Conference on Industrial Technology, Melbourne,
Australia, 13–15 February 2019; pp. 949–954.
31. Sisinni, E.; Carvalho, D.F.; Ferrari, P.; Flammini, A.; Silva, D.R.C.; Da Silva, I.M. Enhanced flexible LoRaWAN
node for industrial IoT. In Proceedings of the IEEE International Workshop on Factory Communication
Systems - Proceedings, WFCS, Imperia, Italy, 13–15 June 2018; pp. 1–4.
32. Sisinni, E.; Ferrari, P.; Fernandes Carvalho, D.; Rinaldi, S.; Pasetti, M.; Flammini, A.; Depari, A. A LoRaWAN
range extender for Industrial IoT. IEEE Trans. Ind. Inform. 2019, 16, 1. [CrossRef]
Sensors 2020, 20, 4273 20 of 21

33. Diop, M.; Pham, C. Increased flexibility in long-range IoT deployments with transparent and light-weight
2-hop LoRa approach. In Proceedings of the IFIP Wireless Days, Manchester, UK, 24–26 April 2019.
34. Zhou, W.; Tong, Z.; Dong, Z.; Wang, Y. LoRa-Hybrid: A LoRaWAN Based multihop solution for regional
microgrid. In Proceedings of the 2019 IEEE 4th International Conference on Computer and Communication
Systems, Singapore, 23–25 February 2019; pp. 650–654.
35. Tanjung, D.; Byeon, S.; Kim, D.H.; Deok Kim, J. OODC: An Opportunistic and On-Demand Forwarding
Mechanism for LPWA Networks. In Proceedings of the International Conference on Information Networking,
Barcelona, Spain, 7–10 January 2020; pp. 301–306.
36. Choi, R.; Lee, S.; Lee, S. Reliability Improvement of LoRa with ARQ and Relay Node. Symmetry 2020, 12, 552.
[CrossRef]
37. Aslam, M.S.; Khan, A.; Atif, A.; Hassan, S.A.; Mahmood, A.; Qureshi, H.K.; Gidlund, M. Exploring Multi-Hop
LoRa for Green Smart Cities. IEEE Netw. 2020, 34, 225–231. [CrossRef]
38. Ochoa, M.N.; Guizar, A.; Maman, M.; Duda, A. Evaluating LoRa energy efficiency for adaptive networks:
From star to mesh topologies. In Proceedings of the International Conference on Wireless and Mobile
Computing, Networking and Communications, Rome, Italy, 9–11 October 2017.
39. Misbahuddin; Iqbal, M.S.; Wiriasto, G.W. Multi-hop uplink for low power wide area networks using
LoRa technology. In Proceedings of the 2019 6th International Conference on Information Technology,
Computer and Electrical Engineering, ICITACEE 2019, Semarang, Indonesia, 26–27 September 2019.
40. Farooq, M.O. Introducing scalability in LoRa-based networks through multi-hop communication setups.
In Proceedings of the 2019 IEEE Global Communications Conference, GLOBECOM 2019, Waikoloa, HI, USA,
9–13 December 2019.
41. Haxhibeqiri, J.; De Poorter, E.; Moerman, I.; Hoebeke, J. A Survey of LoRaWAN for IoT: From Technology to
Application. Sensors 2018, 18, 3995. [CrossRef]
42. Vangelista, L.; Zanella, A.; Zorzi, M. Long-Range IoT Technologies: The Dawn of LoRaTM . In Future Access
Enablers for Ubiquitous and Intelligent Infrastructures; Atanasovski, V., Leon-Garcia, A., Eds.; Lecture Notes
of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering; Springer
International Publishing: Cham, Switzerland, 2015; Volume 159, pp. 51–58._7. [CrossRef]
43. Reynders, B.; Pollin, S. Chirp spread spectrum as a modulation technique for long range communication.
In Proceedings of the 2016 Symposium on Communications and Vehicular Technologies (SCVT), Mons,
Belgium, 22–22 November 2016; pp. 1–5.
44. Farooq, M.O.; Pesch, D. Analyzing LoRa: A use case perspective. In Proceedings of the 2018 IEEE 4th World
Forum on Internet of Things (WF-IoT), Singapore, 5–8 February 2018; pp. 355–360.
45. Petajajarvi, J.; Mikhaylov, K.; Roivainen, A.; Hanninen, T.; Pettissalo, M. On the coverage of LPWANs:
Range evaluation and channel attenuation model for LoRa technology. In Proceedings of the 2015 14th
International Conference on ITS Telecommunications (ITST), Copenhagen, Denmark, 2–4 December 2015;
pp. 55–59.
46. LoRa Alliance. RP002-1.0.1 LoRaWAN Regional Parameters; 2020. Available online: https://lora-alliance.org/
resource-hub/rp2-101-lorawanr-regional-parameters (accessed on 7 June 2020)
47. Bor, M.C.; Roedig, U.; Voigt, T.; Alonso, J.M. Do LoRa Low-Power Wide-Area Networks Scale? In Proceedings
of the 19th ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile
Systems—MSWiM ’16; ACM Press: New York, NY, USA, 2016; pp. 59–67.
48. Haxhibeqiri, J.; Van den Abeele, F.; Moerman, I.; Hoebeke, J. LoRa Scalability: A Simulation Model Based on
Interference Measurements. Sensors 2017, 17, 1193. [CrossRef]
49. LoRa Alliance. LoRaWAN 1.1 Regional Parameters. 2017. Available online: https://lora-alliance.org/
resource-hub/lorawanr-regional-parameters-v11ra (accessed on 1 June 2020)
50. Ertürk, M.A.; Aydın, M.A.; Büyükakkaşlar, M.T.; Evirgen, H. A Survey on LoRaWAN Architecture,
Protocol and Technologies. Future Internet 2019, 11, 216. [CrossRef]
51. Krejci, R.; Hujnak, O.; Svepes, M. Security survey of the IoT wireless protocols. In Proceedings of the 2017
25th Telecommunication Forum (TELFOR), Belgrade, Serbia, 21–22 November 2017; pp. 1–4.
52. Azhari, R.Y. Simple Protocol Design of Multi-hop Network in LoRa. In Proceedings of the 2019 International
Seminar on Research of Information Technology and Intelligent Systems (ISRITI), Yogyakarta, Indonesia,
5–6 December 2019; pp. 177–181.
Sensors 2020, 20, 4273 21 of 21

53. Bezunartea, M.; Van Glabbeek, R.; Braeken, A.; Tiberghien, J.; Steenhaut, K. Towards energy efficient LoRa
multihop networks. In Proceedings of the IEEE Workshop on Local and Metropolitan Area Networks, Paris,
France, 1–3 July 2019; pp. 42–44.
54. Flauzac, O. A Low Power LoRa-LoRaWan Relay Function with a Single Input, Single Output Device.
In Proceedings of the International Conference on Embedded Wireless Systems and Networks (EWSN) 2020,
Lyon, France, 17–19 February 2020; pp. 283–288.
55. Huh, H.; Kim, J.Y. LoRa-based Mesh Network for IoT Applications. In Proceedings of the IEEE 5th World
Forum on Internet of Things, WF-IoT, Limerick, Ireland, 15–18 April 2019; pp. 524–527.
56. Kim, M.; Jang, J.W. A Study on Implementation of Multi-hop Network for LoRaWAN Communication. In
Proceedings of the International Conference on Information Networking, Barcelona, Spain, 7–10 January
2020; pp. 553–555.
57. Barrachina-Muñoz, S.; Bellalta, B.; Adame, T.; Bel, A. Multi-hop communication in the uplink for LPWANs.
Comput. Netw. 2017, 123, 153–168. [CrossRef]
58. Vázquez, T.A.; Barrachina-Muñoz, S.; Bellalta, B.; Bel, A. HARE: Supporting Efficient Uplink Multi-Hop
Communications in Self-Organizing LPWANs. Sensors 2018, 18, 115. [CrossRef]
59. Gu, C.; Tan, R.; Lou, X. One-hop out-of-band control planes for multi-hop wireless sensor networks.
ACM Trans. Sens. Netw. 2019, 15, 1187–1195. [CrossRef]
60. Akyildiz, I.F.; Wang, X.; Wang, W. Wireless mesh networks: A survey. Comput. Netw. 2005, 47, 445–487.
[CrossRef]
61. Gomez, C.; Minaburo, A.; Toutain, L.; Barthel, D.; Zuniga, J.C. IPv6 over LPWANs: Connecting Low Power
Wide Area Networks to the Internet (of Things). IEEE Wirel. Commun. 2020, 27, 206–213. [CrossRef]

c 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access
article distributed under the terms and conditions of the Creative Commons Attribution
(CC BY) license (http://creativecommons.org/licenses/by/4.0/).