This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2019.2930243, IEEE Access

Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000.
Digital Object Identifier 10.1109/ACCESS.2017.DOI

Design and Implementation of Open

LoRa for IoT
QIHAO ZHOU1 , KAN ZHENG1 (Senior Member, IEEE), LU HOU1 , JINYU XING1 , AND
RONGTAO XU2 ,
1 Intelligent
Computing and Communication (IC2 ) Laboratory, Key Laboratory of Universal Wireless Communications, Ministry of Education, Beijing University
of Posts & Telecommunications, Beijing, China, 100876
2 State Key Laboratory of Rail Traffic Control and Safety, Beijing Jiaotong University, Beijing, China, 100044

Corresponding author: K. ZHENG (zkan@bupt.edu.cn)

ABSTRACT Long Range (LoRa) network is emerging as one of the most promising Low Power Wide Area
(LPWA) networks, since it enables the energy-constraint devices distributed over wide areas to establish
affordable connectivity. However, how to implement a cost-effective and flexible LoRa network is still an
open challenge. This paper aims at exposing a feasible solution of design and implementation, allowing
users to conveniently build a private LoRa network for various IoT applications. Firstly, several typical
application scenarios of LoRa network are discussed. Then, the LoRa system architecture is presented with
the functionality of each component. We address the hardware design and implementation of LoRa Gateway,
which is the bridge between LoRa nodes and LoRa network server. Especially, the paper contributes by
proposing an improved software architecture of LoRa network server whose source codes are open on
GitHub. Under the architecture, LoRa network server is divided into four decoupled modules and uses the
messaging system based on streaming data for the interaction between modules to guarantee scalability and
flexibility. Finally, extensive experiments are conducted to evaluate the performance of LoRa networks in
typical environments.

INDEX TERMS LoRa, LPWA, IoT, Microservice, Open Source

I. INTRODUCTION the LoRa network server have a significant impact on the

With the development of low power wide area (LPWA) capacity of LoRa system.
technologies, the flourish of various Internet of Things (IoT) There has been vast amounts of work being explored for
applications is changing the way of living in the world. In LoRa network. Firstly, some of studies focused on comparing
particular, it is estimated that LPWA devices will grow to 339 LoRa with other LPWA technologies such as Sigfox and NB-
million in 2025 [1]. Due to its unique technical features, Long IoT [3]–[5]. The authors in [6]–[8] analyzed and discussed
Range (LoRa) network has attracted significant attention the wide variation of performance in specific scenarios as
from industry and academic sectors in recent years. LoRa well as the capabilities and limitations. These studies used
operates in the unlicensed Industrial Scientific and Medical analytical and simulation-based approaches to carry out the
(ISM) band and offers the long-distance connectivity to low- experiments and gave the processing performance of back-
power devices. On the other hand, LoRaWAN is proposed ground server. There are various challenges when deploying
by LoRa Alliance, which defines the network protocol in LoRa network in practical scenario. Moreover, several IoT
the medium access control (MAC) and network layers [2]. cloud platforms have been proposed to process and manage
A completed LoRa network primarily consists of several IoT data [9]–[11]. However, LoRa Nodes are distributed
components, i.e., LoRa Node, LoRa Gateway, LoRa network over wide areas and utilize LoRa Gateway to establish the
server and LoRa application server. It is worth mentioning connection with Internet. These services provided by IoT
that LoRa Nodes usually operate on battery power and have cloud platforms are failed to be used directly by LoRa
limited computational capabilities. LoRa network server is Nodes. A LoRa network server project is necessary to pro-
responsible to have sufficient ability to provide the packet cess the packets forwarded from/to LoRa Gateway. In [12],
processing services and support massive number of LoRa the authors proposed an implementation of LoRa network
Nodes. Therefore, the architecture and implementation of server on the OpenStack named as LoRaCloud without the

VOLUME 4, 2016 1

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2019.2930243, IEEE Access

Q. Zhou et al.: Design and Implementation of Open LoRa for IoT

performance evaluation. In addition, there are some projects

available for building and managing LoRa network. For Smart City Environmental
example, The Things Network (TTN) has begun to release Monitoring
an open source platform for LoRa network [13]. However,
independent deployment of TTN-based LoRa network server
is cumbersome, which is not conducive to agile development.
Another popular open source project is named LoRaServer
[14]. LoRaServer presented a ready-to-use solution including LoRa
design and implementation. But the centralized architecture Network
leads to excessive functionality concentrated on one module.
It may have a negative impact on the throughput and scalabil-
ity of entire system. Therefore, an open LoRa network with
high performance and flexibility is highly desirable.
In this paper, the typical application scenarios and require-
ments of LoRa network are presented firstly. Then, the LoRa
Smart Healthcare Smart Farming
system architecture is discussed as well as the functions
FIGURE 1: Illustration of typical application scenarios of
of each component. In order to reduce the difficulty of
LoRa networks.
deploying private LoRa networks, the hardware and software
design are proposed in details. LoRa Gateway establishes the
connection between massive LoRa Nodes and LoRa network chitecture of LoRa network server. Section VI demonstrates
server, so its function and performance are crucial. The and analyses the experimental results. Finally, section VII
paper focuses on the design and implementation of LoRa draws the conclusions.
Gateway, which is able to support multi-mode communica-
tion and meets the needs of outdoor deployment. Moreover, II. TYPICAL APPLICATIONS OF LORA NETWORKS
an improved LoRa network server architecture is proposed. With the communication range of over ten kilometers and
The architecture follows the principles of microservice, al- long battery lifetime, LoRa network is promising for the long
lowing for maximum control and flexibility. As a result, range, low power and low cost IoT applications. However,
the LoRa network server is divided into four modularized in order to achieve these excellent characteristics, LoRa
and low-coupling modules, i.e., Connector, Central Server, technology comes at the expense of low data rate [15]. In this
Join Server and Network Controller. They are responsible section, several typical applications and scenarios of LoRa
for different functions such as protocol analysis or node network are discussed.
activation individually. Various advanced techniques are used
in the implementation of LoRa network server to guarantee A. SMART CITY
high performance and scalability. Modular design allows LoRa network provides a reliable and feasible solution
processing modules to be deployed in separated processes or for various IoT applications in smart city, such as smart
servers and help users flexibly extend custom functionality in metering and waste management. More intelligently, these
the corresponding module. LoRa Nodes can automatically report sensing data and be
Aiming at providing insights about the design and imple- controlled remotely through LoRa network. By connecting
mentation of LoRa system, the main contributions of this city services, these applications offer the opportunities to
paper are summarized as follows: improve the efficiency of municipal operations and reduce
1) The design and implementation of LoRa Gateway are maintenance costs.
proposed as a feasible solution.
2) We propose an improved LoRa network server archi- B. ENVIRONMENTAL MONITORING
tecture and implement it with an open-source project Environmental monitoring is crucial for our society to pro-
on GitHub1 . vide real-time environmental indicators, such as air quality,
3) Based on the proposed hardware platform and software temperature and humidity, and alert to critical situations, such
architecture, a LoRa prototype system is deployed in as natural disasters and environment pollution. Taking into
urban environments and several experiments are con- account both financial and energy requirements, it is suitable
ducted to evaluate the performance. to implement a network with LoRa technology across large
The rest of this paper is organized as follows. Section geographical areas. The low-power LoRa Nodes with various
II presents some typical application scenarios of LoRa net- sensors are able to interact with the environment and report
works. Section III describes LoRa network architecture. Sec- data opportunely to detect issues before becoming crises.
tion IV gives the details on hardware design and implementa-
C. SMART HEALTHCARE
tion of LoRa Gateway. Section V proposes the improved ar-
Using information and communication technology in health-
1 https://github.com/xisiot/lora-system care can lead to better treatment and disease surveillance for
2 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2019.2930243, IEEE Access

Q. Zhou et al.: Design and Implementation of Open LoRa for IoT

battery, etc., and performs one or more tasks according to

different application requirements. LoRa Gateway forwards
all uplink radio packets to LoRa network server after adding
Application Server metadata such as Signal-Noise-Ratio (SNR) and Received-
Users
IoT Cloud Signal-Strength-Indicator (RSSI). Conversely, on the down-
Central Server
link, LoRa Gateway performs transmission requests coming
Join Server Network from LoRa network server. Typically, it only transmits the
Controller
received uplink/downlink packets as a relay without any
Load
interpretation of payloads. The hardware implementation
Load
balancing
balancing
details are described in the next section.

Managers
B. LORA NETWORK SERVER
Database


Website
LoRa network server receives packets forwarded from LoRa
LoRa Network Connector
Server Gateway, and is responsible for packet processing and pro-
tocol analysis. Vast amount of functions need to be imple-
mented on LoRa network server. For examples, checking
LoRa LoRa LoRa the legality of end-devices, filtering duplicate uplink packets,
Gateway Gateway Gateway
performing network management mechanisms, scheduling
LoRa
Node acknowledgements and forwarding application layer data to
the application server, etc. A well-designed architecture of
LoRa Node
LoRa Node LoRa network server is important for efficient processing and
LoRa Infrastructure
convenient management. Especially, the flexibility allows
FIGURE 2: Illustration of LoRa network architecture. users to build various applications on existing LoRa hardware
devices and the scalability can meet the needs of supporting
massive LoRa Nodes. In addition, a management framework
patients. However, the vast cost burden is a challenge for the is necessary to help users to register, manage and monitor
healthcare industry. Low cost and reliable performance of their LoRa devices including nodes and gateways. Aiming at
LoRa network make it suitable for typical smart healthcare providing insight about the improvement of LoRa network
applications. Various biological information is collected by server, the proposed design and implementation of LoRa
special on-body sensors and can be checked in time. All ab- network server are presented in Section V.
normal indicators are transmitted to health service providers
or health professionals through LoRa network for the early C. APPLICATION SERVER IN IOT CLOUD
detection and prevention of diseases. LoRa Application Server is responsible for encryption, de-
cryption and processing of application layer payloads. It
D. SMART FARMING can support various applications with different encryption
Smart farming is the application of modern technology into or encoding methods, such as Protocol Buffer, to ensure
agriculture, aiming at improving the quantity and quality data security and improve transmission efficiency. IoT cloud
of agricultural products while reducing environmental im- provides essential services through Application Program In-
pact and preserving resources. LoRa-based smart farming terfaces (APIs) and then applications are provided to users.
use cases, e.g., soil moisture monitoring and autonomous LoRa Application Server acts as a bridge between IoT cloud
irrigation, have a great potential to deliver a more sustainable and LoRa network server so that users can control LoRa
agricultural production. Long-range, low-cost and low-power Nodes and enjoy applications of LoRa network through web
features of LoRa technology enable the use of sensors to browsers or smart phones anywhere. A detailed explanation
transfer information from the farm to the cloud where it can of IoT cloud can be obtained in [16].
make more efficient operations and management.
IV. HARDWARE DESIGN AND IMPLEMENTATION
III. LORA NETWORK ARCHITECTURE The hardware of LoRa system includes LoRa Node and LoRa
As illustrated in Fig.2, a three-tier hierarchical LoRa network Gateway. The design of LoRa Node is dependent on its
architecture is proposed. The functionalities of each compo- specific application requirements and one typical example
nent is described in this section. can be found in our published work [17]. In this paper,
we only focus on the design and implementation of LoRa
A. LORA NODE AND GATEWAY Gateway, which acts as a relay between LoRa Node and
LoRa Node and Gateway are fundamental components of LoRa network server. Due to LoRa technology’s long range
the entire LoRa networks since it can interact with the envi- capability, the LoRa Gateway is expected to cover dozens
ronment as well as forwarding data to LoRa network server of square kilometers in the given environment. Therefore, it
for analysis. LoRa Node mainly includes sensors, actuators, is necessary for LoRa Gateway to support two-way multi-
VOLUME 4, 2016 3

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2019.2930243, IEEE Access

Q. Zhou et al.: Design and Implementation of Open LoRa for IoT

Power Management
In order to build a friendly runtime environment for soft-
ware, the Debian system based on the Linux kernel is used in
Controller Module Localization Module controller module. The packet forwarder program processes
the communication protocol between LoRa Gateway and
Smart4418 CPU Board
MAX-7Q Module
dule
LoRa network server [18]. Based on this program, LoRa
Packet Forwarder
Gateway has the ability to connect with the server using
specific packets through a User Datagram Protocol (UDP)
link.
SX1301 Digital Baseband
Wi-Fii LTE Processor B. LORA MODULE
In order to achieve two-way multi-channel communication
Ethernet SX1255 RF SX1255 RF
Transceiver Transceiver
and excellent receiver sensitivity, the LoRa communication
module consists of two SX1255 transceivers and one SX1301
Communication Module LoRa Module digital baseband processor. SX1255 is an integrated RF
LoRa Gateway transceiver and is designed to operate over the 400-510 MHz
185mm frequency bands. After SX1255 transceivers capture the RF
LoRa GPS LTE Wi-Fi signal, the data is concentrated into the SX1301 baseband
processor via SPI. SX1301 contains 8 programmable parallel
demodulation paths for LoRa channel and is able to demod-
ulate simultaneously up to 8 packets. In addition, data-rate
adaptation (ADR) scheme is supported by our designed LoRa
Gateway. LoRa Node is able to transmit the packets with
280mm

different data rate on a given channel as required.

Power &
Ethernet
C. COMMUNICATION MODULE
The LoRa Gateway has the other communication modules
including Wi-Fi, LTE and Ethernet. Depending on the de-
ployment environment, the reliable connection is able to be
established from gateway to LoRa network server through
FIGURE 3: Illustration of LoRa Gateway and its modules. one of communication mode.

D. LOCALIZATION MODULE
channel communication based LoRa technology and have Localization module uses the U-blox’s MAX-7Q for local-
high signal receiving sensibility. Rich interfaces and high ization and time synchronization. The module can provide
processing performance are the guarantee of scalability and the position accuracy of less than 5 meters with low power
large-scale access. In addition, LoRa Gateway should have and short search time from Global Positioning System (GPS).
good water-proof ability to support outdoor deployment. The GPS related information is transmitted to controller
As shown in Fig.3, the LoRa Gateway consists of five func- module through the serial port and then is parsed according
tional modules, i.e., controller module, localization module, to standard protocols.
power management module, LoRa module and communica-
tion module. Its degrees of protection provided by enclosures
E. POWER MANAGEMENT MODULE
can meet the requirements of IP65 level. The implementation
details are given as follows, i.e., Power Over Ethernet (POE) is adopted to simplify the de-
ployment of LoRa Gateway. The power management module
uses TPS54332D to offer 3.3 V and 5 V voltages for different
A. CONTROLLER MODULE
components.
All control functions are implemented in controller module.
The Smart4418 board is chosen due to its good performance,
which uses a quad core Cortex A9 Computer Processing Unit V. LORA NETWORK SERVER DESIGN AND
(CPU) with dynamic frequency scaling up to 1.4 GHz and has IMPLEMENTATION
1 GB Random Access Memory (RAM) and 8 GB Embedded Aiming at providing an open flexible solution for both allow-
Multi Media Card (eMMC). Moreover, the board offers rich ing users to conveniently deploying the LoRa network and
and advanced communication interfaces, such as up to 24 supporting massive LoRa Nodes, we propose the improved
General-Purpose Input/Output (GPIO), 2 Serial Peripheral architecture of LoRa network server and discuss its details as
Interface (SPI) and Gbps Ethernet, etc. These features make well as the implementation in this section.
Smart4418 suitable for implementation of LoRa Gateway.
4 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2019.2930243, IEEE Access

Q. Zhou et al.: Design and Implementation of Open LoRa for IoT

Join Server Join Server

LoRa LoRa
Gateway
Gateway Application
Network Application End-Device Connector Central Server
End-Device Server
Server Server

Network
(a) LoRa Network Controller
Website
Server
LoRa Geo
Website
Server
FIGURE 5: The improved architecture of LoRa network
LoRa
Gateway server.
LoRa Gateway Application
End-Device LoRa Server
Bridge Server
worth mentioning that Connector performs packet parsing
and discards illegal packets directly, which both improves
(b) security and reduces the occupation of computing resources.
Network Controller is also separated from the traditional
FIGURE 4: (a) The LoRa network architecture given by
architecture in order to flexibly implement and perform
LoRaWAN. (b) The LoRa network architecture proposed by
network management schemes, such as Adaptive Data Rate
CableLabs [14].
(ADR) scheme.
A. RELATED WORKS ON ARCHITECTURE DESIGN Modularizing and splitting main functions into different
In the paper, we describe two typical architecture designs modules can distribute the computational load as well as
for comparison, i.e., the LoRa network architecture given reducing performance requirements of the computer server,
by LoRaWAN and proposed by CableLabs [14], which are such as CPU and memory. The division of functions is in line
shown in Fig.4 (a) and (b) respectively. with the principle of microservices in order to ensure low
In the reference architecture given by LoRaWAN, Network coupling between modules. Therefore, these modules can be
Server is the center of star topology and is expected to deployed flexibly in separated processes or servers, allowing
implement all the main functions. However, it may become a for agile deployment. All the modules in LoRa network
potential bottleneck because integrating excessive function- server also can be quickly deployed by Docker containeriza-
ality requires more capabilities [19]. It also lacks of expan- tion [20]. We package all the necessary components into a
sibility and cannot resist single point of failure. In addition, completed file system including project codes, databases and
LoRaWAN only introduces the typical architecture without libraries. The method simplifies deployment steps as well
giving any concrete implementation. Different realizations as guaranteeing that each module runs correctly regardless
may have a significant impact on the performance of LoRa of its environment. The key points in the architecture are
network server. elaborated as follows.
As shown in Fig.4 (b), the architecture proposed by
CableLabs separates two modules from LoRa Server, i.e., 1) Interaction Between Modules
LoRa Gateway Bridge and LoRa Geo Server [14]. They are The interaction between modules is critical for the overall
designed to establish communication with LoRa Gateway performance of LoRa network server. The publish-subscribe
and provide geolocation services respectively. Registration- messaging system, i.e., Apache Kafka, is used to establish
related features such as handling join requests are integrated reliable communication between models. As shown in Fig.6,
into LoRa Server. Compared with our proposed architecture, the topic is a name of streaming data pipeline in messaging
there are two main differences in the design concept. Firstly,
the interaction between modules is implemented by gRPC
while the messaging system is used in our proposed solution. Group
Application
Server
Group

The advantages of using the messaging system are elaborated Subscribe

later. On the other hand, similar to the architecture proposed Join

Publish Server
by LoRaWAN, the centralized architecture leads to excessive Network
Subscribe
JS-Sub Subscribe

functionality concentrated on one module, i.e., LoRa Server. Controller

AS-Sub
JS-Pub
Publish
Group
We propose a LoRa network server architecture that sepa- Publish
Subscribe CS-Pub Publish
rates functionality into four flexible modules to attenuate the NC-Sub Publish
negative impact of centralization. Subscribe NC-Pub
Group Group

B. DESIGN OF LORA NETWORK SERVER Messaging

Subscribe

System
As illustrated in Fig.5, the improved architecture of LoRa Connector
Publish
Central Server

network server is divided into four modules, i.e., , Connector,

Central Server, Join Server and Network Controller. It is FIGURE 6: The design of interaction between modules.

VOLUME 4, 2016 5

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2019.2930243, IEEE Access

Q. Zhou et al.: Design and Implementation of Open LoRa for IoT

system and different topics are designed for each module 1) Connector
according to requirements. Each module subscribes one or Connector is the bridge between LoRa Gateway and Central
more topics to fetch the corresponding data as a consumer Server, which provides the services for parsing and pack-
and publishes messages to specific topics as a producer. The aging the payload based on LoRaWAN specification [22].
streaming data pipelines are acting as an abstract layer be- LoRa Gateway connects with a given Connector through an
tween consumer and producer. As long as the message format IP back-bone and uses UDP for packet transmission. Firstly,
is specified, producers can be "ignorant" of the consumers. Connector performs legality verification on LoRa Nodes and
Moreover, the messaging system is able to provide both Gateway to avoid unauthorized access. For example, if LoRa
ordering guarantees and reliable asynchronous processing to Gateway has been legally registered, Connector immediately
address high concurrency challenges. replies an acknowledgment to indicates that the packet is re-
ceived. Otherwise, the packet is discarded directly. Moreover,
2) Load balancing parsing and packaging of a packet require many necessary
database operations. Separating the function from traditional
Load balancing is an essential design to handle a massive
network server performs well to spread the processing pres-
number of concurrent packets. In the messaging system,
sure and improve the utilization of all accessible resources.
the consumer group has the concept of clustering the same
On the other hand, packets associated with LoRa node acti-
modules for load balancing and fail-over. It is worth men-
vation process are ignored and forwarded directly to Central
tioning that each message published from the producer is
Server.
assigned to one consumer in the subscribing consumer group.
The scheduler operates the round-robin scheduling policy 2) Central Server
for all available consumers. Load balancing improves overall
Central Server is responsible for data management and ser-
throughput and avoids bottlenecks caused by excessive load
vice scheduling. Different modules are scheduled by Central
on a single processing module. In addition, load balancing
Server according to the requirements of data processing.
also enhances the fault tolerance of LoRa network server.
Depending on the type of uplink packet, the information in
When a given single module fails, the data which needs to
packet is separated into the specific formats in order to fa-
be processed can be immediately switched to other parallel
cilitate subsequent processing. Then, the original application
modules without service interruption.
data is fed into Application Server, the MAC commands are
sent to Network Controller and the join packets are forwarded
3) Database to Join Server. In addition, the transmitted data is collected
In order to meet the storage requirements of heteroge- and stored by Central Server. Managers can use web browsers
neous data, Structured Query Language (SQL) and NoSQL to check up the uplink/downlink packets and monitor the
databases are selectively used in LoRa network server. The running states of LoRa node and Gateway in real time.
persistent data with definite relationships, such as client in- Since LoRa Nodes are not associated with a specific LoRa
trinsic information, are stored in MySQL database. However, Gateway, the single packet may be received by multiple gate-
the main bottleneck of SQL database is the inefficiency in ways simultaneously. To avoid the waste of radio resources
handling high concurrent read and write operations [21]. due to redundancy, Central Server is essential for filtering
Consequently, NoSQL databases are able to provide real- duplicate packets. Only one of duplicate packets is fed into
time and high-efficiency services for data storage. Therefore, the subsequent processing module. Moreover, the respon-
all session-related and non-persistent data, such as logs and sibility of Central Server includes scheduling of downlink
duplicate packets, is stored by NoSQL databases. In addition, packets. The transmission information such as RSSI and SNR
an efficient caching mechanism is necessary to ensure low la- attached in the duplicate packets is not discarded and then
tency and high performance when dealing with large amounts one optimal gateway is selected to send the downlink packet
of concurrent packets. through exploiting this information. Finally, Central Server
determines the downlink parameters according to related
configurations and reads the downlink payload from two data
C. IMPLEMENTATION OF LORA NETWORK SERVER
queues which are responsible for application data and MAC
The implementation of LoRa network server are described commands.
with the functionality of each module. Aim at efficiently
processing large amounts of packets, different types of con- 3) Join Server
tent are assigned to different modules for processing. These The services provided by Join Server include handling acti-
modules are built on microservices principles with the goal vation requests and generating session keys. There are two
of decoupling their duties and achieving distributed deploy- methods to activate LoRa Nodes, i.e., Over-The-Air Activa-
ment. Moreover, a website project is developed as a manage- tion (OTAA) and Activation By Personalization (ABP). For
ment framework, which allows operators to register devices, OTAA method, LoRa Node must follow a join procedure
monitor devices and retrieve historical data, etc. consisting of the join request and the join accept exchange.
To secure the activation process, the join request packet is
6 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2019.2930243, IEEE Access

Q. Zhou et al.: Design and Implementation of Open LoRa for IoT

TABLE 1: LoRa Node Parameters

Parameters Value
LoRa Device Connector Central Server Controller Server
Carrier frequency 433 MHz
MAC Commands
Uplink Packet Requests Preamble 8 Symbol
& Parameters Perform Schemes Transmit power 20 dBm
ADD
Coding rate 4/5
Read ...
Downlink Queue Spreading factor 12
LoRa
Requests Bandwidth 125 kHz
Gateway
Downlink Packet
-40 25

Downlink Queue RSSI

Uplink Packet
... -50
SNR
20

Check
Answers MAC Commands -60 15

Answers
...
Received Answers
Downlink Queue -70 10
Read

RSSI (dBm)

SNR (dB)
-80 5
LoRa
Repeat
Gateway
-90 0

FIGURE 7: Illustration of the workflow of Network Con- -100 -5

troller.
-110 -10

-120 -15

only parsed by Join Server and then the session keys are -130 -20

derived from both the pre-shared key and the transmitted 0 1 2 3 4 5 6 7 8

Distance (km)
random number. Finally, the join accept packet is encap-
sulated and encrypted by the corresponding key in Join
Server. Furthermore, LoRa Nodes using ABP method need FIGURE 8: Coverage performance of LoRa transmission.
to be registered on the website through specific management
interfaces. A. COVERAGE PERFORMANCE AND ANALYSIS
The LoRa Gateway with whip antenna is vertically installed
4) Network Controller on the roof of a 15-floor building at the center of our campus.
The functions of Network Controller focus on processing and The omnidirectional antenna has a gain of 10 dBi and an
managing MAC commands. MAC commands are exchanged operating frequency range from 400 MHz to 470 MHz. Then,
between Network Controller and LoRa Nodes in order to the packets are collected through LoRa transmission and then
modify associated configurations or adjust transmission pa- forwarded to LoRa network server by LTE [17]. Both the
rameters [22]. Network Controller is stripped from classic LoRa Gateway and Nodes operate at the frequency band of
LoRa network server, which flexibly performs Mac com- 433 MHz. In order to evaluate the maximum distance of
mands and new network management schemes. The well- the LoRa transmission, LoRa Nodes adopt the maximum
designed schemes such as Adaptive Data Rate (ADR) are spreading factor, i.e., SF=12, to transmit the packets. The
implemented since they can improve both reliability and main parameters in field trials are given in Table 1.
capability of LoRa networks [23]. Fig.7 shows the workflow In the experiments, several LoRa Nodes continuously send
of Network Controller. Take the implementation of ADR uplink packets and gradually move away from the location of
scheme as an example, the transmission parameters of the LoRa Gateway. The received signal quality parameters are
uplink packets are conveyed from Central Server. Then Net- measured about every 0.5 km. As shown in Fig.8, the RSSI
work Controller performs the ADR scheme and determines and SNR decrease sharply within 1 km, while vary slowly
whether to adjust either the data rate or transmission power. with the increase of distance. It can be seen that the maximum
Finally, the MAC commands are added to the downlink distance that LoRa Gateway can receive the uplink packets is
queue and sent by the downlink packet. When receiving the about 7.5 km, while the minimal RSSI and SNR is -118 dBm
acknowledgement packet, the successful request commands and -16.5 dB respectively.
are removed from the queue. Otherwise, the failed commands
are reserved for the next transmission. B. LORA NETWORK SERVER PERFORMANCE AND
ANALYSIS
VI. EXPERIMENTAL RESULTS AND ANALYSIS In order to evaluate the network performance of LoRa sys-
In order to evaluate the performance of proposed LoRa tem, the proposed modules and the stress testing program
network, a prototype LoRa network has been implemented are deployed on two separated VMs. The main parameters
and deployed in typical urban environments. Not only the of the VMs are shown in Table 2. The testing program is
coverage but also the network server performance of LoRa developed based on Locust, which can emulate thousands
system are evaluated in this section. of concurrent users on a single VM [24]. In our experi-
VOLUME 4, 2016 7

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2019.2930243, IEEE Access

Q. Zhou et al.: Design and Implementation of Open LoRa for IoT

TABLE 2: Virtual Machine Parameters

1,800

Parameters Server VM Test VM

1,600

Median value of Response Time (ms)

Intel(R) Xeon(R) Intel(R) Xeon(R)
CPU
CPU E5-2680 CPU E5-2609 v4 1,400

RAM 8 GB 16 GB
Number of logical CPU 5 8 1,200

Operating System Ubuntu 14.04.3 LTS Ubuntu 16.04.3 LTS

1,000

800
Throughput of LoRa network server (packets/sec)

1 Central Server 600

300

2 Central Server

4 Central Server 400

250
1 Central Server
200
2 Central Server

4 Central Server
200
0
0 2,000 4,000 6,000 8,000 10,000 12,000 14,000

150
Number of LoRa nodes

100
FIGURE 10: The median value of response time.
50

400
0 1 Central Server & Connector
0 2,000 4,000 6,000 8,000 10,000 12,000 14,000
2 Central Server & Connector
350
Number of LoRa nodes Average CPU utilization (%) 4 Central Server & Connector

300

FIGURE 9: Throughput of LoRa network server. 250

200

ments, each LoRa node is treated as a user and generates 150

an uplink application packet about every 40 seconds. We

assume that all the packets are successfully received by LoRa 100

Gateway since LoRa Gateway has multi-channel commu- 50

nication capability and powerful processing performance.

The testing program is designed to directly send/receive 0
0 2,000 4,000 6,000 8,000 10,000 12,000 14,000

the uplink/downlink packets by UDP to/from the network

Number of LoRa nodes
server [18]. The number of LoRa Nodes is set from 400 to
14,000 as required. Each uplink packet should be replied
and the response packets are received by LoRa Nodes if the FIGURE 11: Average CPU utilization of Connector and
network server handles the packets successfully. Otherwise, Central Server.
if no response is received within 5 seconds, the processing
of uplink packet is regarded as a failure. When the number unable to successfully process packets in time. Figure 10
of LoRa Nodes increases, the throughput under the given shows that the median value of response time changes slowly
situation is measured. Meanwhile, the median response time when the number of Nodes is less than the limit but increases
and average CPU utilization of Connector and Central Server sharply when the number becomes too larger.
are also used as reference indicators. Our experiments are Figure 11 shows the average CPU utilization of Central
mainly focused on Connector and Central Server since both Server and Connector for different deployment number. It
of them have significant impacts on the quality of services can be seen that, the CPU utilization of Central Server can
under consideration. slightly exceed 100% and 200% with 1 or 2 Central Server
As shown in Fig.9, the throughput of LoRa network server and the curves no longer rise with the increase of LoRa
is linear with the increasing number of LoRa Nodes in Nodes. In addition, when the CPU utilization of Connector
the region of small number since LoRa network server can reaches 100%, the CPU utilization of Central Server also
successfully process all packets. However, the throughput becomes floor. It is because these modules are a single-
becomes floor when the number of LoRa node reaches a threaded program developed by Node.js. One Connector or
specific limit, e.g., 4000, 7,600, and 12,400 for 1, 2 and Central Server can only occupy one logical CPU. When any
4 Central Server, respectively. Meanwhile, the maximum of the logic CPU is fully occupied no matter on which module
throughput is about 98, 190 and 300 packets per second. It is running, LoRa network server cannot accommodate more
is because that too many packages cause the network server LoRa Nodes. On the other hand, Central Server needs more
8 VOLUME 4, 2016

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.
 This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/ACCESS.2019.2930243, IEEE Access

Q. Zhou et al.: Design and Implementation of Open LoRa for IoT

computing resources than Connector so that it is more likely [12] J. So, D. Kim, H. Kim, H. Lee, and S. Park, “Loracloud: Lora platform on
to become a bottleneck. Luckily, our proposed architecture openstack,” in 2016 IEEE NetSoft Conference and Workshops, pp. 431–
434, June 2016.
supports deploy multiple modules distributedly and achieves [13] The Things Network. Available: https://www.thethingsnetwork.org. [On-
load balancing across them. line; accessed Mar. 15, 2019].
[14] LoRa Server, Open-source LoRaWAN Network-server. Available:
https://www.loraserver.io/. [Online; accessed Mar. 15, 2019].
VII. CONCLUSION [15] U. Raza, P. Kulkarni, and M. Sooriyabandara, “Low power wide area
Due to wide area coverage and low power consumption of networks: An overview,” vol. 19, no. 2, pp. 855–873.
[16] L. Hou, S. Zhao, X. Xiong, K. Zheng, P. Chatzimisios, M. S. Hossain, and
LoRa network, various applications provided by LoRa have W. Xiang, “Internet of things cloud: Architecture and implementation,”
been emerging in the IoT market. In this paper, aiming at IEEE Communications Magazine, vol. 54, pp. 32–39, Dec. 2016.
providing a flexible and completed solution for building a [17] W. Zhao, S. Lin, J. Han, R. Xu, and L. Hou, “Design and implementation
of smart irrigation system based on lora,” in IEEE Globecom Workshops
private LoRa network, the design and implementation of (GC Wkshps), pp. 1–6, Dec. 2017.
LoRa network have been proposed including hardware and [18] Semtech, “Lora network packet forwarder project.” Available:
software. Moreover, the open source project is available on https://github.com/Lora-net/packet_forwarder. [Online; accessed Mar. 15,
2019].
GitHub. The field trails demonstrate that the maximum trans- [19] K. Zheng, S. Ou, J. Alonso-Zarate, M. Dohler, F. Liu, and H. Zhu,
mission distance based on our hardware design is about 7.5 “Challenges of massive access in highly dense lte-advanced networks with
km in urban environments. Furthermore, we also show that machine-to-machine communications,” IEEE Wireless Communications,
vol. 21, pp. 12–18, June 2014.
LoRa system under the improved architecture can support [20] Docker, “What is locust?.” Available: https://docs.docker.com. [Online;
more than 10,000 LoRa Nodes with well-deployed comput- accessed Mar. 15, 2019].
ing resources. It is expected that this open LoRa network can [21] Y. Li and S. Manoharan, “A performance comparison of sql and nosql
databases,” in IEEE Pacific Rim Conference on Communications, Com-
provide the flexibility and feasibility for both academic and puters and Signal Processing, pp. 15–19, Aug. 2013.
industry to deploy their new LPWA applications in the near [22] LoRa Alliance, “Lorawan specification (v1.1).” Available: https://lora-
future. alliance.org/resource-hub/lorawantm-specification-v11. [Online; accessed
Mar. 15, 2019].
[23] F. Liu, K. Zheng, W. Xiang, and H. Zhao, “Design and performance
ACKNOWLEDGMENT analysis of an energy-efficient uplink carrier aggregation scheme,” IEEE
The work was supported by the National Natural Science Journal on Selected Areas in Communications, vol. 32, pp. 197–207, Feb.
2014.
Foundation of China (NSFC) under the Grant Number [24] Locust documentation, “What is locust?.” Available:
61671089. https://docs.locust.io/en/stable/what-is-locust.html. [Online; accessed
Mar. 15, 2019].

REFERENCES
[1] LoRa Alliance, “LoRa Alliance 2017 end of year report.” Available:
https://lora-alliance.org/sites/default/files/2018-04/LoRa-Alliance-
Annual-Report.pdf. [Online; accessed Mar. 15, 2019].
[2] LoRa Alliance, “LoRaWAN What is it? A technical overview of LoRa and
LoRaWAN.” Available: https://lora-alliance.org/sites/default/files/2018-
04/what-is-lorawan.pdf. [Online; accessed Mar. 15, 2019].
[3] X. Xiong, K. Zheng, R. Xu, W. Xiang, and P. Chatzimisios, “Low power
wide area machine-to-machine networks: key techniques and prototype,”
IEEE Communications Magazine, pp. 64–71, Sep. 2015.
[4] J. de Carvalho Silva, J. J. P. C. Rodrigues, A. M. Alberti, P. Solic, and
A. L. L. Aquino, “Lorawan — a low power wan protocol for internet
of things: A review and opportunities,” in International Multidisciplinary
Conference on Computer and Energy Science, pp. 1–6, July 2017.
[5] R. Sinha, Y. Wei, and S.-H. Hwang, “A survey on lpwa technology: Lora
and nb-iot,” ICT Express, pp. 14–21, 2017.
[6] M. C. Bor, U. Roedig, T. Voigt, and J. M. Alonso, “Do lora low-power
wide-area networks scale?,” in Proceedings of the 19th ACM International
Conference on Modeling, Analysis and Simulation of Wireless and Mobile
Systems, pp. 59–67, 2016.
[7] F. Adelantado, X. Vilajosana, P. Tuset-Peiro, B. Martinez, J. Melia-Segui,
and T. Watteyne, “Understanding the limits of lorawan,” IEEE Communi-
cations Magazine, vol. 55, pp. 34–40, Sep. 2017.
[8] D. Magrin, M. Centenaro, and L. Vangelista, “Performance evaluation of
lora networks in a smart city scenario,” in IEEE International Conference
on Communications, pp. 1–7, May 2017.
[9] J. L. Pérez and D. Carrera, “Performance characterization of the servioticy
api: An iot-as-a-service data management platform,” in IEEE First Inter-
national Conference on Big Data Computing Service and Applications,
pp. 62–71, Mar. 2015.
[10] G. Merlino, D. Bruneo, S. Distefano, F. Longo, and A. Puliafito, “Enabling
mechanisms for cloud-based network virtualization in iot,” in IEEE 2nd
World Forum on Internet of Things, pp. 268–273, Dec. 2015.
[11] K. Zheng, H. Meng, P. Chatzimisios, L. Lei, and X. Shen, “An smdp-
based resource allocation in vehicular cloud computing systems,” IEEE
Transactions on Industrial Electronics, vol. 62, pp. 7920–7928, Dec. 2015.

VOLUME 4, 2016 9

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/.