Workshop on ns-3 - WNS3 2018 - ISBN: 978-1-4503-6413-3

Surathkal, India - June 13-14, 2018

A LoRaWAN Module for ns-3: Implementation and Evaluation

Brecht Reynders Qing Wang Soie Pollin
KU Leuven KU Leuven KU Leuven
Leuven, Belgium Leuven, Belgium Leuven, Belgium
[email protected] [email protected] [email protected]

ABSTRACT This all thanks to the powerful physical layer technology of LoRa
Long Range (LoRa) communication has been proposed to connect that trades of range with throughput.
massive numbers of devices in large areas. LoRa itself is a physical Together with the growing interest from industry, there is also
layer technique. Together with the MAC layer solution LoRaWAN an increasing interest from academia not only to exploit the per-
to realize IoT, they have attracted increasing attention from both formance and scalability of LoRa networks, but also to improve
industry and academia. In this work, we present our implemented LoRa’s reliability. LoRa itself is a physical layer technique. To build a
LoRaWAN module for ns-3, to help boost the research in this ris- complete communication system, the MAC layer protocol LoRaWAN
ing area. Our implementation is compliant with the class A of has been proposed which can work well with LoRa. However, due
the LoRaWAN 1.0 speciication. It is highly conigurable and thus to the complex network topology and the ALOHA nature of the Lo-
can be easily used to exploit the impact of diferent parameters RaWAN MAC protocol, closed-form equations, e.g. the packet error
on LoRaWAN’s performance. Our implemented lexible backbone rate for ALOHA access, are insuicient to analyze the network’s
architecture also allows for the easy integration of new protocols performance in a wide range of scenarios. Simulation is an elegant
to improve the network performance. In the past two years, we tool and can provide an easy way of demonstrating the impact of
have used this module to develop new protocols and algorithms to certain parameters on the network performance. In LoRa, these
improve LoRaWAN’s performance, in terms of reliability, capture interesting parameters include acknowledgment response time,
efect, scalability, power consumption, among others. Our research spreading factors and bandwidths. The impact of these parameters
outcomes have demonstrated the usefulness, lexibility, and conig- could be easily done with a network simulator.
urability of the proposed LoRaWAN ns-3 module. We have made With this in mind, we propose a new long range, low power
the source code of our module publicly available1 . module for ns-3. Our model is compliant with the LoRaWAN v1.0
class A speciication [20]. It is highly conigurable to study the
CCS CONCEPTS efect of diferent parameters on the network performance. The
lexible backbone architecture allows for easy integration of new
· Networks → Network simulations;
protocols not only to improve the random access performance of
these networks, but also to study what will happen if a backbone
KEYWORDS
server is congested. One of our main contributions in the model
LoRa, LoRaWAN, ns-3 model, lexible, implementation, evaluation is that it supports distributed gateways. These gateways are con-
ACM Reference Format: nected over an IP network to the network server that controls the
Brecht Reynders, Qing Wang, and Soie Pollin. 2018. A LoRaWAN Module whole network. We also provide base classes that allow for an easy
for ns-3: Implementation and Evaluation. In Proceedings of the 2018 Workshop implementation of new applications in the network server.
on ns-3 (WNS3 2018), June 2018, Surathkal, India. ACM, New York, NY, USA, The remainder of this work is as follows. In Section 2, we in-
8 pages. https://doi.org/10.1145/3199902.3199913
troduce the LoRaWAN ecosystem and the state of the art. We also
highlight the diferences between our model and other solutions. In
1 INTRODUCTION Section 3, we describe the implementation in details. Then, in Sec-
Within the Internet of Things, Long Range (LoRa) communication tion 4 we present some simulation results to show the performance
has received a lot of attention. Due to its capability of supporting of our model. Finally, we conclude the work in Section 5.
long communication range, LoRa can ill the gap between mobility
and low power. With this paradigm, it is possible to track cars and
people with coin cell batteries and monitor power consumption on
2 BACKGROUND AND RELATED WORK
the electric grid in real-time, even in remote places like basements. 2.1 The LoRaWAN Ecosystem
1 https://github.com/networkedsystems/lora-ns3.git LoRaWAN is an open source MAC protocol developed around LoRa.
The LoRaWAN architecture consists of three important elements:
Permission to make digital or hard copies of all or part of this work for personal or nodes, gateways and the backbone, as illustrated in Figure 1. Similar
classroom use is granted without fee provided that copies are not made or distributed
for proit or commercial advantage and that copies bear this notice and the full citation to cellular networks, gateways connect nodes within their coverage
on the irst page. Copyrights for components of this work owned by others than ACM to the backbone. The diference is that gateways in LoRaWAN use
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, non-licensed ISM bands and target extremely at low power and
to post on servers or to redistribute to lists, requires prior speciic permission and/or a
fee. Request permissions from [email protected]. long range communications. In LoRaWAN, nodes typically only
WNS3 2018, June 2018, Surathkal, India have a few messages to transmit per day.
© 2018 Association for Computing Machinery. Depending on the application scenario, LoRaWAN nodes can be
ACM ISBN 978-1-4503-6413-3/18/06. . . $15.00
https://doi.org/10.1145/3199902.3199913 conigured into three diferent types:

61
 A LoRaWAN Module for ns-3: Implementation and Evaluation
B. Reynders, Q. Wang, S. Pollin

Sensor Server

Customer Application Customer Server Logic

(LoRaApplication) Gateway (LoRaNetworkApplications)

LoRaNetDevice
Packet forwarding LoRaWAN Master
LoRaWAN Slave
(LoRaGatewayApplication) (LoRaNetworkServer)

LoRaWAN MAC Backhaul IP network

LoRaWAN MAC Backhaul IP Stack
(LoRaGwNetDevice) IP Stack

LoRa
LoRa PHY layer (LoRaPhY) LoRa PHY layer (LoRaGwPhY)

Figure 1: The structure of a LoRaWAN network according to the LoRa Alliance [1]. The sensor on the left is connected to
the network server on the right. It sends the sensing data to the Gateway using the LoRa technique over long distance. At
the Gateway, a higher-throughput IP network takes over and forwards all the data to the network server. In this work, we
present implementation of the above structure in ns-3 as a LoRaWAN module, to help boost the research in this rising area.
The corresponding classes we implement are highlighted in italics in the above structure

• Class A: Sensor nodes only send small number of data packets 1-persistent MAC. The LoRaWAN MAC layer also provides a way
to the gateway and sleep for most of the time. for reliable communication: with acknowledgments or conirma-
• Class B: Except for the actions in Class A, sensor nodes also tions. In the case that a conirmed message has been transmitted
wake up at scheduled slots to receive downlink messages. by a node, the gateway is obliged to acknowledge this message.
• Class C: Sensor nodes always listen to the channel. However, in the unconirmed case, a gateway sends acknowledg-
To enable long range communication, LoRa uses chirp spread ments at will. These acknowledgments are not compulsory, but
spectrum with diferent Spreading Factors (SFs) to trade of data conirm a proper working connection between a node and the rest
rate for extra range. These spreading factors specify the chirp rate. of the network. If a conirmation is not received, the MAC layer can
In the speciication of LoRa, the SF can be selected from SF7 to decide to switch to more robust modulation schemes by selecting a
SF12.2 A lower SF chirps faster over the bandwidth and, as a result, higher spreading factor or decreasing the bandwidth.
symbols are shorter. This leads to a higher transmission rate and 2.1.2 Network Server. An important part of the network which
shorter transmission time, but requires a higher SNR. It should be is often neglected is the backbone, as visualized in Figure 1. The
noted that a lower SF results in a shorter communication range. left part of the igure shows the long range low power network
2.1.1 MAC Protocol (for Class A). In LoRaWAN, next to the long and sensor discussed in the irst part of this section. The right part
range, power eiciency is very important and the MAC protocol shows the backbone structure. The gateways collect all information,
plays an important role in this aspect. In addition, the MAC layer control and data from the LoRa network and forward this to the
also sets the boundaries of network scalability and mobility. In network server. The network server on its turn, selects the correct
LoRaWAN, the most energy eicient method has been selected to parameters to use, performs localization and forwards data to re-
send data to the gateway, i.e. random access. Whenever a node has mote backends of customers. To date, the most well-known network
data, it sends its data immediately without sensing the channel irst. server is the network server from The Things Network [2] that
The transmission parameters are selected by the node itself, and provides a free and open source network to connect LoRa sensors.
from the node’s point of view, suicient to communicate with the Many other vendors also exist. Note that although a gateway has a
gateway. powerful receiving chip, it is not capable of adding intelligence to
After each transmission, two downlink slots are available for the the network. This capability is provided at the network server.
gateway at ixed time instances: the irst slot at least one second
after the transmission and the second slot exactly one second after 2.2 Related Work
the irst. The gateway picks one of the two slots for transmission. Many work has been done in estimating the performance of LoRA
The communication parameters of this slot, like spreading factor networks, such as [3, 4, 11]. Although their conclusions are inter-
and bandwidth, depend on the agreement between the node and esting, they only use a simpliied MAC protocol. This calls for a
the gateway. The irst slot uses lower spreading factors most of the powerful network simulator that is useful to study the real network
time and requires less time on air, while the second slot uses more performance.
reliable parameters. Several simulation tools have been proposed for LoRaWAN. The
most well-known LoRaWAN simulator is the LoRaSim built with
2 Inthis work, the deinition of spreading factor from the LoRa community is used python [5, 21]. It is open source and gives great insights in the
rather than the typical deinition of spreading factor: chip rate over symbol rate. LoRaWAN performance. However, LoRaSim does not implement

62
 Workshop on ns-3 - WNS3 2018 - ISBN: 978-1-4503-6413-3
Surathkal, India - June 13-14, 2018

Figure 2: Our implemented LoRaWAN model in a uniied modeling language (UML). We present all the relevant classes for
the LoRaWAN implementation. The highlighted functions and variables are the important parts for the hierarchy

acknowledgments. Thus, it cannot be used to study the network factors [15], the efect of interference [14], the reliability and scal-
performance where nodes switch their spreading factor based on ability [17], etc. Our model can also be used to study the efect of
the feedback or absence of feedback from the gateway. Similarly, an downlink messages [13] and multiple gateways [6, 21].
Omnet++ implementation has been proposed in [19]. It implements
an Automatic Data Rate (ADR) scheme where nodes can update 3 IMPLEMENTATION
their spreading factor and power at runtime. In this section, we present the implementation details of our Lo-
For ns-3, two diferent modules have been proposed in liter- RaWAN ns-3 module. We start from the physical layer, then the
ature. The authors in [10] proposed a complete LoRa module. It MAC layer and inally the application layer3 . Our implemented
features MAC commands, diferent overlapping networks and multi- PHY and the MAC layers are connected to the standard ns-3 call-
gateway support. Besides these interesting features, this module backs to communicate with the remainder of the network stack. It
has some drawbacks. First, it can only send LoRa messages, so it allows us to reuse a signiicant amount of the code within the ns-3
is impossible to simulate the efect of interference. Next, similar framework. A helper class is provided to automatically connect all
chirp rates do not have efect on each other. Due to the chirp spread required callback functions. As a result, the LoRaWAN NetDevice
spectrum technique, spreading factor 9 with 125 kHz bandwidth has can easily be conigured with a default set of parameters, but these
a similar chirp rate compared to spreading factor 11 with a 250 kHz parameters can also be altered using the corresponding interfaces.
bandwidth. Another small drawback is that all the gateways in this
model are virtually directly connected to the network server, so the 3.1 Physical Layer
packets cannot be routed over IP.
Our physical layer is similar to lr-wpan [8] and is built upon the
Independently from the previous implementation, the authors
SpectrumPhy code. The standard interfaces for SpectrumPhy allow
in [6] have proposed their solution. Their proposal also supports
us to easily create a SpectrumChannel simulating the 868 MHz band
multiple gateways and overlapping networks. However, they did not
for LoRa traic. To allow fast simulations, we limit the spectrum of
include MAC commands. With their solution, interfering networks
this channel by the default LoRa Channels speciied in LoRa in the
are possible as they accept interference from any network working
868 MHz ISM band, being 868.1 MHz, 868.3 MHz and 868.5 MHz.
on the same channel and frequency. Also in this implementation, the
Packets on this channel are modeled as a subclass of SpectrumSig-
network is not connected to the IP layer, but directly to gateways.
nalParameters, where the spreading factor and bandwidth of this
Compared to the above models, our implementation is totally
signal are added as extra features. These parameters are required
compliant with the LoRaWAN v1.0 class A speciication. It is highly
during reception of this message.
conigurable. Its lexible backbone architecture allows for easy inte-
The physical layer consists of two classes: LoRaPhy, the physical
gration of new protocols. Our model supports distributed gateways
layer for a node, and LoRaGwPhy, the physical layer for a gateway.
that are connected over an IP network to the network server that
controls the whole network. We also provide base classes for the 3.1.1 Phy for Nodes. At each node, LoRaPhy keeps track of the
easy implementation of new applications on the network server and noise on all the channels and records which spreading factors have
new MAC commands. With this model, we have investigated many been used. It also checks if similar LoRa patterns are being used,
aspects of LoRa networks, such as the efect of diferent spreading
3 For better readability, the names of classes and functions are highlighted in italics.

63
 A LoRaWAN Module for ns-3: Implementation and Evaluation
B. Reynders, Q. Wang, S. Pollin

Figure 3: The inite state machine for the physical layer

for example, the chirp rate of a signal with SF9 and bandwidth
125 kHz is identical to the chirp rate of a signal with SF11 and
bandwidth 250 kHz. This similarity is a result of the chirp spread
spectrum modulation in LoRa. Whenever a new packet arrives,
LoRaPhy keeps track of the instantaneous signal-to-noise ratio of
this packet. This is diferent from the LrWpanPhy where only the
average SNR over the whole packet is considered. Keeping track
Figure 4: The inite state machine for the MAC layer
of this instantaneous SNR allows short high powered messages to
destroy a colliding message. So, with each new interfering signal
that arrives at this PHY layer, the bit errors are recalculated up
to that point using the formulas presented in [16]. When a mes-
3.2 MAC Layer
sage is inally successfully received, it is forwarded to the MAC Upon the physical layer is the LoRaWAN MAC protocol. The im-
layer for further processing. In the other direction, when a packet plementation of this layer is also divided into two diferent classes
is ready for transmission (forwarded from the data link layer to due to the diference between uplink and downlink. LoRaNetDevice
LoRaPhy), LoRaPhy will immediately try to send this packet. It is contains the implementation of the MAC layer of a node, while
the MAC layer’s duty to agree with the timings in LoRa. When the LoRaGwNetDevice implements the MAC layer for the gateway. Sim-
transmission fails for any reason, the data link layer is notiied. ilary to the case in the physical layer, the class LoRaGwNetDevice
Figure 3 shows the inite state machine for the physical layer of for the gateway is a derived class from the class LoRaNetDevice of
the node. LoRa messages are only decoded when the physical layer the node, as visualized in Figure 2.
is in RX mode. Transmission of packets is only possible when the
3.2.1 MAC for Nodes. The MAC layer of a node is simple. When-
physical layer is in TX mode. Whenever the physical layer is done
ever a message comes in, the node checks if there is a free channel
with the transmitting or receiving, it returns to the IDLE mode.
on which it can send out the message. This check needs to be done
3.1.2 Phy for Gateways. The implementation of the physical to comply with the duty cycle regulation from both the regulation
layer for gateways is slightly diferent from the physical layer for point of view [7] and the LoRaWAN restrictions [20]. If there is
nodes: a gateway is able to receive multiple packets simultaneously. a channel available, the node waits for a random delay and sends
Thus, a diferent PHY layer is required for gateways. However, since its message. If there is no channel available, the node waits for a
most parameters are identical to those used in the PHY layer for random delay and tries again. After each successful transmission,
nodes, the physical layer class for gateways LoRaGwPhy is imple- two receiving slots are opened for potential downlink messages. If
mented as a derived class of LoRaPhy, shown in Figure 2. The main the irst slot is used, the second downlink is automatically disabled.
diference between them falls into the receiving part. LoRaGwPhy Nodes can send two types of traic: conirmed or unconirmed
keeps a list of all incoming LoRa signals instead of only adding traic. The former traic retransmits the packet up to 8 times until
those to the noise. For each of these incoming LoRa signals, the bit the gateway responds with an acknowledgment, while the latter
errors are calculated. Notice that each incoming signal contributes traic transmits only once. In both cases, the two receiving slots are
to the noise loor of the other incoming signals, even when the opened for downlink messages. If an acknowledgment is expected,
signals use diferent spreading factors. In our implementation, a but not received, the MAC layer automatically retransmits the
gateway can track up to eight LoRa signals simultaneously due to message. For conirmed messages, the MAC layer also increases
the restrictions in hardware [18]. Transmitted messages are also the spreading factor every two lost acknowledgments to increase
handled as incoming messages as well. Uplink and downlink in reliability. For unconirmed messages, nodes will switch to a higher
LoRaWAN occur on the same channels and use the same modula- spreading factor as well. This happens after 96 unacknowledged
tion. Therefore, the self-interference of a gateway will destroy all messages. After 96 messages, the node assumes that communication
messages on that channel of that gateway [13]. That is, the gateway is not possible with the current spreading factor and switches to a
does not have any full-duplex capabilities. higher one. To warn the gateway that this deadline is approaching,
The inite state machine for the physical layer of the gateway a node transmits a lag after 64 non-conirmed messages.
is omitted due to its simplicity and its similarity to the one for the The above process is summarized with the inite state machine
physical layer of the node. shown in Figure 4. The device starts in the IDLE state. Whenever

64
 Workshop on ns-3 - WNS3 2018 - ISBN: 978-1-4503-6413-3
Surathkal, India - June 13-14, 2018

a new packet arrives, it waits at least a second before going to 3.3.1 Application Layer on the Node Side. The application on
TX. After the TX mode, there are 2 states waiting for a downlink the node side is a simple constant packet rate module that sends
message from the gateway. When the sequence is done, the device a message at regular intervals. The time of these intervals is con-
goes to the RETRANSMIT state to check if the packet needs to be igurable as well as the length of the messages on the channel. To
retransmitted or not or goes immediately to the IDLE state. If no skip the networking layer, the LoRaNetDevice is bounded with the
messages are in the queue, the MAC layer returns to the IDLE state. socket of this application.
3.2.2 MAC for Gateways. While a node uses a random access
approach to transmit its message to the intended receiver, the gate- 3.3.2 Application Layer on the Gateway and Backbone. The ap-
way makes use of a synchronized downlink. Whenever a node plication layer of LoRaWAN has been divided over multiple nodes.
transmits a message, at least 1 second later, the gateway can send This is similar to the real implementation of LoRaWAN. In this split,
its reply or message. Whenever a new message is received, each LoRaSinkApplication runs on each gateway, while LoRaNetwork and
gateway schedules these downlink slots. It is important that each LoRaNetworkApplications run on a diferent single node somewhere
gateway does this for the synchronization of the downlink. The in the network. The latter two applications run over an IP network.
received message then gets forwarded as a whole to the application
layer (explained in Section 3.3.2). In the meanwhile, the gateway LoRaSinkApplication. It is a translation application. It collects
waits for a response from the network server. If it replies with a all the messages received by the LoRa gateway, encapsulates it
message to discard the transmission, the scheduled slots are dis- in IP packets, and sends them to a remote server, and vice versa.
carded and the gateway continues its operation. In the other case, The remote server in our model is the LoRaNetwork. Besides, the
it checks if there are any ongoing transmission and if not, it sends packet content from the LoRaGwNetDevice is kept intact, including
its downlink message. If there is a reception going on, it tries to the MAC header and RSSI trailer, as has been mentioned before,
preserve this message and schedules the downlink transmission in although a standard interface between the forwarder and the net-
the next slot. It is important to note that messages arriving from work backend has been provided by the LoRa alliance. In our model,
the physical layer are forwarded as a whole to higher layers. This this standard interface has not been implemented.
means that the payload as well as the MAC header are forwarded
to the transport layer and up. This MAC header is needed for later
processing, e.g. in the LoRaNetworkApplications to see whether a LoRaNetwork. This application is the brain of the network. It is
MAC command was accepted or not. The only diference between the orchestrator of the network that determines which gateway
the packet coming in and the packet forwarded to higher layers is responsible for talking to a node in its network. It also decides
is an RSSI value that is added to the end of a packet to assess the which nodes are part of the network and which nodes are not. It is
quality of the link at the remote servers. therefore important to whitelist the MAC address of each allowed
node in the network with the WhitelistDevice command. This func-
3.2.3 MAC Commands. An important aspect in LoRaWAN are tion makes sure that whenever a message is received from one of
the MAC commands. These MAC commands are embedded in the these devices, a proper answer is created. In addition, this class
MAC header. MAC commands in LoRa provide a way to remotely keeps track of the unique messages that arrive at all gateways. Po-
conigure the transmission parameters of nodes in the network. For tentially, multiple copies are received at diferent gateways, but the
example, a gateway can use a MAC command to request a lower remainder of the network is only interested in the unique messages.
duty cycle. To allow easy integration of all MAC commands in the This application therefore discards any received copy without pass-
LoRa MAC header, an abstract base class LoRaMacCommand has ing it to diferent applications and only signals these applications
been implemented in our model that provides all basic functionality, with a trace source on unique messages. The LoRaNetwork also
see as well in Figure 2. In that regard, the most important function is provides an interface to send data to a speciic node. When data
the Execute function. There are two versions of this function: one for needs to be transmitted from any LoRaNetworkApplication, it is
nodes and the other for the network side. The execute function for suicient to send it to the LoRaNetwork that decides which LoRa
nodes acts directly upon the MAC layer of the nodes, and changes gateway will respond a speciic node.
parameters there. The execute function for the network side is
diferent in the sense that a gateway does not have a complete
LoRaNetworkApplication. This application layer is the applica-
overview over the network and cannot provide all answers to the
tion layer for implementing algorithms in the LoRaWAN network.
requests of nodes. Therefore, the network server or rather a network
They could do power control, store data and so on. The only re-
application will provide the answer for all requests, so the Execute
quirement when installing them is to connect it as a trace sink to
function will be called in LoRaNetworkApplications.
the trace source of the LoRaNetwork. This will trigger when a new
packet has been received, to which these applications can react.
3.3 Transport and Application Layer Some important LoRaNetworkApplications that we have already
The transport and application layer resides above the MAC layer. implemented include a power application that resets the internal
The networking layer is skipped because there is no routing in- power and an application that controls the spreading factor of nodes,
volved in LoRaWAN. As has been presented in Section 2, a gateway as used in our previous work [15]. Notice that LoRaNetworkAppli-
translates the messages on the network to an IP packet. This will cation can also translate LoRaWAN messages to IPV6 messages, to
be described in Section 3.3.2. communicate with a diferent server.

65
 A LoRaWAN Module for ns-3: Implementation and Evaluation
B. Reynders, Q. Wang, S. Pollin

3.4 Power Consumption

An extra class is added to track power consumption. The LoRaRa-
dioEnergyModel tracks the energy consumption of the physical layer. ��)
The energy model tracks the state of the physical layer: RX, TX and
IDLE state. All these states have a corresponding current that gets
��( ��$
drawn from the energy source connected to the node. Multiplying
this current with the supply voltage of the energy source and the
��#
time of the state, the used energy is calculated and subtracted from
the energy source attached to the node.
��' ��%
3.5 Potential Interface with 6LoWPAN
An interesting direction is to interface LoRaWAN with the 6LoW- ��&
PAN, or the sixlowpan module. This enables IPv6 addresses for all
LoRa devices and creates extra lexibility for end-to-end solutions
Figure 5: The network topology used in the simulation. This
and simulations. At the moment, this is not developed in our model
igure shows both the gateway used in the simulated single
yet, although little efort need to be done to enable this. The only
gateway scenario (GW1 ), like the Scenario 1 and Scenario 3,
requirement is to create an extra interface that forwards all the
as well as the multi gateway scenario where all the seven
received data, but strip the LoRaMacHeader. In this case, the de-
gateways are used (Scenario 2)
vices could also make use of IPv6 addresses. It is important to note
that all the messages received from the LoRa nodes should also be
forwarded as a whole to the network server, to allow for further Table 1: Parameters used in the simulations
exploitation of the messages in order to optimize the whole network
performance. Parameter Value Unit
The only drawback of the above approach will be the multiple Number of nodes 100, 500, 1000 /
copies of a message transmitted by a sensor node. Every receiving Packet length (excluding header) 51 byte
gateway will forward the packet and send it to the intended desti- Maximal distance to the GW1 1000 meter
nation. It is then up to the application protocol to ilter out these Distance between GWs 1000 meter
messages. Also, due to the timing constraints of TCP, only UDP Average inter-packet interval 120 second
can be used in LoRa networks.

4 EVALUATION Okunura-Hata model [9]. This model together with Rayleigh fast
To showcase the performance of our implementation, we have run fading (Nakagami-m with default parameters) [12] has been used
simulations in three diferent scenarios: as the path loss model. The packet generation is deterministic, no
• Scenario 1: the irst scenario is a simple network topology variation is added. And the nodes are uniformly distributed over
where nodes are spread in a circle and send data to a central the circle.
gateway. All the nodes transmit unconirmed data to the Before diving into results, we summarize the simulation param-
network server, and hence do not wait for any acknowledg- eters in Table 1. In the simulation of each of the three scenarios,
ments. Therefore, the gateway only responds within every 96 we use the same parameters. Two metrics are used to evaluate the
messages to prevent the nodes switching to higher spreading network performance: the total network throughput (the number
factors. of received packets are the gateway(s)) in function of the number
• Scenario 2: the second scenario is a variation of the irst sce- of nodes, and the reliability (the packet error rate) in function of
nario. Also, a circular set-up is considered, but with more the distance to the gateway. In the last subsection, we also present
gateways. These gateways are located as shown in Figure 5. some statistics of our model in the simulation, such as memory
This scenario is used to show the space diversity of Lo- usage and simulation time.
RaWAN and that diferent gateways can connect to the net-
works and that multiple gateways can respond to diferent 4.1 Single Gateway
nodes in the network. The irst simulation is just a single cell scenario. All nodes try to
• Scenario 3: the inal scenario is again a variation of the irst communicate with the gateway GW1 . Due to the ALOHA nature
scenario. Instead of using unconirmed traic, all nodes will of the protocol, all nodes have to contend for sending their data to
transmit conirmed messages. Through this scenario we will GW1 . The simulation results are shown in Figure 6 and Figure 7. The
show that it is impossible to acknowledge every message in former igure presents the reliability as a function of the distance.
the network because the low power network can not provide Clearly, the closer to the gateway, the higher the received power
such throughput. and thus the lower the packet error ratio. This is a result of the
A tremendous amount of work has also been carried out to capture efect. This efect lets high powered packets survive colli-
measure the path loss of GSM signals in the 900 MHz band. The sions, while low powered packets are discarded. As expected, more
most well known model for this band, and available in ns-3 is the devices results in a higher packet error ratio. Figure 7 shows the

66
 Workshop on ns-3 - WNS3 2018 - ISBN: 978-1-4503-6413-3
Surathkal, India - June 13-14, 2018

50 ·105 6
8

Number of packets in 24 hours

LoRaWAN 100 LoRaWAN 100
Transmitted packets
Packet Error Ratio (%)

Packet Error Ratio (%)

40 LoRaWAN 500 LoRaWAN 500
Received packets
LoRaWAN 1000 6 LoRaWAN 1000
4
30
4
20
2
10 2

0 0 0
50 150 350 550 750 950 50 150 350 550 750 950
100 500 1000
Distance to the Gateway GW1 (m) Number of nodes in the network Distance to the Gateway GW1 (m)

Figure 6: Average packet error ratio ver- Figure 7: The packets transmitted by all Figure 8: Average packet error ratio ver-
sus distances to the gateway (Scenario 1). the nodes (Scenario 1). In dark blue, all sus distances to the gateway (Scenario 2).
Close to the gateway, the packet error ra- transmitted messages are counted. The Close to the gateway, the packet error ra-
tio is very low, while far from the gate- light blue bars show the packets that tio is very low, and vice verse. However,
way, the performance goes down. Also, are successfully decoded at the gateway. 500 meters onwards, nodes are closer to
the more contending nodes, the higher The diference between the two bars is the gateways at the edge of the circle and
the packet error ratio the amount of packets that got lost beneit from the capture efect

·105
8
Number of packets in 24 hours

Number of packets in 24 hours (log)

Transmitted packets LoRaWAN 100 Transmitted packets
Received packets 100
Packet Error Ratio (%)

LoRaWAN 500 Requested packets

6 LoRaWAN 1000 107 Received packets
80

4 60 106
40
2
20 105

0
0 150 350 550 750 950 104
100 500 1000 100 500 1000
Number of nodes in the network Distance to the Gateway GW1 (m) Number of nodes in the network

Figure 9: The packets transmitted by all Figure 10: Average packet error ratio Figure 11: The packets transmitted by
the nodes (Scenario 2). In dark blue, all versus distances to gateway (Scenario 3). all the nodes (Scenario 3). In dark blue,
transmitted messages are counted. The For a small number of nodes, there is all transmitted messages are counted.
light blue bars show the packets that nearly no error. But with more nodes, The middle bars show the amount of
have been successfully decoded at the the packet error ratio goes up dras- packets sent to the MAC layer from
gateway. Notice that more gateways in- tically, deteriorating the channel for higher layers. Light blue bars denote
creases the reliability signiicantly nodes far from the gateway the packets decoded at the gateway

total amount of packets that are transmitted from all the nodes, and 4.2 Multiple Gateways
the number of packets that are successfully received by the Gate- Next, we evaluate the performance of our model in a multi-gateway
way GW1 . In other words, the left bar shows the total amount of scenarios. We use the network topology where seven gateways are
transmitted messages, while the bar on the right shows the amount deployed as illustrated in Figure 5. The simulation results are shown
of messages that are successfully received. As has been explained in Figure 8 and Figure 9. First, we can notice that the reliability in
earlier, the degradation of the performance is due to the random this setup is considerably higher than in the single gateway sce-
access of the share channel in the network. nario. Figure 8 shows a 30% lower packet error ratio. Figure 9 also

67
 A LoRaWAN Module for ns-3: Implementation and Evaluation
B. Reynders, Q. Wang, S. Pollin

demonstrates a higher reliability in the scenario of multiple gate- 5 CONCLUSION

ways. The reason behind these improvements is as follows: when a This work proposed a new LoRaWAN module in ns-3. This module
collision occurs between two nodes, it is unlikely that both of them adds long range communication to the ns-3 simulator. In this work,
are exactly at the same distance from the gateway. Therefore, one we detailed the LoRaWAN structure and how we implemented this
of the packets sent from these two nodes will be received by the within the ns-3 framework. Our implementation is a lexible ap-
central gateway GW1 , and the packet from the other node will be proach that can easily integrate new algorithms on the server side to
discarded. When there are more gateways available in the network, investigate new protocols and the efect of diferent parameters on
it is possible that the previous discarded packet will be received by the network. We have also run simulations in 3 small scenarios from
a neighboring gateway and therefore will be successfully decoded. which we show that acknowledgments are not scalable and that
As a result, the network performance is improved. multiple gateways improve the network performance considerably.

4.3 Acknowledgments ACKNOWLEDGMENTS

In the inal scenario, the irst setup was reused again, but instead of This work is supported in part by the Flemish FWO SBO SAMURAI
sending unacknowledged transmissions, acknowledgments were and the IWT CELTIC O&O project ASUA/RoCCS.
requested for each transmission. Figure 10 shows that for a small
number of devices, an extremely low packet loss can be observed. REFERENCES
For a network with 100 nodes, the packet error ratio is 0 in all cases. [1] 2018. LoRa Alliance. (2018). http://www.lora-alliance.org
[2] 2018. The Things Network. (2018). http://www.thethingsnetwork.org
However, when the number of nodes increases, the reliability drops. [3] F. Adelantado, X. Vilajosana, P. Tuset-Peiro, B. Martinez, J. Melia-Segui, and T.
The reason for this low reliability can be found in Figure 11. It shows Watteyne. 2017. Understanding the Limits of LoRaWAN. IEEE Communications
Magazine (2017).
that the amount of packets transmitted by the nodes increases [4] A. Augustin, J. Yi, T. Clausen, and W. Townsley. 2016. A Study of LoRa: Long
signiicantly when the number of nodes grows. This value should Range & Low Power Networks for the Internet of Things. Sensors (2016).
be compared with the middle bar which shows the actual amount [5] M. Bor, U. Roedig, T. Voigt, and J. Alonso. 2016. Do LoRa Low-Power Wide-Area
Networks Scale?. In Proceedings of the ACM International Conference on Modeling,
of messages that arrived on the MAC layer. Finally, the third bar Analysis and Simulation of Wireless and Mobile Systems (MSWiM). Malta, Malta.
shows the amount of message that has actually been received. These [6] F. Van den Abeele, J. Haxhibeqiri, I. Moerman, and J. Hoebeke. 2017. Scalability
igures show that acknowledgments in LoRaWAN do not scale. Analysis of Large-Scale LoRaWAN Networks in ns-3. IEEE Internet of Things
Journal 4, 6 (2017), 2186ś2198.
Extra transmissions, especially transmissions with high spreading [7] ETSI. 2010. Electromagnetic Compatibility and Radio Spectrum Matters (ERM);
factors, cause a lot of collisions. These higher spreading factors are a Short Range Devices (SRD); Radio Equipment to be Used in the 25 MHz to 1000
MHz Frequency Range with Power Levels Ranging up to 500 mW; Part 1: Technical
result of previous collisions. Therefore, nodes far from the gateway Characteristics and Test Methods. ETSI EN 300 220-1.
get stuck in a vicious circle: while trying to get a more reliable [8] K. Ghomali, N. Elkamoun, K. Hou, Y. Chen, J.P. Chanet, and J. Li. 2013. A new
channel, they only increase their probability on extra collisions and WPAN Model for ns-3 Simulator. In France-China International Workshop on New
Information Communication Science and Technology for Sustainable Development.
quickly hit their duty cycle limitation. Clermont-Ferrand, France.
[9] M. Hata. 1980. Empirical Formula for Propagation Loss in Land Mobile Radio
Services. IEEE Transactions on Vehicular Technology 29, 3 (Aug 1980), 317ś325.
4.4 Some Statistics https://doi.org/10.1109/T-VT.1980.23859
[10] D. Magrin, M. Centenaro, and L. Vangelista. 2017. Performance Evaluation of
Finally, we provide some statistics concerning simulation time and LoRa Networks in a Smart City Scenario. In Proceeding of the IEEE ICC. Paris,
memory usage. The results are summarized in Table 2. In the sim- France.
ulation, we use an Intel Xeon X7750 CPU and 128 GB of memory. [11] K. Mikhaylov, J. Petaejaejaervi, and T. Haenninen. 2016. Analysis of Capacity
and Scalability of the LoRa Low Power Wide Area Network Technology. In
Each of these values corresponds with a simulation of the provided Proceedings of the European Wireless Conference. 1ś6.
number of nodes, with the parameters described above. All nodes [12] M. Nakagami. 1960. The m-Distribution, a General Formula of Intensity of Rapid
send messages every 2 minutes for 24 hours. The measurements Fading, IWC Hofman, Ed. (1960).
[13] A. Pop, U. Raza, P. Kulkarni, and M. Sooriyabandara. 2017. Does Bidirectional
show that small networks can be simulated pretty fast, and that Traic Do More Harm Than Good in LoRaWAN Based LPWA Networks?. In
acknowledgments take a lot of eforts. For the latter case, the re- Proceedings of the IEEE GLOBECOM. Singapore, Singapore, 1ś6.
[14] B. Reynders, W. Meert, and S. Pollin. 2016. Range and Coexistence Analysis of
quirements increase signiicantly. This is due to the retransmissions Long Range Unlicensed Communication. In Proceedings of the IEEE International
and acknowledgments in the network. Conference on Telecommunications (ICT). Thessaloniki, Greece.
[15] B. Reynders, W. Meert, and S. Pollin. 2017. Power and Spreading Factor Control
in Low Power Wide Area Networks. In Proceedings of the IEEE International
Conference on Communications (ICC). Paris, France.
[16] B. Reynders and S. Pollin. 2016. Chirp Spread Spectrum as a Modulation Tech-
Table 2: Statistics of the resources used in our simulations nique for Long Range Communication. In IEEE Symposium on Communications
and Vehicular Technologies (SCVT). Mons, Belgium.
[17] B. Reynders, Q. Wang, P. Tuset-Peiro, X. Vilajosana, and S. Pollin. 2018. Improving
Number of nodes 100 500 1000 Reliability and Scalability of LoRaWANs Through Lightweight Scheduling. IEEE
Internet of Things Journal (2018). https://doi.org/10.1109/JIOT.2018.2815150
Memory (MB) 465 2175 4355 [18] Semtech Corporation [n. d.]. SX1301 Datasheet. Semtech Corporation.
Scenario 1 [19] M. Slabicki, G. Premsankar, and M. Di Francesco. 2018. Adaptive Coniguration
Time (s) 551 11756 47136
of LoRa Networks for Dense IoT Deployments. (2018).
Memory (MB) 517 2235 4378 [20] N. Sornin, M. Luis, T. Eirich, T. Kramp, and O. Hersent. 2015. LoRaWAN Specii-
Scenario 2
Time (s) 971 13773 48654 cation. http://www.lora-alliance.org
Memory (MB) 1364 3635 10029 [21] T. Voigt, M. Bor, U. Roedig, and J. Alonso. 2017. Mitigating Inter-Network In-
Scenario 3 terference in LoRa Networks. In Proceedings of the International Conference on
Time (s) 1653 28894 115523 Embedded Wireless Systems and Networks (EWSN). Uppsala, Sweden, 323ś328.

68