Received 10 September 2022, accepted 18 October 2022, date of publication 26 October 2022, date of current version 2 November 2022.

Digital Object Identifier 10.1109/ACCESS.2022.3217215

Implementation of a LoRa Mesh Library

JOAN MIQUEL SOLÉ , ROGER PUEYO CENTELLES , FELIX FREITAG , AND ROC MESEGUER
Department of Computer Architecture, Universitat Politècnica de Catalunya, BarcelonaTech, 08034 Barcelona, Spain
Corresponding author: Felix Freitag ([email protected])
This work was supported by the Ministry of Science and Innovation of the Spanish Government through the State Research Agency (AEI)
under Project PID2019-106774RB-C21, Project PCI2019-111851-2 (LeadingEdge CHIST-ERA), and Project PCI2019-111850-2 (DiPET
CHIST-ERA).

ABSTRACT LoRa is a popular communication technology in the Internet of Things (IoT) domain, providing
low-power and long-range communications. Most LoRa IoT applications use the LoRaWAN architecture,
which builds a star topology between LoRa end nodes and the gateway they connect to. However, LoRa
can also be used for the communication between end nodes themselves, forming a mesh network topology.
In this paper, we present a library that allows to integrate LoRa end nodes into a LoRa mesh network,
in which a routing protocol is used. Thus, an IoT application running on these nodes can use the library to
send and receive data packets to and from other nodes in the LoRa mesh network. The designed routing
protocol is proactive, and maintains the routing table at each node updated by sending routing messages
between neighboring nodes. The implemented library has been tested on embedded boards featuring an
ESP32 microcontroller and a LoRa single-channel radio. By using our LoRa mesh library, nodes do not need
to connect to a LoRaWAN gateway, but among themselves. This opens the possibility for new, distributed
applications solely built upon tiny IoT nodes.

INDEX TERMS LoRa, mesh network, IoT routing.

I. INTRODUCTION most of the time in sleeping mode, and periodically wake up

LoRa is a wireless communication technology designed for to send a LoRa packet to the gateway. In LoRaWAN there is
the interconnection of Internet of Things (IoT) devices. Its no direct communication between the end nodes.
main features are its long range (hence its name), which In the last few years, a number of proposals have been made
can transmit data over several km of distance, low power to extend the LoRaWAN star topology by means of multi-hop
consumption and low data rate. Configuration parameters communication, which are reviewed in the form of a survey
like the Spreading Factor (SF) can extend the communication in [3]. Multi-hop in LoRaWAN allows extending the distance
distance, although at the expense of lower data rates [1]. between the end nodes and the gateway, without increasing
Most IoT applications that use the LoRa communication the density of gateways. The underlying principle is that LoRa
technology adhere to the LoRaWAN network architecture [2]. end nodes far away from the gateway can communicate with
LoRaWAN defines a star topology where IoT end nodes, intermediate end nodes, which act as forwarders of their mes-
e.g., LoRa-equipped sensor nodes, transmit their data to a sages towards the gateway. Overall, multi-hop for LoRaWAN
LoRaWAN gateway. Typically, a gateway covers an area with provides mostly an extension of the geographical reach of
many end nodes, and listens for incoming LoRa packets from the IoT layer, while it mostly maintains the principles of a
them. The gateway has two network interfaces: on the one LoRaWAN-based IoT application.
hand, a multi-channel LoRa radio; on the other hand, a wired We identify several motivations for considering a more rad-
or a wireless connection to the Internet through which to com- ical shift towards true LoRa mesh network-based solutions,
municate the received data to a higher layer of the application which address 1) the architectural limitations of LoRaWAN,
usually hosted in the cloud. While a gateway is expected to be 2) the opportunity for application decentralization, and 3) the
always powered and operational, end nodes typically spend need for saving cost and energy consumption.
Applications following the LoRaWAN architecture typi-
The associate editor coordinating the review of this manuscript and cally consider the situation where end nodes are able to reach
approving it for publication was Chunsheng Zhu . a LoRaWAN gateway with one hop. This condition can be

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
113158 VOLUME 10, 2022
J. M. Solé et al.: Implementation of a LoRa Mesh Library

a problem in scenarios where the geographic scale of the In this paper, we aim to make a significant step forward
end nodes is large and the density of gateways is low. While in the public availability of ready to use code that allows to
increasing the number of gateways can be considered as a deploy LoRa mesh networks. In particular, we present our
solution to the problem, it is not always possible due to the library code-named LoraMesher, which we have developed
economic cost or the geographic conditions. in order to deploy LoRa mesh networks operating a rout-
Devices used for event-based or periodic data transmission ing protocol as proposed in [7]. The library is implemented
to the gateway are categorized as class A end node [4]. There- in C++ and is conceived to be a part of an application
fore, the LoRa traffic from applications using devices of such code that runs on an IoT node consisting of an embedded
class is mostly on the uplink channel, i.e., LoRa packets from microcontroller and a LoRa radio. Having the LoRaMesher
the data sources (end nodes) sent via radio to the LoRaWAN library integrated within the IoT code running on such a node,
gateway and, from there, over the Internet towards the cloud. an application is able to connect to a LoRa mesh network and
After sending a LoRa packet, these end nodes open two short send, route and receive LoRa packets from the nodes within
reception windows to get any downlink messages from the the network.
gateway, which are optional. Since in LoRaWAN the down- The main contributions of this paper are:
link messages from the gateway are linked to the uplink mes- • We describe the design and implementation of the
sage from the sensor, instantaneous pushes of notifications to LoRaMesher library for deploying LoRa mesh networks
the sensor node are not immediately available. Also, the fact which include a routing protocol.
that in LoRaWAN the field for the Cyclic Redundancy Check • We evaluate the library performance in experiments with
(CRC) of the payload is only available in the uplink LoRa different topologies using real hardware nodes.
packet makes the downlink packet less of a reliable element The main potential of this library, which is freely available
in the data transmission. IoT application based on LoRaWAN as open source code,2 is to enable a new class of distributed
often aim at centralized decision-making, with the purpose applications that can run only at the IoT layer using LoRa
of the sensor nodes solely being to send data to cloud-based interconnected nodes.
services. Decisions are taken after the cloud-based processing
of the sensor data. Other application scenarios, however, con- II. DESIGN AND IMPLEMENTATION
ceive more autonomous IoT nodes where decisions need to be A. OVERVIEW
taken at the device. Indeed, the current trend in performing
The LoRaMesher library is a C++ implementation of a
machine learning on low capacity devices only increases this
proactive distance-vector routing protocol for enabling the
need [5]. For such autonomous IoT nodes, a certain asyn-
communication among LoRa nodes that form a mesh net-
chronous communication capacity is needed, e.g., for being
work, as proposed in [7]. The target hardware for which the
able to inform a node about a current application context to
library is compiled is an embedded board with a System
be taken into account for local decision-making. LoRa point
on a Chip (SoC) and a single-channel LoRa radio, like the
to point communications between end nodes, as delivered by
popular ESP32 SoC-based development boards featuring an
a LoRa mesh networks, can be a solution. However, this type
SX1276 LoRa transceiver. LoRaMesher uses FreeRTOS3 to
of communication is not considered in LoRaWAN.
implement the task handlers of the receiver, sender, packet
The energy consumption of ICT applications has become
processing, routing protocol and application data bidirec-
a raising concern [6]. LoRaWAN-based IoT applications
tional transmission.
address a full software and hardware stack that covers from
For the interaction with the LoRa radio chip, LoRaMesher
the IoT device to the cloud. Therefore, it involves the oper-
leverage RadioLib,4 a versatile communication library which
ation of a huge software and hardware infrastructure, which
supports the SX1276 LoRa series radio available on the hard-
translates in significant environmental costs due to the bill of
ware we use. Features of RadioLib include an easy configura-
materials and the energy consumption. Nonetheless, most ser-
tion of LoRa parameters, and the addition of CRC verification
vices forming an IoT application can be obtained from shared
of the LoRa payload, if enabled. Moreover, LoRaMesher uses
cloud-based computing infrastructures, which reduces the
RadioLib to define an Interrupt Service Routine (ISR) which
operational cost per application. IoT applications can lever-
is executed every time a LoRa packet is detected.
age the already deployed components for LoRaWAN-based
In the following section, we describe in detail the design of
solutions, where providers often offer enterprise and com-
the LoRaMesher library.
munity partnerships, such as The Things Network,1 among
others. Still, we can envision applications of interconnected
B. PACKET STRUCTURE
LoRa devices which only use the computing infrastructure
LoRa belongs to IoT communication technologies for build-
available on the devices themselves. Such gateway-less IoT
ing Low Power Wide Area Networks (LPWANs). LoRa
applications, in terms of infrastructure costs, are much more
targets applications in which remote sensors communicate
affordable in regard to the needed hardware and their energy
consumption. 2 https://github.com/LoRaMesher/LoRaMesher
3 https://www.freertos.org/
1 https://www.thethingsnetwork.org/ 4 https://github.com/jgromes/RadioLib

VOLUME 10, 2022 113159

 J. M. Solé et al.: Implementation of a LoRa Mesh Library

FIGURE 1. Standard LoRa packet Structure using the Explicit Header

Mode (top) and the LoRaMesher packet frame inside the payload section
(center). The two types of messages the library supports are also depicted
(bottom).

data with low data rates. A LoRa packet is limited

to 255 B. [8].
Figure 1 shows the structure of a LoRa packet and that of
a LoRaMesher packet. It can be seen that the LoRaMesher
packet is encapsulated within the payload field of the LoRa
packet. The LoRaMesher packet itself contains a header and
a payload. Following the design in [7], this header consists
of 4 B which hold the address of the destination and the source
node, 1 B to specify the message type and 1 B to indicate the
payload size.
LoRaMesher is a library that implements a proactive rout-
ing protocol. Thus, it sends two types of messages, namely
FIGURE 2. Routing message received diagram (based on [7]).
routing messages which allow nodes to update their routing
table, and data messages, which contain the actual application
data that is sent from one node towards another. processing, the LoRaMesher packet containing the routing
message is deleted.
C. ROUTING AND DATA MESSAGES Data messages contain the data from the application layer.
A routing message in LoRaMesher contains one or multiple The data message has a specific destination in the LoRa mesh
routing entries of the sender node’s routing table. A data network. When a node using the LoRaMesher library receives
message contains an additional field of 2 B to indicate the next a data message, the following outcomes are possible: 1) the
hop, and the actual application data as payload (Figure 1). receiving node is the destination and thus the library will pass
Routing messages are broadcasted by each node at config- this data message to the application layer, 2) the node is not
urable periods. The purpose of sending routing messages is the destination, but it is the one specified in the next hop
to allow neighboring nodes to update their routing tables with field, meaning that it is expected to forward the data message
the information from other nodes around (and, in turn, from (for doing this, it will update the next hop field with the
those nodes beyond their direct reach). A routing message address found in its local routing table), 3) the node is not the
sets the broadcast address 0 × FF as the destination address. destination of the data message nor the next hop and, in both
Thus, a node receiving a LoRaMesher routing packet can cases, the node will delete the data message. A corner case
distinguish it from a data message. The received routing might be found in the second situation above, where a node
messages are not forwarded by the nodes, but are processed is expected to forward a data message headed to a destination
to update their local routing table. not present in its routing table; in that case, the data message
Figure 2 describes the algorithm that processes a received will also be deleted.
routing packet. Once a received message is identified as a
routing message, it is necessary for the node to check if the D. QUEUES
sender is already annotated in the routing table. The next As explained before, a LoRaMesher packet can contain be
step is to process the routing table entries received from the a routing or a data message. Furthermore, received data
neighboring node and update the local routing table. After the messages may be re-routed to its destination or delivered

113160 VOLUME 10, 2022

J. M. Solé et al.: Implementation of a LoRa Mesh Library

to the node’s application, while received routing messages

are processed locally and generated routing messages at the
node are broadcasted. This packet processing creates the
FIGURE 3. Receiver task diagram. When receiving a LoRa packet, this is
need for having local structures where to store these packets. converted to a LoRaMesher packet and added to the Received Packets
LoRaMesher implements for this purpose a set of Packet Queue.
Queues.
Queues are also a means for the tasks in the LoRaMesher
library, i.e., routines that carry out a certain type of processing no matter whether the device is busy or idle, hence max-
of a packet, to have a data structure for sharing packets. Every imizing the number of received packets. Nevertheless, the
time a packet is received and needs to be shared between time spent in this task is critical since, during its execution,
tasks, the library creates a Packet Queue element that contains no other packet can be received. Therefore, the operations
a priority number, the memory address of the packet and the performed by this task determine the maximum amount of
next element. When adding this element to the queue, it is packets that can be received in a certain period of time.
added at the first position such that its priority is higher than Taking advantage of the queues, in LoRaMesher, the opera-
the next Packet Queue element. tions of the Receive Task consists of only the following steps
The LoRaMesher library implements three different (Figure 3).
queues with the following purposes: 1) Receive LoRa packet.
• Received Packets (Q_RP): This queue is used for stor- 2) Get the LoRa packet payload and transform it into a
ing packets received from the LoRa radio and have them LoRaMesher packet.
ready for local processing. A task is needed to fetch the 3) Create a Packet Queue element and add the received
received packet and add it to this queue. LoRaMesher packet to it.
• Send Packets (Q_SP): This queue is implemented to 4) Add the Packet Queue element to the Q_RP queue.
store the packets that the node will send via the LoRa 5) Notify the Process Task.
radio interface. A task is needed to take out the packets
from this queue and transmit them. 2) SEND TASK
• User Received Packets (Q_URP): This queue is used The duty of this task is to get a Packet Queue element from
by the application code of the node. When a packet is Q_SP, send it and delete the Packet Queue element. In addi-
received and the destination is the application layer of tion, if the packet contains a data message, it checks if the
the node itself, a task adds the packet to this queue. destination is inside the routing table; if so, it will update the
next hop of the Data Message.
E. TASKS This task is notified and starts running every time a packet
LoRaMesher is designed with six tasks to perform the dif- is added to Q_SP. In order to comply with the duty cycle
ferent processing duties for the LoRa packets. Each task is regulations, every time a packet is sent, the library calculates
implemented by a specific routine. The routines leverage the the time on air depending on the payload size and the con-
queues introduced in the previous section to operate with the figuration of the library, and adds a mandatory delay before
packets. Thus, packets are added and deleted from the queues sending successive packets.
according to the operation of the task. Through the operations Before sending a packet, the task will start a Channel
on the packets in the queues, tasks indirectly communicate Activity Detection (CAD) routine, which will listen for LoRa
with each other, and make requests between them. preambles. If a LoRa preamble is detected, the task will wait
a random delay and then start the CAD routine again. Only
1) RECEIVE TASK when no preamble is detected, the packet will be sent. This
The duty of the Receive Task is to receive a LoRa packet, operation is an approximation to the Carrier Sense Multiple
get the LoRa packet payload, transform it into a LoRaMesher Access / Collision Avoidance (CSMA/CA) algorithm.
packet, create a Packet Queue element and add the previous The Send Task is designed to have the second highest
packet to it, add this Packet Queue element into the Q_RP and priority. Furthermore, every time and before a packet is sent,
finally notify the Process Task that a new packet needs to be the ISR of the Receive Task is disabled, and thus it cannot
processed. receive any messages. Once the packet is sent, the ISR of the
This task works with an ISR. Thus, the microcontroller is Receive Task is enabled. Figure 4 summarizes the following
switched to the Receive Task every time that a LoRa packet steps of the Send Task.
is detected. The ISR is provided by the RadioLib library and 1) Notification that a packet has been added to the Q_SP.
allows notifying the task upon every reception of a LoRa 2) Get the Packet Queue element from the Q_SP queue.
packet. 3) If the packet contains a Data Message and the destina-
The Receive Task is designed to have the highest prior- tion is found in the routing table, update the Next Hop
ity among the six tasks of LoRaMesher. This implies that field.
the Receive Task is invoked whenever a packet is received, 4) Wait for a random delay.

VOLUME 10, 2022 113161

 J. M. Solé et al.: Implementation of a LoRa Mesh Library

FIGURE 6. Packet Process Task diagram. When the Receiver task notifies
the Packet Process task, then this task processes the first packet inside
the Q_RP queue.

FIGURE 4. Send Task diagram. Automatic duty cycle calculation between

packets and CSMA/CA.
Otherwise, in the case of a Data Message, it will be processed
as shown in Figure 7.
The Data Message process function will check first if the
destination address match the address of this node. If that
is the case, the Process Task will add this message into the
Q_URP and will notify the User Receive Task; the user (i.e.,
the application layer) is ultimately responsible for deleting
FIGURE 5. Routing Protocol Task diagram. It creates a routing message the packet. If the address of the LoRaMesher packet does not
with the actual routing table and adds it to the Q_SP to be sent as soon match the address of this node, it will check if the next hop is
as possible.
the address of this node; if it does not match, the packet and
the Packet Queue element will be deleted. If it matches, it will
be checked if the destination address is inside the routing
5)Start CAD listening for LoRa preambles. table. In that case, it will add the Packet Queue element into
6)If a preamble has been detected, repeat 4. the Q_SP to be forwarded. Otherwise, when the entry in the
7)Disable the Receive Task ISR. routing table with the destination of the packet does not exist,
8)Send the packet that is contained in the previous Packet it will be deleted. Regarding the task’s priorities, the Process
Queue element. Task has a lower priority than the Routing Protocol Task.
9) Enable the Receive Task ISR. The following steps of the Process Task are summarized in
10) Delete the packet and the Packet Queue element. Figure 6.
11) Calculate the time on air for the packet, calculate duty 1) Get a notification from the Receive Task.
cycle and wait for it. 2) Get a Packet Queue element from Q_RP.
3) Process the packet by type.
3) ROUTING PROTOCOL TASK Routing Message case: if the source address is not
The Routing Protocol Task is periodically executed and builds inside the routing table then add a new route, otherwise,
a packet containing a Routing Message. This Routing Mes- update the entry. If the packet contains a Routing Mes-
sage is used to share the node’s routing table with the neigh- sage, process each route. If the destination is contained
boring nodes and to build the routing table in each node. in the node’s routing table, update its cost. If the route
A Routing Message contains the sending node’s routing table, does not exist, create it. Finally, delete the LoRaMesher
consisting of the addresses of nodes and a metric given by packet.
the number of hops with which the node can be reached. The Data Message case: if the destination address is the
priority of this task is less than that of the Send Task, but node, add the packet to the Q_URP queue and notify
higher than that of the Process Task. Moreover, the periodicity the application level. Once processed, the application
of execution can be modified changing a variable named code needs to delete the LoRaMesher packet from the
HELLO_PACKETS_DELAY. In the current implementation, queue. If the destination is not the node, but the address
the routing table maintains only the path with the least num- in the next hop field exists as a destination address in
ber of hops to reach a destination. Figure 5 summarizes the the routing table, then the packet is added to the Q_SP
Routing Protocol Task. queue and forwarded. In any other case, the packet is
deleted.
4) PROCESS TASK
The execution of this task is triggered by the Receive Task. 5) USER SEND TASK
Every time a packet is received, the Receive Task notifies This task is implemented at the application level and cor-
the Process Task. After receiving the notification from the responds to the code that is responsible for sending data
Receive Task (Figure 3), the Process Task takes the first using the LoRaMesher library. Every time the application
Packet Queue element of the Q_RP queue and determines wants to send a Data Message to another node, it needs to
whether the LoRaMesher packet is a Routing Message or call the function createPacketAndSend, where it specifies the
a Data Message (Figure 6). In case it is a Routing Mes- destination, the payload memory address and the number
sage, it will be processed as shown previously in Figure 2. of bytes that have to be sent. If the application code uses

113162 VOLUME 10, 2022

J. M. Solé et al.: Implementation of a LoRa Mesh Library

FIGURE 9. Example of a User Receive Task. Every time the application

FIGURE 7. Data Message received diagram. receives a packet, it gets the first Packet Queue element from Q_URP
queue and processes it. Finally, it deletes the packet.

shows how the application gets an address from the routing

table and sends a specific payload to the corresponding node.

6) USER RECEIVE TASK

The objective of this task is to get the elements inside
the Q_URP queue and process the LoRaMesher packets as
requested from the application level. The User Receive Task
is notified by the library every time the Process Task receives
and identifies a Data Message for the node. This task is imple-
mented in the application code and needs to contain ulTas-
kNotifyTake(pdPASS, portMAX_DELAY), which is a function
of the FreeRTOS operating system that allows the task to stay
in sleep mode until it is notified.
The application code has to take care of deleting the mes-
sages from the queue that are no longer needed. This deletion
of messages is important for a correct memory management
of the device. The LoRaMesher library provides the appli-
cation with the function deletePacket(packet) to delete the
packet.
The code example in Figure 9 shows how to integrate the
User Receive Task into the application layer.
FIGURE 8. Example of a User Send Task. In this example, the application
code sends every 120 seconds a userPayload to a node contained in the F. RELATIONSHIP BETWEEN TASKS AND QUEUES
node’s routing table.
There are a few different situations where LoRaMesher pack-
ets are created. Every time a Packet Queue element is added
structs or classes in C++, which contain the payload data, to a queue, a LoRaMesher packet must have been created
it is recommended to work with a one byte alignment in the previously. First, every time a packet is received, the library
payload data to prevent empty bytes inside it. will create a LoRaMesher packet containing the payload of
If the nodes available in a LoRa mesh network are the packet. Second, when the application layer or the user
not known beforehand and need to be discovered, then wants to send a Data Message, the library will create a
LoRaMesher offers to the application level the possibility to LoRaMesher packet with the payload specified by the appli-
read the node’s routing table. This way, an application can cation. Finally, every time the Routing Protocol Task is exe-
select among the valid addresses of nodes to which Data cuted, a LoRaMesher packet containing a Routing Message
Messages will be sent to. The code fragment of Figure 8 will be created. Moreover, every time a packet shall be added

VOLUME 10, 2022 113163

 J. M. Solé et al.: Implementation of a LoRa Mesh Library

FIGURE 10. Queues diagram. The Receive task adds to the Q_RP queue,
the Process Packet task gets from the Q_RP queue and adds to the Q_SP
and Q_URP queue. The Routing Protocol task and User Send task add to FIGURE 11. LoRaMesher task sequence example when receiving a data
the Q_SP queue, the Send task gets from the Q_SP queue and finally the message whose destination is the application of this node.
User Receive task gets from the Q_URP queue.

inside a packet queue, a Packet Queue element will be created

containing the packet to be shared.
Figure 10 illustrates how the three queues introduced in
section II-D are used by the different tasks. All packets from
any origin that are received by the library are added to the
Received Packets Queue. They are taken by the Process
Packet Task for further packet classification. The Send Task
periodically takes messages from the Send Packets Queue to
transmit them to the LoRa radio. Packets to be sent can consist
of new data messages created by the application at the node,
routing messages created by the library itself, or received data
messages which according to the routing protocol need to
be forwarded by the node. Data messages that are received
being the node itself the destination are added to the User
Received Packets Queue, and these data messages pushed to
the application layer.
FIGURE 12. LoRaMesher tasks sequence when routing a received data
Figures 11 and 12 show examples of task sequences that message.
are executed when receiving a Data Message. It can be seen in
Figure 11 that after performing the Receive task, the Process
Packet task determines that the Data Message received is for
the node itself. Therefore, the User Receive task is notified in real devices. In the experiment, we focus on the following
order for the application to process the packet. In Figure 12 metrics:
the Process Packet task determines that the Data Message Packet Delivery Ratio (PDR): The ratio of the total number
received needs to be routed by the node. Therefore, the packet of packets received to the total number of packets sent from a
is added into the Q_SP queue. It is processed by the Send task source to the destination. This metric is obtained by logging
that is periodically called to get and send the packets of this at each node the number of received packets. The monitored
queue. packet information allows determining the PDR of each node.
Control Overhead: The ratio of the control information sent
over the data received at each node. This metric is influenced
III. EVALUATION by the configured periodicity for the sending of the routing
A. METRICS messages. Dynamic networks require a higher number of
In this section, we describe a set of experiments that we have routing messages in order to keep the routing tables up to
conducted with the LoRaMesher implementation flashed on date, while for stable networks this periodicity can be low.

113164 VOLUME 10, 2022

J. M. Solé et al.: Implementation of a LoRa Mesh Library

TABLE 1. LoRa parameter setting for the experiments with LoRaMesher

(EU863-870).

we determined for each node a set of visible nodes corre-

sponding to the evaluated topology. When starting an exper-
iment, upon receiving routing messages, the node constructs
FIGURE 13. Boards with LoRa radio used for the experimentation. Top its routing table from the messages obtained by the visible
board: TTGO T-Beam V1.1 LoRa ESP32. Bottom board: LoRa V1.3 ESP32.
nodes, while the routing messages received from other nodes
are ignored.
The experimental configuration includes varying the num-
To determine the Control Overhead, we measure the total ber of LoRa packets sent from each node and the payload
number of bytes of routing and data messages sent. We treat size of these LoRa packets. Both parameters influence in the
the headers of the two packet types as control information. number of collisions of the LoRa packets, which grows with
Since both the periodicity of the routing message and that an increasing number of packets and larger payloads.
of the data messages is configurable, the metric reflects the
specific experimental setting. C. RESULTS
The following formula is used to calculate the Con- For the experimentation, the ten nodes are started at the same
trol Overhead: ControlOverehead = (RoutingPacketSize + time. This induces the worst case scenario for the PDR in
HeaderDataMessages)/DataMessagesPayload which each node periodically sends the messages. We add
End-to-End Delay (EED): It is the time that it takes for an identifier attribute of 1 byte in the generic packet which,
an message from the source to completely arrive at the des- together with the source address, allows identifying a packet.
tination. This metric accumulates the time the LoRa packet This additional identifier attribute is included in the payload.
is held at each node in the path to its destination. The time at The packet size is calculated from the payload size and
each node is influenced by the timer configuration of the Send the header. In the experiments we use three different pay-
Task in the LoRaMesher library at each node. As detailed in loads: a 5 bytes payload (4 bytes of payload + 1 byte of the
section II-E, the Send Task is a periodic task and every time packet identifier), 105 bytes and 213 bytes. All three payloads
it is executed, it will send the next packet inside the Q_SP. have an 8 bytes header (6 bytes of the LoRaMesher Packet
Hops: It is the number of nodes a packet passes from Header + 2 bytes of Next Hop of the Data Message type).
the source to the destination. This metric is relevant for
validating the path of the data messages, but not for the 1) EXPERIMENT 1
routing messages, which are not forwarded by the nodes We experiment the LoRaMesher library for a topology where
(see section II-C). the ten nodes are at one hop distance to each other (Figure 14).
This experiment aims to assess from the results the correct
B. EXPERIMENTAL FRAMEWORK operation of the queues and tasks in the implementation. The
For the experimentation, we use eight TTGO T-Beam configuration of the experiment is presented in Table 2. All
V1.1 LoRa ESP32 boards and two LoRa V1.3 ESP32 nodes send data messages to each other every 120 seconds.
(Figure 13). Both boards are equipped with the ESP32 SoC Figure 15 shows the PDR obtained for the different pay-
and a SX1276 LoRa transceiver. The boards are flashed with loads. It can be seen that the PDR decreases for larger sizes
the developed LoRaMesher library. of the payload. This can be explained by the larger time on air
In Table 1 the setting of the LoRa parameters common to all of these packets, which increases the probability of collision
our experiments is shown. The parameters are configurable in with other packets.
RadioLib. Figure 16 looks at the detailed PDR of each of the ten
We evaluate the LoRaMesher library with different net- nodes. A similar PDR pattern can be observed for the different
work topologies. In order to conduct controlled experi- nodes.
ments, we chose to implement the geographic deployment In Figure 17 the EED is compared for the different pay-
of the nodes of each topology by software. Therefore, loads. It can be seen that the EED depends on the payload

VOLUME 10, 2022 113165

 J. M. Solé et al.: Implementation of a LoRa Mesh Library

FIGURE 16. PDR by source node (experiment 1).

FIGURE 14. Topology of the first experiment, where all ten nodes are
interconnected by one hop, as illustrated for node 0 × C5FC.

TABLE 2. Settings of the first experiment.

FIGURE 17. EED by payload (experiment 1).

FIGURE 18. Topology of the second experiment with a chain of nodes.

the first node 0 × 5728, at one end of the chain, creates data
messages that are sent to the last node 0 × C5FC at the other
end of the chain. The experimental settings are described in
Table 3. It needs to be mentioned that, before node 0 × 5728
can start sending data messages, it needs to wait for at least
nine routing message exchanges between the neighboring
nodes in order to have in its routing table the entry of the last
node 0 × C5FC. With the configured periodicity of 300s for
FIGURE 15. PDR by payload (experiment 1).
routing table exchanges, it adds 45 minutes to the experiment
for the routing table updates to travel through the 9 hops of
the middle nodes.
size. The larger packets have a larger time on air, which In Figure 19 it can be seen that, similar to the first experi-
increases the EED. ment, the PDR is lower for the larger packets, which can be
Since all the nodes send the same amount of data, both in attributed to a higher number of collisions. Different to the
terms of routing and data messages, all nodes have the same first experiment, however, the number of data messages sent
Control Overhead, which is 19% in this experiment. in the second experiment is lower since only the first node
creates data messages. The reduced number of packets sent
2) EXPERIMENT 2 results in a higher PDR for the different payloads.
We experiment a topology in which the nodes form a chain Figure 20 shows the obtained EED. The dependence
(Figure 18). This experiment aims to assess whether the rout- between the payload size and the EED can be observed,
ing tables built represent the given topology and that the rout- where the time of the packet in the network increases with the
ing of data messages at each node performs correctly. Only payload size. In the configuration used in this experiment, the

113166 VOLUME 10, 2022

J. M. Solé et al.: Implementation of a LoRa Mesh Library

TABLE 3. Settings of the second experiment.

FIGURE 21. Control Overhead (experiment 2).

FIGURE 19. PDR

¸ by payload (experiment 2).

FIGURE 22. Topology of third experiment with incremental number of

hops.

TABLE 4. Settings of third experiment.

FIGURE 20. EED by payload (experiment 2).

EED is not affected by delays due to duty cycle limitations.

The reason is that even the largest payload of 221 bytes
can be sent every 48 seconds fulfilling duty cycle require-
ments, while the nodes are configured to send packets every
120 seconds. network. The software of the other five nodes, i.e., 0 × 5728,
The Control Overhead is shown in Figure 21. Compared 0 × 9234, 0 × 56C4, 0 × 62D8 and 0 × 6D4C, consists of
to the first experiment, an increase of the Control Overhead the LoRaMesher library without application code. Therefore,
in all nodes is observed. The reason is that in the topology of these nodes operate as routers only.
experiment 2 an additional 9 routing message exchanges are The experimental configuration for this experiment is indi-
done to construct the routing tables before the data messages cated in Table 4. The host nodes increases the payload size
can be sent. The last node, 0 × C5FC, shows a 100% Control of the data packets every thirty messages. Specifically, the
Overhead, which is due to the fact that it is the destination of first payload is 5 bytes, the second 105 bytes and the last
the data messages and does not send any data message itself. one is 213 bytes. This experiment first aims to gain insight
in the performance of the middle node, i.e., 0 × 56C4, which
3) EXPERIMENT 3 is exposed to the maximum traffic, and secondly, present
We experiment with a topology that integrates different con- the case of a distributed application hosted on IoT devices
nectivity situations of nodes (Figure 22). We configured that interconnected over a LoRa mesh network.
five nodes, i.e., 0 × 63AC, 0 × C5FC, 0 × 4E58, 0 × 96A0 We configured the nodes to discard those messages which
and 0 × 8C20, operate as hosts. Their application creates data the radio receives but which are not part of the topology of the
messages to be sent to each of the other host nodes in the experiment. The PDR per payload is shown in Figure 23 and

VOLUME 10, 2022 113167

 J. M. Solé et al.: Implementation of a LoRa Mesh Library

FIGURE 23. PDR by payload (experiment 3).

FIGURE 25. Number of packets inside the Q_SP to be sent to each node
in the third experiment.

FIGURE 24. PDR by source node (experiment 3).

that by node in Figure 24. In comparison with experiment 1,

the PDR is lower, which can be explained by the fact that data
messages are routed over several hops. Compared to experi-
ment 2, there are more devices that create data messages. Both
situations contribute to a higher number of collisions, which
reduce the PDR. FIGURE 26. EED by payload (experiment 3).
Figure 25 shows the Send Packets Queue (Q_SP) of the
router nodes that have more traffic, i.e., 0 × 5728, 0 × 62D8,
0 × 56C4 and 0 × 9234. As a consequence of the topology The increase is even more visible for the payload of 221 bytes
and from how the routing table is being built, node 0 × 5728 (213 bytes of payload and 8 bytes of header), which the duty
is used to forward the packets between the nodes 0 × 56C4 cycle allows sending every 48 seconds. In Figure 25 we can
and 0 × C5FC. It can be seen in the figure how the packets see for the higher traffic nodes that these packets are stored
are becoming hold in the queue of the nodes as the payload before being forwarded, which in some cases led to an EED
grows. That happens since the nodes that do forwarding of of as much as 1400 seconds (∼ 23.33 minutes).
messages need to take into account the duty cycle. Every Figure 27 shows the Control Overhead of each node. It can
time a packet is prepared for sending, the nodes needs to wait be seen that the five nodes that create data message have
for the duty cycle limitation to end before sending the next the highest Control Overhead. This is due to the fact that,
packet. in this topology, these nodes actually send a lower amount
In Figure 26 the EED by payload is shown. We observe of data messages compared to the nodes that route these data
a much higher delay in comparison with Figures 17 and 20 messages. Compared to experiments 1 and 2, when having
of experiment 1 and 2, respectively. The reason is the duty finished sending the data messages, these nodes send only
cycle that affects the nodes with more traffic in the high routing messages (which in the experiments is for a duration
payload scenario, in which packets need to be hold. With of more than 2 hours). The nodes 0 × 62D8, 0 × 6D4C and
the low payload of 13 bytes packet (5 bytes of payload and 0 × 9234 have a similar Control Overhead due to having
8 bytes of header) a packet can be sent every 6 seconds similar data traffic. In comparison, the node 0 × 5728 has
while fulfilling the duty cycle. However, if all the five host more data traffic due to how the routing table was built,
nodes send the packet through the node 0 × 56C4, one of the resulting in that the packets of nodes 0 × 56C4 and 0 × C5FC
packets will need to wait for up to 35 seconds, which is what pass through this node. Finally, node 0 × 56C4 has the highest
we experimented at some points in time. For the 113 bytes data traffic in the network. Therefore, its Control Overhead is
payload (105 bytes of payload and 8 bytes of header), the duty less than that of the other nodes.
cycle allows the nodes to send this packet every 26 seconds.
However, this already represents a situation that the nodes IV. RELATED WORKS
have more packets to send than the network can process Several proposals regarding multi-hop, mesh and routing for
without delays, and the time of the EED starts to increase. LoRa and LoRaWAN have been made in recent years. They

113168 VOLUME 10, 2022

J. M. Solé et al.: Implementation of a LoRa Mesh Library

Sartori et al. addressed the LoRaWAN coverage exten-

sion topic with RLMAC, a Medium Access Control (MAC)
layer protocol that enables Routing over Low Power and
Lossy Networks (RPL) multi-hop communications based on
LoRa [14]. They argue that the star topology is convenient
for the ease of deployment and from a business perspective,
though multi-hop could be the only option for covering very
large areas with few base stations.
Lee and Ke designed and implemented a LoRa mesh net-
FIGURE 27. Control Overhead (experiment 3). working system to ensure that indoor nodes can communicate
with network servers without deploying more gateways [15].
have been thoroughly classified and analyzed by researchers Their design consists of a data sink broadcasting beacons
from different points of view: taking the application scenarios to invite nodes to join the network. The authors state that
into account [9], focusing on the LoRaWAN architecture [3], while their solution extends the coverage of a network with-
or on specific implementation aspects like topology and rout- out installing more gateways, the number of serviced nodes
ing [10]. The maturity and technology readiness level of these would be smaller than with a conventional star topology
works are heterogeneous, and range from theoretical con- because of the latency introduced by successive packet for-
tributions to experimentally validated proposals in testbeds warding.
or real-world deployments. In this section, we analyze the Zhu et al. improved the capacity of a multi-hop LoRa
proposals that are most relevant to our work. network by off-loading traffic into several subnetworks with
Ebi et al. implemented a synchronous LoRa mesh proto- different SFs [16]. This clustering technique results in a
col to extend LoRaWAN networks for end nodes monitor- multiple-access dimension network where each subnetwork
ing underground infrastructures [11]. Their approach adds is rooted at a sink node with a specific SF. This enables packet
repeater nodes that bridge a synchronous LoRa mesh net- transmission in parallel with multiple SFs to become feasible.
work segment with the regular LoRaWAN gateway. The The authors present a Tree-based SF Clustering Algorithm
results outperform a standard LoRaWAN network regarding (TSCA) that conducts node allocation. Their solution requires
the reliability of packet delivery when transmitting from a coordinated effort for the clustering decision-making tasks.
range-critical locations like underground areas. The solution Mai and Kim proposed a collision-free multi-hop LoRa
enhances transmission reliability, efficiency, and flexibility, network protocol with low latency [17]. In their network,
but requires a precise time reference (e.g., using GPS or the sink node exchanges packets with the other nodes to
DCF77 time signaling) for synchronization. construct a tree topology and assign a timeslot and a channel
Another work which investigates LoRaWAN with to each link. The authors state that their protocol provides
multi-hop is presented by Pueyo Centelles et al. [12]. Their high reliability, parallel transmissions, low latency and a
work considers the scenario of an earthquake where principal minimized number of timeslots and packet size. However,
communication infrastructures fail, and a communication it is only suitable for networks with static topology where
system based on the LoRaWAN architecture extended by all the collected data are targeted towards a single sink
LoRa mesh networking provides an emergency network node.
for end users. The performance of the system is evaluated Duong and Kim designed and implemented a protocol with
extensively by simulations. multi-hop communication for LoRa networks covering large
Osorio et al. [13] extended LoRaWAN with a multi-hop distances [18]. Their solution was intended for deployments
forwarding mechanism, which is based on a gossip algo- where every monitoring node is placed along a line, such as a
rithm. The solution improves the efficiency and flexibility of gas pipe or a high voltage line. Devices are synchronized and
transmission, but requires intensive use of the communication wake up at specific moments in time to receive data packets
channel due to the duplicated messages caused by the gossip from their neighbors, which they can combine with their own
algorithm. The number of messages is one of the limitations data packets and send further along the line.
of LoRa and LoRaWAN, and the duty cycle further reduces Similarly, Abrardo and Pozzebon designed a multi-hop
the number of messages. The performance of the system was LoRa linear network for underground environments, optimiz-
evaluated by means of a simple experiment with 8 nodes. ing the nodes’ sleep/wake cycles to reduce battery consump-
There are several proposals for multi-hop networks using tion [19]. They opted for a data propagation model with sen-
LoRa which do not belong to, or extend, the LoRaWAN archi- sor nodes forming a transmission chain towards the gateway,
tecture. Using different strategies like routing, Time-Division including a synchronization mechanism when propagating
Multiple Access (TDMA), clustering techniques, etc. they data between pairs of nodes to maximize the sleep cycles’
create tree and mesh topologies to build more decentralized duration.
and flexible networks. Most often, systems are built with In regard to practical implementations, there are very few
single-channel radio nodes only, but some also combine them readily available commercial or open source products offer-
with multi-channel gateway hardware. ing LoRa multi-hop and mesh possibilities.

VOLUME 10, 2022 113169

 J. M. Solé et al.: Implementation of a LoRa Mesh Library

Hester and several other contributors work on Meshtas- library to route in the mesh network application layer pay-
tic [20], a project for using inexpensive development boards loads beyond the size of LoRa packets. Having such capac-
with GPS, battery and a LoRa chip as secure mesh communi- ities would allow the LoRaMesher library to become a
cators. Meshtastic is intended for outdoor sport activities or communication substrate for distributed embedded machine
any other situation with no Internet access. Users create a pri- learning applications.
vate mesh to exchange their location and send text messages
to a group chat. Devices forward packets using a flooding REFERENCES
algorithm to reach the furthest member. [1] M. A. M. Almuhaya, W. A. Jabbar, N. Sulaiman, and S. Abdulmalek,
Pycom provides commercial development boards and ‘‘A survey on LoRaWAN technology: Recent trends, opportunities,
OEM products for IoT projects in the Python language. These simulation tools and future directions,’’ Electronics, vol. 11, no. 1,
p. 164, Jan. 2022. [Online]. Available: https://www.mdpi.com/2079-
devices can run Pymesh, a firmware for flexible LoRa mesh 9292/11/1/164
networking [21]. It provides encrypted ad-hoc communica- [2] J. Haxhibeqiri, E. De Poorter, I. Moerman, and J. Hoebeke,
tion over raw LoRa, implements Listen-before-talk (LBT) ‘‘A survey of LoRaWAN for IoT: From technology to application,’’
Sensors, vol. 18, no. 11, p. 3995, Nov. 2018. [Online]. Available:
MAC, and supports multiple node roles (leader, router, child, https://www.mdpi.com/1424-8220/18/11/3995
and border router). The firmware also has some routing [3] J. R. Cotrim and J. H. Kleinschmidt, ‘‘LoRaWAN mesh networks: A review
capabilities, as it claims to forward packets via the best link and classification of multihop communication,’’ Sensors, vol. 20, no. 15,
p. 4273, Jul. 2020. [Online]. Available: https://www.mdpi.com/1424-
available. Unfortunately, Pymesh can only run on Pycom’s 8220/20/15/4273
products, making it incompatible with other vendors. [4] N. Sornin, M. Luis, T. Eirich, T. Kramp, O. Hersent. (2016). LoRaWAN
NiceRF commercially offers the SV-Mesh and LoRaS- Specification; Version V1.0.2. LoRa Alliance. Beaverton, OR, USA.
tar range of LoRa transceivers. These products, available Accessed: Oct. 20, 2022. [Online]. Available: https://lora-alliance.org/wp-
content/uploads/2020/11/what-is-lorawan.pdf
as embedded boards or packaged devices, provide serial [5] F. Sakr, F. Bellotti, R. Berta, and A. De Gloria, ‘‘Machine learning on
TTL, RS232, or RS482 communication over LoRa links. mainstream microcontrollers,’’ Sensors, vol. 20, no. 9, p. 2638, May 2020.
They consist of a low power microcontroller and a regular [Online]. Available: https://www.mdpi.com/1424-8220/20/9/2638
[6] E. Ahvar, A.-C. Orgerie, and A. Lebre, ‘‘Estimating energy consumption
LoRa transceiver. The manufacturer developed the propri- of cloud, fog, and edge computing infrastructures,’’ IEEE Trans. Sustain.
etary LoRa-Pro mesh networking protocol, which defines a Comput., vol. 7, no. 2, pp. 277–288, Apr. 2022.
2 byte addressing scheme, three network roles (node, router, [7] R. P. Centelles, ‘‘Towards LoRa mesh networks for the IoT,’’ Ph.D. dis-
node plus router), and a virtually unlimited number of routes. sertation, Dept. Comput. Archit., Universitat Politècnica de Catalunya,
Barcelona, Spain, Nov. 2021.
Based on this review of related works, we can conclude [8] LoRa Core sx1276/77/78/79 Documentation. Accessed: Oct. 20, 2022.
that most of the works that propose a LoRa mesh network do [Online]. Available: https://www.semtech.com/products/wireless-rf/lora-
not implement it, they are limited to simulations or analytical core/sx1276#documentation
[9] R. P. Centelles, F. Freitag, R. Meseguer, and L. Navarro, ‘‘Beyond the star
calculations. The few works that implement a network focus of stars: An introduction to multihop and mesh for LoRa and LoRaWAN,’’
on addressing very specific and particular use cases. They do IEEE Pervasive Comput., vol. 20, no. 2, pp. 63–72, Apr. 2021.
not perform a general implementation as the one done in this [10] A. Osorio, M. Calle, J. D. Soto, and J. E. Candelo-Becerra, ‘‘Routing in
LoRaWAN: Overview and challenges,’’ IEEE Commun. Mag., vol. 58,
paper. no. 6, pp. 72–76, Jun. 2020.
[11] C. Ebi, F. Schaltegger, A. Rust, and F. Blumensaat, ‘‘Synchronous LoRa
V. CONCLUSION mesh network to monitor processes in underground infrastructure,’’ IEEE
This paper presented the development of the LoRaMesher Access, vol. 7, pp. 57663–57677, 2019.
[12] R. P. Centelles, R. Meseguer, F. Freitag, L. Navarro, S. F. Ochoa,
library, which implements a routing distance-vector protocol and R. M. Santos, ‘‘LoRaMoto: A communication system to provide
for the communication of nodes in a LoRa mesh network. safety awareness among civilians after an earthquake,’’ Future Gener.
The design of the library is explained in detail. The imple- Comput. Syst., vol. 115, pp. 150–170, Feb. 2021. [Online]. Available:
https://www.sciencedirect.com/science/article/pii/S0167739X20306063
mentation is deployed on real devices, showing the library as [13] A. Osorio, M. Calle, J. Soto, and J. E. Candelo-Becerra, ‘‘Routing
ready to use code. The experimentation with LoRaMesher is in LoRa for smart cities: A gossip study,’’ Future Gener. Comput.
done with different topologies and payloads and evaluates the Syst., vol. 136, pp. 84–92, Nov. 2022. [Online]. Available:
https://www.sciencedirect.com/science/article/pii/S0167739X22001996
packet delivery ratio, end-to-end delay and control overhead.
[14] B. Sartori, S. Thielemans, M. Bezunartea, A. Braeken, and K. Steenhaut,
The implementation of LoRaMesher is open source. ‘‘Enabling RPL multihop communications based on LoRa,’’ in Proc.
The results obtained from the experimentation showed that IEEE 13th Int. Conf. Wireless Mobile Comput., Netw. Commun. (WiMob),
the LoRaMesher library worked correctly in the different Oct. 2017, pp. 1–8.
[15] H.-C. Lee and K.-H. Ke, ‘‘Monitoring of large-area IoT sensors using a
topologies and for small, medium and large sizes of payloads. LoRa wireless mesh network system: Design and evaluation,’’ IEEE Trans.
Configuration parameters such as the periodicity of data and Instrum. Meas., vol. 67, no. 9, pp. 2177–2187, Sep. 2018.
routing messages allow the user of the library to adapt its [16] G. Zhu, C.-H. Liao, T. Sakdejayont, I.-W. Lai, Y. Narusue, and
H. Morikawa, ‘‘Improving the capacity of a mesh LoRa network
operation to the specific application requirements. The library by spreading-factor-based network clustering,’’ IEEE Access, vol. 7,
can be included in an IoT application code with a few steps, pp. 21584–21596, 2019.
which can lead to distributed LoRa mesh-based applications [17] D. L. Mai and M. K. Kim, ‘‘Multi-hop LoRa network protocol with
minimized latency,’’ Energies, vol. 13, no. 6, p. 1368, Mar. 2020. [Online].
at the IoT layer.
Available: https://www.mdpi.com/1996-1073/13/6/1368
Future work will include extending the implemented pro- [18] C. T. Duong and M. K. Kim, ‘‘Multi-hop linear network based on LoRa,’’
tocols with reliable LoRa packet delivery and enabling the Adv. Sci. Technol. Lett., vol. 150, pp. 29–33, Apr. 2018.

113170 VOLUME 10, 2022

J. M. Solé et al.: Implementation of a LoRa Mesh Library

[19] A. Abrardo and A. Pozzebon, ‘‘A multi-hop LoRa linear sensor network FELIX FREITAG is currently an Associate Profes-
for the monitoring of underground environments: The case of the medieval sor with the Department of Computer Architec-
aqueducts in Siena, Italy,’’ Sensors, vol. 19, no. 2, p. 402, Jan. 2019. ture, Universitat Politècnica de Catalunya (UPC).
[20] Meshtastic: Open Source Hiking, Pilot, Skiing and Secure GPS His research interests include edge computing and
Mesh Communicator. Accessed: Oct. 20, 2022. [Online]. Available: federated machine learning.
https://meshtastic.org/
[21] Pycom PyMesh. Accessed: Oct. 20, 2022. [Online]. Available:
https://docs.pycom.io/pymesh/

JOAN MIQUEL SOLÉ received the bachelor’s

degree in computer science from the Faculty of
Informatics, Universitat Politècnica de Catalunya
(UPC), in 2022. He is currently a Main Developer
and Maintainer at the LoRaMesher Library. He is
also working as a Research Engineer with UPC.
His research interest includes networks and proto-
cols for the IoT.

ROGER PUEYO CENTELLES received the ROC MESEGUER is currently an Associate Pro-
Ph.D. degree from the Universitat Politècnica de fessor with the Department of Computer Architec-
Catalunya (UPC), in 2021. He is currently working ture, Universitat Politècnica de Catalunya (UPC).
as a Senior Researcher with the i2CAT Founda- His research interests include resource alloca-
tion. His research interests include community tion for large-scale systems, decentralized systems
networks, mesh and ad-hoc networks, and the IoT. applied to ambient intelligence, and bottom-up
networks.

VOLUME 10, 2022 113171