PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Dinh C. Nguyen, Pubudu N. Pathirana, Ming Ding, Aruna Seneviratne

arXiv:2109.14295v1eess.SP

TL;DR

Existing healthcare offloading and sharing schemes leave challenges in QoS, privacy, and decentralized access and retrieval. BEdgeHealth combines MEC, blockchain, IPFS, and smart contracts for offloading and sharing in distributed hospitals. The authors report improved offloading and retrieval performance alongside security evaluations.

  • Problem

    Healthcare schemes still face challenges in QoS, privacy, and security, while decentralized sharing and retrieval in MEC-supported hospital networks remain insufficiently addressed.

    Source: §I · p. 1

  • Method

    BEdgeHealth combines privacy-aware mobile-to-MEC offloading with blockchain and IPFS sharing, using smart contracts for decentralized access authentication.

    Source: §I · p. 1, C. Health Data Storage · p. 6, B. Health Data Retrieval with MEC and… · p. 8

  • Results

    The authors report improved offloading time, energy, and memory outcomes, faster data retrieval, improved blockchain performance, and high system security versus existing works.

    Source: §VIII · pp. 13–14

  • Takeaways & Limitations

    The evaluations support the feasibility of the proposed architecture for healthcare applications.

    Source: §VIII · p. 14

    Future work is planned to extend the model to speech and video data management and secure real-time health monitoring.

    Source: §VIII · p. 14

Abstract

from arXiv · show

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.

I. INTRODUCTION

The introduction motivates a comprehensive healthcare architecture that combines MEC efficiency with blockchain-based security, addressing gaps in privacy-aware offloading and decentralized data sharing. BEdgeHealth integrates offloading and sharing schemes for distributed hospitals.

I. INTRODUCTION

  • MEC supports low-latency computation near mobile devices and sharing of offloaded health data among healthcare users.The introduction gives doctors’ diagnosis and treatment, and patients’ medication advice, as examples of edge use.Source: §I · p. 1
  • The introduction identifies joint QoS and privacy-aware offloading, decentralized sharing, and lower-latency retrieval as open needs.It also notes that MEC-supported blockchain sharing in cooperative hospital networks has not been adequately investigated.Source: §I · p. 1
  • The proposed smart contract authenticates and traces sharing events without an external authority, while contract-stored hashes replace IPFS’s global DHT lookup.The paper presents this design as a way to improve data lookup and retrieval rates.Source: §I · pp. 1–2

B. Organization

  • The paper situates its contribution among work on offloading and sharing, then outlines the architecture, schemes, evaluation, security analysis, and conclusion.The stated organization moves from related work through the system model and designs to experiments and security analysis.Source: A. Motivations and Contributions · p. 2, B. Organization · p. 2

A. Motivations and Contributions

  • BEdgeHealth combines privacy-aware health-data offloading with blockchain-enabled sharing for cooperative hospital networks.Its stated contributions include edge access control and data management without third parties, plus real-world evaluation.Source: A. Motivations and Contributions · p. 2

II. RELATED WORKS

  • Existing offloading studies do not jointly address latency, energy, memory use, and privacy, while sharing proposals retain cloud or IPFS lookup drawbacks.Central-cloud storage raises single-point failure, trust, and communication-overhead concerns; classic IPFS’s global DHT can increase retrieval latency.Source: A. Health Data Offloading · p. 2, B. Health Data Sharing · pp. 2–3

III. SYSTEM MODEL

The system links cooperative hospitals through MEC servers and blockchain, with IPFS holding health records and smart contracts managing access. Its offloading model lets each mobile device choose local execution or edge computation using task-profile information.

III. SYSTEM MODEL

  • The paper frames data offloading and sharing as the two designs within its healthcare architecture.This section introduces the architecture and blockchain design before presenting those schemes.Source: §III · p. 3, B. Blockchain Design · p. 4

A. Proposed Healthcare Architecture with MEC and Blockchain

  • Cooperative hospitals connect through MEC servers that execute offloaded tasks and communicate with other hospitals for data sharing.Mobile devices collect patient data, while healthcare users at any hospital may seek access through the sharing scheme.Source: A. Proposed Healthcare Architecture… · p. 3
  • Because MEC servers may be curious or misbehave, raw EHRs are stored in IPFS and record hashes in smart contracts for traceable retrieval.Authenticated users may retrieve IPFS data; the design aims to detect and prevent malicious access.Source: A. Proposed Healthcare Architecture… · pp. 3–4

B. Blockchain Design

  • The architecture uses permissioned Hyperledger Fabric with PBFT and global and local blockchains linking MEC servers, hospitals, and mobile users.The global chain supports inter-hospital communication; the local chain processes user requests, and blockchain is used for sharing rather than the assumed private offloading network.Source: B. Blockchain Design · p. 4

A. Offloading Model

  • Each mobile device’s task profile records task, energy, processing-time, and memory information for a decision maker that minimizes weighted offloading costs.The decision maker uses an integer linear programming model to choose between local processing and MEC offloading.Source: A. Offloading Model · p. 4, §1 · p. 5

B. Offloading Formulation

The offloading formulation models local execution and MEC offloading against latency, energy, memory, privacy, and system constraints. Offloaded tasks are encrypted on the mobile device, then transmitted and executed at the edge.

B. Offloading Formulation

  • The formulation addresses gaps in joint consideration of processing time, energy, memory use, and privacy, with local and offloaded execution as alternatives.The stated objective is to account for these factors in health-data offloading.Source: B. Offloading Formulation · p. 5

1) Local Execution:

  • With local execution, the mobile device uses its own resources to process the healthcare task.The local-execution choice is represented by x_n = 0.Source: 1) Local Execution · p. 5
  • Local execution accounts for device battery consumption and memory usage, measured with mobile-device tools.The passage identifies these as local-mode resource costs.Source: 1) Local Execution · p. 5

2) Offloading to the MEC Server:

  • Offloading encrypts healthcare data on the mobile device with AES before transmission to the MEC server.The paper selects AES, citing its lower energy consumption and latency.Source: 2) Offloading to the MEC Server · p. 5
  • Offloaded task completion time includes mobile encryption, transmission to the MEC server, and execution at the edge.The model uses mobile and edge CPU utilization and transmission rate to characterize these components.Source: 2) Offloading to the MEC Server · p. 5
  • Offloading energy is characterized by encryption and transmission energy, with mobile transmission power included in the model.Encryption energy is measured on the mobile device; transmission energy follows the cited model.Source: 2) Offloading to the MEC Server · p. 5
  • Offloading also incurs encryption-related memory use, and the formulation represents total time, energy, and memory costs.These quantities feed the model’s resource-cost accounting.Source: 2) Offloading to the MEC Server · p. 5

3) Offloading Problem Formulation:

The formulation jointly minimizes latency, energy consumption, and memory use under system constraints. It uses binary offloading decisions and a PSO algorithm implemented on Android phones.

3) Offloading Problem Formulation:

  • The objective jointly minimizes time latency, energy consumption, and memory usage under system constraints.The weights α_t, α_e, and α_m represent the respective costs.Source: 3) Offloading Problem Formulation · p. 5
  • Each task is either executed locally or offloaded, while execution time is bounded and transmission reliability is protected by a minimum-rate constraint.The rate constraint keeps transmission time short enough for task completion before the deadline.Source: 3) Offloading Problem Formulation · pp. 5–6
  • The offloading optimization uses a Java PSO model on Android phones, described as low-cost and simple to implement compared with genetic algorithms [25],.The formulation also constrains mobile memory and transmission power and requires positive MEC resources within the computation budget.Source: 3) Offloading Problem Formulation · p. 6

C. Health Data Storage

Health records and analyzed results are stored through IPFS nodes on the MEC network, with hashes recorded in smart contracts and IPFS replicas synchronized across hospitals. The sharing scheme uses edge-based contract authentication and replicated hashes for retrieval and traceability.

C. Health Data Storage

  • The storage workflow handles patients' raw health data and analyzed results at an MEC server, then stores the resulting records in IPFS.The described example has one MEC server and a network of mobile devices and patients at a representative hospital.Source: C. Health Data Storage · p. 6
  • The data are encrypted before placement in the IPFS node, which returns a cryptographic content hash.The stored hash is retained in the MEC server's smart contract for lookup instead of using the classic DHT.Source: C. Health Data Storage · p. 6
  • IPFS records are synchronized between hospitals over a peer-to-peer network, while the MEC server broadcasts a blockchain transaction containing the record hash and patient identifier.Other MEC servers extract and store the offloading information in the ACSC contract database.Source: C. Health Data Storage · p. 6

V. HEALTH DATA SHARING

  • At the network edge, smart-contract access control authenticates sharing without a central authority, while replicated record hashes support faster retrieval and traceability.The scheme is presented as reducing authentication latency and increasing sharing reliability.Source: §V · p. 6

A. User Authentication with MEC and Smart Contract

Each hospital's MEC server initializes keys, and users register through the local blockchain with their identifying information recorded in a contract database. For retrieval, the MEC server validates an encrypted request against contract mappings and returns an authentication certificate when validation succeeds.

A. User Authentication with MEC and Smart Contract

2) Registration Phase:

  • During registration, the MEC server decodes the user's transaction, checks the user's information, and stores the public key and unique address in the contract database.The registration transaction hash is published on the local hospital blockchain, and the MEC server broadcasts its public key to the user.Source: 2) Registration Phase · pp. 6–7

3) User Authentication Phase:

  • A user submits an encrypted retrieval request containing the target patient and hospital identifiers, which the MEC server decrypts and checks against contract mappings.The request includes a patient identity and hospital address, and invalid mapping checks trigger a penalty for access prevention.Source: 3) User Authentication Phase · p. 7
  • After successful validation, the MEC server signs the request and sends the user a certificate through the local blockchain as proof of authentication.The server checks the received user identification information before issuing the certificate.Source: 3) User Authentication Phase · p. 7

B. Health Data Retrieval with MEC and Blockchain

After authentication, MEC servers retrieve records from IPFS using patient and hospital information. Same-hospital requests are resolved locally; cross-hospital requests are directed to the MEC server holding the record rather than broadcast to all servers.

B. Health Data Retrieval with MEC and Blockchain

  • For same-hospital retrieval, the MEC server verifies the requested patient through the ACSC contract, obtains the record hash, fetches and decrypts the IPFS record, then returns it securely.The contract mapping verifies the requested patient information before retrieval.Source: B. Health Data Retrieval with MEC and… · p. 7
  • For cross-hospital retrieval, the ACSC contract identifies the destination MEC server, which receives a targeted request instead of a network-wide broadcast.The paper says this strategy saves lookup time and bandwidth and can reduce global blockchain traffic congestion.Source: B. Health Data Retrieval with MEC and… · p. 8
  • The destination MEC server retrieves the record from IPFS by its hash, returns it through the requesting MEC server, and broadcasts an access transaction to the blockchain.MEC servers synchronize user access events; the described retrieval flow covers both same- and cross-hospital cases.Source: B. Health Data Retrieval with MEC and… · p. 8

VI. EXPERIMENTAL RESULTS AND EVALUATIONS

The section introduces experiments and implementation evaluations of BEdgeHealth.

VI. EXPERIMENTAL RESULTS AND EVALUATIONS

  • The section presents experiments and implementation evaluations of the proposed architecture.No further experimental details are stated in this passage.Source: §VI · p. 8

A. Experiment Settings

The testbed models three hospitals with MEC servers, mobile devices, and sensor-collected motion data, and deploys blockchain and IPFS components for evaluation.

A. Experiment Settings

  • Three computers served as MEC servers representing hospitals, each connected to mobile devices through a Cisco access point.The mobile devices were Sony Android phones with Snapdragon 845 processors, 2GB memory, and 2870mAh batteries.Source: A. Experiment Settings · p. 8
  • Biokin sensors collected human motion data in 100 KB–5 MB files for analysis on phones and MEC servers.The data included acceleration and gyroscope time series, and the analysis algorithm estimated movement disorders.Source: A. Experiment Settings · p. 8
  • Firebase Performance Monitoring measured processing time, battery consumption, and memory usage for mobile evaluations.The offloading optimization application was implemented in Android Studio 3.5.Source: A. Experiment Settings · p. 9
  • Hyperledger Fabric 1.3 supported global and local blockchains, with PBFT consensus at MEC servers and an IPFS node at each of the three servers.The smart contract handled user authentication and data retrieval.Source: A. Experiment Settings · p. 9

B. Evaluation of Data Offloading Performance

Across the tested offloading tradeoffs, the edge scheme had the lowest cost among the edge, cloud, and local baselines; data-sharing evaluations also reported lower authentication and retrieval latency for the decentralized design.

B. Evaluation of Data Offloading Performance

  • For 1000 KB files, edge offloading saved 21.3% energy versus local, while processing time fell by up to 31% versus local and 15% versus cloud.The energy comparison also reports an 11% saving versus local and 5% versus cloud for 200 KB files; edge and cloud used 5% and 9% less memory than local at 200 KB and 1000 KB, respectively.Source: B. Evaluation of Data Offloading… · p. 9, Figure 4 · p. 10
  • At 1000 KB, offloading cost was 29.5 for edge, 34.2 for cloud, and 38.3 for local under the energy-weighted setting.The authors report the edge scheme had the lowest cost in both tested tradeoff settings.Source: B. Evaluation of Data Offloading… · p. 10, Figure 5 · p. 10

1) Authentication Cost:

  • The decentralized smart-contract scheme had lower authentication latency than the centralized scheme as the number of healthcare users varied.The authors attribute the difference to edge authentication without a remote authority; the authentication-cost evaluation also reports small computation costs and acceptable PBFT latency for time-sensitive use.Source: 1) Authentication Cost · pp. 10–11, Figure 6 · p. 10

2) Data Retrieval Latency:

  • The proposed design achieved minimal retrieval latency against centralized-MEC and classic-IPFS baselines as requests increased, and lower latency than cloud and central-authority baselines.The authors relate the comparisons to avoiding centralized-MEC queuing, global-DHT lookup overhead, remote-cloud communication, and authority-verification communication.Source: 2) Data Retrieval Latency · p. 11, Figure 7 · p. 11

3) Request Acceptance Probability:

BEdgeHealth reports higher deadline-based request acceptance than baselines and lower Hyperledger transaction latency than Ethereum, then analyzes its security properties under internal and external threat assumptions.

3) Request Acceptance Probability:

  • Request acceptance remains higher than baselines as request volume rises, although longer queues reduce the probability of returning data before the deadline.The authors attribute the result to processing-time savings from optimized edge computing and decentralized smart-contract design.Source: 3) Request Acceptance Probability · p. 11, Figure 8 · p. 12

4) Blockchain Performance:

  • Hyperledger Fabric exhibits much lower transaction latency than Ethereum as transaction counts vary, supporting its suitability for time-sensitive healthcare applications.The experiment ran the ACSC contract on three computers and measured average local-blockchain latency while smartphones sent transactions continuously.Source: Figure 9 · p. 12, 4) Blockchain Performance · p. 12

1) Attack Model:

  • The attack model treats MEC servers and healthcare users as semi-trusted, MDs as fully trusted in private offloading, and considers internal and external attacks.Semi-trusted servers may be honest but curious; external attackers may target offloaded information or communications.Source: 1) Attack Model · p. 12

2) Security Analysis:

  • The authors identify privacy and authentication as security features: data and requests are encrypted, while decentralized contract checks govern data retrieval without MEC-server control of policies.The design also avoids third-party centralized IPFS storage, which the authors associate with possible data leakage in prior works,,.Source: 2) Security Analysis · p. 12
  • Blockchain records access events and data hashes for traceability, while key-based encryption and digital signatures protect communication confidentiality.The authors compare security features with existing works and report advantages for BEdgeHealth in Table II.Source: 2) Security Analysis · pp. 12–13

B. Discussions

The authors report real-world implementation and evaluation results for BEdgeHealth, while noting smart-contract/IPFS security risks and proposing further development for healthcare sharing and other data-management settings.

B. Discussions

  • Smart-contract IPFS integration may introduce timestamp dependence, mishandled exceptions, reentrancy, or fake authorization risks that could affect privacy or storage logic.The authors call for more research on full realization of smart-contract-based IPFS in health-data sharing.Source: B. Discussions · p. 13
  • An incentive mechanism across the MEC network is proposed to encourage reliable authentication and punish misbehaving servers, mitigating fake authentication.The authors frame this as an example of further work for smart-contract-based IPFS health-data sharing.Source: B. Discussions · p. 13
  • The offloading scheme is commercially launched at Royal Victorian Eye and Ear Hospital, while blockchain sharing is implemented in a Deakin University testbed across Melbourne hospitals.The hospital deployment supports clinical assessments of cerebellar disease; the testbed targets sharing among doctors working on that disease.Source: B. Discussions · p. 13

VIII. CONCLUSIONS AND FUTURE WORK

  • Evaluations report reduced time latency and energy consumption, better memory usage, fast data retrieval, improved blockchain performance, and high system security versus existing methods.The authors conclude that these results show feasibility for healthcare applications.Source: §VIII · pp. 13–14
  • Future work extends the blockchain-MEC model to other healthcare systems, including speech and video data management and secure real-time health monitoring.Source: §VIII · p. 14
Loading 2109.14295v1…