More efficient IoT communication through LoRa
network with LoRa@FIIT and STIOT protocols
Ondrej Perešíni, Tibor Krajčovič
Slovak University of Technology in Bratislava
Faculty of Informatics and Information Technologies
Ilkovičova 2, 842 16 Bratislava, Slovakia
ondrej.peresini@stuba.sk, tibor.krajcovic@stuba.sk
Abstract—This paper describes a concept of Internet of Things
using Low-power Wide Area network based on LoRa wireless
technology, LoRa@FIIT link layer protocol and STIOT network
protocol. LoRa technology is proprietary owned by Semtech and
the most common implementation relies on open source
LoRaWAN network protocol. This protocol is robust and
versatile however it has a quite high overhead and therefore
devices with limited duty cycle can transmit useful data only a
fraction of associated time. Therefore we decided to propose a
more efficient LoRa@FIIT link layer protocol and versatile
STIOT network protocol for devices with highly limited
resources.
Index Terms—IoT, LoRa, network server, LPWA
I. INTRODUCTION
Nowadays, we are able to see massive increase of using a
concept called Internet of Things. This concept represents a
complex system of many various devices connected to the
network and internet via any possible technology in order to
build more sophisticated and complex system which is
adaptable to the environment in real time. This model of the
system brings extensive usage of sensor devices called nodes
which collect specific data for calculations, representations or
they serve as triggers for specific events of some part of the
system. The nodes are connected to gateways in a star topology
and gateways mediate communication to a server. To improve
comfort in usage, the nodes are mostly connected via wireless
technology and there are a lot of ways to make it work. For
example, we are able to monitor parking slots availability in
the city, build smart lighting which is weather adaptive, make
soil moisture measurements to know how much water does the
area need and much more [1] Gartner, Inc. expects that there
will be 20.8 billion connected devices by 2020 [2].
There are many different ways how to achieve benefits of
IoT concept. One of the most important decisions is to choose
and build the physical layer of the network properly, which
structure heavily depends on the use case. Currently there are
many possibilities to choose from. Good examples are
Bluetooth, various mobile networks and low-power wide area
networks (LPWAN) like LoRa wireless technology [3].
Since the goal is to build a robust smart system, sending
raw data is considered too few usage of abilities. Other
decision, which mostly users make, is to choose convenient
standard also depended on the actual use case. The offer of
existing protocols is quite large, but there is also a possibility
of defining the custom one which will be more suitable for
specific use cases. In the following chapters we will describe
proposed protocols for link layer and network layer
connectivity.
II. AN OVERVIEW OF THE LORA NETWORK
In simple terms, Lora represents a physical layer in OSI
model. It specifies how data is sent over the air. In our proposal
a LoRa transmission serves as a first (physical) layer of our
3-layer concept. Second layer can be handled by LoRa carrier
protocols like LoRaWAN or the proposed LoRa@FIIT. These
protocols facilitate the communication between end device and
LoRa Gateway. Third network layer is responsible for
delivering IP packets between LoRa Gateways and Network
server which is responsible for network, admission and
performance control of the whole LoRa wireless domain.
A specific hardware is needed for receiving LoRa
transmission from end devices which must be in the range of
end devices signal. Devices with hardware supported listening
and transmission of LoRa signal are named gateways. Their
main goal is to receive LoRa communication, process it and
encapsulate it to more standard IP communication. Multiple
gateways, which belong to the one network, may cover wide
area and they need to be coordinated by the network server. All
gateways send all their data to the main server, so the data is
processed in one place.
Gateways and the network server can facilitate various
standards and protocols for mutual communication.
LoRa@FIIT or LoRaWAN does not specify the protocol to be
used for this communication. Therefore, we propose our
multipurpose protocol STIOT for this communication and
describe the use of STIOT with layer 2 protocol LoRa@FIIT.
We also describe differences between existing solutions like
MQTT and specify the advantages and common use cases for
STIOT. The first decision for implementing STIOT was to
specify the separation of work between server and gateways.
The main purpose of a gateway is to bridge the communication
between server and end devices by processing and re-
encapsulating it between layer 2 and layer 3 protocols. In
contrast to LoRaWAN our proposed gateways serve two more
purposes, calculating their own duty cycles and informing the
server about it with the key duty_c. Gateways also decrypt
LoRa@FIIT messages and send decrypted data over more
secure TLS connection which is achieved by using extra
messages KEYS, KEYR and KEYA.
III. LORA@FIIT SPECIFICATION
LORA@FIIT is a proposed link layer communication
protocol for LoRa network which has a unique modulation
format. By default, radio chips using LoRa modulation provide
simple packet structure composed of preamble, header, CRC,
payload and CRC of payload. There is an option to choose
implicit mode without header and CRC. We have created a
protocol which specifies the inner structure of payload, its
contents and block distribution in packets. The integrity of
received packet is checked by CRC and the integrity of
payload by the payload CRC. The header carries information
about the length of payload in bytes, the information about the
forward error correction code rate and the presence of an
optional 16-bit CRC for the payload. Some parts of payload are
encrypted using the XXTEA algorithm.
A. Message types
LoRa@FIIT protocol is prepared to distinguish between
four basic message types according to its content:
• Data message
• Hello message
• Emergency message
• Register message
Sending a message from node to gateway is considered as
an uplink message. Any message with the opposite direction is
called downlink message. Each message contains the data type
which informs what type of message is transmitted with
direction included, its acknowledgment requirements and
a lock of device’s id to identify the certain node. All messages
are padded to the block size of 32 bits (for encryption with
XXTEA which has a 32-bit block size and minimum size of 64
bits). Acknowledgement messages, like data messages, are
simple. However, they come without the payload.
1) Data message
The data message is reserved for a sending data, either for
an application data or for a network data. Apart from the
general blocks, uplink data message is equipped with blocks
carrying information about the length of the payload, the
sequence number of the message, message integrity code and
the main content in application payload block. Downlink data
message is enriched with network data having a specified size
in network data length. The block carrying network data type is
meant to inform the node about what kind of network data is
in the following blocks - the number of elements followed by
the field values or one value. The user is able to alter the code
rate, frequencies, power, spreading factor, emergency
frequency and frequency of sending a hello message. All these
network configuration settings may be changed using the
network data.
2) Hello message
The user is able to take advantage of sending a special
“hello” message. This message has been created for the cases,
when there is no need to send any data for a longer period of
time in uplink direction, but the amount of information about
actual life status of a node is not sufficient.
3) Emergency message
Sometimes a network topology change may occur and
actual network configuration settings may be inadequate or the
communication is interrupted because of some reason. This
situation may be detected by non-received acknowledgment on
the side of a node. For this case the protocol defines emergency
message which is transmitted using different network settings
(f.e. transmission power, spreading factor, frequency, e.g.). The
programmer decides maximum number of retransmissions
before sending an emergency message. If any gateway receives
the emergency message, then the gateway generates more
powerful network configuration settings for that node and
sends it a command to reconfigure communication parameters
using the new settings.
4) Register message
The process of registration of a node to a certain gateway
begins with sending a register message to the gateway which
also initiates authentication attempt. Register authentication is
based on a Diffie-Hellman key exchange. The uplink register
message contains a Diffie-Hellman key A. The answer to this
message is a downlink register message which provides a
Diffie-Hellman key B. After this exchange, both devices
generate their common secret shared key which is used for
payload encryption using symmetric XXTEA algorithm. Each
device generates its own code to communicate with gateway.
The downlink register message contains network configuration
settings and may include application data.
B. Packet Structures
The four types of messages may be sent in prepared
packets. The protocol defines two packet structures for the
uplink direction and two packets structured for the downlink
direction.
Uplink register message structure:
Downlink register message structure:
Uplink data, hello or emergency message:
Downlink data or emergency message structure:
Fig. 1. LORA@FIIT packet structure
Figure 1 overviews all needed packet structures. The white
blocks represent unencrypted parts and the blocks which are
filled with black color represent encrypted part of packets. p LoRaWAN. It is very beneficial to send the short messages
Padding may be added to the end of any packet. The register with a minimal user data payload to save a duty cycle.
messages need their own packet structure because of a Security is extremely important for any network.
demand on sending a Diffie-Hellman code A and B. The other LoRa@FIIT provides encryption for all transmitted data except
messages are composed of the common packet structures. of "Device id" block, "type" block and "Diffie–Hellman key"
Description of all packet structures is presented in the Table I. block in register messages which does not need to be
encrypted. An XXTEA algorithm is used for data encryption
TABLE I. PURPOSE OF THE BLOCKS which allows us to send shorter messages with less padding
Key name Description
compared to LoRaWAN (32-64b vs. 128b). LoRaWAN uses
DEV_ID The unique id of a node AES-128 encryption and therefore sending a short message
TYPE The set of bits that distinguishes four types of messages
requires a lot of padding. LoRa@FIIT padding costs less duty
cycle and it allows us to send messages more often, with fewer
DH_A The code that is used for Diffie-Hellman key exchange
hardware resources (RAM, etc.), therefore it saves battery
DH_B The code that is used for Diffie-Hellman key exchange
lifetime and manufacturing costs.
N_LEN The length of network data block
There are some more battery optimizations during receiving
N_DATA The network data
process where end device opens receive window only when
A_LEN The length of application data block
needed (acknowledgment is requested) and not every time the
A_DATA The application data end device transmits as in a case of LoRaWAN protocol.
SEQ The sequence number of message LoRa@FIIT distinguishes three types of acknowledgments.
MIC The message integrity code First type is Non-ACK and it does not require
acknowledgment. Second type is optional-ACK which does not
A block structure Type distinguishes between specified require direct acknowledgment. An end device opens a receive
message types and the requirement for an acknowledgment. window to receive configuration data from a server after the
message has been sent. The third type of acknowledgment is
TABLE II. TYPE BLOCK VARIATIONS ACK. This message requires acknowledgment from the server
0. 1. 2. 3. 4. 5. 6. 7.
to verify that the message was delivered correctly. If no
Message type, bit
Uplink register 0 0 0 RFU 1 1 F
acknowledgment is received, then the sending process is
repeated few times. In case of multiple unsuccessful sending
Downlink register 1 0 0 RFU 1 1 F
attempts, user payload could be sent via Emergency message
Uplink data 0 0 1 RFU X X F
with maximum transmission output power and different
Downlink data 1 0 1 RFU X X F
network settings for higher delivery probability. We can save
Uplink hello 0 1 0 RFU X 1 F
battery lifetime and duty cycle thanks to adjustable ACK. All
Uplink emergency 0 1 1 RFU 1 1 F of these benefits help to achieve an optimal functionality,
coverage and battery life. Also LoRa@FIIT does not create any
The three most significant bits distinguish between message useless background noise.
types and bits 5 and 6 contain information about the Each end-device has to be activated to participate in a
requirement of acknowledgment. The “RFF” represents bits LoRa@FIIT network. Network activation of LoRaWAN
reserved for the future use and “X” means optional. devices can be achieved in two ways, either over the air by join
Acknowledgment is determined as following: procedure or with activation by personalization (APB).
• 00 - no acknowledgment Activation in LoRa@FIIT is performed only over the air
• 01 - optional acknowledgment (OTAA), using the "Register" messages. Due to the
• 11 - mandatory acknowledgment LoRa@FIIT limitation to single network key it is not easily
All other options are reserved for the future use. possible to achieve roaming. To partially overcome this issue,
the message contains "DEV_ID" block which provides up to
C. Comparison of LoRa@FIIT with other link protocols 24 bits of end device IDs, that allows to connect up to 16 777
Main reason to design LoRa@FIIT is to revamp the 216 end devices in one LoRa@FIIT network segment.
shortcomings of LoRaWAN [4]. LoRaWAN protocol has a
few extra features like Roaming ability and port numbers IV. STIOT SPECIFICATION
which are not mandatory in LoRa@FIIT because standard use STIOT is a TCP-based protocol designed to transfer data
cases do not require them. However, LoRa@FIIT can be between the network server and gateways in LoRa networks.
further extended via RFU fields. Its name is an acronym for Secured TCP for IOT.
The main reason for the LoRa@FIIT is to decrease the The main design priority was to make the protocol secure
amount of useless overhead of LoRaWAN. Whilst the and reliable. We decided to use TLS (SSL) for end to end
LoRaWAN uplink message with 1B user payload has a total encryption and server authentication via public certificate. SSL
size of 29B, the LoRa@FIIT message uses only 12B. This relies on TCP for the transport layer of his secured data [5].
helps to maintain extremely efficient communication which TCP uses many techniques like acknowledgments, sequences,
uses only 42% of a duty cycle and battery compared to keep-alives for reliable communication [6].
 The second decision was to use some kind of key-value transmission. Then this PARAM objects are converted to
data format. Based on our analysis we have chosen JSON, as it meaningful layer 2 message on the gateway.
is human readable and well supported. Extra messages KEYR, KEYA and KEYS are added to
One of key features of STIOT is its flexibility. We have synchronize specific values with server and gateways. Key
focused on making it adaptable and usable for other layer 2 dev_id is the only predefined key which is used for getting and
(LoRa carrier) protocols. We defined general form of messages updating data at a shared database table on the server. In a case
where every message has its predefined keys and array of of LoRa@FIIT, we use these messages to sync session keys
values. STIOT specifies 10 types of messages, which can be (key) and sequence counters (seq) between gateways and
separated into 3 groups (GATEWAY_SETUP, server. Gateway uses KEYR message for requesting shared
DEVICE_REGISTRATION, DEVICE_TRANSMISSION). information. With KEYA message server answers to KEYR
Messages can be altered by adding more keys specific for used request. KEYS message serves to update shared information.
layer 2 protocol. In our case, we also added some keys to make All extra messages are described in section D in more details.
LoRa@FIIT work better with STIOT.
C. DEVICE_TRANSMISSION messages
A. GATEWAY_SETUP messages The main group DEVICE_TRANSMISSION contains just
First group GATEWAY_SETUP contains 2 messages 2 messages RXL and TXL. RXL message contains data from
SETR and SETA. The main purpose is to start communication end device and its transmission parameters (RSSI, SNR, etc.).
between server and gateway. In case of LoRa@FIIT protocol data is decrypted from
The gateway first sends SETR message which contains LoRa@FIIT and striped down to just application data.
information about the STIOT version and the protocol used for Complete structure of TXL messages is presented in Table III.
layer 2 LPWAN transport. The key values for these parameters TXL messages are very similar to REGA messages, both
are ver and lora_stand that are consisting of 2 strings contain application data, network data and additional fields of
representing name and version. Gateway also sends its dev_id and power which are presented in Table IV. In a case of
hardware capabilities in these keys: m_chan, channels, TXL messages, we do not need a pre-shared key anymore.
sup_freqs, sup_sfs, sup_crs, sup_bands and max_power.
If the key id received from the gateway is correct than TABLE III. RXL MESSAGE
server responds with SETA message. In this message a server Key name Value type Description
is sending an array of one or many objects PARAM containing time Integer Timestamp of reception
parameters for receiving LoRa transmission. They are dev_id String End device id
accessible by the following keys: cr for code rate, freqs for
rssi Integer Signal strength
frequencies, band for bands, sf for spreading factor and power
snr Integer Signal noise ratio
for transmission power.
data String Base64 string of data
B. DEVICE_REGISTRATION messages conf_need* Boolean End device needs reconfiguration
Next group DEVICE_REGISTRATION is intended for dutty_c* Integer Count of messages of 1 byte
online registration of end devices. The main messages are ack* String Type of acknowledgment
REGR and REGA. When gateway accepts end device request seq* Integer Sequence number
for registration, it will send REGR message containing *LoRa@FIIT specific key
identification of the sender (dev_id) and layer 2 message
reception parameters like signal strength (rssi), signal noise TABLE IV. REGA/TXL MESSAGE
ratio (snr), bandwidth (band), code rate (cr), spreading factor
Key name Value type Description
(sf) and time of reception (time). For further explanation,
dev_id String End device id
values in brackets represent key names in REGR message. In a
power Integer Transmit power
case of using STIOT with the LoRa@FIIT, the gateway will
app_data String Base64 string of data
send extra information for duty cycle calculation (duty_c).
net_data Array of PARAM Array of objects containing
If received information from REGR message is correct, the
objects network settings
server answers with REGA message. This message contains sh_key* String Shared key for generating
information about transmission power (power) and end device session key
id (dev_id). In a case of LoRa@FIIT, we added one key sh_key *LoRa@FIIT and REGA specific key

for sending a pre-shared key to the gateway. The message also
contains first configuration or useful data destined for the end
device piggybacked in app_data string key and net_data key.
We separated data into application data (app_data) and
network data (net_data). Application data is just raw data
encoded to string with Base64 coding. A different approach
was taken with network data which is sent like an array of
PARAM objects containing various parameters for LoRa
The last message is an ERROR message which does not
belong to any of previous groups. If there is a problem, this
message will be used to describe the problem with id number
represented by error key name. For more verbose information,
error_desc key for description was added.
D. STIOT communication
GATEWAY_SETUP messages are the initial messages
sent between server and gateways. Gateway initiates
a communication with the server by connecting to its domain
name. Before any data is sent, communication is secured via
TLS (SSL) by authenticating server with its TLS certificate.
The gateway does not need to authenticate itself with TLS
compatible certificate, however the server can authenticate
gateway by id in SETR message. After server received correct
SETR message, server will respond with SETA message to
finish gateways setup process.
After this exchange of messages, the TSL (SSL) connection
will be opened. Gateway needs to send keep-alive messages
periodically to keep the communication open. The
communication is closed only if a network problem occurs. In
this case, gateway tries to connect with the server. An example
of this communication is pictured in Figure 2.
Fig. 2. Start of communication
Fig. 3. Registration of end device
DEVICE_REGISTRATION messages are sent when end
device wants to register to a server. Gateway accepts layer 2
message for registration and converts it to REGR message. If
the end device is known to a server, it will accept the request
and it will send the REGA message for the gateway. Gateway
can create answer message for end device afterwards.
When LoRa@FIIT protocol is in use, the gateway will
finish the end device registration by updating session key and
sequence number in server database with KEYS message.
The gateway, which does not have the most recent session
key and sequence number for the end device, can request this
information from server with KEYR message. If the request is
correct, server will send KEYA message. Good example of
device registration and key request is in Figure 3.
DEVICE_TRANSMISSION messages can be described as
simple request and answer messages. The difference is that a
server does not respond to gateway if server has no data for end
device. In case of problematic message both server and
gateway can respond to accepted message with error message.
E. STIOT support for layer 2
In this part, we want to summarize everything needed to
add a layer 2 protocol compatibility to STIOT. At first, you
need to specify protocol names and version. At startup every
gateway sends a SETR message which contains following
information. If your protocol needs extra keys, you must
specify in which messages these keys are used.
It is mandatory to specify at least one type of object
PARAM which will be used for gateway setup. If you want to
use network data, you must also specify the type of PARAM
object which will be transformed on a gateway to your layer 2
message.
F. Comparison of STIOT with other network protocols
STIOT protocol can be assigned to machine to machine
group of protocols. Other protocols included in this group are
MQTT, CoAp, OMA_LWM2M and some more.
The basic M2M LoRa protocol is available at Semtech
example code on GitHub. It is a simple UDP based server
client protocol for LoRaWAN using JSON for its data
structure. Our STIOT protocol also uses JSON for its data
structure but messages are more complex. STIOT is also
created to support more than one layer 2 protocol (for example
for both LoRa@FIIT and LoRaWAN). Finally, STIOT uses
more reliable and secure TLS connection.
MQTT is open source standard with specification available
on oasis web pages [7]. It is used in open source LoRaWAN
server available on GitHub. MQTT is a modern TCP based
protocol with payload encryption. This protocol supports
publish/subscribe messaging model. Application like an open
source Mosquitto can be used to realize publish/subscribe
model. STIOT is just a simple server client communication
protocol which does not need message broker. STIOT is
suitable mainly for LoRa networks, while MQTT is more
generic protocol.
 V. NETWORK SERVER FOR TRANSMISSION CONTROL
LoRa transmission does not need any network control
server to be able to transfer raw data, however all network
parameters would be static and not optimal for all different
devices and scenarios. The main reason to use network server
is to control communication parameters based on current
network state and to handle end devices’ messages. It can
directly control several transmission parameters like spreading
factor (SF), communication channel, coding rate (CR),
bandwidth (BW) and transmission power. Only through
controlling these parameters can LoRa network maintain
maximum throughput with minimal power consumption. A
good example would be lowering spreading factor and
transmission power in a case of good signal reception which
would result in a lower mutual radio interferences and power
consumption. Network server must constantly calculate several
network parameters and send updates to end devices that will
apply new communication settings during next transmission.
There are several open-source network servers for
LoRaWAN like Brocaar [8] or The Things Network [9]
however they are either not compatible with LoRa@FIIT or
they are too simple and unable to control transmission
parameters. Therefore we decided to implement a new network
server for both protocols LoRaWAN and LoRa@FIIT which
would communicate with gateways through STIOT protocol.
To control transmission parameters, we proposed several
threshold levels at which the network server lowers or
increases transmission parameters. Calculations are based on
received signal strength (RSSI), signal to noise ratio (SNR),
and other parameters like remaining duty cycle and type of
acknowledgment. Duty cycle on the gateways is strictly limited
and therefore it is crucial to change those parameters only
when needed. Using LoRa@FIIT without network server
would decrease protocol overhead to 42% compared to
LoRaWAN. Additional control of transmission parameters via
network server could result in a decrease of spreading factor
from SF12 to SF7 which provides 8 times faster transmission
rate and less time in radio transmission will result in a better
battery life. In a case of good reception the network server may
further decrease transmission power from 14 dBm up to 5
dBm. All of those changes combined may result in a more than
99% of power reduction for data transmission and are handled
at the background without the need of user intervention.
Another purpose of the network server is to select correct
gateway for sending a response to end device because at a
given moment several gateways are able to reach out a specific
device. Network server must choose transmission gateway
wisely not to deplete duty cycle at any of them. Additional
purpose of a network server is to collect and process all
received data and provide API interface for applications.
VI. CONCLUSION
In this paper we have described specifications of
LoRa@FIIT protocol which is designed for a large number of
end devices and industrial use cases like processes monitoring.
It can save battery lifetime and duty cycle, leveraging the low
data transfer and planned opening of receive windows via
optional acknowledgments. Besides that, LoRa@FIIT provides
mandatory acknowledgments which can be used to guarantee
message delivery. In a case when end device will not receive
acknowledgement due to signal loss, it will start emergency
transmission on a maximal power settings. LoRa@FIIT does
not offer roaming between several LoRa@FIIT networks, but it
uses XXTEA algorithm which allows minimalization of
unnecessary padding and can send short messages while
guaranteeing security for user data. We recommend a usage of
static end devices to eliminate signal loss and to ensure the best
power consumption. However, the network server is
responsible for the network configuration of end devices and
sets up their transmission parameters in a way that every device
can maintain minimal transmission power required for reliable
communication.
The main use case for STIOT protocol is to carry messages
between end devices and network server reliably and securely.
Proposed protocol specification can be used in a
communication between a server and a gateway. STIOT
protocol can carry several different layer 2 protocols like
LoRaWAN and LoRa@FIIT and therefore it is suitable for
several different use cases of commercial and academic
networks. Future development can include additional features
like storing valuable messages from end devices to local
memory of gateways which would serve as a backup in a case
of temporary network failure.
ACKNOWLEDGMENT
The authors would like to thank for financial contribution
from the STU Grant scheme for Support of Young
Researchers.
REFERENCES
[1] Morgan, J.: A Simple Explanation Of ‘The Internet Of Things’.
Online available at:
http://www.forbes.com/sites/jacobmorgan/2014/05/13/simple-
explanation-internet-things-that-anyone-can-
understand/#68cd72246828
[2] GARTNER: Gartner Says 6.4 Billion Connected “Things” Will
Be in Use in 2016, Up 30 Percent From 2015. Online available
at: http://www.gartner.com/newsroom/id/3165317
[3] VANGELISTA, L., ZANELLA, A., ZORZI, M.: Long-Range
IoT Technologies: The Dawn of LoRa™. Online available at:
http://link.springer.com/10.1007/978-3-319-27072-2_7
[4] Sornin, N., Luis, M., Eirich, T., Kramp, T., Hersent, O.:
LoRaWAN™ Specification. ©2015 LoRa™ Alliance, (2015)
[5] INTERNET ENGINEERING TASK FORCE (IETF).: RFC
5246: The Transport Layer Security (TLS) Protocol Version
1.2. Online available at: https://tools.ietf.org/html/rfc5246
[6] INTERNET ENGINEERING TASK FORCE (IETF).: RFC 793:
Transmission Control Protocol. Online available at:
https://tools.ietf.org/html/rfc768
[7] OASIS.: MQTT Version 3.1.1 Plus Errata 01. Online available
at: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
[8] Brocaar.: Lora network server. Online available at:
https://github.com/brocaar/loraserver
[9] TTN: The Things Network. Online available at:
https://www.thethingsnetwork.org/