LoRaCloud: LoRa Platform on OpenStack
Jaeyoung So, Daehwan Kim, Hongseok Kim, Hyunseok Lee, Suwon Park
Dept. of Electronics and Communications Engineering
Kwangwoon University
Seoul, South Korea 01897
Abstract—In this paper, we discuss the implementation of
LoRa network server on OpenStack. LoRa is a type of low
power wide area wireless network protocols for Internet of
Thing applications. We restructured the operations of LoRa
network server so it can be flexible and scalable by exploiting
the system services provided by OpenStack. For validation, we
have established an experimental system by using available open
sources for LoRa terminal, LoRa gateway, and OpenStack.
I. I NTRODUCTION
Internet of Things (IoT) starts from enabling network con-
nectivity on tiny edge devices and providing new services
which have not been available with reasonable cost. Key
challenges in the realization of IoT systems and applications
are to minimize edge nodes deployment cost and maintenance
cost. It is because the number of required edge nodes is much
higher than that of hand-held devices. Wireless communication
protocols, which are specially designed for IoT applications,
can minimize the hardware complexity and power consump-
tion of edge nodes. Furthermore, cloud technology providing
the common service frameworks can reduce maintenance cost
of IoT systems.
According to the possible communication ranges, we can
classify the wireless communication protocols for IoT systems
into two categories: short range communication protocols
and long range communication protocols. WiFi, Zigbee, and
Bluetooth are representative short range communication pro-
tocols for IoT. These protocols are appropriate for indoor
environment. Except for the short wireless link between edge
nodes and wireless gateways, this type of IoT systems use
legacy wired networks and application servers.
Meanwhile, LoRa [1] and Sigfox [2] are representative long
range wireless communication protocols for IoT. The edge
terminals of LoRa or Sigfox systems can operate several
years without battery replacement. At the same time, the
communication range of these terminals is tens of kilometers.
These protocols are suitable for outdoor situation such as
agricultural data sensing or civil infrastructure monitoring.
Different from short range IoT systems, these long range
IoT systems additionally require network servers between
wireless gateways and application servers for more efficient
radio resource management considering the channel status of
multiple wireless gateways.
There have been a number of studies on the realization
of the IoT application server on cloud platform [3] [4] [5]
because the application program interfaces (API) provided by
978-1-4673-9486-4/16/$31.00
c 2016 IEEE
431
Customer Customer
Application Application
Packet Forwarding
LoRaWAN LoRaWAN
Slave Master
Packet Forwarding
HAL HAL Socket Socket Socket Socket
Ethernet/ Ethernet/
LoRa PHY LoRa PHY Ethernet Ethernet
3G/WiF/.. 3G/WiF/..
Terminal Gateway Network Server Application
Server
Fig. 1. Structure of LoRaWAN system
cloud platform allow fast IoT application deployment and low
maintenance cost. However, the implementation of network
servers, which are tightly coupled with wireless gateways and
terminals, on cloud platform has not been studied yet. Usually
this type of radio network control devices have been imple-
mented on a specially designed embedded system. However,
the IoT systems operate with much relaxed timing constrains
and it allows the implementation of the network server on a
cloud platform running on general purpose hardware.
In this paper, we showed our implementation result of
the LoRa network server on the OpenStack based cloud
platform, LoRaCloud system. We selected the LoRa protocol
because it is an open standard system while the Sigfox is a
system based on private standards. We also selected OpenStack
amoung possible cloud platforms because it is widely used.
For building evaluation system, we used commercial LoRa
terminals and gateway. In the implementation of the LoRa
network server on cloud platform, network scalability is one of
the most challenging issues in order to efficiently cope with the
expected traffic volume increase without service interruption
or software change. As a solution, we divide the function of
the LoRa networks server into four virtual machines (VM),
gateway agent VM, application server agent VM, data process-
ing VM, and control VM. Except for the control VM that is
responsible for control plane signaling, other three VMs can be
distributed on network without substantial overhead. Another
challenge is to fully utilize the existing service APIs of the
OpenStack. For this purpose, we restructure the functions of
the LoRa network servers into a combination of OpenStack
APIs. We implemented a number of management operations
with the OpenStack APIs such as account management and
terminal deployment.
 Network Server
UI (Horizon)

Terminal Gateway Life Cycle Authentication Application

Management (Heat) (Keystone) server
Compute(NOVA) LoRaWAN
T1
Control
T2 Gateway
Agent LoRaWAN App. Server
Data Agent
T3 Gateway
Agent App. Server
T4 Agent

...

...

...
T5
Gateway
Agent App. Server
T6 LoRaWAN
Agent
Data
Gateway
Agent
T7

T8 Metering Networking
Image (Glance)
(Celiometer) (Newtron)

Fig. 2. Structure of network server implemented on the Openstack platform

II. P RELIMINARY In 4G cellular network system, MAC operations are fulfilled

A. LoRaWAN
As shown in Fig. 1, the LoRa system consists of the
following components: terminal, gateway, network server, and
application server. Terminal is an edge device that is in-
stalled on remote sites. Meanwhile, gateway bridges packets
between LoRa terminals and LoRa network servers. The
gateway terminates wireless LoRa physical layer protocol
and converts it into backhaul network protocols. Network
server is responsible for upper layer protocols of IoT systems.
It exchanges MAC/L2/L3 control signaling messages with
terminals. Application server is used to process data collected
from IoT terminals. Usually the application server is operated
by different organizations. Thus, it is independent of IoT
network protocols.
The LoRa protocol is effective at IoT applications where
low data rate is required and poor power supply and network
connectivity are expected. Long range wireless communication
with low power consumption is achieved by exploiting the low
data rate characteristics of these applications. Most previous
wireless communication systems have been designed to maxi-
mize its peak data rate, but LoRa achieves long communication
range and low power consumption by sacrificing its peak data
rate [6].
The functions of LoRa network server can be classified into
three categories: medium access control (MAC), encryption,
and management operations. MAC operation manages radio
resources so as to maximize its network throughput. For this
purpose, LoRa network server gathers channel status infor-
mation and controls data transmission interval of terminals.
in basestations which are corresponding to the gateways in
the LoRa system. However, in the IoT system, this operation
can be performed at the network server because of its non
realtime and low data rate characteristics. It reduces the device
cost of the gateway and eventually substantially decreases the
deployment cost of IoT systems. Encryption is essential to
protect the data collected by LoRa terminals. Management
operation is related to the installation and uninstallation of
devices and application services.
Data plane operations of LoRa network server consists of
uplink operation and downlink operation. Uplink is for the
data transmission wireless link from LoRa terminals to LoRa
gateways. Downlink corresponds to the opposite communica-
tion direction. One unique characteristic of uplink is that one
transmission of data from a LoRa terminal can be received
at multiple LoRa gateways. It is caused by the simplified
MAC protocol of LoRa system, which does not have gateway
selection procedure. The simpler MAC procedure in the LoRa
terminals results in the higher power efficiency. Although it
is not explicitly specified in its specifications, the multiple
reception of the same data requires a selection procedure in
the LoRa network server. In the downlink communication,
the network server needs to select a optimal gateway among
candidate ones. The computational overhead for the gateway
selection depends on channel status. Unstable channel status
may increase the complexity of the gateway selection opera-
tions.

432
B. OpenStack
OpenStack is one of most popular open source cloud
Network for LoRa
platforms [7]. This platform provides fundamental functions Network Server

commonly required for building application services on cloud

environment such as computation, networking, storage, user
interface, authentication, telemetric, etc. It allows the building
of cloud services to be fast, easy, and independent of hard-
ware/software platforms.
In the utilization of the OpenStack on IoT service platform,
one of the key challenges is to restructure the operations for
IoT services into a collection of service application program
interfaces provided by OpenStack. OpenStack allows the au-
tomation of management operations, which are also important
to minimize the network operation cost.
III. L O R AC LOUD
A. LoRa Network Server on OpenStack
Fig. 2 shows the design result of the LoRa network server on
the OpenStack platform. In our design, The functions of LoRa
network server are divided into four VMs: i) gateway agent,
ii) LoRa data, iii) LoRa control, and iv) application server
agent. The gateway agent VMs terminate the transport protocol
between the LoRa gateways and the LoRa network server.
Similarly, the application server agent VM terminates transport
protocol between the LoRa network server and the application
server. LoRa data VM performs data plane operations which
are discussed in the previous section. The LoRa control
VM performs control plane operations by exchanging control
message with LoRa gateways or LoRa terminals.
Control plan processing and data plan processing are sep-
arated because of the difference in their scalability require-
ments. In IoT system, most traffic handled by the network
server is data traffic not signaling message. Data plan pro-
cessing can be more easily saturated. We also separate the
application server agent as an independent VM because each
application server could require different protocol for inter-
facing with them. The gateway agent is separated for better
maintenance. Each gateway may be provided by different
vendor and require subtle difference on its protocols. These
VMs are managed by the Nova package of the OpenStack.
VMs corresponding to these four functions are created and
deleted by the Nova package. In order to provide the net-
work connection between VMs, the Neutron package of the
OpenStack is used. It provides an unified network service to
VMs without concerning the details of underlying physical
networks, for instance, between the VMs within the same
processor core or VMs between different server machines.
Software defined networking is an underlying technology of
Nova package. We used Horizon for user interface, Keystone
for authentication and account management, Heat for software
life cycle management, Glance for virtual machine image
management, and Ceilometer for process load metering.
B. Management Operations
Because management operations are different according to
the service providers, we focused on a limited number of
Network for
LoRa Gateways Console for LoRa Network Server Instance
Console for LoRa Gateway
OpenStack
LoRa Terminal LoRa Gateway
Dashboard
Fig. 3. Implementation result of LoRaWAN evaluation system
management operations which are common to all systems:
i) application server management, ii) LoRa gateway manage-
ment, and iii) LoRa terminal management.
Then we update the configuration information of the gate-
way agents blocks, LoRa data blocks, and LoRa control
blocks. In our design, because a set of gateway agent blocks
and LoRa data blocks have tight interaction, we placed these
blocks on a VM instance. The addition of a new gateway may
result in the change of operation parameter of the existing VM
instance for the gateway agent blocks and LoRa data blocks
if system resource is enough. Otherwise, we invoke a new
VM instance for the new gateway. The addition or removal of
new LoRa terminals only results in configuration change of
existing instances.
IV. E VALUATION
A. Evaluation System
We built an evaluation system with commercial devices and
open sources as shown in Fig. 3. The evaluation system can be
divided into two parts: an access network and a cloud network.
In the implementation of access network part, we used IoT
station 868 produced by Kerlink [8] as the LoRa terminal.
We used SK-iM880A produced by IMST [9] as the LoRa
Gateway. Its software structure can be classified into three
parts: firmware, hardware adaptation layer (HAL), and cus-
tomer application layer. Firmware is only available in the form
of a binary image. There were two options on the HAL. One
is provided by Kerlink and the other by Semtech. We used the

433

Packet from LoRa Gateway : Status Packet from LoRa terminal : Join Request
Fig. 4. Screen shot of console terminal of VM instance for the LoRa network
server
Fig. 5. Screen shot of management window for the addition of a new
application server
Semtech’s version of HAL because it is open source. Customer
application layer includes well-known gateway function that
switches packets between LoRa terminals and networks server.
In the implementation of cloud network part, we installed the
Liberty version of the OpenStack on Ubuntu desktop version
14.04 LTS. The four LoRa networks gateway functions are
instantiated as VMs.
On the dashboard of the OpenStack, we built two networks,
one is an external network for the communication with LoRa
gateways and the other is an internal network for the commu-
nication between VMs comprising the LoRa network server.
B. Evaluation Results
Fig 4 shows the screen shot of a VM instance for the LoRa
network server. As an initial step, we instantiated only one VM
by placing all functions within one instance. The first message
is ”status report” message sent from the LoRa gateway. It
shows that the identifier of the gateway is -86, 85, 90, 0, 0,
6, 3, -115 in decimal number format and all statics for data
transmission and reception are zero. The second message is
originated from the LoRa terminal for its joining to the LoRa
434
network server. In this case, the data payload from the LoRa
terminal was written in JSON format. It represents the LoRa
terminal invoking a join request message with two identifiers,
one representing hardware and the other application.
Fig 5 shows the screen shot of a management window
for the addition of a new application server installation. This
example is shows a case to add application server ”new” to
an existing LoRa network ”LoRaWan.” In this example, the
IP address of the new application server is ”192.168.10.179.”
From this result, we can see that complex management oper-
ations can be simplified.
As a next step, we will enhance the evaluation platform to
perform all management operations mentioned above without
service interruption. In addition, we will activate big data
processing engine on the proposed platform. High data volume
is one of the fundamental challenges in most IoT systems. Data
pre-processing in the LoRa network server and LoRa gateway
may mitigate processing power problems in the application
server. Because the OpenStack platform already have packages
for the big data processing, we could exploit that.
V. C ONCLUSION
In this paper, we showed the implementation result of the
LoRa network server on the OpenStack platform. We classified
the operations of the LoRa network server into four blocks,
gateway agent, application server agent, LoRa data, and LoRa
control, with considering system scalability and maintainabil-
ity. Based on this design, we built an experimental system with
fundamental features by using available commercial hardware
and open source softwares. We will improve this experimental
system so as to validate the our system design for system
scalability and maintainability.
ACKNOWLEDGMENTS
This work was supported by Institute for Information &
communications Technology Promotion(IITP) grant funded
by the Korea government(MSIP) (No.B190-15-2012, Global
SDN/NFV OpenSource Software Core Module/Function De-
velopment)
R EFERENCES
[1] LoRa Alliance, “Lorawan specification,” Jan. 2015.
[2] Sigfox. [Online]. Available: http://www.sigfox.com/en/
[3] H. Chang, A. Hari, S. Mukherjee, and T. Lakshman, “Bring the cloud
to the edge,” in Proc. IEEE INFOCOM Workshop on Mobile Cloud
Computing, April 2014.
[4] F. Longo, D. Bruneo, S. Distefano, G. Merlino, and A. Puliafito,
“Stack4things: an openstack-based framework for iot,” in Proc. Inter-
national Conference on Future Internet of Things and Cloud, Aug. 2015.
[5] G. Merlino, D. Bruneo, S. Distefano, F. Longo, and A. Puliafito, “En-
abling mechanisms for cloud-based network virtualization in iot,” in Proc.
IEEE 2nd World Forum on Internet of Things, Dec. 2015.
[6] J. Petajajarvi, K. Mikhaylov, A. Roivainen, T. Hanninen, and M. Pet-
tissalo, “On the coverage of lpwans: range evaluation and channel
attenuation model for lora technology,” in Proc. of 14th Internation
Conference on ITS Communications, Copenhagen 2015.
[7] Openstack open source cloud computing software. [Online]. Available:
https://www.openstack.org
[8] Kerlink. [Online]. Available: http://www.kerlink.fr/en/products/
[9] Wireless solutions by imst gmbh - sk-im880a. [Online]. Available:
http://www.wireless-solutions.de/products/long-range-radio/sk-im880a