BEdgeHealth: A Decentralized Architecture for Edge-based IoMT Networks Using Blockchain

Dinh C. Nguyen, Member, IEEE, Pubudu N. Pathirana, Senior Member, IEEE,

Ming Ding, Senior Member, IEEE, and
Aruna Seneviratne, Senior Member, IEEE
*Part of this work has been accepted at the IEEE Global Communications Conference (GLOBECOM), Taiwan, 2020 [1].
Dinh C. Nguyen is with School of Engineering, Deakin University, Waurn Ponds, VIC 3216, Australia, and also with the Data61, CSIRO, Docklands, Melbourne, Australia  (e-mail: cdnguyen@deakin.edu.au).
Pubudu N. Pathirana is with School of Engineering, Deakin University, Waurn Ponds, VIC 3216, Australia (email: pubudu.pathirana@deakin.edu.au).
Ming Ding is with the Data61, CSIRO, Australia (email: ming.ding@data61.csiro.au).
Aruna Seneviratne is with School of Electrical Engineering and Telecommunications, University of New South Wales (UNSW), NSW, Australia (email: a.seneviratne@unsw.edu.au).

Accepted at IEEE Internet of Things Journal

The healthcare industry has witnessed significant transformations in e-health services by using mobile edge computing (MEC) and blockchain to facilitate healthcare operations. Many MEC-blockchain-based schemes have been proposed, but some critical technical challenges still remain, such as low quality of services (QoS), data privacy and system security vulnerabilities. In this paper, we propose a new decentralized health architecture, called BEdgeHealth that integrates MEC and blockchain for data offloading and data sharing in distributed hospital networks. First, a data offloading scheme is proposed where mobile devices can offload health data to a nearby MEC server for efficient computation with privacy awareness. Moreover, we design a data sharing scheme which enables data exchanges among healthcare users by leveraging blockchain and interplanetary file system. Particularly, a smart contract-based authentication mechanism is integrated with MEC to perform decentralized user access verification at the network edge without requiring any central authority. The real-world experiment results and evaluations demonstrate the effectiveness of the proposed BEdgeHealth architecture in terms of improved QoS with data privacy and security guarantees, compared to the existing schemes.

Blockchain, mobile edge computing, healthcare, data offloading, data sharing, security.

§ INTRODUCTION

Recent advances in mobile edge computing (MEC) and Internet of Medical Things (IoMT) technologies have promoted smart e-health services [2] in the healthcare industry. In hospital networks, health data collected from mobile devices (MDs), i.e., smartphones, laptops, and tablets, can be offloaded to nearby MEC servers for low-latency data execution, which thus helps improve users' computation experience, enhance quality of services (QoS) and reduce computing burden on local devices. Further, MEC also enables the ubiquitous sharing of health data acquired from the offloading phase among health users  to support healthcare delivery [3]. For example, a doctor can exploit health data at the network edge to serve disease diagnosis and treatment, and patients can gain medical benefits such as medication advice in a low-latency fashion. Particularly, blockchain, a disruptive technology for enabling healthcare in recent years, is able to provide high security for health data sharing due to its unique features such as decentralization, traceability, and immutability [4]. In fact, blockchain can ensure reliable data exchange among healthcare users such as healthcare providers, insurance companies, and patients in smart healthcare environments like cooperative hospital networks [5], by using immutable data ledgers and smart contracts [4]. Enabled by the computing efficiency of MEC and the security features of blockchain, the combination of these two emerging technologies has been regarded as the key enabler for smart healthcare services, i.e., data offloading and data sharing, in distributed hospital settings [2].

However, realizing the potential of such a comprehensive system in healthcare still faces non-trivial challenges. First, how to offload IoT healthcare data to the MEC servers to support e-health applications while guaranteeing both high QoS (i.e., minimal service latency) and data privacy is a critical issue. Most traditional approaches [6, 7] only either focus on the QoS problem of network latency and energy usage or data privacy for the healthcare offloading, while building a holistic framework with all these factors taken into consideration is vitally necessary. Second, some data sharing solutions in [8] rely on a centralized cloud architectur which is prone to single-point failures and raises trust concerns from third party. The storage of electronic health records (EHRs) in central cloud also incurs high communication overhead, although it requires less data management efforts. Final, some blockchain-based proposals for health data sharing have been introduced in recent works [9, 10, 11]. However, these schemes often use a classic interplanetary file system (IPFS) which relies on a global Distributed Hash Table (DHT) for health data storage and sharing, leading to high data retrieval latency. To be clear, to access a record stored on an IPFS node, one needs to refer to a DHT to obtain the hash and then returns to the IPFS node for retrieving data, which incurs high data sharing overhead. Moreover, the potential of blockchain for healthcare sharing scenarios with MEC in cooperative hospital networks has not been adequately investigated.

To fill these research gaps, this paper proposes a new decentralized health architecture which integrates a data offloading scheme and a data sharing scheme for distributed hospital networks with MEC and blockchain. Particularly, we design  a new decentralized smart contract associated with IPFS running on top of the MEC network which brings two key benefits. First, the smart contract is able to provide authentication and traceability in the data sharing [9]. Any upload events or user access behaviours in the hospital network will be authenticated and traced by the contract without the need of external authority. Further, any modification or alternation on the data record will lead to a change on hash value, which can be also traced by the contract. Second, the combination of smart contract and IPFS helps accelerate the data retrieval rate. Here, we make an improvement in IPFS design by eliminating the global DHT. Instead, we store directly the hash values of data records in the smart contract at each of the MEC servers, which improves the data lookup and data retrieval rates in the data sharing.

§.§ Motivations and Contributions

First, the work in [12] makes us realize that the research on health data offloading and data sharing is of great practical significance in facilitating smart healthcare. Second, the existing studies on mobile health data offloading [13], [14] motivate us to focus on the MEC framework for highly efficient health data computation. Moreover, the analysis in [15], [9] and the preliminary results from our recent work [10] reveal that blockchain can provide promising health data sharing solutions with improved QoS and enhanced security. Third, the in-depth discussion in [4] highlights the urgent need of developing a comprehensive architecture of data offloading and data sharing for improving the healthcare quality. Therefore, the above existing works strengthen our determination to implement a comprehensive healthcare architecture by using blockchain, IPFS, smart contract and MEC technologies. The key contributions of this paper are summarized as follows:

* We propose a new decentralized health architecture for a cooperative hospital network, called BEdgeHealth that integrates blockchain and MEC for data offloading and data sharing with user QoS and security awareness.

* We propose a privacy-aware health data offloading scheme where MDs can offload data tasks to a nearby MEC server for efficient computation. An optimization algorithm is built on each MD to minimize the offloading cost of energy consumption, processing time, and memory usage with respect to system constraints.

* We develop a data sharing scheme enabled by the cooperation of blockchain, MEC, smart contract and IPFS in the distributed hospital network. Particularly, a decentralized authentication mechanism associated with a distributed IPFS storage is built to implement access control and data management at the network edge without requiring third party, in order to enhance the sharing security and improve data retrieval rate.

* We conduct real-world experiments to evaluate the effectiveness of the proposed BEdgeHealth architecture. The implementation results and discussions demonstrate the superior performance of our proposed approach over the existing works.

§.§ Organization

The remainder of the paper is organized as follows. Section <ref> discusses the literature works related to health data offloading and data sharing. In Section <ref>, we introduce our decentralized health architecture where the network components and blockchain are explained. We then present our data offloading scheme in Section <ref> where the offloading model is formulated. Next,  Section <ref> introduces the health data sharing scheme using blockchain in distributed hospitals. The experimental results are provided in Section <ref>, while Section <ref> presents the security analysis and discussions. Finally, Section <ref> concludes the paper and highlights some possible future works.

§ RELATED WORKS

In this section, we survey the literature works related to health data offloading and sharing in healthcare.

§.§ Health Data Offloading

Many data offloading approaches have been proposed to support healthcare. In [6], mobile healthcare data can be offloaded to cloud for processing, analysis, and storage, but it remains high latency incurred by offloading data to remote clouds. Also, the offloading privacy is not considered, which puts sensitive health data at risks of external attacks. Another work in [12] proposed an IoT architecture for executing healthcare applications on clouds, but the optimization for memory usage of MDs in the offloading has been overlooked. In fact, there is close relationship between memory usage and the data task as investigated in the recent work [16]. That is, the higher size of data tasks to be offloaded, the higher device memory required to handle the task. Therefore, it is important to consider device memory usage in the data task offloading. Other works in [7, 13, 14] concentrated on offloading security issues in healthcare. For example, the research in [13] used a hash function and a key cryptosystem for data security. Also, the offloading privacy issues were also solved in [7], [14] by using consensus algorithms and learning-based privacy preservation techniques with respect to response time and delay requirements. However, the above studies lack the joint consideration of all QoS constraints (i.e., network latency, energy consumption and memory usage) and privacy awareness, which are the important aspects of practical health data offloading systems [3].

The proposed healthcare architecture with MEC and blockchain.

§.§ Health Data Sharing

Several solutions using blockchain have been introduced for health data sharing. Our preliminary work in [1] proposed a decentralized health data sharing based on blockchain and MEC for federated hospitals. The work [8] presented a privacy-preserved data sharing scheme enabled by the conjunction of a tamperproof consortium blockchain and cloud storage. Furthermore, the authors in [15] described a hybrid architecture of using both blockchain and edge-cloud nodes where smart contracts are employed to monitor access behaviours and transactions. Despite data privacy enhancements, such solutions [8], [15] mainly rely on central cloud servers for EHRs storage, which remains single-point failure bottlenecks and incurs high communication overhead. Further, the performances of smart health contract have not been evaluated. Another work in [9] employed an IPFS system with Ethereum blockchain for EHRs sharing over clouds, but the important performance metrics such as data retrieval speed and security capability have not been verified. Moreover, the work in [11] described a privacy-preserving EHRs sharing by using blockchain in the Ethereum. Blockchain stores hash values of EHRs while raw data is kept on the cloud server. The authors also constructed a stealth authorization framework to achieve privacy-preserving access authorization delivery over the hospital network. The study in [17] suggested an EdgeCare model that uses edge computing for healthcare management in decentralized health environments. The local authorities were employed to perform access verification for the data offloading and sharing, but healthcare storage has not been considered. Also, a privacy-preserving sharing scheme for IoTs including healthcare was also considered in [18] by using a classic IPFS system with a global DHT look-up solution that results in unnecessary
communication overhead.

§ SYSTEM MODEL

In this section, we present a new health architecture in hospital networks and then describe our blockchain design.

§.§ Proposed Healthcare Architecture with MEC and Blockchain

Here, we propose a decentralized health architecture as shown in Fig. <ref>. The proposed architecture consists of a network of cooperative hospitals linked by a blockchain ledger. Each hospital is controlled by an MEC server which executes the data tasks offloaded by MDs and also communicates with other MEC servers for data sharing. Here, we consider a set of MEC servers as $\mathcal{M} = \{1,2,..., M\}$, each MEC server $m$ is located at a hospital $HP_m$. We assume that each hospital has a set of MDs $\mathcal{N} = \{1,2,..., N\}$ which collect data from a set of patient $\mathcal{J} = \{1,2,..., J\}$ using IoMT devices. Then, this data is offloaded to the MEC server for computation via the data offloading scheme. Note that here we consider at each hospital $HP_m$, a MD $n$ can collect health data from different patients. We also assume that there is a set of healthcare users (HUs) $\mathcal{U} = \{1,2,..., U\}$ such as doctors, clinicians who may be situated at any hospital and want to access data on the MEC network via the data sharing scheme (healthcare users, users and HUs are used interchangeably throughout the paper). The details of each network components are explained as follows.

* MEC servers: Each MEC server acts as a coordinator that manages a group of MD devices in its hospital to provide low-latency computation services in the data offloading scheme. The MEC server also links with the other MEC servers from other hospitals in a peer-to-peer (P2P) manner to build a decentralized data sharing network. We consider a realistic scenario that MEC servers may be semi-trusted, which means that the MEC server may be curious about health data and misbehaves in the data sharing. To overcome these challenges, we store sensitive EHRs data in the IPFS, instead of in the MEC server's hard drive, while the hash value of data record is kept in the smart contract so that any data retrieval behaviours are traced on the blockchain in a transparent manner.

* Healthcare users (HUs): HUs such as doctors and clinicians across federated hospitals may be interested in EHRs data for providing healthcare, e.g., medical diagnosis. Considering the realistic health settings that the HUs are not trusted, we develop an access control mechanism based on smart contracts to perform authentication of user access behaviours, which will be presented in Section <ref>. Only authenticated users are able to retrieve data in the IPFS, while malicious users are detected and prevented.

* Mobile devices (MDs): MDs such as smartphones, laptops are responsible for gathering data from IoMT sensors. The MD can use its hardware to execute its data tasks or offload them to a nearby MEC server by data offloading. In this paper, we use smartphones as MDs to collect data from wearable sensors and perform data computation.

* IPFS storage: As MEC servers are semi-trusted, in our paper, raw EHRs collected from IoMT and data processed from the offloading phase are uploaded to the decentralized off-chain IPFS platform running on top of the MEC network. IPFS introduces low-latency and fast decentralized archiving with reliable P2P content delivery, which has been investigated in healthcare scenarios [19]; and thus it is well suitable for our health applications. Specially, in our work, we make an improvement in the IPFS design by replacing the global DHT with smart contracts to manage the hash records of health data, aiming to solve communication latency issues remained in classic IPFS systems [9, 10].

* Smart contract: A smart contract can be regarded as a self-operating computer program which is automatically executed when specific conditions are met [4]. Each contract has an account that contains data and codes with programmable logic functions. In our paper, we design a contract called access control smart contract (ACSC). Each MEC server holds a copy of smart contracts and any their new events (i.e., user access) are updated at other MEC servers via the global blockchain network. The details of our contract design will be explained in the following section.

§.§ Blockchain Design

Blockchain is the heart of our decentralized healthcare architecture. In this paper, we suggest using a permissioned Hyperledger Fabric [20] blockchain platform based on practical Byzantine fault tolerance (PBFT) consensus to implement our healthcare system. The Hyperledger Fabric blockchain only allows authenticated users to join the network, and the validation is performed by only pre-selected nodes with high computing capability, i.e., MEC servers in our scenario, without mining requirements for lightweight entities like mobile users. This would improve the transaction performance, i.e., low transaction latency, compared to permissionless blockchains such as Ethereum [20]. As shown in Fig. <ref>, we consider two types of blockchain for our healthcare architecture: a global blockchain and local blockchains.

* Global blockchain: It interconnects all MEC servers together for hospital communications under the control of all MEC servers. Once a data storage event at each MEC server occurs (triggered by the offloading process), this MEC server broadcasts an offloading transaction to the other MEC servers for global updates. Moreover, in the data sharing phase, when a mobile user performs a data request to an MEC server, this MEC server also creates a sharing transaction and broadcasts it to other MEC servers in the hospital network.

* Local blockchain: Each hospital deploys a local hospital to link the local MEC server with its mobile users. This local blockchain is controlled by the local MEC server. When a mobile user performs a data request to the MEC server, he creates a sharing transaction and submits it to the local blockchain so that the MEC server can process the request and return the data. If the MEC server can look up data locally, the server will return immediately to the user. Otherwise, it asks the other MEC servers to find the address of the requested data and then responds the user.

Remark: It is worth noting that in the proposed healthcare architecture as illustrated in Fig. <ref>, blockchain is only used in the sharing scheme, while we assume that the offloading network is private and thus does not need to apply blockchain in the offloading scheme. In fact, this assumption holds in practical hospital settings [21] where each MD is managed by its healthcare provider such as a physician who uses the device to only collect data from his trusted patients and offload it to the MEC server in each medical test.

In the following sections, we will present our designs for a data offloading scheme and a data sharing scheme in details.

§ HEALTH DATA OFFLOADING

In this section, we introdude the offloading scheme and then formulate the offloading model in details.

§.§ Offloading Model

Here, we focus on formulating the offloading model for a representative hospital. Based on the QoS requirements (i.e., latency, energy consumption), each health data task can be executed at the MD or at the MEC server via task offloading.  Accordingly, we introduce an offloading decision policy for each MD $n$ denoted by a binary variable $x_n \in \{0,1\} $. Here $x_n= 0$ means that the MD $n$ decides to process its data task locally, and $x_n = 1$ indicates that the MD $n$ offloads its task to the MEC server. For the sake of simplicity, we assume that each MD $n$ has a task $Y_n$ to be executed, which can be defined by a variable $Y_n = (D_n, X^l_n, T^{max}_n)$, where $D_n$ expresses the size of the input data (in bit), $ X^l_n$ denotes the required number of CPU cycles of the task, and $ T^{max}_n$ specifies the maximum permissible latency (in second) to accomplish the task $ Y_n$. Motivated by the experimental results of our recent work [22], in this paper we propose an offloading architecture as shown in Fig. <ref> which consists of two main modules: task profile and decision maker installed on each MD $n$.

- Task profile: This module is responsible for collecting all task information such as the data task $Y_n$, energy consumption ($E_n$), processing time ($T_n$) and memory usage ($M_n$), by using mobile performance measurement tools. Therefore, a task profile of a MD $n$ can be formulated as a tuple $ [Y_n, E_n, T_n, M_n]$ which is then stored in a database of the MD $n$ for supporting the offloading decision process. Details of the modelling of each component in the task profile will be presented in the following section.

- Decision maker: This module receives task profile information collected by the profile module to make offloading decisions. Similar to [23], we employ an integer linear programming model to develop a decision making algorithm on MDs. By using profile information, the algorithm analyses and makes decisions whether the data task should be offloaded to the MEC server or not. The main objective is to determine an optimal computation decision for each task to minimize the offloading cost of energy consumption, execution latency and memory usage.

§.§ 	Offloading Formulation

In the literature, the existing schemes [7, 13, 12, 14] lack a joint consideration of important QoS metrics in health data offloading, including processing time, energy consumption and memory usage. Moreover, data privacy issues in the offloading have not been solved [6]. Motivated by the limitations of current schemes, we here formulate the health data offloading problem by taking these factors into account. Two computation modes are considered, namely local execution and offloading.

The data offloading scheme.

§.§.§ Local Execution

When a MD decides to execute the task $Y_n$ locally ($x_{n} =0$), it uses its resource to process healthcare data. We denote $X^l_n,f^l_n$ as mobile CPU utilization for task $n$ (in CPU/bit) and mobile computational capacity (in CPU/sec), respectively. Then, the local execution time can be calculated as

\begin{equation}
T^{local}_n = \dfrac{D_nX^l_n}{f^l_n}.
\end{equation}

We also define $E^{local}_n$ and $M^{local}_n$ as battery consumption (in Mah) and memory usage (in MByte), which can be measured by mobile measurement tools [23].

§.§.§ Offloading to the MEC Server
In the case of task offloading ($x_{n} =1$), the data task needs to be encrypted for privacy before transmitting to the MEC server. Here we employ an Advanced Encryption Standard (AES) encryption function installed in each MD to encrypt healthcare data due to its less energy consumption and low latency [24]. Thus, the time required to accomplish a task in the offloading mode includes three parts: the task encryption time at the MD $n$, the time for transmitting the task to the MEC server, and the task execution time at the MEC server. Then, let denote $X^{enc}_n, X^e_n $ as mobile CPU utilization for encrypting the task $Y_n$ (in CPU cycles/bit) and edge CPU utilization (in CPU cycles/bit), respectively, the total offloading time is specified as

\begin{equation}
T^{offload}_n = \dfrac{D_nX^{enc}_n}{f^l_n} + \dfrac{D_n}{R_n} + \dfrac{D_nX^{e}_n}{f^e_n},
\end{equation}

where $f^e_n$ is defined as the computational resource (in CPU cycles/second) allocated by the MEC server to accomplish the task $Y_n$, which should not exceed the available edge computational budget $f^e$. Also, $R_n$ is the data transmission rate of the MD $n$ (in bit/second).

Moreover, the energy consumption for the offloading is mainly characterized by the encryption energy and transmission energy [23]. Then, we define $E^{enc}_n$ as battery consumption when encrypting the task $Y_n$ at the MD $n$ which is measured by mobile measurement tools. Moreover, according to [22], the transmission energy is computed by

\begin{equation}
E^{trans}_n = p_n\dfrac{D_n}{R_n},
\end{equation}

where $p_n$ is the transmission power of the MD $n$. Hence, the total offloading energy is specified by

\begin{equation}
E^{offload}_n =E^{enc}_n + E^{trans}_n.
\end{equation}

The offloading process also incurs a memory usage cost for encryption, defined as $M^{offload}_n$, which can be also obtained through mobile measurement tools [23]. Accordingly, the total offloading time, energy consumption and memory usage can be expressed respectively as

\begin{equation}
T_n = (1-x_n)T^{local}_n + x_nT^{offload}_n,
\end{equation}

\begin{equation}
E_n = (1-x_n)E^{local}_n + x_nE^{offload}_n,
\end{equation}

\begin{equation}
M_n = (1-x_n)M^{local}_n + x_nM^{offload}_n.
\end{equation}

§.§.§ Offloading Problem Formulation

Based on above formulations, we derive the optimization problem to jointly optimize time latency, energy consumption and memory usage under system constraints as follows

\begin{equation}
\begin{aligned}
& (P1): \underset{\textbf{x}}{\min}
&& \sum_{n=1}^{N} \left(\alpha_tT_n+\alpha_eE_n+\alpha_mM_n\right)\\
& \text{subject to}
&& (C1): x_n \in \{0,1\}, \forall n \in \mathcal{N}, \\
&&& (C2): T_n \leq T^{max}_n, n \in \mathcal{N},\\
&&& (C3): R_n \geq R^{min}_n, n \in \mathcal{N},\\
&&& (C4): M_n \leq M^{max}_n, n \in \mathcal{N}, \\
&&&(C5): 0 < p_n \leq P_n, n \in \mathcal{N},  \\
&&& (C6): 0 <f^e_n \leq f^e, n \in \mathcal{N}.
\end{aligned}
\end{equation}

where $\textbf{x} = [x_1, x_2,...,x_N]$ is the offloading decision vector of all MDs $n \in \mathcal{N}$, and $\alpha_t, \alpha_e, \alpha_m$ are the weights of time, energy and memory cost, respectively. In the problem (P1), the constraint (C1) implies that each task can be either executed locally or offloaded to the MEC server.  Further, the total task execution time should not exceed a maximum latency value (C2). The constraint (C3) is added to guarantee the reliability of the task offloading at a MD $n$, where $R^{min}_n$ is the minimum transmission rate and specified by $ R^{min}_n = D_n/T^{max}_n$. This condition ensures that the transmission time of MD $n$ during the offloading process is not too long, and thus the computation of the data task can be completed before the deadline $ T^{max}_n$. (C4) defines that the memory used for task computation must not exceed the available mobile memory. (C5) shows the transmission power constraint of each MD, and the constraint (C6) shows that the MEC server must allocate a positive computing resource to each MD under an available computation budget $f^e$. In this paper, we employed a particle swarm optimization (PSO) [25] model written in java to build the above offloading optimization algorithm in Android phones. The PSO algorithm has proven its superior advantages over its counterparts like genetic algorithm in terms of extremely low computational cost and simple implementation on Android devices for mobile offloading applications like healthcare [26].

§.§ Health Data Storage

The raw health data associated with the analysed results from the data offloading scheme are stored in the IPFS system running on top of the MEC network. We here analyze a representative hospital $HP_m$ where there is an MEC server $m$ along with its network of MDs $n$ ($n \in \mathcal{N}$) and patients $PID_j$ ($j \in \mathcal{J}$). The data storage process is implemented through four steps.

* The raw health data of the patient $PID_j$ collected from the MD $n$ is offloaded to the MEC sever $m$ for computation. For simplicity, here we assume that each patient $j$ has a health data record. Then, the MEC server aggregates the raw data and the analysed result and adds them into a data record identified by the patient ID $j$ as

\begin{equation}
C_j = (rawdata||analyzedResult).
\end{equation}

* Instead of storing the data and analysed results in the MEC server's hard drive, we encrypt these data as

\begin{equation}
C^{enc}_j \leftarrow Enc(C_j,PKM_m),
\end{equation}

where $PKM_m$ is the private key of the MEC $m$ (its creation will be explained in the following section). Then we put this data to the IPFS storage node located on top of the MEC server for data security.

* Uploading the data to the IPFS storage would automatically return a cryptographic hash of its content by using a hash function $H_{IPFS}$:

\begin{equation}
h_j = H_{IPFS}(C^{enc}_j, timestamp).
\end{equation}

Here, we keep the hash value in the smart contract on the MEC server for fast data look-up, instead of relying on the classic DHT.

* The storage of a data record in the IPFS node at the MEC server $m$ is synchronized with other IPFS nodes at other hospitals via the P2P network for global data sharing. The MEC server $m$ also adds ($h_j, PID_j, PKM_m, timestamp$) as a transaction including the EHRs' hash $h_j$ and broadcasts it to the global blockchain network:

\begin{equation}
MEC_m \rightarrow *: (h_j, PID_j, PKM_m, timestamp).
\end{equation}

The other MEC servers will receive the transaction and extract the offloading information $h_j, PID_j$ that is then stored on the database of the ACSC contract. The details of contract design will be presented in the following section.

§ HEALTH DATA SHARING

The health data records stored in the IPFS from the data offloading scheme are then used in the data sharing scheme in federated hospitals. To provide authentication for data sharing, a smart contract-based access control solution is adopted at the network edge without requiring any central authority like previous works [8], [15]. This not only reduces authentication latency but also increases the reliability of data sharing. Moreover, the integration of smart contract into IPFS enables the replica of hash value of data records across the edge network which helps accelerate the data retrieval rate while the data traceability is achieved. In the following, we explain our proposed data sharing scheme as shown in Fig. <ref>, including two key parts: user authentication and data retrieval.

§.§ User Authentication with MEC and Smart Contract

The user authentication process consists of three phases: initialization phase, user registration phase, and data retrieval phase, which are explained as follows.

§.§.§ 	Initialization Phase

Each hospital is initilized by its MEC server. In this phase, a key is set up by the MEC server for data sharing establishment. Also, the MEC server $m$ in each hospital sets up the private key and the public key.

§.§.§ Registration Phase

This phase is invoked whenever a HU wants to register to the MEC server for the first time. To do so, the user joins the local blockchain network and follows the steps as below.

* Each HU $u$ submits a transaction $T_{{reg}_u}$ to the MEC server $m$ as $T_{{reg}_u}$ for registration:

\begin{equation}
T_{{reg}_u} = (PKU_u||ID_u||timestamp).
\end{equation}

* The MEC server $m$ decodes the $T_{{reg}_u}$ to obtain the user's public key as $PKU_u \leftarrow T_{{reg}_u}.getSenderPublicKey()$.

* Then, the MEC server decodes the transaction to get the user ID. First, it decodes the transaction $T_{{reg}_u}$, then finally obtain the user ID as an unique address $ADD_u$:

\begin{equation}
deT_u \leftarrow abiDecoder.decodeMethod(T_{{reg}_u}),
\end{equation}

\begin{equation}
ADD_u \leftarrow  web3.eth.getData(deT_u([ID_u])).
\end{equation}

* The MEC server checks user information and stores $\{ PKU_u, ADD_u \}$ as the user identification information in the contract database.

* The MEC server then calculates the hash value of the register transaction $T_{{reg}_u}$ as:

\begin{equation}
H_{{HU}_u} \leftarrow Hash(T_{{reg}_u}, SKM_m),
\end{equation}

which is then published to the local hospital blockchain network for tracing. The MEC server $m$ also broadcasts its public key $PKM_m$ to the user that is necessary for the future user data access.

§.§.§ User Authentication Phase

It is supposed that a HU $u$ wants to access the patient's EHRs stored on the MEC network for their medical tasks. To obtain the EHRs of the target patient, the HU $u$ needs to know his patient identity $PID_j$ so that the MEC server can locate the address of this patient in the hospital network during EHRs sharing. The data retrival process is presented by the following key steps.

* A HU $u$ prepares a data retrieval request $T_{{req}_u}$ involved a target patient ID $PID_j$ and the address of patient's hospital $HP_w$ ($w \in \mathcal{M}$). Thus, the target patient address on the hospital network can be expressed as $P_{addr}= <PID_j,HP_w>$, i.e., the $5^{th}$ patient in the $3^{th}$ hospital.  Then, the request $T_{{req}_u}$ can be specified by

\begin{equation}
T_{{req}_u} \leftarrow (PKU_u||ID_u||P_{addr}||timestamp),
\end{equation}

where each compoment in $T_{{req}_u}$ is formatted with an index in the array $index=[1-4]$, i.e., the index of $PKU_u$ is 1. This format is necessary for transaction decoding later.

* To ensure privacy, the user request should be encrypted with the MEC $m$'s public key $PKM_m$ (obtained from the registratrion phase) as $T_{{enc}_u} \leftarrow Enc(T_{{req}_u},PKM_m)$ and submits it to the MEC $m$.

* At the edge side, the MEC server $m$ decrypts the user request $T_{{enp}_u}$ as $T_{{dec}_u} \leftarrow Dec(T_{{req}_u},SKM_m)$.
To provide security for the EHRs sharing, user authentication is highly essential. To do so, the MEC server extracts the user's public key from the request as

\begin{equation}
Pub_u \leftarrow T_{{dec}_u}.getSenderPublicKey().
\end{equation}

It also decodes the transaction $T_{{dec}_u}$ to obtain the request information $ReqInf_u$:

\begin{equation}
deT_{{dec}_u} \leftarrow abiDecoder.decodeMethod(T_{{dec}_u}),
\end{equation}

\begin{equation}
ReqInf_u \leftarrow  web3.eth.getData(deT_{{dec}_u}[DataIndex]),
\end{equation}

and then obtains the user identity $Iden_u$ as

\begin{equation}
Iden_u = ReqInf_u(Index[index_{Iden}]).
\end{equation}

* The MEC server will check and authenticate the received user identification information $<Pub_u,Iden_u>$, and then put them into user mapping as

\begin{equation}
UMAP_{PK_{u}} = Map<Pub_u => PKU_u>,
\end{equation}

\begin{equation}
UMAP_{ID_{u}} = Map<Iden_u => ID_u>,
\end{equation}

by using the smart contract (see in Algorithm 1). If both $UMAP_{PK_{u}} \rightarrow true$ and $UMAP_{ID_{u}} \rightarrow true$, the user request is validated successfully, otherwise a penalty is issued for
access prevention.

* In the case of successful request validation, the MEC server $m$ will calculate the signature of $T_{{dec}_u}$ as

\begin{equation}
Sig_u \leftarrow Hash(T_{{dec}_u}, SKM_m),
\end{equation}

Finally, the MEC server will issue a certificate $Cert_{u}$ as

\begin{equation}
Cert_{u}= \{ Sig_u, PKU_u, ID_{u}, timestamp\},
\end{equation}

which is then sent to the HU $u$ via the local blockchain for successful authentication proof.

§.§ Health Data Retrieval with MEC and Blockchain

After successful authentication, the MEC server $m$ will locate the requested EHRs based on the patient information $<PID_j,HP_w> \leftarrow ReqInf_u(Index[indexPID_u])$ that is defined in the authentication phase. In fact, the patient and the user may be located in the same hospital or in different hospitals. For example, a patient may only stay at a hospital for his treatment, but in some cases (e.g., seeking treatment for a new disease), he wants to visit a different doctor in another hospital. Motivated by this realistic scenario, here we consider two cases: (1) The patient and the user are in the same hospital and (2) The patient and the user are in different hospitals.

Case 1: The patient and the user are in the same hospital: In this case, the MEC server finds that the HU and the patient are in the same hospital by checking $HP_w$ information. It is supposed that the HU $u$ communicates with the MEC server $m$ to request the data record of the patient $PID_j$ in the same hospital, then the data retrieval process is implemented by the following steps:

* The MEC server $m$ first verifies the request information $PID_j$ by refering to the ACSC contract to perform mapping between the patient record stored in the contract $PID_j^{sc}$ and information in the request $PID_j^{req}$:

\begin{equation}
UMAP_{PID_{j}} = Map<PID_j^{sc} => PID_j^{req}>.
\end{equation}

If $UMAP_{PID_{j}} \rightarrow true$, the request information is verified for ready data retrieval.

* Based on the received patient information, the ACSC contract will extract the hash value $h_j$ that represents the patient $j$'s health record. Then, the contract sends a request to the IPFS storage for data retrieval using the hash by a command: $C_j^{enc} = GET_{IPFS}(h_j)$, i.e.,: pcripfs get /ipfs/ Qmd84db7be0690ebb015f1cD9d9491cE18076c.

* Since the data stored on the IPFS was encrypted in the storage process (see in Section IV-C), we need to decrypt to obtain the real data as

\begin{equation}
C_j \leftarrow Dec(C_j^{enc}, SKM_m).
\end{equation}

The MEC $m$ then returns the data $C_j$ via a secure channel to the requestor.

* Finally, the MEC server $m$ adds a conjunction of ($PKU_u, h_j, PKM_m, timestamp$) as a transaction and broadcasts it to the global blockchain network:

\begin{equation}
MEC_m \rightarrow *: (PKU_u, h_j, PKM_m, timestamp).
\end{equation}

The proposed health data sharing procedure with MEC and IPFS.

Case 2: The patient and the user are in different hospitals:
In this case, the MEC server will seek the address of the patient in the MEC network. Due to all patient addresses ($PID_j,HP_w$) are stored on the ACSC contract replicated across the global hospital network, an MEC server at a hospital can know exactly where the requested patient data is currently located. Hence, an MEC server only needs to send the data request to the destination MEC server (using $HP_w$ information) that contains the requested data for data retrieval, without broadcasting the request to all MEC servers. This strategy not only saves data lookup time but also saves network bandwidth and potentially reduces the traffic congestion on the global blockchain network. The data retrieval process in this case is summarized as the following steps:

* The MEC server $m$ first also verifies the request information $PID_j$ from the user $PKU_u$ by refering to the ACSC contract, and then performs mapping to verify that the patient information $PID_{j}$ is correct. Then, it also identifies which MEC server is currently storing the requested data by checking $HP_w$ information. Here, we assume that an MEC server $MEC_y, (y\#m, y \in \mathcal{M})$ is holding the requested data.

* After identifying the destination MEC server $y$, the MEC server $m$ will send a transaction for data retrieval request:

\begin{equation}
MEC_m \rightarrow MEC_y: (PID_j, PKU_u, PKM_m, time).
\end{equation}

* Based on the patient information $PID_j$, the ACSC contract in the MEC $y$ obtains the hash value $h_j$. Next, the contract sends a request to the IPFS node in the MEC $y$ by a command: $C_j^{enc} = GET_{IPFS}(h_j)$, which is then decrypted to obtain the real data:

\begin{equation}
C_j \leftarrow Dec(C_j^{enc}, SKM_y).
\end{equation}

* The MEC server $y$ then transmits the collected data $C_j$ to the MEC server $m$ so that the server $m$ returns it to the requestor. Finally, the MEC server $y$ adds a conjunction of ($PKU_u, h_j, PKM_y, timestamp$) as a transaction and broadcasts it to the global blockchain network:

\begin{equation}
MEC_y \rightarrow *: (PKU_u, h_j, PKM_y, timestamp).
\end{equation}

Finally, all MEC servers update the user access events and acheive a synchronization over the data sharing across the hospital network.

The data retrieval process for two cases are shown in Fig. <ref>, and the data sharing is summarized in Algorithm 1. Here, lines (5-8) present the pre-processing steps when a HU $u$ submits a request to the MEC server. Then, the MEC server will authenticate the request using the ACSC, by verifying the identification information ($PKU_u, ID_u$) (lines 9-18). For the request authenticated by the contract, the MEC server specifies whether the patient and the user are in the same hospital or in the different hospitals. The MEC server will refer to the IPFS storage for data retrieval based on patient information $PID_j$ before returning to the HU $u$ (in lines 19-38).

Health data sharing with MEC and blockchain
[1]
Input: $ PID_j, HP_w, PKU_{u}, ID_u, T_{{req}_u} $
Output: $ Auth_u, C_j$
Initialization: (by the user HU $u$)
Encrypt the request: $T_{{enc}_u}$ and submits it to the MEC $m$
Pre-processing the request (by MEC)
The MEC $m$ decrypts the user request $T_{{enp}_u}$ as $T_{{dec}_u} \leftarrow Dec(T_{{req}_u},SKM_m)$
Obtain the user's public key: $Pub_u \leftarrow T_{{dec}_u}.getSenderPublicKey()$
Decode $T_{{dec}_u}$ and get the user identity $Iden_u$
Authentication (by the ACSC contract)
$msg.sender == MEC_m$
$PKcheck = policy[EHRresource][action].PKU_u$
$Idencheck = policy[EHRresource][action].ID_u$
$PKcheckIdencheck \rightarrow true$
$Auth_u \leftarrow AccessResult(msg.sender, Accepted, true, time)$
Accept the user request
$Auth_u \leftarrow AccessResult(msg.sender, Denied, false, time)$
Refuse the user request
$Auth_u \rightarrow true$
$HP_w == HP_w^{sc}$
(Case 1: The patient and the user are in the same hospital)
Get the data on IPFS: $C_j^{enc} = GET_{IPFS}(h_j)$
Decrypt to obtain the real data $C_j \leftarrow Dec(C_j^{enc}, SKM_m)$
The MEC $m$ returns the data $C_j$ to the $HU_u$
The MEC $m$ adds a transaction to the global blockchain network: $MEC_m \rightarrow *: (PKU_u, h_j, PKM_m, timestamp)$
$HP_w != HP_w^{sc}$
(Case 2: The patient and the user are in different hospitals)
Communicate with the MEC $y$: $MEC_m \rightarrow MEC_y: (PID_j, PKU_u, PKM_m, timestamp)$
Get the data on IPFS: $C_j^{enc} = GET_{IPFS}(h_j)$
Decrypt to obtain the real data $C_j \leftarrow Dec(C_j^{enc}, SKM_y)$
The MEC $y$ returns data $C_j$ to the MEC $m$ and then the HU $u$
The MEC $y$ adds a transaction to the global blockchain network: $MEC_y \rightarrow *: (PKU_u, h_j, PKM_y, timestamp)$

§ EXPERIMENTAL RESULTS AND EVALUATIONS

In this section, we present experiments and perform implementation evaluations in details.

§.§ Experiment Settings

We implemented a testbed to evaluate the proposed BEdgeHealth architecture. We employed three computers (Microsoft Windows 10 64-bit, Intel core i7 at 3.4 GHz, 8GB of RAM) to work as MEC servers where each MEC server represents a hospital. Each server will connect with a network of MDs via a Cisco access point. Here we used Sony Android mobile phones as MDs for data offloading and data sharing tasks with Qualcomm Snapdragon 845 processor, 2GB memory, and a battery capacity of 2870mAh. In our study, healthcare data and programming code are necessary. For a specific case study, we used Biokin sensors [10] developed by our lab as IoMT devices to collect simultaneously human motion data (including acceleration and gyroscope time-series data) with the size from 100 KB to 5 MB. This data is stored in separate files to be executed by an analysis program integrated in both Android phones and the MEC server. By using a programmed data analysis algorithm, we can estimate the movement disorder of a patient to serve doctors during clinical decisions [10]. The experiment parameters are set up as follows: task CPU workload $ X_n^l = [0.8-1.5]$ Gcyles, maximum latency threshold $T_n^{max}=10$ second, device computing capability $f^l_n= 1$ GHz, edge computing capability $f^e = 5$ GHz. The maximum transmission power $P_n$ of MDs is set to $20$ mW, and the minimum transmission rate requirement $R^{min}_n = 0.5$ Mbps. For mobile performance evaluations, we employed a Firebase Performance Monitoring[https://firebase.google.com/docs/perf-mon] service to measure processing time, battery consumption, and memory usage. The mobile application for the offloading optimization was implemented using Android studio 3.5.

For blockchain deployment, two Hyperledger Fabric platforms version 1.3 were used to build the global blockchain on the MEC system and the local blockchain on the MEC-device system. The PBFT consensus was implemented by MEC servers, while devices only joined the blockchain network for data request. We followed the instructions in the official Hyperledger Fabric tutorial to install required files and docker images [27]. The smart contract was implemented in docker to serve user authentication and data retrieval [28]. We also installed the JavaScript version of the IPFS platform in the MEC system [29].  Each of three MEC servers holds an IPFS node which is embedded with the Fabric blockchain to perform data storage and data sharing. To highlight the merits of the proposed BEdgeHealth architecture, we compare our scheme with the related works using different performance metrics which are presented as follows.

§.§ Evaluation of Data Offloading Performance

height=4.1cm, width= 18cm
[Battery consumption.]
[ybar,legend pos=north west, legend cell align=left,
ylabel=Battery consumption (Mah),ymajorgrids,
xlabel = Size of healthcare data file (KB),
symbolic x coords=200, 400, 600, 800, 1000,
[fill=green!60] coordinates  (200,2.5)  (400,3.7)  (600,4.9)  (800,7.3)  (1000,9.6) ;

[fill=blue!55] coordinates  (200,2.3)  (400,3.5)  (600,4.5)  (800,6.3)  (1000,8.6) ;
[fill=red!65] coordinates  (200,2.1)  (400,3.3)  (600,4.1)  (800,5.6)  (1000,7.3)  ;

Local execution [10], The cloud scheme [23], The proposed edge scheme

[Processing time.]
[ybar,legend pos=north west, legend cell align=left,
ylabel=Processing time (sec),ymajorgrids,
xlabel = Size of healthcare data file (KB),
symbolic x coords=200, 400, 600, 800, 1000,
[fill=green!60] coordinates (200,1.5) (400,2.6)   (600,2.8) (800,3.7) (1000,5.3)   ;

[fill=blue!55] coordinates (200,1.3) (400,2.2)   (600,2.55) (800,3.4) (1000,4.5)   ;

[fill=red!65] coordinates (200,1.1)  (400,2)  (600,2.4)  (800,2.9)  (1000,3.6) ;

Local execution [10], The cloud scheme [23], The proposed edge scheme

[Memory usage.]
[ybar,legend pos=north west, legend cell align=left,
ylabel=Memory usage (MB),ymajorgrids, ymax=120,
xlabel = Size of healthcare data file (KB),
symbolic x coords=200, 400, 600, 800, 1000,
[fill=green!60] coordinates  (200, 32)  (400,38)  (600,52)  (800,77)  (1000,93)  ;

[fill=blue!55] coordinates  (200,27)  (400,34)  (600,44)  (800,60)  (1000,80)  ;

[fill=red!65] coordinates  (200,27)  (400,34)  (600,44)  (800,60)  (1000,80)  ;

Local execution [10], The cloud scheme [23], The proposed edge scheme

[Total offloading cost.]
[ybar,legend pos=north west, legend cell align=left,
ylabel=Total offloading cost,ymajorgrids, ymax=60,
xlabel = Size of healthcare data file (KB),
symbolic x coords=200, 400, 600, 800, 1000,
[fill=green!60] coordinates  (200, 13.8)  (400,21.4)  (600,33.2)  (800,39.5)  (1000,42.1)  ;

[fill=blue!55] coordinates  (200,11.9)  (400,16.3)  (600,27.53)  (800,30.6)  (1000,34.4)  ;

[fill=red!65] coordinates  (200,10.6)  (400,14.5)  (600,23.25)  (800,27)  (1000,31.2)  ;

Local execution [10], The cloud scheme [23], The proposed edge scheme

Comparison results for health data offloading with $\alpha_e =1/3, \alpha_t=1/3, \alpha_m=1/3$.

We compare our edge offloading scheme with two baselines: local execution [10] (only executing data on devices) and cloud computation [23] (offloading to the cloud server) to prove the advantages of our scheme. A set of health data files with different sizes (200 KB-1000 KB) collected from sensors is used in our evaluations. We implement each test with 10 times to obtain average values, and evaluate the offloading performance of these schemes on processing time, energy consumption, and memory usage. We present two settings with different weight values to evaluate the tradeoff among these three performance metrics, as shown in Fig. <ref> and Fig. <ref>.

height=4.1cm, width= 18cm
[Battery consumption.]
[ybar,legend pos=north west, legend cell align=left,
ylabel=Battery consumption (Mah),ymajorgrids,
xlabel = Size of healthcare data file (KB),
symbolic x coords=200, 400, 600, 800, 1000,
[fill=green!60] coordinates  (200,2.2)  (400,3.4)  (600,4.4)  (800,7.14)  (1000,9.4) ;

[fill=blue!55] coordinates  (200,1.95)  (400,2.8)  (600,4.2)  (800,6.04)  (1000,8.3) ;
[fill=red!65] coordinates  (200,1.6)  (400,2.5)  (600,3.6)  (800,5.2)  (1000,6.7)  ;

Local execution [10], The cloud scheme [23], The proposed edge scheme

[Processing time.]
[ybar,legend pos=north west, legend cell align=left,
ylabel=Processing time (sec),ymajorgrids, ymax=11,
xlabel = Size of healthcare data file (KB),
symbolic x coords=200, 400, 600, 800, 1000,
[fill=green!60] coordinates (200,3.1) (400,5.3)   (600,6.2) (800,7.3) (1000,9.3)   ;

[fill=blue!55] coordinates (200,2.4) (400,4.2)   (600,5.15) (800,6.9) (1000,8.2)   ;

[fill=red!65] coordinates (200,1.9)  (400,3.5)  (600,4.4)  (800,5.5)  (1000,6.3) ;

Local execution [10], The cloud scheme [23], The proposed edge scheme

[Memory usage.]
[ybar,legend pos=north west, legend cell align=left,
ylabel=Memory usage (MB),ymajorgrids,
xlabel = Size of healthcare data file (KB),
symbolic x coords=200, 400, 600, 800, 1000,
[fill=green!60] coordinates  (200, 62)  (400,75)  (600,105)  (800,135)  (1000,183)  ;

[fill=blue!55] coordinates  (200,51)  (400,68)  (600,84)  (800,114)  (1000,156)  ;

[fill=red!65] coordinates  (200,51)  (400,68)  (600,84)  (800,114)  (1000,156)  ;

Local execution [10], The cloud scheme [23], The proposed edge scheme

[Total offloading cost.]
[ybar,legend pos=north west, legend cell align=left,
ylabel=Total offloading cost,ymajorgrids, ymax=60,
xlabel = Size of healthcare data file (KB),
symbolic x coords=200, 400, 600, 800, 1000,
[fill=green!60] coordinates  (200, 12.3)  (400,19.4)  (600,32.2)  (800,38)  (1000,38.3)  ;

[fill=blue!55] coordinates  (200,11.2)  (400,15.3)  (600,19)  (800,24.4)  (1000,34.12)  ;

[fill=red!65] coordinates  (200,10.6)  (400,12.5)  (600,16.6)  (800,20.25)  (1000,29.5)  ;

Local execution [10], The cloud scheme [23], The proposed edge scheme

Comparison results for health data offloading with $\alpha_e =2/3, \alpha_t=1/6, \alpha_m=1/6$.

Fig. <ref> shows the offloading performances with $\alpha_e =1/3, \alpha_t=1/3, \alpha_m=1/3$.
For the processing time, it consists of execution time in the local case, and encryption time, offloading time and remote execution time in the edge and cloud offloading cases. From Fig. <ref>(a), we can see that our edge offloading scheme consumes less energy when processing the health data tasks. As an example, offloading a 200 KB file  consumes in the edge scheme less 11% energy than that in the case of local computation and less 5% energy than that in the cloud scheme. Specially, the energy usage of the edge scheme becomes more efficient when the data size increases. For instance, the edge offloading scheme can save 21.3% energy when executing a 1000 KB file, compared to the local scheme.

Fig. <ref>(b) indicates the average processing time of three schemes, with a significant performance improvement in the proposed edge scheme. For example, executing a 200KB file by the edge scheme only consumes 1.1 sec, whereas it requires about 1.3 sec and 1.5 sec in the cloud and local schemes, respectively. This leads to a 10-18% time saving of data execution by using our edge scheme. Further, the proposed edge scheme saves up to 31% and 15% time when computing a 1000 KB file, compared to the local and cloud schemes, respectively. We also found with the selected human motion dataset, although data encryption is integrated in offloading, the edge-cloud offloading schemes still achieves better offloading performances than the local scheme, showing the efficiency of the proposed encryption technique.

Moreover, the memory performance is illustrated in  Fig. <ref>(c). The edge and cloud schemes have the same memory usage due to using the same encryption function for the offloading. However, these schemes achieve greater memory performances, with 5% and 9% memory savings compared to the local scheme when executing a 200 KB and 1000 KB file, respectively. Note that the above implementation results were obtained from the proposed offloading application with human motion data and current hardware settings of devices and MEC servers. Different mobile applications with other health data types such as videos and different hardware settings can achieve different offloading performances. However, in general, the proposed edge offloading scheme yields the best performances with reduced time latency, energy consumption, and better memory savings among three schemes for any task size. As a result, our edge scheme shows an significant improvement in the offloading performance with lower offloading cost, compared to the cloud scheme and the local scheme, as indicated in Fig. <ref>(d).

Next, we investigate the offloading performances of three schemes with $\alpha_e =2/3, \alpha_t=1/6, \alpha_m=1/6$, as illustrated in Fig. <ref>. Based on the objective function in the optimization problem (P1), a larger $\alpha_e$ value will give more penalty on the energy consumption. Particularly, the performance gap between the edge scheme and other schemes in this setting is larger than that in the previous setting in Fig. <ref> due to the increased latency and memory cost and reduced energy consumption. Moreover, our scheme achieves the best performance with lowest offloading cost among three schemes. For instance, when the task size is 1000 KB, the offloading cost of our edge scheme is 29.5, compared to 34.2 in the cloud scheme and 38.3 in the local scheme. The experimental results from two tradeoff settings in Fig. <ref> and Fig. <ref> demonstrate the advantage of our proposed edge scheme over the baselines, showing its efficiency in health offloading applications.

Authentication cost test.

Authentication functions      Computation Cost

Hash function 	   5.6 ms

Request encryption   	12.3 ms

Transaction decoding   	3.2 ms

Request decryption   	4.1 ms

User verification   	22.5 ms

PBFT consensus commitment     	30 ms

[legend pos=north west, legend cell align=left, grid=major,legend style=font=77,
xlabel=The number of healthcare users, ymax=1000,
ylabel=Authentication time (ms), every axis plot/.append style=ultra thick]
[mark =square*, blue] coordinates
[mark =triangle*, red] coordinates
Centralized authentication scheme [11],Our scheme with decentralized authentication

Authentication latency with different numbers of healthcare users.

[Data retrieval latency under blockchain designs.]

[legend pos=north west, legend cell align=left, grid=major,legend style=font=77,
xlabel=The number of data requests, ymax=8.5,
ylabel=Data retrieval latency (s), every axis plot/.append style=ultra thick]
[mark =square*, brown] coordinates
[mark =triangle*, red] coordinates
Centralized MEC-based sharing without IPFS [17],MEC-based sharing with classic IPFS [18], Our scheme with decentralized IPFS and contract

[Data retrieval latency under network designs.]

[legend pos=north west, legend cell align=left, grid=major,legend style=font=77,
xlabel=The number of data requests, ymax=10.5,
ylabel=Data retrieval latency (s), every axis plot/.append style=ultra thick]
[mark =square*, brown] coordinates
[mark =triangle*, red] coordinates
Cloud-based scheme [8],Distributed MEC with a central authority [7], Our scheme with cooperative distributed MEC

Data retrieval rate under different numbers of data requests.

§.§ Evaluation of Data Sharing Performance

For data sharing, we investigated the authentication cost, data retrieval latency, request acceptance probability, and blockchain performance.

§.§.§ Authentication Cost
We calculate the computation cost for the authentication process. Here, a user leverages his smartphone to submit a request with 160 bit to its MEC server for data retrieval in the blockchain network. The MEC server performs some functions such as encryption, decryption, transaction decoding for user verification. As shown in Table <ref>, the computation costs are small, and the latency of PBFT consensus is acceptable and thus suitable for time-sensitive healthcare applications.

Besides, we also compare the authentication latency of our proposed scheme with a centralized scheme [11] with the different number of healthcare users. In the proposed scheme, we organize the access authentication at the network edge where each MEC server authenticates its users by the distributed smart contract. Meanwhile, the scheme [11] relies on a central authority to implement its user authentication. As shown in Fig. <ref>, our scheme exhibits a lower latency compared to the baseline [11]. This is because that the use of decentralized smart contract enables fast authentication at the network edge without passing a remote authority, which thus reduces communication overhead in the authentication process.

§.§.§ Data Retrieval Latency

We investigated the data retrieval latency of our proposed model from blockchain design and network design perspectives as shown in Fig. <ref>. We used smartphones to send data requests continuously to the MEC servers to record the results. In terms of blockchain design, we use two existing works for comparison. The first one is a centralized edge-based health sharing scheme without IPFS [17] which used a centralized MEC server to serve a large hospital network and health data was stored in a classic database. The second one is an edge blockchain health sharing scheme with classic IPFS [18] that integrated blockchain and edge computing without IPFS design improvement.

From Fig. <ref>(a), we can see that when the number of requests increases, the baseline [17] has the highest data retrieval latency due to the queuing latency in the centralized MEC server. The baseline [18] used a classic IPFS storage with a global DHT look-up solution that results in unnecessary communication overhead. By contrast, our scheme provides a fully decentralized solution with distributed MEC and smart contracts, which allows to implement request verification and data look-up at the network edge without using the global DHT. As a result, our scheme can achieve a minimal data retrieval latency.

Next, we evaluated the data retrieval latency from a network design perspective as shown in Fig. <ref>(b). We leveraged a cloud-based scheme [8] and a distributed MEC with a central authority [7] as the baselines for comparison. For cloud computing implementation, we employed Amazon cloud services to communicate with smartphones [10]. The results in Fig. <ref>(b) clearly show a significant improvement in our decentralized scheme with a much lower retrieval latency. This is because our scheme combines MEC, distributed smart contracts, and decentralized IPFS for fast data retrieval, without passing any external authority during the data sharing. Meanwhile, the work in [8] relies on a remote cloud model which remains high latency due to excessive communication overhead. Also, the work in [7] used a central authority for request verification that consumes a certain overhead for communication between the MEC servers and the authority in the request verification. The above experiment results demonstrate a lower retrieval latency cost of our approach in comparison with the existing works.

§.§.§ Request Acceptance Probability
We added a time threshold $ \delta_u$ in the request transaction $ T_{{req}_u} $ to set up a new transaction involving the latency condition: $T_{{req}_u} \leftarrow (PKU_u||ID_u||P_{addr}||\delta_u ||timestamp)$. This threshold represents the maximum latency that a request needs to be responded by returning the data to the requestor before the $ \delta_u$ deadline (successful request); otherwise, the request is regarded as a failed one. Here we introduce an acceptance probability function which is defined as the number of successful requests per the total requests. As shown in Fig. <ref>, the request acceptance probability of our scheme is higher than that of the other baselines [17] and [7]. Although the probability reduces when the number of requests increases due to the longer queue time, our decentralized scheme still yields the best performance. This can be explained by the significant processing time saving achieved in our scheme thanks to an optimized edge computing and decentralized smart contract design.

[legend pos=south west, legend cell align=left, grid=major, legend style=font=77,
xlabel=The number of data requests, ymin=65,
ylabel=Successful acceptance probability (%), every axis plot/.append style=ultra thick]
[mark =square*, brown] coordinates
[mark =triangle*, red] coordinates
Centralized edge-based health sharing [17],Distributed MEC with centralized authority [7], Our scheme with decentralized authority

Request acceptance probability under different numbers of data requests.

§.§.§ Blockchain Performance

Next, we evaluate the performance of our permissioned Hyperledger Fabric blockchain and compare it with the popular permissionless Ethereum blockchain used in [18]. We run the ACSC contract on three computers and use smartphones to send transaction continuously to the computers to measure the average transaction latency in the local blockchain. As indicated in Fig. <ref>, our proposed Hyperledger Fabric blockchain exhibits a much lower transaction latency, compared to the Ethereum blockchain under the varying number of transactions. This experiment result shows the suitability of using Hyperledger Fabric blockchain for time-sensitive healthcare applications like our scenario.

[ybar,legend pos=north west, legend cell align=left,
ylabel=Transaction latency (ms),ymajorgrids,
xlabel = The number of transactions,
symbolic x coords=1, 20, 40, 60, 80,
[fill=green!60] coordinates (1,150) (20,460)   (40,880) (60,1370) (80,1910)  ;

[fill=blue!55] coordinates (1,130) (20,222)   (40,665) (60,820) (80,1205)   ;
Ethereum blockchain [18], Our Hyperledger blockchain

Comparison on transaction latency of Hyperledger and Ethereum blockchains.

§ SECURITY ANALYSIS AND DISCUSSIONS

§.§ Security Analysis

In this sub-section, we present the attack model and then analyze theoretically some key security features acheived by our blockchain design.

§.§.§ Attack Model

We consider two types of attacks: internal attack and external attack.

- Internal attack: According to our design description in the previous sections, the MEC servers and healthcare users in this paper are considered semi-trusted in the data sharing, while the MDs are regarded as fully trusted entities in the private offloading.
Under the semi-trusted assumption, the MEC servers would be honest but curious about the health data and thus can infer some sensitive information from transactions on the blockchain.

- External attack: During data offloading and sharing, external attackers can gain access to obtain health information. For example, an adversary can attack the MEC server to obtain patient information offloaded from MDs. Also, the data sharing may be vulnerable due to the data threats on the communication between the MEC server and healthcare users.

Next, we present the main security properties of our proposed BEdgeHealth scheme, and explain how these properties make our scheme resilient to security threats.

§.§.§ Security Analysis

Our scheme is able to provide four important security features, including data privacy, authentication, traceability, and confidentiality.

2.1) Data privacy: Our scheme can preserve data privacy in both data offloading and data sharing schemes. In data offloading, the health data is actually encrypted by an AES encryption function in MDs when performing the offloading. Moreover, the health data offloaded from MDs is encrypted by using the private key of the MEC server $\left( C^{enc}_j \leftarrow Enc(C_j,PKM_m)\right)$.  An external adversary may not decrypt the data due to the lack of MEC server's private key. Thus, the health data privacy is preserved. In the data sharing, the data request is also encrypted $\left(T_{{enc}_u} \leftarrow Enc(T_{{req}_u},PKM_m)\right)$ so that private user information is protected against threats. Moreover, the data transactions stored in the blockchain cannot changed or modified by using immutable ledgers. Unlike recent works [15, 9, 10] with a centralized IPFS on a third-party cloud which may remain data leakage, our architecture provides strong data control in the MEC network under the management of blockchain without a third party. This would eliminate single-point failures and avoid illegal data usage for better data privacy control.

2.2) Authentication: In our BEdgeHealth scheme, the data sharing is authenticated in a decentralized manner with the help of the distributed ACSC contract. In our design, the smart contract works independently with the MEC server which means the authentication policies cannot be controlled by the misbehaving MEC server but managed by the global blockchain network. Any contract updates are reflected on the blockchain network and monitored by all MEC servers. This would avoid the risks of contract modifications caused by internal attacks and hence ensure reliable contract operations. In the data sharing, the data retrieval is executed only if the user information $PKU_u, ID_u$ is authenticated by the contract.

2.3) Traceability: This is ensured by the fact that our BEdgeHealth framework is running on a blockchain network where any data access events and user behaviours are traced by all entities that cannot achieved in the existing works [7, 8, 11]. A user request  to our BEdgeHealth system is registered by an MEC server and broadcast to all other entities in both global blockchain and local blockchains. As a result, all MEC servers and users have acknowledged a data access event when it occurs. Furthermore, one can easily trace the origin where data is modified or updated through transaction logs. Moreover, we store health data on IPFS associated with smart contracts, instead of in the MEC server's hard drive to achieve traceability over data usage. To be clear, the raw data is stored in the IPFS while the hash value of data is kept in the smart contract. Hence, any modification or change behaviours on a data record will lead to a change in its hash value, and thus the smart contract can detect for prevention. Moreover, since all activities at an MEC server are recorded and synchronized on the global blockchain, other MEC servers can also trace them in a transparent manner.

2.4) Confidentiality: In BEdgeHealth, the confidentiality of health communications is guaranteed by exploiting the standard cryptographic primitives. We employ key-based encryption solutions coupled with digital signatures for our offloading and sharing schemes. An external attack cannot gain access to the health communication due to the lack of private keys of entities (i.e., MEC servers or health users). Even if an external adversary tries to modify or change the communication protocol, the message digest on blockchain would detect such malicious actions. In fact, to modify the metadata on blockchain, an attack needs an extensive computation capability to gain the power control from all MEC servers, which may be nearly impossible to achieve in practice [2]. Hence, the user confidentiality can be preserved.

Based on the above implementation results and discussions, we summarize the key features of our proposed BEdgeHealth architecture and compare with the related works in Table <ref>. The comparison results demonstrate the advantages of our scheme over the conventional schemes, showing the usability of our BEdgeHealth architecture in practical e-health applications.

§.§ Discussions

In this article, we present a decentralized BEdgeHealth architecture in hospital networks with a data sharing scheme and a data offloading scheme, and their performances are also verified via real-world experiments. By using MEC, our scheme is able to provide efficient health data offloading services at the network edge, proximity to MDs and IoMT networks, for user QoE improvement. Moreover, the health data can be stored and shared over the distributed hospital networks using blockchain without the need of central authority. We incorporate smart contracts with IPFS for enabling reliable access authentication and fast data retrieval in order to facilitate the data exchange among healthcare users. However, the integration of smart contracts in IPFS possibly introduces new challenges, including security vulnerabilities which can include timestamp dependence, mishandled exceptions, reentrancy attacks on smart contracts [30, 31], and fake authorization caused by misbehaving MEC servers. These security issues may result in privacy leakage or system logic modifications in the data storage process on IPFS; and thus more research efforts should be made for the full realization of smart contract-based IPFS in health data sharing applications. For example, developing an incentive mechanism may be very useful to solve fake authentication issues [32]. More specifically, an incentive scheme can be designed and deployed across the MEC network, aiming to incentivize the MEC server with efficient authentication and punish the MEC server with misbehaving authentication. In this way, we can mitigate the possibility of fake authentication among MEC servers.

At present, the health data offloading scheme in our BEdgeHealth architecture has been launched commercially at Royal Victorian Eye and Ear Hospital, Melbourne city, Australia for supporting the clinical assessments of cerebellar disease [33]. This project aims to use Biokin sensors [10] associated with a Biokin mobile app to collect real-world health data from patients diagnosed with cerebellar disease and then offload to the MEC server for medical analysis. Besides, our health data sharing with blockchain has been implemented in the testbed environment at Networked Sensing and Control (NSC) lab, Deakin University on the Hyperledger blockchain platform. We set up MEC servers located in different hospitals in Melbourne city and connect with an MEC server at our university, aiming to implement a health sharing among doctors working in cerebellar disease. The implementation results achieved in this work demonstrate the practicality and feasibility of our proposed BEdgeHealth model in real-world health applications.

Comparison of security features between our proposed scheme and the existing works.

[7]   	[8]   	[11]   	[17]   	[18]   	Our scheme

Data privacy
Decentralized storage
Offloading and sharing services

§ CONCLUSIONS AND FUTURE WORK

This paper has proposed a new decentralized health architecture, called BEdgeHealth that employs MEC and blockchain for health data offloading and sharing in distributed hospital networks. We have first proposed a privacy-aware data offloading scheme where MDs can offload IoMT health data to the nearby MEC server under system constraints. Then, a new data sharing scheme is introduced by using blockchain and smart contracts to enable secure data exchange among healthcare users in different hospitals. To realize access management, we have developed an ACSC contract that enables decentralized user authentication at the network edge without requiring central authority, which would ensure authentication reliability and reduce network latency. We have implemented various real-world experiments to verify the effectiveness of the proposed BEdgeHealth architecture. The implementation results have demonstrated the significant advantages of the proposed offloading scheme over the other baseline methods in terms of reduced time latency, energy consumption, and better memory usage. Moreover, the data sharing scheme can achieve fast data retrieval with improved blockchain performance, compared to the existing works. The evaluations also prove the high system security of our design, showing the feasibility of the proposed model for healthcare applications.

Future work is in progress to extend our blockchain-MEC model to many other healthcare systems, including speech and video data management and secure real-time health monitoring systems.

[1]
D. C. Nguyen, P. N. Pathirana, M. Ding, and A. Seneviratne, “Blockchain and
edge computing for decentralized EMRs sharing in federated healthcare,” in
2020 IEEE Global Communications Conference (GLOBECOM), 2020.

[2]
M. A. Rahman, M. S. Hossain, G. Loukas, E. Hassanain, S. S. Rahman, M. F.
Alhamid, and M. Guizani, “Blockchain-based mobile edge computing framework
for secure therapy applications,” IEEE Access, vol. 6, pp.
72 469–72 478, 2018.

[3]
P. Verma and S. K. Sood, “Fog assisted-IoT enabled patient health monitoring
in smart homes,” IEEE Internet of Things Journal, vol. 5, no. 3, pp.
1789–1796, 2018.

[4]
T. McGhin, K.-K. R. Choo, C. Z. Liu, and D. He, “Blockchain in healthcare
applications: Research challenges and opportunities,” Journal of
Network and Computer Applications, 2019.

[5]
A. Yazdinejad, G. Srivastava, R. M. Parizi, A. Dehghantanha, K.-K. R. Choo, and
M. Aledhari, “Decentralized authentication of distributed patients in
hospital networks using blockchain,” IEEE Journal of Biomedical and
Health Informatics, 2020.

[6]
M. Asif-Ur-Rahman, F. Afsana, M. Mahmud, M. S. Kaiser, M. R. Ahmed,
O. Kaiwartya, and A. James-Taylor, “Toward a heterogeneous mist, fog, and
cloud-based framework for the internet of healthcare things,” IEEE
Internet of Things Journal, vol. 6, no. 3, pp. 4049–4062, 2018.

[7]
R. Saha, G. Kumar, M. K. Rai, R. Thomas, and S.-J. Lim, “Privacy ensured
e-healthcare for fog-enhanced IoT based applications,” IEEE Access,
vol. 7, pp. 44 536–44 543, 2019.

[8]
J. Liu, X. Li, L. Ye, H. Zhang, X. Du, and M. Guizani, “BPDS: A blockchain
based privacy-preserving data sharing for electronic medical records,” in
2018 IEEE Global Communications Conference (GLOBECOM), 2018, pp. 1–6.

[9]
S. Wang, Y. Zhang, and Y. Zhang, “A blockchain-based framework for data
sharing with fine-grained access control in decentralized storage systems,”
IEEE Access, vol. 6, pp. 38 437–38 450, 2018.

[10]
D. C. Nguyen, P. N. Pathirana, M. Ding, and A. Seneviratne, “Blockchain for
secure EHRs sharing of mobile cloud based e-health systems,” IEEE
Access, vol. 7, pp. 66 792–66 806, 2019.

[11]
S. Jiang, H. Wu, and L. Wang, “Patients-controlled secure and
privacy-preserving EHRs sharing scheme based on consortium blockchain,” in
2019 IEEE Global Communications Conference (GLOBECOM), 2019, pp. 1–6.

[12]
R. M. Abdelmoneem, A. Benslimane, E. Shaaban, S. Abdelhamid, and S. Ghoneim,
“A cloud-fog based architecture for IoT applications dedicated to
healthcare,” in IEEE International Conference on Communications
(ICC), 2019, pp. 1–6.

[13]
D. Giri, M. S. Obaidat, and T. Maitra, “Sechealth: An efficient fog based
sender initiated secure data transmission of healthcare sensors for e-medical
system,” in IEEE Global Communications Conference, 2017, pp. 1–6.

[14]
M. Min, X. Wan, L. Xiao, Y. Chen, M. Xia, D. Wu, and H. Dai, “Learning-based
privacy-aware offloading for healthcare IoT with energy harvesting,”
IEEE Internet of Things Journal, vol. 6, no. 3, pp. 4307–4316, 2018.

[15]
H. Guo, W. Li, M. Nejad, and C.-C. Shen, “Access control for electronic health
records with hybrid blockchain-edge architecture,” in 2019 IEEE
International Conference on Blockchain, 2019, pp. 44–51.

[16]
H. H. Elazhary and S. F. Sabbeh, “The W5 framework for computation
offloading in the internet of things,” IEEE Access, vol. 6, pp.
23 883–23 895, 2018.

[17]
X. Li, X. Huang, C. Li, R. Yu, and L. Shu, “Edgecare: leveraging edge
computing for collaborative data management in mobile healthcare systems,”
IEEE Access, vol. 7, pp. 22 011–22 025, 2019.

[18]
P. C. M. Arachchige, P. Bertok, I. Khalil, D. Liu, S. Camtepe, and
M. Atiquzzaman, “A trustworthy privacy preserving framework for machine
learning in industrial IoT systems,” IEEE Transactions on Industrial
Informatics, 2020.

[19]
R. Kumar, N. Marchang, and R. Tripathi, “Distributed off-chain storage of
patient diagnostic reports in healthcare system using IPFS and
blockchain,” in 2020 International Conference on COMmunication Systems
& NETworkS (COMSNETS), 2020, pp. 1–5.

[20]
S. Pongnumkul, C. Siripanpornchana, and S. Thajchayapong, “Performance
analysis of private blockchain platforms in varying workloads,” in
26th International Conference on Computer Communication and Networks
(ICCCN), 2017, pp. 1–6.

[21]
T. Banerjee, M. Enayati, J. M. Keller, M. Skubic, M. Popescu, and M. Rantz,
“Monitoring patients in hospital beds using unobtrusive depth sensors,” in
36th Annual International Conference of the IEEE Engineering in
Medicine and Biology Society, 2014, pp. 5904–5907.

[22]
D. C. Nguyen, P. N. Pathirana, M. Ding, and A. Seneviratne, “Privacy-preserved
task offloading in mobile blockchain with deep reinforcement learning,”
IEEE Transactions on Network and Service Management, pp. 1–1, 2020.

[23]
I. Elgendy, W. Zhang, C. Liu, and C.-H. Hsu, “An efficient and secured
framework for mobile cloud computing,” IEEE Transactions on Cloud
Computing, pp. 1–1, 2018.

[24]
B. S. Kumar, V. R. Raj, and A. Nair, “Comparative study on AES and RSA
algorithm for medical images,” in 2017 International Conference on
Communication and Signal Processing (ICCSP), 2017, pp. 0501–0504.

[25]
K. Tamilarasi and A. Jawahar, “Medical data security for healthcare
applications using hybrid lightweight encryption and swarm optimization
algorithm,” Wireless Personal Communications, pp. 1–22, 2020.

[26]
S. K. ElKady and H. M. Abdelsalam, “A modified particle swarm optimization
algorithm for solving capacitated maximal covering location problem in
healthcare systems,” in Applications of Intelligent Optimization in
Biology and Medicine, 2016, pp. 117–133.

[27]
“Hyperledger fabric,” Accessed Jun. 2020. [Online]. Available:

[28]
“Docker software,” Accessed Jun. 2020. [Online]. Available:

[29]
“Interplanetary file system (ipfs),” Accessed Jun. 2020. [Online]. Available:

[30]
S. Rouhani and R. Deters, “Security, performance, and applications of smart
contracts: A systematic survey,” IEEE Access, vol. 7, pp.
50 759–50 779, 2019.

[31]
M. Wohrer and U. Zdun, “Smart contracts: security patterns in the ethereum
ecosystem and solidity,” in 2018 International Workshop on Blockchain
Oriented Software Engineering (IWBOSE), 2018, pp. 2–8.

[32]
E. K. Wang, Z. Liang, C.-M. Chen, S. Kumari, and M. K. Khan,
“enPoRX: A Reputation Incentive Scheme for
Blockchain Consensus of IIoT,” enFuture
Generation Computer Systems, vol. 102, pp. 140–151, Jan. 2020.

[33]
D. Phan, N. Nguyen, P. N. Pathirana, M. Horne, L. Power, and D. Szmulewicz, “A
random forest approach for quantifying gait ataxia with truncal and
peripheral measurements using multiple wearable sensors,” IEEE Sensors
Journal, vol. 20, no. 2, pp. 723–734, 2019.