# Design and Prototype Implementation of a Blockchain-enabled LoRa System with
Edge Computing

Lu Hou, Kan Zheng Zhiming Liu, Xiaojun Xu, Tao Wu This work was supported in
part by National Natural Science Foundation of China (NSFC) under Grant
61731004, in part by Huawei Technologies CO.,ltd., and in part by the Key Lab
of Universal Wireless Communications, Ministry of Education.L. Hou, K. Zheng,
Z. Liu, X. Xu and T. Wu are with the Intelligent Computing and Communications
(IC2) Lab, Wireless Signal Processing and Networks Lab (WSPN), Key Lab of
Universal Wireless Communications, Ministry of Education, Beijing University
of Posts & Telecommunications, Beijing, China, 100088.Corresponding author:
Kan Zheng.Contact email<EMAIL_ADDRESS>(c) 20xx IEEE. Personal use
of this material is permitted. However, permission to use this material for
any other purposes must be obtained from the IEEE by sending a request to
<EMAIL_ADDRESS>
###### Abstract

Efficiency and security have become critical issues during the development of
Long Range (LoRa) system for Internet of Things (IoT) applications. The
centralized work method in LoRa system, where all packages are processed and
kept in central cloud, cannot well exploit the resources in LoRa gateways and
also makes it vulnerable to security risks such as data falsification or data
loss. On the other hand, the blockchain has the potential to provide a
decentralized and secure infrastructure for LoRa system. However, there are
significant challenges on deploying blockchain at LoRa gateways with limited
edge computing abilities. This paper proposes a design and implementation of
blockchain-enabled LoRa system with edge computing by using the open-source
Hyperledge Fabric, which is called as HyperLoRa. According to different
features of LoRa data, a blockchain network with multiple ledgers is designed,
each of which stores a specific kind of LoRa data. LoRa gateways can
participate in the operations of the blockchain and share the ledgers that
keep the time critical network data with small size. Then, the edge computing
abilities of LoRa gateways are utilized to handle the join procedure and
application packages processing. Furthermore, a HyperLoRa prototype is
implemented on embedded hardware, which demonstrates the feasibility of
deploying the blockchain into LoRa gateways with limited computing and storage
resources. Finally, various experiments are conducted to evaluate the
performances of the proposed LoRa system.

###### Index Terms:

LoRa, blockchain, edge computing, IoT security, Hyperledger Fabric

##  I Introduction

Long Range (LoRa), one of the low-power wide-area (LPWA) technologies, is
expected to provide energy-efficient communications to a massive number of
end-devices that are distributed in a wide area [1]. It is an attractive
solution for various Internet of Things (IoT) applications, such as
environment monitoring and Industrial IoT (IIoT) [2]. In these applications, a
great amount of IoT data can be collected by LoRa gateways in a low sampling
rate and processed by the central cloud [3]. However, there are a few
challenges that have to be solved before the LoRa systems are widely deployed.
Most of them are about how to improve the efficiency and security of LoRa
systems.

The current LoRa gateways are only responsible for the transparent forwarding
of packages between end-devices and central cloud. Then, all LoRa packages are
handled and stored in the central cloud, which undertakes all of the workloads
[4]. Therefore, the computing and storage resources in the LoRa gateways are
not well exploited. Moreover, the central cloud is far from the end-devices,
making it hard to meet the low-latency requirements of time-critical IoT
applications [5]. The LoRa systems also have their potential risks of
security. For example, the LoRa data are vulnerable to falsification and
destruction, since all of the data are gathered into central cloud [6, 7].

Thanks to the development of edge computing technologies, some of the
workloads of central cloud can be transferred to LoRa gateways, such as the
management of end-devices and the basic processing of LoRa packages.
Meanwhile, the blockchain with decentralized ledgers can help to protect LoRa
data from being falsified when it is applied in LoRa systems. Therefore, a
blockchain-enabled LoRa system with edge computing is expected to improve the
performances of LoRa systems as well as the security.

There are few existed designs on blockchain enabled LoRa systems. Most of them
can be roughly divided into two types. The former ones are to deploy
blockchain only in the central cloud, e.g. in [8, 9]. Such a design can
improve data security by the blockchain, but the edge computing abilities of
LoRa gateways are not utilized. Meanwhile, the workload of central cloud is
increased because central cloud needs to maintain the blockchain additionally.
In the latter ones, the blockchain was proposed to directly be implemented at
LoRa gateways without a specific design, which lacks of the implementation
feasibility [10]. As the increasing data of the blockchain, the computing and
storage resources in LoRa gateways might be exhausted soon. To the best of our
knowledge, none of them has provided a feasible blockchain-based solution for
LoRa with edge computing.

Therefore, this paper aims to propose and implement a blockchain-enabled edge
computing approach for LoRa systems with the open-source Hyperledger Fabric,
which is called as HyperLoRa for the sake of illustration. A blockchain
network with multiple ledgers is designed in HyperLoRa. Each node in
blockchain network shares a whole copy of ledger that keeps transactions in
chained blocks. Two ledgers are specially constructed for processing and
storing different types of data, i.e., the delay tolerant application data
with large size is in one ledger in the central cloud, while the time critical
network data with small size is in another ledger at LoRa gateways. Then, the
edge computing potentials of LoRa gateways can be well exploited. Two main
features of the network servers, i.e., join procedure handling and application
packages processing, can be migrated to LoRa gateways. As a consequence, the
workloads of central cloud can be balanced by LoRa gateways, while the central
processing unit (CPU) utilization in central cloud and the network bandwidth
required between the LoRa gateways and the central cloud can be reduced.

Moreover, a HyperLoRa prototype is also implemented on embedded hardware to
demonstrate the feasibility of our proposed design. In order to run
Hyperledger Fabric on LoRa gateways that are built upon CPU of ARM64
architecture, the embedded Linux operating system is customized to let it fit
with a third-party docker image of Fabric. Then, two channels are configured
and governed by two organizations, i.e., LoRa gateway organization and network
server organization. Each channel consists of an ordering node for consensus
and many peers that maintain a shared ledger. The LoRa gateways can request
and query transactions by invoking chaincodes via Fabric client. Moreover, the
join server (JS) and network connector (NC) modules are implemented at LoRa
gateways using the edge computing abilities. The prototype implementation of
HyperLoRa demonstrates that it is viable to integrate blockchain into the LoRa
gateways with the embedded hardware that are considered resource-constrained.
The experimental results show that HyperLoRa can have an equivalent
performance but less resource consumption compared with traditional LoRa
systems.

The rest of the content is organized as follows. The related works are
discussed in Section II. Section III provides the overview of LoRa. The design
of HyperLoRa system, as well as the edge computing functions of LoRa gateways
are given in Section IV-A. Then, the security analysis is presented in Section
V. The implementation of HyperLoRa and the experiments with the results are
elaborated in Section VI. Section VII concludes the paper.

##  II Related works

Efficiency and security issues become critical for the development of IoT
services. As a promising solution, blockchain has attracted lots of attention,
since it can ensure the data security and privacy in a distributed manner [11,
12], or provide a secure way to trade items [13]. Besides, edge computing can
provide efficient and decentralized data services, such as data analytics or
distributed machine learning at the edge, because it is closer the data source
than central cloud [14, 15]. However, due to the various requirements and the
limited resources in IoT devices, it is still challenging on how to integrate
blockchain into different IoT scenarios both theoretically and technically.

###  II-A Open-source implementations of LoRa system

There are several implementations of LoRa system, e.g., the
XisLoRa111https://github.com/xisiot/lora-system, the
ChirpStack222https://www.chirpstack.io/ and the Things Network
(TTN)333https://www.thethingsnetwork.org/. Their designs are all based on the
reference model that is proposed in [16]. XisLoRa separates a network
connection module to handle the package parsing and verification, while
ChirpStack uses a gateway bridge to communicate directly with LoRa gateways.
TTN follows the reference model and deploys one network server to handle all
kinds of requests. These implementations have two things in common. On the one
hand, all the LoRa gateways in these systems are only responsible for package
forwarding. No further work is required for LoRa gateways to finish. Thus, the
resources at LoRa gateways are not efficiently utilized. On the other hand,
all the data in these systems are stored in traditional databases, such as
MySQL (by XisLoRa), PostgreSQL (by ChirpStack) and InfluxDB (by TTN).
Therefore, these systems have potential risks of data falsification and
leakage without blockchain.

###  II-B IoT system with blockchain

In traditional IoT systems, data are stored in centralized servers, which may
cause eavesdropping and single-point bottleneck. The blockchain can be used to
build a distributed and trustful data storage method and let all related
entities to participate and supervise for data security. Among most of the
literature, blockchain for IIoT becomes a widely studied scenario. Liang _et
al._ [17] proposed a blockchain based data transmission model for IIoT. By
using secure cryptologic algorithm and decentralized consensus technique, the
power data can be transmitted in a secure way. Wan _et al._ [18] deploy a
private blockchain in IIoT architecture in order to enhance the data security
and privacy. The traditional storage layer is substituted by decentralized
blockchain network. Moreover, Zhao _et al._ [19] propose a multi-chained IIoT
platform to provide secure and decentralized data transmission between IIoT
resources and end-users. Vehicular networks can also benefit a lot by
blockchain. Kang _et al._ [20] deploy a Directed acyclic graph (DAG) based
blockchain network in vehicular networks with edge computing. DAG is
considered as a new kind of data structure for blockchain, in order to enhance
the efficiency. However, it may cause inconsistency after some time. Jiang _et
al._ [21] propose a distributed Internet of vehicles architecture with
blockchain. The transmission delay is analyzed considering the mobility of
vehicles. Blockchain can also be deployed in healthcare scenarios. In order to
avoid the health data being eavesdropped by third-party servers, a blockchain
based healthcare scheme is proposed where all end-devices, patients and
doctors participate in the blockchain network [22]. Blockchain can also
improve the progress of machine learning for IoT. Qiu _et al._ [23] propose a
collective $Q$-learning approach where the blockchain is used to share the
training results between IoT nodes in order to govern the results in an
efficient and secure way.

###  II-C Blockchain-enabled LoRa system with edge computing

As one of the promising IoT transmission techniques, LoRa is widely used for
scenarios with low-power and wide-area requirements. Blockchain is suitable
for a LoRa system to ensure data security. However, it is challenging to
integrate blockchain into LoRa system. This is because most of the end-devices
are resource-constrained. They cannot maintain ledgers in blockchain network.
Meanwhile, the LoRa gateways are not as capable as central cloud, they are
only used for transparent transmission of LoRa packages between end-devices
and central cloud. Deploying blockchain in LoRa gateways needs a re-design of
LoRa system architecture and well consideration of the resources. Liu  _et
al._ [24] propose an edge computing based LoRa system in order to migrate the
functions of rejoin and media access control (MAC) commands into LoRa gateways
to mitigate the workloads of central cloud. However, databases are deployed in
LoRa gateways to store data, which requires an extra mechanism for data
synchronization. Both Lin  _et al._ [9] and Danish  _et al._ [8] propose their
designs for LoRa systems where blockchain is only deployed in central cloud.
These designs cannot ease the burden of central cloud, but entails more
workloads on it. The edge computing abilities of LoRa gateways are not
enabled. Ozyilmaz  _et al._ [10] propose a blockchain based LoRa system where
entities with different computing and storage abilities play different roles.
LoRa gateways with high abilities can download full blockchain, while weak
LoRa gateways can only download the headers of blocks. However, such a design
has ignored that the increasing size of the ledgers in the blockchain may
exceed the storage limitation of LoRa gateways. Besides, the intention of
deploying blockchain in LoRa gateways is to verify blocks and store data,
making no benefit for the efficiency of the whole system.

##  III Overview of LoRa system

###  III-A Network reference model

Most of the common LoRa systems are built based on the network reference model
that is recommended in [16]. The specification suggests that the LoRa system
should contain five basic parts, i.e., end-device, LoRa gateway, network
server, join server and application server, which is illustrated in Fig. 1.
The end-devices are applied for IoT applications, such as sensing the
environment. The application data are transmitted from end-devices to LoRa
gateways via LoRa wireless links. The network servers, join servers and
application servers are deployed in central cloud. LoRa gateways are
responsible for package forwarding between end-devices and network servers.
Then, all the application messages are processed by network servers. Among all
these messages, the join messages are transferred to join servers, while the
application messages are sent to application servers. All data are created,
read, updated or deleted in databases.

Figure 1: Illustration of LoRa network reference model.

###  III-B Basic features and categories of LoRa data

The LoRa system mainly accomplishes two functions, i.e., the authentication of
end-devices via join procedure and the transmission of application data
between end-devices and application servers.

  1. 1.

Join procedure: A join procedure is required for an end-device to be activated
and access the LoRa network. There are two modes of join procedure, i.e.,
over-the-air activation (OTAA) and activation by personalization (ABP). OTAA
works by dynamic negotiations between end-device and join server, while in ABP
mode, all the session context are preset manually and remain unchanged both in
end-device and join server. Either way, a session to exchange messages is
established between end-device and network server.

  2. 2.

Transmission of application data: The application data are wrapped into
LoRaWAN packages by end-devices for uplink transmission or by application
servers for downlink transmission. Therefore, the network servers need to
unpack/pack the packages, authenticate/specify the end-devices and
verify/ensure the integrity of the packages for uplink/downlink transmission
of application data.

Basically, the data that are involved in the two functions can be classified
into two categories, i.e., the session context data of end-devices and the
application data. The context data contain all the necessary information to
keep connections between end-devices and network servers. For example, the
end-device address (DevAddr), the Application Session Key (AppSKey) for
encryption/decryption of application data and the Network Session Key
(NwkSKey) for calculation of message integrity code (MIC) value, and some
configurations of LoRa physical layer. The application data are application-
specific and owned by application providers or end-users. Take the environment
monitoring as an example, the application data are the environment data that
are gathered from end-devices with sensors.

##  IV Design of HyperLoRa system

###  IV-A HyperLoRa architecture with multiple ledgers

The set of LoRa gateways and network servers are given as
$\mathcal{G}=\\{G_{1},G_{2},\dots,G_{K}\\}$ and
$\mathcal{S}=\\{S_{1},S_{2},\dots,S_{M}\\}$, respectively. $G_{k}$ stands for
the GatewayEUI of the $k$-th gateway that is used to identify LoRa gateway,
while $S_{m}$ represents the identity (ID) of network server $m$. Each LoRa
gateway or network server has a pair of secret keys which are denoted as
$<k^{\text{pub}}_{\varepsilon},k^{\text{pri}}_{\varepsilon}>$, where
$\varepsilon\in\mathcal{G}\cup\mathcal{S}$. $k^{\text{pub}}_{\varepsilon}$ is
the public key that is freely accessed by all other entities, while
$k^{\text{pri}}_{\varepsilon}$ is the private key that is only possessed by
the owner. As illustrated in Fig. 2, HyperLoRa consists of a network ledger
$\mathcal{N}$ and an application ledger $\mathcal{A}$. All data are stored as
immutable records of transactions in ledgers. The functions of the two ledgers
are elaborated as follows, from perspectives of both data types and node
types.

  * •

Perspective of data types: All session context of end-devices are kept in
$\mathcal{N}$. These data include all the attributes of end-devices that
remain unchanged during one session. The Device Extended Unique Identifier
(DevEUI) field is created when the end-device registers to join servers, while
the other fields are generated during the join procedure. The application data
that are produced by end-devices are stored in $\mathcal{A}$. Only application
servers are authorized to access these data for further processing.

  * •

Perspective of node types: $\mathcal{N}$ is maintained by all LoRa gateways
and network servers. LoRa gateways can generate new blocks for $\mathcal{N}$
in OTAA mode, while network servers create new blocks for end-devices in ABP
mode. This is because LoRa gateways receive join requests from OTAA-mode end-
devices directly. Thus, they can pack session context data into blocks without
wasting time and resources forwarding data to network servers. Both LoRa
gateways and network servers are responsible for block verification and
synchronizing on their ledgers. As for $\mathcal{A}$, the new blocks are
generated and validated only by network servers. However, some application
programming interfaces (APIs) are provided for the development of application
servers.

The session context data and the application data have different
characteristics and purposes. The session context data are used to
authenticate end-devices, encrypt messages and calculate MIC. The amount of
session context data is small and the changing frequency is low. Therefore,
LoRa gateways can be able to maintain $\mathcal{N}$, because there are extra
resources apart from those that are used by physical layer. Different from
that, the size of $\mathcal{A}$ can be increasing quickly. Besides,
application data should only be accessed by application servers to provide
data services for end-users. Thus, only network servers can maintain
$\mathcal{A}$. Although all the data are generated by end-devices originally,
they cannot participate in blockchain network due to their limitation on
resources.

Figure 2: Illustration of HyperLoRa system architecture. TABLE I: List of mathematical notations Notation | Explanation | Notation | Explanation
---|---|---|---
$\mathcal{G}$ | Set of LoRa gateways | $\mathcal{S}$ | Set of network server
$\varepsilon$ | An entity of LoRa gateway or network server | $k^{\text{pub}}_{\varepsilon}$ | Public key of entity $\varepsilon$
$k^{\text{pri}}_{\varepsilon}$ | Private key of entity $\varepsilon$ | $\mathcal{N}$ | Network ledger
$\mathcal{A}$ | Application ledger | $B$ | Block
$T$ | Transaction | $h$ | Message digest of transaction
$t$ | Request time of transaction | $d$ | Raw data in transaction
$\tau$ | Generation timestamp of block | $\mathcal{M}$ | Root value of Merkle tree
$\mathcal{H}$ | Hash value of previous block |  |

####  IV-A1 Network ledger

The context data are recorded in $\mathcal{N}$ in the form of transactions
which is denoted as $T^{\mathcal{N}}$. The content of $T^{\mathcal{N}}$ is
given as,

$T^{\mathcal{N}}=<\varepsilon,h,t,\bar{d}>,$ (1)

where $h$ is the message digest of the transaction, $t$ is the timestamp of
the transaction and $\bar{d}$ is the session context data after encryption.
The raw $d$ is given as,

$d=\text{ DevEUI }||\text{ AppKey }||\text{ DevAddr }||\text{ NwkSKey
}||\text{ Nonces },$

where operator $||$ means the concatenation of the data, and
$\text{Nonces}=\text{DevNonce}||\text{AppNonce}$. Note that the AppSKey is not
included because it is related to applications and should only be kept by
application servers. Each LoRa gateway needs to encrypt $d$ and calculate $h$
to generate a $T^{\mathcal{N}}$ using the key pairs. $\bar{d}$ is calculated
as,

$\bar{d}=\text{Enc}\\{k^{\text{pub}}_{\varepsilon},d\\}$ (2)

and $h$ is derived as,

$h=\text{Sign}\\{k^{\text{pri}}_{\varepsilon},t||\bar{d}\\},$ (3)

where operator Enc stands for an encryption algorithm using the public key of
the requester and Sign represents a digital signature algorithm with private
key. Therefore, $d$ can only be decrypted out using the corresponding private
key, and $h$ can be verified by any LoRa gateway or network server that has
the public key of the requester.

In $\mathcal{N}$, after reaching a pre-defined condition (e.g. a period of
time or maximum number of transactions), the LoRa gateway starts to generate a
new block that contains all the transactions after that period. Assuming that
totally $R$ transactions need to be packaged at time $\tau$, and letting
$T_{r}^{\mathcal{N}}=<\varepsilon_{r},h_{r},t_{r},\bar{d}_{r}>$ denotes the
$r$-th transaction, the LoRa gateway needs to construct a Merkle tree before
generate the block according to Algorithm 1.

Input: All transactions
$\\{T_{1}^{\mathcal{N}},T_{2}^{\mathcal{N}},\dots,T_{R}^{c}\\}$, let
$R=2^{x}+y$, where $x\geq 0,0\leq y<2^{x}$ and $z=1$

Output: The root hash $\mathcal{M}$

for  _$z$ in $1,2,\dots,x+1$_ do

for  _$i$ in $1,2,\dots,\lceil\frac{R}{2^{z}}\rceil$_ do

if  _$z=1$_ then

if  _$2i\leq R$_ then

$hash_{z,i}=H(h_{2i-1}||h_{2i}),$ where $H$ is a hash function.

end if

else

$hash_{z,i}=h_{2i-1}$

end if

end if

else

if  _$2i\leq\lceil\frac{R}{2^{z-1}}\rceil$_ then

$hash_{z,i}=H(hash_{z-1,2i-1}||hash_{z-1,2i}),$

end if

else

$hash_{z,i}=hash_{z-1,2i-1}$

end if

end if

end for

end for

$\mathcal{M}=hash_{x+1,1}$.

Algorithm 1 The generation of Merkle tree and root value.

After creating the Merkle tree and getting the root value $\mathcal{M}$, LoRa
gateway starts to generate a block $B^{\mathcal{N}}$ which includes an index
indicator $\zeta\in\mathbb{Z}$, a body $b^{\mathcal{N}}$ and a header
$e^{\mathcal{N}}$. $b^{\mathcal{N}}$ is given as follows,

$b^{\mathcal{N}}=\varepsilon_{1}||h_{1}||t_{1}||\bar{d}_{1}||\varepsilon_{2}||h_{2}||t_{2}||\bar{d}_{2}||\dots||\varepsilon_{R}||h_{R}||t_{R}||\bar{d}_{R}$

Keeping the $\varepsilon$ field in blocks are necessary, because transactions
can be transferred from one LoRa gateway to others. The $e^{\mathcal{N}}$ is
given as $e^{c}=<\tau,\mathcal{M},\mathcal{H}>$, where $\tau$ is the timestamp
of the generation of the block, $\mathcal{M}$ is the root of Merkle tree and
$\mathcal{H}$ is the hash value of the previous block. For the $i$-th block,
the $\mathcal{H}_{i}$ is derived as follow,

$\mathcal{H}_{i}=H(\zeta_{i-1}||e_{i-1}^{\mathcal{N}}||b_{i-1}^{\mathcal{N}})$

The new block is broadcast to all other LoRa gateways and network servers in
$\mathcal{N}$. Others need to verify the block and endorse it if it is
considered valid. At first, other nodes need to check $h$ of all
$T^{\mathcal{N}}$ to make sure they come from exactly a trustful LoRa gateway.
With the ID value, the $k^{\text{pub}}_{\varepsilon}$ can be derived, and $h$
can be verified using the same algorithm as the signing procedure. Then, the
root of Merkle tree is calculated again to ensure its validity. Note that the
session context data of end-devices are encrypted, thus, the data cannot be
eavesdropped during transmission, and other nodes need not to verify the raw
content of transactions.

After verification, other nodes need to broadcast a signed result. According
to practical Byzantine fault tolerance (PBFT), if each node receives more than
$2p+1$ (where $p$ is the maximum possible node that is not functioning well)
results that are the same, then the consensus is reached. All nodes
synchronize $B^{\mathcal{N}}$ on their ledger.

####  IV-A2 Application ledger

The application data are stored in $\mathcal{A}$ as transactions which is
denoted as $T^{\mathcal{A}}$. The structure of $T^{\mathcal{A}}$ is similar to
$T^{\mathcal{N}}$ except for the identifier of requester and the data field.
Let $T^{\mathcal{A}}=<\varepsilon,h,t,d>$, where $\varepsilon\in\mathcal{S}$
and $d$ is the application data. Note that the requester of $T^{\mathcal{A}}$
can only be network servers, and the data in transactions need not to be
deciphered by network servers, because the application data have been
encrypted by end-devices using AppSKey and kept encrypted during the
processing.

When a network server receives enough $T^{\mathcal{A}}$, it starts to wrap
them into a new block. By reaching consensus with all other network servers,
the new block can be recorded on $\mathcal{A}$, and the application data $d$
is finally stored on the shared ledger. End-users can access the application
data through application servers that could get application data from APIs and
decrypt them using proper AppSKey.

TABLE II: Information of each component in HyperLoRa system Component | Functions |  Capability of computing and storage | Ledger
---|---|---|---
End-device |  Sensing, actuating, $\dots$ | Very low | None
LoRa gateway |  Signal processing, data forwarding, join procedure handling, application packages processing | Mediocre | $\mathcal{N}$
Network server |  Data analytics, application APIs, $\dots$ | High | $\mathcal{N},\mathcal{A}$

###  IV-B Edge computing in LoRa gateways

With edge computing abilities in HyperLoRa, two modules are moved from network
servers to LoRa gateways, i.e., JS that handles the join procedures of end-
devices and NC that is responsible for application package processing. By join
procedures, the context data of end-devices are generated and stored in
$\mathcal{N}$. On the other hand, LoRa gateways need these context data from
$\mathcal{N}$ to fulfill the tasks of application package processing.

Figure 3: Illustration of join procedure. Figure 4: Illustration of
application package processing.

####  IV-B1 Join procedure handling

As shown in Fig. 3, the join procedure of OTAA mode is mainly handled by LoRa
gateways, while the ABP mode activation of end-devices are processed by
network servers.

  * •

OTAA: As shown in Fig. 5, when a LoRa gateway receives a join request, it
checks the validity of the request, including the MIC value. Then, LoRa
gateway needs to generate session context data for this end-device, including
the DevAddr, two session keys and some meta data. A transaction that contains
these data is requested and put into a new block by the LoRa gateway. After
consensus, the new block is added into $\mathcal{N}$. In the meantime, the
LoRa gateway has to generate a join accept message and send it back to end-
device. Successful reception of join accept message by end-device indicates
the success of the join procedure.

  * •

ABP: In ABP mode, the manufacturers or owners of end-devices need to fill all
session context data manually via the interfaces offered by network servers.
Then, network servers request transactions of these data and add blocks on
$\mathcal{N}$ after consensus. No more negotiations are needed between end-
devices and JS in LoRa gateways before end-devices can upload application
data.

Figure 5: Workflow of join procedure in OTAA mode.

####  IV-B2 Application packages processing

Owing to $\mathcal{N}$ being deployed in LoRa gateways, an NC module that is
used for application package processing is moved from network server to LoRa
gateway, as shown in Fig. 4. The workflow of message exchange between end-
device and the HyperLoRa system is depicted in Fig. 6.

  * •

Uplink package: When the end-device uploads an application package, the NC in
LoRa gateway parses the package into three parts, i.e, the meta data, the
encrypted application data and the MIC value. By extracting the DevAddr field
from the meta data, NC can query the session context data of the end-device
from $\mathcal{N}$. Then, it checks the validity of MIC value to ensure the
integrity of the package. If the MIC value mismatches, the package is
discarded directly. Otherwise, LoRa gateway uploads the encrypted application
data to network server. The application data are packed into blocks that will
be added to $\mathcal{A}$ by network servers. In the meantime, LoRa gateway
needs to inform end-device of the successful reception of package with an
acknowledgment (ACK) message.

  * •

Downlink package: If there are any downlink data for end-devices, network
servers need to reply the downlink data to LoRa gateways at the same time as
adding new block on chain. Only encrypted data need to be sent from network
server to LoRa gateways rather than full packages. Then, the downlink package
including the information and the MIC value that are created and calculated by
LoRa gateways are encapsulated in NC. During this process, the context data of
end-devices are retrieved by $\mathcal{N}$. The downlink package is finally
transmitted to end-devices via LoRa wireless channels.

Figure 6: Workflow of application package processing.

With edge computing that uses the LoRa gateway near the end-devices to perform
preliminary processing, the central cloud efficiency of HyperLoRa can be
optimized. The works of package parsing, encapsulation and MIC calculation are
finished by LoRa gateways that are on the edge rather than network servers
that are on the central cloud. Thus, a lot of computing resources of central
cloud are saved, while the spare resources from LoRa gateways are utilized.
Besides, the invalid messages such as those that have wrong MIC values are
blocked by LoRa gateways without affecting both the computing resources in
central cloud and the transmission links between LoRa gateways and central
cloud.

##  V Security analysis

In this section, the improvement of security brought by HyperLoRa system is
analyzed with respect to four kinds of risks, i.e, application-layer Denial of
Service (DoS) attack, Single Point Of Failure (SPOF), malicious LoRa gateway
and malicious network server. These risks can be mitigated or eliminated by
the deployment of blockchain and edge computing in HyperLoRa.

###  V-A Application-layer DoS attack

For traditional LoRa system, the interfaces between network servers and LoRa
gateways is defined in [25]. Therefore, an attacker can launch DoS attack by
sending a large number of invalid application packages to network servers in
high frequency to exhaust computing and bandwidth resources. In HyperLoRa
system, the application packages are processed in LoRa gateways, and the
interface protocol between network servers and LoRa gateways can be defined
privately. It could take attackers much more effort to crack the private
protocol and launch DoS attack towards network servers. It is also very hard
to attack HyperLoRa through LoRa gateways, because they are geographically
distributed and they only receive physical LoRa signals. LoRa gateways can
also filter malicious traffic for network servers, thus, it is guaranteed that
network servers can stay healthy to ensure the functions of the HyperLoRa
system during the DoS attack through LoRa gateways.

###  V-B SPOF

In HyperLoRa, the SPOF of both LoRa gateways and network servers can be
solved, because each LoRa gateway or network server maintains a full copy of
the shared ledger. When one LoRa gateway malfunctions, the nearby LoRa
gateways can take the place as long as they can receive the LoRa signals from
end-devices. They only need to get the private key of the broken LoRa gateway
in a secure way. When one network server breakdowns, other network servers can
replace it, while LoRa gateways can re-uploads data to the alternative network
servers. On the one hand, the JS and NC are migrated into LoRa gateways, so
that the malfunctions of one network server has no effect on the handling of
join procedures and application package processing. On the other hand, some of
the workloads of network servers are balanced by LoRa gateways with edge
computing, thus, the crashing possibility of network servers is decreased a
lot.

###  V-C Malicious LoRa gateway

A malicious LoRa gateway can do two things to HyperLoRa system. The first kind
is to steal session context data of end-devices from $\mathcal{N}$. The other
kind of thing is to disturb the consensus process. In both ways, the malicious
LoRa gateway needs to pass the authentication process and participate in the
blockchain in HyperLoRa. If the shared ledger is retrieved, the malicious LoRa
gateway also needs to obtain the $k^{\text{pri}}$ of other LoRa gateways to
decrypt the session context data in blocks. This could be extremely difficult
because LoRa gateways can keep the $k^{\text{pri}}$ in specialized encryption
chips. For consensus process, attackers need to crack more than $p$ LoRa
gateways in HyperLoRa to break the PBFT algorithm, which is difficult to
realize.

###  V-D Malicious network server

Assume an attacker has deployed in HyperLoRa system a malicious network server
that has successfully passed the authentication and has established
connections with some LoRa gateways (which is actually difficult to realize).
Then, the malicious network server can share both $\mathcal{N}$ and
$\mathcal{A}$. However, neither the session context data of end-devices nor
the application data can be stolen, falsified or destroyed. First of all, all
the session context data are encrypted using $k^{\text{pri}}$, while all the
application data are encrypted using AppSKey that is kept only by end-devices
and application servers. To decipher the data, the attacker needs also to get
all these keys. Then, the blockchain in HyperLoRa ensures that the data inside
the blocks cannot be altered. Moreover, all nodes share a full copy of
ledgers, thus, deleting data from one network server will not damage the data
that are kept in other LoRa gateways or network servers.

##  VI Implementation and Experiments

###  VI-A Implementation with Hyperledger Fabric

The prototype of HyperLoRa system is implemented where the blockchain is
realized using Hyperledger Fabric, as shown in Fig. 7. The end-device is
deployed with a LoRa transceiver module SX1276 from Semtech. By plugging in
proper sensor, the end-device can collect data and upload to LoRa gateway. The
LoRa gateway is developed on embedded hardware with Smart6818 CPU board that
is industrial specialized and uses Samsung S5P6818 octa-core Cortex-A53 System
on Chip (SoC). The edge computing can be achieved with such hardware. Besides,
two radio frequency front-ends (SX1255) are deployed and connected to a
digital baseband chip SX1301 for signal processing.

In order to deploy Fabric on LoRa gateway, the operating system is customized
based on Linux OpenWrt project since Fabric requires cgroup feature and
overlay file system. In the meantime, a third-party docker image of Fabric is
built to run on the LoRa gateway. During the initialization of Fabric, two
organizations are created, i.e., LoRa gateway organization that contains peers
that are deployed in LoRa gateways and network server organization that
includes peers that are deployed in network servers. Each peer acts as both
endorser and committer. Two channels are then established, each of which
maintains ledger $\mathcal{N}$ and $\mathcal{A}$. All peers in two
organizations can communicate in the channel of $\mathcal{N}$, while only
peers in network server organization can communicate secretly in channel of
$\mathcal{A}$. As a permissioned blockchain, a Membership Service Provider
(MSP) is built to handle the authentications and authorizations of all peers.
That is to say, only authorized LoRa gateway or network server can join in the
blockchain network. The consensus is accomplished using PBFT algorithm by
several ordering nodes in each channel. Due to the limited computational
capabilities of LoRa gateways, all ordering nodes in two channels are deployed
in the central cloud.

Several chaincodes are developed and hosted in LoRa gateways peers to
manipulate data in $\mathcal{N}$. Both JS and NC can invoke the chaincodes by
Fabric client to create, read or delete session context data of end-devices.
Then, peers try to run the chaincodes in a virtual environment to ensure they
are valid. By receiving the responses from peers, JS or NC sends the
transaction to the ordering nodes for consensus. After consensus, the data are
recorded on all distributed $\mathcal{N}$ and the latest values of specific
data fields are kept as the world states of $\mathcal{N}$ in a state database.

Figure 7: Implementation of HyperLoRa with embedded LoRa gateways and
Hyperledger Fabric.

###  VI-B Experimental setup

Our prototype system consists of $4$ LoRa gateways and $2$ network servers at
the central cloud. To emulate hundreds of end-devices, several customized
Locust444https://www.locust.io/ clients is deployed on independent servers
that can connect to LoRa gateways directly. A Fabric network of version
$1.4.0$ is established on both LoRa gateways and network servers. The hardware
information is summarized in Table III.

TABLE III: Hardware information Type of device | Processor | Number of CPU cores | Memory
---|---|---|---
LoRa gateway | Samsung(R) S5P6818 @ $1.40\text{\,}\mathrm{GHz}$ | $8$ | $1\text{\,}\mathrm{GB}$
Network server | Intel(R) Xeon(R) W-2123 @ $3.60\text{\,}\mathrm{GHz}$ | $8$ | $32\text{\,}\mathrm{GB}$
Locust client server | Intel(R) Xeon(R) CPU E5-2609 v4 @ $1.70\text{\,}\mathrm{GHz}$ | $8$ | $16\text{\,}\mathrm{GB}$

Some of the key experimental parameters are listed in Table IV. The ordering
type is solo, which means the consensus is reached by a single ordering node
using sorting algorithm. New block is generated every $2\text{\,}\mathrm{s}$.
If the total number of transactions that are received within
$2\text{\,}\mathrm{s}$ exceeds $200$, a new block is also forced to be
created.

TABLE IV: Parameter settings Name | Value | Description
---|---|---
General settings
OrdererType | Solo | Type of order in Hyperledger
BatchTimeout | $2\text{\,}\mathrm{s}$ | Time interval to generate a block
MaxMessageCount | $200$ | Maximum number of one batch
Join requests
MaxPackageInterval | $2\text{\,}\mathrm{h}$ |  Maximum intervals between two packages of one end-device
MinPackageInterval | $10\text{\,}\mathrm{min}$ |  Minimum intervals between two packages of one end-device
Timeout | $300\text{\,}\mathrm{s}$ | Timeout of each join request
Application packages by authorized end-devices & Application packages by
authorized and unauthorized end-devices
MaxPackageInterval | $17\text{\,}\mathrm{s}$ | -
MinPackageInterval | $13\text{\,}\mathrm{s}$ | -
Timeout | $30\text{\,}\mathrm{s}$ | Timeout of each application package

Three kinds of experiments are conducted, i.e.,

  1. 1.

Experiment 1 (join requests): $100\sim 2,200$ end-devices are emulated to
continuously send join requests to LoRa gateways. Each LoRa gateway manages
$25\sim 550$ end-devices. As shown in Fig. 8(8(a)), each end-device runs
periodically with a randomly chosen interval between $10\text{\,}\mathrm{min}$
and $2\text{\,}\mathrm{h}$. If a join accept message is received by end-
device, the join procedure is considered successful. If no apply is received
after $300\text{\,}\mathrm{s}$, the join request is failed. The detailed
processing time of join requests are recorded.

  2. 2.

Experiment 2 (application packages by authorized end-devices): $100\sim 2,000$
end-devices are emulated in this experiment. Each LoRa gateway covers $25\sim
400$ end-devices equivalently. The join procedures of all end-devices are
accomplished. Thus, end-devices are authorized to send application packages.
Each end-device randomly chooses an interval between $13\text{\,}\mathrm{s}$
and $17\text{\,}\mathrm{s}$ to upload packages constantly. The network server
replies each package with an acknowledgment to indicate that the uplink data
are received successfully, as shown in Fig. 8(8(b)). If no acknowledgment is
received by end-device for $30\text{\,}\mathrm{s}$ after it uploads, the
transmission of application package is considered failed. End-device keeps
sending after the time interval or any failure occurs. By running this
experiment, the maximum possible performance of the prototype can be
evaluated. The processing time, CPU utilization and system throughput are
recorded.

  3. 3.

Experiment 3 (application packages by authorized and unauthorized end-
devices): In this experiment, $100\sim 2,000$ end-devices are emulated in
total. $4$ LoRa gateways share equal number of end-devices. Among all the end-
devices under the coverage of each LoRa gateway, half of them have finished
the join procedures, while the other half are considered unauthorized to the
prototype. All the end-devices send application packages to LoRa gateways in
the same way as the Experiment 2. For those unauthorized end-devices, their
packages cannot pass the MIC verification process in LoRa gateways and will be
discarded directly, as shown in Fig. 8(8(c)). This experiment can simulate the
situation that the system is under the application-layer DoS attack. The
system throughput, CPU utilization and network bandwidth occupation are
recorded. Moreover, a comparison experiment with traditional LoRa system
approach is conducted. The application packages are sent to a traditional LoRa
system where both the JS and NC are implemented in central cloud rather than
in the LoRa gateways. Therefore, central cloud needs to process all valid and
invalid application packages. A blockchain network is also established in the
traditional LoRa system, but both $\mathcal{N}$ and $\mathcal{A}$ are
maintained only by network servers, as illustrated in Fig. 8(8(d)). The
comparison can show the improvement of performance brought by HyperLoRa.

(a) Experiment 1: join requests.

(b) Experiment 2: application packages by authorized end-devices.

(c) Experiment 3: application packages by authorized and unauthorized end-
devices.

(d) Comparison experiment with traditional LoRa system in Experiment 3.

Figure 8: Illustrations of the experiments on HyperLoRa prototype. Figure 9:
Distribution of processing time of join requests in Experiment 1. Figure 10:
Processing time statistics of join requests in Experiment 1. Figure 11:
Illustration of processing time of application packages in Experiment 2.

###  VI-C Results and analysis

Figure 9 shows the detailed distribution of processing time of join requests.
Each bar represents the percentage of end-devices whose processing time
locates within the value of the top point for specific number of end-devices.
The processing time rises slightly with the increase of the number of end-
devices before $2,000$. When the number of end-devices comes to around $500$
per LoRa gateway, the processing time has a significant growth. The same trend
is shown in Fig. 10. It presents the statistical results of processing time of
join requests. The black-dash line is the maximum allowable latency during
which an end-device can receive the join accept message. It can be configured
according to specific requirements ($5\text{\,}\mathrm{s}$ in the Experiment
1). The join request is considered failed if time exceeds the threshold. The
mean latency starts to exceed the threshold after the number of end-devices
passes $2,000$. The results demonstrate the maximum capability of handing join
requests in this system, i.e., for $5\text{\,}\mathrm{s}$ restriction and
$1,800$ end-devices, nearly $75\%$ can receive join accept messages
successfully.

Figure 11 illustrates the statistical processing time of application packages
in Experiment 2. The mean latency keeps rising as the number of end-devices
increases before $1,100$, because more end-devices generate more application
data, costing more time to process. When the number exceeds $1,200$, the
processing time becomes stable, this is because the HyperLoRa system has
reached its maximum load. There are no further resources to handle more
application packages. Then, these packages are considered being discarded.
This result shows that the prototype can handle totally $1,200$ end-devices
whose uploading intervals are around $15\text{\,}\mathrm{s}$ and timeouts are
$30\text{\,}\mathrm{s}$. Note that the uploading frequency is far more than
most of the sensing based IoT applications. In practical, the maximum number
can still be increasing.

Figure 12: Illustration of system throughput of application packages, as well
as CPU utilization of LoRa gateways and network server in Experiment 2. Figure
13: Illustration of CPU utilization of LoRa gateways and network server with
both valid and invalid application packages in Experiment 3.

During the processing of valid application packages, the system throughput and
the CPU utilization of both LoRa gateways and network server are shown in Fig.
12. Before $1,100$ end-devices, the throughput keeps rising, because the
resources are not fully utilized. In the meantime, the CPU utilization is
increasing. After the number of end-devices exceeds $1,200$, the throughput
becomes stable, and even declines a little. Similar to the trend that is
presented in Fig. 11, it is because the system is in full-load condition. This
is also reflected by the change of the CPU utilization. Nearly $7$ cores of
CPU in LoRa gateways are occupied by NC module. The rest core is taken up by
the operation systems and the signal processing modules. However, the CPU
utilization of network server remains in a low level, because LoRa gateways
with edge computing have taken the works of packages processing and
verification.

Figure 13 shows the CPU utilization of both LoRa gateways and network server
in Experiment 3 and the comparison experiment. With the increase of end-
devices, more CPU resources are occupied both in LoRa gateways and network
server. Because LoRa gateways have processed all packages and filtered invalid
packages, the CPU utilization of network server has reduced by $22\%$ compared
with the network server of traditional LoRa system where network server needs
to handle all packages itself. Not only CPU resources are spared, but also the
bandwidth of transmission link between LoRa gateways and network server is
saved, which is shown in Fig. 14. This is because the invalid traffic has been
blocked by LoRa gateways. The result shows that nearly $41.1\%$ save of
bandwidth is gained when the number of end-devices is $1,000$, compared with
traditional LoRa system. The gap keeps enlarging linearly as the increasing of
end-devices. One of the benefits of the resource saving is that the spared
resources can be used on more valid packages, avoiding them from being
affected by the invalid or malicious traffic. Figure 15 shows that the system
throughput of the HyperLoRa is equivalent to the system throughput of
traditional LoRa system. It means that HyperLoRa can reach the same
performance as traditional LoRa system with less occupation of resources,
owing to the efficient utilization of the resources in the LoRa gateways.

Figure 14: Illustration of bandwidth occupation of transmission links between
LoRa gateways and network server in Experiment 3. Figure 15: Illustration of
system throughput with both valid and invalid application packages in
Experiment 3.

##  VII Conclusion

This paper has proposed a new design of HyperLoRa system with edge computing,
where a blockchain is deployed with two ledgers that store different types of
LoRa data. Our proposed system can well utilize the limited resources at LoRa
gateways to maintain one ledger. Two functions of network servers are also
migrated to LoRa gateways to exploit the edge computing abilities. In
HyperLoRa, some potential security risks can be mitigated or prevented by edge
computing and the deployment of blockchain. Moreover, a prototype of HyperLoRa
has been successfully implemented which demonstrates the feasibility of our
proposed design. Through the experiments, we have shown the maximum
performances that HyperLoRa can reach, e.g., handling almost $1,350$ join
requests with $5\text{\,}\mathrm{s}$ timeout, and processing $48$ application
packages per second with $1,000$ end-devices that upload data in
$15\text{\,}\mathrm{s}$ interval. Furthermore, the central cloud can save CPU
utilization and bandwidth occupation without any decrease on system
throughput, compared with traditional LoRa system.

## References

  * [1] 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_ , vol. 53, no. 9, pp. 64–71, 2015.
  * [2] L. Leonardi, F. Battaglia, and L. Lo Bello, “RT-LoRa: A medium access strategy to support real-time flows over lora-based networks for industrial iot applications,” _IEEE Internet of Things Journal_ , vol. 6, no. 6, pp. 10 812–10 823, 2019.
  * [3] L. Hou, S. Zhao, X. Xiong, K. Zheng, P. Chatzimisios, M. S. Hossain, and W. Xiang, “Internet of things cloud: Architecture and implementation,” _IEEE Communications Magazine_ , vol. 54, no. 12, pp. 32–39, 2016.
  * [4] Q. Zhou, K. Zheng, L. Hou, J. Xing, and R. Xu, “Design and implementation of open LoRa for IoT,” _IEEE Access_ , vol. 7, pp. 100 649–100 657, July 2019.
  * [5] A. Mavromatis, C. Colman-Meixner, A. P. Silva, X. Vasilakos, R. Nejabati, and D. Simeonidou, “A software-defined IoT device management framework for edge and cloud computing,” _IEEE Internet of Things Journal_ , vol. 7, no. 3, pp. 1718–1735, 2020.
  * [6] F. Meneghello, M. Calore, D. Zucchetto, M. Polese, and A. Zanella, “IoT: Internet of threats? A survey of practical security vulnerabilities in real IoT devices,” _IEEE Internet of Things Journal_ , vol. 6, no. 5, pp. 8182–8201, 2019.
  * [7] H. Dai, Z. Zheng, and Y. Zhang, “Blockchain for internet of things: A survey,” _IEEE Internet of Things Journal_ , vol. 6, no. 5, pp. 8076–8094, 2019.
  * [8] S. M. Danish, M. Lestas, W. Asif, H. K. Qureshi, and M. Rajarajan, “A lightweight blockchain based two factor authentication mechanism for LoRaWAN join procedure,” in _2019 IEEE International Conference on Communications Workshops (ICC Workshops)_ , 2019, pp. 1–6.
  * [9] J. Lin, Z. Shen, C. Miao, and S. Liu, “Using blockchain to build trusted LoRaWAN sharing server,” _International Journal of Crowd Science_ , vol. 1, no. 3, pp. 270–280, 2017.
  * [10] K. R. Ozyilmaz and A. Yurdakul, “Designing a blockchain-based IoT with ethereum, swarm, and LoRa: The software solution to create high availability with minimal security risks,” _IEEE Consumer Electronics Magazine_ , vol. 8, no. 2, pp. 28–34, 2019.
  * [11] Y. Liu, K. Wang, K. Qian, M. Du, and S. Guo, “Tornado: Enabling blockchain in heterogeneous internet of things through a space-structured approach,” _IEEE Internet of Things Journal_ , vol. 7, no. 2, pp. 1273–1286, 2020.
  * [12] M. A. Ferrag, M. Derdour, M. Mukherjee, A. Derhab, L. Maglaras, and H. Janicke, “Blockchain technologies for the Internet of things: Research issues and challenges,” _IEEE Internet of Things Journal_ , vol. 6, no. 2, pp. 2188–2204, 2019.
  * [13] P. Yuan, X. Xiong, L. Lei, and K. Zheng, “Design and implementation on Hyperledger-based emission trading system,” _IEEE Access_ , vol. 7, pp. 6109–6116, 2019.
  * [14] X. Wang, Y. Han, V. C. M. Leung, D. Niyato, X. Yan, and X. Chen, “Convergence of edge computing and deep learning: A comprehensive survey,” _IEEE Communications Surveys Tutorials_ , vol. 22, no. 2, pp. 869–904, 2020\.
  * [15] X. Wang, C. Wang, X. Li, V. C. M. Leung, and T. Taleb, “Federated deep reinforcement learning for internet of things with decentralized cooperative edge caching,” _IEEE Internet of Things Journal_ , pp. 1–1, 2020\.
  * [16] “LoRaWAN™ backend interfaces 1.0 specification,” LoRa Alliance, 2017\.
  * [17] W. Liang, M. Tang, J. Long, X. Peng, J. Xu, and K. Li, “A secure fabric blockchain-based data transmission technique for industrial Internet-of-things,” _IEEE Transactions on Industrial Informatics_ , vol. 15, no. 6, pp. 3582–3592, 2019.
  * [18] J. Wan, J. Li, M. Imran, D. Li, and Fazal-e-Amin, “A blockchain-based solution for enhancing security and privacy in smart factory,” _IEEE Transactions on Industrial Informatics_ , vol. 15, no. 6, pp. 3652–3660, 2019.
  * [19] S. Zhao, S. Li, and Y. Yao, “Blockchain enabled industrial internet of things technology,” _IEEE Transactions on Computational Social Systems_ , vol. 6, no. 6, pp. 1442–1453, 2019.
  * [20] J. Kang, R. Yu, X. Huang, M. Wu, S. Maharjan, S. Xie, and Y. Zhang, “Blockchain for secure and efficient data sharing in vehicular edge computing and networks,” _IEEE Internet of Things Journal_ , vol. 6, no. 3, pp. 4660–4670, 2019.
  * [21] T. Jiang, H. Fang, and H. Wang, “Blockchain-based internet of vehicles: Distributed network architecture and performance analysis,” _IEEE Internet of Things Journal_ , vol. 6, no. 3, pp. 4640–4649, 2019.
  * [22] J. Xu, K. Xue, S. Li, H. Tian, J. Hong, P. Hong, and N. Yu, “Healthchain: A blockchain-based privacy preserving scheme for large-scale health data,” _IEEE Internet of Things Journal_ , vol. 6, no. 5, pp. 8770–8781, 2019.
  * [23] C. Qiu, X. Wang, H. Yao, J. Du, F. R. Yu, and S. Guo, “Networking integrated cloud-edge-end in iot: A blockchain-assisted collective $Q$-learning approach,” _IEEE Internet of Things Journal_ , pp. 1–1, 2020\.
  * [24] Z. Liu, Q. Zhou, L. Hou, R. Xu, and K. Zheng, “Design and implementation on a LoRa system with edge computing,” in _2020 IEEE Wireless Communications and Networking Conference (WCNC)_ , 2020, pp. 1–6.
  * [25] “LoRaWAN™ network server demonstration: Gateway to server interface definition,” Semtech Ltd., 2015.


by ERC Grant No: 693024, STFC and the Beecroft Trust.

## References

  * (1)
  * Adelberger, Heckel & Nelson (2003) Adelberger E, Heckel BR, Nelson AE 2003 Ann. Rev. Nucl. Part. Sci 53:77
  * Alam et al. (2016) BOSS collaboration, Alam A, Ata M, Bailey S, Beutler F et al 2016 M.N.R.A.S. 470:2617
  * Allwright & Lehner (2018) Allwright G., Lehner L 2018 Submitted ArXiv:1808.07897
  * Alonso et al. (2017) Alonso D, Bellini E, Ferreira PG, Zumalacarregui M 2017 Phys. Rev. D95, 063502
  * Amendola et al. (2008) Amendola L, Kunz M, Sapone D 2008 J.C.A.P. 0804:013
  * Amendola et al. (2018) Amendola L, Kunz M, Saltas I 2018 J.C.A.P. 1808:030
  * Amin et al. (2009) Amin MA, Wagoner RV, Blandford RD, 2009 M.N.R.A.S. 390:131
  * Amon et al. (2017) Amon A, Blake C, Heymans C, Leonard CD et al 2017 M.N.R.A.S. 479:3422
  * Amon et al. (2018) Amon A, Blake C, Heymans C, Leonard CD, Asgari, M et al. 2018 M.N.R.A.S 479:3422
  * Arkani-Hamed et al. (1998) Arkani-Hamed N, Dimopoulos S, Dvali G 1998 Phys. Lett. B 429:263
  * Asvathaman et al. (2017) Asvathaman A, Heyl J, Hui L 2017 M.N.R.A.S. 465:3261
  * Avilez & Skordis (2014) Avilez A, Skordis C 2014 Phys. Rev. Lett. 113:011101
  * SDSS (2002) SDSS collaboration, Bahcall N, Dong F, Bode P, Kim R at al 2002 Astroph. Journ. 585:182
  * Baker et al. (2012) Baker T, Ferreira PG, Skordis C 2012 Phys. Rev. D87:024015
  * Baker et al. (2014) Baker T, Ferreira PG, Skordis C 2014 Phys. Rev. D89:024026
  * Baker & Bull (2015) Baker T, Bull P 2015 Astroph. Journ. 811:116
  * Baker et al. (2015) Baker T, Psaltis D, Skordis C Astroph. Journ. 802:63
  * Baker et al. (2017) Baker T, Bellini E, Ferreira PG, Lagos M, Noller J, Sawicki I 2017 Phys. Rev. Lett. 119:251301
  * Baker et al. (2018) Baker T, Clampitt J, Jain B, Trodden M 2018 Phys. Rev. D98:023511
  * Barreira et al. (2015) Barreira A, Cautun M, Li B, Baugh C, Pascolo, S 2015 J.C.A.P. 1508:028
  * Barreira et al. (2016) Barreira A, Sanchez A, Schmidt F 2016 Phys. Rev. D94:084022
  * Battye & Pearson (2011) Battye RA, Pearson JA 2011 Phys. Rev. D 84:125032
  * Belgacem et al. (2018) Belgacem E, Dirian Y, Foffa S, Maggiore M 2018 Phys. Rev. D97:104066
  * Bellini & Sawicki (2014) Bellini E, Sawicki I 2014 J.C.A.P. 1407:050
  * Bellini et al. (2016) Bellini E, Cuesta A, Jimenez R, Verde L 2016 J.C.A.P. 1602:053
  * Bellini et al. (2017) Bellini E, Barreira A, Frusciante N, Hu B, Peirone S et al. 2017 Phys. Rev. D97:023520
  * Bernardeau et al. (2002) Bernardeau F, Colombi S, Gaztanaga E, Scoccimarro R 2002 Phys. Rept. 367:1
  * Berti et al. (2015) Berti E, Barrausse E, Cardoso V, Gualtieri L, Pani P et al. 2015 Class. Quant. Grav. 32:243001
  * Bertotti et al. (2003) Bertotti B, Iess L, Tortora P 2003 Nature 425:374
  * Bertschinger & Zukin (2008) Bertschinger E, Zukin P 2008 Phys. Rev. D78:024015
  * WiggleZ (2011) WiggleZ collaboration, Blake C, Kazin E, Beutler F, Davis T, Parkinson D et al. 2011 M.N.R.A.S. 418:1707
  * Blake et al. (2016) Blake C, Joudaki S, Heymans C, Choi A et al 2016 M.N.R.A.S. 456:2806
  * Blas et al. (2011) Blas D, Lesgourgues J, Tram T 2011 J.C.A.P. 1107:034
  * Blas et al. (2011) Blas D, Shaposhnikov M, Zenhausern D 2011 Phys. Rev. D84:044001
  * Bloomfield et al. (2012) Bloomfield J, Flanagan E, Park M, Watson S 2012 J.C.A.P. 1308:010
  * Bose et al. (2017) Bose B, Koyama K, Hellwing W, Zhao GB, Winther H 2017 Phys. Rev. D96:023519
  * Brans & Dicke (1961) Brans C, Dicke RH 1961 Phys. Rev. 124:925
  * Broderick et al. (2013) Broderick A, Johannsen T, Loeb A, Psaltis D 2013 Astroph. J. 784:7
  * Burgess (2003) Burgess C 2003 Living Rev. Rel. 7:5
  * Burrage & Sakstein (2017) Burrage C, Sakstein J 2017 Living. Rev. Rel. 21:1
  * Cabre et al. (2012) Cabre A, Vikram V, Zhao GB, Jain B, Koyama K 2012 J.C.A.P. 1207:034
  * Cai et al. (2014) Cai YC, Neyrink M, Szapudi I, Cole S, Frenk C 2014 Astroph. Journ. 786:110
  * Carrasco et al. (2012) Carrasco JJ, Hertzberg M, Senatore L 2012 J.H.E.P. 1209:082
  * Cataneo et al. (2015) Cataneo M, Rapetti D, Schmidt F, Mantz A, Allen S et al. 2015 Phys. Rev. D92:044009
  * Cataneo et al (2018) Cattaneo M, Lombriser L, Heymans C et al, 2018 Submitted to M.N.R.A.S ArXiv:1812.05594
  * Chisari et al. (2018) Chisari NE, Richardson M, Devriendt J, Dubois Y, Schneider A et al. 2018 M.N.R.A.S. 480:3962
  * Choquet-Bruhat & Geroch (1969) Choquet-Bruhat Y, Geroch R 1969 Comm. Matt. Phys 14:329
  * Clampitt & Cai (2012) Clampitt J, Cai Y-C 2012 M.N.R.A.S. 431:749C
  * Clifton et al. (2012) Clifton T, Ferreira PG, Padilla A, Skordis C 2012 Phys. Rep. 513:1
  * Cooray & Sheth (2002) Cooray A, Sheth R 2002 Phys. Rept. 372:1
  * Creminelli et al. (2009) Creminelli P, D’Amico G, Norena J, Vernizzi F 2009 J.C.A.P. 0902:018
  * Creminelli & Vernizzi (2017) Creminelli P, Vernizzi F 2017 Phys. Rev. Lett. 119:251301
  * Crittenden et al. (2012) Crittenden R, Zhao GB, Pogosian L, Samushia L, Zhang X 2012 J.C.A.P. 1202:048
  * Cusin et al. (2018) Cusin G, Lewandowksi M, Vernizzi F 2018 J.C.A.P. 1804:061
  * BOOMERanG (2000) BOOMERanG Collaboration, de Bernardis P, Ade P, Bock, JJ, Boscaleri A et al. 1999 Nature 404:955
  * De Felice et al. (2011) De Felice A, Kobayashi T, Tsujikawa S 2011 Phys. Lett. B706:123
  * Deffayet et al. (2009) Deffayet C, Esposito-Farese G, Vikman A 2009 Phys. Rev. D79:084003
  * DeLaTorre et al. (2016) de la Torre S, Jullo E, Giocoli C, Pezzotta A et al 2016 Astron. Astrophys. 608:44
  * De Rahm et al. (2011) de Rahm C, Gabadadze G, Tolley A 2011 Phys. rev. Lett 106:231101
  * DES (2018a) DES Colaboration, Abbott TC, Abdalla FB, Avila A, Banerji M et al. 2018a Phys. Rev. D98:043526
  * DES (2018b) DES Colaboration, Abbott TC, Abdalla FB, Avila A, Banerji M et al. 2018b Submitted to Phys. Rev. D ArXiv:1810:02499
  * Deser (1970) Deser S 1970 Gen. Rel. Grav. 1:9
  * Deser & Woodard (2007) Deser S, Woodard R 2007 Phys. Rev. Lett. 99:111301
  * Desjacques et al. (2016) Desjacques V, Jeong D, Schmidt F 2016 Phys. Rept. 733:1
  * Desmond et al. (2018a) Desmond H, Ferreira PG,Lavaux G, Jasche J 2018a M.N.R.A.S. 474:3152
  * Desmond et al. (2018b) Desmond H, Ferreira PG, Lavaux G, Jasche J 2018b Submitted ArXiv: 1802.07206
  * Desmond et al. (2018c) Desmond H, Ferreira PG, Lavaux G, Jasche J 2018c Accepted to Phys. Rev. ArXiv: 1807.01486
  * Desmond et al. (2018) Desmond H, Ferreira PG, Lavaux G, Jasche J 2018d Submitted ArXiv: 1807.11742
  * Doeleman et al. (2008) Doeleman S, Weintroub J, Rogers A, Plambeck, Freund R et al. 2008 Nature 455:78
  * Donoghue (1994) Donoghue J 1994 Phys. Rev. D50:3874
  * Dossett et al. (2011) Dossett J, Ishak M, Moldenhauer J 2011 Phys. Rev. D84 123001
  * Dvali et al. (2000) Dvali G, Gabadadze G, Porrati M 2000 Phys. Lett. B485:208
  * Espejo et al. (2018) Espejo J, Peirone S, Raveri M, Koyama K, Pogosian et al. 2018 Submitted ArXiv:1809.01121
  * Ezquiaga & Zumalacarregui (2017) Ezquiaga JM, Zumalacarregui M 2017 Phys. Rev. Lett. 119: 251304
  * Fierz & Pauli (1939) Fierz M, Pauli W 1939 Proc. Roy. Soc. A173:211
  * Ferreira et al. (2016) Ferreira PG, Hill C, Ross G 2016 Phys. Lett. B763:174
  * Ferreira & Skordis (2010) Ferreira PG, Skordis C 2010 Phys. Rev. D81:104020
  * Feynman et al. (1995) Feynman RP, Mornigo FB, Wagner WG 1995 Feynman lectures on gravitation Addison Wesley
  * Freire et al. (2012) Freire PC, Wex N, Esposito-Farese G, Verbiest JPW, Bailes M et al. 2012 M.N.R.A.S 423:3328
  * Garcia-Bellido et al. (2011) Garcia-Bellido J, Rubio J, Shaposhnikov M, Zenhausern D 2011 Phys. Rev. D84:123504
  * Gleyzes et al. (2013) Gleyzes J, Langlois D, Piazza F, Vernizzi F 2013 J.C.A.P. 1308:025
  * Gleyzes et al. (2015a) Gleyzes J, Langlois D, Vernizzi F 2015a Int. J. Mod. Phys D23:1443010
  * Gleyzes et al. (2015b) Gleyzes J, Langlois D, Piazza F, Vernizzi F 2015b Phys. Rev. Lett. 114:211101
  * Gubitosi et al. (2012) Gubitosi G, Piazza F, Vernizzi F 2012 J.C.A.P. 1302:032
  * Hamaus et al. (2015) Hamaus N, Sutter PM, Lavaux G, Wandelt B 2015 J.C.A.P. 1511:036
  * Hamaus et al. (2016) Hamaus N et al. 2016 Phys. Rev. Lett. 117:091302
  * MAXIMA (2000) MAXIMA Collaboration, Hanany S, Ade P, Balbi A, Bock J 2000 Astroph. Journ. 545:L5
  * Hassan & Rosen (2012) Hassan F, Rosen R 2012 J.H.E.P. 1202:126
  * Heisenberg (2014) Heisenberg L 2014 J.C.A.P. 1405:015
  * KIDS (2016) KIDS Collaboration, Hildebrandt H, Viola M, Heymans C, Joudaki S et al. 2016 M.N.R.A.S. 465:1454
  * Hinterbichler & Khoury (2010) Hinterbichler K, Khoury J 2010 Phys. Rev. Lett. 104:231301
  * Hinterbichler (2012) Hinterbichler K 2012 Rev. Mod. Phys 84:671
  * Hojiati et al. (2011) Hojiati A, Pogosian L, Zhao GB 2011 J.C.A.P. 1108:005
  * Hojman et al. (1976) Hojman SA, Kuchar K, Teitelboim C 1976 Annals. Phys. 96:88
  * Horndeski (1974) Horndeski G W 1974 Int. J. Theor. Phys. 10:363
  * Hu et al. (2013) Hu B, Raveri M, Frusciante N, Silvestri A 2013 Phys. Rev. D89:103530
  * Hu & Sawicki (2007) Hu W, Sawicki I 2007 Phys. Rev. D76:104043
  * Hui & Nicolis (2012) Hui L, Nicolis A 2012 Phys. Rev. Lett. 109:051304
  * Jain & Vanderplas (2011) Jain B, Vanderplas J 2011 J.C.A.P. 10:032
  * Jacobson & Mattingley (2000) Jacobson T, Mattingley D 2000 Phys. Rev. D64:024028
  * Johannsen & Psaltis (2010) Johannsen T, Psaltis D (2010) Astroph. Journ. 718:446
  * KIDS (2018) KIDS collaboration, Joudaki S, Blake C, Johnson A, Amon A et al. 2018 M.N.R.A.S. 474:4894
  * Joyce et al. (2014) Joyce A, Jain B, Khoury J, Trodden M 2014 Phys. Rept. 568:1
  * Kaiser & Sfakianakis (2014) Kaiser D, Sfakianakis E 2014 Phys. Rev. Lett 112:011302
  * Kaiser (1987) Kaiser N 1987 M.N.R.A.S. 227:1
  * Khoury & Weltman (2004) Khoury J, Weltman A 2004 Phys. Rev. D69:044026
  * Koboyashi et al. (2011) Koboyashi T, Yamaguchi M, Yokoyama J 2011 Prog. Theor. Phys. 126:511
  * Koyama et al. (2009) Koyama K, Taruya A, Hiramitsu T 2009 Phys. Rev. D79:123512
  * Kreisch & Komatsu (2017) Kreisch CD, Komatsu E 2017 Submitted ArXiv:1712.02710
  * Kunz (2012) Kunz M 2012 Compt. Rend. Phys. 13:539
  * Lagos at al (2016) Lagos M, Baker T, Ferreira PG, Noller J 2016 J.C.A.P. 1608:007
  * Lagos & Ferreira (2016) Lagos M, Ferreira PG 2016 J.C.A.P. 1701:047
  * Lagos at al (2016) Lagos M, Bellini E, Noller J, Ferreira PG, Baker T 2016 J.C.A.P. 1803:021
  * Lehner & Pretorius (2014) Lehner L, Pretorius F 2014 Ann. Rev. Astron. Astroph. 552:661
  * Leonard et al. (2015) Leonard D, Ferreira PG, Heymans C J.C.A.P. 1512:051
  * LIGO (2016a) LIGO and Virgo Scientific Collaborations, Abbott BP, Abbott R, Abbott TD, Abernathy MR et al. 2016a Phys. Rev. Lett. 116:061102
  * LIGO (2016b) LIGO and Virgo Scientific Collaborations, Abbott BP, Abbott R, Abbott TD, Abernathy MR et al. 2016b Phys. Rev. Lett. 116:221101
  * LIGO (2017a) LIGO and Virgo Scientific Collaborations, Abbott BP, Abbott R, Abbott TD, Acernese F al 2017a Phys. Rev. Lett. 119:161101
  * LIGO (2017b) LIGO and Virgo Scientific Collaborations, Abbott BP, Abbott R, Abbott TD, Acernese F al 2017b Nature 551:85
  * Linder et al. (2016) Linder E, Sengor G, Watson S 2016 J.C.A.P. 1605:053
  * Llinares et al. (2014) Llinares C, Mota D, Winther H 2014 A.& A. 562:A78
  * Leonard et al. (2018) Leonard C, Ferreira PG, Heymans C 2018 J.C.A.P. 12:051
  * Lewis et al. (1999) Lewis A, Challinor A, Lasenby A 1999 Astroph. Jour. 538:473
  * Li et al. (2012) Li B, Teyssier R, Koyama K 2012 J.C.A.P. 1:51
  * Linder (2005) Linder E 2005 Phys. Rev. D72:043529
  * Lombriser et al. (2012) Lombriser L, Slosar A, Seljak U, Hu W 2012 Phys. Rev. D85:124038
  * Lovelock (1972) Lovelock D 1972 J. Math. Phys 13: 874
  * Macaulay et al. (2013) Macaulay E, Wehus I, Eriksen HK 2013 Phys. Rev. Lett. 111:161301
  * Maggiore & Mancarella (2014) Maggiore M, Mancarella M 2014 Phys. Rev. D90:023005
  * Mancarella (2017) Mancarella M 2017 PhD. Thesis
  * HSC (2018) HSC collaboration, Mandelbaum R, Miyatake H, Hamana T, Oguri M et al. (HSC collaboration) 2018 PASJ 70:S25
  * Melchior et al. (2014) Melchior P, Sutter P, Sheldon ES, Krause E, Wandelt, BD et al. 2014 M.N.R.A.S. 440:2922
  * Miller et al. (2002) Miller A, Beach J, Bradley S, Caldwell R, Chapman H et al. 2002 Astroph. Journ. Suppl. 140:115
  * Mueller et al. (2018) Mueller EM, Percival W, Linder E, Alam S, Zhao GB et al. 2018 M.N.R.A.S. 475:2122
  * Nadathur et al. (2015) Nadathur S, Hotchkiss S, Diego JM, Iliev IT, Gottlober S et al. 2015 M.N.R.A.S. 449:3997
  * Nicolis et al. (2009) Nicolis A, Rattazzi R, Trincherini E 2009 Phys. Rev. D79:064036
  * Peirone et al. (2018) Peirone S, Koyama K, Pogosian L, Raveri M, Silvestri A 2018 Phys. Rev. D97:043519
  * SCP (1998) Supernova Cosmology Project (SCP) Collaboration, Perlmutter S, Aldering G, Goldhaber G, Knop, RA et al. 1998 Astroph. Jour. 517:565
  * Planck (2014) Planck Collaboration, Ade P, Aghanim N, Armitage-Caplan C, Arnaud M et al. 2014 A.& A. 571:A20
  * Planck (2016) Planck Collaboration, Ade P, Aghanim N, Arnaud M, Ashdown M et al. 2016 A.&A. 594:A14
  * Planck (2018a) Planck Collaboration, Aghanim N, Akrami Y, Ashdown M, Aumont J, Baccigalupi C et al. 2018a Submitted ArXiv:1807.06209
  * Planck (2018b) Planck Collaboration, Akrami Y, Arroja F, Ashdown M, Aumont J, Baccigalupi C. al 2018b Submitted 1807.06211
  * Pogosian & Silvestri (2016) Pogosian L, Silvestri A 2016 Phs. Rev. D94:104014
  * Puchwein et al. (2013) Puchwein E, Baldi M, Springel V 2013 M.N.R.A.S. 436:348
  * Pullen et al. (2015) Pullen AR, Alam S, Ho S 2015 M.N.R.A.S. 449:4326
  * Pullen et al. (2016) Pullen A, Alam S, He S, Ho S 2016 M.N.R.A.S. 460:4098
  * Randall & Sundrum (1999) Randall L, Sundrum R. 1999 Phys. Rev. Lett 83:3370
  * Riess et al. (1998) Riess A, Filippenko A, Challis P, Clocchiatti A et al. 1998 Astron. J 116:1009
  * Riess et al. (2016) Riess A, Macri LM, Hoffmann S, Scolnic D, Casertano S et al. 2016 Astroph. Journ. 826:56
  * Renk et al. (2017) Renk J, Zumalacarregui M, Montanari M, Barreira A 2017 J.C.A.P. 1710:020
  * Reyes, R. et al. (2010) Reyes R, Mandelbaum R, Seljak U, Baldauf T, Gunn JE et al. 2010 Nature 464:256
  * Sakstein et al. (2016) Sakstein J, Wilcox H, Bacon D, Koyama K, Nichol R 2016 J.C.A.P. 1607:019
  * Sakstein et al. (2017) Sakstein J, Jain B, Heyl J, Hui L 2017 Astroph. Journ. 844:L14
  * Samushia et al. (2014) Samushia L, Reid B, White M, Percival WJ, Cuesta AJ et al. 2014 M.N.R.A.S. 439:3504
  * Schmidt et al. (2011) Schmidt F, Vihlinin A, Hu W 2011 Phys. Rev. D83:063503
  * Schwarz et al. (2015) Schwarz D, Copi C, Huterer D, Starkman G 2015 Class. Quant. Grav. 33:184001
  * Simpson & Peacock (2010) Simpson F, Peacock J 2010 M.N.R.A.S. 402:2009
  * Singh et al. (2018) Singh S, Alam S, Mandelbaum R, Seljak U, Rodriguez-Torres S et al. 2018 Submitted ArXiv:1803.08915
  * Spergel et al. (2015) Spergel D, Flauger R, Hlozek R 2015 Phys. Rev. D91:023518
  * Springel (2005) Springel V 2005 M.N.R.A.S. 364:1105
  * Sotiriou & Faraoni (2010) Sotiriou T, Faraoni V 2010 Rev. Mod. Phys. 82:451
  * Sutter et al. (2012) Sutter P, Lavaux G, Wandelt B, Weinberg D 2012 Astroph. Journ. 761:44
  * Switzer et al. (2013) Switzer E, Masui KW, Bandura K, Calin L-M, Cheng T-C et al. 2013 M.N.R.A.S. 434:L46
  * Tattersall et al. (2018) Tattersall O, Ferreira P, Lagos M 2018 Phys. Rev. D97:084005
  * Terukina et al. (2014) Terukina A, Lombriser L, Yamamoto K, Bacon D, Koyama K et al. 2014 J.C.A.P. 4:013
  * Teyssier (2002) Teyssier R 2002 A.& A. 385:337
  * Thorne & Will (1971) Thorne K, Will C 1971 Astroph. Jour. 163:595
  * Vainshtein (1972) Vainshtein AI 1972 Phys. Lett. 39B:393
  * Valogiannis & Bean (2017) Valogiannis G, Bean R 2017 Phys. Rev. D95:103515
  * Valogiannis & Bean (2018) Valogiannis G, Bean R 2018 Phys. Rev. D97:023535
  * Wang et al. (2012) Wang J, Hui L, Khoury J Phys. Rev. Lett. 109:241301
  * Weinberg (1964) Weinberg S 1964 Phys. Rev. 135:B1049
  * White (2016) White M 2016 J.C.A.P. 1611:057
  * Will (2014) Will C Living. Rev. Rel. 4:4
  * Winther et al. (2015) Winther H, Schmidt F, Barreira A, Arnold C, Bose S et al. 2015 M.N.R.A.S. 454:4208
  * Winther et al. (2017) Winther H, Koyama K, Manera M, Wright B, Zhao GB et al. 2017 J.C.A.P. 1708:006
  * Woodard (2007) Woodard R 2007 Lect.Notes Phys. 720: 403
  * Zhang et al. (2007) Zhang P, Liguori M, Bean R, Dodelson S 2007 Phys. Rev. Lett. 99:141302
  * Zlosnik et al. (2007) Zlosnik T, Ferreira PG, Starkman G 2007 Phys. Rev. D75:044017
  * Zumalacarregui & Garcia-Bellido (2014) Zumalacarregui M, Garcia-Bellido J 2014 Phys. Rev. D89:064046
  * Zumalacarregui et al. (2017) Zumalacarregui M, Bellini E, Sawicki I, Lesgourgues J, Ferreira PG 2017 J.C.A.P. 1708:019