An Edge-Based Architecture to Support Efficient Applications for Healthcare Industry 4.0

Edge computing paradigm has attracted many interests in the last few years as a valid alternative to the standard cloud-based approaches to reduce the interaction timing and the huge amount of data coming from Internet of Things (IoT) devices toward the Internet. In the next future, Edge-based approaches will be essential to support time-dependent applications in the Industry 4.0 context; thus, the paper proposes BodyEdge, a novel architecture well suited for human-centric applications, in the context of the emerging healthcare industry. It consists of a tiny mobile client module and a performing edge gateway supporting multiradio and multitechnology communication to collect and locally process data coming from different scenarios; moreover, it also exploits the facilities made available from both private and public cloud platforms to guarantee a high flexibility, robustness, and adaptive service level. The advantages of the designed software platform have been evaluated in terms of reduced transmitted data and processing time through a real implementation on different hardware platforms. The conducted study also highlighted the network conditions (data load and processing delay) in which BodyEdge is a valid and inexpensive solution for healthcare application scenarios.

novel healthcare services are expected to reduce costs and increase the quality of life of users, the more data organizations collect, from both fixed and mobile medical monitoring devices, the more difficult is the effective use of a cloud-based centralized data processing and repository.
In fact, in the case of almost real-time applications the massive use of cloud-based infrastructure could affect the real-time constraints and burden the network infrastructure from the local to the cloud.Moreover, to provide healthcare services to a large scale of patients, simplistic approaches, in which the infrastructure between sensing devices and the cloud is used only as a common communication infrastructure, are not often feasible due to the presence of other healthcare challenges.For example, in some cases, to ensure patient's privacy, data cannot be stored in the public cloud or, in other cases, for patient safety, data must be immediately available and any delay or failure introduced by the cloud cannot be tolerated.
Speed of data and analysis is essential in many industrial IoT applications but is also a key element of industrial healthcare and all the other areas where we move towards autonomous and semiautonomous decisions made by systems, actuators and various controls.In particular, the degree of autonomy is one of the more important and desired goals of the next Industry 4.0 development stage.Thus, for a mix of reasons (bandwidth, costs, speed, predictive analytic, remoteness, maintenance) a faster, cheaper, and smarter approach than the traditional cloudbased one, needs to be implemented [2].
Very recently, smartphones are playing an increasingly important role in modern computing architecture, thanks to their mass distribution and the increasing computing resources.They are often used as mobile IoT gateways [3] or to support heterogeneous wireless sensor networks integration [4], but in our opinion, each personal mobile device (i.e.smartphone, smartwatch) can play a central role also in edge computing architecture.The inclusion of personal mobile devices in modern edge computing IoT systems can speed up the development of peoplecentric mobile solution, not only in the healthcare area, with an evident fallout on the improvement of the quality of life.On this direction, the use of personal mobile devices is the quickest and easiest way to support the integration of body sensor networks (BSN) and to provide large scale of m-Health services.According to this modern vision, healthcare edge computing is emerging as a way for entities to embrace near real-time results by processing data as close as possible to the source, definitely stating that cloud computing is not an efficient way to process data when data are produced at the edge of the network [5].
Within this challenging context, we propose BodyEdge, a novel edge-based architecture well designed to support emerging applications for healthcare industry.The main contribution of this paper is the design of a new communication and computing architecture for mobile healthcare monitoring based on the edge paradigm [5] rather than on the classical cloud paradigm to achieve the following.
r Reduced communication delay.r Wide support to scalability and responsiveness.r BSN and mobility support.r Limited cost in terms of bandwidth for data transmission (i.e. it is not needed to send all data to the cloud but only statistics).r Enhanced privacy level (i.e. the edge network can be con- sidered as a private cloud).The designed and implemented edge-based architecture mainly consists of two complementary components: i) a tiny mobile client module to be installed on mobile devices (i.e.smartphones, smartwatch) to integrate BSN and ii) a performing gateway, placed at the edge of the network, deployable on different resource constrained or resource-rich hardware platforms supporting multiradio and multitechnology communication to collect and locally process data coming from several application scenarios.Two different cardiac monitoring case studies have been implemented to detect high-stress conditions of automotive factory workers and athletes connected to both BodyEdge and a reference cloud platform in order to measure the overall system performance in terms of processing time, delay, and scalability.
The obtained results highlighted the system conditions and the application scenarios in which the proposed edge-based approach is very useful and convenient while standard cloud support should still be adopted for long-term storage and statistical analysis.
The remainder of this paper is organized as follows.Section II discusses the recent related works on IoT, BSNs, and edge computing for healthcare systems and applications, also pointing out the advantages of using edge devices respect to the classical cloud platforms.Section III describes the proposed BodyEdge system architecture, including specific features and application domains, also presenting the general system architecture to support healthcare composed by both body client and body edge sides.Section IV describes the case studies designed to test the new system architecture while the performance evaluation on a real testbed are presented in Section V. Finally, Section VII concludes the paper pointing out the main future research directions and open issues.

II. RELATED WORKS
The IoT paradigm is a viable solution to provide healthcare services to a large scale of patients; however, simplistic approaches in which the infrastructure between sensing devices and the cloud is used only as a common communication infrastructure, are not often feasible due to the presence of other healthcare challenges.For example, in some cases, to respect the patient's privacy, data cannot be stored in the public cloud or, in other cases, for patient safety, data must be immediately available and any delay or failure introduced by the cloud cannot be tolerated.
In the last few years, several solutions have been proposed to support healthcare services using standard cloud-based solutions.Hassanalieragh et al. [6] proposed a mobile Android application for electrocardiogram (ECG) monitoring.This solution does not support edge processing so health professional can take a decision only after cloud processing and not at the time the health device collects the signal.In the same direction, the authors of [7] proposed an application based on the ECG as a service that allows collecting, processing, storing, and analyzing ECG data streams generated by sensors worn by several individuals.Also, this solution needs cloud processing and miss reactiveness.More and more other solutions exist but all highlight the needs to overcome specific healthcare challenges.
With the advent of edge computing, the healthcare industry has evolved considerably due to its ability to store, process and analyze data closer to patients, hospitals, and clinics.In fact, the edge computing is permeating the industry so powerfully that doctors and physicians are starting to increasingly rely on it to support patient's treatment.In this context, many new research works have been conducted to demonstrate that standard cloudbased services still face various issues related to unpredictable delays, high bandwidth requirements and security/safety concerns.These issues are very critical to healthcare and active and assisted living scenarios where a correct and timely reaction can also result in saving a life or drastically reducing a disability (e.g., after a stroke).
In [8], authors define the edge computing as the enabling technologies allowing computation to be performed at the edge of the network.Edge computing is often exchangeable with Fog computing [9], but edge computing focus more closely to the things side, while Fog computing comes closer to the Internet infrastructure side.Under the edge computing paradigm, some application services are handled at the edge and some others are handled by a remote server in the cloud.This type of distributed analytics edge intelligence offers great potential to overcome healthcare challenges, improving the effectiveness and the efficiency of pervasive health monitoring.
According to this modern vision, a flexible multilevel architecture based on a computing paradigm in which heterogeneous devices at the edge of the network collect data, compute a task with minimal latency, and produce physical actions meaningful for the user, has been proposed and tested in [10].In the same direction, the authors of [11] proposed another IoT enabled healthcare system architecture which benefits from the concept of fog computing providing advanced techniques and services such as embedded data mining, distributed storage, and notification service at the edge of a network.Authors of [12] employed pervasive fall detection as a specific case study since fall is a major source of injury and mortality among stroke patients.They proposed a distributed fall detection system, named U-Fall, utilizing both edge devices (e.g., smartphones) and data center services (e.g., server in the Cloud) to achieve low miss rate and low false positive rate when compared to nonedge stateof-the-art systems.
Many existing contributions use a gateway as an edge intermediary between IoT devices and the cloud.However, such solutions fail to satisfy some critical challenges of the healthcare area, particularly for nomadic health monitoring, availability, security, and privacy.The aim of our BodyEdge solution is to overcome these domain-specific requirements by providing a solution that moves the edge closer to end users.

III. SYSTEM ARCHITECTURE TO SUPPORT MOBILE HEALTHCARE
In this section, we describe BodyEdge, a general IoT system architecture well designed to support specific applications for emerging healthcare industry.The need to develop such novel architecture comes from the accurate analysis of the nowadays healthcare contexts in which application requirements related to communication delay, scalability, responsiveness, transmission capacity, and data privacy are becoming more and more important; thus the wise integration and use of an edge communication device can play a key role to face few limitations of the public/private cloud platforms as pointed out in the previous section.
BodyEdge presents key features that make it much more than a simple improvement with respect to a reference architecture [13], [14]; in particular, it consists of two main components: a tiny BodyEdge mobile BodyClient (BE-MBC) software module and a performing BodyEdge gateway (BE-GTW).
Fig. 1 shows the use of the proposed BodyEdge architecture in different healthcare scenarios in which the users can be either workers in a factory, people playing sports or patients in a hospital.The multiradio and multitechnology edge gateway can collect and locally process data coming from different scenarios or it can exploit the facilities made available from both private and public cloud platforms according to the specific requirements of each scenario in order to guarantee a high flexibility, robustness, and adaptability level of service.
In particular, as shown in Fig. 2, the proposed framework is organized in a three-tier (i.e.cloud/edge/IoT devices) architecture in which the edge layer represents the connecting layer between the far cloud and the physical IoT devices whose data can be directly collected from the BE-GTW or through the BE-MBC in specific application contexts.

A. BE-MBC Architecture
The BE-MBC component, developed as a software application, can be installed on a smartphone and it communicates with the body sensors worn by the people using multiradio interfaces as described in [3], [4].It basically acts as a multiradio communication relay node in order to reach the edge gateway when the body sensors at the edge gateway are too far (due to the use of a small-range communication technology) or they cannot be directly connected to it (due to a not easy peering process to be physically executed by the user on the edge gateway).In these cases, such tiny mobile client is a mandatory component of the proposed communication architecture since it also acts as a simplified edge gateway with reduced capabilities toward the more powerful BE-GTW.However, the communication with the BE-GTW can also take place without any mobile client component when IoT devices can directly send their data to the BE-GTW as shown in Fig. 2.
Fig. 3 shows the functional scheme of the BE-MBC component constituted by the following modules.r BE-MBC database -it is used to store the acquired mea- surements on a local database on the smartphone in order to visualize and manage the acquired data.
r BE-GTW interface management -it allows the communi- cation with the BE-GTW for sending data and receiving control commands for the connected IoT devices.
r Graphical user interface -it handles an easy interaction with users.Through these modules, it is possible to show all measurements and access all settings of the software modules.

B. BE-GTW Architecture
In this section, we describe the general architecture of the BE-GTW to support applications for healthcare industry that is mainly composed by the following.
1) A remote interface management through, which the BE-GTW can directly communicate with external end users or Public/Private clouds by using specific APIs.2) A BodyEdge federator through, which the BE-GTW can communicate with other edge gateways placed in different locations with the aim of implementing a gateways federation for distributed services.3) A BodyEdge middleware (BEMW) to enable the various components of the BE-GTW architecture to manage data also guaranteeing interoperability.It includes the following internal blocks: a) Discovery: it is in charge of periodically executing a discovery procedure to find new IoT devices asking for a connection to the BE-GTW.b) Registry: it is responsible for registering all the IoT devices with their multiple sensors and actuators in the BE-GTW.It will add an entry in the Data Manager database with the information about each sensor and actuator.4) Application protocol controller: It contains all the communication protocols supported by the BE-GTW also implementing the common interfaces between those protocols and the other components such as the BE-GTW Configurator, the BEMW and the BEM.This component provides support to the messages exchanged during the registration phase and the triggering action of each IoT device.It also plays a central role during the communication between the remote public/private cloud platforms and the devices (through the BEMW) when they act as actuators and during the internal communications with its specific protocol modules (CoAP, MQTT, LwM2M, etc.) [16].5) BodyEdge manager: It is used by the BE-GTW when a local data processing can be performed without using external cloud resources or facilities.In these cases, a set of high-level data processing and mining functionalities such as those related to data fusion and computer vision, are made available for real-time local processing and computation.All the described modules are finally connected to the BE-GTW Configurator that contains the general gateway configuration parameters uploaded through a text file to be stored in a local memory.Every component can access the BE-GTW configurator component to get the right configuration values.

IV. CASE STUDIES DESCRIPTION
In this section, we describe the cardiac monitoring case study to test the proposed system architecture to detect high-stress conditions for users in two different scenarios.
r Workers in a factory.r Athletes training in a fitness center.
In these scenarios, we have to remark that the participants involved in each specific case study need to be equipped with a smart-watch in order to receive data from the chest band on the Bluetooth interface and to forward data toward the edge gateway on the Wi-Fi interface.In this way, we can correctly support a proper radio coverage needed to implement the described case studies.In these contexts, the BE-GTW architecture will be used to monitor the mental stress by acquiring and analyzing heart rate variability (HRV) signals [17], [18], as discussed in detail in the following section.HRV analysis in based on the study of the beat-to-beat variations in the heart rate.Doctors and psychologists agree on the importance of HRV for mental stress recognition, among other mental conditions such as anxiety, phobias and posttraumatic stress disorders.

A. HRV Features for Stress Detection
The input signal for any type of HRV analysis is derived from the interbeat, or RRi time series, which are obtained as the time difference between successive R-wave occurrences.That is, the ith RR interval is obtained as the difference between the heart beat at time i and i − 1 RRi = beat(t i ) − beat(t (i−1) ). ( Several features measure the variability within the RR series; they are mainly divided in time-domain and frequency-domain features.Fundamental time-domain HRV features for stress detection [19] include the standard deviation of RRi, the root mean square of successive differences, the NN50 (i.e., the number of successive intervals differing by more than 50 ms), and pNN50 (the proportion derived by dividing NN50 by the total number of RRi in the observation period).
Frequency-domain features for stress detection [20] involve the spectral analysis of HRV, and specifically the power spectral density of the RR series by considering the high frequency (from 0.18 to 0.4 Hz) component, the low frequency component, the normalized Power spectra in Low (from 0.04 to 0.15 Hz) and High (from 0.15 to 0.4 Hz) frequency ranges and the ratio of the low-to-high frequency spectra.

B. Testbed Implementation
The testbed.we implemented is specifically designed to be applied to all the considered communication scenarios to validate and measure the overall performance of the proposed system architecture.
In particular, the BE-MBC module has been installed on a Huawei watch 2 supporting the Android Wear 2.0 operating system and tested with a Polar H10 chest band to acquire the cardiac signal in real time; then the signal is sent to the BE-GTW  installed on two different hardware platforms: i) Raspberry Pi3 single board and ii) Zotac CI540 NANO Pc.
In addition, we also integrated the HRVFrame [15] within the BEM module of the BE-GTW in order to support processing and analysis of the received heart signals for stress detection.In particular, this software module consists of an extensive Java-based framework containing many features covered in the HRV analysis literature and, among the supported features, we considered those one described in Section IV-A.Moreover, the stress level of the subjects is measured on a time window of ten minutes representing the minimum observation period to obtain significant results [21].
Finally, we also used a simple wireless access point to route data coming from the users to a standard cloud platform such as Microsoft Azure on which we installed a Virtual Machine for remote processing.This further implementation is aimed to validate the proposed BE-GTW architecture with respect to the standard cloud based approach.In this way, we can make a fair comparison in terms of processing time, propagation delay and used bandwidth to outline the best choice with respect to the application scenarios.
Table I resumes all the hardware characteristics of both edge and cloud platforms used during the testbed while the specific communication scenarios are shown in Fig. 5.It is worth noting that also the prices shown in Table I are important parameters to guide the choice of the most suitable solution; in fact, since the raspberry Pi 3 platform is very cheap, it could be a valid choice in small environments with a small number of users.The performance analysis described in Section V will try to put evidence on these particular and meaningful aspects.

V. PERFORMANCE EVALUATION
In this section, we measure the performance of our proposal in terms of processing time and needed bandwidth for data transmission by increasing the number of connected users.The aim of this analysis is mainly devoted to highlight the system conditions in which the role of BE-GTW can be played by a constrained hardware platform instead of using more powerful and costly cloud computing resources that in some other conditions cannot be used because they do not meet the real time constraints imposed by specific applications.
Since the presented results aimed at evaluating the computational load of the presented BodyEdge architecture rather than the accuracy of the stress detection algorithm, we used real heart rate traces coming from previous studies on workers in automotive manufacturing [22] and athletes [23], [24] to progressively increase the computing load for the BE-GTW installed on three different platforms (i.e.Raspberry Pi3, Nano PC, and Azure cloud).This choice is also motivated by the lack of a significant number of subjects available for such field trials.The two reference scenarios are mainly motivated by the will to test the system performance on different heart rate baselines.In fact, since the factory workers have on average 75 beats per minute (bpm) whereas the athletes have 170 bpm, both the data traffic and processing load are different.
Following the presented approach, we have been able to measure the system performance without involving a big number of users directly.It is worth noting that the results, obtained by using already stored traces, are still meaningful from the computation load, bandwidth requirement and delay time perspectives.Fig. 6 shows the processing time by increasing the number of workers from 1 to 100 in order to study the system behaviour in different load conditions.In particular, we monitored the heart activity of the users for 5 hours by computing the time and frequency domain features described in Section IV-A over 10 minutes windows.It is worth noting that many healthcare applications require processing consecutive data windows partially overlapped to improve recognition precision and to update the recognition output more frequently.Thus, a key parameter to be considered is the shift ahead, which is often around 50% of the window length, but it could be much smaller [25].
The averaged obtained results show that the Nano PC and the Azure cloud virtual machine present very similar results in every load conditions while the constrained Raspberry Pi3 is always less performing but it can support up to 100 workers in less than 1600 ms.The same system parameter has been computed in the scenario involving the athletes doing trainer and the Fig. 7 shows coherent results; in fact, the processing time experienced by all platforms in this scenario is greater than the previous one since the athletes generate more data to be processed due to the higher cardiac activity (i.e.170 bpm on average).Anyway, the general trend of the obtained results is confirmed and we can argue that the constrained Raspberry Pi3 edge platform is still less performing with respect to the others, however it can support up to 100 athletes in less than 3200 ms.According to the presented results, it is possible to reduce the shift ahead of the data window up to 3200 ms in the worst case represented by the constrained Raspberry Pi3 platform with 100 connected athletes.
Fig. 8 shows the volume of transmitted data of RR signals from the users to the BE-GTW or to the Azure cloud for further processing.In particular, the presented data traffic are referred to a 10 minutes window; clearly those data are the same for the three tested platforms.The two monitored scenarios present the same trend but the main difference among them is due to the fact that the higher the average heart rate, the greater the amount of RR intervals to be transmitted.Of course, this analysis highlights one of the main advantage of the proposed BodyEdge architecture, which consists of avoiding the data transmission on the cloud platform.
Finally, we computed the round trip time (RTT) between the users and BE-GTW or the Azure cloud platform to complete the overall system performance analysis.We would like to remark that the RTT delay is only due to the network propagation time for transmitted data to reach the specific processing platform and come back to the users with the processed results.Table II shows the averaged values from which it is clear that the Azure cloud RTT delay is more than doubled respect to the edge platforms in both tested scenarios.

VI. OPEN ISSUES
As presented in this paper, there are clear advantages of introducing edge computing in the loop of healthcare system development; however, depending on application requirements, a number of research challenges have to be fully explored and faced yet.
Edge platforms for healthcare should effectively handle the gradual transition between different environments, e.g. when a patient leaves the highly instrumented infrastructure of a care center to enter the domestic context.
Device/patient mobility also introduces the need for seamless, dynamic execution of computational task; in fact, it is not enough to introduce computational resources between the devices and the cloud, but also to manage them according to changes in their availability.
Device integration and interoperability is another relevant challenge since new smart wearables continuously reach the market and should be added to the existing edge infrastructure, which should serve as abstraction and compatibility layer.
Finally, an effective edge platform should support prioritybased service administration since it should be possible to define and execute life critical services such as fall or heart failure detection with higher priority (in terms of bandwidth allocation and computation power) than e.g.fitness services.

VII. CONCLUSION AND FUTURE WORKS
In this paper, we presented BodyEdge, a software framework to support healthcare applications in local environments with the main aim of reducing the data traffic toward Internet.
The conducted studies, through a real testbed implementation, validated the soundness of the proposed architecture, also providing a way to measure the system performance in different network load conditions and hardware platforms.Two different case studies have been defined to support the evaluation phase, respectively, on workers operating in a factory and athletes training in a fitness center.The obtained results demonstrated a reasonable processing time (i.e. less than 3.5 s) up to 100 users with the constrained Raspberry Pi3 edge platform compared to a perceptible saving in terms of delay and data transmitted toward the cloud.Future works will be devoted to extend the validity and accuracy of the obtained results by conducting a test in which a significant number of people will be involved and monitored during their daily life stiles.In addition, we plan to extend our framework to support dynamic adaptation according to user-defined, possibly mutable at runtime, security, and privacy policies that might favor (and even force, in certain cases) the use of an edge platform rather than a public cloud.He is an Assistant Professor of computer engineering at the Department of Informatics, Modeling, Electronics, and Systems, at the University of Calabria, Italy.His research interests include wireless body sensor networks, smart-Health, and IoT technology.He has authored and coauthored more than 60 papers in international journals, conferences, and books.He is co-founder and CTO healthcare sector of SenSysCal S.r.l., a Unical spin-off focused on innovative IoT systems.

r
Manager -It starts all software blocks by handling the logic functionalities of the application at a high level.rCommunication engine -It contains all the possible bound services (i.e., ZigBee, ZWAVE, Wi-Fi, and Bluetooth) by handling the logical functionality of access to data and measures.The bound services are based on a standard client-server communication model by allowing other components and applications to be connected, to send requests and receive replies.

r
IoT Device handler -It is in charge of data inter- pretation exchange, control commands execution, and

Fig. 6 .
Fig. 6.Processing time increasing the number of workers.

Fig. 7 .
Fig. 7. Processing time increasing the number of athletes.

Fig. 8 .
Fig. 8. Transmitted data increasing the number of users.
Pasquale Pace (M'05) received the Ph.D. degree in information engineering from University of Calabria, Rende, Italy, in 2005.He is an Assistant Professor in telecommunications at the University of Calabria, Italy.He was a Visiting Researcher at the CCSR, Surrey, UK and the Georgia Institute of Technology.He has authored and coauthored more than 80 papers in international journals, conferences, and books.His research interests include cognitive and opportunistic networks, sensor and self-organized networks, interoperability of IoT platforms and devices.Gianluca Aloi (M'02) received the Ph.D. degree in systems engineering and computer science, at the Department of Electronics, Informatics and Systems of the University of Calabria, Rende, Italy, in 2003.In 2004, he is currently an Assistant Professor of telecommunications with the Department of Informatics, Modeling, Electronics and System Engineering of the University of Calabria.His main research interests include spontaneous and reconfigurable wireless networks, cognitive and opportunistic networks, sensor and self-organizing wireless networks, IoT technologies.Raffaele Gravina (M'16) received the Ph.D. degree in computer and systems engineering from the University of Calabria, Rende, Italy, in 2012.
elastic traffic (i.e.temperature sensing IoT devices) and delay sensitive and bandwidth inelastic (real-time) traffic (i.e.ECG sensing IoT devices).Inelastic traffic is further discriminated in two subclasses: a high-rate inelastic traffic (e.g., real-time video traffic) and a low-rate inelastic traffic (e.g., real-time ECG monitoring).

TABLE I EDGE
AND CLOUD COMPUTING PLATFORM SPECIFICATIONS