PaperlayerView exact revision on arXiv

Source-linked AI summary

Distributed Service Orchestration in Edge-Cloud Continuum for Digital Healthcare

Johirul Islam, Hafiz Faheem Shahid, Ijaz Ahmad, Tanesh Kumar, Ayan Mondal, Erkki Harjula

arXiv:2609.28855v1cs.DC

TL;DR

Centralized registry dependence makes new healthcare-service deployment vulnerable to network or registry outages. The paper evaluates a three-tier registry architecture in an emergency ambulance use case. The local registry has the lowest reported energy, bandwidth, and CPU overhead, while upper tiers offer scalability and continuity.

  • Problem

    New service deployment depends on network connectivity and remote registry availability, which can prevent deployment during disruptions when healthcare continuity is crucial.

    Source: B. Edge-cloud service orchestration · p. 2

  • Method

    The paper evaluates a three-tier service registry architecture using a Raspberry Pi 5 in an emergency ambulance use case, measuring deployment time, energy, bandwidth, and computational load.

    Source: §I · p. 1, §VII · p. 11

  • Results

    The local registry yields the lowest energy use, bandwidth consumption, and CPU load on Raspberry Pi 5, while MEC-based and cloud registries introduce progressively higher overheads.

    Source: §VIII · p. 12

  • Takeaways & Limitations

    A local-first strategy supported by MEC and cloud fallback offers a balanced approach for resource-constrained, latency-critical edge environments.

    Source: §VIII · p. 12

    Local registries require dedicated infrastructure and maintenance, while MEC-based registries can face resource bottlenecks when serving many nodes.

    Source: §VII · p. 11

Abstract

from arXiv · show

Today's digital healthcare services rely on various applications and functions that must be continuously accessible. Cloud computing enables global access to these services through public networks, which often also introduce increased latency, higher bandwidth consumption, and additional security risks compared to local operation. Edge computing mitigates these challenges by deploying cloud services closer to the end users and data sources, thereby improving resilience to network disruptions and reducing latency, bandwidth usage, and exposure to security threats. However, service deployment typically relies on the availability of centralized registry servers. Consequently, if the network connection or the registry server itself becomes unavailable, service deployment at the target edge node may fail. To address this, we propose a three-tier registry architecture to enhance deployment reliability and service availability, considering DockerHub as a remote public registry, an MEC-based off-premises registry as a remote private registry, and a LAN-based on-premises registry as a local private registry. The performance and efficiency are analyzed through measurements related to the estimated deployment time, inflicted network and computational load, and energy consumption, while the required nanoservices are deployed from different tiers. The experimental results indicate that alongside the improved tolerance to network disruptions, the local private and remote private registries also outperform the remote public registry in the deployment performance. The findings highlight the effectiveness of proximity-aware service distribution in improving the resilience, performance and efficiency of service deployment.

I. INTRODUCTION

Centralized service registries leave critical-service deployment vulnerable to network or registry outages. The paper proposes a three-tier registry model and evaluates its performance and efficiency in a medical first-response use case.

A. Evolution of edge-cloud computing

I. INTRODUCTION

  • Centralized registry dependence can prevent deployment of critical healthcare applications during network or registry outages, even when those services are urgently needed.Source: §I · p. 1
  • The proposed three-tier registry model is intended to support critical-service deployment even when public registry connections are unavailable.Source: §I · pp. 1–2
  • The study evaluates deployment performance and efficiency in an emergency first-response care pathway and examines local-node hardware, network bandwidth, energy use, and deployment performance.Source: §I · pp. 1–2

A. Evolution of edge-cloud computing

  • Cloud computing supports scalable healthcare data storage and analysis, but depends on reliable internet and can increase latency, bandwidth use, and security risks relative to local operation.Source: A. Evolution of edge-cloud computing · p. 2

B. Edge-cloud service orchestration

Existing orchestration can keep deployed services operating through local resources, but new remote-registry-dependent deployments remain vulnerable to connectivity interruptions. The paper presents a functional prototype and an emergency-care pathway in which nanoservices are deployed as patient monitoring moves from the scene to the hospital.

B. Edge-cloud service orchestration

  • Nanoservices extend edge-cloud computing to local devices, supporting local data processing and critical-function operation during local network problems.Source: B. Edge-cloud service orchestration · p. 2
  • Network disruption can leave already-deployed services operating while preventing new remote-registry-dependent services from being deployed, a concern where healthcare service continuity is crucial.Source: B. Edge-cloud service orchestration · p. 2
  • Prior decentralized deployment works focus mainly on architecture and proof-of-concept implementations; this paper builds a functional prototype and evaluates it against centralized deployment.Source: B. Edge-cloud service orchestration · p. 3

III. USE CASE: EMERGENCY RESPONSE SCENARIO

  • The emergency pathway follows a seriously ill patient from on-site first aid through ambulance transport to hospital handover, with monitoring and treatment functions implemented as nanoservices.Source: §III · p. 3
  • On site, the ePCR device hosts patient identification, and monitoring nanoservices for pulse rate, oxygen level, and ECG are deployed after resources are discovered.Source: §III · pp. 3–4
  • During ambulance transport, EEG monitoring and a visualizer nanoservice are deployed on suitable ambulance computing devices and connected to hospital systems.Source: §III · p. 4
  • At hospital arrival, monitoring tasks migrate from ambulance and paramedic devices to newly discovered emergency-unit devices to maintain patient monitoring.Source: §III · p. 4

A. Proposed System Model

The system places registries at local, mobile-edge, and public-cloud tiers, supporting nanoservice discovery and deployment as a patient moves through emergency care. Its example workflow uses local and remote registries according to service availability and care-pathway stage.

1) Framework setup:

  • R1 is the ambulance-mounted local private registry, R2 the mobile-network edge remote private registry, and R3 the cloud-based remote public registry.R1 provides fast access for on-site workloads, R2 regional caching and distribution, and R3 a central image repository.Source: 1) Framework setup · p. 4
  • The delivery workflow tests nanoservice code, reviews it, builds images for target computing systems, and uploads them to registries after tests pass.Developers produce service code, a test team checks it, and an administrator reviews it and provides feedback as needed.Source: 1) Framework setup · p. 4

2) Functional setup:

  • The care pathway begins with the BLE Scanner loaded from R1; RabbitMQ, unavailable locally and at R1/R2, is fetched from R3 and cached at R1/R2.The Visualizer is separately requested from R1 when unavailable on the Nvidia NX.Source: 2) Functional setup · p. 5
  • During ambulance brain monitoring, the EEG nanoservice is deployed from R2 and cached into R1.Source: 2) Functional setup · p. 6
  • At hospital arrival, recently used monitoring services are deployed from R1, while the database nanoservice is obtained from R3 after R1 and R2 are tried.The system then transfers relevant sensor data to the hospital host.Source: 2) Functional setup · p. 6

B. Prototype Implementation

The prototype assigns different image sources to local, regional, and public tiers, with containerized nanoservices deployed using Docker on the worker nodes.

  • Nanoservices for RPi 5 and Nvidia NX are primarily deployed from local R1, EEG mainly from remote private R2, and other public images from Docker Hub R3.R1 and R2 cache upper-tier services for a predefined time to serve frequently deployed services faster.Source: B. Prototype Implementation · p. 6
  • R1 runs on an 8 GB RAM, 32 GB storage Raspberry Pi 5, while R2 runs on an 8 GB RAM, 64 GB storage University of Oulu VM.The public DockerHub host hardware depends on its data center.Source: B. Prototype Implementation · p. 6
  • Docker containers and Docker Engine 27.3.1 provide the nanoservice runtime, while registry:2 builds R1/R2 and GitLab tools support CI/CD pipelines.Portainer is an optional registry UI.Source: B. Prototype Implementation · p. 6

V. EVALUATION SETUP

The evaluation downloads nanoservice containers to an RPi 5 from three registries and measures deployment performance, resource use, and power-related quantities.

V. EVALUATION SETUP

  • The experiment downloads and deploys nanoservice containers to an RPi 5 from R1, R2, and R3 over Wi-Fi or 5G.The setup uses a Cudy Wi-Fi 6 router and a Quectel 5G modem; KPIs are monitored on the RPi 5 and Netio PowerBox.Source: §V · p. 7

A. KPI definitions:

  • Deployment performance is measured using registry round-trip time, hop count, and total nanoservice download-and-deployment time in cached and non-cached scenarios.Cached and non-cached indicate whether the registry-server path is already known to the RPi 5.Source: A. KPI definitions · p. 7
  • Computational load is tracked as RPi 5 CPU percentage and average image-storage utilization in megabytes during deployment.These measurements use Linux resource-monitoring tools.Source: A. KPI definitions · p. 7
  • Network traffic is measured at the RPi 5 in MB/s, while Netio acquires voltage, current, and true power factor during image downloads.Source: A. KPI definitions · p. 7
  • The monitoring script uses five minutes of idle time, pauses 20 seconds before each pull and 10 seconds afterward, then deletes the downloaded image.The image deletion ensures subsequent iterations download it again rather than use local storage.Source: A. KPI definitions · p. 7

B. KPI data collection:

A bash script records deployment KPIs during repeated image pulls, while an MQTT-based pipeline collects and visualizes measurements and supports energy calculation.

B. KPI data collection:

  • The bash script monitors a five-minute idle baseline, pauses before each pull, deletes the image after each iteration, and stops monitoring when the run ends.Its inputs are the image name and iteration count; the pauses are 20 seconds before pulling and 10 seconds before deletion.Source: B. KPI data collection · p. 7

C. KPI visualization:

  • RPi 5 Linux tools and Netio supply KPI readings, which MQTT publishes to a broker and the Ubuntu VM stores in InfluxDB for Grafana dashboards.Netio voltage, current, and power-factor readings are sent to the VM over Wi-Fi.Source: C. KPI visualization · pp. 7–8
  • Deployment energy is calculated from a nanoservice's mean power and mean download time, while instantaneous power uses Netio voltage, current, and power factor.Source: C. KPI visualization · p. 8

VI. RESULTS AND ANALYSIS

Deployment performance was measured across three registries, with discovery latency and nanoservice download times varying by registry and routing-path cache state. Computational efficiency was assessed through computational load and storage consumption.

A. Performance

  • Registry discovery required 1 hop and 46.9 ms at R1, 5-8 hops and 186.24 ms at R2, and 28-29 hops and 1435.18 ms at R3.R1's local deployment remained available when the external network was not functioning; R3 was slightly faster than R2, attributed to its CDN and higher-capacity physical configurations.Source: A. Performance · p. 8
  • For SpO2, cached/non-cached download times were 12.00/12.05 s from R1, 14.70/15.89 s from R2, and 13.64/15.08 s from R3.Other nanoservices showed similar trends in Fig. 7.Source: A. Performance · p. 8, Figure 7 · p. 8

B. Computational efficiency

  • Computational efficiency was evaluated through inflicted computational load and storage consumption.The following subsections report these measurements.Source: B. Computational efficiency · p. 8

1) Computational load:

The evaluation measured RPi 5 CPU load during downloads and quantified storage consumed by Docker components, the CI/CD pipeline, and nanoservices.

1) Computational load:

  • CPU baseline was around 10%; SpO2 downloads raised mean RPi 5 load to 20%, 22.5%, and 25% for R1, R2, and R3.These correspond to increases of 10%, 12.5%, and 15%, respectively.Source: Figure 8 · p. 8, 1) Computational load · p. 9
  • During nanoservice downloads, CPU load at RPi 5 increased for Visualizer by 5/17.5/17.5%, RabbitMQ by 5/10/7.5%, ECG by 2.5/5/12.5%, and DB by 17.5/12.5/20% for R1/R2/R3, respectively.Source: 1) Computational load · p. 9

2) Storage consumption:

  • RPi 5 Swarm workers/managers consumed 176.9/217 MB, versus 232/273.5 MB for Ubuntu VM-based workers/managers.The listed Docker Engine package footprints include required components and optional buildx and compose plugins.Source: 2) Storage consumption · p. 9
  • GitLab and GitLab Runner used 3.45 GB and 798 MB; registry images used 25 MB on RPi 5 and 25.4 MB on the Ubuntu VM.Portainer's registry UI image consumed 302 MB on the Ubuntu VM.Source: 2) Storage consumption · p. 9
  • Compressed registry/decompressed RPi 5 footprints were SpO2 128.56/365 MB, Visualization 100.46/399 MB, RabbitMQ 58.21/134 MB, ECG 101.45/215 MB, and DB 155.24/416 MB.Source: 2) Storage consumption · p. 9

C. Network efficiency

Network load and download rates were compared across local R1 and remote R2/R3 registries, alongside deployment energy measurements. Results show registry-specific bandwidth, stability, and energy trade-offs.

C. Network efficiency

  • R1 downloads used the RPi 5 built-in WiFi, while remote R2 and R3 downloads used a Quectel modem over 5G.The network-load comparison covered the SpO2 nanoservice.Source: C. Network efficiency · p. 9
  • SpO2 download rates from R1/R2/R3 were 12/14.7/13.64 MB/s; Visualizer rates were 11.14/12.10/8.91 MB/s; RabbitMQ rates were 9.04/10.46/9.07 MB/s.ECG rates were 11.37/12.15/10.55 MB/s, and DB rates were 12.48/16.54/13.63 MB/s.Source: C. Network efficiency · p. 9
  • R1 used the least bandwidth in most cases; R2 inflicted the highest network load, and its path was more stable than R3 by standard deviation.For Visualizer and ECG, R1 used more bandwidth than R3, but R1 had lower transfer standard deviations; R3 performed better than R2, while R2 was more stable.Source: C. Network efficiency · p. 10, Figure 9 · p. 10

D. Energy-efficiency

  • No-traffic baseline power was 4.61 W for RPi 5 and 0.80 W for the Quectel modem; R1 energy excludes modem power.A download event's total energy is the sum of RPi 5 and modem energy, calculated from mean power and mean download time.Source: D. Energy-efficiency · p. 10
  • SpO2 download energy was 69.53 J from R1, 76.96 J from R2, and 107.24 J from R3; the R2/R3 increases versus R1 were 10.69%/54.24%.R2 and R3 also increased energy versus R1 for Visualizer, RabbitMQ, and ECG; DB used slightly less energy from R2 than R1, while R3 increased it by 108.92%.Source: D. Energy-efficiency · p. 10, Figure 10 · p. 10

VII. DISCUSSION AND FUTURE WORK

Registry proximity shaped deployment efficiency: local registries reduced device-side energy, bandwidth, and processing overhead, while upper tiers offered alternatives with their own performance trade-offs. The study also identifies limits in deployment scope, registry infrastructure, device-specific evaluation, and trust modeling.

VII. DISCUSSION AND FUTURE WORK

  • Local-registry downloads were quick and required no external network, while MEC-based downloads took slightly longer than remote centralized downloads.Deployment performance depends on both registry discovery and nanoservice download time.Source: §VII · p. 11
  • Local registry deployment used the least energy and bandwidth and imposed less computational load on the RPi 5 than the remote public registry.Computational load generally increased with registry distance, although the remote public registry performed better than the local public registry because of higher backend resources.Source: §VII · p. 11
  • Local registries require dedicated infrastructure and maintenance, and MEC registries may bottleneck when serving many nodes, degrading performance and increasing end-device energy and CPU overhead.Source: §VII · p. 11
  • The evaluation covers service deployment, not the full lifecycle from nanoservice development through deployment on hospital devices or criteria for selecting locally available images.Source: §VII · p. 11
  • Device variation in computational performance, capacity, energy efficiency, and status calls for more use-case-specific performance and efficiency studies.Source: §VII · p. 11
  • The authors identify a need for a layered trust model to balance performance and efficiency across registries with different security exposure.They describe local private registries as generally more secure due to processing closer to the source, while public registries require heavier security solutions.Source: §VII · p. 11

VIII. CONCLUSION

In an emergency ambulance context, the paper assesses a three-tier registry architecture for nanoservice distribution to edge devices. It concludes that a local-first strategy with MEC and cloud fallback balances local efficiency with scalability, resilience, and continuity.

VIII. CONCLUSION

  • The local registry yielded the lowest energy use, bandwidth consumption, and CPU load on the Raspberry Pi 5, while MEC-based and cloud registries introduced progressively higher overheads.The paper attributes the overhead increases to communication distance and processing requirements.Source: §VIII · p. 12
  • MEC-based and cloud registries provide scalability, resilience, and operational continuity that complement the local tier’s performance advantages.Source: §VIII · p. 12
  • For resource-constrained, latency-critical edge environments, the authors conclude that local-first deployment with MEC and cloud fallback offers a balanced, dependable approach.Source: §VIII · p. 12
Loading 2609.28855v1…