IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
1
Distributed Service Orchestration in Edge-Cloud Continuum for Digital Healthcare
arXiv:2609.28855v1 [cs.DC] 23 Sep 2026
Johirul Islam , Hafiz Faheem Shahid , Ijaz Ahmad , Tanesh Kumar , Ayan Mondal , and Erkki Harjula
Abstract—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. Index Terms—IoT, Edge-Cloud Continuum, Microservice Orchestration, Healthcare Applications.
I. I NTRODUCTION The ever-growing demand for real-time processing and analysis capabilities in healthcare applications necessitates robust and latency-sensitive computing infrastructures [1]. Cloud-based computing architecture was for long the reference architecture for most IoT applications. However, the original centralized model suffers from high latency and vulnerability to network disruptions. Edge–cloud architecture was introduced as a solution to address these challenges by integrating edge computing Manuscript received April 19, 2026; revised August 16, 2026.
resources, located close to end users or sensor devices, with cloud infrastructure. [2]. To further improve the system reliability, privacy protection, and resource efficiency, the authors in [3]–[5] proposed a three-tier edgecloud architecture combined with a distributed nanoservice architecture, which together made it possible to deploy service parts to constrained-capacity local devices. While this three-tier architecture successfully reduces the reliance of the already deployed services to the constantly available and high-performance underlying network architecture, one critical challenge remains: in most of the current systems, the service deployment relies on a central service registry [6], [7]. This model compromises the reliability of the service deployment during, e.g., network or registry server outages, potentially hindering the deployment of critical healthcare or other applications when those are critically needed. In this paper, we address this critical limitation by proposing a three-tier service registry model to ensure the system’s ability to deploy critical services in all circumstances, including when the connection to public service registries is down. In this paper, we exemplify such critical service with a medical first-response use case, where we implement a digital care pathway for an emergency patient requiring first aid at a scene, followed by monitoring the patient’s vitals from the site during ambulance transportation to the hospital. This care pathway service is implemented based on patient monitoring and care-related nanoservices that are deployed or undeployed based on the need during the care pathway. These aspects include the hardware requirements for local computing nodes, bandwidth requirements for the local networks, energy consumption on the local devices, and overall performance of the deployment in different deployment scenarios. Based on the gained knowledge, we are able to outline the best practices for, e.g., selecting which local nodes could be utilized as local edge nodes or which nanoservices should be maintained in the limited-capacity local registry, prioritizing the most critical, most often-used, and least resource-consuming services. The key contributions of this paper are:
0000–0000/00$00.00 © 2026 IEEE
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
The concept for robust service orchestration to enable the seamless deployment of services in a medical use case. • Three-tier service registry architecture to ensure the deployment of critical services during remote service registry unavailability. • Evaluating the performance and efficiency of the proposed concept and analyzing the impact of the results in the selected use case scenario and beyond. The rest of this paper is organized as follows: Section II discusses the background and related works. Section III and Section IV present the selected use case and its system model, respectively. Section IV-B and section V discusses the implementation setup and evaluation results of the system model. Discussion and the future are presented in Section VII. Finally, Section VIII concludes the paper. •
II. BACKGROUND AND RELATED WORKS A. Evolution of edge-cloud computing Cloud computing is a widely used concept for delivering applications, software platforms and computational resources over the Internet, instead of deploying those on dedicated servers or personal devices [8]–[10]. This approach offers scalability, flexibility, and cost-efficiency as services can be scaled up or down based on user demand without the need for infrastructure investments and maintenance. In healthcare domain, medical equipment generate vast amounts of health-related data, ranging from patient vital signs to diagnostic imaging. Cloud computing provides a centralized platform for storing, processing, and analyzing these data, facilitating realtime monitoring and data-driven decision-making [11], [12]. Additionally, cloud computing in medical IoT enables the implementation of sophisticated analytics and machine learning algorithms. Cloud computing is, however, highly dependent on a reliable internet connection, and it introduces increased latency, higher bandwidth consumption, and also additional security risks compared to local operation. Edge computing is a distributed computing paradigm that involves processing data closer to the users and data sources, rather than relying solely on centralized cloud servers [13], [14]. It reduces latency and enhances real-time processing capabilities, while improving robustness against network connectivity problems and security threats [13], [15]. Shahid et al. [5] has conducted a comprehensive comparative analysis of five architectural frameworks for IoT service orchestration in the edge–cloud continuum of 6G networks, namely traditional IoT–cloud, edge computing, fog computing, Multi-access Edge Computing (MEC), and local edge computing. The edge-cloud approach is particularly relevant in healthcare, where reliable, efficient and timely
2
processing of data from medical devices is crucial. Edge computing alleviates the load on the network by processing data through the resources in the user’s proximity and sending only relevant data to the cloud [16], [17]. This reduces not only the network congestion but also the costs associated with data transmission and storage, and helps limit unnecessary propagation of sensitive patient data [14], [18], [19]. B. Edge-cloud service orchestration Microservice architecture is a widely used decentralized approach that structures online applications as a collection of small, independent services. These services operate as autonomous entities and communicate with one another through well-defined APIs. Many of today’s IoT computing nodes include sufficient processing power to process data and execute different actions locally. There is a clear need for mechanisms enabling harnessing this potential to practical operation. Harjula et al. have proposed a nanoservice approach [3], [20], defining methods to deploy ultra-lightweight virtualized edge-cloud microservices on local computing devices, including IoT sensors and actuators. Docker swarm or Kubernetes are then used to deploy and orchestrate the containers across the cluster nodes. Nanoservices extend the edge-cloud computing architecture to the local tier, enabling, e.g., local data pre-processing to save network bandwidth or avoid propagating sensitive data outside a room, floor, or building, thereby also improving privacy. Locally deployed functionalities also help addressing local network problems by enabling fully local operation of critical functions, thereby improving service resilience. To support this, Shahid et. al. [21] have introduced a concept for intelligent resource-aware orchestration of nanoservices as a part of a comprehensive three-tier edge-cloud architecture. In [22], they proposed an AIdriven and ML-based heuristic algorithmic approach for the orchestration of IoT services by performing task scheduling, classification of each type of service, load balancing and optimizing the computing resource in the distributed edge-cloud continuum. Although the concepts above enable the resilient operation of already deployed microservices and nanoservices, the current deployment methodologies remain heavily dependent on stable and continuously available network connectivity, as these services are typically provisioned from remote service registries. This poses a major obstacle: if there are disruptions in the network, despite the reliable operation of already deployed services, new services cannot be deployed until the network operation has been restored. This dependence on network stability highlights a serious weakness in the current solutions, especially when it comes to healthcare, where
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
service continuity is crucial [23]. However, the next investigations should prioritize enhancing performance of constructing resilient systems capable of enduring network interruptions and guaranteeing ongoing healthcare service provision [24]. The emergence of distributed edge orchestration and service deployment has presented new opportunities for addressing the challenge of resilient service placement at the edge, such as presented in [25] and [26]. The former proposes a decentralized container scheduler capable of building an edge cloud from volunteer resources using Docker containers, while the latter introduces a dynamic, event-driven orchestration architecture leveraging decentralized registries and local decision logic. However, both works focus primarily on architectural design and proofof-concept implementations. In this paper, we aim to further advance the state-of-the-art by implementing a functional prototype for a real-life application scenario, and evaluate feasibility of the concept against the traditional centralized deployment, with respect to the above metrics.
gency medical procedures already on site and extend the procedures during ambulance transportation to ensure the best patient outcome. Initially, they attach medical sensors to monitor the real-time health status of the patient, and during ambulance transportation, they enhance the monitoring with more advanced sensors and analytic tools that are connected to the hospital systems. Finally, the patient is handed over to the emergency unit of the hospital, during which the system must ensure the continuity of critical monitoring and treatment. The monitoring and treatment functions are implemented as nanoservices that follow the patient during the care pathway. Fig. 1 presents the overview of the use case, whereas Fig. 2 shows relevant phase-by-phase procedures that are used to deploy the use case nanoservices. Following are the four key phases identified for this emergency response use case: Phase 1 (on-site) – Identification: To monitor the patient with various medical sensors, the patient needs to be identified on site. For this, the paramedics attach a BLE-based smart wristband to the patient, which then connects to the Electronic Patient Care Record (ePCR) device the team carries with them. The ePCR device hosts the identification nanoservice. Phase 2 (on-site) – Resource discovery and service deployment: At the site, paramedics start monitoring the patient’s pulse rate (PR) and oxygen level (SpO2 ) with a pulse-oximeter. Later, the team utilizes a portable
III. U SE CASE : E MERGENCY RESPONSE SCENARIO As the use case for our work, we consider an emergency response scenario, where a patient in a serious medical condition – resulting from, e.g. a serious injury, stroke, etc. – needs to be transported to a hospital. The emergency response team needs to start the primary emer-
...
...
3
...
...
...
...
Storage
... Manager 1
Old Services from R1
New Services from
Primary Medical Services
R1
RPi 5
Accident Site
RPi 5
Worker 1
CT Imaging
Old Services from R3
New Service from R3
R2
2 1
Reports Generator
Worker 2
Advanced Medical Services
New Services from R1
Manager N
Migration
Visualizer
...
Service & Data
Oximeter
Service Bubbles
Service Bubbles
EEG ECG
3
Workers (1 … N)
Fig. 1: Resilient deployment of nanoservices for emergency patient monitoring.
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
lightweight Electrocardiogram (ECG) sensor for better observation. To get the data from these sensors, nanoservices related to each monitoring task need to be deployed at the ePCR device. For a successful deployment of the nanoservices, the requirements of the nanoservices and the suitable resources must be discovered beforehand. Phase 3 (in ambulance) – Resource discovery and service deployment: At this phase, paramedics move the patient from the site to the ambulance and mount a wireless non-invasive EEG device on the patient’s head to monitor and analyze brain activity as the patient becomes unconscious. Furthermore, the monitoring services are connected to the hospital system with the wireless connectivity provided by the ambulance. Moreover, to visualize the patient’s status, a visualizer nanoservice needs to be deployed. These new medical resources need to be discovered by the system and deployed at suitable computing nodes in the ambulance, either the ePCR device or another abbulance-mounted monitoring device. Phase 4 (from ambulance to hospital) – Data & service migration: When the patient transportation arrives at the hospital, the system must ensure the continuity of the patient monitoring despite the migration of monitoring tasks from ambulance and paramedic team’s devices to the devices at the hospital’s emergency unit. For this, the system must discover the newly available monitoring devices capable of continuing the patient monitoring and then redeploy the nanoservices to the hospital devices. The use case-related nanoservices are presented in Table I. TABLE I: Use case nanoservices. Phases Phase 1
Phase 2
Nanoservices Identification
Resource BLE wristband
SpO2
Oximeter
Visualizer
Display
RabbitMQ
Message broker
ECG
Movesense
Phase 3
EEG
–
Phase 4
DB
InfluxDB
1
Identification
Purposes Identify the patient. Detect oxygen saturation level & Pulse Rate (PR) of the patient. Visualize sensor data in a graphical formats Store generated data temporarily. Obtain the ECG signal from the patient. Collect EEG signal from the patient. Store all sensor data permanently.
2
Resource discovery & service deployment
4
IV. T HREE - TIER R EGISTRY A RCHITECTURE A. Proposed System Model 1) Framework setup: The success of the deployment depends on the availability of the underlying network between a computing node and a nanoservice provider, namely a registry server. For the seamless deployment of the nanoservices, we develop a 3-tier registry server to improve reliability, performance, and efficiency across distributed environments. Fig. 1 represents the system model of the 3-tier registry setup. In the 3-tier registries, the Local Private Registry (R1) is inaugurated mainly in the ambulance-mounted devices. Furthermore, the Remote Private Registry (R2) is depicted to be configured at the edge computing node of the mobile network, providing connectivity to the accident site and the ambulance, whereas the Remote Public Registry (R3) is considered to be deployed on a cloud data center. Table II shows the intended use and scope of the 3-tier registry setup for resilient deployment. The service development and deployment model illustrated in Fig. 3, where a developer team develops the source code of a nanoservice related to medical sensors and actuators, and a test team develops test code to check related bugs in the nanoservice. The system administrator reviews the code and provides the feedback to the relevant team if needed. The system then generates container images for different computing systems, e.g., for RPi 5, and then uploads those to different registries once the service passes test logic. Here, the R1 provides fast, resilient access to images for on-site workloads; the R2 enables regional caching and distribution, and the R3 serves as the central image repository. 2) Functional setup: The proposed system’s functionality is illustrated in Fig. 4, where the internal subprocesses of the nanoservices at different phases are denoted by the phase number followed by the subtasks. Identification: (1.1) When paramedics have attached a BLE-based smart wristband to the patient at the site, the wristband starts advertising its BLE ID. (1.2) Upon receiving this advertisement, the resource/service discovery (R+S) component in a paramedic’s ePCR device, depicted with an RPi 5 in our setup, checks if the “BLE Scanner UI” nanoservice is already installed/deployed. 3
Resource discovery & service deployment
4
Data & service migration
Wrist band
Oximeter
ECG
EEG
Data
Computer
Paramedics
Doctors & nurses
+ Phase 1: on site
Phase 2: on site
Phase 3: ambulance
Phase 4: ambulance and hospital
Fig. 2: Phase-by-phase procedures that are used to deploy use case nanoservices.
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
5
Feedback No
Local Code Repo
Dev Team
Local Private (R1)
Remote Private (R2)
Remote Public (R3)
Dev Codes Test Passed? Test Codes
Repo Server
Test Team
Create Container Image & Push to Registry
Yes
Sys Admin
Docker Engine
Feedback
(hospital)
Nvidia NX
RPi 5
Patient 1.1
Wrist band
(ambulance)
R+S
Nvidia Clara
Fig. 3: System Model. (on site & ambulance)
R1
R2
R3
Pulse Oximeter
1.2 – 1.5 2.1
R+S
2.2 – 2.7 R+S
2.8 – 2.12 EEG
3.1
R+S
3.2 – 3.5
4.1
cached
Service migration
3.6 – 3.9 R+S
Data migration
R+S
4.2 – 4.6 4.7 – 4.8
Fig. 4: Example sequence of nanoservice deployment in the use case scenario. (1.3) In this case, the nanoservice is not installed, and therefore the R+S sends a request to the local orchestrator to deploy the “BLE Scanner UI” from a service registry. The orchestror then sends the request to load the service from R1. (1.4) Once loaded, the nanoservice is deployed on the RPi 5. (1.5) Finally, paramedics register the basic patient info at the RPi 5 before starting the sensor data collection. Oxygen saturation and heart rate monitoring deployment: (2.1) Paramedics configure the pulse oximeter to start monitoring the patient’s oxygen saturation SpO2 and heart rate HR with the patient’s wristband ID, which then starts broadcasting with the wristband ID. (2.2) Upon receiving this broadcast, the R+S checks if the SpO2 nanoservice is already deployed at the RPi 5. (2.3) As the R+S notices that the nanoservice is not installed, it sends a request to the local orchestrator to deploy the nanoservice into the RPi 5. (2.4) Once the SpO2 nanoservice is deployed, the RPi 5 starts it. (2.5) Upon
a request from SpO2 nanoservice to store the data into a RabbitMQ Broker nanoservice, the local orchestrator checks if that nanoservice is already deployed at the RPi 5. (2.6) As the RabbitMQ Broker is not available in it, the local orchestrator tries to deploy it from R1, which forwards the request to R2, which again forwards the request to R3, as the nanoservice is available in neither of those. The RabbitMQ Broker is found at R3, which returns it to the local orchestrator, which then deploys it. The RPi 5 now starts storing the data into the broker. (2.7) Frequently used nanoservices are cached into R1 and R2 (e.g., RabbitMQ Broker in this step) to avoid the excessive deployment delay in the future requests. (2.8) To visualize the sensor data from the broker, the R+S tries to load the Visualizer nanoservice at the Nvidia NX in the ambulance, but fails as it is not available there. (2.9) As a result, the Visualizer nanoservice is requested from R1, which happens to have it. (2.10) After the deployment of Visualizer it starts receiving
TABLE II: Registries and their scope of use. Registry Local Private Registry (R1)
Remote Private Registry (R2) Remote Public Registry (R3)
Location On-premises (e.g., Ambulance & Hospital) off-premises (MEC & cloud e.g., ) off-premises (public cloud DockerHub)
Purpose Testbed setup
Scope / accessible by LAN / PAN devices
Restricted use (subject to the policy) Open / generic setup
Authorized devices Any device from anywhere
Example Nanoservices Identification (BLE Scanner), Oximeter (SpO2 ), Visualizer, ECG EEG InfluxDB
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
Registries R1
6
KPIs R3
R2
InfluxDB V, I, pf
Mosquitto (broker) 4
publish 3
Fig. 5: Implementation setup.
RPi 5
External Power
CPU-Mem Net. I/O
5 retrive
P, E
Netio PowerBox
network Quectel
subscribe
2
WiFi Router
Ubuntu VM 6
1
CPU-Mem Net. I/O
1
publish
2
... 6 CPU-Mem, Net. I/O 3 ... 6 Power / Energy
3
Grafana
Fig. 6: KPIs evaluation at RPi 5 (during → no traffic and pulling images).
SpO2 and HR data from RPi 5, (2.11) once those are published. (2.12) Finally, the Visualizer nanoservice starts visualizing the SpO2 and HR data in a display. Brain monitoring deployment: (3.1) In the ambulance, the paramedics configure the EEG device to start monitoring the patient’s brain status similarly to the previous case. The EEG sensor device is then registered to the system with the patient ID. (3.2) The R+S at the Nvidia NX (at ambulance) requests the EEG nanoservice. (3.3) As it is not installed, the local orchestrator tries to deploy the nanoservice from R1, which forwards the request to R2. (3.4) The EEG nanoservice is deployed from R2 (and cached into R1). (3.5) After that, the Nvidia NX starts EEG. (3.6) Once initiated, the EEG sensor start capturing and publishing EEG data to the Nvidia NX. (3.7) The RabbitMQ Broker now subscribes to EEG data from the Nvidia NX. Finally, RPi 5 acquires (3.8) and visualizes (3.8) the EEG data in a in a display. Service and data migration: (4.1) As soon as the ambulance reaches the hospital, R+S at the RPi 5 initiates the migration of the monitoring services to Nvidia Clara (depicting the hosting node at the hospital), by instructing it to deploy the needed nanoservices (BLE Scanner, RabbitMQ Broker, SpO2 , EEG). Similarly to the previous phases, the R+S initiates the deployment of these nanoservices. As all of these recently used nanoservices have been cached by R1 during the previous deployments, those are deployed from there. (4.2) To migrate the previously acquired patient data, the R+S at the Nvidia Clara requests the deployment of the DB nanoservice. After discovering that it is not locally installed, (4.3) the local orchestrator first tries to deploy it from R1 and then (4.4) from R2, and finally (4.5) from R3, from where it is successfully deployed. (4.6) After the successful deployment, the Nvidia Clara starts the DB nanoservice. (4.7) The Nvidia Clara subscribes to the RPi 5 and Nvidia Nx to transfer the relevant sensor data from those. (4.8) Finally, RPi 5 and Nvidia Nx publish all requested data to the Nvidia Clara. Once finished, the monitoring can continue at the hospital premises. The nanoservices no longer used at RPi 5 and Nvidia Nx can either remain deployed or be undeployed based
on the need. B. Prototype Implementation Nanoservices are deployed into worker nodes from the different registries (R1, R2 & R3), based on the usage and scope as defined in Table II. In our 3-tier registry setup, the Identification, SpO2 , ECG nanoservices (required by RPi 5), and Visualizer (required by Nvidia NX) are primarily deployed from the local private registry (R1). The EEG nanoservice is mainly deployed from the 5GTN-based remote private registry (R2). Additionally, all other publicly available Docker images, for instance, the RabbitMQ, DB, etc., are deployed directly from the Docker Hub public registry (R3). In addition, R1 and R2 keep the services deployed from upper levels in their caches for a predefined time, in order to serve faster the frequently deployed upper-level services. Figs. 5 and 6 depict the testbed setup of the 3-tier registry servers. Hardware specifications: The R1 registry server is deployed on a Debian GNU/Linux 12 (bookworm) OSbased RPi 5 having a Cortex-A76 ARM (aarch64) CPU along with 8 GB memory (RAM) and 32 GB storage. A 5GTN-based VM (in the University of Oulu) is used for the R2 registry server with Ubuntu 24.04.2 LTS (Noble Numbat) having an Intel(R) Xeon(R) Gold 6230 CPU along with 8 GB memory (RAM) and 64 GB storage. The node hosting the R3 DockerHub depends on the data center hardware. Software specifications: The nanoservices are virtualized as Docker containers. To deploy the containerized nanoservices, Docker Engine 27.3.1 is used in each node. Containerized nanoservices are stored in R1, R2 and R3 registry servers. To build the private registries R1 and R2, registry:2 Docker image is used. Furthermore, portainer/portainer-ce:2.21.4 Docker image is used optionally as the registry UI. Finally, GitLab 17.4.1-ee.0 and GitLab Runner v17.4.0 are used to build the entire continuous integration and continuous deployment (CI/CD) pipelines as depicted in Fig. 3. V. E VALUATION S ETUP The performance of the retrieval and deployment of
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
Docker images in our scenario—and in general— depends on the physical and logical distance between the worker node and the resource registry. Furthermore, there are significant differences in the resource consumption profiles—including CPU, network, storage, and energy resources—between the deployment from different registries. To evaluate the feasibility of the proposed approach, we conducted a Proof-of-Concept (PoC) experiment and identified a set of Key Performance Indicators (KPI)s to measure the performance and efficiency of the deployment. The evaluation setup used in the experiment is presented in Fig. 6. In the experiment, nanoservice containers (as described in Table I) are downloaded and deployed to a local RPi 5 device, acting as the registry client, from three different registries: R1, R2, and R3. A Cudy 5G NR AX3000 WiFi 6 router and a Quectel RM500Q-GL 5G modem enable the RPi 5 to download the required nanoservices from the registry servers through Wi-Fi and 5G network interfaces, respectively. The KPIs are monitored separately on the RPi 5 and the Netio PowerBox, as discussed below. A. KPI definitions: Performance: We measured the performance of the deployment by observing the round-trip time (RTT) in milliseconds (ms) and the number of hops (#) between the RPi 5 and registry servers and the overall download and deployment time in seconds (s) of deploying the used nanoservices from each registry service. We considered two different scenarios—cached and non-cached— depicting the scenarios where the registry server path is already known or unknown to the RPi 5. Computational load: The KPIs related to computational load (CPU and storage) were observed directly in RPi 5. The CPU load is presented in percentage (%) which is basically the average number of the processes that are either (i) running on the CPU or (ii) waiting in the runnable queue while the CPU is busy. The average storage utilization of images was observed in megabytes (MB) during the deployment. Both observations were carried out with Linux OS’s resource-monitoring tools. Network load: Similarly, the inflicted network load, i.e., incoming/outgoing network traffic, was observed at the RPi 5 registry client while a nanoservice container was being downloaded from different registries. The network load was measured in Megabytes per second (MB/s) with Linux OS’s resource monitoring tools. Power consumption: We used Netio PowerBox 4KF to acquire the power consumed by the RPi 5 and the Quectel modem. At first, the RPi 5 and the Quectel modem were mounted on 2 physical sockets in Netio, and then turned on through the Netio dashboard. Later, the voltage in (Volts, V), the current I in (Ampere, A) and the true power factor (pf ) were obtained from Netio,
7
while the Docker images were being downloaded from different registries. Algorithm 1 KPI analysis for 3-tier registry 1: Registries, R = {R1, R2, R3} 2: Users, U = {user1, user2, user3, ..., usern } 3: Tags, T = {t1, t2, t3, ..., tn } 4: Inputs: ← image, iterations 5: // Start: KPI monitoring processes (with MQTT) 6: for (registry, user, tag) ∈ (R, U, T ) do 7: sleep(5*60) // no-traffic – for 5 minutes 8: for i = 1 ← iterations do 9: sleep(20) 10: docker pull registry/user/image : tag 11: sleep(10) 12: docker rmi registry/user/image : tag 13: end for 14: end for 15: sleep(5*60) // no-traffic – for 5 minutes 16: // Stop: KPI monitoring processes (with MQTT)
B. KPI data collection: The KPIs for the 3-tier registry setup are collected with a Linux bash script while a Docker image (i.e., nanoservice) is downloaded to RPi 5 from the registries, as shown in Algorithm 1. The script accepts two inputs: (1) the name of the nanoservice image and (2) the number of iterations. With MQTT, the script starts monitoring the KPIs for 5 minutes for the idle period before downloading a Docker image from any registry. Generally, a Docker image is not downloaded if it is already in the local storage in RPi 5. To see the impact on the KPIs during downloading a nanoservice, the related Docker image is deleted from the local storage each time. In every iteration, there is a 20s pause before downloading and a 10s pause before deleting the image. At the end, the script terminates all MQTT-based KPI monitoring processes. C. KPI visualization: In the experiment, a WSL-based Ubuntu 24.04 VM was used to store and visualize the measured data. Fig. 6 presents the subtasks with red circles: (1) At first, the CPU, storage, and network utilization are acquired directly from RPi 5 using Linux tools; (2) the voltage (V), current (I), and power factor (pf) values are acquired from Netio and then sent to the Ubuntu VM via WiFi by using the MQTT-based pub-sub protocol; (3) the RPi 5 and Netio publish the acquired data to the Mosquitto 2.0.15 MQTT broker; finally, (4) the inflicted computational and network load data are stored
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
in InfluxDB 2.7.10 as soon as the data are available in the Ubuntu VM. Equation 1 is used to calculate the instantaneous power (watt, W) with Netio-acquired V, I and pf. During the deployment of a nanoservice, equation 2 is used to calculate the energy consumption with the mean power (P ) and mean download time (∆t) observed for a nanoservice. P ower, P = V × I × pf Energy, E = P × ∆t
(1) (2)
Both the power and energy consumptions are observed before storing in InfluxDB. (5 & 6) Finally, Grafana 10.3.1 is used to visualize all these KPIs in a graphical format in a web browser through a dashboard. VI. R ESULTS AND A NALYSIS A. Performance
0
12.48 12.53 16.54 16.73 13.63 15.07
11.37 11.42 12.15 12.34 10.55 11.99
9.04 9.09 10.46 10.65 9.07 10.51
11.14 11.19 12.10 12.29 8.91 10.35
12.00 12.05 14.70 14.89 13.64 15.08
5
Time (s) 10
15
We evaluate the performance of service deployments while different nanoservices are being downloaded from registries R1, R2, and R3. The download event is basically divided into two parts, e.g., registry discovery and actual content, or the nanoservice download. Thus, at first, the registry discovery is observed with the roundtrip time (RTT) and the number of hops between the client (RPi 5) and different registry servers. Here, the network hops indicate the links between the registry client, i.e., RPi 5, and the target registry server, including the intermediate networking devices (routers, etc.). According to the observation, only one hop is required to reach the R1 registry, as it is deployed locally. The mean latency in this case is 46.9 ms. To catch up to the R2 registry, 5-8 hops are needed in our case, resulting in 186.24 ms mean latency. The R3 is reached by 28-29 hops, resulting in the mean latency of 1435.18 ms.
SpO2 R1
Visualizer RabbitMQ R2
R3
cached
R1
ECG R2
R3
8
whether the registry server path is already known or unknown to the RPi 5. The summary of the observations is presented as stacked blue, orange, and green bars while the nanoservices are downloaded from R1, R2 and R3, respectively. The lower part of the stacked bars represent the download time when the routing path is known (cached) to RPi 5, while the upper part indicates the registry discovery time when the routing path is not known or cached at RPi 5. Therefore, in non-cached scenarios, the download time is the sum of registry discovery and actual download time. For instance, the RPi 5 takes 12.00 s to download the SpO2 nanoservice from R1 when the routing path is known to RPi 5, and another 0.05 s is added if the registry path to R1 needs to be discovered. Thus, it takes 12.05 s in total to download the SpO2 nanoservice while the registry path is not known beforehand. The RPi 5 downloads the same nanoservice from R2 in 14.70 (cached) / 15.89 s (noncached), and from R3 in 13.64 s (cached) / 15.08 s (noncached). The observations suggest that the RPi 5 reliably downloads a nanoservice from R1 when the external network is not in function, as predicted. When the same nanoservice is downloaded from R2 and R3, slightly less time is needed when the nanoservice is downloaded from R3 rather than R2, as R3 is maintained through a content delivery network (CDN), which makes it more optimized apart from its other higher-capacity physical configurations. The results for the other nanoservices (Visualizer, RabbitMQ, ECG and DB) can also be read from Fig. 7, showing similar trends. B. Computational efficiency We evaluate the computational efficiency by two measurements, the inflicted computational load, and the inflicted storage consumption. The results of these measurements are presented in the following subsections. 1) Computational load: We use the CPU load to evaluate the inflicted computational load on the RPi 5 registry client during downloading nanoservices from different registries. Fig. 8 shows the CPU load in RPi 5 during the SpO2 nanoservice download from different registries, and the no-traffic situations in between.
DB
non cached
Fig. 7: Nanoservices download time for R1, R2 & R3. In the next phase, we observed the overall time consumed by the deployment sequences for the five nanoservices used in our scenarios, when deployed from R1, R2 and R3. These results are presented in Fig. 7. For this, we consider two different scenarios: cached and non-cached. In real life, this scenario depends on
Fig. 8: Inflicted computational load at RPi 5. In our evaluation scenario, CPU load is initially observed for 5 minutes with no deployment activity in order
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
9
TABLE III: CPU Load observed in RPi 5 while nanoservices are downloading from R1, R2 & R3. Nanoservices SpO2 Visualizer RabbitMQ ECG DB
No traffic Mean Std. Dev.
10.0
0.0
Last 15 minutes CPU load (in percentage, %) at RPi 5 Local Private Registry (R1) Remote Private Registry (R2) Remote Public Registry (R3) Mean Std. Dev. Mean Std. Dev. Mean Std. Dev. 20.0 2.5 22.5 2.5 25.0 2.5 15.0 2.5 27.5 5.0 27.5 2.5 15.0 0.0 20.0 2.5 17.5 0.0 12.5 2.5 15.0 2.5 22.5 2.5 27.5 2.5 22.5 0.0 30.0 5.0
to observe the baseline CPU load. Then, CPU load is observed for 20 subsequent nanoservice downloads from different registries. With almost all the nanoservices, all 20 downloads from any registry were accomplished roughly in 15 minutes. Thus, a 15 minute CPU load is observed for a nanoservice while it is downloading from a registry. The overall result is consolidated in Table III. During the no-traffic situation, the mean CPU load at the RPi 5 registry client was measured to be around 10%. While the SpO2 nanoservice was downloaded from the R1, R2, and R3 registry servers, the average CPU load reached 20%, 22.5%, and 25%, respectively. In other words, the CPU load at the RPi 5 were increased by 10%, 12.5%, and 15%. In the case of visualizer nanoservice, R1, R2, and R3 increased the CPU load at RPi 5 by 5%, 17.5%, and 17.5%, respectively. In the case of RabbitMQ, the respective increases were 5%, 10%, and 7.5%, while in the case of ECG nanoservice, the readings were 2.5%, 5%, and 12.5%, and 17.5%, 12.5%, and 20% in the case of the DB nanoservice.
ment, GitLab consumes 3.45 GB, while GitLab Runner consumes 798 MB of disk storage at the Ubuntu-based VM. The registry:2 Docker image consumes 25 MB and 25.4 MB at the RPi 5 and the Ubuntu-based VM, respectively, which are used to deploy R1 and R2. The portainer/portainer-ce:2.21.4 Docker image consumes 302 MB in the Ubuntu-based VM, which is used for the registry UI. Docker internally compresses the containerized nanoservices before storing those into registry servers. Therefore, they need to be decompressed at the local node after downloading from a Swarm worker. Table IV (columns 9-12) presents the storage consumed by use case nanoservices at different registries (compressed) and on RPi 5’s local disk (decompressed). At the registry servers, the SpO2 , Visualization, RabbitMQ, ECG, and DB approximately consume 128.56, 100.46, 58.21, 101.45, and 155.24 MB. At the RPi 5, the decompressed nanoservices approximately consume 365, 399, 134, 215, and 416 MB, respectively.
2) Storage consumption: Different components are required for building the virtualized system and CI/CD pipelines to deploy the nanoservices. The step-by-step storage consumption is described below. Docker Engine requires five different packages. Table IV (columns 1-4) shows the storage consumed by these packages on RPi 5 and Ubuntu VM-based 5GTN to set up the R1 and R2 registry servers. In RPi 5, the docker-ce-cli, docker-ce, containerd.io, docker-buildxplugin, and docker-compose-plugin consume 40.1, 79.4, 97.5, 80.1, and 62.2 MB, respectively. On the other hand, in 5GTN VM, these packages consume 41.5, 111, 121, 82.5, and 53.9 MB, respectively. Docker-buildxplugin and docker-compose-plugin are optional, although helpful for debugging and deploying the Docker containers in a node. All Swarm nodes (both workers and managers) require docker-ce and containerd.io packages. Additionally, each Swarm manager requires docker-cecli. In our setup, each RPi 5-based Swarm worker and manager consumes 176.9 MB and 217 MB, respectively. Furthermore, each Ubuntu VM-based Swarm worker and manager consumes 232 MB and 273.5 MB, respectively. Table IV (columns 5-8) shows the storage consumption for setting up the CI/CD pipeline. In the experi-
C. Network efficiency The efficient use of network resources is an important factor of resource-efficient service deployment. For this, we compare the total local network load inflicted by deploying the nanoservices from alternative registries: R1, R2 and R3. In our scenario, the R1 resides within the local WiFi network, and therefore the RPi 5’s builtin WiFi is used for nanoservice downloads from the R1. Furthermore, the remote registries are connected through a 5G network connectivity. Therefore, a Quectel modem is used for deploying nanoservices from remote registries R2 and R3. Fig. 9 shows the average network load while the SpO2 nanoservice was downloading from registries R1, R2, and R3. According to the experiment, the RPi 5 downloaded the SpO2 nanoservice at 12 MB/s, 14.7 MB/s, and 13.64 MB/s from R1, R2, and R3. The visualizer nanoservice is downloaded at the RPi 5 from R1, R2, and R3 at 11.14 MB/s, 12.10 MB/s, and 8.91 MB/s, respectively. Furthermore, the RabbitMQ nanoservice is downloaded at 9.04 MB/s, 10.46 MB/s, and 9.07 MB/s. The respective results for the ECG nanoservice were 11.37 MB/s, 12.15 MB/s, 10.55 MB/s, 12.48 MB/s, 16.54 MB/s and 13.63 MB/s for the DB nanoservice.
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
10
TABLE IV: Storage consumption. +
⇒ managers
⇒ workers
for infrastructure
27.3.1 27.3.1 1.7.22 0.17.1 2.29.7
SpO2
Visualizer RabbitMQ R1 R2
9.04 10.46 9.07
11.14 12.1 8.91
14.7 13.64
12.0
Inflicted Network Load (MB/s) 0 5 10 15
1 → for building cross-platform images,
Packages
Version
Gitlab Gitlab Runner Registry Portainer (Registry UI)
17.4.1-ee.0 v17.4.0 2 2.21.4
ECG R3
for use case
Size RPi 5 5GTN VM – 3.45 GB – 798 MB 25 MB 25.4 MB –
2 → for deploying multi-containers,
16.54 13.63
docker-ce-cli docker-ce containerd.io docker-buildx-plugin1 docker-compose-plugin2
Size (MB) at RPi 5 5GTN VM 40.1 41.5 79.4 111 97.5 121 80.1 82.5 62.2 63.9
12.48
Version
11.37 12.15 10.55
Packages
⇒ optional
for CI/CD pipeline
302 MB
Nanoservices
Tags
SpO2 Visualization RabbitMQ ECG DB
v2 10.3.1 3.12.6-alpine v1 2.7.10
3 → compressed,
Size (MB) at server3 client4 128.56 362 100.46 399 58.21 134 101.45 215 155.24 416
4 → decompressed.
SpO2 nanoservice when it downloads from R1, R2, and R3 registries.
DB Fig. 10: Mean power consumption of RPi 5 & Quectel.
Fig. 9: Inflicted network load. According to the results, in most cases the RPi 5 utilizes the least bandwidth when the nanoservices are downloaded from R1. In the case of V isualizer and ECG nanoservices, more bandwidth is utilized while downloading from R1 rather than R3. However, the standard deviations (σR 1), and (σR 3), for the transfers from R1 are lower, indicating higher stability of the end-to-end network path. The highest network load is inflicted while the nanoservices are downloaded from R2. The commercial registry server R3 performs better than our on-premises registry server R2, as the R3 has more computational capacity than the R2. However, R2 is more stable than R3 when the standard deviation is considered.
D. Energy-efficiency We also observed energy consumption of the RPi 5 (device energy consumption excluding the networking energy consumption) and the Quectel modem (the networking energy consumption) while the nanoservices are downloaded from the R1, R2, and R3. Table V presents the observed mean power consumption (P ), mean download time (∆t) and the calculated mean energy consumption (E) for a deployment event of each nanoservice. To observe the baseline power consumption, the mean power consumption was observed for 5 minutes with no deployment activity before, in between and after the deployments. To exemplify the measurement process, Fig. 10 shows the real-time power consumption for the
In the no-traffic situation, the RPi 5 and the Quectel modem consume 4.61 W and 0.80 W, respectively. The total energy consumption for a download event is the sum of energy consumed by RPi 5 and Quectel modem. The mean energy of the devices is calculated with equation 2 by using the mean power and the mean download time. In the experiment, while a nanoservice is downloaded from R1, we do not consider the power consumption of the Quectel modem, as the RPi 5 uses the built-in WiFi module rather than the Quectel modem. Thus, the total energy consumption is equal to the energy consumption observed at the RPi 5 when a nanoservice is downloaded from R1. In the experiment, to download the SpO2 nanoservice, RPi 5 consumes 69.53 J of energy. While the same nanoservice is downloaded from R2 and R3, the energy consumption reaches 76.96 J and 107.24 J, respectively. As a result, R2 and R3 are causing 10.69% and 54.24% more energy consumption for a single download event. Similarly, R2 and R3 registries are causing more energy consumption, e.g., 30.76% and 92.53% for Visualizer, 5.07% and 78.88% for RabbitMQ, 35.12% and 96.61% for ECG nanoservices while these nanoservices download from the R2 and R3 registries rather than the R1 registry. The DB nanoservice, however, consumed slightly less energy while it was downloaded from the R2 compared to R1. The download from R3 increases the energy consumption by 108.92%. VII. D ISCUSSION AND F UTURE W ORK Although cloud-based service registries are globally available and powerful in normal conditions, they depend
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
11
TABLE V: Energy consumption at RPi 5 & Quectel while images are downloading from R1, R2, & R3. Nanoservices NT* SpO2 Visualizer RabbitMQ ECG DB
4.61
NT* → no traffic,
Mean power consumption (P in W) of RPi 5 Quectel R1** R2 R3 NT* R1** R2 5.54 5.88 5.81 1.52 5.55 5.61 5.46 1.41 5.43 5.62 5.26 0.80 1.43 5.65 5.81 5.65 1.46 5.47 5.70 5.48 1.51
R3 1.54 1.41 1.47 1.44 1.38
R1** 69.53 59.27 40.67 43.31 69.09
R1** → nanoservices downloaded through WiFi,
on reliable network connectivity, which is a critical drawback in the deployment of critical healthcare services. This study evaluated the performance and efficiency implications of a three-tier service deployment architecture – addressing the above-mentioned drawback – in a real-world use case scenario. Using a Raspberry Pi 5 (RPi 5) as a representative resource-constrained device and an emergency ambulance scenario as the motivating use-case, we examined how the registry placement affects the nanoservice deployment time, as well as the energy usage, network bandwidth, and computational load during the deployment. The performance of service deployments depends on the registry discovery from the client and the actual nanoservice download time. Both the RTT and number of hops in the registry discovery part gradually increase from the local registry to the remote centralized registry. However, the experiment revealed that the client quickly downloads a nanoservice from the local registry without requiring the external network in the three-tier registry setup. The client requires slightly more time when the same nanoservice is downloaded from an MEC-based registry rather than a remote centralized registry. Meanwhile, we also observed that deploying the nanoservices from the local registry leads to the lowest energy usage. Deploying from the registries located further away was observed to increase energy consumption due to longer data paths and communication overhead. We conclude that registry proximity is a major factor influencing the energy consumption of a service deployment. Moreover, our measurements related to the inflicted network load imply that the registry client requires less bandwidth when communicating with the on-premises local registry, likely due to reduced network hops and more stable local connectivity. Remote registries introduce more bandwidth overhead, partly due to external network dependencies and higher protocol negotiation costs. Furthermore, the computational load was observed to increase with the distance between the registry and the target node, indicating that processing overhead, including network stack operations, retries, longer session handling, etc., accumulates as the registry is further away. The remote public registry performs better than the local public registry because of higher backend resources
Mean energy consumption (E in J) for a single download event RPi 5 Quectel Total (RPi 5 + Quectel) R2 R3 R1** R2 R3 R1** R2 R3 61.15 84.77 15.81 22.47 69.53 76.96 107.24 61.93 90.69 15.57 23.42 59.27 77.50 114.11 34.06 56.86 8.67 15.89 40.67 42.73 72.75 46.77 67.86 11.75 17.29 43.31 58.52 85.15 53.64 115.30 14.21 29.04 69.09 67.85 144.34
R2 & R3 → nanoservices downloaded through Quectel Modem.
but still imposes more load on the RPi 5 than the local private registry. The qualitative trends suggest that registry proximity reduces device-side energy, bandwidth, and processing overhead by offering resiliency with fewer cyber attacks. Apart from this, the three-tier setup also supports scalability, where registries can offload storage and serve as alternatives. However, the three-tier registry setup has some limitations despite the various benefits. For instance, local registries require dedicated infrastructure and maintenance, which may not be feasible for all deployments. Meanwhile, MEC-based local public registries can suffer from resource bottlenecks in case they serve a high number of nodes, leading to degraded performance and higher energy and CPU overhead on end devices. This study focused on the service deployment. The full service lifecycle from developing nanoservices to deploying those into the devices in the hospital remains as the future work, including the criteria on selecting which service images should be made available locally. Furthermore, the devices may vary highly in terms of computational performance and capacity, as well as energy efficiency, capacity, and status, thus requiring more detailed performance and efficiency studies tailored to specific use case scenarios. Furthermore, we see a need for developing a layered trust model to optimize the tradeoff between performance and efficiency. For example, a local private registry is generally seen as more secure than public registries since the data is processed closer to the source, reducing the exposure to external threats. On the other extreme, public registries can be considered less trustworthy due to broader exposure to potentially hostile actors, thus requiring heavier security solutions. The recent advancements and integration of AI/ML-based approaches to dynamically assess and maintain trust scores in real-time, considering parameters like history of security incidents and breaches, response time, and traffic anomalies, seem to be a promising area for future research. VIII. C ONCLUSION This paper assessed a three-tier registry architecture for nanoservice distribution to edge devices in an emergency ambulance context. The results show that registry
IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 01234, NO. 56789, AUGUST 2026
proximity is the dominant factor affecting efficiency: the local registry yields the lowest energy use, bandwidth consumption, and CPU load on the Raspberry Pi 5, while MEC-based and cloud registries introduce progressively higher overheads due to increased communication distance and processing requirements. Nevertheless, the upper-tier registries provide scalability, resilience, and operational continuity that complement the performance advantages of the local tier. Overall, a local-first strategy, supported by MEC and cloud fallback, offers a balanced and dependable approach for resource-constrained, latency-critical edge environments. ACKNOWLEDGMENTS This research is supported by the Business Finland projects under Tomohead (grant 8095/31/2022), and Research Council of Finland-funded projects 6G Flagship (369116) and Profi6 (336449), Finnish Doctoral Program Network in Artificial Intelligence, AI-DOC (decision number VN/3137/2024-OKM-6). Ayan Mondal acknowledges the support from IIT Bhilai Innovation and Technology Foundation (grant IBITF/Note/EIRPRAYAS/SanctionLetter/2024-25/0897). R EFERENCES [1] S. M. Nagarajan, G. G. Devarajan, A. S. Mohammed, T. V. Ramana, and U. Ghosh, “Intelligent task scheduling approach for iot integrated healthcare cyber physical systems,” IEEE Transactions on Network Science and Engineering, vol. 10, no. 5, pp. 2429– 2438, 2023. [2] S. S. Nuguri, S. C. Bhamidipati, A. Kambhampati, K. Karthik, A. Calyam, M. K. Duvvuri, M. L. Alarcon, and P. Calyam, “Security and privacy framework for cloud-based remote patient monitoring and in-place sensor-based care,” Communications in Computer and Information Science, vol. 2716 CCIS, p. 188 – 213, 2026. [3] E. Harjula, P. Karhula, J. Islam, T. Leppänen, A. Manzoor, M. Liyanage, J. Chauhan, T. Kumar, I. Ahmad, and M. Ylianttila, “Decentralized iot edge nanoservice architecture for future gadget-free computing,” IEEE Access, vol. 7, pp. 119 856– 119 872, 2019. [4] B. Akdemir, H. Faheem Shahid, M. A. K. Brix, J. Lääkkölä, J. Islam, T. Kumar, J. Reponen, M. T. Nieminen, and E. Harjula, “From technical prerequisites to improved care: Distributed edge ai for tomographic imaging,” IEEE Access, vol. 13, pp. 14 317– 14 343, 2025. [5] H. F. Shahid, B. Akdemir, J. Islam, I. Ahmad, I. Ahmad, and E. Harjula, “Iot service orchestration in edge-cloud continuum with 6g: A review,” IEEE Internet of Things Journal, pp. 1–1, 2026. [6] A. Zerouali, “Analyzing technical lag in docker images,” in BENEVOL 2018, vol. 2361, 2018, Conference paper. [7] M. Osorio, C. Buil-Aranda, and H. Vargas, “Dockerpedia: A knowledge graph of docker images,” in ISWC (P&D/Industry/BlueSky), vol. 2180, 2018, Conference paper. [8] D. C. Marinescu, Cloud computing: theory and practice. Morgan Kaufmann, 2022. [9] K. Fu, W. Zhang, Q. Chen, D. Zeng, and M. Guo, “ Adaptive Resource Efficient Microservice Deployment in Cloud-Edge Continuum ,” IEEE Transactions on Parallel & Distributed Systems, vol. 33, no. 08, pp. 1825–1840, Aug. 2022.
12
[10] K. Cao, S. Hu, Y. Shi, A. W. Colombo, S. Karnouskos, and X. Li, “A survey on edge and edge-cloud computing assisted cyberphysical systems,” IEEE Transactions on Industrial Informatics, vol. 17, no. 11, pp. 7806–7819, 2021. [11] T. Shi, H. Ma, G. Chen, and S. Hartmann, “ Cost-Effective Web Application Replication and Deployment in Multi-Cloud Environment ,” IEEE Transactions on Parallel & Distributed Systems, vol. 33, no. 08, pp. 1982–1995, Aug. 2022. [12] M. Prabu, M. Diviya, R. Bhuvaneswari, D. S. Reddy, K. Venkatesan, and A. K. Natarajan, The impact and integration of cloud computing for enhanced patient care and operational efficiency. IGI Global Scientific Publishing, 2024. [13] Z. Ning, P. Dong, X. Wang, S. Wang, X. Hu, S. Guo, T. Qiu, B. Hu, and R. Y. K. Kwok, “ Distributed and Dynamic Service Placement in Pervasive Edge Computing Networks ,” IEEE Transactions on Parallel & Distributed Systems, vol. 32, no. 06, pp. 1277–1292, Jun. 2021. [14] Z. Xiang, Y. Zheng, D. Wang, J. Taheri, Z. Zheng, and M. Guo, “ Cost-Effective and Robust Service Provisioning in Multi-Access Edge Computing ,” IEEE Transactions on Parallel & Distributed Systems, vol. 35, no. 10, pp. 1765–1779, Oct. 2024. [15] G. Cui, Q. He, X. Xia, F. Chen, and Y. Yang, “ EESaver: Saving Energy Dynamically for Green Multi-Access Edge Computing ,” IEEE Transactions on Parallel & Distributed Systems, vol. 34, no. 07, pp. 2155–2166, Jul. 2023. [16] K. Suriyan, S. Ganesh, P. Palaniyammal, G. Priya, and V. Singh, Recent Trends in Edge Computing: Challenges and Opportunities. IGI Global Scientific Publishing, 2025. [17] N. Hussain, V. Dankan Gowda, C. Shyamsunder, V. Srinivas, R. Rani, and M. Balaji, “Optimizing iot device networks with edge computing to address latency and bandwidth constraints,” in 2024 5th international conference on electronics and sustainable communication systems (ICESC), 2024, Conference paper, p. 388 – 395. [18] S. Ramanathan, A. Pineda-Briseno, T. K. Mohd, and M. Ramasundaram, Edge Computing in Healthcare: Concepts, Tools, Techniques, and Use Cases. CRC Press, 2024. [19] A. Karami and M. Karami, “Edge computing in big data: challenges and benefits,” International Journal of Data Science and Analytics, vol. 20, no. 7, p. 6183 – 6226, 2025. [20] J. Islam, E. Harjula, T. Kumar, P. Karhula, and M. Ylianttila, “Docker enabled virtualized nanoservices for local iot edge networks,” in 2019 IEEE Conference on Standards for Communications and Networking (CSCN), 2019, pp. 1–7. [21] H. F. Shahid and E. Harjula, “Resource slicing through intelligent orchestration of energy-aware iot services in edge-cloud continuum,” in Proceedings of the 14th International Conference on the Internet of Things, 2024, pp. 244–245. [22] H. F. Shahid, J. Islam, I. Ahmad, and E. Harjula, “Optimizing resource-aware service orchestration in edge-cloud continuum,” in 2025 IEEE Intelligent Mobile Computing (MobileCloud), 2025, pp. 44–50. [23] S. Wiig and J. K. O’Hara, “Resilient and responsive healthcare services and systems: challenges and opportunities in a changing world,” BMC Health Services Research, vol. 21, pp. 1–5, 2021. [24] Q. Liu, K. G. Mkongwa, and C. Zhang, “Performance issues in wireless body area networks for the healthcare application: a survey and future prospects,” SN Applied Sciences, vol. 3, pp. 1–19, 2021. [25] A. Pires, J. Simão, and L. Veiga, “Distributed and decentralized orchestration of containers on edge clouds,” Journal of Grid Computing, vol. 19, pp. 1–20, 2021. [26] U. C. Özyar and A. Yurdakul, “A decentralized framework with dynamic and event-driven container orchestration at the edge,” in 2022 IEEE International Conferences on Internet of Things (iThings) and IEEE Green Computing & Communications (GreenCom) and IEEE Cyber, Physical & Social Computing (CPSCom) and IEEE Smart Data (SmartData) and IEEE Congress on Cybermatics (Cybermatics), 2022, pp. 33–40.