This article has been accepted for publication in IEEE Access.

This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000.
Digital Object Identifier 10.1109/[Link]

A minimalistic distance-vector routing

protocol for LoRa mesh networks
ROGER PUEYO CENTELLES1 , ROC MESEGUER1 , FELIX FREITAG1 , ROGER BAIG VIÑAS1 ,
LEANDRO NAVARRO1
1
Universitat Politècnica de Catalunya, Computer Architecture Department, BarcelonaTech, 08034 Barcelona, Spain (e-mail: [Link]@[Link],
[Link]@[Link], [Link]@[Link], [Link]@[Link], [Link]@[Link])
Corresponding author: Felix Freitag (e-mail: [Link]@[Link]).
This work was funded by the Spanish State Research Agency (PDC2023-145809-I00 / AEI / 10.13039/501100011033), the Recovery and
Resilience Mechanism of the European Union, and by the European Union – NextGenerationEU.

ABSTRACT LoRa is popular in the Internet of Things (IoT) domain as a Low Power, Wide Area Network
(LPWAN) radio technology, providing low-power and long-range communication in the sub-GHz band.
Most often, LoRa is used as part of the LoRaWAN architecture with a star-of-stars topology, but it can
also be operated standalone. This paper presents and evaluates a minimalistic Routing Protocol (RP) for
building LoRa networks with a more flexible mesh network topology. We propose a Time on Air (ToA)
metric that, when used in heterogeneous network topologies, can take better advantage of LoRa’s multiple
Spreading Factors (SFs), and their trade-off between transmission distance and bit rate, and their quasi-
orthogonality property. We evaluate the routing protocol with the FLoRa framework and OMNeT++ and
compare it with other common routing strategies. Our experiments provide a comprehensive understanding
of the routing protocol performance concerning the scalability, throughput, and latency in several topology
and network traffic scenarios. When using the ToA metric, we observed in LoRa mesh networks formed by
random topologies and heterogeneous links the positive impact of a more balanced Packet Delivery Ratio
(PDR) among the nodes with different network centrality, suggesting hence the multi-SF ToA metric to be
used for improved PDR in conditions that are expected to occur in real-world systems. Regarding goodput,
we observed that using multiple SF simultaneously had a limited impact on low to high traffic loads but
dramatically improved throughput and goodput in traffic saturation scenarios. This suggests that multi-SF
operation would be preferred to maximize network performance. We observed the best latency performance
with multi-SF ToA for low and medium traffic loads, especially for the random topology, where the metric
can again take advantage of the node and link heterogeneity.

INDEX TERMS LoRa, mesh network, routing

I. INTRODUCTION RaWAN’s single-hop, gateway-client scheme. For instance,

Several technologies have emerged during the last decade to increase network coverage, to deal with challenging ge-
providing wireless communication for IoT devices in various ography, to overcome the need for additional infrastructure
scenarios [1]. Among them, LoRa has proven successful in besides the end devices themselves in Peer-To-Peer (P2P)
the LPWAN domain for a vast number of deployments in communications, or even to avoid data going to the cloud
diverse environments that require the transmission of small through an Internet connection in underserved locations [4].
amounts of data over long distances (Figure 1). Figure 2 depicts the LoRaWAN architecture, signaling the
LoRaWAN is an open specification by the LoRa Alliance issues mentioned above. Our proposal, rather than extending
that provides the Medium Access Control (MAC) and appli- LoRaWAN’s set of features, aims at breaking the hierarchical
cation layers on top of the LoRa radio technology, defining star of stars topology and contributing to building LoRa
a star of stars topology with gateways at the center and end mesh networks that allow communication between any pair
nodes around them [2]. This network architecture has proven of nodes without the need for the gateway infrastructure [5]
suitable for many diverse IoT applications [3]. However, increasing the service of a LoRa mesh network. However,
there are reasons for using a more flexible topology than Lo- mesh topologies come at the price of requiring the nodes to

VOLUME 4, 2016 1

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

OMNeT++ simulator [8], tested in different mesh network

5G Cellular
WiFi
deployments with up to 64 nodes. We analyze key perfor-
4G
Data rate

Bluetooth
mance aspects such as PDR, throughput, and latency under
Mb/s

BLE 3G
NFC ZigBee LPWAN different setups and compare our proposed metric with other
2G
RFID
DASH7 LoRa well-known routing strategies.
kb/s

Weightless SigFox
Short range nWave Wize The following Section II provides a brief introduction to
10 m 100 m
100 m
Communication range
11 km
km the LoRa radio technology. Routing for LoRa –and most
often, for LoRaWAN– is an active research topic; we selected
FIGURE 1: A non-exhaustive classification of radio tech- the most relevant state-of-the-art in Section III. In Section IV,
nologies and protocols for IoT according to their approximate we introduce our minimalist DV RP for building LoRa mesh
communication range and data rate. LoRa provides long- networks and describe its fundamentals, including the ToA
range links, of up to a few km, at tens of kbps. metric used to evaluate the cost of paths to the nodes.
Section V discusses the methodology followed in the exper-
iments, explaining the simulation framework, the network
spend resources (CPU, memory, power, airtime) to maintain topologies, the nodes’ characteristics, etc., and includes a
the network operative and forward data from other partici- benchmark comparing the simulator performance with real
pants in the network that could not otherwise communicate. hardware. Section VI evaluates the simulation experiments
This paper presents a minimalistic Distance-vector (DV) performed, analyzing the capabilities that multi-SF-aware
Routing Protocol (RP) built on the multi-hop LoRa mesh routing for LoRa adds and comparing the ToA metric with
networks we developed in [6]. We focus on the design and other well-known routing strategies. We summarize the most
performance comparison of the novel Time on Air (ToA) remarkable findings in Section VII, including a look at the
routing metric. The RP leverages the Spreading Factor (SF). open issues and future work.
This modulation parameter balances communication range
and bit rate, providing multiple channels of quasi-orthogonal II. THE LoRa RADIO TECHNOLOGY
signals when different SF values are used with single radio LoRa, which stands for long range, is a wireless communi-
hardware. This setup allows simultaneous transmissions on cation technology owned by Semtech 1 that operates in the
the same frequency under certain conditions. The ToA metric sub-gigahertz range of the radio spectrum. It employs Chirp
utilizes the multi-SF characteristics of LoRa to determine Spread Spectrum (CSS), a proprietary modulation technique
the best route between nodes based on the total transmission resistant to multi-path fading and suitable for noisy envi-
time required along the entire path, making it sensitive to ronments, aiming to provide low throughput communication
congestion. with links of more than 10 km –outdoors, in rural areas–
To evaluate the RP and the different routing metrics, while maintaining low power consumption.
including ToA, we use the FLoRa framework [7] and the Several parameters of the LoRa physical layer can be
configured to optimize communications for a given scenario
or application: radio band and frequency, channel bandwidth,
transmission power, Forward Error Correction (FEC) rate,
Net work server
and SF. These settings can be applied network-wide or on
Applicat ion servers
Int ernet connect ion a per-device basis. IoT deployments commonly operate on
license-exempt Industrial, Scientific, Medical (ISM) bands,
which change from one geographic area to another; diverse
LoRa transceivers can operate in any of them. Many channels
are available inside these bands for up-link and down-link
transmissions, with thinner or narrower channel bandwidths
and different maximum transmission powers allowed. In
addition to the robust CSS modulation, LoRa’s FEC protects
Smart met ering Environment sensing Fleet t racking
against interference on noisy links. Table 1 summarizes the
configurable parameters and lists their possible values.
The SF is, perhaps, the most distinctive configuration
FIGURE 2: A schematic representation of the LoRaWAN
parameter in LoRa, as it determines a direct trade-off be-
architecture. The gateways in the center define the star of
tween communication range and data rate. Furthermore, two
stars topology and the coverage area for the end nodes at
LoRa transmissions on the same frequency using different
the bottom. At the top, the network and application servers
SFs are quasi-orthogonal [9] meaning that, generally, both
usually reside in the cloud. The orange arrows indicate the
can be successfully demodulated simultaneously, each by a
main issues LoRa mesh networking can address: dependence
different receiver. This feature is leveraged by LoRa gateway
on the cloud, Internet connectivity, gateway infrastructure,
and P2P communication between end nodes. 1 Semtech LoRa Technology Overview - [Link]

2 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

TABLE 1: Configurable parameters in LoRa transmissions scenario they tackle, or the specific features they provide.
Configurable parameter Values
Radio band 169, 433, 868, 915 MHz a A. MULTI-HOP AND MESH ON TOP OF THE LoRaWAN
Bandwidth 62.5, 125, 250, 500 kHz b
ARCHITECTURE
Transmission power 14 dBm (EU), 27 dBm (USA)
Spreading Factor 6 to 12 c The extension of a LoRaWAN network is determined by the
FEC rate 4/5, 4/6, 4/7, 4/8 coverage of the gateway –or gateways– that form it. Even if
LoRa allows transmitting data over several km, sometimes
a Common frequency allocations for ISM in different regions this is not enough to cover vast areas, especially when de-
worldwide; LoRa may also be used in licensed bands. ploying more gateways is technically or economically not
b Smaller bandwidths (7.8 to 41.7 kHz) are also supported, al-
though rarely used.
feasible. Instead, adding multi-hop capability on top of the
c Certain bandwidth and SF combinations may result in too long LoRaWAN architecture has been proposed, allowing packets
transmissions for specific radio bands in which duty cycle or time- to travel through different devices until they reach their des-
on-air limitations often apply. tination. Three main strategies are found: adding multi-hop
to the gateways, adding it to the end nodes, or introducing
intermediate relaying devices [13].
transceiver chips, extensively used in the LoRaWAN archi-
Tian et al. [14] leveraged Concurrent Transmissions (CTs)
tecture. Gateway chips include different signal sampling,
to build LoRaHop, a protocol with multi-hop support for
decimation, switching, and processing steps in their die.
LoRaWAN networks in uplink and downlink directions. Built
They are capable of receiving up to nine LoRa transmissions
upon LoRaDisC (the authors’ protocol that provides regular
concurrently 2 (plus a tenth one using other modulations).
end nodes with the capacity to form a mesh network), it
End nodes typically feature a single-channel transceiver with
allows for relaying messages between a gateway and the
a more straightforward design and a much-reduced cost.
other nodes. To this end, it performs different flooding rounds
These chips allow only half-duplex transmission/reception on
to disseminate data using CT and network coding, hence
a single channel and with a single SF at a time.
not requiring building and updating routing tables. Their
A drawback for LoRa (and, in fact, for any radio tech-
protocol learns the predictable data transmission patterns
nology operating in the sub- GHz part of the spectrum) is
of LoRaWAN end nodes to use the nodes’ idle slots and
the legal duty cycle limitation imposed in ISM bands, which
reduce interference. Utilizing multi-hop, LoRaHop extends
only allows a device to transmit on a given channel for a
LoRaWAN coverage and allows using faster SFs with less
maximum of percentage of time (e.g., in Europe, duty cycle
power consumption.
in the 868 MHz ISM band is 1 %). Sometimes, depending on
Islam et al. [15] modified the Distance Ring Exponential
the local regulation, this limitation can be relaxed if Channel
Stations Generator (DRESG) framework. The relay operation
Activity Detection (CAD) or Listen-before-talk (LBT) mech-
uses intermediate gateways and employs a distance-based
anisms are implemented.
adaptive transmission configuration. The network topology
is structured as a tree, allowing for flexible node positioning.
III. STATE-OF-THE-ART
Nodes are distributed into distance-rings within the system.
Several proposals regarding multi-hop, mesh, and routing for
End nodes are randomly deployed, with the primary gateway
LoRa and LoRaWAN have emerged recently. They have been
at the network center. A non-linear distance-spreading model
thoroughly classified and analyzed by different researchers
establishes virtual rings around the main gateway. The end
from different points of view: taking the application scenar-
nodes are between successive rings, and each network node
ios into account [4], focusing on the LoRaWAN architec-
is associated with its nearest virtual ring. Subsequently, the
ture [10], or on specific implementation aspects like topology
system organizes multiple clusters, each comprising nodes
and routing [11]. Their maturity and Technology Readiness
with the same hop count required to reach the primary
Levels (TRLs) are heterogeneous and range from theoretical
gateway. The formation of these clusters is determined by
contributions to experimentally validated proposals in testbed
the distance of nodes from the main gateway. Intermediate
or real-world deployments.
gateways are strategically positioned within each ring, a
The communication range and transmission rate become
placement contingent on the specific application scenario.
significant factors influencing deployment costs as the system
Lundell et al. [16] designed a routing protocol to provide
scales up. The scalability of LoRa nodes at a low cost de-
mesh networking between gateways to extend coverage in
pends on the ability of transceivers to cover a large area [12]
urban and rural scenarios. This way, gateways without In-
reliably. This fact presents a challenge as it raises the overall
ternet access can forward packets to those with a backhaul
costs and efforts required for expanding the coverage range
connection. They adapted Hybrid Wireless Mesh Protocol
of LoRa networks.
(HWMP) and Ad-Hoc On-Demand Distance Vector (AODV)
In this section, we analyze the most relevant proposals,
to the characteristics of LoRa and built a tunneling mecha-
classifying them depending on their application domain, the
nism that operates transparently to both end nodes and the
2 Semtech SX1301 Digital Baseband Chip - [Link] LoRaWAN server. The protocol was validated only with up-
products/wireless-rf/lora-core/sx1301 link messages in a 4-hops network with in-lab experiments.
VOLUME 4, 2016 3

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

Ebi et al. [17] implemented a synchronous LoRa mesh serviced nodes would be smaller than with a conventional
protocol to extend LoRaWAN networks for end nodes mon- star topology because of the latency introduced by successive
itoring underground infrastructures. Their approach adds re- packet forwarding.
peater nodes that bridge the synchronous LoRa mesh network Zhu et al. [22] improved the capacity of a multi-hop LoRa
segment with the regular LoRaWAN gateway. The results network by off-loading traffic into several subnetworks with
outperform a standard LoRaWAN network concerning the different SFs. This clustering technique results in a multiple-
reliability of packet delivery when transmitting from range- access dimension network where each subnetwork is rooted
critical locations, like underground areas. The solution en- at a sink node with a specific SF. This technique makes
hances transmission reliability, efficiency, and flexibility but packet transmission in parallel with multiple SFs feasible.
requires a precise time reference (e.g., using GPS or DCF77 Their solution ensures the connectivity of all subnetworks,
time signaling) for synchronization. off-loads traffic according to the number of nodes, data rates,
and topologies, and shortens the ToA by reducing the hop
B. MULTI-HOP, MESH, AND ROUTING FOR LoRa count. The authors present a Tree-based SF Clustering Algo-
In this section, our focus shifts toward complex multi-hop rithm (TSCA) that conducts node allocation. Their solution
or mesh topologies. While several works propose linear requires a coordinated effort for the clustering decision-
topologies, as exemplified by works [18, 19], these do not making tasks.
necessitate routing as there is only one possible path between Mai and Kim [23] proposed a collision-free multi-hop
source and destination nodes. LoRa network protocol with low latency. In their network,
Several proposals for multi-hop networks using LoRa do the sink node exchanges packets with the other nodes to
not belong to, or extend, the LoRaWAN architecture. Using construct a tree topology, assigning a timeslot and a channel
alternative strategies like routing, Time-Division Multiple to each link. This way, communication between the leaf and
Access (TDMA), clustering techniques, etc., they create tree parent nodes is collision-free with the neighbors, as nodes
and mesh topologies to build more decentralized and flexible transmit on their frequency during their assigned timeslot.
networks. Systems are often built with only single-channel The authors state that their protocol provides high reliability,
radio nodes, but some combine them with multi-channel parallel transmissions, low latency, and minimized timeslots
gateway hardware. and packet size. However, it is only suitable for networks
Sartori et al. [20] addressed the LoRaWAN coverage with static topology where all the collected data are targeted
extension topic with RLMAC, a MAC layer protocol that towards a single sink node.
enables Routing over Low Power and Lossy Networks (RPL) Prade et al. [24] introduced a multi-radio and multi-hop
multi-hop communications based on LoRa. They argue that LoRa communication architecture to enhance the coverage
the star topology is convenient for ease of deployment and, and service for large-scale IoT deployment in rural areas,
from a business perspective. However, multi-hop could be the called Multi-LoRa. Their multi-hop architecture considered
only option for covering vast areas with few base stations. the limitations of LoRa deployment in scenarios like farms
Furthermore, it could mitigate congestion issues and increase with hundreds of kilometers. They also presented a hardware
throughput or reduce ToA by using faster SFs. The au- prototype implementing their design, which improved the
thors designed a multi-hop solution for single-channel LoRa delay and packet loss figures compared to other setups in a
nodes. They implemented the algorithms to bootstrap and physical testbed and a simulation environment.
operate a network using RPL by combining a slow reception Berto et al. [25] introduced a preliminary study to establish
loop with fast transmission loops. This approach ensures that a LoRa-based mesh network. The prototype of this network
nodes can receive messages using any SFs, albeit at a high is based on RadioHead. The message’s header includes in-
synchronization cost. formation necessary for routing and forwarding, whether the
Lee and Ke [21] designed and implemented a LoRa mesh data is unreliable or reliable, through retransmission upon
networking system to ensure indoor nodes can communi- request. The network ensures multi-hop delivery of data-
cate with network servers without deploying more gateways. grams from a source node to a destination node, potentially
Their design consists of a data sink (somewhat misleadingly, involving zero or more intermediate nodes. The delivery is
the authors call it a gateway) broadcasting beacons to invite achieved through automatic route discovery and re-discovery,
nodes to join the network. Those, in turn, set the gateway facilitated by a particular route discovery request broadcast
(i.e., the data sink) as their parent. New nodes that hear packets. These packets are generated by the source node and
packets from the gateway, or other nodes, can also join the conveyed to the destination node, utilizing a reactive routing
network, choosing a suitable parent based on multiple factors approach. To validate their research, the authors presented
(namely, Received Signal Strength Indicator (RSSI), hop a hardware/software prototype that employed low-power-
count). The gateway polls children nodes to request their data consumption devices and provided an initial assessment of
and holds a complete view of the network topology, which the proposed solution.
it can modify based on its comprehensive information. The As detailed in their publication, Leonardi et al. [26] intro-
authors state that while their solution extends a network’s duced MRT-LoRa, a multi-hop real-time communication pro-
coverage without installing more gateways, the number of tocol designed specifically for LoRa networks. This protocol
4 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

adopts a tree topology organized into levels and employs bandwidth by utilizing multiple SFs simultaneously and mit-
Time-Division Multiple Access (TDMA) to fulfill its multi- igates interference issues that may arise when the same SF is
hop and real-time communication objectives. It structures the used nearby.
network time into repeating superframes. Each superframe Westenberg [31] first exploited the single-node multi-SF
comprises a set of timeslots designated for various purposes, reception strategy for building single-channel LoRaWAN
such as transmitting/receiving beacons, global acknowledg- gateways out of inexpensive ESP8266 and ESP32-based end
ments, data transmission, or data forwarding. These timeslots node devices. This solution is not related to multi-hop or
are scheduled offline across channels and Spreading Factors mesh but demonstrates that a single-channel radio can be
(SFs). The critical distinction between this approach and our used more flexibly. The LoRa chip is configured in a way
proposal lies in the offline scheduling mechanism. that it detects the SF of an incoming transmission automat-
Ghosh et al. [27] proposed LoRaute, where a LoRa mesh ically, so the receiver is dynamically configured every time
network is conceived as a backhaul network with hosts and to decode the signal regardless of the SF used by the sender.
mobile nodes. Routing nodes request their neighbor nodes Given the limited capabilities of the transceiver, the reception
for a list of their neighboring nodes. The obtained list forms is still restricted to one LoRa packet at a time on a single
the routing table of that node. While the experiments were channel. However, this strategy offers the flexibility of using
done with actual nodes, the scale for evaluating the routing any available SFs instead of a fixed predefined one.
capacity was limited to at most seven nodes, and the results Kim et al. [32] proposed an Adaptive Spreading Factor
were tested with only a few scenarios, such that the scope of Selection (ASFS) scheme to build LoRa mesh networks using
the results cannot easily be generalized. single-channel transceivers, increasing throughput and reduc-
Arratia et al. [28] presented a LoRa network-based solu- ing costs. Their proposal uses the modems’ CAD capability
tion to solve the data transmission of buoy sensor nodes in with an iterative SF inspection and selection algorithm that
a lagoon. A multi-hop network forwarded messages without allows links to operate independently at different data rates,
the need for a routing protocol. The evaluation was centered achieving almost 100 % correct detection. This idea had
on practical aspects of the IoT application case, such as the already been implemented on single-channel gateways but
throughput with different SFs and energy consumption. The had not previously been adapted for multi-hop usage. The
evaluation scale was limited to a few nodes corresponding to authors experimentally evaluate the proposal with up to 10
the actual deployment of the network. nodes and compare three topologies (star, tree, and mesh)
In [29], we introduced the LoRaMesher library. The using Semtech’s single-channel SX1272 and multi-channel
LoRaMesher library offers multi-hop mesh delivery capa- SX1301 transceivers. Using ASFS allows nodes to choose
bilities in the form of a real implementation that enables different and faster SFs, achieving data rates four to six times
the operation of a LoRa mesh network on physical nodes. faster than without it (when all the nodes stick to a common,
However, LoRaMesher’s routing protocol is single-SF and network-wide slower SF).
uses a simple hop count metric, limiting certain scenarios’ Both references in this section are essential to our pro-
operation. Because LoRaMesher is not available as a simula- posal. They provide the foundations to build faster and more
tor, it is not easy to employ a real deployment to conduct the complex LoRa mesh networks with single-channel trans-
performance evaluation of a large-scale design space. On the ceivers, e.g., by choosing the SFs on a per-link basis to
contrary, the simulation results of the multi-SF ToA of this maximize the throughput instead of using a [much] slower,
paper can feed back into the implementation improvements common network-wide SF.
of LoRaMesher. While our proposal involves SF detection using preamble
Summarizing the above works, the most used routing met- detection, similar to the approach presented in [31, 32],
ric in today’s practical state-of-the-art LoRa mesh networks alternative techniques exist to achieve the same goal. Koch et
is the hop count in single SF scenarios. While the results al. introduced a method based on Discrete Wavelet Transform
demonstrate the feasibility of LoRa mesh networks, there is for SF detection that is agnostic to transmitter settings, as
still a lack of understanding of more complex routing metrics detailed in their work [33]. This computationally lightweight
for these networks and how the multi-SF potential that LoRa algorithm can be implemented on readily available Software-
offers can be integrated into the network operation. Defined Radios (SDRs), thereby reducing the cost and com-
plexity of multi-SF reception in single-channel implementa-
C. MULTI-SF RECEPTION WITH SINGLE-CHANNEL tions.
LoRa RADIO IN CLIENT NODES
As discussed in their work, Croce et al. [30] demonstrated IV. A MINIMALISTIC Distance-vector Routing Protocol
that it is not always possible to achieve independent LoRa FOR LoRa MESH NETWORKS
transmissions using different spreading factors simultane- To assess multi-hop LoRa mesh networks and overcome
ously due to imperfect orthogonality. However, this limita- most of the related work limitations, we propose a proactive,
tion does not prevent the creation of links between different hybrid Layer 2/3 (L2/3) DV RP that takes advantage of this
nodes within a mesh network using different Spreading Fac- radio technology’s specific characteristics. Our design prin-
tors (SFs). This approach effectively expands the network’s ciple is to keep complexity to the minimum needed so that
VOLUME 4, 2016 5

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

it could be run on resource-constraint embedded devices fea-

turing a microcontroller and a LoRa radio. Besides that, the n0
n1
RP can benefit from LoRa’s SFs different range and orthog-
onality properties, which allow for concurrent transmissions
between other pairs of nodes. To achieve it, we also introduce
a novel multi-SF-aware ToA metric that minimizes the total n2
transmission time for a packet to reach the destination, which n3
improves performance under certain network conditions.
Our protocol’s main features are:
• Distance-vector: best routes towards any destination are
calculated in a distributed way across nodes based on n4
the information provided by the neighbors. n5
• Pro-active: network nodes periodically broadcast availa-
n6
ble routes, independent of data traffic, refreshing and
keeping routes up-to-date and readily available. FIGURE 3: Topology of a sample LoRa mesh network.
• Layer 2+3 hybrid: by aggregating the two layers into Links between each pair of nodes may use any valid SF (the
one, we simplify and optimize the architecture and the diagram shows the smallest and fastest possible to create a
requirements for low-power embedded LoRa devices. working link). Most links are symmetrical, but others require
• Duty cycle-aware: for networks operating in unlicensed different SFs in each direction; this may generate different
ISM bands, time-on-air limitations in the form of duty routes for each direction between a pair of nodes.
cycles are usually enforced; these restrictions can be
embedded into the route metrics calculations.
• Lightweight, flexible, and configurable: many aspects of (Layer 3 (L3)) layers into a single one (compared to, e.g., the
the protocol (metric, packet timing, etc.) can be fine- Wi-Fi 802.11+IP stack and Ethernet 802.3, where addresses
tuned to fit specific use cases. of different types are used on each layer). This solution
• Concurrent, overlaid networks: thanks to the orthogo- reduces network traffic overhead and computing effort on
nality properties of LoRa’s SFs, several “virtual” lay- the nodes, although it may limit direct interoperation with
ered networks can operate on the same radio channel, other networks (e.g., the Internet). In our design, network
providing higher global throughput. addresses take 2 bytes, ranging from 0x0000 to 0xFFFF
• ToA metric: route costs are calculated based on the resulting in up to 65.536 usable addresses per network. We
end-to-end packet transmission time, taking multi-SF consider this specific addressing space size a convenient
capability into account. value between the ability to build an extensive mesh net-
work, LoRa’s throughput and range performance, and ease of
A. NETWORK TOPOLOGY AND ADDRESSING implementation. However, it could be reduced or increased
The RP builds a flat mesh network topology with no hierar- when implemented in particular scenarios. For example, a
chical differentiation between nodes, regardless of their hard- smart metering network covering a city with hundreds of
ware characteristics or role at the application level. To join thousands of nodes may require a larger addressing space.
the network, a node runs an instance of the RP, generates a Still, other strategies (e.g., network partitioning) could be
local routing table and exchanges routes with its neighboring more effective in scenarios.
nodes periodically. The RP supports transmitting network packets in unicast to
Figure 3 shows the topology of a sample LoRa mesh a single node using its unique network address or broadcast-
network running the RP. One-hop, direct communication ing to all the neighbors at one hop using a broadcast address.
between a given pair of nodes can usually be performed For the latter mode, the highest address (0xFFFF) is only
with different SFs; the diagram indicates the fastest (i.e., the reserved for broadcast routing packets. Reception acknowl-
lowest) one that makes the link possible. Communication edgments, packet retransmissions, etc., can be implemented
between distant nodes that are not directly connected is made in higher layers. The RP does not handle them to keep it
by multi-hop packet forwarding, using the routes calculated as simple as possible and reduce its footprint on embedded
by the RP. While most of the links in the diagram are nodes. Therefore, neither one-hop nor end-to-end delivery is
symmetric, a few require different SFs in each direction to guaranteed at the routing level.
achieve a successful communication. This asymmetry can
happen in scenarios with heterogeneous hardware or envi- B. NETWORK PACKETS STRUCTURE
ronmental conditions, either temporary or permanent. As a Data and routing packets have a very similar structure,
result, packets traveling between a given pair of nodes could schematically depicted in Figure 4. Since packet size is con-
use different routes in each direction. strained by the LoRa hardware to a maximum of 256 B, our
To simplify the design of the RP and the applications built protocol uses a minimalistic approach to reduce the overhead
upon, we merge the data link (Layer 2 (L2)) and the network introduced by the header, which takes 7 B at most.
6 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

Dest NextHop SF Cost Expiry

Source Destination
(2 bytes) (2 bytes) 0x0001 0x0001 10 - 189
0 2
0x0002 0x0002 7 - 293
0x0004 0x0004 9 - 251
Via* Flags, TTL
0x0001 0x0002 - 4 293
(2 bytes) (1 byte) 0x0003 0x0002 - 3 293
4 6 7 ... 0x0004 0x0002 - 3 293
0x0005 0x0002 - 5 293
Payload 0x0006 0x0002 - 4 293
(max. 249 bytes)* 0x0002 0x0001 - 4 189
255 0x0003 0x0001 - 12 189
0x0004 0x0001 - 9 189
FIGURE 4: Structure of a data/routing packet. Source and ... ... - ... ...
Destination bytes identify the communication end points. Dest Source SF Cost Expiry
The Via field is omitted when the broadcast address (0xFFFF) 0x0000 0x0001 9 - 189
0x0000 0x0002 7 - 293
is set as the destination. The Flags/TTL byte is used to
0x0000 0x0004 10 - 251
identify the packet type and watch its lifespan. The Payload
field can carry either the RP information or the application TABLE 2: Routing table for node n0 from Figure 3. The
data, depending on the packet type. first block contains the routes from n0 to all other nodes. The
second block corresponds to routes from neighbor nodes to n0
(which is required to account for asymmetric links correctly).
The first 4 B of a data packet holds the address of the node
originating the message (Source, 2 B) and the address of the
final recipient (Destination, 2 B). The following field (Via,
2 B) is used in multi-hop data packets to indicate the address Table 2 shows a snapshot of the routing table for node n0
of the next hop in its route. Its value changes from hop to hop from Figure 3. In the first block, the three entries on top show
as intermediate nodes forward the packet. In the last hop in the direct, single-hop routes from node n0 to its neighbors
the route, or for single-hop data packets, the Via field should n1 , n2 and n4 (indicated by Dest=NextHop, but using a
be the same as the Destination. The Flags, Time to live (TTL) different SF). The following entries show multi-hop routes
space (1 B) is reserved for tagging packets (2 b) if required by to other routes in the network (indicated by Dest̸=NextHop).
the upper application layer and to account for the TTL (6 b) The routes include the nodes that are not directly reachable
This approach effectively sets a maximum number of hops using one hop (n3 , n5 and n6 ) and also those that have a
to 64 for any packet. Last, the Payload field holds the actual better metric using a multi-hop path rather than the direct link
application data or the RP exchanged between different nodes (this is the case for n1 and n3 ). For instance, the direct single-
(see next section), holding up to 249 B. hop path n0 ⇒ n4 has a higher ToA cost than the multi-hop
Routing packets are differentiated from regular data pack- path n0 ⇒ n2 ⇒ n4 .
ets because they use the broadcast address in the Destination The second block of entries in Table 2 shows inbound
field instead of a unicast address. Therefore, the Via field is routes to node n0 . Node n0 does not use them for its own
not necessary and is hence omitted to save 2 B that can be routing decisions. However, it must keep track of them and
assigned to the payload, which becomes up to 251 B long. let its neighbor nodes learn about them. This way, neighbors
can know the minimum SF required to reach n0 and correctly
C. ROUTING TABLE calculate their routes toward it.
Each node in the network runs an instance of the routing Upon successfully transmitting a new routing packet, the
protocol, creating a local routing table that is constantly receiving node processes it and refreshes its local routing
updated as messages from neighboring nodes are received. table, updating the information accordingly. First, the link
Being a DV protocol, the table consists of a list of all the characteristics with the source neighbor node are added to
nodes known to be in the network, the neighbor through the routing table or refreshed if already present. Then, one by
which they can be reached, the path cost, and the route one, the announced routes are processed. Depending on the
expiry time. With the information in the table, every node case, they will be added to the routing table, used to update or
can theoretically communicate with any other node in the replace known routes, or discarded if not useful. The diagram
network directly (if they are neighbors) or indirectly using in Figure 5 shows this process as a flow chart.
multi-hop. Furthermore, every node can also forward multi- As exemplified by Table 2, a routing table may contain
hop traffic that goes through it towards its destination. different entries with routes to the same node via different
In addition to the routes towards other nodes, each node next hops. While the RP will use the one with the lowest cost
also keeps track of the routes from neighbor nodes to it. Since by default, this provides alternatives in case the main route
the physical connection between two neighbor nodes may suddenly increases its cost or expires. However, maximum
not be symmetrical, the RP also needs to feed back neighbor total and per-node routes can be established to limit the
nodes with the information of its inbound links so that they table’s growth.
can correctly calculate the routes towards it.
VOLUME 4, 2016 7

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

Section III-C to enable multi-SF reception. Therefore, they

can send and receive packets on any SF available between
SFmin and SFmax . The RP can use single-SF metrics, where
all the nodes are expected to use a single, network-wide SF,
No Yes
and multi-SF metrics, where nodes may dynamically switch
between SFs depending on their current status.
The transmission time for a packet when using a given SF
is approximately double the time required by the immediately
lower SF. 3 Therefore, when using multi-SF metrics, rout-
ing packets are sent using the following strategy. Broadcast
messages on any given SF are sent twice as often as on the
immediately higher SF (i.e., broadcast packets using SF9 are
sent at double the rate than packets using SF10). This method
of proceeding balances the cost of using different SFs and
helps keep routes using faster links more up-to-date than
those using slower links. Broadcast packets on different SFs
are sent in random order (rather than sequentially) using the
following probability formula:
2SFmax −SFn
p(SFn ) = Pmax SFi −SFmin
i=min 2

since: (1)
Xmax
p(SFi ) = 1
i=min
p(SFmin ) = 2SFmax −SFmin · p(SFmax )
Sending packets on different SFs randomly, instead of using
a predefined sequence, also helps to avoid repeated collisions
if nodes become synchronized.
The following pseudo-code implements the random selec-
FIGURE 5: Flow chart upon reception of a new routing tion of a SF between SFmin and SFmax with the probability
packet at a node. described above:

Algorithm 1: Random selection of the SF on which

D. ROUTES EXCHANGE BETWEEN NEIGHBOR NODES to broadcast a routing packet.
Nodes running an instance of the RP periodically broadcast SF = 0;
routing packets to their neighbors. This way, they proactively while SF == 0 do
generate the network topology and keep it updated by re- thisSF = SFmin;
freshing their routing tables locally as packets from neighbor while thisSF ≤ SFmax do
nodes are received. These packets include: if random(0, 1) < 0.5 ) then
• the source node information (i.e., its address) SF = thisSF;
• a 6 b incremental counter (instead of the TTL, which break;
can be used to evaluate packet loss and collisions on a else
link to infer its quality or its occupation) thisSF++;
• an excerpt of the source node routing table (i.e., a list end
with the best routes and their path cost to the other nodes end
in the network). end
With this information and the details from the LoRa radio
physical layer (namely, the SF used to transmit the message), As mentioned in Section IV-B, routing packets are very
the nodes that receive the broadcast packet update their local similar to data packets, except that they are single-hop and
routing tables accordingly. In turn, these nodes will propagate use the broadcast address as the destination, skipping the
their routes further away to their neighbors when they send
3 To be precise, the LoRa symbol rate is linear with the SF, but the time on
their own broadcast messages.
air calculation also depends on other non-linear factors. The exact formula
The devices running the RP are expected to have single- can be found in the documentation provided by the chip manufacturer (e.g.,
channel LoRa radios and use the technique described in Semtech SX1276’s datasheet).

8 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

SF Rx sens. PT x BW Dist. ∆dist.

Source: 0x0000 Destination: 0xFFFF
(2 bytes) (2 bytes) 7 −124 dBm 20 dBm 125 kHz 250 m n/a
0 2
8 −127 dBm 20 dBm 125 kHz 349 m ×1, 4
9 −130 dBm 20 dBm 125 kHz 487 m ×1, 4
10 −133 dBm 20 dBm 125 kHz 679 m ×1, 4
Flags, Cnt. Route #0 Route #1
(1 byte)

0x0000 0x0001

0x0000 0x0001 11 −135 dBm 20 dBm 125 kHz 848 m ×1, 25
4
5 SF10 11 SF7 12 −137 dBm 20 dBm 125 kHz 1058 m ×1, 25

Route #10 Route #11 TABLE 3: Maximum reach, in the simulator, with different


0x0002 0x0000

0x0004 0x0000
SFs.
65 SF11 71 SF10

FIGURE 6: Sample routing packet as sent by node n0 from

Figure 3. The Destination address field indicates a broadcast send data packets and uses unicast transmissions only for the
packet destined to its neighbors. Routes in the payload corre- last hop.
spond to those in the routing table from Table 2.
2) Single-SF metrics
Our RP implements four metrics for LoRa mesh networks
Via field. Their payload contains the network routes, as where nodes use a single network-wide SF. The first and
advertised by the source node. Figure 6 shows an example simplest one is HC, for which the cost of a given path equals
of a routing packet (corresponding to node n0 from Fig. 3), the number of hops required to reach the destination.
where the payload contains the best routes of the routing The second metric is ETX, for which the cost of a given
table from Table 2. If the routing table does not fit inside the path depends on the links along the route, proportional to the
packet’s payload, routes to transmit are chosen randomly by number of transmissions required to reach the destination.
assigning each route a transmission probability as a function The quality of a link between two nodes is calculated based
of its Cost value. This design decision makes routes to nearby on the number of lost routing packets over a period of time
nodes more updated than those to distant devices. Therefore, (the more lost packets, the worse the link is and the higher its
route timeouts must be configured based on the number of cost).
nodes and the topology of the specific deployment to avoid Two more single-SF metrics are available, which calculate
flapping. path costs based on the physical links’ RSSI. The RSSI sum
Upon reception of a new routing packet, nodes process it metric uses the reception quality measure to calculate a route
and refresh their local routing table, updating it accordingly. cost as a sum of RSSIs along the path:
First, the link characteristics with the source neighbor node Xn
|min(RSSIh , −1)| (2)
are added or refreshed in the routing table. Then, one by h=0
one, the received routes (if any) 4 are processed and added or so that links with lower signal reception quality incur in a
updated in the routing table. The diagram in Figure 5 shows higher route cost. Likewise, the RSSI product metric uses
this process as a flow chart. the reception quality measure to calculate a route cost as the
product of RSSIs along the path:
E. ROUTING METRICS Yn
Our RP can be configured to use different routing strategies, |min(RSSIh , −1)| (3)
h=0
particularly regarding the metric used to calculate the costs
of the possible paths towards a destination. These determine 3) Multi-SF Time on Air (ToA) metric
which node a packet will be forwarded to reach its destina- The SF is a critical element of the LoRa radio technology, as
tion. The protocol can use a Broadcast (BC) flooding strategy, it poses a trade-off between the transmission reach and the
single-SF metrics (like the well-known Hop Count (HC) or time required to send a packet. Roughly, switching to a SF
Expected Transmission Count (ETX)), or our proposed ToA one step higher (e.g., SF7→SF8) doubles the transmission
multi-SF metric. time (or halves the transmission speed, see Fig. 9), while in-
creasing the distance between ×1, 25 and ×1, 4 (see Table 3).
1) Broadcast packet flooding Taking the restrictions mentioned above into account, we
The most straightforward multi-hop operation for the RP propose a Time on Air (ToA) routing metric to evaluate the
consists of a packet flooding strategy, with no actual routing cost of a path towards a destination that aims at minimizing
involved. Nodes keep a copy of the last packets received and the total end-to-end time required to transmit a packet from
broadcast in a finite buffer to avoid double broadcasts that source to destination and the radio channel occupation.
would cause traffic amplification. The ToA metric in our RP calculates the path cost towards
A smarter version of the flooding strategy, still not involv- a node as a function of the SFs used by the successive links
ing actual routing, keeps track of neighboring nodes as they between forwarding nodes until reaching the destination. It
ponders the cost of the hop hl,m between two neighbor nodes
4 A node joining the network would start with an empty routing table. For nl and nm as a power of 2:
a period of time, it would not include any routes in its routing packets but
only send to announce itself. hl,m = 2SFl,m −SFmin (4)
VOLUME 4, 2016 9

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

where SFl,m is the smallest SF required to successfully trans- ability before starting an infinite count. Additionally, it may
mit between nodes nl and nm , and SFmin is the minimum increase network convergence times.
SF available in the system. 5 Therefore, we calculate the cost
of a path between two arbitrary nodes ni and nj , with H 3) Maximum route cost
intermediate hops, as: Routes have a finite maximum cost, and those reaching this
XH XH value are discarded. Therefore, in the event of an infinite
ToAi,j = hk = 2SFk −SFmin (5) count loop, affected routes are eventually discarded.
k=1 k=1
This parameter poses a trade-off between how fast loops
where SFk corresponds to the SF used in each of the interme- are fixed and how large a network can be regarding routing
diate H hops in the route. If two or more paths are available (i.e., maximum number of hops).
with the same metric, the one with the next hop using a lower
SF is preferred. Still, in case of a tie (same metric and same 4) TTL
SF in the next hop), the path is chosen randomly among the Data packets have a maximum hop count of 64 hops. How-
contenders. ever, this limit can be set to a lower value, like the number of
The example in Figure 3 uses SF7 as the smallest SF known nodes in the network (if smaller than 64). This way,
available (SFmin ). Using the ToA metric, the cost of the packets entering a routing loop will be discarded sooner, as
direct single-hop path from node n0 to node n1 would their TTL is exhausted.
be 210−7 = 8. Instead, the three-hops path via nodes n2
and n3 would be preferred, since its ToA metric would be 5) Avoid duplicate transmissions
27−7 + 28−7 + 27−7 = 1 + 2 + 1 = 4. The usage of a When the flooding mechanism is used (Section IV-E1) in-
simple additive metric calculation is convenient in the context stead of actual routing, nodes hold a copy of the last packets
of resource-constraint IoT devices, which are often driven by they forwarded in a finite buffer. If the packet is received
8 or 32 bit Microcontroller Units (MCUs). These operations again to be forwarded, it is discarded, avoiding duplicates and
can be easily implemented and require few processor cycles. loops. This mechanism is also employed when actual routing
Section VI evaluates the metric in depth in a simulation is implemented and complements the TTL embedded in the
environment and compares it with other well-known metrics. packets to avoid them entering routing loops.

F. LOOPS MITIGATION G. PROTOCOL CONFIGURATION

Our RP is subject to routing loops (e.g., in the case of a Many parameters of the RP can be configured to adapt to
node disappearing from the network), which is a common specific use cases and conditions. This section summarizes
problem in DV algorithms. To mitigate them or their effects, the most remarkable ones for the RP operation.
we implement the following mechanisms. First, several LoRa-related aspects can be customized. For
instance, the maximum SF to use can be changed (from
1) Route poisoning the default SF12 to a smaller one, which could be required
If a direct route (i.e., to a one-hop neighbor) reaches the in certain regulatory domains). Instead of the default ToA
timeout on a given node, it broadcasts this route with the metric, other well-known ones can be chosen (HC, ETX,
maximum possible cost. This way, nodes will drop the ex- etc.). Other aspects, like the expiry time of a learned route,
pired route sequentially and propagate the action along the can be modified to ensure the liveliness of the information in
network. the routing table. Table 4 shows these configurable parame-
Given that routing packets are transmitted without recep- ters. Regarding data and routing packets, their transmission
tion guarantees, this mechanism may have a limited impact priority at a node can be adjusted in an n : 1 ratio. Similarly,
on loop mitigation, especially on busy networks with high forwarded and local data packets can be prioritized according
packet collision probability. As a possible workaround, poi- to the application’s needs.
soned routes could be broadcast twice or more before being
deleted locally. V. EVALUATION METHODOLOGY
In this study, we use OMNeT++ [8], an extensible, modular,
2) Hold-down component-based C++ simulation library and framework, in
When a node learns about an unreachable route (e.g., a failed combination with FLoRa [7], a framework to carry out end-
neighbor), it sets up a timer. During this period, the node to-end simulations for LoRa networks. OMNeT++ is a well-
ignores incoming information about the route, avoiding an known discrete event simulator framework used by a lively
infinite count situation. academic community and, together with FLoRa, it provides
This mechanism may be only partially effective, depend- an implementation of the LoRaWAN architecture [34] and
ing on whether a node can detect or receive a route’s unreach- an accurate model of the LoRa radio physical layer derived
from previous experimental findings [35]. Its features and
5 The smallest SF available in LoRa is SF6. For practical reasons, the performance have been analyzed, evaluated, and compared
minimum SF commonly used is SF7, but a higher value could be preferred. to other available tools [36].
10 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

Scope Parameter Range Default

LoRa Minimum SF SF7, . . . SFmax SF7
LoRa Maximum SF SFmin , . . . SF12 SF12
Routing Metric BC a , HC, ETX, RSSI (sum/product), ToA ToA
Routing Average routes broadcast period 0 ...∞ 60 s
Routing Routes expiry time (SFmin ) 0 ...∞ 300 s
Routing Max. routes to a node 1 ...n 2
Routing Max. total routes 0 . . . 1024 1024
Routing Routing/Data traffic prior n:1 10 : 1
Routing Forward/Local traffic prior n:1 10 : 1
Regulation Duty cycle (%) (0, 100) – 100 100

TABLE 4: Configuration options for the RP.

a Even if broadcast-based flooding is not a routing metric, but a strategy.

Dx
dx
whether using one given SF and, concurrently, in addition,
n0 n1 ... n4
n0 n21
n9 higher ones, has any impact on performance, compared to
dy dy dy using just one). On the other hand, the random topology
n5 dx n6 ... n9
n6 n5
allows measuring how multi-SF routing adapts to hetero-
Dy ... geneous situations and how using different SFs in different
... ... ...
n20
n4 parts of the network (i.e., use the fastest SF possible for each
n1
link between pairs of nodes) performs compared to using
dx
n20 n21 ... n24 n24 network-wide common SF that provides communication to
all the participating nodes.
(a) Symmetric grid topology, (b) Random topology, with When nodes are arranged following a grid topology, four
with equal horizontal (dx ) and nodes distributed over a Dx × different spacing between them are used (both vertical and
vertical (dy ) spacing between Dy area using a uniform density
nodes. probability function.
horizontal): 177 m, 178 m, 246 m and 247 m. These values
are not arbitrarily chosen but have a specific purpose, as
FIGURE 7: Depiction of the network topologies used in the depicted in Figure 8. A spacing between of 177 m allows
simulations. nodes using the shortest-range SF7 to communicate with
their adjacent nodes in horizontal, vertical, and diagonal
(Fig. 8a). When the spacing is increased by one unit, diagonal
We have stripped down the LoRaWAN functionalities communication with adjacent nodes is no longer possible
from the FLoRa framework, allowing direct communication with SF7, only vertically and horizontally. Similarly, a 246 m
and packet forwarding between end nodes without a gateway. spacing or 247 m allows communication between adjacent
Our solution includes adding a DV routing protocol with nodes in diagonal with SF8 or requires using the slower
different path cost calculation metrics. Furthermore, we have SF9. The experiments with these four spacing values allow
added to the framework other helpful features, like the CAD a comparison of how the mesh density affects the network
found in other implementations [31, 32]. The source code performance.
for our derived project, rebranded as FLoRaMesh, is publicly When the random topology is used, nodes are uniformly
available on GitLab [37]. distributed over the same area occupied by the grid topology.
For instance, in a network with N 2 = 36 nodes, to compare
A. NETWORK TOPOLOGIES it with a grid topology where nodes are spaced 178 m:
The simulations consist of a network with a variable number 5 · 178 m × 5 · 178 m = 890 m × 890 m). This approach
of nodes arranged in two different topologies: an N × N allows comparison between a synthetic network and a more
symmetrical grid topology with equal vertical and horizontal heterogeneous deployment.
distance (Fig. 7a) and a random topology with N 2 nodes
uniformly distributed over a delimited square area (Fig. 7b). B. NODES CHARACTERISTICS
Each of these two topologies serves a different evaluation All the nodes are identically configured in the simulation,
purpose. On the one hand, the grid topology with a constant using the same settings for the LoRa physical layer (e.g.,
distance between nodes offers a regular and predictable transmission power, bandwidth, etc.), as listed in Table 5.
environment. Therefore, once the right SF and transmission Therefore, their behavior and performance are only affected
power are set, single SF routing provides communication by their network position and interaction with neighbors are
to either all or none of the nodes, and performance will only affected by their behavior and performance. Most of the
only depend on the metric properties (rather than on the chosen configuration parameters (SF, bandwidth, preamble
network topology characteristics). This procedure also allows size, etc.) are typical in real-world deployments [38]. Given
checking if multi-SF routing can offer any advantage (i.e., these settings in the simulator, two nodes using SF7 can
VOLUME 4, 2016 11

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

n33 n34 n35

n44

(a) dx = dy = 177 m (b) dx = dy = 247 m

FIGURE 8: Minimum SFs required for a LoRa packet to successfully reach different nodes from node n00 .

Configurable parameter Values

Carrier frequency 868 MHz
random order, thus evenly distributing traffic between all the
Channel bandwidth 125 kHz nodes in the network.
Spreading Factor (SF) 7, 8, 9, 10, 11, 12 a
Transmission power 20 dBm D. PRELIMINARY SIMULATOR AND LoRa HARDWARE
Coding rate (CR) 4/5
Preamble length 16 symbols BENCHMARK
We run a simple benchmark to verify that the devices sim-
TABLE 5: Common node settings in the simulations. ulated with the FLoRa framework offer a network perfor-
mance comparable to real ones. The experiment consists of
a Single-SF metrics are tested with all the possible SFs, one by
two nodes, one transmitting packets continuously for one
one. Multi-SF metrics are tested with all the possible combinations of
consecutive SFs (e.g., SF7-8, SF7-9, SF7-10, etc. hour and the other listening to them. Duty cycle restrictions
are not enforced, letting the transmitter occupy 100 % of the
airtime.
successfully communicate up to 250 m apart. Therefore, to We perform several simulations using different payload
reach nodes further away, a node either must switch to higher sizes with all the SFs, 7 to 12, and count the number of
SFs, use packet forwarding via its neighbors, or combine received packets to calculate the achieved throughput. In
both strategies. This maximum communication distance also parallel, we run the same experiment with real hardware,
motivates the spacing described previously in Section V-A. using two TTGO ESP32 devices 6 and the RadioLib library
For completeness, Table 3 summarizes the maximum to interact with the LoRa transceiver [39]. Table 6 provides
transmission distance a node can reach in the simulator, the node configuration and settings used in simulated and real
for all the available SFs. The values depend on the LoRa environments. Note that since the real devices are deployed in
settings specified in Table 5 and on the radio propagation the lab, only 2 m apart, the lowest transmission power is used,
model implemented in the simulator framework (in this case, and a 15 dB attenuator is coupled to the antenna to minimize
an urban environment). With a maximum of 1058 m, when radio emissions to the environment.
using SF12, communication between nodes further away is Figure 9 shows the achieved throughput from the source
only possible through multi-hop. to the destination, for both the FLoRa simulation and the
physical devices. Values range from 7.4 bps (smallest 1 B
C. TRAFFIC SETTINGS payload using SF12) to roughly 5 kbps (250 B payload size
During a simulation run, each node generates a total of or bigger, using SF7). While the simulator and real hard-
100×(N 2 −1) unique data packets (i.e., 100 different packets ware provide similar results, noticeable deviations occur. In
for each one of the other nodes in the network) with a fixed particular, achieved throughput with lower SFs is up to 6 %
size of 27 B (header+payload). The packets are progressively higher in real hardware than in the simulator. This behav-
sent during the simulation, at regular intervals of 100, 10, ior could be attributed to how the software calculates the
1, and 0.1 s (corresponding to a low, medium, high, and 6 LILYGO® TTGO ESP32: [Link]
saturation traffic respectively), towards their destinations in TypeId=50003&Id=1271&FId=t3:50003:3

12 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

Configurable parameter Values

Carrier frequency 868 MHz
VI. EXPERIMENTAL RESULTS
Link bandwidth 125 kHz This section evaluates the proposed RP for LoRa mesh
Spreading Factor (SF) 7 networks. We conduct several experiments using different
Transmission power 20 (FLoRa), 2 dBm (TTGO) topologies, traffic settings, and node configurations to obtain
Coding rate (CR) 4/5
LoRa packet preamble 16 symbols performance details about three significant Key Performance
Message header size 7 bytes Indicators (KPIs): scalability, throughput, and latency.
Message payload size 1 to 500 bytesa To get a better understanding of the protocol capabilities,
Time between packets 0s
we perform the set of experiments using the different multi-
Duty cycle 100 % (i.e., no restriction)
hop and routing strategies presented in IV-E: Broadcast (BC),
TABLE 6: Node settings for the benchmark experiment. Hop Count (HC), Expected Transmission Count (ETX), Re-
ceived Signal Strength Indicator (RSSI) 7 and multi-SF ToA.
a RadioLib allows a total message size of 256 B maximum, while
FLoRa allows an arbitrarily big message size. A. SCALABILITY
The first KPI we analyze is scalability to understand how a
LoRa mesh network behaves as the number of nodes grows.
A network can scale up when adding more nodes, covering a
larger area, or keeping it fixed and increasing the density of
the devices.
To understand the behavior of our RP with the LoRa radio
technology regarding scalability, we perform two sets of
experiments for both scenarios mentioned above and analyze
the effects of each. First, we simulate a mesh network as
it increases its number of nodes, keeping the nodes at a
constant distance, covering a larger area each time. Second,
FIGURE 9: Maximum unidirectional data throughput, in we analyze a mesh network covering a predefined fixed area
bps, with different payload sizes, for SFs 7 to 12. Solid lines with an increasing number of nodes and, hence, an increasing
correspond to the FLoRa simulator. Dotted lines are obtained density.
from two TTGO ESP32 devices. To evaluate our multi-SF routing protocol based on the
ToA metric, we test it under low, medium, and high traffic
conditions and compare it with the single-SF BC, HC, ETX
packet transmission time. Also, the performance of hardware and RSSI routing strategies. We simulate network deploy-
devices appears slightly lower with large payloads. This ments with N 2 = {9, 16, 25, 36, 49 and 64} nodes, both on
decrease in performance could be caused by delays in the a grid topology or randomly distributed over an equivalent
embedded System on a Chip (SoC) when receiving packets area. The ToA metric is tested with all the possible SF ranges
from the LoRa transceiver and processing them. Considering (i.e., SF7-8, SF7-9, SF7-10, SF7-11, SF7-12, then SF8-9,
the magnitude of these discrepancies, we assume that the SF8-10, SF8-11, etc.).
modifications made to the FLoRa framework do not affect its
accuracy so that it provides a simulation environment precise 1) Area coverage
enough. In this section, we perform different network simulation
experiments to investigate network scalability. An increasing
E. DUTY CYCLE number of nodes covers an area that grows proportionally.
Radio spectrum regulators usually enforce duty cycle lim- We look at the end-to-end PDR performance metric of the
itations. For example, the unlicensed ISM bands where data packets sent between any pair of nodes in the network.
LoRaWAN is commonly used are subject to a 10 % or a We hypothesize that, as more nodes operate on the network
1 % duty cycle in most parts of the world. However, LoRa and, on average, the distance between a pair of nodes will
radios can also be used in bands without limitations on the be higher, end-to-end transmissions will require more hops,
transmission time, whether licensed or not (e.g., the 2.4 GHz which will result in a higher number of collisions, hence
band). increasing packet loss and reducing PDR. Our objective is to
The FLoRa framework, in its original form, enforces the find whether using the multi-SF ToA metric and combining
duty cycle restrictions found in ISM bands to the simulations. different SFs in the network improves the average PDR or
In our derived work, FLoRaMesh, we implemented the duty not.
cycle enforcement mechanism at the routing protocol level. A Initially, we simulate network deployments on a regular
user-configurable parameter in the (0, 1] interval is employed grid topology, keeping horizontal (dx ) and vertical (dy ) dis-
to define the average fraction of time that a node can spend tance between nodes constant. Thus, as the number of nodes
transmitting messages. 7 Simulations with RSSI sum and RSSI product reported almost identical
results, so only the first one is shown in the results for simplicity.

VOLUME 4, 2016 13

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

Topology Nodes dx = dy Area

Grid 9 177 m 354 × 354 m2
178 m 356 × 356 m2
247 m 494 × 494 m2
248 m 496 × 496 m2
Random 9 n/a 354 × 354 m2
(uniform) n/a 356 × 356 m2
n/a 494 × 494 m2
n/a 496 × 496 m2
Grid 16 177 m 531 × 531 m2
178 m 534 × 534 m2
247 m 831 × 831 m2
248 m 834 × 834 m2
Random 16 n/a 531 × 531 m2
(uniform) n/a 534 × 534 m2
n/a 831 × 831 m2 FIGURE 10: Nodes density (nodes/km2 ) in function of the
n/a 834 × 834 m2 number of nodes simulated, for the different spacing between
... ... ... ... nodes dx used in Sec VI-A1. The graphs show an asymptotic
Grid 64 177 m 1239 × 1239 m2
178 m 1246 × 1246 m2 behavior.
247 m 1729 × 1729 m2
248 m 1736 × 1736 m2
Random 64 n/a 1239 × 1239 m2
(uniform) n/a 1246 × 1246 m2 results, with respectively 99 % of the packets successfully
n/a 1729 × 1729 m2 delivered end-to-end. The flooding strategy’s redundancy,
n/a 1736 × 1736 m2 combined with the relatively free nodes, allows room for
packet duplication, which helps ensure that at least one of
TABLE 7: List of topologies, number of nodes, distance
between nodes, and the total area used in the simulations. the copies reaches the destination. This approach, however,
comes at the expense of high latency, as packets are often
queued in the intermediate nodes. As the traffic increases and
increases, so does the area they occupy. By testing different the links begin to saturate, BC provides no significant benefits
values for these distances dx = dy , we aim to understand compared to other routing strategies.
if the routing protocol can take advantage of the multi-SF Regarding the actual single-SF routing strategies, HC (the
capabilities of LoRa and improve performance. Later, we most straightforward metric) provides the best PDR perfor-
perform the same network simulations except that nodes mance in most of the experiments, closely followed by the
are randomly distributed, occupying an equivalent area to RSSI metric. The traffic-aware ETX metric performs worse
the previous grid topology, creating a more heterogeneous in low-traffic scenarios but is almost on par with HC as the
topology. Table 7 lists the topologies and dimensions used in traffic load increases. The multi-SF ToA does not offer any
these simulations. significant improvement in terms of PDR, and its perfor-
Due to the shape of the grid topology and the border effect, mance is in between the single-SF metrics. Furthermore, it
the density of nodes (i.e., the nodes/area ratio) is not constant, does not take advantage of the available links in diagonal,
as shown in Figure 10. However, as the network grows, using a higher SF that would allow using two different SFs
it tends asymptotically to a fixed value, only determined simultaneously. Therefore, in the context of a grid topology
by the number of nodes and the spacing between them. with equal spacing between all nodes, a simpler single-SF
From 36 nodes onward, we consider that the border effect algorithm seems to be the most reliable solution for end-to-
is negligible, so the resulting PDR will be affected mainly by end packet delivery. Despite not being shown in the graphs,
the number of nodes and the area they occupy rather than by goodput and latency performance figures are consistent with
their density. the PDR results.
Figure 11 shows the average PDR as a function of the num- The simulations with random network topologies offer
ber of nodes deployed with a grid topology when different a different picture, as visible in Figure 12. There, we can
routing strategies are used. Similarly, Figure 12 corresponds observe that the multi-SF ToA routing metric provides better
to the same experiments, with nodes randomly deployed over PDR performance than single-SF metrics in some situations.
the equivalent areas. Each row in the figure corresponds to a More specifically, where nodes are more separate apart, for
different spacing between nodes (medium spacing omitted, low traffic load (Figs. 12c the ToA result bars have less
minor difference), and each column corresponds to low- dispersion, and their averages are higher along most of the
to high-network traffic scenarios (medium traffic omitted, experiments. These results indicate that the multi-SF routing
minor difference). strategy has a direct impact on nodes that, because of their
The general trend shows the expected negative relation random placement, are more isolated (e.g., at the edges
between the PDR and the number of nodes –except for the of the network) and, therefore, have fewer communication
flooding-based strategies–. First, we can observe that in low opportunities than those at the center of the network area. In
traffic scenarios, BC-based forwarding provides the best PDR other words, the ToA metric better adapts to heterogeneous
14 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

1 0.25
BC (SF7)
HC (SF7)
ETX (SF7)
0.8 0.2 RSSI (SF7)
ToA (SF7-8)
Average PDR

Average PDR
0.6 0.15

0.4 0.1

BC (SF7)
0.2 HC (SF7) 0.05
ETX (SF7)
RSSI (SF7)
ToA (SF7-8)
0 0
9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes

(a) dx = 177 m, low traffic load. (b) dx = 177 m, high traffic load.
1 0.25
BC (SF7)
HC (SF7)
ETX (SF7)
0.8 0.2 RSSI (SF7)
ToA (SF7-8)
Average PDR

Average PDR
0.6 0.15

0.4 0.1

BC (SF7)
0.2 HC (SF7) 0.05
ETX (SF7)
RSSI (SF7)
ToA (SF7-8)
0 0
9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes

(c) dx = 248 m, low traffic load. (d) dx = 248 m, high traffic load.
FIGURE 11: Average network PDR for different numbers of nodes in a grid topology with a constant horizontal and vertical
node spacing of 177 up to 248 m, using different routing strategies. Notice the y-axis scale change.

network topologies and balances the PDR performance be- 500 m2 . As the number of nodes grows on each iteration,
tween nodes with different network centrality. These benefits while the area is kept constant, the density of nodes becomes
are also visible regarding the goodput KPI, which is analyzed higher proportionally. To evaluate our multi-SF routing pro-
later in Section VI-B. tocol based on the ToA metric, we test it under low, medium,
In conclusion, multi-SF routing strategies like our pro- and high traffic conditions and compare it with the BC, HC,
posed ToA metric may have a positive impact on PDR, ETX and RSSI routing strategies. The ToA metric is tested
which is a main indicator of the scalability, depending on with all the possible SF ranges (i.e., SF7-8, SF7-9, SF7-10,
the network topology. They can better cope with the network SF7-11, SF7-12, SF8-9, SF8-10, SF8-11, etc.).
links’ heterogeneity than other routing strategies, benefiting
Figures 13 and 14 show the average PDR in function of
overall performance. Still, they do not provide any advantage
the number of nodes used in the simulations when different
to networks with regular topologies like a grid one. Since
routing strategies are used. In the former, nodes are deployed
diversity in nodes and links is expected to occur in real-world
on a grid topology; in the latter, nodes are randomly deployed
systems, with nodes placed in diverse locations, subject to
with uniform distribution (details about it are in Sec. V-A).
different environmental conditions (attenuation, interference,
Each figure contains two sub-figures corresponding to low
number of neighbors, etc.), the multi-SF ToA metric may
and high network traffic conditions (medium omitted, minor
ease the deployment of LoRa mesh networks and improve
difference)). As expected, their general trend shows a neg-
their performance –at least, in terms of end-to-end PDR–.
ative relation between the average PDR and nodes’ number
–and density. For the case of the ToA metric, the SFs range
2) Density of nodes
providing the best performance results (e.g., SF7-9) is plotted
In this second part of the section, we conduct several ex-
(rather than all the combinations).
periments to analyze scalability as the number of nodes
grows and their density increases. We use the end-to-end For the low traffic scenarios (Figs. 13a, 14a), the BC
PDR, averaged among all the nodes in the network, as the strategy provides the best PDR results. Since packets are
performance metric. As more nodes are placed in the same broadcast and replicated on each hop, flooding the network,
area and radio transmissions become more frequent, the PDR the chance for any copies to arrive at the destination is very
is expected to degrade due to the higher collision probability. high, mostly compensating for any additional collisions. The
We aim to find whether the simultaneous usage of multiple actual routing strategies (HC, ETX, RSSI and ToA) offer
SFs reduces collisions, improving the average PDR. a quasi-linear relation between the number of nodes and
We simulate different network deployments, with N 2 = the PDR. Their results fluctuate depending on the number
{9, 16, 25, 36, 49 and 64} nodes on a fixed area of 500 × of nodes and the topology but are consistent, revealing no
VOLUME 4, 2016 15

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

1 0.25
BC (SF7)
HC (SF7)
ETX (SF7)
0.8 0.2 RSSI (SF7)
ToA (SF7-8)
Average PDR

Average PDR
0.6 0.15

0.4 0.1

BC (SF7)
0.2 HC (SF7) 0.05
ETX (SF7)
RSSI (SF7)
ToA (SF7-8)
0 0
9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes

(a) Area equivalent to dx = 177 m, (b) Area equivalent to dx = 177 m,

low traffic load. high traffic load.
1 0.25
BC (SF7)
HC (SF7)
ETX (SF7)
0.8 0.2 RSSI (SF7)
ToA (SF7-8)
Average PDR

Average PDR
0.6 0.15

0.4 0.1

BC (SF7)
0.2 HC (SF7) 0.05
ETX (SF7)
RSSI (SF7)
ToA (SF7-8)
0 0
9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes

(c) Area equivalent to dx = 248 m, (d) Area equivalent to dx = 248 m,

low traffic load. high traffic load.
FIGURE 12: Average network PDR for different numbers of nodes in a random topology with a constant horizontal and vertical
node spacing of 177 up to 248 m, using different routing strategies. Notice the y-axis scale change.

1 0.25
BC (SF7)
HC (SF7)
ETX (SF7)
0.8 0.2 RSSI (SF7)
ToA (SF7-8)
Average PDR

Average PDR

0.6 0.15

0.4 0.1

BC (SF7)
0.2 HC (SF7) 0.05
ETX (SF7)
RSSI (SF7)
ToA (SF7-8)
0 0
9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes

(a) Low traffic load. (b) High traffic load.

FIGURE 13: Average network PDR, for different number of nodes, in a grid topology on a fixed area of 500 × 500 m2 , using
different routing strategies. Notice the y-axis scale change.

1 0.25
BC (SF7)
HC (SF7)
ETX (SF7)
0.8 0.2 RSSI (SF7)
ToA (SF7-8)
Average PDR

Average PDR

0.6 0.15

0.4 0.1

BC (SF7)
0.2 HC (SF7) 0.05
ETX (SF7)
RSSI (SF7)
ToA (SF7-8)
0 0
9 16 25 36 49 9 16 25 36 49
Number of nodes Number of nodes

(a) Low traffic load. (b) High traffic load.

FIGURE 14: Average network PDR, for different number of nodes, in a random topology with uniform distribution on a fixed
area of 500 × 500 m2 , using different routing strategies. Notice the y-axis scale change.

16 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

evident performance difference between them. As the traffic end, we also define the network’s goodput as the total amount
increases (Figs. 13b, 14b, the network becomes each time of valid data transmitted end-to-end between pairs of nodes,
more congested, affecting the collision probability and hence measured over a given period of time. This magnitude pro-
PDR. The difference between BC and the routing strategies vides a more precise picture of how effective the network is
becomes smaller, as the congested network does not allow at transmitting valid data from one node to any other. To this
room for packets to flood the whole network and reach the end, in this section, we use the goodput figures to evaluate
destination. the different routing metrics.
According to the PDR results, there is no observable bene- Figure 15 shows the average goodput achieved by the
fit in using the multi-SF approach and the ToA instead of any network, averaged to all the participating nodes. Nodes are
other single-SF strategy. Our simulations indicate, however, deployed using a grid topology with a constant horizontal
that combining different SFs does help to increase PDR and vertical spacing of 177 and 248 m between them in low,
results in very congested networks, where nodes are con- medium, high, and saturation traffic scenarios. Each of the
stantly sending packets one after the other. In this scenario, four traffic scenarios reveals a different network behavior
–regardless of the topology–, single-SF routing can barely that helps to understand the throughput KPI in a LoRa mesh
provide a PDR of 0.001 (i.e., one packet out of a thousand network. In the low and medium traffic scenario, both single-
reaching its final destination) in a 16-nodes network, while SF and multi-SF metrics provide similar results, with HC
multi-SF ToA achieves, approximately, a PDR of 0.01 (i.e., and ToA offering comparable figures. The rest of single-SF
one packet out of a hundred). Even if the effect of multi-SF metrics offer slightly worse performance. It is worth noting
is measurable, it is irrelevant in practical terms, so the results that flooding-based BC and Single Board Computer (SBC),
were removed from Figures 11 and 12. which gave the best PDR performance in Section VI-A1,
did it at the expense of significantly bad goodput results.
B. THROUGHPUT As the traffic increases to a high volume, the multi-SF ToA
Besides the scalability and the PDR analyzed above, through- offers slightly better goodput results than single-SF metrics.
put is an important KPI to take into account to understand This metric can benefit from diagonal transmissions with the
the amount of data a LoRa-based mesh network can handle. immediately higher SF when comparing the topologies with
In Section V-D, we ran a simple benchmark that indicated a spacing of 177 and 178 m between nodes.
the maximum throughput two LoRa nodes could achieve in In the high-traffic scenarios, where links start to become
ideal conditions (i.e., continuous unidirectional transmission, saturated, the benefits of using single-SF or multi-SF are
no duty cycle restriction, no collisions). For a payload sized less obvious, as some of the experiments show a relatively
the same as the one in our simulations, the throughput ranged small advantage and others a disadvantage, suggesting that
between 2500 bps and 100 bps, depending on the SF used the additional complexity of multi-SF ToA may not match
(roughly, each SF step up halves the speed). However, our the elementary and regular grid topology. However, in the
LoRa mesh network experiments differ from the deploy- saturated traffic scenario (where all the nodes try to transmit
ments in the benchmark. First, packet collisions will occur packets as frequently as possible), the multi-SF ToA metric
in the absence of a scheduler to organize transmissions. provides nodes with a mechanism to deal with some of the
Their frequency will mostly depend on the number of nodes packet collisions. The traffic is spread on the overlaid net-
and topologies, and the packets’ egress rate. Second, the works with different SFs, partially desaturating the spectrum
nodes will use a fraction of the available airtime to broadcast and avoiding part of the collisions. As a result, each node can
routing messages instead of data packets. Third, multi-hop still correctly transmit a few bps, while the single-SF metrics
communication between arbitrary pairs of nodes requires the provide close to zero a goodput.
participation of different intermediate forwarders, spending It is worth mentioning that even the best average goodput
their available time to route other nodes’ traffic. Therefore, results (approx. 16 bps on SF8) are much lower than the
the expected throughput measurements will be well below ideal benchmark results from Section V-D. However, they are
the numbers obtained in the ideal conditions benchmark. consistent with the radio technology used and the challenges
For our experiments, we define the network’s throughput this demanding topology and traffic pattern poses.
as the total amount of valid data (i.e., payload) transmitted Figure 16 shows the average goodput results achieved by
by any node and correctly received (i.e., no collisions) by the network, averaged to all the participating nodes when
the destination node specified in the header, measured over a these are deployed randomly over an area the same size as the
given period of time. Throughput is a good KPI to understand previous experiments. Now, the multi-SF ToA routing metric
how much data can be handled by the network. Still, it can adapt to the heterogeneity of each node, which positively
may provide an incomplete picture of its performance since impacts the performance. In most experimented cases, the
packets being forwarded by different nodes may account for best goodput figures are achieved by the ToA metric, whether
more throughput than single-hop communication between we consider a low, medium, high, or saturated traffic load
adjacent nodes. Also, a multi-hop packet colliding halfway (medium and high omitted, minor differences). It is worth
to its destination would have generated throughput without comparing the ratio between this figure and the one for
reporting the benefit of end-to-end communication. To this the throughput (Fig. 15) to see how efficient the network
VOLUME 4, 2016 17

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

1.4 14 45 18
BC (SF7) BC (SF7) BC (SF7) BC (SF7)
HC (SF7) HC (SF7) 40 HC (SF7) 16 HC (SF7)
1.2 ETX (SF7) 12 ETX (SF7) ETX (SF7) ETX (SF7)
RSSI (SF7) RSSI (SF7) 35 RSSI (SF7) 14 RSSI (SF7)
Average goodput [bps]

Average goodput [bps]

Average goodput [bps]

Average goodput [bps]

ToA (SF7-8) ToA (SF7-8) ToA (SF7-8) ToA (SF7-8)
10
1 30 12
8 25 10
0.8
6 20 8

0.6 15 6
4
10 4
0.4 2
5 2

0.2 0 0 0
9 16 25 36 49 64 9 16 25 36 49 64 9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes Number of nodes Number of nodes

(a) dx,y = 177 m, (b) dx,y = 177 m, (c) dx,y = 177 m, (d) dx,y = 177 m,
low traffic. medium traffic. high traffic. saturated traffic.
1.2 11 40 40
BC (SF7) BC (SF7) BC (SF7) BC (SF7)
1.1 HC (SF7) 10 HC (SF7) HC (SF7) HC (SF7)
ETX (SF7) ETX (SF7) 35 ETX (SF7) 35 ETX (SF7)
1 RSSI (SF7) 9 RSSI (SF7) RSSI (SF7) RSSI (SF7)
30 30
Average goodput [bps]

Average goodput [bps]

Average goodput [bps]

Average goodput [bps]

0.9 ToA (SF7-8) 8 ToA (SF7-8) ToA (SF7-8) ToA (SF7-8)

0.8 7 25 25
0.7 6
20 20
0.6 5
0.5 4 15 15
0.4 3 10 10
0.3 2
5 5
0.2 1
0.1 0 0 0
9 16 25 36 49 64 9 16 25 36 49 64 9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes Number of nodes Number of nodes

(e) dx,y = 248 m, (f) dx,y = 248 m, (g) dx,y = 248 m, (h) dx,y = 248 m,
low traffic. medium traffic. high traffic. saturated traffic.
FIGURE 15: Average network goodput, in bps, for different number of nodes in a grid topology with a constant horizontal and
vertical node spacing of 177 and 248 m, using different routing strategies. Notice the y-axis scale changes.

is in providing end-to-end communication between pairs of C. LATENCY

nodes. In the low traffic scenario for a grid topology with The last KPI analyzed for our RP is packet latency. Compared
nine nodes, 177 m apart, using the ToA metric with two SFs to the LoRaWAN architecture, where packet transmissions
(8 to 9), nodes achieve an average throughput of 1, 85 bps are single-hop only and have a negligible latency, latency is a
(Subfig. 15a), but only deliver a goodput just below 1, 2 bps. crucial boundary that must be considered in multi-hop mesh
Under good PDR conditions (i.e., few packet losses), each networks.
end-to-end packet transmission requires an average of 1.5 Figure 17 shows the average latency experienced by pack-
hops, which is in tune with the network dimensions. In any ets crossing the network with a grid topology, with different
case, this ratio varies depending on the number of nodes, node spacing (177 and 248 m). In particular, only those
their spacing, the traffic load, and the routing strategy. A packets successfully delivered end-to-end are considered, not
ratio closer to 1 may indicate that nodes use fewer hops those that experienced a collision and got lost. Similarly,
to perform end-to-end communications (e.g., using longer- Figure 18 offers the results for the experiments with nodes
reaching SFs). At the same time, higher rates suggest that randomly distributed over an area the same size.
each successful end-to-end communication requires more The figures for both topologies show that single-SF and
packet transmissions, indicating either shorter-reaching SF multi-SF metrics perform very similarly, even if some partic-
or higher packet losses. Still, Subfigures 15d and 15h, cor- ular differences may be observed. First, flooding-based BC
responding to a saturated traffic scenario, reveal that nodes and SBC provide much higher latency (even three orders
using the multi-SF ToA take advantage of LoRa’s orthogo- of magnitude or mode), as they often force links saturation
nality between SFs, delivering goodput figures in the tens of and filling of the nodes’ buffers, which indicates they are
bps order. inferior multi-hop strategies. Second, single-SF-based met-
rics provide consistent results –even if some metrics have
The analysis of the network’s throughput and goodput slightly better performance in some traffic conditions and
performance, with different numbers of nodes, topologies, other metrics in other environments–. Third, multi-SF ToA
and traffic loads, shows that the data rates achieved by the provides the best latency performance in low and medium
nodes are much smaller than the ideal benchmark results, traffic loads, especially for the random topology, again taking
between two and three orders of magnitude below. Addition- advantage of the nodes and links heterogeneity.
ally, we can acknowledge that using multiple SFs simultane- It is worth mentioning that, because of the very slow packet
ously has a limited impact on the low to high traffic loads transmission rate of the low traffic scenarios (nodes send,
but dramatically improves throughput and goodput in traffic at most, one packet every 100 s), messages incur very high
saturation scenarios, suggesting that, to maximize network latency numbers, in the order of tens of thousands of seconds.
performance, multi-SF operation would be preferred. This is due to the number of hops needed to reach the
destination and the waiting time at the intermediate nodes’
buffers. As discussed in Section VII, our RP may require a
18 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

2.5 40
BC (SF7) BC (SF7)
HC (SF7) HC (SF7)
ETX (SF7) 35 ETX (SF7)
2 RSSI (SF7) RSSI (SF7)
30

Average goodput [bps]

Average goodput [bps]

ToA (SF7-8) ToA (SF7-8)

1.5 25

20
1 15

10
0.5
5

0 0
9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes

(a) Area equivalent to (b) Area equivalent to

dx = 177 m, dx = 177 m,
low traffic. saturated traffic.
1.8 60
BC (SF7) BC (SF7)
1.6 HC (SF7) HC (SF7)
ETX (SF7) 50 ETX (SF7)
1.4 RSSI (SF7) RSSI (SF7)
Average goodput [bps]

Average goodput [bps]

ToA (SF7-8) ToA (SF7-8)
1.2 40

1
30
0.8

0.6 20

0.4
10
0.2

0 0
9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes

(c) Area equivalent to (d) Area equivalent to

dx = 248 m, dx = 248 m,
low traffic. saturated traffic.
FIGURE 16: Average network goodput, in bps, for different amount of nodes in a random topology with an equivalent constant
horizontal and vertical node spacing of 177 and 248 m, using different routing strategies. Notice the y-axis scale changes.

modification to ensure that packets received by intermediate routing strategies using other metrics like HC or ETX. These
nodes are dispatched as soon as possible, with a different rate contributions should be helpful in real-world deployments,
independent of the data generation rate. where nodes are expected to operate in diverse and heteroge-
neous environmental conditions.
VII. CONCLUSION Our future work will aim to implement the protocol and
In this paper, we presented the design and evaluation of a DV the understanding gained from our simulation study into
RP for LoRa mesh networks, which includes a novel multi- real embedded devices, leveraging existing libraries such as
SF ToA metric that adapts to networks with heterogeneous [29] in combination with the radio chip’s CAD feature, and
topologies. evaluate our DV RP and the proposed multi-SF ToA metric
Our proposed RP is designed with a minimalistic set of first in controlled laboratory environments and later seek
features to reduce memory and computing footprint. Thus, realistic outdoors deployment.
it is suitable for embedded devices with a microcontroller
and a LoRa radio chip. It merges L2 and L3 addressing and REFERENCES
uses a proactive broadcast mechanism for nodes to exchange [1] C. Milarokostas, D. Tsolkas, N. Passas, and L. Merakos,
routes with their neighbors, keeping the routing tables up-to- “A comprehensive study on lpwans with a focus on the
date and propagating changes over the network. Its simplicity potential of lora/lorawan systems,” IEEE Communica-
comes at the expense of a lack of certain features, such as tions Surveys & Tutorials, vol. 25, no. 1, pp. 825–867,
multicast, route discovery, node-to-node or end-to-end trans- 2023.
mission reliability, and lower power footprint with reactive [2] LoRa Alliance Technical Commitee, “LoRaWAN®
routing updates. L2 1.0.4 Specification ,” 2020, Accessed:
A novel aspect of our RP is that it takes into account 2024-04-22. [Online]. Available: https:
LoRa’s capability to transmit and receive with different SFs. //[Link]/technical-specifications/
This approach allows working with nodes in a mesh network ts001-1-0-4-lorawan-l2-1-0-4-specification
using different SFs simultaneously, with packets potentially [3] Z. Sun, H. Yang, K. Liu, Z. Yin, Z. Li, and W. Xu,
being forwarded using multiple SFs along their path. The “Recent advances in lora: A comprehensive survey,”
ToA metric we present takes advantage of this feature and has ACM Trans. Sen. Netw., vol. 18, no. 4, nov 2022.
proven suitable for LoRa mesh networks with heterogeneous [Online]. Available: [Link]
links and topologies. For these situations where nodes have [4] R. Pueyo Centelles, F. Freitag, R. Meseguer, and
different characteristics in terms of placement, number of L. Navarro, “Beyond the star of stars: An introduction
neighbors and distance to them, etc., our proposal achieves to multihop and mesh for LoRa and LoRaWAN,” IEEE
better PDR, goodput, and latency results than single-SF Pervasive Computing, pp. 1–10, 2021.
VOLUME 4, 2016 19

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

1x106 1000
BC (SF7)
HC (SF7)
ETX (SF7)
100000 RSSI (SF7) 100

Average packet latency [s]

Average packet latency [s]

ToA (SF7-8)

10000 10

1000 1

BC (SF7)
100 0.1 HC (SF7)
ETX (SF7)
RSSI (SF7)
ToA (SF7-8)
10 0.01
9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes

(a) dx = 177 m, (b) dx = 177 m,

low traffic. saturated traffic.
6
1x10 1000
BC (SF7)
HC (SF7)
ETX (SF7)
RSSI (SF7) 100
Average packet latency [s]

Average packet latency [s]

100000 ToA (SF7-8)

10
10000
1

1000 BC (SF7)
0.1 HC (SF7)
ETX (SF7)
RSSI (SF7)
ToA (SF7-8)
100 0.01
9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes

(c) dx = 248 m, (d) dx = 248 m,

low traffic. saturated traffic.
FIGURE 17: Average network latency, in bps, for different numbers of nodes in a grid topology with a constant horizontal and
vertical node spacing of 177 and 248 m, using different routing strategies. Notice the y-axis scale change.

[5] A. W.-L. Wong, S. L. Goh, M. K. Hasan, and S. Fattah, RaWAN ® Relay Specification TS011-
“Multi-hop and mesh for lora networks: Recent 1.0.0 ,” 2022, Accessed: 2024-04-22. [On-
advancements, issues, and recommended applications,” line]. Available: [Link]
ACM Comput. Surv., vol. 56, no. 6, jan 2024. [Online]. technical-specifications/ts011-1-0-0-relay
Available: [Link] [14] P. Tian, C. Boano, X. Ma, and J. Wei, “Lorahop: Multi-
[6] R. Pueyo Centelles, “Towards LoRa mesh networks hop support for lorawan uplink and downlink messag-
for the IoT,” Ph.D. dissertation, Universitat Politèc- ing,” IEEE Internet of Things Journal, pp. 1–1, 2023.
nica de Catalunya, Computer Architecture Department, [15] R. Islam, B. Paul, and R. Palit, “Performance Evalua-
Barcelona, Spain, Nov 2021. tion of Multi-hop LoRaWAN,” IEEE Access, pp. 1–18,
[7] G. Slabicki, M; Premsankar, “FLoRa—a framework 2023.
for LoRa simulations,” 2018, Accessed: 2024-03-22. [16] D. Lundell, A. Hedberg, C. Nyberg, and E. Fitzger-
[Online]. Available: [Link] ald, “A routing protocol for LoRA mesh networks,”
[8] O. Ltd., “OMNeT++ discrete event simulator,” 2020, in 2018 IEEE 19th International Symposium on "A
Accessed: 2024-04-22. [Online]. Available: https: World of Wireless, Mobile and Multimedia Networks"
//[Link] (WoWMoM), 2018, pp. 14–19.
[9] P. Gkotsiopoulos, D. Zorbas, and C. Douligeris, “Per- [17] C. Ebi, F. Schaltegger, A. Rüst, and F. Blumensaat,
formance determinants in lora networks: A literature “Synchronous LoRa mesh network to monitor pro-
review,” IEEE Communications Surveys & Tutorials, cesses in underground infrastructure,” IEEE Access,
vol. 23, no. 3, pp. 1721–1758, 2021. vol. 7, pp. 57 663–57 677, 2019.
[10] J. R. Cotrim and J. Kleinschmidt, “LoRaWAN [18] C. T. Duong and M. K. Kim, “Multi-hop linear network
mesh networks: A review and classification of based on LoRa,” Advanced Science and Technology
multihop communication,” Sensors, vol. 20, no. 15, Letters, vol. 150, pp. 29–33, 2018.
2020. [Online]. Available: [Link] [19] A. Abrardo and A. Pozzebon, “A multi-hop LoRa linear
1424-8220/20/15/4273 sensor network for the monitoring of underground envi-
[11] A. Osorio, M. Calle, J. D. Soto, and J. E. Candelo- ronments: The case of the medieval aqueducts in Siena,
Becerra, “Routing in LoRaWAN: Overview and chal- Italy,” Sensors, vol. 19, no. 2, p. 402, 2019.
lenges,” IEEE Communications Magazine, vol. 58, [20] B. Sartori, S. Thielemans, M. Bezunartea, A. Braeken,
no. 6, pp. 72–76, 2020. and K. Steenhaut, “Enabling RPL multihop communi-
[12] C. Li and Z. Cao, “LoRa Networking Techniques for cations based on LoRa,” in WiMob, 2017, pp. 1–8.
Large-scale and Long-term IoT: A Down-to-top Sur- [21] H.-C. Lee and K.-H. Ke, “Monitoring of large-area IoT
vey,” ACM Computing Surveys, vol. 55, no. 3, pp. 1–36, sensors using a LoRa wireless mesh network system:
2023. Design and evaluation,” IEEE Transactions on Instru-
[13] LoRa Alliance Technical Commitee, “Lo- mentation and Measurement, vol. 67, no. 9, pp. 2177–

20 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

1x106 1x106 100 1000

BC (SF7) BC (SF7)
HC (SF7) HC (SF7)
100000 ETX (SF7) 100000 ETX (SF7)
RSSI (SF7) RSSI (SF7) 100
Average packet latency [s]

Average packet latency [s]

Average packet latency [s]

Average packet latency [s]

ToA (SF7-8) ToA (SF7-8) 10
10000
10000
10
1000
1000 1
100
1
100
10
0.1 BC (SF7) BC (SF7)
HC (SF7) 0.1 HC (SF7)
10 1 ETX (SF7) ETX (SF7)
RSSI (SF7) RSSI (SF7)
ToA (SF7-8) ToA (SF7-8)
1 0.1 0.01 0.01
9 16 25 36 49 64 9 16 25 36 49 64 9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes Number of nodes Number of nodes

(a) Area equivalent to (b) Area equivalent to (c) Area equivalent to (d) Area equivalent to
dx = 177 m, dx = 177 m, dx = 177 m, dx = 177 m,
low traffic. medium traffic. high traffic. saturated traffic.
6
1x10 100000 100 1000
BC (SF7) BC (SF7)
HC (SF7) HC (SF7)
ETX (SF7) ETX (SF7)
100000 RSSI (SF7) 10000 RSSI (SF7) 100
Average packet latency [s]

Average packet latency [s]

Average packet latency [s]

Average packet latency [s]

ToA (SF7-8) ToA (SF7-8) 10

10000 1000 10
1
1000 100 1

0.1 BC (SF7) BC (SF7)

100 10 HC (SF7) 0.1 HC (SF7)
ETX (SF7) ETX (SF7)
RSSI (SF7) RSSI (SF7)
ToA (SF7-8) ToA (SF7-8)
10 1 0.01 0.01
9 16 25 36 49 64 9 16 25 36 49 64 9 16 25 36 49 64 9 16 25 36 49 64
Number of nodes Number of nodes Number of nodes Number of nodes

(e) Area equivalent to (f) Area equivalent to (g) Area equivalent to (h) Area equivalent to
dx = 248 m, dx = 248 m, dx = 248 m, dx = 248 m,
low traffic. medium traffic. high traffic. saturated traffic.
FIGURE 18: Average network latency, in bps, for different amount of nodes in a random topology with an equivalent horizontal
and vertical node spacing of 177 and 248 m, using different routing strategies. Notice the y-axis scale change.

2187, Sep 2018. vol. 10, no. 22, pp. 19 964–19 971, 2023.
[22] G. Zhu, C.-H. Liao, T. Sakdejayont, I.-W. Lai, [28] B. Arratia, E. Rosas, C. T. Calafate, J.-C.
Y. Narusue, and H. Morikawa, “Improving the capacity Cano, J. M. Cecilia, and P. Manzoni, “Allora:
of a mesh LoRa network by spreading-factor-based Empowering environmental intelligence through
network clustering,” IEEE Access, vol. 7, pp. 21 584– an advanced lora-based iot solution,” Computer
21 596, 2019. Communications, vol. 218, pp. 44–58, 2024.
[23] D. L. Mai and M. K. Kim, “Multi-hop LoRa [Online]. Available: [Link]
network protocol with minimized latency,” Energies, science/article/pii/S0140366424000641
vol. 13, no. 6, 2020. [Online]. Available: https: [29] J. M. Solé, R. P. Centelles, F. Freitag, and R. Meseguer,
//[Link]/1996-1073/13/6/1368 “Implementation of a lora mesh library,” IEEE Access,
[24] L. Prade, J. Moraes, E. de Albuquerque, vol. 10, pp. 113 158–113 171, 2022.
D. Rosário, and C. B. Both, “Multi-radio [30] D. Croce, M. Gucciardo, S. Mangione, G. Santaromita,
and multi-hop lora communication architecture and I. Tinnirello, “Impact of lora imperfect orthogonal-
for large scale iot deployment,” Computers and ity: Analysis of link-level performance,” IEEE Commu-
Electrical Engineering, vol. 102, p. 108242, 2022. nications Letters, vol. 22, no. 4, pp. 796–799, 2018.
[Online]. Available: [Link] [31] M. Westenberg, Single Channel LoRaWAN Gateway,
science/article/pii/S0045790622004773 2020. [Online]. Available: [Link]
[25] R. Berto, P. Napoletano, and M. Savi, “A ESP-1ch-Gateway
lora-based mesh network for peer-to-peer long- [32] S. Kim, H. Lee, and S. Jeon, “An adaptive spreading
range communication,” Sensors, vol. 21, no. 13, factor selection scheme for a single channel LoRa mo-
2021. [Online]. Available: [Link] dem,” Sensors, vol. 20, no. 4, p. 1008, Feb 2020.
1424-8220/21/13/4314 [33] D. J. Koch, M. O. Shahid, and B. Krishnaswamy,
[26] L. Leonardi, L. Lo Bello, and G. Patti, “MRT- Spreading Factor Detection for Low-Cost Adaptive
LoRa: A multi-hop real-time communication protocol Data Rate in LoRaWAN Gateways. Association for
for industrial IoT applications over LoRa networks,” Computing Machinery, 2022, vol. 1.
Computer Communications, vol. 199, no. December [34] M. Slabicki, G. Premsankar, and M. Di Francesco,
2022, pp. 72–86, 2023. [Online]. Available: https: “Adaptive configuration of LoRa networks for dense
//[Link]/10.1016/[Link].2022.12.013 IoT deployments,” in NOMS 2018-2018 IEEE/IFIP
[27] A. Ghosh, S. Misra, V. Udutalapally, and D. Das, “Lo- Network Operations and Management Symposium.
raute: Routing messages in backhaul lora networks for IEEE, 2018, pp. 1–9.
underserved regions,” IEEE Internet of Things Journal, [35] J. Petajajarvi, K. Mikhaylov, A. Roivainen, T. Hanni-

VOLUME 4, 2016 21

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2024.3443605

Author et al.: Preparation of Papers for IEEE TRANSACTIONS and JOURNALS

nen, and M. Pettissalo, “On the coverage of LPWANs: ROGER PUEYO CENTELLES obtained his
range evaluation and channel attenuation model for PhD from the Universitat Politècnica de Catalunya
(UPC) in 2021. His research interests include com-
LoRa technology,” in 2015 14th International Confer- munity networks, mesh and ad-hoc networks, and
ence on ITS Telecommunications (ITST), Dec 2015, pp. IoT. He currently works as a senior researcher at
55–59. the i2CAT Foundation.
[36] S. Idris, T. Karunathilake, and A. Förster, “Survey
and comparative study of lora-enabled simulators for
internet of things and wireless sensor networks,”
Sensors, vol. 22, no. 15, 2022. [Online]. Available:
[Link]
[37] R. Pueyo Centelles, M. Slabicki, and G. Premsankar,
“FLoRaMesh—a framework for LoRa mesh ROC MESEGUER is an Associate Professor
at the Computer Architecture Department at the
simulations,” 2020, Accessed: 2020-12-01. [Online]. Universitat Politècnica de Catalunya (UPC). His
Available: [Link] research interests include resource allocation for
[38] A. Augustin, J. Yi, T. Clausen, and W. M. Townsley, large-scale systems, decentralized systems applied
“A study of LoRa: Long range & low power to ambient intelligence, and bottom-up networks.
networks for the Internet of Things,” Sensors, vol. 16,
no. 9, 2016. [Online]. Available: [Link]
com/1424-8220/16/9/1466
[39] J. Gromeš, RadioLib – Universal wireless
communication library for Arduino, 2020. [Online].
Available: [Link]
FELIX FREITAG is an Associate Professor at
the Computer Architecture Department at Uni-
versitat Politècnica de Catalunya (UPC). His re-
search interests include edge computing, embed-
ded federated learning, and LoRa mesh networks
for the IoT. Felix supervised several Ph.D. theses.
The full list of his publications is available at
[Link]

ROGER BAIG VIÑAS Assistant Professor at

the Computer Architecture Department, which
he joined in 2016. Industrial PhD in 2019 in
Computer Architecture. He co-founded a start-
up (Routek, 2018). He was an engineer at the
[Link] Foundation (2011-19), where he previ-
ously researched community networks. His cur-
rent research interests include decentralized orga-
nizations and blockchain technology.

LEANDRO NAVARRO is a Professor at the

Computer Architecture Department at UPC. He
coordinated the CONFINE FIRE IP project and
participated in several EU projects (SORMA,
CATNETS, GRID4ALL, Clommunity, CON-
FINE, NetCommons, LightKone). His research
interests include the design of scalable and coop-
erative Internet-scale and economics-inspired sys-
tems. Leandro coordinated the Erasmus Mundus
Joint Doctorate in Distributed Computing (EMJD-
DC) and supervised more than 10 PhD theses. His publications are available
at [Link]

22 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see [Link]