1 Introduction

The number of fragile people such as seniors, disabled and those with chronic diseases such as diabetics living in their own homes is increasing exponentially. As a result, there is a wide interest for efficient and effective ways to help monitor and care for patients in their home (i.e., outside the hospital environment). It has been shown that constant patient health monitoring can lead to 50% reduction in hospitalizations, 73% drop in emergency room visits, and 51% decrease in patient cost [1]. As remote patient monitoring is becoming standard care practices, the question of how to offer quality patient care outside the hospital setting and eliminate avoidable premature deaths in a cost effective manner have become an interesting but challenging problem [2, 3].

Advances in smart mobile devices and wearable sensors have recently fuelled the development of an automated real-time patient health status monitoring systems. Therefore, the development of technology-driven solutions that are capable of patients’ vital data collection such as blood pressure and glucose without the human involvement have received unprecedented attention in industry and research laboratories worldwide. In particular, IoT-based technologies have recently become eminent for creating non-invasive patient health status monitoring where various medical devices, sensors, and diagnostic devices can be viewed as smart devices or objects constituting a core part of the IoT.

Although IoT has the potential to be applied in many medical applications, the appropriate resource management of large amounts of monitored data is a critical issue in a remote electronic healthcare system. In fact, there are several constraints related to the core IoT devices such as limited memory, power supply and processing capabilities that negatively influence the performance of the networks. Moreover, they are solely focused on single application based per users. This forces each healthcare provider to deploy a personalized monitoring network, which restricts sharing of the physical sensors with other organizations particularly those that are not primarily involved in the same security aspects [4]. As these personalized networks require independent services in terms of their resources such as communication and networks, the cost is increased proportionally.

IoT-based technologies connecting medical monitoring devices through smartphones to cloud platforms have recently become eminent for creating non-invasive patient health status monitoring [5, 6]. The advantage of using such frameworks in patient health status monitoring systems is to develop a platform that allows authorized medical staff at various levels, to monitor patients’ situations in real time. The platform can reduce the cost of healthcare as services can be shared by different end users. Also, applying an IoT–WBAN platform in a health monitoring system enhances the efforts of system utilization by sharing information on that particular platform, thus enhancing the coordination and operations [7].

In this paper, we address the problem of creating cost-effective and non-invasive patient health status monitoring framework that integrates different services for healthcare on a common platform to provide an enhanced command and control. Although there exist many frameworks for patient health monitoring systems, the solutions still have technical challenges and remain insufficient [7, 8]. Moreover, there is no work that provides theoretical modelling for providing powerful shared resources and storage infrastructures. Recent research shows that developing a comprehensive remote patient health monitoring systems is still a research gap that need to be addressed [8, 9]. For instance, existing solutions are incapable of providing a robust underlying platform that is highly available, expandable and secure [10, 11]. They also slightly make use of varying Cloud services to benefit from Cloud capabilities. These gaps motivate our work.

In this paper, we propose an IoT-based remote patient health status monitoring framework that connects WBAN through smartphones to cloud platforms for use in healthcare environments. The proposed approach significantly contributes toward dissemination of the access of different applications to multiple users/organizations. In order to demonstrate the usability of our framework, we describe a case study based on our system architecture for people who suffer from neuropathy disorders. This paper makes the following contributions:

  1. 1)

    The framework enables users with access IoT-based applications without owning the sensor nodes. This work theoretically models virtualization of the biological nodes which is independent of the physical topologies.

  2. 2)

    The framework helps different users to share resources as per requirements. In this, same set of physical sensor nodes can be used for a set of the same applications lodged by different users. That obviously enhances power consumption and network lifetime for users.

  3. 3)

    The framework enhances scalability of users’ demands on the IoT and pay for only services. That remarkably improves related expenses as they can avoid deployments and maintenances associated with sensitive biological sensor nodes.

  4. 4)

    The framework provides consumers with accessing information as well as undertaking tasks without being dependent on a particular location thereby, providing flexibility and mobility.

The rest of the paper is organized as follows: Sect. 2 provides related work regarding Cloud-based remote monitoring systems. Section 3 presents the proposed architecture with a theoretical model. Section 4 discuss the framework with a case study. Section 5 describes the theoretical model of the proposed framework. Finally, conclusive remarks and future work are outlined.

2 Related work

In this section, literature relevant to the proposed work will be discussed. A new Cloud-based WBANs with statistical modelling techniques to enhance energy consumption and query latency is proposed in [10, 11]. Although the approach enhances efficiency of energy consumption, it cannot be reliable enough to be used in healthcare environment. That is because, their proposed model perform based on error tolerance and a probabilistic confidence interval. Therefore, vital signs are not continuously transferred that increase the risk of missing very critical information for a patient in an emergency situation.

The authors in [12] tried to enhance the processes of patients’ vital data collection in healthcare institutions. They automated this process by applying sensors attached to existing medical equipment that are inter-connected to ex-change services. The information is reported in the Cloud from where it can be processed by expert systems and/or distributed to medical staff. This work provides a full end-to-end telemedicine system based on Cloud services and wireless sensors. However, it does not address the existing resource constraints in the WBANs.

Hassan et al. [13] combines WBAN and Cloud for valid data sharing. The proposed network architecture is designed as four layers: perception layer, network layer, cloud computing layer, and application layer. In the network, the integration of TCP/IP and ZigBee in the coordinator devices is utilized. Consequently, WBAN coordinators can compatibility inter-operate with various local networks such as WiFi and LTE network to support high mobility of users. Besides, they improve the ability of the WBAN coordinator. Thus, it can support uninterrupted media healthcare content delivery. In addition, adaptive streaming technique was also utilized to reduce packet loss. However, scalability, security and security aspect of the approach are not taken into consideration.

Authors in [14] focused on Cloud Computing based on the Internet of Things in medical monitoring and management. They proposed and analysed architecture for remote monitoring Cloud platform of healthcare information. The employed Cognitive radio network (CRN) has become more prevalent due to the introduction of the IEEE 802.22 standard which aims to promote the sharing of the unused spectrum among primary and secondary users. Simulation results show that the proposed scheme can improve the efficiency about 50%. However the proposed approach meets some challenges. For instance jammers still remain a threat to the realization of a CR built on a WSN. Besides, authors did not provide a strict mathematical proof of their study.

In [15] a research has been carried out to manage data provided by body sensor networks through Cloud computing based infrastructure. Although these approaches have succeeded to enhance efficiency of energy consumption, the authors could not fully address the issues associated with energy consumption. That is because the energy consumption could have been more efficient if they could share the virtual sensor nodes for different applications.

Recently, there have been many research to reduce the costs associated with health monitoring systems. In [16] authors came up with a Sensor-Cloud based infrastructure that provide cooperative composite services provisioning. In this approach, users equipped with wearable sensor nodes. Absence of communication infrastructure and the poor communication quality are among the important challenging issues of this approach. Besides, they only considered the real-time processing of data already stored in the cloud server. Nevertheless, in health monitoring applications, sensors generate continuous data streams that need to be processed in a real-time manner as data arrives before being stored in cloud databases.

Eggert et al. in [17] focused on the diverse nature, implementation of the varied and scalable functionalities in an IoT–WBAN platform for health care environment. In [18] the authors developed a mechanism for transferring a large volume of sensory data from the local memory of sensor nodes to a Cloud storage. The authors took the responsibility of data processing to the Cloud with the purpose of enhancing efficiency of energy consumption. Alamri et al. [1] presented a comparison of the type of message flows for different algorithmic approaches. The authors have also explained the possible technical challenges in integrating WSNs and Cloud computing technology. In general, all the authors aimed to reduce cost along with the fairness, whereas in our work, we aim to reduce the cost while we use a compromise for different users.

In general, all the authors aimed to reduce cost along with the fairness, whereas in our work, we aim to reduce the cost while we use a compromise for different users. In this approach a group of applied sensor nodes can be used for multiple applications and shared as the intercommunication module can share the services among different applications from different organizations. In this, the cost can even be shared on a time base to reduce expenses.

3 Proposed framework

In this section, we present the proposed IoT–WBANs Cloud-based framework.

We assume that there are n. registered patients, \(P=\left\{ {p_1 ,p_2 ,\ldots ,p_\mathrm{n}} \right\} \). in the system. Each patient \(p_i \in P\). is assigned a unique identifier (\(pid_\mathrm{i}\)). We also assume that each patient owns a smartphone equipped with GPS. The location of the patients is frequently updated in the Cloud storage following the patient movement. We refer to authorised users (e.g., such as doctors and nurses) of services provided by the proposed framework as service consumers. We assume that there are m. service consumers, \(C=\left\{ {c_1 ,c_2 ,\ldots ,c_\mathrm{m}} \right\} \) in the system.

We also assume that there are \(\alpha \) different types of sensor nodes, \(T=\{T_1 ,T_2 ,\ldots ,T_\upalpha \), and

figure e

access point, A= {\(\hbox {A}_1 \),\(\hbox {A}_2 \),...,\(\hbox {A}_{\upgamma } \). }, in the system. The sensor nodes can form wireless body area network (WBAN).

Definition 1

A physical sensor node \(s_i \in S\) is represented by the following tuple:

$$\begin{aligned} s_{i} =\langle {id_{i} ,t_{i} ,L_{i}}\rangle \end{aligned}$$

where \(id_i \) is the unique identification number of the sensor node, \(t_i \) denotes the type of the sensor node, and \(L_i \) represents the current physical location of the sensor node.

In the proposed framework the communication interface for users is a web interface that has a server running at the site of the proposed framework as it has been used in [19, 20]. Thus, service consumers submit service requests/applications through a web page. Since they are in the same platform, they can share, revise and put notes on the collected patients’ information.

Figure 1 depicts a general view of the proposed framework for remote patient health status monitoring system. In the following subsections, we explain the key components of the proposed framework in more detail.

Fig. 1
figure 1

Cloud-based body area network framework

3.1 Platform layers

The proposed platform consists of a consumer interface, a Cloud interface and a virtual sensor/sever layer.

3.1.1 Consumer interface layer

The consumer interface component consists of the Web server, the Service Analyser, and the Consumer/patient Profiler. The Web server provides the consumers with an ability to log into and lodge their requests. They can lodge multiple applications from predefined services by providing information such as the ID of the patients and the required data with due times and due dates.

The Service Analyser interprets and analyses the service requirements for the requested applications submitted by the consumers. It consists of a variety of monitoring applications that are used for collecting and analysing health information based on the existing monitoring status. Specifically, three types of monitoring schemes are used: continuous, on-request and periodic. In continues form of monitoring, sensors continuously collect vital data and send them for further analysis. The on-request monitoring process is started based on requests from any authorized person in the system such as patients, doctors or nurses. Finally, periodic monitoring process can be established based on a periodic pattern. This is usually based on a defined start and end times from the controller of the system.

The Consumer/patient Profiler gathers specific characteristics of consumers so that important consumers can be granted special privileges and prioritized over other consumers. It also maintains information about the registered patients.

3.1.2 Cloud interface layer

The Cloud interface component consists of an Application Manager, an Intercommunication module and an IoT–WBAN platform Scheduler. On receipt of a request, the Application Manager creates the application, prioritizes the requests based on their urgency (\(\hbox {A}_{\hbox {urg}} )\) and then sends them to the Intercommunication module. The Intercommunication module acts as a gateway for an application to switch among the consumers to provide services with applying fewer resources. In essence, the emphasis on the intercommunication module is the core for the implementation of sensor-Cloud in an inter-service cooperation for operations and decision making. Finally, the IoT–WBAN platformScheduler is responsible for scheduling the tasks to accomplish on the basis of their priorities. Applications in this layer play very important roles in scheduling the requests. The applications also allocate resources on receipt of the requests from an application. It also keeps tracks of available resources to share them on the Cloud.

3.1.3 Virtualization layer

The virtualization layer is basically responsible for visualizing the nodes (sensors and/or servers) that consists of CPU, memory and networking components. This layer monitors the actual usage of resources by the nodes and accounts for the resource usage costs. It keeps track of the availability of the virtual nodes and their resource usage. Moreover, this layer allows multiple virtual nodes to be dynamically started and stopped on a single physical node according to incoming requested applications. Therefore, workloads can be consolidated and unused resources can be switched to a low-power mode, turned off or configured to operate at low-performance level.

3.2 Sensor layer

This module is the lowest layer of the healthcare monitoring framework and it is composed of two main procedures. The first procedure deals with data collecting phase. In this phase, patient’s vital signs such as blood pressure, blood glucose, temperature, etc. are monitored using body sensor nodes. We assume that there are adequate sensor nodes such as ECG (ElectroCardioGraphy), EMG (ElectroMyoGraphy), motion sensor, temperature sensor, etc. These sensor devices are able to sense and process health data [21]. Also, there are other sensors that collect none vital signs such as financial information of patients, their medicine and food consumption information as well as IP cameras to communicate with their doctors.

The second procedure deals with the transmission phase. In this phase, the monitored data is transferred to the Cloud via smart phone. There are several transportation protocols available for sensors such as Bluetooth over IEEE 802.15.1, ZigBee over IEEE 802.15.4, UWB over IEEE 802.15.6, and radio frequency identification (RFID). However, based on study in [22], communication protocols such as Bluetooth and Wi-Fi do not have enough energy that efficient to use in wireless body area network. On the other hand, the IEEE 802.15.4 standard was specifically designed to support low power and energy usage for WBAN.

Fig. 2
figure 2

IoT-cloud remote patient health status monitoring work flow

4 Illustration of the framework usage

In this section, we illustrate the applicability of the proposed framework in real scenarios. The main objective is to prove the usefulness of the main components of the framework where patients need to be remotely monitored. Although the proposed IoT-cloud based framework can be used in different medical scenarios such as detecting muscles disorders in a request based monitoring scheme, in this study we focus on monitoring patients with Myopathy or Neuropathy diseases.

Electromyography (EMG) is commonly used to diagnose disorders such as muscular neuropathy and myopathy [23]. We assume that the patients are equipped with wireless EMG physical sensors attached to their bodies. We also assume that the patients own smart phones that are capable of communicating through IEEE 802.15.4 standard. The patients also need to have a profile in the system with his/her personal details. The profile details include their medical histories and stored in IoT-cloud database. The patient’s information is indexed based on the patient’s identification number (ID).

Figure 2 depicts the workflow of the patient monitoring using the proposed IoT-cloud framework. The monitoring process can be initiated by authorized people by lodging applications to the Cloud service. The required information about each type of health application already exists in the Cloud. When a consumer initiates an EMG signal request through an online form in a web server at the first step, the system authenticates users to authorize them to lodge requests.

Next, the Service Analyzer interprets the request and picks the requested service. Then, in the Application Manager module, application type and urgency of the request will be checked and organized. After that, the request will be sent to Intercommunication stage to organize cooperation among the received applications if necessary. For instance, in some cases, GPs and medical institutions require to collect EMG data from a patient. In this case, the intercommunication module produces one set with similar requests and considers the set as one individual request. As a result, this module reduces running tasks in the IoT–WBAN platform.

Next, each requested applications is analyzed and scheduled to ensure that the addressed virtualization module is not overloaded with other lodged applications. Once the requests is prioritized and scheduled to be accomplished, virtualization layer establishes an allocation between the virtual sensors and the physical sensor nodes. The allocation process is based on patients’ locations. After configuration set up, sensors start gathering information to send to the smart phone.

The phone will send the data to the IoT-cloud to be processed in the Cloud service module. Then, the sensors will be de-allocated and ready to be used for other out coming applications. Based on the proposed framework, most of the computing calculations and decision makings occur in the Cloud service component of the proposed IoT–WBAN platform. For instance, EMG signal is very small and needs amplifiers to be proceed and visible on a display. The Cloud service also eliminates low or high frequency noise, or any other factors that may affect the outcome of the data. For more detail can be found in [24].

The data will then be analyzed using different methods in the Cloud service. For example, the system can automatically calculate patients’ health status based on the discrepancy between monitored value and a predefined minimum and maximum values of the healthcare parameter. If discrepancy is too high based on the historic and pre-defined data of patients, situation can be considered as an emergency. As emergency centers and ambulances are already connected to the system can automatically subscribe to get required services.

For patients at home, real-time location can be obtained by Time Difference of Arrival Time (TDAT) method. In outdoor and hospital environments, GPS on the smart phone will help to obtain patients’ locations quickly. Back to the service models, if discrepancy is out of the acceptable range gently, situation can be considered as warning. In this case, based on caregiver’s prescription, patients need a medical visit. In addition to the provided services, it is possible to install high speed cameras in patients’ locations to access to the video streaming and other multimedia facilities. At the end of the process, medical information can be saved in the Cloud center for future services.

The users’ profiles and medical history data are maintained by the data storage of the IoT–WBAN platform. According to a user’s service priority and/or doctor’s availability, the doctor may access the users’ information as needed. At the same time, automated notifications can be issued to his/her relatives based on this data via various telecommunication means. With Cloud support, the mobile devices of medical staff will easily exhibit richer mobile video streaming from remote cameras.

5 Theoretical model

This section mathematically describes the procedures performed in the proposed framework. The procedure starts by lodging applications to allocate physical sensor nodes on particular patients for the applications.

Definition 2

An application (\(A_{APP} )\) in the proposed framework is characterized by four tuple as follow:

$$\begin{aligned} A_{APP} =\{A_{id} ,A_{type} ,A_{urg} ,A_{P_{id} } \} \end{aligned}$$
(1)

where \(A_{id}\) represents unique identification number, \(A_{type}\) is the type of the application, \(A_{urg}\) is represents the urgency of the application and \(A_{P_{id}}\) identifies a specific patient targeted for the application.

The following example represents an application that collects body temperature of a patient with identification number 828 by a due date

$$\begin{aligned} A_{APP} =\left\{ 100,\hbox {Body tempreture},\hbox {Due date},828 \right\} \end{aligned}$$

Sine, there are four consumers (i.e., general practitioner, specialists, medical lab and ambulances as shown in Fig. 1) in the IoT-cloud framework, there could be four different applications lodged by four consumers. Also, consumers in some cases may submit a number of applications at the same time. For instance, authorized GPs might need to monitor the latest blood results of some patients during a day. The lodged applications can be expressed as below:

$$\begin{aligned} A_L =\cup _{t=1}^T A_{APP_t } \end{aligned}$$
(2)

where \(\hbox {L}\) represents the number of service consumers, \(\hbox {t}\) is the number of lodged applications of type \(\hbox {T}\). The applications then will be sent to the intercommunication module.

In the proposed framework, we monitor a set of applications together rather than monitoring each application individually. Let N. be the set of applications in the system waiting to be processed.

Definition 3

Two applications \(A_{APP_i}\) and \(A_{APP_j}\) are set to be identical provided that they meet the following conditions:

  1. a.

    \(A_{APP_i } \) and \(A_{APP_j}\) are submitted by different service consumer and \(i\ne j\);

  2. b.

    Each pair of corresponding entries are equal.

$$\begin{aligned} \left( \hbox {A}_{{\mathrm{id}_\mathrm{i} }} ,\hbox {A}_{{\mathrm{type}_\mathrm{i}}} ,{\hbox {A}_{\mathrm{urg}_\mathrm{i}}} ,\hbox {A}_{\mathrm{P}_{\mathrm{id}_\mathrm{i}}} \right) =\left( \hbox {A}{_{\mathrm{id}_\mathrm{j}}} ,\hbox {A}_{\mathrm{type}_{\mathrm{j}}} ,\hbox {A}_{\mathrm{urg}_{\mathrm{j}}} , \hbox {A}_{\mathrm{P}_{\mathrm{id}_\mathrm{j}}}\right) \end{aligned}$$

Based on the above definition, the system groups the N. applications into \(\hbox {k}\) subsets such that each \(N_i \in N\) contains identical applications but lodged by two or more different service consumers.

$$\begin{aligned} N=\left\{ {\hbox {N}_1 ,\hbox {N}_2 ,\ldots ,\hbox {N}_{\mathrm{k}} } \right\} \end{aligned}$$
(3)

For each set of applications, \(N_i {=}\left\{ \hbox {A}_{\mathrm{APP}_1 },\hbox {A}_{\mathrm{APP}_2 },\cdots ,\hbox {A}_{\mathrm{APP}_\mathrm{m}} \right\} \) such that \(m \ge 1\), we can monitor the m. application in \(N_i \). together simultaneously. For example, a GP and a researcher from a medical research institute can lodge an application to monitor heartbeat rates of the same patients. Hence, the heartbeat rate requests for each patient will be organized in one set, separated to other lodged applications. This reduces communication costs substantially.

Next, the applications in each \(N_i \in N\) is passed on to the scheduler. The scheduler prioritized the applications based on their urgency \(\left( {\hbox {A}_{\mathrm{urg}_{\mathrm{j}} } } \right) \). Once the application in \(\hbox {N}_\mathrm{i} \) are prioritized, a compatibility function \(f_{i}\) is introduced to select a subset of sensor types (\(\hbox {T}_\mathrm{i}\subset \mathrm{T}\)) on patients for the set of applications in \(N_{i} \).

$$\begin{aligned} f_i \left( {\hbox {N}_{\mathrm{i}} } \right) =\left\{ {\hbox {T}_\mathrm{i} :\hbox {T}_\mathrm{i} \in \hbox {T}} \right\} \end{aligned}$$
(4)

Based on type of the defined sensors, we need to choose physical sensor nodes belong to the patient. The selection of the sensor nodes is completed using a simple allocation function \(f_{alloc} ()\). The allocation function (\(f_{alloc} \left( {f_i \left( {\hbox {N}_\mathrm{i}} \right) } \right) \rightarrow \hbox {s}_\mathrm{i})\) maps the set of applications in \(N_i\) to a subset of physical sensor nodes belong to one or more patients in different locations.

$$\begin{aligned} f_{alloc} \left( {f_{i} \left( {N_i } \right) } \right) =\{s_i |s_i \in S,\left( {s_i\cdot t} \right) =T^{\prime }\} \end{aligned}$$
(5)

where \(s_i\) is the set of sensors belong to a particular patient, \(\left( {s_i\cdot \hbox {t}} \right) \) is the type of the chosen sensor worn by the patient.

After defining physical sensor node resources for applications in the same group, we now need to allocate virtual sensors to the physical sensor nodes in the Cloud platform. Therefore, we introduce a function \(f_{v}\) which is located in virtualization module of the architecture. This function maps the lodged applications (\(\hbox {A}_{\mathrm{APP}_\mathrm{i}})\) to virtual applications (\(V_{A\hbox {PP}_\mathrm{i}})\) as follow;

$$\begin{aligned} f_v \left( {\hbox {A}_{\mathrm{APP}_\mathrm{i}}} \right) :\hbox {A}_{\mathrm{APP}_{\mathrm{i}}} \rightarrow V_{\mathrm{APP}_{\mathrm{i}}} \end{aligned}$$
(6)

Since we have already considered the same applications as one lodged application we can use:

$$\begin{aligned} f_{v}^{-1} \left( {V_{APP_{i} } } \right) =f_{alloc} \left( {f_{i} \left( {N_{i} } \right) } \right) \end{aligned}$$
(7)

That shows each application that runs through the Cloud is mapped to a virtual application and runs on virtual sensor nodes. In fact, \(f_v\). maps physical sensors (\(s_\mathrm{i})\) to virtual sensor nodes existing in the Cloud. It considers \(s_\mathrm{i} \) as input and finds \(s_v \).

$$\begin{aligned} f_v \left( {f_{alloc} \left( {f_{i} \left( {N_{i} } \right) } \right) } \right) =\{v_{i} |v_{i} \in V\} \end{aligned}$$
(8)

where \(v_i\) is the set of selected virtual sensors to use for a set of applications (\(N_i )\) and V is the entire set of available virtual sensor node in the cloud.

Proposition 1

Sensor network controller in the proposed Cloud needs to assign a set of physical sensor nodes to each application.

Proof

to prove this we use method of contradiction. In this we assume that there is at least one application that does not have physical sensor i.e. \(\exists A_{PP_i } \rightarrow S=\emptyset \).

\(S = \emptyset \) that means \(f_{allocation} \left( {f_i \left( {N_i } \right) } \right) \). = \(\emptyset \) or \(f_v^{-1} \left( {V_{APP_i } } \right) =\emptyset \) thus, \(V_{APP_i } =\emptyset \), which means there is no application. \(\square \)

Proposition 2A: We claim that \(f_v (f_{allocation} \left( {f_i \left( {N_i } \right) } \right) \) is a one-to-one function. That means, every element of the function \(f_v \) codomain (\(V_{APP_i} \)) is the image of at most one element of its domain \(f_{allocation} \left( {f_i \left( {N_i} \right) } \right) \)

Proof

To prove that, we use method of contradiction. In this system there is at least one set of virtual sensor node that is created and can be assigned to two different set of the same applications.

$$\begin{aligned} \exists v_i \in V|\hbox {f}_\mathrm{v}^{-1}\left( {v_i } \right) =f_{allocation} \left( {f_i \left( {N_i } \right) } \right) . \end{aligned}$$

&

$$\begin{aligned} \exists v_i \in V|\hbox {f}_\mathrm{v}^{-1}\left( {v_i } \right) =f_{allocation} {{\prime }}\left( {f_i \left( {N_i } \right) } \right) \end{aligned}$$

Since \(f_v \left( {A_{PP_i } } \right) =V_{APP_i } \) and therefore we have \(f_v \left( {f_{allocation} \left( {f_i \left( {N_i } \right) } \right) } \right) =\{v_i |v_i \in V\}\), to use \(v_{i}\) for another application \(V_{{APP}_{j}} \) we need have another lodged application (\(A_{PP_j } \)), that means \(f_v \left( {A_{PP_i } } \right) =V_{APP_i}=f_v \left( {A_{PP_j } } \right) =V_{APP_j } \). or \(V_{APP_i } =V_{APP_j } \). That proves the contradiction as \(A_{PP_i} \ne A_{PP_{j}} \rightarrow V_{APP_i } \ne V_{APP_j }\) \(\square \)

Proposition 2B: there is no virtual sensor that is managed to use by more than one application by the IoT–WBAN platform.

Proof

to prove this we use method of contradiction. In this we assume that there is at least one virtual sensor node that is used for two different applications.

$$ \begin{aligned}&\exists v_{k} \in V:\left( v_{k} \in V_{APP_{i} } \right) \& \left( v_{k} \in V_{APP_{j} } \right) ,\\&V_{APP_j } \ne V_{APP_{i}} \end{aligned}$$

\(\hbox {f}_\mathrm{v} \left( \hbox {f}_{\mathrm{allocation}} \left( f_i \left( {N_i } \right) \right) \right) =\left\{ {v_i \hbox {|}v_i \in V} \right\} \). Thus we have \(\hbox {f}_\mathrm{v}^{-1}\left( {v_i }\right) =APP_i \) \(\hbox {f}_\mathrm{v} \left( {\hbox {f}_{\mathrm{allocation}} \left( {f_{i} \left( {N_{i} } \right) } \right) } \right) =\left\{ {v_{i} \hbox {|}v_{i} \in V} \right\} \). Thus we have \(\hbox {f}_\mathrm{v} ^{-1}\left( {v_{i} } \right) ={APP}_{j} \)

As a result we have \({APP}_{i} =APP_{j} \). Therefore, \(\not \exists v_{i} |\exists v_{i} \in V: f^{-1}\left( {v_j} \right) =VA_{PP_{i}} \) , which proves this proposition. . \(\square \)

6 Performance evaluation

In this section, we evaluate and compare the performance of the proposed framework against a traditional WBAN. The performance is analysed against energy consumption as well as maximum possible life time of the sensor nodes. We also examine the costs of deployment, maintenance and rent of the proposed health monitoring system.

As the proposed system is a basic Cloud computing environment, it is essential to evaluate it on a large-scale infrastructure. However, it is extremely difficult to conduct repeatable large-scale experiments on a real infrastructure. Therefore, to ensure the repeatability of experiments, simulations have been chosen as a way to evaluate the performance of the proposed approach as the existing approaches [20, 26]. We use the CloudSim toolkit as it supports modeling of on-demand virtualization-enabled resource and application management [27].

Table 1 presents the applied symbols in this paper. We assumed that transmission rate in the node is set to 1Mbps and the packet length to 128 byte. The throughput delivered by the 3G network is assumed to be equal to 15 Mbps to the WBAN as in [25]. Patients may either remain at their place or move randomly. The values are firstly assumed and then we modified the values based on trial and error method with the purpose of achieving clear and stable outcome for each simulation.

Table 1 Notations

To study and analyze the performance of the proposed framework accurately, we used energy consumption, sensor network lifetime and cost effectiveness as the performance metrics have been used in [20, 28] to examine QoS .

6.1 Energy consumption

Efficiency of consuming energy in monitoring systems is an incredibly important factor that can enhance quality of the service. Energy consumption of a sensor node \(\left( E \right) \) is calculated using the following Eq.

$$\begin{aligned} E=\hbox {E}_{\mathrm{tr}} +\hbox {E}_\mathrm{r} +\hbox {E}_\mathrm{s} +\hbox {E}_{\mathrm{Proc}} \end{aligned}$$
(9)

In this simulation, it is assumed that the units of energy consumption for both WBAN and the proposed IoT–WBAN platform are the same.

Figure 3 depicts the cumulative energy expenses of a sensor node in WBAN with and without Cloud architecture. The figure proves that the IoT–WBAN platform enhances energy consumption as compared to WBANs. That is due to many reasons. First, in a WBAN, intranet work communication occurs by repetitive multi-hop communication followed by packet transmission to a data center.

Fig. 3
figure 3

Energy consumption

However, in an IoT–WBAN environment, energy expenses due to transmission are mainly attributed to reach the Cloud platform via multi-hop communication. Communication among sensor nodes is very rare thus, large amount of energy is conserved. Moreover, unlike WBAN, a particular sensor node does not necessarily serve a user or organization, even if it is application compatible. However, in the proposed framework a group of applied sensor nodes can be used for multiple applications as explained by Eq. (3)–(5).

6.2 Sensor node lifetime

Lifetime of the WBAN in this approach is defined by an amount of time that a sensor node needs to perform and its residual energy reaches to a predefined value of energy. To calculate lifetime rate of a sensor node we use the following equation [28]:

$$\begin{aligned} L_t =t-\frac{\left( {E_{rs} -E_{th} } \right) \times \tau }{E_{in} } \end{aligned}$$
(10)

where \(E_{rs} \) is the residual energy of the sensor node, \(E_{in}\) is the initial energy of a node, t is the estimated time that the sensor node can perform and \(\tau \) isn an average required time for a node’s operation. Lifetime of a node is calculated as the number of sensing operations that is performed by the sensor node. It starts from the time of its deployment until its residual energy reaches below the minimum possible value that it can have.

Fig. 4
figure 4

Sensor node lifetime

Figure 4 depicts the sensor node lifetime reduction rate of the proposed framework and the WBAN. Considering the energy consumption rate of the sensor nodes in WBAN and the proposed framework, it is obvious that the reduction of lifetime rate in the proposed framework is less than that of the WBAN. That is due to the multihop communications followed by packets transmission to data centres. In the proposed approach energy consumption is mostly due to multihop communication data transferring to the Cloud.

6.3 Cost effectiveness

To evaluate the proposed approach from cost effectiveness point of view, we investigate the flow of expenses in the proposed framework and the WBAN. In this study, we analyze costs of deployment, maintenance and rent. Obviously sensor owners have different expenses to those who rent them as the owners need to consider expenses of purchasing, deploying and maintaining the sensor nodes. Therefore cost for a sensor owner in a WBAN can be calculated as follow:

$$\begin{aligned} Cost_{WBAN} =n\cdot \left( {C_{deploy} +C_{maintain} } \right) \end{aligned}$$
(11)

However, in the the proposed IoT–WBAN, each user or organization needs to rent the physical sensor nodes. The cost of the sensors for a fortnight is calculated by the following equation.

$$\begin{aligned} C_{RS} =\left| S \right| \times C_{rent} \times T_p \end{aligned}$$
(12)

where \(\left| S \right| \) is the number of registered active sensors by the sensor owners. This cost also would be shared as the intercommunication module can share the services among different applications from different organizations. The cost can even be shared on a time base. As a result, the cost of the services can be decreased significantly.

Fig. 5
figure 5

Cost effectiveness

Figure 5 compares the cumulative cost of the proposed framework and the WBAN. Note that the end user of a WBAN is responsible for several jobs involving maintenance and overhead. However, in the proposed framework, an end user perceives a sensor as an instantaneous service (similar to electricity and water), rather than as a hardware. Thus, users are liable to pay for only those services that they have actually consumed. The figure proves the decrease in the expenditure of an end-user organization in the proposed framework.

7 Conclusion

The need for remote patient monitoring has become a focal point in the healthcare environment with the growing aging population and people with chronic diseases. In this paper, we proposed an IoT-based framework that connects WBAN through smartphones to cloud platforms for monitoring health status of patients. The proposed framework is location independent and improves cooperation among different requested applications. Moreover, it is capable of processing different applications while sharing resources. Performance analysis showed that the proposed architecture substantially better performance as compared to the standard WBAN. The proposed framework did not consider the security and privacy concerns. We plan to address these issues in the future.