Efficient, Reliable and Secure Framework for the 5G Virtualization of the UltraSound Medical System

Efficient, Reliable and Secure Framework for the 5G Virtualization of the UltraSound Medical System Alessandro Carrega∗Antonio Passalacqua‡ ∗Department of Electrical, Electronic and Telecommunications Eng., and Naval Architecture (DITEN) University of Genoa (UNIGE), Italy {name}.{surname}@unige.it ‡ESOATE, Genoa, Italy {name}.{surname}@esaote.com Abstract—The integration of 5G and Internet of Things (IoT) technologies in the healthcare sector has paved the way for transformative advancements in medical imaging systems, particularly in the realm of UltraSound (US) imaging. This abstract delves into the innovative approach of virtualizing US medical imaging systems through cloud-edge computing, highlighting the benefits, challenges, and implications of this paradigm shift. The traditional US medical imaging process is often constrained by the technical limitations of local devices and the expertise of healthcare operators. Electronic Health Record (EHR) processes typically rely on on-premises hardware components for real-time data processing, leading to high acquisition costs and limited flexibility in system upgrades. By virtualizing US systems and migrating critical functions to the cloud-edge continuum, barriers related to hardware capabilities and localization can be overcome, enabling a more agile and scalable approach to medical imaging. The core concept of virtualization involves transforming US acquisition hardware and imaging viewers into smart, wirelessconnected entities that can seamlessly interact with cloud-based applications. This dematerialization of US system functions, except for the probe and input/output devices, allows for centralized data processing, analysis, and visualization. Through the deployment of Virtual Objects (VOs) and Composite VOs (cVOs), physical and virtual components can be intelligently managed and orchestrated to meet service requirements and optimize system performance. Index Terms—Framework, Virtualization, UltraSound Medical System, 5G, NFV, Security I. INTRODUCTION The current UltraSound (US) medical imaging processes are constrained by both the technical features of the local device and the knowledge of the (local) healthcare operator performing the examination. In fact, Electronic Health Record (EHR) processes are currently bound to on-premises dedicated hardware/firmware components to fulfil the need of a real-time or an almost real-time execution of the process [1]. As a result, acquisition costs/capital expenses are very high and limit the degrees of flexibility in upgrading the hardware and, consequently, the types and number of functions that can be (locally) provided. [2] Functions refer to those EHR processes that elaborate US data to provide the operator with additional qualitative information (often visualized over coloured overlay images over the black and white video) or quantitative data (spatial measures, pattern identifications, etc.). The goal of this Use Case (UC) is to connect, and somehow to decompose and virtualize US medical imaging systems into the cloud-edge continuum to lose any barriers due to the hardware capabilities and localization of current physical systems. As depicted in Figure 1, by exploiting and leveraging on Fifth-Generation (5G) and Internet of Things (IoT) technologies, the idea is to transform the US acquisition hardware and the medical imaging viewers into smart wireless-connected “things”, that can be “plugged and played” through the cloudedge medical imaging application: the essential functions of the US system, with the sole exception of the probe and the input/output devices (such as monitors, keyboards, etc.), must be dematerialized and migrated to the cloud/edge. Figure 1. Overall architecture of the e-Health UC. The ultrasound image processing currently involves a probe, image acquisition hardware, several local software functions devoted to the actual image processing and a monitor for displaying the images. The probe is a passive element cabled to the acquisition hardware in the device. The same device locally performs base and advanced image processing (typically using embodied Graphical Processing Units (gpus)) and renders the results on the local monitor. Since the image should have a high medical-grade resolution and that the whole imaging process is very complex, as it requires high volumes of data to be processed with strict latency (to react to human/operatordriven actions) and security constraints, present-day systems heavily rely on HardWare (hW)/FirmWare (FW) tools. The decomposition of such systems into the cloud-edge continuum encompasses: (a) the management through the Virtual Object (VO) stack of the connected physical acquisition and rendering devices, (b) the possibility to “plug and play” physical systems (by means of their VOs) into different instances of the ultrasound medical app to execute visits even by involving remote operators (with their monitors and keyboards), (c) the possibility of smartly manage (as-a-Service and at runtime) the processes for added value qualitative/quantitative analysis, medical reporting, and hardware maintenance [3] [4]. As shown in Figure 1, the virtualized components, along with additional processes, will be deployed across the edgecloud continuum, depending on the strictness of their time requirements. In more details, the base ultrasound image acquisition and visualization will become likely a tactile Internet application, and as such its proximity to the physical acquisition/rendering system will be crucial to provide the needed reactivity to the operator actions. On the other hand, the processes related to the medical reports’ generation are less time-critical and can be deployed in the cloud. Between these two categories of applications, the edge-cloud continuum is accomplished with several services which still have strict latency requirements, but not as in the tactile Internet realm. The most relevant of these applications regard the overlay processes in charge of elaborating the raw images to identify known patterns or perform measurements, which are heavily based on Machine and Deep Learning - Machine Learning (ML) and Deep Learning (DL) - techniques [5]. Finally, the current system capabilities will be improved by pairing the physical components and, potentially, some of the virtualized functions, with a VO. Such digital counterparts will support and extend the capabilities of the IoT devices as well as helping with the interplay of physical and virtualized processes, for example, by adapting the image coding to the monitor resolution, providing data pre-processing, by managing caching, etc. [6]. A. Benefits There are several possible advantages considering the goal described in the previous section. In particular, the benefits can be grouped in different categories based on the possible beneficiaries. From the point of view of the clinical device manufacture (e.g., ESAOTE) there is a dramatic cost reduction: no plastics, mechanical boards, spare parts. The focus is on the software transducers and high parallel computing network. There is also a dramatic reduction of transport and installation cost and service management and maintenance. An additional benefit could be a less environmental impact. Instead, from the point of view of the clinical staff and the hospital there is the possibility to use always up-to-date equipment with the support of remote control and diagnosis. This solution also allows a space reorganization. Finally, there are benefits regarding the reduced time for reporting and training for the clinical staff and the end-user (in this specific case: the patients). II. CASE STUDY: AMBULANCE IN A RURAL ENVIRONMENT (ARE) In this UC, the technologies and solutions will be tailored for a 5G-enabled Ambulance in a Ambulance in a Rural Environment (ARE) with the support of the mobility. Nonetheless, these can be adopted to a series of other similar scenarios where the mobility is involved, or where the environment has some connectivity limitations. A. Stakeholders Several stakeholders are involved in an ARE scenario in focus in this UC. These range from the paramedical and the emergency medical staff to the network and infrastructure providers. All of them may be categorized as belonging to the medical staff or the ones involved to the infrastructure management. Besides them, the main actor in focus for this UC is the paramedical and emergency medical staff. For instance, the paramedical staff can use the dematerialized ultrasound system inside the ambulance consisting of the probe and the data processing part for local elaboration. Due to the 5G connectivity, the data obtained using the probe can be elaborated with further and advanced analysis in the cloud. Besides the hardware, the hospital defines the logic of a EHR application to be deployed and executed over the A Lightweight Software Stack And Synergetic Meta-Orchestration Framework For The Next Generation Compute Continuum (NEPHELE) platform [7]. NEPHELE is a Research and Innovation Action (RIA) project funded by the Horizon Europe program under the topic “Future European platforms for the Edge: Meta Operating Systems” for the duration of three years (September 2022August 2025). Its vision is to enable the efficient, reliable and secure end-to-end orchestration of hyper-distributed applications over a programmable infrastructure that is spanning across the compute continuum from IoT to edge to cloud. In doing this, it aims at removing the existing openness and interoperability barriers in the convergence of IoT technologies against cloud and edge computing orchestration platforms and introducing automation and decentralized intelligence mechanisms powered by 5G and distributed Artificial Intelligence (AI) technologies The application logic is represented as a Hyper Distributed Application (HDA) graph which will be available on the NEPHELE repository. The application logic will define the high-level goal and the Key Performance Indicator (KPI) requirements for the application. To run and deploy the HDA represented by the graph, some input parameters will be given. The application graph will require the deployment of one or more VOs/Composite VOs (cVOs) to represent IoT devices like probes, a Minimal HW Device (mHWDev) for Local Processing (LP), a touchscreen display, and one or more generic functions to support the application. These will support the EHR operations with scanning, processing, and displaying capabilities. The VO description required by the EHR HDA graph will be available on the NEPHELE HDAs repository. The data processing part for local elaboration will be ready to be used with some basic software components running. For instance, this component already has Operating System (OS) installed and correctly set up, with some basic applications already running. Once the network connectivity is established the VO/cVO configuration will also enable some device management features to start and configure components on the devices and orchestration of software components according to the specific task to be executed over time. The paramedical staff will then use the physical devices and the HDA to guide them in their mission and benefit from the enhanced situational awareness offered thanks to the NEPHELE platform for the specific UC. Figure 2. Needs, functionalities and expected outcomes for the main users in the UC. B. Location The main physical location for the study case is the ARE. The ambulance is connected using the 5G to the central hospital where the emergency medical staff can make remote support with advanced analysis useful as feedback for the paramedical staff. The rural environment increases the complexity of this scenario, adding some possible limitations for the connectivity. In this regards the data processing elaboration can integrate the remote advanced analysis ensuring in any case an answer even when communication is not enough. The following hardware is used for the scope: Probe is a passive element cabled to the acquisition hardware in the device. It locally performs base and advanced image processing (typically using embodied gpus) and renders the results on the local primary screen. Touchscreen Display (TD) to control and configure the probe. mHWDev for applying preliminary and LP of the collected data stream. Keyboard to control and configure the probe. Primary Screen (PS) to visualize the analysed and processed image data. Figure 3. Devices at the physical, networking and computation levels. C. Constraints, Challenges, and Risks As reported in Figure 1, the study case carries with it several inherent constraints, risks, and challenges as detailed next. Risks •Ensure quick and safe intervention considering the security and the privacy of the patient data analysed in the edge / cloud part of the network. Constraints •In a rural environment scenario typically non network infrastructure is available or not reliable. •Regularity limitations may limit the service in a rural environment. For example, the use of 5G frequencies that are regulated by national and international regulations. Challenges •Fast response is required to ensure efficient and effective intervention. •To perform advanced analysis of the available data requires a high computation load which cannot be provided by the data processing devices located in the ambulance and used by the paramedical staff. Network coverage should be reliable during the whole time of intervention. •The device used by the paramedical staff are very heterogeneous in nature, such as probe, or touchscreen display. These devices differ in hardware, software and communication protocols used. III. TECHNICAL REQUIREMENTS AND CHALLENGES The distribution of ultrasound medical system into different application components in the cloud-edge continuum poses several challenges related heterogeneous performance levels required by the different functions (falling from “Tactile Internet” requirements to ones generally provided by current cloud systems), and to the way data is treated. Data security is of paramount importance for medical processes and so is the need of a real-time or an almost real-time execution of the process. To best face the needs of the EHR operations in the use case above and offer solutions to reach the overall goal for the solution we can identify the following main technical requirements and challenges. Orchestration of software components •Given the EHR application graph a dynamic placement of software components should be enabled based on service requirements and resource availability. •This will require performance and resource monitoring at the various levels of the continuum and dynamic components redeployment. Device Management •Some application functionalities can be pre-deployed on the devices or at the edge. •The device management should also enable bootstrapping and self-configuration, adding and removing devices on the fly, supporting hardware heterogeneity, and guaranteeing self-healing of software components. Low latency communication •Communication networks to/from a rural environment towards the edge and cloud should guarantee low delays for fast response under mobility conditions and possible disconnections. High bandwidth for edge/cloud •The data collected from the probe and after some preprocessing with the mHWDev should be sent to the edge/cloud for advanced analysis and to obtain additional diagnosis from remote and skilled operators. Smart data filtering/aggregation/compression •Large amount of data is collected from the probe. •A part of this data can be filtered, other ones can be down sampled or aggregated before sending it to the edge/cloud using the mHWDev for LP. •Smart policies should be defined to also tackle the high degree of data heterogeneity. IV. APPLICATIONS AND SERVICES OF THE STUDY CASE A. Application Scenario: Real-Time Cloud Elaboration This scenario refers to the application components and services to provide Real-Time (RT) elaboration of the data collected the different devices (probe and keyboard). The collected data using the probe and some command sent with the keyboard are sent to the cloud for additional elaboration. The mHWDev is responsible to make preliminary elaboration. For different VOs should be deployed for the following IoT devices: PS, mHWDev, TD, and the GateWay (GW) that is used to send the command from the Keyboard to the cloud. The Keyboard and the Probe devices are not directly connected to the network, and, for this reason, a specific VO is not required. A network connection fulfilling data rate and latency requirements for data streaming is required between the mHWDev and NEPHELE through the corresponding VO to send the data and process them. The communication between physical devices, the virtual counterparts at the VO and the other application components is enabled through the Zenoh [8]. protocol (some data communication can be integrated using HyperText Transfer Protocol (HTTP) and Representational State Transfer (REST) implementation). Some service will be running on the physical devices, whereas other on the edge and cloud continuum and will have to be configured through the VO. The mHWDev is responsible to decrease the amount of data sent to the cloud for the processing. In addition, it includes local storage to save the data in case the connection is lost and should be sent when the connection is recovered. From Figure 4 to Figure 6 we represent respectively the high-level view, the application graph, and the service graph for the RT Cloud Elaboration application scenario. Figure 4. RT Cloud Elaboration application scenario - High level. Figure 5. RT Cloud Elaboration application scenario - Application graph. Figure 6. RT Cloud Elaboration application scenario - Service graph. B. Application Scenario: Remote Support This scenario refers to the application components and services to provide remote support for maintenance, tutorial, and training activities. The elaborated data is accessible in RT using a dashboard on a Web Interface. Like the previous application scenario, a VO should be deployed the following IoT devices: PS, mHWDev, TD, and the GW. A network connection fulfilling data rate and latency requirements for data streaming is required between the mHWDev and NEPHELE through the corresponding VO to send the data and process them. The communication between physical devices, the virtual counterparts at the VO and the other application components is enabled through the Zenoh protocol. Some service will be running on the physical devices, whereas other on the edge and cloud continuum and will have to be configured through the VO. The Web interface includes a Dashboard that allows the following remote operations: monitoring, alerting, and replaying. In addition, with the Dashboard is it possible to make further remote elaboration for advanced analysis. From Figure 7 to Figure 9 we represent respectively the high-level view, the application graph, and the service graph for the Remote Support application scenario. Figure 7. Remote Support application scenario - High level. Figure 8. Remote Support application scenario - Application graph. Figure 9. Remote Support application scenario - Service graph. C. Application Scenario: Off-Line Remote Consultation This scenario refers to the application components and services to provide a data storage needed to perform off-line consultation of the elaborated data using a Web Interface. The web interface makes possible to program further elaboration that can be useful for maintained, tutorial and training activities in a similar way of the previous application scenario. A network connection fulfilling data rate and latency requirements for data streaming is required between the mHWDev and NEPHELE through the corresponding VO to send the data and process them. The communication between physical devices, the virtual counterparts at the VO and the other application components is enabled through the Zenoh protocol. Some service will be running on the physical devices, whereas other on the edge and cloud continuum and will have to be configured through the VO. The Data storage includes a Time Series DataBase (DB) that allows to view the history of the elaborated data that can be used to simulate a stored cases useful to make additional analysis and elaboration. From Figure 10 to Figure 12 we represent respectively the high-level view, the application graph, and the service graph for the Off-Line Remote Consultation application scenario. Figure 10. Off-Line Remote Consultation application scenario - High level. Figure 11. Off-Line Remote Consultation application scenario - Application graph. V. PHASES OF THE OPERATIONS FOR THE STUDY CASE The EHR operations can be split into the following four main sub-problems to be tackled. •Deployment of network infrastructure and application software. The network infrastructure should guarantee communication in the area and towards the Internet. The application software to be deployed in the involved devices includes all the components in the application graph and the VO/cVOs for the hyper-distributed application. •React to the dynamic environment which causes disconnections and requires monitoring (e.g., battery level status) and reconfiguration of devices. Once the network infrastructure is deployed, communication with all devices is to be guaranteed over time. •Data collection and analysis. Data will be collected by the physical devices and sent to the higher levels of the continuum for further analysis. •Clinical intervention operations that include collected data with probe, controlling and configuring the probe with the touchscreen display, take smart decisions for patients’ diagnosis and optimization. Figure 12. Off-Line Remote Consultation application scenario - Service graph. VI. APPLICATION COMPONENTS The EHR HDA will have a classic three-tier architecture with a presentation tier, an application tier, and a data tier. Presentation tier the application will offer a frontend for visualization of the clinical situation of the patient. The dashboard integrates data coming from the probe together related to the intervention area and the patients’ personal information. The dashboard will be accessible through a web browser or a Graphical User Interface (GUI) remotely and enable the Service Consumer to interact with the application tier to see the clinical status of the patient and analyse historical data for further information collection and clinical awareness. Application tier the inputs and requests coming from the presentation tier are collected and application components are activated to execute intervention operations. At this level, all application components for supporting the application logic in this UC are included. Some of these components will run directly on the IoT devices, some on the edge and some on the cloud through the VO/cVO. New data can be produced, and old data accessed from the data tier. Data tier includes a storage element for storing processed images or historical data about the EHR intervention. The data produced by the probes will be compressed, down sampled and/or secured before being stored for future use by the application tier. The data can be stored on the VO data store and is to be transmitted from the physical devices to the corresponding VO/cVO with low latency. VII. CONCLUSIONS The paper provides a comprehensive overview of the integration of 5G and IoT technologies in the healthcare sector, specifically focusing on the virtualization of US medical imaging systems. By leveraging cloud-edge computing capabilities, the traditional hardware components of US systems are transformed into smart, wireless-connected entities that can be seamlessly integrated into medical imaging applications. This transformation not only enhances the flexibility and functionality of US systems but also opens up new possibilities for remote diagnostics, real-time data analysis, and improved patient care. One of the key themes highlighted in the document is the shift towards dematerializing and migrating US system functions to the cloud/edge. This approach allows for the centralization of image processing tasks, enabling efficient data analysis, storage, and visualization. By virtualizing components and deploying them across the edge-cloud continuum, the system can adapt to varying time requirements and ensure optimal performance based on service demands. Furthermore, the integration of VOs and cVOs plays a crucial role in managing connected devices and facilitating seamless interactions between physical and virtual components. This not only simplifies the deployment of US systems but also enables remote operators to access and utilize the system for medical visits and analysis. The ability to dynamically allocate resources and orchestrate software components based on service requirements enhances the overall efficiency and responsiveness of the system. Moreover, the document emphasizes the importance of low latency communication, high bandwidth capabilities, and smart data processing techniques in optimizing the performance of US systems. By ensuring fast response times, reliable data transmission, and efficient data filtering/aggregation, the system can deliver timely and accurate diagnostic information to healthcare professionals. This is particularly critical in scenarios where real-time cloud elaboration of data is required for making informed clinical decisions. The implementation of ML and DL techniques further enhances the system’s capabilities by enabling pattern recognition, measurements, and advanced image processing. By pairing physical components with digital counterparts, the system can achieve higher levels of automation, accuracy, and adaptability. This not only benefits clinical device manufacturers in terms of cost reduction and improved efficiency but also enhances the overall user experience for healthcare providers and patients. In conclusion, the virtualization of US medical imaging systems through the integration of 5G and IoT technologies represents a significant advancement in the healthcare industry. By embracing cloud-edge computing, virtualization, and smart data processing techniques, healthcare providers can offer more personalized, efficient, and reliable diagnostic services to patients. The seamless integration of physical and virtual components, coupled with advanced data analysis capabilities, paves the way for a new era of healthcare delivery that is driven by innovation, connectivity, and intelligence. ACKNOWLEDGMENT This research was supported supported by the Horizon european project NEPHELE (grant agreement no. 101070487). REFERENCES [1] Shobha, B. Thapa, A. Bhuju, et al., “IoT enabled health care system,” in Proc. of the Int. Conf.on Augmented Intelligence and Sustainable Systems (ICAISS), Trichy, India: IEEE, Nov. 2022, pp. 1180–1184. DOI: 10.1109/ ICAISS55157.2022.10010830. [2] V. Dogra, A. Thanoch, C. P. Rai, et al., “Real-time health monitoring and management: Leveraging the power of IoT and Machine Learning,” in Proc. of the 7th International Conference on IoT in Social, Mobile, Analytics and Cloud (I-SMAC), Kirtipur, Nepal: IEEE, Oct. 2023, pp. 7–11. DOI: 10.1109/I-SMAC58438.2023.10290596. [3] S. Palarimath, P. M, T. K, et al., “Powering iot systems with 5g wireless communication: A comprehensive review,” in Proc. of the 8th Int. Conf.on Comm. and Electronics Systems (ICCES), Coimbatore, India: IEEE, Jun. 2023, pp. 420–424. DOI: 10 . 1109 / ICCES57224 . 2023.10192678. [4] N. Gupta, S. Sharma, P. K. Juneja, et al., “Sdnfv 5G-IoT: A framework for the next generation 5G enabled IoT,” in Prof. of the Int. Conf.on Advances in Computing, Comm. & Materials (ICACCM), Dehradun, India: IEEE, Aug. 2020, pp. 289–294. DOI: 10.1109/ICACCM50413.2020. 9213047. [5] B. Bhushan, “Synergizing AI, 5G, and Machine Learning (ML): Unleashing transformative potential across industries with a focus on network security,” in Proc. of the 3rd Int. Conf. on Advancement in Electronics & Comm. Eng. (AECE), Ghaziabad, India: IEEE, Nov. 2023, pp. 750–754. DOI: 10.1109/AECE59614.2023 . 10428548. [6] B. D. Deebak and F. AL-Turjman, “How to exploit 5G networks for IoT e-health security and privacy challenges,” IEEE Internet of Things (IoT) Magazine, vol. 4, no. 3, pp. 6–11, 2021. DOI: 10 . 1109 / IOTM . 0101 . 2000048. [7] European Project (EP). “A Lightweight Software Stack And Synergetic Meta-Orchestration Framework For The Next Generation Compute Continuum (NEPHELE).” (Jun. 2024), [Online]. Available: https://nephele-project. eu/ (visited on 07/11/2024). [8] Eclipse Foundation. “Zenoh - zero overhead network protocol.” (Jun. 2024), [Online]. Available: https://www. horse-6g.eu (visited on 07/05/2024).