43
LoRaWAN is a communication protocol that bases on LoRa and specifies mainly the
medium access control (MAC) layer and network topology [9]. The LoRaWAN
specification defines three transmission classes for end-devices. According to the
specification, LoRaWAN devices must be able to implement at least Class-A [10]. In
Class-A, the communication is based on an access method similar to pure-ALOHA. End-
devices always initiate the communication. An uplink message is followed by two one-
second intervals for incoming downlink messages from the network server [14].
Acknowledgements of incoming messages are optional. The procedure requires only little
coordination effort. However,
due to collisions, there is much more data loss with an
increasing number of sent messages [11]. To keep the protocol as simple as possible,
LoRaWAN only offers a stars-of-stars topology. Here, many end-devices communicate
via gateways with a network server. According to the current LoRaWAN specification,
direct point-to-point communication between the end-devices is not possible [12]. This is
a problem for the approach of distributed verifiable identities: central instances are avoided
for security reasons and the network nodes verity their respective identities.
LoRaWAN defines three types of devices (Class A, B and C) with different
capabilities [2]. Class A devices use pure ALOHA access for the uplink. After sending a
frame, a Class A device listens for a response during two downlink receive windows. Each
receive window is defined by the duration, an offset time and a data rate. Although offset
time can be configured, the recommended value for each receive window is 1 sec and 2
sec, respectively. Downlink transmission is only allowed
after a successful uplink
transmission. The data rate used in the first downlink window is calculated as a function
of the uplink data rate and the receive window offset. In the second window the data rate
is fixed to the minimum, 0.3 kbps. Therefore, downlink traffic cannot be transmitted until
a successful uplink transmission is decoded by the gateway. The second receive window
is disabled when downlink traffic is received by the end-device in the first window. Class
A is the class of LoRaWAN devices with the lowest power consumption. Class B devices
are designed for applications with additional downlink traffic needs. These devices are
synchronized using periodic beacons sent by the gateway to allow the schedule of
additional receive windows for downlink traffic without prior successful uplink
44
transmissions. Obviously, a trade-off between downlink traffic and power consumption
arises. Finally, Class C devices are always listening to the channel except when they are
transmitting. Only class A must be implemented in all end-devices, and the rest of classes
must remain compatible with Class A. In turn, Class C devices cannot implement Class B.
The three classes can coexist in the same network and devices can switch from one class
to another. However, there is not a specific message defined by LoRaWAN to inform the
gateway about the class of a device and this is up to the application.
Figure 1 – LoRa classes and band
LoRaWAN defines the communication protocol and
system architecture for the
network while the LoRa physical layer enables the long-range communication link. The
protocol and network architecture have the most influence in determining the battery
lifetime of a node, the network capacity, the quality of service, the security, and the variety
of applications served by the network.
LoRa uses Industrial, Scientific, and Medical (ISM) frequencies, and every country
or region has its frequency band. Europe uses 868 MHz, while the USA, Brazil, and
Australia use 915 MHz, for example. Each country also uses a sub-band frequency scheme
to create channels of transmissions. Each sub-band is composed of several frequencies
called channels.
Australia, for example, uses sub-bands composed of eight channels
(frequencies) using 125 kHz bandwidth. The sub-band is essential to separate networks in
the same area by using different frequencies. non-specialized SRD devices operating in
the frequency ranges 863-868 MHz with a channel width of 100 KHz (up to 25 mw) can
be used on the territory of the Republic of Kazakhstan without obtaining permits.
45
The goal of this article is to bring some sanity to these statements, by providing a
comprehensive, fair and independent verification and design of LoRaWAN security with
RSSI-position and Byzantine Fault Tolerance.
We design and verify the model for LoRaWAN with RSSI-position and Byzantine
Fault Tolerance. Section II analyzes the methods of design and verification of the
technology. Section III discusses the results of verification models to using BFT and RSSI-
position for LoRaWAN security.
Research methods
. We have placed our effort in researching
and identifying the
formal verification and LoRa WAN mesh protocol, testing the Sensor Chain
Communication tree, verifying our model, starting programming with LoRa. Figure 2
describes the algorithm of determine accept / reject of Distrust – Alerts.
BFT protocols are commonly designed to achieve state-machine replication, where
processes agree on an ordered set of incoming requests from clients, creating an input log
that is equal on all processes. Running a deterministic state
machine on the log then
produces the same results on each node. The design goals in this problem space are usually
low latency and high throughput, enabling the protocol to handle a high volume of requests
quickly.
This paper considers the related but slightly different problem of BFT log replication.
In this problem, a set of n nodes, of which at most f may fail, periodically run a distributed
algorithm to maintain a log [1].
We have successfully validated the first model of Sensor Chain Communication Tree.
We are currently making new modifications for the testing of our model.
