This article has been accepted for publication in a future issue of this journal, but has not been
fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/LNET.2020.3003161, IEEE
Networking Letters
Clustering-Based Layering Approach for Uplink
Multi-Hop Communication in LoRa Networks
Muhammad Omer Farooq
Department of Systems and Computer Engineering
Carleton University Canada
Email: omer.farooq@sce.carleton.ca
Abstract—LoRa is the most popular low-power wide-area net-
working (LPWAN) technology, and typically it uses LoRaWAN as
the MAC layer. Usually, LoRaWAN forms a single-hop network.
LoRa supports customization of transmission parameters, such
as, bandwidth, spreading factor, and coding rate. Hence, a single-
hop LoRaWAN network’s coverage can be increased at the
expense of higher energy consumption and lower data rate.
However, there are a few issues: (i) there is an upper bound
on a single-hop network’s coverage, (ii) high throughput and
large coverage can not be achieved simultaneously, and (iii)
most importantly high energy consumption is generally not an
option in IoT use cases. Here, a multi-hop uplink communication
scheme is presented that exploits LoRa’s ability to customize its
transmission parameters and combine it with a novel routing
protocol to eliminate the mentioned shortcomings. In simulation-
based studies the proposed protocol uses LoRa’s fastest data
rate setting, however its coverage is lower than the LoRa’s
PHY layer setting recommended in LoRaWAN specification.
Hence, a network’s coverage is extended through multi-hop
communication. Results have shown that the proposed uplink
multi-hop communication scheme outperforms LoRaWAN and a
state-of-the-art routing protocol for low-power wireless networks.
The proposed protocol demonstrated nearly 20 times higher
packet delivery ratio, and 60% lower energy consumption.
Index Terms—LoRa, LoRaWAN, Multi-hop Communication,
Routing
I. I NTRODUCTION
Low-power wide-area networking (LPWAN) is an emerg-
ing communication paradigm for Internet of Things (IoTs).
Among existing LPWAN technologies long range (LoRa) is
the most popular [1]. LoRa PHY layer supports a broad
operating range as it defines a number of PHY layer settings
that impact reliability, coverage, and energy consumption.
LoRaWAN is the standard MAC layer for LoRa, and it forms
a single-hop star topology-based network. Generally, IoT use
cases, such as, street lighting, smart metering, etc span a
large geographical area. As LoRaWAN forms a single-hop
network, therefore large area coverage is achieved by using
lower bandwidth (BW) and higher spreading factor (SF).
However, such an approach to achieve large coverage suffers
from the following: (i) lower BW results in higher packet
air-time, hence higher energy consumption, (ii) mostly, the
number of wireless sensor nodes in a large geographical area
is high, therefore using lower bandwidth may not result in
an acceptable level of performance, and (iii) LoRaWAN uses
pure Aloha as the MAC protocol, hence higher air-time result
is higher packets collision probability.
2576-3156 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on June 22,2020 at 19:03:47 UTC from IEEE Xplore. Restrictions apply.
Here, a solution for the stated issues is presented by using
LoRa’s fastest data rate transmission parameters. To make up
for the reduced coverage resulting from the use of higher BW,
multi-hop communication can be used. Hence, a multi-hop
uplink communication protocol is also presented that has the
following characteristics: (i) lower control overhead, and (ii)
lower energy consumption.
The rest of this letter is organized as follows: Section
II presents related work. Proposed clustering-based layering
approach for uplink multi-hop communication in LoRa-based
networks is presented in Section III. Performance evaluation
is presented in Section IV, and finally conclusions and future
work are presented in Section V.
II. R ELATED W ORK
A. LoRa/LoRaWAN
LoRa’s radio modulation is based on chrip spread spectrum.
The unique characteristic of LoRa is that it offers customiza-
tion of SF, BW, transmission power (TP), and coding rate
(CR). Choice of 7 different SFs is available in LoRa. A
LoRa node can use BW in the range [7.8, 500] KHz, however
mostly LoRa transceivers operate at 125 KHz, 250 KHz,
or 500 KHz. A LoRa transceiver can transmit in the range
[−4, 20] dBm in 1 dB steps. Hardware limitations limits the
TP in the [2, 20] dBm range. Four different CRs can be used
4 4 4 4
in LoRa: 5, 6 , 7 , 8 . In LoRa, the useful bit rate (Rb ) is given
by Rb = SF × BW 2SF
× CR. LoRaWAN is the open MAC layer
specification for LoRa. Three important entities in LoRaWAN
network are: end device (ED), gateway (GW), and a server.
ED can only communicate with GW, and GW facilitates com-
munication between EDs and the network server. The server
is responsible for the following: processing ED data packets,
duplicate packet detection, storing data, and generating data
and commands for EDs. LoRaWAN uses simple Aloha as the
MAC protocol, and devices must obey 1% duty cycling rule.
LoRaWAN network operates in a star topology.
B. Multi-Hop Communication in LoRa
In [2], a network clustering approach is presented to enhance
coverage of LoRa networks using multi-hop communication.
A fully-connected network is partitioned into multiple sub-
nets. To enable concurrent transmissions, nodes in different
sub-nets use different SFs. To ensure a node’s reachability to
the gateway, each sub-net is rooted at the gateway. To avoid
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/LNET.2020.3003161, IEEE
Networking Letters
Legend:
: Layer 2 Gateway
: Layer 1 Gateway
: Layer 0 Gateway
: Root Gateway
Fig. 1. LoRa-Based Multi-Hop Network
any sub-net becoming a throughput bottleneck, an algorithm
is also presented that attempts to balance data traffic load in
each sub-net. In [3], a feasibility of multi-hop LoRa network
is presented using concurrent transmission (CT) multi-hop
protocol. In order to use the CT protocol with LoRa, first the
LoRa PHY layer receiver performance is analyzed using the
CT protocol. Afterwards, an enhanced CT protocol for LoRa
is presented that randomly adds timing delay before packet
transmission, and it ensures that timing delay does not diverge
over the multi-hop network. In [4], multi-hop communication
is enabled in LoRa-based networks using the routing protocol
for low-power and lossy networks (RPL) [5]. Another routing
protocol for LoRa-based networks is presented in [6]. The
routing protocol constructs data forwarding paths using short-
est hop-count and received signal strength indicator metrics.
In existing protocols, majority of nodes participate in route
construction process. As nodes in such networks have limited
resources, therefore such protocols do not fit well with the
limitation of LoRa nodes. Second, use cases for LPWAN
contain 100s or 1000s of nodes, therefore a routing protocol
that requires participation of most of the nodes in the route
construction process can negatively impact performance as
control overhead increases with an increase in the number of
nodes. Therefore, here I present a routing protocol that only
requires a few nodes to participate in the route construction
process, and the control overhead only increases with an
increase in the number of gateways. Moreover, the presented
communication scheme enables large coverage and relatively
high throughput in LoRa-based networks.
III. C LUSTERING -BASED L AYERED M ULTI -H OP U PLINK
C OMMUNICATION
In this section, I present a protocol that enables clustering-
based layered multi-hop uplink communication in LoRa-based
networks. The topology of such a network is shown in Fig.
1. The protocol uses LoRaWAN MAC layer frame structure,
however in its present form it is only compatible with Lo-
RaWAN under: (i) uplink communication, and (ii) activation
by personalizing security method.
A. Layers Formation and Gateways Discovery
In the proposed approach, the first step is to partition a
network into different layers and discover operational gate-
2576-3156 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on June 22,2020 at 19:03:47 UTC from IEEE Xplore. Restrictions apply.
ways at different layers of the network. The radius of each
layer is equal to the transmission range of a LoRa PHY layer
setting in use. LoRaWAN does not support network layering
and gateways discovery, therefore a new set of messages need
to be defined to incorporate the required functionalities. In Lo-
RaWAN MAC layer frame header, there is a M essage T ype
field that is used to identify the type and structure of message
inside LoRaWAN MAC frame payload. LoRaWAN has stan-
dardized 8 message types, and there is another special message
type called ”proprietary”. I use this proprietary message type
to encode a set of messages required for network layering,
clusters formation inside a layer, gateways discovery, and
multi-hop message relaying.
To partition a network into layers and to discover gateways
at different layers, I define the following messages: (i) gateway
discovery (GDIS ), and (ii) gateway response (GRES ). The
size of GDIS message is 7 bytes: Message ID (MID ) 1 byte,
layer ID (LID ) 1 byte, hop count (HCN T ) 1 byte, and trans-
mitting node ID (TN ID ) 4 bytes. Similarly, the size of GRES
message is 6 bytes: MID 1 byte, LID 1 byte, and TN ID 4
bytes. In case of GRES message, LID and TN ID fields contain
LID and TN ID of gateway transmitting the GRES message.
The MID field contains value 0x00 and 0x01 in GDIS and
GRES messages respectively. In the proposed protocol only
gateways are involved in route construction, and there are
usually a few gateways in a network. Therefore, all control
message transmissions take place using LoRa technology.
The root gateway initiates gateways discovery procedure.
To discovery gateways in layer 0, the root gateway broadcasts
GDIS message. As the root gateway intends to discovery
gateways in layer 0, hence it set GDIS .LID (ID of the layer in
which the root wants to discover gateways) field to 0, similarly
it sets GDIS .HCN T field to 0 so that gateways in layer 0 do
not rebroadcast the GDIS message. When a gateway in layer 0
receives GDIS , it stores the root gateway’s address and reply
with the GRES message. The information in GRES helps the
root gateway to store information about a gateway in layer 0.
In general, the root gateway helps gateways in layer n − 1 to
discovery gateways in layer n. The root gateway broadcasts the
GDIS message with GDIS .LID and GDIS .HCN T fields set
to n. Gateways in layer 0 receive the message decrement the
value in the GDIS .HCN T field by 1, replace the GDIS .TN ID
field with its own address, and rebroadcast the message. The
process continues till the message reaches to gateways in layer
n. When a gateway in layer n receives GDIS , it transmits
GRES to the gateway from whom it received GDIS . The
detailed processing of GDIS message at any gateway is shown
in Algorithm 1.
When a gateway in layer n − 1 receives the GRES message
from a gateway in layer n, if checks whether the gateway
from whom it has received the GRES message is in the list
of gateways whose data packets the gateway should forward
to a gateway in layer n − 2. The gateway’s network address is
added to the list, if it is not already in the list. As a gateway
in layer n − 1 needs to relay packets of a gateway in layer n,
therefore a network planning is required that ensures that there
is at-least one relaying gateway in layer n − 1 for a gateway
in layer n. The mentioned requirement can also be satisfied
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/LNET.2020.3003161, IEEE
Networking Letters

Algorithm 1: GDIS Processing at a Gateway be relayed by gateways present at different layers. To enable
1 Input: GDIS ; this multi-hop packet forwarding I define another message
2 if GDIS . LID ≤ gtw. layer id & & GDIS .HCN T == 0 called the data packet (DataP KT ) message. The DataP KT
then message header contains the following information: MID 1
3 if GDIS .LID < gtw.layer id then byte, and GtwADDR 4 bytes. The MID field of DataP KT
4 gtw.layer id = GDIS .LID ; message contains 0x03 value. The body of DataP KT con-
gtw.list.remove all entries(); tains application message. The maximum payload that can
gtw.list.add upstrm gtw(GDIS .TN ID ) ; be carried in LoRaWAN frame varies from 51 bytes to 222
5 end bytes depending upon the LoRa PHY layer setting in use. As
6 else DataP KT message header size is 5 bytes, therefore the max-
7 if gtw.list.search(GDIS .TN ID ) == null then imum application data that can be carried inside DataP KT
8 gtw.list.add upstrm gtw(GDIS .TN ID ) ; varies from 45 bytes to 217 bytes.
9 end Whenever a node has a data packet to transmit it sets MID
10 end field of DataP KT header to 0x03, and the GtwADDR field
11 GRES = create GRES (gtw.layer id, gtw addr); to the address of the cluster head gateway. When the cluster
unicast(GRES , GDIS .TN ID ) ; head receives the packet it searches the list of nodes that
12 end belong to its cluster. If the source node is present in the list, it
13 else forwards the packet to one of its upstream gateways. When the
14 if GDIS .HCN T > 0 then upstream gateway receives the packet, it searches its internal
15 GDIS .HCN T = GDIS .HCN T − 1; data structure to check whether the gateway can forward the
GDIS .TN ID = gtw addr; packet to its upstream gateway. If the gateway can forward
16 broadcast(GDIS ); the packet, it replaces the GtwADDR field in the DataP KT
17 end header with its own address and transmit the packet to one of
18 end its upstream gateways. The process continues till the packet is
delivered to the root gateway.

by randomly deploying a relatively high number of gateways, IV. P ERFORMANCE E VALUATION

however an additional cost is associated with this approach.
B. Cluster Formation
The purpose of cluster formation is to associate a node with
exactly one gateway. Once a node is associated with a gateway
the node communicates through the gateway. It is possible
that a node is within the transmission range of more than one
gateways, in such a scenario the node has to choose one gate-
way. Therefore, to facilitate proper cluster formation I define
another control message called the HELLO message. Each
gateway in a network periodically broadcasts the HELLO
message. The size of HELLO message is 9 bytes: MID 1
byte, LID 1 byte, Network ID (N etID ) 3 bytes (LoRaWAN
uses 3 bytes for N etID ), and Gateway ID (GtwADDR ) 4
bytes. MID for the HELLO message is 0x02. One of the
metrics that can be used by a node to select a gateway is
the received signal strength indicator (RSSI). It is possible
that a node is in layer n, but due to its location it can also
hear the HELLO message broadcasted by a gateway in layer
n + 1. To avoid such a situation in which a node in layer
n attempts to join a gateway in layer n + 1, the proposed
algorithm uses LID as well, this is why the HELLO message
contains LID field. Using the proposed algorithm’s HELLO
message a node joins a gateway with lowest LID , and if there
are multiple gateways with the same lowest LID the node
selects the gateway with the best RSSI value.
C. Packet Forwarding Logic
Whenever a source node has a data packet to transmit and
the node is not in cluster 0, the node’s packet possibly needs to
Experiments were carried out using discrete event LoRaSim
simulator [7]. The simulator uses log-distance path loss model
which is widely used to model wireless channel in densely
populated build-up areas. In LoRa, a node’s energy consump-
tion depends on TP, SF, BW, and CR. Therefore, LoRaSim
uses energy model that takes into account the mentioned
factors. Further information about the energy model can be
found in [7]. The number of nodes in network was varied
from 300 to 1200 in steps of 300 nodes. The network was
partitioned into 3 layers. In layer 0, there was a root gateway,
and layer 1 and layer 2 contained 2 gateways each. Hence,
the total number of gateways in the network is 5. A gateway
is costly compared to a LoRa end device, therefore a small
number of gateways was used. To gain a good understanding
of the protocol’s scalability, the number of gateways is not
increased with an increase in the number of nodes. The
nodes were distributed in such a manner that each gateway
handles the same number of nodes. The root gateway only
communicates with the gateways in layer 1, hence no node
is directly connected to the root. Each gateway in layer 2
is connected to single gateway in layer 1. In simulations
data packet payload size of 50-byte is used. Each simulation
duration was 24 hours, and each simulation scenario was
repeated 21 times.
The proposed protocol’s performance is compared with
LoRaWAN and RPL [5]. LoRaWAN uses SF12, 125 KHz BW,
and CR = 4/5. RPL uses trickle timer to multicast control
messages, therefore in the simulations RPL control message
transmission is modeled using the Poisson distribution with
mean arrival rate of 15 minutes. In the proposed clustering-

2576-3156 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on June 22,2020 at 19:03:47 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/LNET.2020.3003161, IEEE
Networking Letters

Log(Control Messages) Log(Energy Consumped) J

100 4 multi-hop communication, hence no control message transmit-
Mean PDR (%) ted. The proposed protocol demonstrated significantly lower
50 2 control messages transmission compared to RPL because only
gateways transmitted control messages. With an increase in
the number of nodes, RPL control overhead increased be-
0 0
300 600 900 1200 300 600 900 1200 cause each node in the network transmitted control messages.
(a) No. of Nodes (b) No. of Nodes However, the proposed protocol’s control overhead is not
Log(Overhead Energy) J

3 6
impacted as the number of gateways is constant in our setup.
2 4 In the proposed protocol, only gateways participate in route
construction, hence the control overhead will only increase
1 2
in scenarios where an increase in the number of gateways
0 0 is required. I performed another set of simulations where
300 600 900 1200 300 600 900 1200 the LoRaWAN uses 5 gateways. In this case, the proposed
(c) No. of Nodes (d) No. of Nodes
Clustering-Based Layering Approach RPL LoRaWAN protocol only demonstrates up to 3% higher PDR compared to
LoRaWAN. However, the proposed protocol still demonstrates
Fig. 2. Protocols’ Performance Comparison up to 60% lower energy consumption compared to LoRaWAN.
Overall, the results demonstrate that carefully selected
based layering approach (hereafter referred as proposed proto- LoRa’s PHY layer transmission parameters along with multi-
col) root initiates the control messages transmission after every hop communication support can substantially reduce energy
5 minutes. Each node in a network generates data packets consumption, improve PDR, and can yield large coverage in
using a Poisson arrival process with mean arrival rate (λ) of LoRa-based networks. This highlights that such a combination
1 hour. In simulations, the proposed protocol and RPL use the can enhance network lifetime and satisfy applications’ perfor-
LoRa’s fastest data rate setting (SF 6, 500 KHz, CR = 4/5). mance requirements.
The coverage of this setting is 3 times lower than the LoRa’s
PHY layer setting recommended by LoRaWAN. Hence, to V. C ONCLUSIONS AND F UTURE W ORK
match the coverage of LoRaWAN’s recommended setting
A novel multi-hop uplink communication approach is pre-
using LoRa’ fastest data rate setting I introduce three layers
sented that exploits LoRa’s PHY layer parameters customiza-
and forwarding gateways in each layer.
tion characteristic to not only extend LoRa network’s coverage,
Fig. 2(a) shows the mean packet delivery ratio (PDR)
but to achieve relatively high throughput and large coverage
demonstrated by different protocols. The proposed protocol
simultaneous. This feature was missing in existing state-of-
outperformed LoRaWAN and RPL. The proposed protocol
the-art. Simulation results demonstrated that the proposed
demonstrated up to 3 times and 10% higher PDR compared
multi-hop communication approach substantially outperforms
to LoRaWAN and RPL respectively. RPL demonstrates lower
LoRaWAN and RPL in terms of throughput, reliability, and
PDR compared to the proposed protocol primarily because
energy consumption. The protocol only supports uplink multi-
RPL’s control overhead is higher, and this is evident from
hop communication, therefore in future a support for multi-hop
Fig. 2(d). The recommended LoRaWAN setting uses lower
downstream communication will be incorporated.
BW to cover large area, thus the packet air-time is higher. The
higher air-time results in higher number of packet collisions,
hence lower PDR. The results also demonstrate that the R EFERENCES
proposed protocol exhibits scalability feature as the PDR is [1] N. Sornin, M. Luis, T. Eirich, T. Kramp, and O. Hersent, “LoRaWAN
Specifications, LoRa Alliance, San Ramon, CA, USA,” 2015.
slightly impacted with an increase in the number of nodes. [2] G. Zhu, C. Liao, T. Sakdejayont, I. Lai, Y. Narusue, and H. Morikawa,
The total network-wide energy consumption (including control “Improving the Capacity of a Mesh LoRa Network by Spreading-Factor-
overhead energy consumption) is shown in Fig. 2(b). The Based Network Clustering,” IEEE Access, vol. 7, pp. 21 584–21 596,
2019.
proposed protocol demonstrated up to 60% and 20% lower [3] C. Liao, G. Zhu, D. Kuwabara, M. Suzuki, and H. Morikawa, “Multi-
energy consumption compared to LoRaWAN and RPL respec- Hop LoRa Networks Enabled by Concurrent Transmission,” IEEE Access,
tively. LoRaWAN demonstrated highest energy consumption vol. 5, pp. 21 430–21 446, 2017.
[4] B. Sartori, S. Thielemans, M. Bezunartea, A. Braeken, and K. Steenhaut,
due to the higher air-time associated with its PHY layer “Enabling RPL Multihop Communications based on LoRa,” in IEEE 13th
transmission parameters. RPL demonstrated higher energy International Conference on Wireless and Mobile Computing, Networking
consumption compared to the proposed protocol because of and Communications (WiMob), 2017, pp. 1–8.
[5] A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur, and
its higher control overhead. Fig. 2(c) shows the comparison R. Alexander, “RPL: IPv6 Rotuing Protocol for Low-Power and Lossy
of control overhead energy consumption. LoRaWAN does Networks,” March 2012, RFC 6550.
not support multi-hop communication, hence its multi-hop [6] H. Lee and K. Ke, “Monitoring of Large-Area IoT Sensors Using a
LoRa Wireless Mesh Network System: Design and Evaluation,” IEEE
control overhead energy consumption is 0. The proposed Transactions on Instrumentation and Measurement, vol. 67, no. 9, pp.
protocol demonstrated significantly lower control overhead 2177–2187, 2018.
energy consumption compared to RPL because only gateways [7] M. C. Bor, U. Roedig, T. Voigt, and J. M. Alonso, “Do LoRa Low-Power
Wide-Area Networks Scale?” in Proceedings of the 19th ACM Interna-
transmit control messages, whereas in RPL each node trans- tional Conference on Modeling, Analysis and Simulation of Wireless and
mits control messages. Fig. 2(d) shows the total number of Mobile Systems, ser. MSWiM ’16, 2016, pp. 59–67.
control messages transmitted. LoRaWAN does not support

2576-3156 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on June 22,2020 at 19:03:47 UTC from IEEE Xplore. Restrictions apply.