See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/349411607

Multi-Hop Communication Protocol for LoRa With Software-Defined

Networking Extension

Article  in  Internet of Things · February 2021

DOI: 10.1016/j.iot.2021.100379

CITATION READS
1 483

1 author:

Muhammad Omer Farooq

Qualcomm
57 PUBLICATIONS   785 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Deep Reinforcement Learning in LoRa Networks for Effective Resource Allocation View project

All content following this page was uploaded by Muhammad Omer Farooq on 18 February 2021.

The user has requested enhancement of the downloaded file.

 1

Multi-Hop Communication Protocol for LoRa With

Software-Defined Networking Extension
Muhammad Omer Farooq
Department of Systems and Computer Engineering
Carleton University Canada
Email: [email protected]

Abstract—Long Range (LoRa) is a leading low-power wide- Emerging Internet of Things (IoTs) use cases, such as, smart
area networking technology, and LoRaWAN is the open MAC cities span large geographical area. Moreover, hundreds and
layer specification for LoRa technology. LoRaWAN operates thousands of sensor nodes are deployed to support such use
in a star network topology, thus LoRaWAN forms single-hop
network. LoRa technology allows customization of its PHY layer cases. The requirement for a long coverage and reliability can
transmission parameters, such as bandwidth, spreading factor, either be satisfied by using established long-range technolo-
transmission power, and coding rate, therefore long coverage gies, such as, LTE, WiMAX, etc or by using a combination of
can be achieved by using a lower bandwidth. However, a single- LoRa PHY layer transmission parameters that can yield a long
hop LoRaWAN network cannot achieve high data rate and long coverage and provide a good level of reliability. Typically, an
coverage simultaneous. To simultaneously achieve high data rate
and long coverage, the LoRa PHY layer setting that yields the IoT use case comprises of severely resource constraint devices.
fastest data rate can be used, however it reduces coverage. To Hence, the established long-range technologies cannot be used
makeup for the reduced coverage multi-hop communication can as they are not designed for resource constraint devices. In
be used. To enable multi-hop communication here a routing light of the above, we are left with an option to use a LoRa
protocol for LoRa-based networks is presented. Moreover, to PHY layer transmission parameter combination that can yield
enable traffic engineering in LoRa-based networks, such as traffic
load balancing a software-defined networking (SDN) extension long coverage and a good level of reliability. However, the
for the protocol is also presented. Performance evaluation has stated benefits are achieved at the expense of lower data rate
shown that the proposed protocol and its SDN-based extension and high energy consumption. In reality, the negative impact
can match coverage of LoRa PHY layer setting that offers of the lower data rate and high energy consumption over
maximum coverage at a relatively very high data rate and weighs the benefits of long coverage due to the following:
lower energy consumption. The protocol demonstrates up to
5 times higher packet reception ratio, and 63% lower energy (i) lower energy consumption is the most desired feature for
consumption compared to the LoRa PHY layer setting that offers resource constraint wireless sensor node, (ii) the number of
maximum coverage and reliability. Moreover, the protocols also wireless sensor nodes in a large geographical area is high,
outperform an existing state-of-the-are routing protocol for low- hence lower channel bandwidth may not result in an acceptable
power wireless networks. level of performance due to the large number of nodes, and
Index Terms—LoRa, LoRaWAN, Routing Protocol, Multi-hop (iii) LoRaWAN uses pure Aloha as the MAC protocol, and
Communication, Software Defined Networking. lower bandwidth-based LoRa transmission parameters result in
higher packet air-time, hence the probability of high number
I. I NTRODUCTION of packets collision is also high.
Recently, Long Range (LoRa) has emerged as a leading Here, a solution to the mentioned problem is presented by
low-power wide-area networking technology. LoRaWAN [1] is using the LoRa PHY layer transmission parameters that yield
the de facto MAC layer for the LoRa technology. LoRaWAN highest data rate. However, it reduces coverage, to makeup for
network uses a centralized entity, called gateway. Hence, it is the short coverage a proposal for multi-hop communication
based on single-hop star topology. Moreover, LoRaWAN uses is presented. To enable multi-hop communication in LoRa-
pure Aloha protocol as a channel access mechanism. LoRa based networks, a routing protocol that posses the following
supports customization of PHY layer transmission parameters, features is presented: (i) lower control overhead, (ii) lower
such as, bandwidth (BW), spreading factor (SF), coding rate energy consumption, and (iii) supports upstream, downstream,
(CR), and transmission power (TP). Different combinations and peer-to-peer communication. Typically, IoT use cases
of the stated parameters impact coverage, resilience against comprise of a large number of wireless sensor nodes that spans
interference, and energy consumption. For example, lower relatively large area, therefore multi-hop communication may
BW, higher SF, and higher CR combination can result in large end up in fast battery depletion of a number of relaying nodes.
coverage, higher resilience against interference, higher energy To cope with the stated issues, a software-defined networking
consumption due to high air-time, and lower data rate [1]. (SDN) extension for the proposed routing protocol is also
Similarly, higher BW and lower SF can result in high data presented. The SDN-based extension can be used for traffic
rate, and lower coverage. Hence, there is a trade-off between load balancing, and it may also be used for network slicing.
data rate and coverage. Simulation-based results have not only demonstrated the feasi-
bility of using the proposed multi-hop communication protocol
 2

in LoRa-based network, however they have also demonstrated hopping based communication scheme for LoRa is proposed
that the proposed protocol matches coverage of LoRa’s PHY in [3]. LoRaWAN defines three types of end devices: class A,
layer setting that yields largest coverage at a relatively very class B, and class C. Bi-directional communication is possible
high data rate and significantly lower energy consumption. using class A devices, however downlink communication can
Moreover, the proposed protocol has also outperformed an only take place after an uplink communication. Class B
existing state-of-the-art routing protocol for wireless sensor devices are similar to class A devices, but they support an extra
networks. downlink transmission window. Class C devices are similar to
The rest of this paper is organised as follows: Section II class B devices, however there is no restriction on downlink
presents background work. Requirements and objectives for communication. Hence, class C devices support continuous
multi-hop communication in LoRa networks is presented in downlink transmission window.
Section III. The multi-hop communication protocol and its Recently, research work has focused to improving the
SDN-based extension is presented in Section IV. Experimental LoRaWAN MAC layer. In [4], it is stated that a “class A”
results are presented in Section V, and finally conclusions are LoRa node receives the PHY layer parameters, i.e., SF and
presented in Section VIs. BW after a successful transmission. The node should use the
received parameters in a subsequent data packet transmis-
II. BACKGROUND sion. It is likely that next transmission happens after a few
A. LoRa/LoRaWAN hours, hence the wireless channel condition may also change
during that time. Therefore, an enhancement is proposed for
The LoRa communication technology uses chrip spread the LoRaWAN MAC layer, i.e., instead of transmitting the
spectrum radio modulation technique. An ability to customize PHY layer parameters after the transmission, the LoRaWAN
PHY layer transmission parameters is an important feature of gateway transmits the parameters just before the transmission.
the LoRa technology as it can impact scalability and reliability Experimental results have validated the effectiveness of the
of LoRa-based networks [2]. Using LoRa the following PHY proposed enhancement.
layer transmission parameters can be customized: SF, BW, TP,
and CR.
Spreading Factor: The ratio between the symbol B. Multi-Hop Communication in LoRa-Based Networks
rate and the chip rate is defined by SF. Seven Routing protocol for low-power and lossy networks (RPL)
different SFs are supported by LoRa, namely: is the routing protocol standardized by the Internet Engi-
[SF 6, SF 7, SF 8, SF 9, SF 10, SF 11, SF 12]. Sensitivity neering Task Force for low-power and lossy networks [5].
and range is impacted by SF. The chips per symbol are RPL is capable of discovering upstream data forwarding
calculated as 2SF . An increased SF reduces data rate, path, downstream data forwarding paths, and peer-to-peer data
increases energy consumption, resilience against interference, forwarding paths. RPL uses three different control messages to
and range. For example, a unit increase in SF results in 50% construct and maintain data forwarding paths. Each node in a
reduction in data rate. network multicasts control message using RPL’s trickle timer
Bandwidth: BW is an important parameter for any com- algorithm. Multi-hop communication is achieved in LoRa-
munication technology. A LoRa transceiver can operate in based networks using RPL in [6]. As part of the stated work a
[7.8, 500] KHz range. Generally, LoRa nodes function at new MAC layer protocol is also proposed that enables the use
125 KHz, 250 KHz, and 500 KHz band. LoRa’s chip rate of RPL in LoRa-based networks. The authors use an objective
is dependent on the BW being used. function to minimize a packet’s air-time with an objective to
Transmission Power: A LoRa node uses TP in the range minimize total network-wide energy consumption. Similarly,
[−4, 20] dBm. But, hardware limitation restricts the operation in an attempt to use existing well-established networking pro-
in range [2, 20] dBm. Furthermore, a node has to adhere to tocols, such as, IPv6, Constraint Application Protocol (CoAP),
1% duty cycling rule for TP levels higher than 17 dBm. etc with the LoRa technology work presented in [7] extends
Coding Rate: CR is the one of the important factors that Contiki (amongst one of the popular operating system for
defines resilience against interference. LoRa uses the following sensor networks) to support LoRa nodes.
four coding rates: 4/5, 4/6, 4/7, 4/8. Transmissions based on Multi-hop communication protocol for LoRa-based net-
higher CR are more resilient against interference, and vice works with SF-based clustering is presented in [8]. To enable
versa. In LoRa, the useful bit rate (Rb ) is given by Rb = concurrent transmissions (CT), a network is partitioned into
SF × BW 2SF
× CR. multiple sub-nets, and different sub-nets use different SFs.
LoRaWAN [1] is the standard MAC layer specification for Each sub-net is a multi-hop LoRa network rooted at the
LoRa. A LoRaWAN network consist of three entities: LoRa gateway. As different sub-nets use different SFs, therefore data
nodes, gateway, and a network server. LoRaWAN network rate and energy consumption in the network is not uniform.
operates in a star topology, hence LoRa nodes directly commu- Effectiveness of CT in LoRa-based networks is demonstrated
nicate with the gateway. Gateway is connected to the network in [9]. Moreover, it has also been demonstrated that CT’s
server, and it relays data back and forth between nodes and effectiveness in LoRa-based networks can be enhanced further
the server. LoRaWAN uses pure Aloha as the MAC layer by introducing timing offset between different transmissions.
protocol, hence nodes in LoRaWAN transmit data without Based on the mentioned insights, a CT-based multi-hop com-
employing clear channel assessment mechanism. A channel munication protocol for LoRa-based network is also presented.
 3

Before each data packet transmission the protocol randomly equal, therefore on an average one node in layer 3 acts as a
introduces a timing delay, and it ensures that multi-hop net- relayer for one node in layer 2. In multi-hop communication
work setup does not result in the divergence of delay. setup 2, it is assumed that half of the total nodes in a LoRa
A deployment of LoRa-based network for underground network are in layer 1, one quarter nodes are in layer 2, and
pervasive monitoring is presented in [10]. It has been shown another one quarter nodes are in layer 3. Hence, on an average
through measurements that LoRa’s transmission is limited to one node in layer 2 acts as a relayer for two nodes in layer
200 meters in an underground environment. Therefore, single 1. Since, the number of nodes in layer 2 and layer 3 is equal,
hop LoRaWAN network is not useful in such an environment. hence a node in layer 3 acts as relayer of one node in layer
To support such use cases multi-hop communication is re- 2. In communication setup 3, it is assumed that the number
quired, therefore an ah-hoc multi-hop communication protocol of nodes in each layer are nearly equal, hence one node in
for chain network topology is presented with the aim to layer (N + 1) acts as a relayer for a node in layer N . The
enhance LoRa’s coverage and reduce energy consumption. An- simulation results have demonstrated the effectiveness of the
other routing protocol for LoRa-based networks is presented presented communication setups.
in [11]. The routing protocol constructs data forwarding paths In [16], a clustering-based routing protocol for LoRa net-
using shortest hop-count and received signal strength indicator works is presented. The protocol assumes a central gateway,
(RSSI) metrics. The routing protocol constructs data paths for and it partitions a LoRa network in different clusters. The
upstream and downstream communications. In [12], a design clusters in the network are formed based on distance of
of 2-hop LoRa network is presented to extend the coverage nodes from the central gateway. Nodes near to the central
of LoRa-based networks in urban scenarios. Experimental gateway has a lower cluster number, and nodes away from
results have shown improvement in coverage and network the central gateway has a higher cluster number. Nodes in
performance. lower cluster act as relayers/parent for nodes in higher cluster.
In [13], two multi-hop communication setups for LoRa- In the presented protocol ordinary LoRa nodes are involved
based networks are presented. The first setup introduces a in route discovery and maintenance processes. An overview
relay node between an end device and a gateway. The relay of routing protocols for LoRa-based networks, and associated
node implements packet decoding and forwarding logic. The challenges are presented in [17].
relay device comes with the packet forwarding layer that
directly resides over the LoRa PHY layer. In the second setup, III. R EQUIREMENTS AND O BJECTIVES
multiple LoRa gateways are deployed in a LoRa network. Emerging IoT use cases, such as, smart parking, street
Each end device joins a single gateway, and end devices only lightning, smart metering, etc. are diverse and they span a large
communicates with their respective gateways. In the proposed geographical area. Moreover, to successfully support a typical
setup, there is a central gateway and each gateway can directly IoT use case hundreds or thousands of wireless sensor nodes
reach the central gateway. Hence, whenever an end device are deployed in a large geographical area. It is not uncommon
transmits a packet, the end device’s gateway receives the that in the same geographical area wireless sensor nodes
packet and transmit it again so that the central gateway can belonging to different IoT use cases are deployed. Hence, there
receive the end device’s packet. is a strong possibility that a deployed networking infrastructure
In [14], a routing protocol for gateway-to-gateway com- has to support multiple IoT use cases. Different IoT use cases
munication in LoRa-based networks is presented. Initially, may have different quality of service requirements, hence a
each gateway in a network broadcasts a HELLO message network deployed to support multiple IoT use cases in a large
to discover its direct neighbor gateways, hence each gateway geographical area needs to implement mechanisms that can
in a network maintains a list of its direct neighbour gateways. satisfy requirements of multiple IoT use cases each having
Afterwards, a reactive approach is followed to discover a path hundreds or thousands for wireless sensor nodes.
to the central gateway. A route request message is flooded in LoRaWAN is the de facto MAC layer for the LoRa PHY
a LoRa network so that the route request message can reach layer. LoRaWAN forms a network based on star topology,
the central gateway. On reception of the route request message hence each node in a network has to reach the gateway directly.
at the central gateway, the central gateway transmits a route Single-hop LoRaWAN network suffers from the following
reply message to the originator of the route request message. limitations: (i) LoRa coverage in urban settings is significantly
The route reply message reaches the originator of the route lower compared to its coverage in rural settings, hence in an
request message using the reverse path, and during the process urban setting LoRaWAN may not satisfy the coverage require-
the discovered route is stored at intermediate gateways. ment of an IoT use case (ii) LoRa PHY layer settings impacts
In [15], three multi-hop communication setups for a LoRa- coverage and reliability, therefore an IoT use case’s reliability
based network are presented. These setups partition a LoRa requirements can further impact the coverage of a single-hop
network in multiple layers, and an assumption about the LoRaWAN network, hence it is likely that LoRaWAN may not
number of LoRa nodes in each layer is made. In multi-hop satisfy the coverage requirement of those IoT use cases that
communication setup 1, it is assumed that 70% of total nodes require high coverage and reliability simultaneously, and (iii)
in a network are in layer 1, 15% of total nodes are in layer to provide maximum coverage LoRaWAN needs to use LoRa
2, and remaining 15% of total nodes are in layer 3. On an PHY layer setting that uses lower BW and highest possible
average one node in layer 2 acts as a relayer for five nodes in SF, this results in higher packet air-time, hence such a setting
layer 1. Since, the number of nodes in layer 2 and layer 3 are
 4

is not useful for those IoT uses cases that require hundred or
thousands of sensor nodes or those IoT use cases that require Legend:
relatively high BW. : Layer 2 Gateway
: Layer 1 Gateway
In light of the above, it is evident that there is a strong : Layer 0 Gateway
requirement to devise protocols and mechanisms that can en- : Root Gateway
able LoRa to support diverse set of IoT use cases with varying
: Cluster of Nodes
coverage, data rate, and reliability requirements in different
operational environments, such as, rural and urban. Moreover,
the devised protocols and mechanisms should enable the LoRa
technology to also support those IoT use cases that use a large
number of nodes. The aim of the work presented here is to
introduce multi-hop communication in LoRa-based networks
in order to enhance a LoRa network coverage, exploit LoRa’s
PHY layer customization ability to support multiple IoT use Layer 0
Layer 1
cases and large number of nodes, and in an attempt to provide
better quality of service a data traffic engineering mechanism Layer 2
is also presented.
Fig. 1. Multi-Hop LoRa Network Topology
The work presented here differs from the existing state-of-
the-art in the following manner: gateway (upstream), the root gateway and the nodes (down-
- Existing research work on multi-hop communication in stream), and between nodes (peer-to-peer). For the stated com-
LoRa-based networks follows a traditional approach, munication types, it is possible that the source and destination
i.e., majority of nodes in a LoRa network participate in nodes are not in the direct communication range. Hence, there
forwarding paths construction process by broadcasting is a need for multi-hop communication. To enable multi-
control messages. Such a method is not appropriate for hop communication, a routing protocol is required that can
low-power networks as nodes in such network possess discover and maintain data forwarding paths. Mostly, ordinary
limited resources and power. LoRa nodes are scarce in resources, such as available memory
- Usually, a low-power wide-area network comprises of and energy, therefore the presented routing protocol avoids
a large number of nodes, therefore routing protocols in involvement of such nodes in the route discovery process. The
which majority of nodes broadcast control messages can proposed protocol only involves gateways in route discovery
have a significant impact on the network’s performance. and maintenance process. Furthermore, ordinary LoRa nodes
- A LPWAN usually comprises of hundreds of thousands are not used as relayer, thus gateways also act as relayers.
of nodes, therefore simply constructing data forwarding For network formation and multi-hop communication there
paths may not be enough for a better performance. For is a need to assign addresses to each node in a network,
example, a large number of nodes in a network may need furthermore in the presented communication scheme a gateway
traffic load balancing, hence there is a need for traffic forms a subset of the overall network, therefore there is also a
engineering mechanisms with low control overhead. requirement to assign network address to each network formed
by a gateway. Here, the proposal is to reuse the addressing
IV. M ULTI - HOP C OMMUNICATION ROUTING P ROTOCOL scheme standardized in LoRaWAN. In a LoRaWAN network,
FOR L O R A a network formed by a gateway has a 3-byte network iden-
A. Network Topology and Addressing tifier (ID), and each node in the network is assigned 4-byte
address. Similarly, in the proposed multi-hop communication
The protocol forms a multi-hop LoRa network topology as
setup, each gateway’s network has a unique 3-byte network
shown in Fig. 1. In proposed multi-hop communication setup
ID and the gateway assigns unique 4-byte address to each
each LoRa node joins a network formed by a lightweight
node connected to the gateway. The multi-hop communication
gateway. There is also the root gateway that is connected to
setup as shown in Fig. 1 is composed of multiple gateways
the Internet. In the proposed multi-hop communication setup,
lightweight gateways and the root gateway, therefore a node in
apart from the root gateway other lightweight gateways are
such a network can be uniquely identified by using the node’s
fairly simple devices as they do not require the following
network ID and its the node’s address. As a node can only join
LoRaWAN’s gateway features: (i) decoding different simul-
exactly one gateway’s network and the node is connected to
taneous transmissions, (ii) connection to a network’s server,
the gateway in a star topology, therefore the proposed protocol
(iii) support for other communication technologies apart from
can discover data forwarding paths by only using network
LoRa, (iv) there is no need for the Internet connection, and
IDs. The protocol partitions overall network into layers, and
(v) there is no need for an electric supply as such gateways
gateways in adjacent layers act as relayers for each other. List
can work with relatively high capacity batteries. Therefore, the
of abbreviations used here are presented in Table I.
lightweight gateway is only responsible for forming a network
and relaying packets to other gateways lightweight gateways
and root gateway and nodes in its network. Typically, IoT
uses cases require communication between nodes and the root
 5

TABLE I 0 do not rebroadcast the NDIS message. Upon receiving the

L IST OF A BBREVIATIONS NDIS message, gateways at layer 0 store the root gateway’s
Abbreviation Expanded Form network ID for upstream communication, and prepare and
NDIS Network Discovery transmit the NRES message. In the NRES message, each
NRES Network Response gateway stores its own network ID in NRES → T GN ID
MID Message ID
LID Layer ID and NRES → DGN ID fields. Upon receiving the NRES
HCN T Hop Count message, the root stores the layer 0 gateway’s ID in its
T GN ID Transmitting Gateway’s Network ID forwarding table for downstream communication. The root
RGN ID Root Gateway’s Network ID maintains the following information in its forwarding table:
DGN ID Destination Gateway’s Network ID
N etID Network ID destination network ID = NRES → DGN ID and next hop
GwADDR Gateway Address = NRES → T GN ID . As the next step in the process, the root
RSSI Received Signal Strength Indicator initiates the process to discover gateways at layer 1. Therefore,
DataP KT Data Packet
SrcN ID Source Network ID
the root broadcasts NDIS message with NDIS → LID and
DsnN ID Destination Network ID NDIS → HCN T fields set to 1. As gateways at layer 1
SrcN ADDR Source Node Address are not in the transmission range of the root, therefore the
DsnN ADDR Destination Node Address gateways at layer 0 rebroadcast NDIS message, and before
N hopGID Next-hop Gateway ID
CtrlBY T E Control Byte rebroadcasting the message NDIS → HCN T field is decre-
N etT OP O Network Topology Message mented by one, and a gateway changes NDIS → T GN ID
N umGW s Number of Gateways field with its own network ID. When a gateway at layer 1
F lowSET U P Flow Setup
receives NDIS message with NDIS → HCN T containing
value 0, it stores root gateway’s network ID in its forwarding
B. Layers Formation, Gateways Discovery, and Forwarding
table and NDIS → T GN ID is stored as the next hop towards
Paths Construction
the root. Afterwards, layer 1 gateway prepares and transmits
The proposed routing protocol first partitions a network area NRES message. In NRES message the gateway inserts its own
into multiple layers, and discovers different LoRa networks in network ID in NRES → DGN ID and NRES → T GN ID
each layer. The root gateway decides about the LoRa PHY fields and unicasts the message to NDIS → T GN ID (the
layer parameters to be used in a network, hence the radius gateway at layer 0 from whom the gateway has received
of a layer depends on the coverage of selected LoRa PHY the NDIS message). Upon receiving the NRES message a
layer parameters. A number of control messages to discover gateway at layer 0 stores NRES → DGN ID in its forwarding
gateways at different layers, and to construct upstream, down- table and next hop is also set to NRES → DGN ID as
stream, and peer-to-peer data forwarding paths are designed. the destination gateway is directly reachable. Afterwards, the
To avoid reinventing the wheel, here the proposal is to reuse gateway at layer 0 changes NRES → T GN ID field to its own
data/control frame formats standardized in LoRaWAN with ap- network ID, and transmits the message to the root. In this
propriate modifications. The LoRaWAN frame header contains way, the root constructs forwarding path to layer 1 gateway
M essageT ype field to identify the type of message carried by storing the following information in its forwarding table:
in the frame. The LoRaWAN specification has standardized 8 destination network ID = NRES → DGN ID and next hop
message types, and there is a reserved M essageT ype called = NRES → T GN ID . The process continues till the root
proprietary. The routing protocol uses proprietary message discovers forwarding paths to all gateways in a network, and in
type to encode its different messages. Using LoRaWAN frame the process all gateways also discover forwarding paths to the
structure is an option, however the protocols presented here root. Processing of NDIS and NRES messages at a gateway
can work even if the LoRaWAN frame structure is not used. is shown in Algorithm 1 and Algorithm 2 respectively.
The routing protocol defines the following control messages: As the network ID of a network operating under each
(i) network discovery (NDIS ), and (ii) network response gateway is unique, therefore the proposed protocol can route
(NRES ). The size of NDIS message is 9 bytes: message ID data packets in the following three scenarios: (i) data packet
(MID ) 1 byte, layer ID (LID ) 1 byte, hop count (HCN T ) originating from any node for the root (upstream communica-
1 byte, transmitting gateway’s network ID (T GN ID ) 3 bytes, tion), (ii) data packet originating from the root to another
and the root gateway’s network ID (RGN ID ) 3 bytes. Sim- node (downstream communication), and (iii) data packet
ilarly, the size of NRES is 7 bytes: MID 1 byte, T GN ID 3 originating from any node for another node (peer-to-peer
bytes, and destination gateway network ID (DGN ID ) 3 bytes. communication). For upstream communication each gateway
The MID field contains value 0x00 and 0x01 in NDIS and stores next-hop upstream gateway’s network ID, and for
NRES messages respectively. Initially, each gateway’s LID is downstream communication the root gateway stores next-hop
set to ∞. downstream gateways’ network IDs that can route its packets
The root gateway initiates the network layering, gateways to the destination node. However, neither nodes nor gateways
discovery, and forwarding paths construction process. Initially, maintain peer-to-peer data forwarding paths. For peer-to-peer
the root discovers gateways at layer 0 by broadcasting NDIS communication first a data packet is routed to the root, and
message with NDIS → LID and NDIS → HCN T fields afterwards the root routes the packet to the destination node
set to 0, and NDIS → RGN ID contains root’s network ID. using the destination network ID.
Setting NDIS → HCN T to 0 ensures that gateways in layer
 6

Algorithm 1: NDIS Processing at a Gateway

Legend:
1 Input: NDIS ; : Layer 2 Gateway
2 if : Layer 1 Gateway
: Layer 0 Gateway
NDIS → LID < Gw → LID & & NDIS → HCN T == 0 : Root Gateway
then
3 Gw → LID = NDIS → LID ;
Gw → add upstrm entry(NDIS → T GN ID ) ;
GRES = create NRES M sg() ;
GRES → DGN ID = Gw → N ET ID ;
GRES → T GN ID = Gw → N ET ID ;
unicast(NRES , NDIS → T GN ID ) ;
4 end
5 else
6 if NDIS → HCN T > 0 then
Fig. 2. Constructed LoRa-Based Multi-Hop Network
7 NDIS → HCN T = NDIS → HCN T − 1;
NDIS → T GN ID = Gw N ET ID; O(1), i.e., constant time.
8 broadcast(NDIS );
9 end
C. Cluster Formation
10 end
The cluster formation process ensures that each node asso-
ciates itself with exactly one gateway. After a node associates
Algorithm 2: NRES Processing at a Gateway itself with a gateway, the node can communicate with the root
1 Input: NRES ; and other nodes through the gateway. If there are multiple
2 dwnstrm rcd = create dwnstrm rcd() ; gateways within the transmission range of a node, the node
dwnstrm rcd → dsn net ID = NRES → DGN ID has to select one gateway for its association. For proper
; dwnstrm rcd → next hop = NRES → T GN ID ; association the protocol defines another control message called
update f wding table(dwnstrm rcd) ; HELLO. The size of HELLO message is 8 bytes: MID
3 if is root gateway() == false then 1 bytes, network ID (N etID ) 3 bytes, and gateway address
4 NRES → T GN ID = gtw → N ET ID ; (GwADDR ) 4 bytes. MID for the HELLO message is 0x02.
next hop = get next hop towards root() ; Each gateway periodically broadcasts the HELLO message.
unicast(NRES , next hop) ; If a node is within the transmission range of multiple gateways,
5 end the node uses RSSI metric to join a gateway. In a dynamic
wireless channel, only using one sample of RSSI may not
result in an appropriate gateway selection, therefore before
1) Control Overhead for Gateways Discovery and Algo- selecting a gateway a node must collect N samples and can use
rithms Time Compexity: The following assumptions are made exponential average to select the best gateway. Fig. 2 shows
in order to determine the number of control messages trans- a sample LoRa-based multi-hop network constructed through
mission for gateways discovery in a LoRa-based network: the proposed protocol.
Another use of the HELLO message is that it allows gate-
- The network is partitioned in L layers.
ways to discover direct neighbour gateways. In the proposed
- There are approximately equal number of gateways in
routing protocol, each gateway maintains a list of its direct
each layer.
neighbor gateways by storing their network IDs. Maintaining a
- The number of gateways in each layer is denoted by P .
list of direct neighbor gateways achieves efficient peer-to-peer
Let OverheadGDIS denotes the total control messages communication. Before forwarding a data packet, a gateway
transmissions for network-wide gateways discovery. Let can check if the gateway with the destination network ID is its
T otalN DIS denotes the total number of NDIS messages trans- direct neighbour. If that is the case, the gateway can directly
mitted for network-wide gateways discovery, and T otalN RES forward the packet to the destination gateway. Otherwise, a
denotes the total number of NRES messages transmitted data packet may have to traverse a longer forwarding path.
for network-wide gateways discovery. Therefore, total control
overhead is OverheadGDIS = T otalN DIS + T otalN RES .
D. Packet Forwarding Logic
T otalN DIS = L + P + 2P + ... + (L − 1)P = L +
Pk=L−1  To enable multi-hop packet forwarding using the
P (1 + 2 + 3 + ... + (L − 1)) = L + P k=1 k =
  proposed routing protocol, another M essageT ype, i.e.,
L(L−1)
L+P 2 . Similarly, T otalN RES = P + 2P + ... + data packet (DataP KT ). The total size of DataP KT header
P   
LP = P (1 + 2 + ... +L) = P
k=L
k = P L(L+1)
. is 19 bytes, and it contains the following fields: MID 1 byte,
 k=1   2  source network ID (SrcN ID ) 3 bytes, source node address
L(L−1) L(L+1)
Hence, OverheadGDIS = L + P 2 +P 2 . (SrcN ADDR ) 4 bytes, destination network ID (DsnN ID )
The time complexity for Algorithm 1 and Algorithm 2 is 3 bytes, destination node address (DsnN ADDR ) 4 bytes,
 7

next hop gateway ID (N hopGID ) 3 bytes, and control byte pares its gateway ID with the ID present in the DataP KT →
(CtrlByte ) 1 byte. The most significant bit in the control byte DsnN ID field. If the IDs match, the gateway changes the
indicates whether the message needs to be processed by a value in DataP KT → CtrlByte to 0x00, and transmits
gateway or a node. For now, the other bits in the CtrlByte are the message to the destination node. If the values do not
reserved. A gateway only processes a DataP kT if CtrlByte match, the gateway searches for the destination gateway in its
is set to 0x80, and an ordinary LoRa node only processes a neighbouring gateways table, if the DsnN ID is present in the
DataP KT if CtrlByte is set to 0x00. The MID field value table, the gateway changes the ID in DataP KT → N hopGID
for DataP KT is 0x03. with the destination gateway ID, and transmits the packet. If
1) Upstream Packet Forwarding: Whenever a node has DsnN ID is not present in the neighbour table, the gateway
a data packet for the root gateway, the node prepares indexes its forwarding table using the gateway ID present in
DataP KT message with DataP KT → MID field set to 0x03, the DataP KT .DsnN ID field. If the gateway finds a valid next
DataP KT → SrcN ID field set to the node’s gateway ID, hop gateway in the forwarding table, it changes the ID in the
DataP KT → SrcN ADDR field set to node’s own address, DataP KT → N hopGID field with the N hopGID obtained
DataP KT → DsnN ID field set to the root gateway’s ID, from the forwarding table. If a valid entry is not present
DataP KT → DsnN ADDR field set to the root gateway’s in the forwarding table, the gateway indexes its forwarding
address (each gateway’s node ID within their network is 0, table again with the root gateway ID, and changes the ID in
therefore this field contains value 0), DataP KT → N hopGID the DataP KT → N hopGID field with the obtained gateway
to the node’s gateway ID, and as the message needs to be ID. Finally, the gateway transmits the packet. This process
processed by the gateway, therefore DataP KT → CtrlByte continues till the packet is delivered to the destination node.
contains the value 0x80. When the gateway receives the
message, it examines DataP KT → N hopGID field. The V. S OFTWARE -D EFINED N ETWORKING E XTENSION
gateway only processes the data packet if the value stored in Author envision that a software defined networking (SDN)
DataP KT → N hopGID matches its own gateway ID. After- based extension for the proposed protocol can further enhance
wards, the gateway compares the value stored in DataP KT → multi-hop communication in LoRa-based networks. It can
DsnN ID with its own gateway ID, if the values match the enable different traffic engineering features, such as, load-
DataP KT has arrived at the root. Otherwise, the gateway balancing among the available gateways and efficient data
fetches the next hop gateway ID towards the root from its for- packet forwarding in case of peer-to-peer communication as
warding table, replaces the value in DataP KT → N hopGID gateways can forward a packet without involving the root in
with the fetched ID, and transmit the data packet. The process the forwarding process. The proposed SDN-based extension
continues till the packet is delivered to the root. consists of the following components:
2) Downstream Packet Forwarding: Whenever the root
- Network topology discovery for the root gateway
has a data packet for any node in a network, it prepares
- Flow tables setup at gateways
the DataP KT message with appropriate values. Using the
DsnN ID value, the gateway searches its forwarding table, and
inserts the fetched gateway ID in the DataP KT → N hopGID A. Network Topology Discovery
field. Afterwards, the root transmits the packet. All gateways in In section IV-C, the HELLO control message is defined.
the transmission range of the root receives the packet, however The message is used by a node to select a gateway, and it
the gateway whose gateway ID matches the gateway ID stored is also used by gateways to discover their direct neighbour
in DataP KT → N hopGID processes the packet. The gateway gateways. In the proposed protocol data packet forwarding is
compares its own gateway ID with the gateway ID present carried out based on DGN ID , therefore if the root gateway
in the DataP KT → DsnN ID field, if the values match the can obtain information about each gateway’s neighbouring
gateway forwards the packet to the destination node that is gateway, the root gateway can construct a network’s topology
part of the gateway’s own network. Before forwarding the and different forwarding paths. In the proposed protocol,
packet to the destination node, the gateway changes the value each gateway maintains information about its direct neighbour
in DataP KT → CtrlByte to 0x00. This is required as in the gateways, therefore if each gateway shares this information
proposed protocol an ordinary LoRa node only processes data with the root, the root can accurately construct the network
packet if the value stored in the DataP KT → CtrlByte field is topology. To facilitate network topology construction at the
0. If the DsnN ID does not match with the ID present in the root, here another control message called network topology
DataP KT → DsnN ID , the gateway indexes its forwarding message (N etT OP O ) is defined. The N etT OP O message
table using the ID present in DataP KT → DsnN ID , and contains the following fields: MID 1 byte, N hopGID 3 byte,
replaces the ID in DataP KT → N hopGID with the fetched number of gateways (N umGW s ) 1 byte, and list of gateway
gateway ID. Afterwards, the gateway transmits the message. IDs (variable length). In this work the proposal is to reuse the
The process continues till the packet is delivered to the LoRaWAN MAC frame structure, the maximum payload that
destination node. can be carried in LoRaWAN frame varies from 51 bytes to
3) Peer-to-Peer Packet Forwarding: Whenever a node has 222 bytes depending upon the LoRa PHY layer parameters in
a data packet for another node in a network, it prepares use. The constant length part of N etT OP O message is 5 bytes,
DataP KT with appropriate values, and transmits the packet therefore the maximum size of the gateway IDs list varies from
to its gateway. Upon receiving the message, the gateway com- 46 bytes to 217 bytes. As a gateway network ID comprises of
 8

1 Byte 1 Byte 1 Byte 3 Bytes 3 Bytes

3 bytes, therefore the maximum number of gateway IDs that
can be stored in the gateway IDs list varies from 15 to 72.
MID LID HCNT TGNID RGNID
The MID for the N etT OP O message is 0x04. The working
of the presented protocols are not impacted by the choice of (a) Network Discovery (NDIS) Message Format
the MAC frame structure, therefore the presented protocols
1 Byte 3 Bytes 3 Bytes
can work even if one does not want to use LoRaWAN MAC
frame structure.
MID TGNID DGNID
Each gateway periodically transmits the N etT OP O mes-
sage. Before transmitting the message a gateway stores 0x04 (b) Network Response (NRES) Message Format
in N etT OP O → MID field, the number of the gateway’s
neighbouring gateways is stored in N etT OP O → N umGW s . 1 Byte 3 Bytes 4 Bytes

As the message is for the root gateway, therefore the gateway

extracts the next-hop gateway ID to the root from its forward- MID NetID GwADDR

ing table, and stores it in the N etT OP O → N hopGID field. (c) HELLO Message Format
Finally, the message is transmitted to the N hopGID . When
the N etT OP O message is received at a gateway, it replaces the 1 Byte 3 Bytes 4 Bytes 3 Bytes 4 Bytes 3 Bytes 1 Byte Variable

N etT OP O → N hopGID field with its next-hop towards the

MID SrcNID SrcNADDR DsnNID DsnNADDR HhopGID CtrlBYTE Payload
root, and transmits the message. Finally, the message reaches
at the root and it stores and maintains the network topology (d) Data Packet (DataPKT) Format
information in a table data structure.
1 Byte 3 Bytes 1 Byte Variable
B. Flow Tables Setup at Gateways
MID HhopGID NumGWs List of Gateway IDs
In a SDN-based network, there is a centralized controller
that setup flow tables at different nodes in a network. In the (e) Network Topology (NetTOPO) Message Format
proposed protocol, the root performs the SDN controller func-
tionality of setting up the flow tables. Typically, specialized 1 Byte 3 Byte 3 Byte 1 Byte Variable

control message is used to setup a node’s flow table. The

MID DGNID HhopGID CtrlBYTE List of (DGNID, HhopGID) tuples
proposed protocol is not an exception, hence a F lowSET U P
control message for the purpose of setting up flow tables at
(f) Flow Setup (FlowSETUP) Message Format
gateways is defined. The F lowSET U P message contains the
following fields: MID 1 byte, DGN ID 3 bytes, N hopGID Fig. 3. Multi-Hop Communication Protocol Messages’ Format
3 byte, CtrlBY T E 1 byte, and a list of DGN ID , N hopGID
tuples. The size of each tuple is 6 bytes. The number of tuples VI. P ERFORMANCE E VALUATION
in the list of DGN ID , N hopGID tuple is one less the number For performance evaluation discrete event LoRaSim sim-
of gateways in a network including the root gateway. Hence, ulator designed for LoRa-based networks [18] is used. The
the root setup the flow table at each gateway with the following simulator uses log-distance path loss model which is widely
information: DGN ID and next-hop to the DGN ID . The MID used to model wireless channel in densely populated build-up
field in the F lowSET U P message contains value 0x05. areas. The simulator models path loss using Equation 1. In the
It is possible that the list of DGN ID , N hopGID tuple does equation, Lpl (d) represents path loss in dB, mean path loss at
not fit in single F lowSET U P message. If that is the case the reference distance do is represented Lpl (d0 ), γ represents
the root set the most significant bit in the F lowSET U P → the path loss exponent, and Xσ ∼ N (0, σ 2 ) is the normal
CtrlByte field of the message. This indicates that there are distribution with 0 means and σ 2 variation. In LoRa, a node’s
still some pending entries which are being sent in a sep- energy consumption depends on transmission power, spreading
arate F lowSET U P message. If the most significant bit of factor, bandwidth, and coding rate. Therefore, LoRaSim uses
the F lowSET U P → CtrlByte field is not set, this indicates energy model that takes into account the mentioned factors,
that there are no pending flow tables entries. The remaining more information about the energy model can be found in
bits in the CtrlBY T E field are reserved for future use. The [18].
root prepares the F loWSET U P message for each gateway  
in a network, and forward the messages to the respective d
Lpl (d) = Lpl (d0 ) + 10γlog + Xσ (1)
gateways using the data forwarding paths discovered by the d0
root during the layers formation phase. This separates the In simulations, the total size of LoRa MAC layer frame is
control plane and data plane as control information flows 50 bytes including application payload. This is large enough
using the forwarding paths constructed during layers formation frame size to facilitate multitude of IoT use cases, such as
phase, and data packets are forwarded using the set up flow smart metering, smart lightning, smart parking, etc. the per-
tables. Fig. 3 shows the format of different messages used by formance of the proposed multi-hop communication protocol
the proposed protocol. (MHCP) and its SDN variant is compared with single hop
LoRa network based on star topology (hereafter, we call this
 9

setup as LoRaWAN because LoRaWAN is also based on packets forwarded by layer 3 gateways. RPL demonstrates
star topology), and RPL [5]. Since, single-hop LoRa network lower PRR relative to the proposed protocols, and the main
usually needs to cover large geographical area, therefore reason is that the control overhead associated with RPL is
for single-hop LoRaWAN network in the simulation-based significantly higher, and this is also shown in Fig. 4 (c). As
experiments the following PHY layer settings are used: SF the LoRaWAN’s recommended PHY layer setting uses lower
= 12, BW = 125 KHz, and CR = 4/5. Performance of the bandwidth to cover relatively large area, hence the packet air-
proposed protocols is also compared against RPL because it time is significantly higher. The higher packet air-time results
is the standard routing protocol for low-power wireless net- in the higher number of collisions, thus lower PRR. The
works, moreover existing work on multi-hop communication results also demonstrate that the LoRaWAN’s recommended
in LoRa-based networks has focused on using RPL [6]. In setting is not scalable as the PRR substantially deteriorates
the simulation-based experiments, the RPL implementation with an increase in the number of nodes. However, the results
uses the objective function based on the shortest hop-count to presented here also demonstrate that the proposed protocols
construct data forwarding paths. To simulate multi-hop LoRa- also exhibit scalability feature.
based networks using the proposed protocols and RPL, here Fig. 4 (b) shows the total network-wide energy comparison
LoRa’s fastest data rate PHY layer setting is used [SF = 6, BW on the log scale. MHCP and MHCP-SDN demonstrate up to
= 500 KHz, and CR = 4/5]. Therefore, MHCP, MHCP-SDN, 63% and 33% lower energy consumption compared to Lo-
and RPL use LoRa’s fastest data rate PHY layer setting. Based RaWAN and RPL respectively. Among the proposed protocols,
on radio channel model used in this study, the coverage of the MHCP-SDN demonstrates slightly higher energy consumption
PHY layer settings used by the proposed protocols and RPL compared to MHCP, however the difference is not statistically
is 3 times lower than the LoRa PHY layer setting used for significant. As MHCP-SDN uses additional control messages
single-hop LoRa network in the experiments [18]. Therefore, to setup flow tables at different gateways, and gateways also
to enable the setup based on LoRa’s fastest data rate PHY propagate topology information to the root gateway, hence
settings to match the coverage of LoRa PHY setting used for higher control message overhead contributes towards a slightly
single-hop LoRa network, for the proposed protocols and RPL higher energy consumption. In RPL, each node inside the net-
we use a network topology in which a node in the network work broadcasts control message to discover forwarding paths,
can reach the root gateway in at most 3-hops. As part of the and in the proposed protocols only gateways broadcast control
work presented here, LoRaSim has been extended so that it messages to discover forwarding paths, hence relatively higher
can simulate the proposed multi-hop communication protocols control message overhead contributes towards RPL’s higher
and RPL. energy consumption. LoRaWAN exhibits highest amount of
In simulations, the number of nodes are varied from 200 energy consumption primarily because of the significantly
to 1000 in steps of 200 nodes. For the proposed protocols, higher air-time associated with the recommend PHY layer
the network is partitioned in 3-layers, layer 1 contains root setting. As the results shown in Fig. 4 (b) shows total network-
gateway, layer 2 contains 4 gateways, and layer 3 also contains wide energy consumption, therefore with an increase in the
4 gateways. LoRa nodes are distributed in such a manner that number of nodes the total energy consumption also increases.
each gateway handles the same number of nodes. However, Fig. 4 (c) shows the total network-wide control messages
using MHCP it is possible that a gateway in layer 2 is overhead comparison on the log scale. As LoRaWAN uses
relaying data packets for more than one gateways in layer 3. single hop star topology-based network, therefore there is no
The MHCP-SDN protocol introduces load-balancing, therefore multi-hop communication control messages overhead associ-
each gateway in layer 2 relays data packets for exactly one ated with LoRaWAN. The proposed protocols demonstrate
gateway in layer 3. To obtain a confidence interval (CI) each significantly lower control messages overhead compared to
simulation scenario is repeated 31 times. The total duration of RPL. This is primarily due to the reason that in RPL each
each simulation is 24 hours. Generally, IoT use cases traffic node transmits control messages, however in the proposed
generic follows Poisson and periodic data generation models, protocols only gateways transmit control messages. With an
therefore in simulation-based experiments the same data traffic increase in the number of nodes inside the network RPL
generation models are used. control overhead increases, however for the proposed protocols
multi-hop communication control overhead will only increase
A. Results Using Periodic Data Generation Model with the increase in the number of gateways. Therefore, the
proposed protocols also exhibit scalability feature in terms of
Each node in a network periodically generates data packet
multi-hop communication control messages overhead.
after every 30 minutes. Fig. 4 (a) shows the mean packet
reception ratio (PRR) demonstrated by different protocols.
The MHCP and MHCP-SDN protocols outperformed RPL B. Results Using Poisson Data Generation Model
and LoRaWAN, and the difference in the performance is Each node generates data packets using a Poisson arrival
statistically significant. The proposed protocols demonstrated process with mean arrival rate (λ) of 30 minutes. Fig. 5
up to 5 times higher PRR compared to LoRaWAN. MHCP- (a) shows the mean PPR demonstrated by the protocols. In
SDN demonstrated slightly higher PRR compared to MHCP. this case as well, MHCP and MHCP-SDN outperform RPL
This is primarily due to the fact that MHCP-SDN balances and LoRaWAN, and the difference is statistically significant.
data packet forwarding load among layer 2 gateways of the MHCP and MHCP-SDN demonstrate nearly 400% and 53%
 10

100

Log(Total Energy Consumed) Joule

5

Log(Total Control Messages)

4
80 4
3
PRR (%)
60 3

40 2
2

20 1 1

0 0 0
200 400 600 800 1000 200 400 600 800 1000 200 400 600 800 1000
(a) Number of Nodes (b) Number of Nodes (c) Number of Nodes
MHCP MHCP-SDN RPL LoRaWAN

Fig. 4. Protocols’ Performance Comparison Using Periodic Data Generation Model

100
Log(Total Energy Consumed) Joule

Log(Total Control Messages)

4
80 4
3
PPR (%)

60 3

40 2
2

20 1 1

0 0 0
200 400 600 800 1000 200 400 600 800 1000 200 400 600 800 1000
Number of Nodes Number of Nodes Number of Nodes
MHCP MHCP-SDN RPL LoRaWAN

Fig. 5. Protocols’ Performance Comparison Using Poisson Data Generation Model

higher PPR compared to LoRaWAN and RPL respectively. energy consumption compared to LoRaWAN and RPL respec-
Primarily, RPL’s performance is impacted due to its higher tively. The reasons for LoRaWAN and RPL higher energy
control overhead, and LoRaWAN’s performance is impacted consumption are the same as described in Section VI-A. Fig.
due to its recommended PHY layer setting’s higher air-time. 5 (c) shows the total network-wide control messages overhead
With an increase in the number of nodes MHCP and MHCP- comparison on the log scale. The results are consistent with
SDN demonstrate steady performance, however RPL and the results shown in Fig. 4 (c), i.e., the proposed protocol has
LoRaWAN performance deteriorate. Therefore, these results significantly lower multi-hop communication control overhead
also highlight that MHCP and MHCP-SDN hold scalability compared to RPL, and it does not increase with an increase
feature. Comparison of Fig. 4 (a) and Fig. 5 (a) highlights that in the number of nodes given that the number of gateways in
the data packet generation model based on Poisson distribution the network stays the same.
improves the protocols’ performance. This is due to the fact
that in periodic data generation model multiple nodes transmit VII. C ONCLUSIONS
data packets at the same time, hence it results in higher Based on the LoRa’s fastest data rate PHY layer setting
collision and lower PRR. a multi-hop communication protocol with an aim to achieve
Fig. 5 (b) shows the total network-wide energy compar- high data rate and large coverage is presented. Moreover, to
ison on the log scale. The results shown in Fig. 5 (b) are enable traffic engineering features in LoRa-based networks a
consistent with the results shown in Fig. 4 (b), i.e., MHCP SDN-based extension for the protocol is also presented. The
and MHCP-SDN demonstrate statistically significantly lower protocols’ performance has been evaluated using periodic and
energy consumption compared to RPL and LoRaWAN. MHCP event-based data generation models. Moreover, the protocols’
and MHCP-SDN demonstrate nearly 48% and 18% lower performance has also been investigated by varying the total
 11

number of nodes in a network. The simulation-based results [8] G. Zhu, C. Liao, T. Sakdejayont, I. Lai, Y. Narusue, and H. Morikawa,
have shown that the proposed protocols can match coverage “Improving the Capacity of a Mesh LoRa Network by Spreading-Factor-
Based Network Clustering,” IEEE Access, vol. 7, pp. 21 584–21 596,
of one of the LoRa’s high coverage PHY layer setting at a 2019.
higher data rate and lower energy consumption. The protocols [9] C. Liao, G. Zhu, D. Kuwabara, M. Suzuki, and H. Morikawa, “Multi-
have also demonstrated steady performance with an increase in Hop LoRa Networks Enabled by Concurrent Transmission,” IEEE
Access, vol. 5, pp. 21 430–21 446, 2017.
the number of nodes in a network, hence the protocols possess [10] A. Abrardo and A. Pozzebon, “A Multi-Hop LoRa Linear Sensor
scalability feature. Moreover, the protocols have outperformed Network for the Monitoring of Underground Environments: The Case of
RPL, and the presented multi-hop communication protocols’ the Medieval Aqueducts in Siena, Italy,” Sensors, vol. 19, no. 2, 2019.
[11] H. Lee and K. Ke, “Monitoring of Large-Area IoT Sensors Using a
control overhead is substantially lower compared to RPL. LoRa Wireless Mesh Network System: Design and Evaluation,” IEEE
Transactions on Instrumentation and Measurement, vol. 67, no. 9, pp.
2177–2187, 2018.
R EFERENCES [12] M. DIOP and C. PHAM, “Increased flexibility in long-range IoT
[1] N. Sornin, M. Luis, T. Eirich, T. Kramp, and O. Hersent, “LoRaWAN deployments with transparent and light-weight 2-hop LoRa approach,”
Specifications, LoRa Alliance, San Ramon, CA, USA,” 2015. in 2019 Wireless Days (WD), 2019, pp. 1–6.
[2] N. Aftab, S. A. R. Zaidi, and D. McLernon, “Scalability Analysis [13] M. S. Aslam, A. Khan, A. Atif, S. A. Hassan, A. Mahmood, H. K.
of Multiple LoRa Gateways Using Stochastic Geometry,” Internet of Qureshi, and M. Gidlund, “Exploring Multi-Hop LoRa for Green Smart
Things, vol. 9, p. 100132, 2020. Cities,” IEEE Network, vol. 34, no. 2, pp. 225–231, 2020.
[3] R. K. Singh, R. Berkvens, and M. Weyn, “Synchronization and Efficient [14] M. H. Dwijaksara, W. Sook Jeon, and D. G. Jeong, “Multihop Gateway-
Channel Hopping for Power Efficiency in LoRa Networks: A Compre- to-Gateway Communication Protocol for LoRa Networks,” in 2019 IEEE
hensive Study,” Internet of Things, vol. 11, p. 100233, 2020. International Conference on Industrial Technology (ICIT), 2019, pp.
[4] H. Mroue, B. Parrein, S. Hamrioui, P. Bakowski, A. Nasser, E. M. Cruz, 949–954.
and W. Vince, “LoRa+: An Extension of LoRaWAN Protocol to Reduce [15] M. O. Farooq, “Introducing Scalability in LoRa-Based Networks
Infrastructure Costs by Improving the Quality of Service,” Internet of through Multi-Hop Communication Setups,” in 2019 IEEE Global
Things, vol. 9, p. 100176, 2020. Communications Conference (GLOBECOM), 2019, pp. 1–6.
[5] A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur, [16] B. Paul, “A Novel Energy-Efficient Routing Scheme for LoRa Net-
and R. Alexander, “RPL: IPv6 Rotuing Protocol for Low-Power and works,” IEEE Sensors Journal, vol. 20, no. 15, pp. 8858–8866, 2020.
Lossy Networks,” March 2012, RFC 6550. [17] A. Osorio, M. Calle, J. D. Soto, and J. E. Candelo-Becerra, “Rout-
[6] B. Sartori, S. Thielemans, M. Bezunartea, A. Braeken, and K. Steenhaut, ing in LoRaWAN: Overview and Challenges,” IEEE Communications
“Enabling RPL Multihop Communications based on LoRa,” in IEEE Magazine, vol. 58, no. 6, pp. 72–76, 2020.
13th International Conference on Wireless and Mobile Computing, [18] M. C. Bor, U. Roedig, T. Voigt, and J. M. Alonso, “Do LoRa Low-
Networking and Communications (WiMob), 2017, pp. 1–8. Power Wide-Area Networks Scale?” in Proceedings of the 19th ACM
[7] S. Thielemans, M. Bezunartea, and K. Steenhaut, “Establishing Trans- International Conference on Modeling, Analysis and Simulation of
parent IPv6 Communication on LoRa based Low Power Wide Area Wireless and Mobile Systems, ser. MSWiM ’16, 2016, pp. 59–67.
Networks (LPWANS),” in Wireless Telecommunications Symposium
(WTS), 2017, pp. 1–6.

View publication stats