2017 IEEE 13th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob)

Enabling RPL multihop communications based on LoRa

Benjamin Sartori Maite Bezunartea

ETRO, Vrije Universiteit Brussel ETRO, Vrije Universiteit Brussel
Brussels, Belgium Brussels, Belgium
imec, Leuven, Belgium imec, Leuven, Belgium
Email: [email protected] Email: [email protected]

Steffen Thielemans An Braeken

ETRO, Vrije Universiteit Brussel INDI, Vrije Universiteit Brussel
Brussels, Belgium Brussels, Belgium
imec, Leuven, Belgium Email: [email protected]
Email: [email protected]

Kris Steenhaut
ETRO, Vrije Universiteit Brussel
Brussels, Belgium
imec, Leuven, Belgium
Email: [email protected]

Abstract—New Long-Range radio technologies have recently this information wirelessly to a control node to process or
emerged in the IoT landscape. These technologies work in the store it. They are meant to be directly connected to the Inter-
Sub-GHz bands, allowing low-power communications over long net to guarantee interoperability, ease data exchange through
distances. They are typically based on star-topology networks,
where nodes send the data directly to a base station connected the use of simple and well-known web technologies such
to the Internet. One of such technologies is LoRa. Enabled as Web Services, offer easy management and configuration
LoRa-based multihop communications would open up new options and make each sensor individually reachable from
possibilities. In this paper we present a solution allowing to outside its network via its own IP address.
have multihop LoRa communications. This is done by means In order to be able to achieve this, it is necessary to
of a newly designed MAC protocol (RLMAC), used to select
the Spreading Factor for each available neighbor. The proposed create and develop adequate and efficient communication
Objective Function used by RPL will therefore be able to select protocols and radio technologies specifically designed for
the routing path that minimizes time on-air. By selecting the meeting the requirements of LLNs, as opposed to traditional
path with the lowest time on-air, the power consumption can be IP-based networks. That is the reason why many standard-
decreased, enlarging network lifetime. Preliminary validation ization efforts have been made to fully integrate resource-
tests are also presented in the paper.
constrained mesh networks in the Internet, using IPv6 as
Keywords-LoRa; IPv6; RPL; Multihop communications; network protocol (6LoWPAN, the RPL routing protocol,
MAC. CoAP, etc).
Recently, new long-range, low-bitrate radio technologies
I. I NTRODUCTION have emerged in the IoT landscape [1]. These new radio
The interest in and the market of the Internet of Things technologies work in the sub-1GHz unlicensed ISM bands,
(IoT) and its related technologies is indeed steadily in- offering power-efficient communication over long distances.
creasing. As it is well known, the IoT aims at connecting Examples of such new technologies are LoRa, Sigfox and
and automating every aspect of daily life. Some of the Weightless. They are typically networks of nodes commu-
most important IoT applications are: predictive maintenance, nicating the data to a base station in a single-hop manner.
resource control, natural disaster prevention or fast detection, The so created star topology is convenient for the ease of
medical monitoring, intelligent building and smart home, deployment and has advantages from a business perspective.
production chain control and monitoring, etc. Being able to have multi-hop between nodes though, could
Within IoT, Low-power and Lossy networks (LLNs) are of mitigate some upcoming issues of bandwidth congestion [2].
great importance. These are networks of spatially distributed Moreover, multi-hop may be the only alternative for
autonomous motes used to measure and monitor specific instance in wildlife monitoring application covering very
physical or chemical environmental magnitudes, and to send large areas with a few base stations or LLNs located in

Authorized licensed use limited to: TEL AVIV UNIVERSITY. Downloaded on November 16,2023 at 14:47:58 UTC from IEEE Xplore. Restrictions apply.
978-1-5386-3839-2/17/$31.00 ©2017 IEEE
 2017 IEEE 13th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob)

the mountain or other environment where path loss is high. particular, for the 868 MHz band, the Duty Cycle (maxi-
More generally, multi-hop can increase the amount of data mum transmitter activity time, expressed as a percentage) is
sent or reduce the time needed to send the same amount of limited to a maximum of 1% of the time.
data by using lower LoRa Spreading Factors (SFs). The LoRa PHY layer is especially interesting since several
In this paper we present an adaptation to the typical parameters can be configured in order to optimize wireless
protocol stack for LLNs to enable RPL-based multihop data transmission. Table II shows the most important recon-
communications on top of LoRa [3], calculating the optimal figurable parameters, being bandwidth, transmission power
per-link Spreading Factor (SF). On the one hand, we propose and spreading factor.
a modification of one of the standardised RPL Objective
Table II
Functions (OF0) in order to compute rank, using the selected L O R A PHY C ONFIGURABLE PARAMETERS
LoRa SF as routing metric. On the other hand, we propose
a MAC mechanism to select the optimal SF per link. The Values
Spreading Factor 6 to 12
proposed implementation is realized in in the well-known Bandwidth 125kHz, 250kHz and 500kHz
open-source ContikiOS. Transmission Power -1dBm to 14dBm
The paper is structured as follows. Section II introduces
the technical LoRa radio specifications and its particularities. One of the most interesting features of LoRa is that it
Section III presents the RPL routing protocol. Section IV re- offers the possibility of trading throughput for link budget.
views the context and related work. Section V introduces the This can be done by adapting the Spreading Factor (SF),
different issues arising from having LoRa-based multihop with values ranging from 6 to 12, where each spreading
communications. Section VI introduces the proposed MAC factor is orthogonal. The combination of different frequen-
and RPL solution. A first validation test for the presented cies with different SFs defines what we call ”sub-channels”.
solution is included in section VII. Finally, section VIII The SF controls how many chips will be used to represent a
concludes and gives suggestions for future work. symbol. A symbol encodes SF bits in the LoRa modulation.
II. L ONG R ANGE (L O R A ) C OMMUNICATIONS The higher the spreading factor, the better the sensitivity and
the lower the throughput. An example of different sensitiv-
LoRa stands for Long Range. LoRa provides long-range, ities and corresponding throughput that can be achieved for
low-power and low-bitrate communications. LoRa is one of the SX1272 radiochip, in function of the bandwidth and the
the most popular Low Power Wide Area Network (LPWAN) spreading factor, is shown in Table III.
technologies today and was developed by Semtech.
LoRa is the combination of two distinct technologies: Table III
E XAMPLE OF L O R A PERFORMANCES WITH A 4/5 CODING RATE
the LoRa physical layer and the LoRaWAN MAC protocol. OBTAINED FROM [6]
The former specifies the physical modulation, whereas the
latter specifies a secure ALOHA-based MAC protocol. The Bandwidth Spreading Sensitivity Throughput
LoRaWAN specification can be particularly interesting for (kHz) Factor (dBm) (bps)
125 6 -122 9375
many IoT applications with low bandwidth requirements, 125 12 -137 293
allowing straightforward and cheap one-hop communication. 250 6 -119 18750
In this study, we will focus on the LoRa physical layer, since 250 12 -134 586
the LoRaWAN MAC is not used in the proposed solution. 500 6 -116 37500
500 12 -131 1172
The LoRa RF physical layer uses a kind of spread
spectrum modulation, called Chirp Spread Spectrum (CSS),
The drawback of achieving a better sensitivity is that the
which is a proprietary modulation technique. This CSS
symbol period increases with the spreading factor. Obvi-
modulation offers a good resilience to interference and is
ously, increasing the symbol period implies that the time
Doppler-resistant [4] [5]. Depending on the geographical re-
on air and the power consumption will also increase. The
gion, it operates in different ISM bands. This is summarized
symbol period (Ts) can be calculated as follows:
in Table I.
Ts = 2SF /BW (1)
Table I
L O R A F REQUENCY BANDS where SF and BW are the selected spreading factor and
ISM Band
bandwidth, respectively. LoRa data rates range from 0.3
Europe 868 MHz kbps to 50 kbps, depending on the selected communication
North America 915 MHz settings. The Data Rate (DR) can be calculated as follows:
Asia 433 MHz
DR = SF ∗ (BW/2SF ) ∗ CR (2)
When working with radio technologies transmitting in where SF, BW and CR are the Spreading Factor, Bandwidth
ISM bands, some regulatory limitations should be met. In and Coding Rate, respectively.

Authorized licensed use limited to: TEL AVIV UNIVERSITY. Downloaded on November 16,2023 at 14:47:58 UTC from IEEE Xplore. Restrictions apply.
 2017 IEEE 13th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob)

III. T HE RPL ROUTING P ROTOCOL • Router: a node that is downward-routable, because it

sends DAO messages to announce its routes. It is a
The IPv6 Routing Protocol for Low-Power and Lossy
potential parent for other nodes since it also sends DIO
Networks (RPL) is defined in RFC 6550 [3]. RPL is the
messages to announce its routing availability.
protocol in charge of finding multi-hop routes to reach
• Leaf: a node that cannot be chosen as a parent by other
every destination within a LLN. Figure 1 shows the typical
nodes. Leaf nodes do not transmit DIOs to announce
protocol stack for Low-Power and Lossy Networks (LLNs)
themselves as a potential parent. They may, however,
using RPL and 6LoWPAN. It depicts the typical use of RPL
issue DAO and DIS messages. Leaf nodes always have
on top of IEEE 802.15.4 MAC and PHY layers.
infinite rank (0xFFFF).
Application Layer A. RPL routing metrics
The RPL routing protocol is basically a generic Distance
UDP
Vector protocol, that leaves the process of route selection
IPv6 to an external mechanism called Objective Function (OF).
6LoWPAN An Objective Function defines how nodes select parents and
RPL
how they translate one or more metrics and constraints into a
value called Rank. The Rank indicates how close to the root
MAC (IEEE 802.15.4) a node is: the higher the rank, the further away the node is
from the DODAG root. Each DODAG must use a common
Radio Duty Cycling
OF.
PHY (IEEE 802.15.4) Only two OFs have been standardized in two RFCs.
RFC 6552 [7] defines the Objective Function Zero (OF0),
Figure 1. Typical protocol stack for a multihop LLN. which minimizes hop count to sink. RFC 6719 [8] defines
the Minimum Rank with Hysteresis Objective Function
RPL is designed to meet the requirements of LLNs. (MRHOF). MRHOF is used to minimize a certain metric
LLNs feature nodes with limited memory and processing (e.g. latency or Expected Number of Retransmissions), while
capabilities, usually battery-powered and connected by lossy using hysteresis to prevent route changes caused by small
links with low data rates. RPL creates a Destination Oriented metric changes. According to [8], each node obtains its path
Directed Acyclic Graph (DODAG). In a DODAG, nodes cost by summing up the selected link cost to the path cost
are organized in a hierarchical way, forming a configuration advertised by the parent.
that converges at the root node. RPL provides routing paths In most studies, MRHOF with the Expected Number of
in both directions: from the nodes to the root (upwards) Retransmissions (ETX) as a routing metric is used. ETX is
and from the root to the nodes (downwards). To create the average number of retransmissions of a packet at the
the DODAG, RPL uses Internet Control Message Protocol CSMA level. In every node, the ETX value is computed
version 6 (ICMPv6) control messages. The three basic types for each neighbor as a moving average. By minimizing
of RPL control messages are: ETX, power consumption and packet end-to-end latency are
implicitly minimized by reducing the number of retransmis-
• DODAG Information Object (DIO): It contains the
sions necessary to transmit a data packet successfully.
information that allows a node to discover a RPL
Instance, learns its configuration parameters, selects IV. C ONTEXT
a DODAG parent set, builds and maintains upward
To the best of our knowledge, and since it is a relatively
routes.
novel technology, there have been few research publications
• DODAG Information Solicitation (DIS): This type of
on the multihop LoRa topic. The studies published so far
message may be used to solicit a DIO from a RPL
mainly focus on range studies and analyse the limits of
node.
LoRaWAN. For instance, the authors in [9] [10] evaluate
• Destination Advertisement Object (DAO): These mes-
the range of LoRa radio communications, in different sce-
sages are necessary in order to build and maintain
narios. Furthermore, the authors in [9] have presented a
downward routes.
channel attenuation model. A study regarding the limits of
Depending on its functionality, a node can play different LoRaWAN is described in [2]. The authors in [4] provide a
roles in a RPL network: comprehensive and detailed analysis of the LoRa modulation
• Root: node that triggers the construction of the and present a testbed built to study the performance of
DODAG, by sending the first DIO message announcing LoRaWAN communications. They also raise the question
its availability as a parent. All upward routes in the of the suitability of some state of the art routing protocols
DODAG are oriented towards the root node. (such as RPL) for LoRa.

Authorized licensed use limited to: TEL AVIV UNIVERSITY. Downloaded on November 16,2023 at 14:47:58 UTC from IEEE Xplore. Restrictions apply.
 2017 IEEE 13th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob)

Some LoRa-based deployments have already been rolled for the LoRaMote platform, a demo platform featuring
out. The authors in [11] present a bicycle tracking system Semtech’s SX1272 radio transceiver [14].
based on LoRaWAN communications. The authors in [12] The proposed Contiki-based protocol stack is depicted
also propose a LoRa-based Sailing Monitoring System, in Figure 2. We make use of the µIP stack implemented
proving that it meets the basic application requirements. in Contiki, including UDP, IPv6, 6LoWPAN and the RPL
Related to multihop LoRa-based solutions, only one pro- routing protocol. The standard MAC layer typically used
tocol has been proposed in the literature. This protocol for (see Figure1) is replaced by the proposed MAC protocol,
LoRa transceivers is called LoRaBlink. It supports multi- called the RPL+LoRA MAC protocol (RLMAC). Finally,
hop bidirectional communications, and is described in [13]. the LoRa PHY layer is used to transmit the data over long
This seems an interesting first step towards extending LoRa distances wirelessly.
communications with multihop mechanisms. However, the
proposed solution works with a fixed Spreading Factor. Application Layer
mIP
V. M ULTIHOP L O R A
UDP
Multi-hop communications offer a higher degree of redun-
dancy and provide means to improve reliability in lossy net- IPv6
works. By using multi-hop communications, the geograph- 6LoWPAN
ical density of gateways can be decreased and alternative RPL
routes can be provided in case of gateway outage.
However, the RPL routing protocol has no provisions RLMAC
for selecting PHY layer parameters (such as LoRa’s SF).
LoRa PHY
Therefore, a new MAC mechanism is proposed in this paper
in order to find the optimal SF per link. The selected SF is
Figure 2. Proposed Contiki-based protocol stack for LoRa multihop.
then used in the OF used by RPL to compute link cost, to
be able to choose the preferred parent. The proposed RLMAC layer and the adaptations made in
This presents some additional challenges. In LoRaWAN, RPL will be presented in detail in the following sections.
messages are always exchanged between a LoRa concen-
trator acting as gateway and a mote. The concentrator can VI. P ROPOSED SOLUTIONS
demodulate packets from different sub-channels (defined by As explained earlier, a multi-hop LoRa network could
frequency, SF and BW) simultaneously, making it possible have a full base-station acting as RPL node but this paper
for default LoRaWAN devices to send at any time, on focuses on the more complex scenario in which all the
whatever sub-channel. In our multi-hop network, however, nodes (root, routers and leaves) have a radio that can listen
the nodes can only listen to one sub-channel at a time. to one sub-channel at the time (e.g. Semtech’s SX1272/6).
Therefore, the nodes need to agree on time slots dedicated The first challenge of multi-hop is the discovery of the
to certain sub-channels with their neighbours in order to neighbours. In order to simplify the problem, we consider
successfully transmit the data. that all devices use the same frequency and bandwidth. The
In order to enable RPL-based multihop communications, proposed mechanism aims at choosing the optimal SF.
the ContikiOS was chosen. Contiki is a lightweight, open-
source OS designed to operate on IoT devices. It is particu- A. Neighbour discovery and SF selection
larly interesting because it includes implementations for the In order to select the optimal SF per link, the process
most important and well-known communication protocols is split in two distinct phases: neighbor discovery and SF
for LLNs. Specifically, it provides IPv6-based conectivity by selection. Three ideas were considered for both phases at
means of its 6LoWPAN (IPv6 over Low-Power and Lossy MAC layer:
Networks) implementation, along with an implementation • All devices initially use SF12. This is the most basic
of the RPL routing protocol and its standardised OFs. solution, however it presents several disadvantages:
Additionally, Contiki also provides support for well-known the messages will be sent with the slowest data rate,
(lightweight) application layer protocols (CoAP, MQTT). increasing the power consumption and the risk of
The implementation of all these communication protocols collision due to the long time-on-air and the augmented
is developed in a platform-independent way. This approach transmission range. The devices will need additional
makes it possible to run the implemented protocols in any control messages to agree on the optimal SF for the
platform supported by the ContikiOS in a straightforward links they are involved in.
manner. Therefore, the necessary support for including the • Synchronized timeslots. The nodes have access to a
LoRa PHY layer was the first step to enable standardised global clock, for instance, from a GPS module included
multihop communications based on LoRa. This was done in the motes. This would allow for all of them to try

Authorized licensed use limited to: TEL AVIV UNIVERSITY. Downloaded on November 16,2023 at 14:47:58 UTC from IEEE Xplore. Restrictions apply.
 2017 IEEE 13th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob)

Router sending DIOs: fast loop

T
SF7 SF8 SF9 SF10 SF11 SF12 SF7 SF8 SF9 SF10 SF11 SF12 SF7

Match 1 Match 2
Node listening: slow loop

SF7 SF8

6T
Figure 3. Timeline of the SF loop method for a router node and a node waiting to join

Yes
the different SFs in a more time-efficient way, but with
Root ? Fast loop
a high the risk of interference.
• SF loops. The routers are configured to listen to each
No
SF (7 to 12) during a time-slot of T seconds, the
nodes that need to join the DODAG do the same with
slots nSF (the number of different SFs, 6 in this case) Slow loop
times longer, as shown in Figure 3. After n2SF · T, we
DIO
ensure that two neighbours have met once for each
SF. This method makes the discovery longer but avoids Wait SF = max
collisions. This method allows to select the optimal SF Disconnected
as soon as a new neighbor is discovered, provided that
the fast loop of the RPL router began before the start Yes
of the slow loop of the other device. Router ? Fast loop

The first method scales poorly due to collisions and

No
requires extra control traffic. The second solution is not
always suitable, since it requires a GPS signal, which may Disconnected
not always be available (for instance, for indoor or deep No loop
indoor applications). Therefore, the selected method is the
SF loops. Even though it is slow, this mechanism allows Figure 4. SF loop device state
to build a network directly with the lowest achievable SF
(so highest bitrate) on each link, optimising time-on-air and
saving power. It also reduces the probability of collisions could run below RLMAC (RDCs are out of the scope of this
with compared to the other two methods. article).
1) Timing issues:
B. RLMAC A device using RLMAC needs to know the SF fast loop
We propose the RLMAC protocol to allow multi-hop over interval (T seconds) and the list of used SFs, as well as the
LoRa devices. bandwidth, default frequency and Forward Error Correction
Figure 4 shows the state of the devices during discovery (FEC) coding rate used. It also needs a timer (the SF
and after having joined the DODAG. Their state depends on timer), that starts at the same moment as the SF loops,
whether the node is a RPL root, a router or a leaf node. and resetting after nSF · T seconds. RLMAC relies on that
RLMAC handles LoRa neighbours and delays the trans- timer and a g̀ood enough’ approximation of the time offsets
mission of packets to the right SF slot of a parent or child. (see Equation 3) with respect to its neighbors to schedule
It includes MAC commands to manage the links. After the transmissions.
SF loop discovery, router nodes switch to fast loop and leaf At the reception of a valid DIO, a node adds its LoRa
nodes only listen to their preferred parent’s SF. This change parent as well as its RPL parent. The parent can send the
of state (from slow to fast loop or no loop) only occurs after current value of its SF timer (tDIO,A ) in the MAC header
the end of the slow loop. Doing so, the node will discover of the message containing the DIO (we call that ‘explicit
as many parents as possible by listening to all available SFs. mode’) and the child can then compute the true timing offset
RLMAC does not schedule messages at a precise moment, between them. Otherwise, in the so called implicit mode, the
but within the right time slot (order of magnitude of tens of child assumes that the DIO was sent at the beginning of the
seconds). A Radio Duty Cycling protocol suited for LoRa slot. It makes an approximation of the parent’s SF timer

Authorized licensed use limited to: TEL AVIV UNIVERSITY. Downloaded on November 16,2023 at 14:47:58 UTC from IEEE Xplore. Restrictions apply.
 2017 IEEE 13th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob)

A SF7 SF8 SF9 SF7 SF8 SF9 SF7 SF8 SF9

T = 40s 25s

DIO
Approximation
of A in B SF9 SF7 SF8 SF9 SF7 SF8 SF9
Approx
offset(B,A) = 10

B SF9 SF7 SF8 SF9 SF7 SF8 SF9

True
offset(B,A) = -15
Approximation
of B in A SF7 SF8 SF9 SF7 SF8 SF9

Figure 5. Time slots of two neighbor router nodes and approximations

value following the formula: MAC.send()

tDIO,A ' (SFlink − SFmin ) · T + T oA(SFlink , L) (3) multicast address ?

Yes
RDC.send()

Where SFlink is the Spreading Factor used to send the No

DIO, SFmin is the lowest SF and T oA is the time on air
No
for a DIO message of length L. Compared to the magnitude Address in
neighbour list ?
RDC.send()
of these intervals, which is in the order of seconds, the time
Yes
to process the message can be neglected.
The estimation error on tDIO,A in implicit mode can be as
SF(neighbour) = SF(link) Yes set_sf(SF(link))
large as T , which has a very negative impact on the ability OR RDC.send()
INFINITE offset
to schedule messages correctly. Figure 5 shows that a child
No
receiving a DIO at 25 seconds into a 40 seconds time slot
will use the previous parent’s SF for 62.5% of the time. A queue(packet)
delay = get_delay (SF, offset)
ctimer expires

node could consider only a portion of the parent’s timeline ctimer_set(delay)

as reliable. Another way of avoiding this negative effect is

to forbid routers to send implicit DIOs after a certain time Figure 6. Execution of the RLMAC send packet function
in a time slot.
A parent never computes its offset in respect to a child
by itself. It will wait for a MAC command containing that right time slot. This should not be done systematically as
offset, which is the opposite of the child’s offset if the child too many messages would be sent with the highest SF in a
is a router, and ”infinite offset” (0x7FFF) if it is a leaf node. dense network.
A neighbor listed with a valid SFlink and an infinite offset 2) MAC commands:
can be reached with that SF at any time from the MAC The MAC commands are used to enable the timing of
layer’s perspective. For instance because it is a leaf node and RLMAC and manage the physical parameters to be used by
only listens to the SF of the link with its preferred parent. nodes, much like in LoRaWAN MAC. The header should
Figure 6 summarize the execution of the send packet consist of the receiver and sender link addresses, a single
function in RLMAC. Broadcast and unicast packets to octet Command ID (CID) and 0 to 2 bytes of parameters,
unknown addresses are sent right away, with the current SF. depending on the Command.
Unicast messages to the LoRa neighbors are sent only if The first two commands have already been discussed:
that neighbor is currently listening to the right SF, otherwise advertisement of the sender’s SF timer and of the link offset.
the packet is queued and a callback timer will trigger its Each value is sent as a 16-bit integer (time in seconds). In
transmission after a certain delay. This introduces a MAC addition to those, three pairs of request/ACK commands are
queue that could fill up and force the device to drop packets. needed to:
Since all the routers stay in the fast loop state, a node can • Change SFlink .
always decide to send a packet at higher SF than SFlink • Change the transmission power used.
to avoid waiting several seconds for getting access to the • Change the channel used by a leaf node.

Authorized licensed use limited to: TEL AVIV UNIVERSITY. Downloaded on November 16,2023 at 14:47:58 UTC from IEEE Xplore. Restrictions apply.
 2017 IEEE 13th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob)

A different channel can only be used to send messages than its previous value plus a constant, except to become
to a leaf, as routers need to keep the connection to multiple INFINITE RANK. Note that INFINITE RANK is the rank
neighbors, on the default frequency. of all leaf nodes.
A last feature that could be included in the MAC layer This method aims at minimizing the total time on air
is the Open Specific Window (OSW), that also needs com- for a packet traveling from a node to the RPL root. Since
mands for requests and ACKs. An OSW request asks to all nodes are limited to 1% duty cycle per channel, more
listen for different SF, channel and bandwidth than the ones data can be sent in the network if the fast links (links with
defined by the loop, after a given delay. That command lower SFs) are chosen, and bottlenecks appear less often. A
allows for a whole new mode of operation: the receiver sets router close to the root may end up with too many children.
its radio to the parameters asked by the sender, although the Therefore, a second metric, denoted ǹode availability’, could
default mode of operation is the sender waiting for the right be introduced to limit the risk of every route going through
time in the loop. the same node. That is especially true for a router that needs
With the current state of RLMAC, the acceptance of an to send a lot of data, thus will not have a lot of opportunities
OSW means losing a part of a time slot, as the radio of to forward the children’s packets.
the router is reconfigured for different PHY parameters, and
possibly missing some packets. That issue could be solved VII. VALIDATION
by having one or several gaps in the fast loop that are In order to validate the correct functioning of the proposed
available for OSW packets, for instance a gap of 5 second solution, a small network consisting of 4 LoRaMotes was set
at the end of each slot. up in an office building on campus. One of the LoRaMotes
was configured as RPL root, and the other motes were
C. Objective Function for LoRa
configured as RPL routers. Each node was located in a
A new Objective Function was needed to compute the different floor of the building: the root node was located
nodes’ ranks in our multi-hop LoRa network. RFC6551 on the 4th floor, and the other nodes were located on the
gives a list of link and node metrics - as well as constraints - 2nd , 1st and ground floor respectively.
that can be used by an OF. Using the LoRa modulation, the The parameters used were: SFs from 7 to 10, fast loop
data rate is be twenty times faster with the lowest SF than time slots (T ) are 15 seconds long and a maximum MAC
with the highest. Therefor, the link cost is made proportional queue length of 5. The nodes were configured to send 82-
to the duration (time on air) of one bit: bytes UDP frames containing RPL-related information (e.g.
rank and preferred parent) every 30 seconds.
linkCost ∝ 2SFlink −SFmin (4) The network topology obtained is shown in Figure 7, with
A node selects its preferred parent to minimize the the SF of the links as selected by the discovery.
path cost, i.e. rank(parent) + linkCost, then it com-
putes its own rank as rank(parent) + rankIncrease.
The rankIncrease has to be in the [minRankIncrease, 9 · 4th floor
minRankIncrease] interval, otherwise the parent is not
considered valid. The implementation uses integer multiples 3rd floor SF 7
of minRankIncrease for the ranks computation. Table IV
shows the values used in this paper. The ranks will always SF 7
2nd floor
advertise a lower value than the real path cost.
Table IV SF 9
RPL RANK INCREASE AND PATH COST FOR ALL SF 1st floor

SF rank increase link cost

7 1 1.22 Ground floor RPL Root
8 2 2.13
9 3 3.79 RPL Router
10 6 6.82
11 9 12.41
12 9 22.75 Figure 7. RPL network topology

If SFlink is modified later on through the exchange of Some unexpected behavior was found while performing
the adequate MAC commands, the rank can be changed this first test. As shown in Figure 7, two nodes selected SF7
accordingly, as long as it respects the two rules set by RPL. to communicate with the root node. Since both nodes made
These rules dictate that the rank of a node may not become this choice after having received the same broadcasted DIO
less than any parent’s rank, and it may not become more message, they were always sending queued messages at the

Authorized licensed use limited to: TEL AVIV UNIVERSITY. Downloaded on November 16,2023 at 14:47:58 UTC from IEEE Xplore. Restrictions apply.
 2017 IEEE 13th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob)

exact same time, which led to frequent collisions. This issue (Vlaio), under the project HBC.2016.0101 - Horizontal-IoT.
could be solved by adding an additional random delay for
R EFERENCES
the queued packets at the MAC layer.
That feature was added using a feature of the LoRa radio [1] X. Xiong, K. Zheng, R. Xu, W. Xiang, and P. Chatzimisios.
Low power wide area machine-to-machine networks: key
itself: generating random values based on a 1-millisecond
techniques and prototype. IEEE Communications Magazine,
RSSI measurement. After that modification, the sink could 53(9):64–71, sep 2015.
receive packets from multiple neighbors using the same SF.
The MAC layer was also modified to send packet only 70% [2] F. Adelantado, X. Vilajosana, P. Tuset-Peiro, B. Mar-
of the time slots (the 70% at the beginning of the slot tinez, and J. Melia. Understanding the limits of Lo-
RaWAN, CoRR, vol. abs/1607.08011, 2016. [Online]. Avail-
when sending to parents and those at the end of the slot able: http://arxiv.org/abs/1607.08011.
when sending to children) to limit the effect of bad offset
estimation described in figure 5. [3] N. Sornin, M. Luis, T. Eirich, T. Kramp, and O.Hersent.
In a new test including only 2 motes, the PDR was LoRaWAN Specification, 2015.
measured on a link using SF8 with the updated software: 43 [4] A. Augustin, J. Yi, T. Clausen, and W. Townsley. A Study of
packets were correctly received out of 50, yielding a 86% LoRa: Long Range & Low Power Networks for the Internet
PDR. Part of the packet loss is due to the sender that was of Things. Sensors, 16(9):1466, sep 2016.
scheduling transmissions too close to each other. This can
[5] T. Wendt, F. Volk, and E. Mackensen. A benchmark survey
be fixed by checking the state of the radio before trying to of long range (LoRaTM) spread-spectrum-communication at
send. 2.45 GHz for safety applications. In 2015 IEEE 16th Annu.
The performance of the protocol will get worse when Wirel. Microw. Technol. Conf., pages 1–4. IEEE, apr 2015.
more SFs and longer slots are used or messages are sent
[6] Semtech. Datasheet: SX1272/73 - 860 MHz to 1020 MHz
more often, as all packets are dropped once the MAC queue Low Power Long Range Transceiver, 2015.
is full.
[7] P. Thubert. RFC 6552 - Objective Function Zero for the
VIII. C ONCLUSIONS
Routing Protocol for Low-Power and Lossy Networks (RPL),
Enabling multi-hop with RPL on LoRa devices is a chal- 2012.
lenging issue. To deal with this, a new MAC protocol called
[8] O. Gnawali and P. Levis. RFC 6719 - The Minimum Rank
RLMAC has been proposed. It features an asynchronous with Hysteresis Objective Function, 2012.
discovery mechanism of neighbor nodes and offers the
possibility for a node with a small radio to act as a router, [9] M. Aref and A. Sikora. Free space range measurements with
thanks to time slots dedicated to different SFs. This allows to Semtech LoRa technology. In 2014 2nd Int. Symp. Wirel.
select the optimal SF per link, optimizing the time on air as Syst. within Conf. Intell. Data Acquis. Adv. Comput. Syst.,
pages 19–23. IEEE, sep 2014.
well as the power consumption. The protocol includes MAC
commands (some directly inspired by LoRaWAN MAC) to [10] J. Petajajarvi, K. Mikhaylov, A. Roivainen, T. Hanninen, and
manage the LoRa neighbors. By default, a node sending a M. Pettissalo. On the coverage of LPWANs: range evaluation
packet does the effort of waiting for its neighbor to be in and channel attenuation model for LoRa technology. In 2015
14th Int. Conf. ITS Telecommun., pages 55–59. IEEE, dec
the right time slot. The proposed MAC commands, allow 2015.
the sender to open a receive window with specific SF. This
feature can be useful in applications in which messages need [11] D.H. Kim, J.B. Park, J. H. Shin, and J.D. Kim. Design and
to be received with the lowest possible delay. implementation of object tracking system based on LoRa.
In 2017 International Conference on Information Networking
A new Objective Function has been proposed for RPL, in
(ICOIN). IEEE, jan 2017.
order to compute the path cost, based on the selected SF for
the given link. [12] L. Li, J. Ren, and Q. Zhu. On the application of LoRa
A small RPL network was deployed on campus, in order LPWAN technology in Sailing Monitoring System. In 2017
to validate the correct functioning of the proposed solution. 13th Annual Conference on Wireless On-demand Network
Systems and Services (WONS). IEEE, feb 2017.
Some unexpected behavior was found, and a solution adding
an additional random timer is proposed. [13] K. Romer, K. G. Langendoen, and T. Voigt. LoRa for the
Before considering the use of RLMAC in real life, a Internet of Things. In Proc. 2016 Int. Conf. Embed. Wirel.
simulation tool would be needed to test its performance for a Syst. Networks, pages 361–366, Graz, Austria, 2016. Junction
Publishing.
larger number of nodes and evaluate the power consumption
of routers and leaf nodes. [14] S. Thielemans, M. Bezunartea, and K. Steenhaut. Establishing
transparent IPv6 communication on LoRa based Low Power
ACKNOWLEDGMENT
Wide Area Networks (LPWANS). In 16th Annual Wireless
This work is partially supported by the TETRA grant Telecommunications Symposium, Chicago, EEUU, apr 2017.
of the Flanders Innovation and Entrepreneurship agency IEEE.

Authorized licensed use limited to: TEL AVIV UNIVERSITY. Downloaded on November 16,2023 at 14:47:58 UTC from IEEE Xplore. Restrictions apply.