LoRaWAN Mesh Networks: A Review and Classification of Multihop Communication

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.


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][9][10][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 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. 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].
... 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 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.

End-Devices
Gateway Application Server

Join Server
Network Server LoRaWAN Network Server 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.
• 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.

Rx1
Rx2 Rx2 Class C 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.

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.

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.

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 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.

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.
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.

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][39][40], simple solutions [52][53][54][55][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][53][54][55][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 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.

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. 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.

Device Characteristics
The devices performing relay and router functions share three main characteristics as follows. 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 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.

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.  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 Aslam et al. [37] Relay-Device 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 Ebi et al. [27] Router-Device Single 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

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.
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.

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.

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 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.

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.

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. 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.

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,  [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.   [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.

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.